| Oracle® Application Server Advanced Web Services Developer's Guide 10g Release 3 (10.1.3) B25603-01 |
|
 Previous |
 Next |
| Oracle® Application Server Advanced Web Services Developer's Guide 10g Release 3 (10.1.3) B25603-01 |
|
Previous |
Next |
This chapter describes the logging and auditing functionality available for Oracle Application Server Web Services. Auditing enables you to keep a complete, persistent record of request, response, and fault SOAP messages. It records the entire message. Logging enables you to extract and persistently store discrete portions of request, response, and fault SOAP messages.
Auditing enables you to keep a complete, persistent record of SOAP requests, responses, and faults. During development it is often very convenient to be able to inspect the contents of SOAP requests and responses to diagnose problems.In a production environment, specific SOAP messages can be stored to support non-repudiation efforts. For example, an on-line retailer could record all received purchase order requests.
Auditing also enables you to design a strategy that records and analyzes security-related events. A history of audit records can produce an audit trail enabling the reconstruction and examination of a sequence of events. The audit trail can be used to detect attacks, confirm compliance with policy, deter abuse, and so on.
Auditing is initiated and performed by the server. It cannot be initiated or performed by the client. Adding auditing to your Web service does not require changes or extensions to the WSDL.
If you enable auditing, there will probably be a measurable impact upon the performance of the system. You should use it only during development and debugging, or when there is a clear need to persist the entire contents of a message during production. Auditing for non-repudiation is a good example. In this case, it is likely that you will have to audit only a small set of Web service operations, so the performance impact should be acceptable.
The size of the logged messages will effect how large the performance impact will be. Larger message will take more time and system resources to store.
Auditing can be applied at runtime to messages flowing into the platform (request messages), flowing out of the platform (response messages), and generated fault messages. The following sections describe how the runtime processes these messages.
Example 6-1 illustrates a sample logged SOAP message. The original SOAP message appears in the <MSG_TEXT> element and is highlighted in bold in this example.
Example 6-1 Sample SOAP Message in the Audit Log
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2003-12-22T16:44:09.455-05:00</TSTZ_ORIGINATING>
<ORG_ID>wsm</ORG_ID>
<COMPONENT_ID>auditing</COMPONENT_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>jdoe-us</HOST_ID>
<HOST_NWADDR>111.2.3.444</HOST_NWADDR>
<PROCESS_ID>null-12</PROCESS_ID>
<USER_ID>jdoe</USER_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID><UNIQUE_ID>138.2.8.162:82684:1072129449465</UNIQUE_ID><SEQ>0</SEQ></EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><env:Header/>
<env:Body><operation:echo xmlns:operation="http://oracle.com/test/wsdl">
<String_1>Hello</String1></operation:echo></env:Body>
</env:Envelope></MSG_TEXT>
</PAYLOAD>
</MESSAGE>
When an inbound SOAP message is received, the runtime determines, based on the configuration, whether auditing is enabled for the port. The configuration also indicates whether request messages are to be audited. If auditing is enabled for both the port and operation, then the entire message is written to the audit log.
When the Web service implementation creates outbound response SOAP messages, the management features are applied in reverse order. If auditing is enabled for the port and the configuration also indicates that response messages are to be audited, then the entire message is written to the audit log.
The configuration information for auditing is located in the server-side Web services proprietary deployment descriptor oracle-webservices.xml. The contents of this file can be modified during packaging, deployment, or runtime. At runtime, changes must be made using either Application Server Control or by editing the ORACLE_HOME\j2ee\home\config\wsmgmt.xml file.
Auditing can be performed only at the operation level. Hence, there is no global or port-level configuration.
Auditing captures request, response, and fault messages and stores them in the persistent file ORACLE_HOME\log\wsmgmt\audit\log.xml. This is a rolling file: after it reaches a certain size, it is renamed log-[number].xml and a new log.xml file is started. Over time, older versions of the file may be deleted. Application Server Control can read this file. For information about this file see "Configuring Auditing for a Web Service" in the Application Server Control on-line help
An auditing configuration can be defined for each operation in a Web service port. The <auditing> element and its three attributes, request, response, and fault, define the auditing configuration. Each attribute can have a true or false value to indicate whether Web service management will store these messages. The following is a sample auditing configuration.
<auditing request="true" response="false" fault="false"/>
Example 6-2 illustrates the <auditing> element, highlighted in bold, as it appears in the oracle-webservices.xml deployment descriptor. Note that even though you cannot specify auditing for a port, a <runtime enabled="auditing"> element is still required at the port level. The schema for this file is:
http://xmlns.oracle.com/oracleas/schema/oracle-webservices-10_0.xsd
Example 6-2 Operation-Level Auditing Element in the Server-Side Configuration File
... <port-component name="String"> ... <runtime enabled="auditing"> ... </runtime> <operations> <operation name "..." > <runtime> ... <auditing request="true" response="true" fault="false"/> </runtime> </operation> </operations> </port-component> ...
Table 6-1 describes the attributes of the auditing element.
Table 6-1 Elements to Enable Message Auditing
| Element Name | Description |
|---|---|
|
<auditing> |
Has attributes
|
The configuration information for auditing is located in the client-side Web services proprietary deployment descriptor. Depending on the client application, this can be either orion-web.xml, orion-ejb-jar.xml, or orion-application-client.xml. The contents of this file can be modified during packaging or deployment.
Auditing can be performed only at the operation level. Hence, there is no global or port-level configuration.
Similar to the server-side, a client-side auditing configuration can be defined for each operation in a Web service port. The <auditing> element and its three attributes, request, response, and fault, define the auditing configuration. Each attribute can have a true or false value to indicate whether Web service management will store these messages. Table 6-1 provides a description of the <auditing> element and its attributes. The following is a sample auditing configuration.
<auditing request="true" response="false" fault="false"/>
The auditing configuration appears within the <operation> clause of the <service-ref-mapping> element. Each operation can have its own auditing configuration. Example 6-3 illustrates the skeleton of an orion-web.xml Oracle-proprietary client-side deployment descriptor that indicates the position of the auditing configuration in the hierarchy. The auditing configuration is highlighted in bold. Note that the configuration occurs within the <port-info> element. The schema for this file is:
http://xmlns.oracle.com/oracleas/schema/orion-web-10_0.xsd
Example 6-3 Sample Client-Side orion-web.xml with an Auditing Configuration
<orion-web-app ...>
<service-ref-mapping name="service/MyTestServiceRef">
<port-info>
...
<runtime>
...
<security/>
<reliability/>
...
</runtime>
<operations>
...
<operation name="echo">
<runtime enabled = "security,reliability,auditing">
...
<security/>
<reliability/>
<auditing request="true" response="true" fault="false"/>
...
</runtime>
</operation>
...
</operations>
</port-info>
</service-ref-mapping>
</orion-web-app>
OracleAS Web Services includes basic SOAP message logging. This functionality lets you extract and persistently store discrete portions of request, response, and fault SOAP messages.
There are many situations where you might want to persistently capture information from SOAP messages. For example many large organizations deploying internal Web services may want to track which groups within the organization are using the service. Logging could enable this by extracting and collecting group information from messages.
Logging is likely to have a minor impact upon the performance of the system. Since only simple types can be extracted from messages, this impact should be limited. If the logging mechanism is asked to extract large amounts of information from individual messages (for example, large text blocks) a proportional performance impact may occur.
Logging can be applied at runtime to messages flowing into the platform (request messages), flowing out of the platform (response messages), and generated fault messages. See the following sections for information on how the runtime processes these messages.
Example 6-4 provides a sample of a log record derived from an inbound SOAP request message. In the log, two messages are logged, account and amount.
Example 6-4 Sample Log File Entry
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2004-01-30T11:32:19.724-05:00</TSTZ_ORIGINATING>
<ORG_ID>wsm</ORG_ID>
<COMPONENT_ID>logging</COMPONENT_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>xwen-us</HOST_ID>
<HOST_NWADDR>138.2.8.175</HOST_NWADDR>
<PROCESS_ID>null-10</PROCESS_ID>
<USER_ID>xwen</USER_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID><UNIQUE_ID>138.2.8.175:52155:1075480339694</UNIQUE_ID><SEQ>0</SEQ></EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>account='Checking',amount='100.0'</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
When an inbound SOAP message is received, the runtime determines, based on the configuration, whether logging is enabled for the port. The logging mechanism then determines, based again on the configuration, what information, if any, is to be extracted from the message for the operation. This information is then stored.
When the Web service implementation creates outbound response SOAP messages, the management features are applied reverse order. If logging is enabled for the port and the configuration also indicates that information from response messages should be logged, then the information is extracted and stored.
The configuration information for logging is stored in the server-side Web services proprietary deployment descriptor oracle-webservices.xml. The contents of this file can be modified during packaging, deployment, or runtime. At runtime, changes must be made either by using Application Server Control or by editing the ORACLE_HOME\j2ee\home\config\wsmgmt.xml file.
Logging must be configured at the port and operation levels. There is no global-level configuration.
If logging features are employed, they must be configured at both the port and the operation level. The port-level configuration contains information that is referenced by the operation level. Unlike security, operation-level configuration does not override port-level configuration.
Logging information is stored in ORACLE_HOME/log/wsmgmt/logging/log.xml. This is a rolling file: after it reaches a certain size, it is renamed log-[number].xml and a new log.xml file is started.
Example 6-5 displays the port-level logging elements as they appear in the server-side Web services proprietary deployment descriptor, oracle-webservices.xml. These elements are used to create a set of namespace prefix and URI pairs that are referenced by the operation level configuration. The schema for this file is:
http://xmlns.oracle.com/oracleas/schema/oracle-webservices-10_0.xsd
Example 6-5 Port-Level Logging Elements in the Server-Side Configuration File
... <port-component name="..."> ... <runtime enabled="logging"> <logging> <namespaces> <namespace prefix='env' uri='http://schemas.xmlsoap.org/soap/envelope/'/> <namespace prefix='ns0' uri='http://oracle.com/test/wsdl'/> </namespaces> </logging> ... </runtime> </port-component> ...
Table 6-2 describes the port-level namespace elements that must be set for logging information to be reported. The namespace prefix-URI pairs are used for processing xpath expressions.
Example 6-6 illustrates the operation-level logging elements as they appear in the server-side Web services proprietary deployment descriptor, oracle-webservices.xml. At the operation level, you can enable or disable logging for request, response, and fault messages. The schema for this file is:
http://xmlns.oracle.com/oracleas/schema/oracle-webservices-10_0.xsd
Example 6-6 Operation-Level Logging Elements in the Server-Side Configuration File
...
<port-component name="String">
...
<operations>
<operation name="...">
<runtime>
...
<logging>
<request enabled='true'>
<attributes>
<attribute name='input'
...
xpath='/env:Envelope/env:Body/ns0:echo/String_1/text()'/>
</attributes>
</request>
<response enabled='true'>
<attributes>
<attribute name='output'
xpath='/env:Envelope/env:Body/ns0:echoResponse/result/text()'/>
</attributes>
</response>
<fault enabled='true'>
<attributes>
<attribute name='output'
xpath='/env:Envelope/env:Body/ns0:echoResponse/result/text()'/>
</attributes>
</fault>
</logging>
</runtime>
</operation>
</operations>
</port-component>
...
Table 6-3 describes the message logging elements: request, response, and fault. Setting an element to true enables logging for that message type. If logging is enabled, you can specify one or more attributes you want to log for each message type. These attributes are indicated by its name and xpath.
If logging for a message type is enabled, but no attributes are configured, then no logging will occur. Similarly, if the xpath query returns no results, then no logging will occur.
Table 6-3 Elements to Enable Message Logging
| Element Name | Description |
|---|---|
|
<request> |
If |
|
<response> |
If |
|
<fault> |
If |
This section provides an overview of the parts of the Web service auditing and logging configuration that can be set by the JDeveloper and Application Server Control tools. For detailed information of the individual auditing and logging options that can be controlled by these tools, see the on-line help for Application Server Control and JDeveloper.
This section describes how to use WebServicesAssembler commands to add an auditing and logging configuration to a Web service. A configuration can be added in a top down or bottom up Web service assembly. Auditing can also be assembled into a Web service client (logging is not available on the client). In each case, the configuration is specified in an XML file and passed to the WebServicesAssembler command with the ddFileName argument.
The following general steps describe how to assemble an auditing and logging configuration into a Web service bottom up.
Create the XML file that provides settings for the auditing and logging features you want to enable. There are two different ways in which you can do this.
Manually write the XML file that contains the auditing and logging settings. Example 6-8 illustrates a sample XML file that contains these settings. Save the file.
Run the WebServicesAssembler tool with the appropriate *Assemble command for your Web service. One of the files it creates will be an oracle-webservices.xml file that contains a skeleton of the ports and operations. For example, you could run the Ant task in Example 6-7 without the ddFileName argument to obtain this file. Edit oracle-webservices.xml file to enter the appropriate settings for the auditing and logging features. Save the file under a different name.
"Server-Side Auditing Configuration Elements" and "Server-Side Logging Configuration Elements" describe the port-level and operation-level auditing and logging features that are available on the server.
Use the appropriate *Assemble command to assemble the Web service. Use the ddFileName argument to pass the file with the auditing and logging configuration you created in Step 1 to the WebServicesAssembler tool.
"Web Service Assembly Commands" in the Oracle Application Server Web Services Developer's Guide provides more information on the commands that can assemble a Web service bottom up. See "ddFileName" in the "Deployment Descriptor Arguments" section of the Oracle Application Server Web Services Developer's Guide for more information on this argument.
Example 6-7 illustrates an assemble Ant task that uses the ddFileName argument to add the auditing and logging configuration in wsmBankServiceConfig.xml to the Web service.
Example 6-7 Passing an Auditing and Logging Configuration in a Bottom Up Web Service Assembly
<oracle:assemble appName="bank"
targetNamespace="http://www.oracle.com/bank"
typeNamespace="http://www.oracle.com/bank"
serviceName="Banking"
interfaceName="oracle.ws.server.bank.Bank"
className="oracle.ws.server.bank.BankImpl"
input="./build/classes/service"
output="build"
ear="build/bank.ear"
style="rpc"
use="encoded"
ddFileName="wsmBankServiceConfig.xml"
>
</oracle:assemble>
Example 6-8 illustrates the contents of the wsmBankServiceConfig.xml for a server-side auditing and logging configuration. While both auditing and logging are enabled at the port level, only a logging configuration is provided. At the operations level, an auditing configuration is provided for the withdraw operation and a logging configuration is provided for the deposit operation. Note that the contents of the file are enclosed in the <oracle-webservices> element.
Example 6-8 Sample Server-Side Auditing and Logging Configuration
<?xml version='1.0' encoding='UTF-8'?>
<oracle-webservices xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/
oracle-webservices-10_0.xsd">
<webservice-description name="Bank">
<port-component name="HttpSoap11">
<runtime enabled="auditing, logging">
<auditing/>
<logging>
<namespaces>
<namespace prefix="target_ns" uri="http://oracle.com/bank/wsdl"/>
<namespace prefix="soap" uri="http://schemas.xmlsoap.org/soap/envelope/"/>
</namespaces>
</logging>
</runtime>
<operations>
<operation name="withdraw">
<runtime>
<auditing request="true" response="true" fault="false"/>
</runtime>
</operation>
<operation name="deposit">
<runtime>
<logging>
<request enabled="true">
<attributes>
<attribute name="request_string"
xpath="/soap:Envelope/soap:Body/target_ns:deposit/String_1/text()"/>
</attributes>
</request>
<response enabled="true">
<attributes>
<attribute name="response_result"
xpath="/soap:Envelope/soap:Body/target_ns:depositResponse/result/text()"/>
</attributes>
</response>
</logging>
</runtime>
</operation>
</operations>
</port-component>
</webservice-description>
</oracle-webservices>
The following general steps describe how to assemble an auditing and logging configuration into a Web service top down.
Create the XML file that provides settings for the auditing and logging features that you want to enable. There are two different ways in which you can do this.
Manually write the XML file that contains the auditing and logging settings. Example 6-8 illustrates an XML file that contains sample auditing and logging settings.
Run the WebServicesAssembler tool with the topDownAssemble command. One of the files it creates is an oracle-webservices.xml file that contains a skeleton of the ports and operations. For example, you could run the Ant task in Example 6-9 without the ddFileName argument to obtain this file. Edit oracle-webservices.xml file to enter the appropriate settings for the auditing and logging features. Save the file under a different name.
"Server-Side Auditing Configuration Elements" and "Server-Side Logging Configuration Elements" describe the port-level and operation-level auditing and logging features that are available on the server.
Use the topDownAssemble command to assemble the Web service. Use the ddFileName argument to pass the file with the auditing and logging configuration you created in Step 1 to the WebServicesAssembler tool.
"Assembling a Web Service from a WSDL" in the Oracle Application Server Web Services Developer's Guide, provides more information about the topDownAssemble command and assembling a Web service top down. See "ddFileName" in the "Deployment Descriptor Arguments" section of the Oracle Application Server Web Services Developer's Guide for more information on this argument.
Example 6-9 illustrates a topDownAssemble Ant task that uses the ddFileName argument to add the auditing and logging configuration in wsmLoggingServiceConfig.xml to the Web service.
Example 6-9 Passing an Auditing and Logging Configuration in a Top Down Web Service Assembly
<oracle:topDownAssemble
wsdl="BankService.wsdl"
input="build/classes/service"
output="build"
className="oracle.ws.server.bank.BankImpl"
ear="dist/bank.ear"
packageName="oracle.ws.server.bank"
ddFileName="BankServiceWsmConfig.xml"/>
The following general steps describe how to assemble an auditing configuration into a J2SE Web service client proxy. Logging is not available for a Web service client.
Provide settings for the auditing features that you want to enable in an XML file.
"Managing Auditing on the Client" describe the operation-level auditing features that can be set for the client.
Use the genProxy command to assemble the Web service proxy. Pass the auditing configuration to the command with the ddFileName argument.
This will result in the generation of an XML file. For the genProxy command illustrated in Example 6-10, this would result in the file oracle\generated\runtime\BankPortBinding_Stub.xml being generated into the test\src directory.
"Configuring Management Information for a J2SE Client" provides more detailed information on adding a management configuration to a J2SE client.
Example 6-10 illustrates a genProxy Ant task that uses the ddFileName argument to add the auditing configuration in wsmClientDD.xml to the Web service.
Example 6-10 Passing an Auditing Configuration in a Web Service Client Assembly
<oracle:genProxy
wsdl="http://localhost:8888/bankdemo/bank?WSDL"
output="test/src"
packageName="oracle.generated"
ddFileName="wsmClientDD.xml"/>
</oracle:genProxy>
Example 6-11 illustrates the contents of the wsmClientDD.xml for a client-side auditing configuration. The auditing configuration is highlighted in bold. Note that the contents of the file are enclosed in the <port-info> tag.
J2EE Web service clients can be configured to perform auditing. Logging is not available for Web service clients. The following general steps describe how you can add an auditing configuration to a J2EE Web service client. In addition to generating the client code, you must also edit both the standard and the Oracle-proprietary Web service deployment descriptor.
Generate the J2EE client code by providing the WSDL and the service endpoint interface as input to the genInterface command. See "How to Assemble a J2EE Web Service Client" in the Oracle Application Server Web Services Developer's Guide for more detailed information on using WebServicesAssembler to assemble J2EE client code.
Edit the deployment descriptor for the J2EE component (either web.xml, ejb-jar.xml, or application-client.xml) to add the code to the <service-ref> element that will allow the component to access the Web service endpoint. For examples of how auditing and other Web service management information can be added to a standard J2EE Web service client deployment descriptor, see the following examples.
Example 3-5, "web.xml—Static Configuration for a Servlet or JSP Web Service Client"
Example 3-7, "ejb-jar.xml—Static Configuration for an EJB Web Service Client"
See "Adding J2EE Web Service Client Information to Deployment Descriptors" in the Oracle Application Server Web Services Developer's Guide for information on the <service-ref> element and its contents.
Edit the Oracle-proprietary deployment descriptor for the J2EE component (either orion-web.xml, orion-ejb-jar.xml, or orion-application-client.xml) to add OC4J platform-specific information and the auditing configuration to the <service-ref-mapping> element.
For examples of how auditing and other Web service management information can be added to a J2EE Web service client, see the following examples.
See "Adding OC4J-Specific Platform Information" in the Oracle Application Server Web Services Developer's Guide for information on the <service-ref-mapping> element and its contents.
Example 6-12 illustrates a sample orion-web.xml file that has been edited to contain an auditing configuration. The configuration appears within the <service-ref-mapping> element, which is used to provide platform-specific information.
Example 6-12 orion-web.xml File Edited to Contain an Auditing Configuration
<?xml version="1.0"?>
<orion-web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-web-10_0.xsd">
<service-ref-mapping name="service/BankTeller">
<port-info>
<wsdl-port namespaceURI="http://oracle.com/bank" localpart="BankPort"/>
<service-endpoint-interface>oracle.ws.client.bank.BankService</service-endpoint-interface>
<runtime enabled="auditing"/>
<operations>
<operation name="deposit">
<runtime>
<auditing request="true" response="true" fault="false"/>
</runtime>
</operation>
</operations>
</port-info>
</service-ref-mapping>
</orion-web-app>
Application Server Control lets you enable and configure different auditing options at deployment and at runtime. Application Server Control lets you perform the following tasks.
Modify at deployment time which Web service operations and messages to audit.
Control at runtime which Web service operations and messages to audit.
Browse the messages contained in the audit logs.
Similarly, you can enable and configure different logging options at deployment and at runtime. Application Server Control lets you perform the following tasks.
Modify at deployment time the type of information to extract and log.
Control at runtime the type of information to extract and log.
Browse the messages contained within the logs.
For more information, see the topics Configuring Auditing for a Web Service and Configuring Logging for a Web Service in the Application Server Control on-line help.
Wizards in JDeveloper let you configure auditing and logging for a Web service in a deployment module. The auditing and logging configuration is stored in the Oracle-proprietary deployment descriptor, oracle-webservices.xml.
When JDeveloper performs the final packaging of a Web service module, it includes the deployment descriptor in the location required by the Web services runtime. When JDeveloper is used as the deployment tool for deploying Web services, you have the option to override any auditing and logging configuration that was set during packaging.
This configuration created by JDeveloper can also be overridden at deployment by Application Server Control. See the JDeveloper on-line help for more information on enabling logging and auditing. For more information on overriding auditing and logging features after deployment, see "Edit Auditing Configuration Page" and "Edit Logging Configuration Page" in the Application Server Control on-line help.
For more information on:
the contents of the oracle-webservices.xml deployment descriptor which contains the Web services management configuration, see Chapter 18, Packaging and Deploying Web Services, in the Oracle Application Server Web Services Developer's Guide.
adding Web service management information, including security, to a Web service, see Chapter 3, "Managing Web Services".
adding security information to a Web service, see Chapter 4, "Ensuring Web Services Security" and the Oracle Application Server Web Services Security Guide.
adding reliability information to a Web service, see Chapter 5, "Ensuring Web Service Reliability".
the contents of the wsmgmt.xml file which contains the security configuration, see Appendix A, "Understanding the Web Services Management Schema".
assembling a Web service top down, see "Assembling a Web Service from a WSDL" in the Oracle Application Server Web Services Developer's Guide.
using Java classes to assemble a Web service, see "Assembling a Web Service with Java Classes" in the Oracle Application Server Web Services Developer's Guide.
using EJBs to assemble a Web service, see "Assembling a Web Service with EJBs" in the Oracle Application Server Web Services Developer's Guide.
using JMS topics and destinations to assemble a Web service, see "Assembling Web Services with JMS Destinations" in the Oracle Application Server Web Services Developer's Guide.
using database resources, such as PL/SQL packages, SQL queries, DML statements, Oracle Streams AQ, or server-side Java classes, to assemble a Web service, see "Assembling Database Web Services" in the Oracle Application Server Web Services Developer's Guide.
assembling a J2EE Web Service client, see "Assembling a J2EE Web Service Client" in the Oracle Application Server Web Services Developer's Guide.
assembling a J2SE Web service client, see "Assembling a J2SE Web Service Client" in the Oracle Application Server Web Services Developer's Guide.
using WebServicesAssembler commands to assemble Web service artifacts, see "Using WebServicesAssembler" in the Oracle Application Server Web Services Developer's Guide.
the contents of the oracle-webservices.xml deployment descriptor which contains the Web services management configuration, see "Packaging and Deploying Web Services" in the Oracle Application Server Web Services Developer's Guide.
