Skip Headers
Oracle® Application Server Web Services Developer's Guide
10g Release 2 (10.1.2)
Part No. B14027-01
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

12 Advanced Topics for Web Services

This chapter covers advanced Oracle Application Server Web Services topics, including the following topics:

12.1 Setting the Web Services Debugging Property ws.debug

To obtain Oracle Application Server Web Services debugging information, use the Java property ws.debug, and set its value to true. To set the ws.debug value to true, use Oracle Enterprise Manager 10g to specify OC4J startup options. Debugging output is sent to the OC4J instance log file corresponding to the island where Oracle Application Server Web Services is running.

Example 12-1 provides sample debugging output.

Example 12-1 Web Services Debug Output

WS Debug: initQnameMap('null')WS Debug: operation name is: helloWorld
WS Debug: QueryString is: invoke=helloWorld&param0=test
WS Debug: Operation Name is: helloWorld
WS Debug: Port Type Local name is: StatelessExamplePortType
WS Debug: Port Type Namespace URI is: http://oracle.j2ee.ws_example/StatelessExample.wsdl
WS Debug: Operation Local name is: helloWorld
WS Debug: Operation Namespace URI is: http://oracle.j2ee.ws_example/StatelessExample.wsdl
WS Debug: Operation Get parameter order: null


See Also:

Oracle Application Server Containers for J2EE User's Guide for information on setting debugging options and showing debugging output.

12.2 Untyped Request Handling Options

Oracle Application Server Web Services supports requests for RPC style Web Services in the following cases:

Oracle Application Server Web Services client-side applications and tools do not generate untyped requests, but some external tools or applications may generate such requests. Due to the performance cost for supporting untyped requests, by default such support is not enabled.

To support requests with untyped parameters, use the optional <accept-untyped-request> tag with the WebServicesAssembler. This tag applies as a sub-tag with the <stateful-java-service> and <stateless-java-service> tags when the corresponding <message-style> tag is set to the value RPC. The <accept-untyped-request> tag also applies as a sub-tag for the <stateless-session-ejb-service> tag.

Table 12-1 shows <accept-untyped-request> tag specification.

Example 12-2 Sample Typed RPC Request

 <?xml version='1.0' encoding='UTF-8'?>
 <SOAP-ENV:Envelope xmlns:SOAP-ENV="
    http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <SOAP-ENV:Body>
    <ns1:sayHello xmlns:ns1="urn:Hello"
        SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
       <param0 xsi:type="xsd:string">Scott</param0>
       <param1 xsi:type="xsd:int">27</param1>
    </ns1:sayHello>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Example 12-3 Sample Un-Typed RPC Request

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="
      http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <SOAP-ENV:Body>
     <ns1:sayHello xmlns:ns1="urn:Hello"
       SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
       <param0>Scott</param0>
       <param1>27</param1>
     </ns1:sayHello>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Table 12-1 WebServicesAssembler <accept-untyped-request> Tag

Tag Description
<accept-untyped-request> value</accept-untyped-request> Setting value to true tells WebServicesAssembler to allow the Web Service to accept untyped requests. When the value is false, the Web Service does not accept untyped-request.

Valid values: true, false (case is not significant; TRUE and FALSE are also valid)

Default value: false


12.3 SOAP Header Support

This section covers Oracle Application Server Web Services support for SOAP request headers sent from a Web Services client to an endpoint. This section covers the following topics:

12.3.1 Client Side SOAP Request Header Support

Oracle Application Server Web Services generated client-side proxy code provides methods to use SOAP request headers. A SOAP request message, including the SOAP request headers is transmitted to a service endpoint when Web Services proxy code is invoked.

When Oracle Application Server Web Services generates a proxy, either from WSDL for a Web Services Document or RPC style service, the proxy code provides two SOAP request header support methods:

void _setSOAPRequestHeaders(org.apache.soap.Header headers)
org.apache.soap.Header _getSOAPRequestHeaders()

These methods provide access to an org.apache.soap.Header object. By default the org.apache.soap.Header object's value is set to null which signifies there are no headers in the SOAP request message. When a request header is needed, use the _setSOAPRequestHeaders() method to specify the Header object to be sent with the SOAP request message.


Note:

When proxies are generated for Stored Procedure or JMS Document Style Web Services the _setSOAPRequestHeaders() and _getSOAPRequestHeaders() methods are not supplied.

The SOAP request header information is shared for all proxy operations. After the headers are set using _setSOAPRequestHeaders(), all subsequent operation invocations using the proxy use the same header value. To set a new header value, call _setSOAPRequestHeaders() using a new Header object or with a null value.


Note:

After setting the SOAP request header, the same header object is used for each subsequent operation invocation until the object is reset using _setSOAPRequestHeaders().

To create and manipulate SOAP request headers you need to populate the header object. The org.apache.soap.Header object provides a method for specifying the contents of one or more SOAP header blocks. It is defined as:

public void setHeaderEntries(java.util.Vector headerEntries)

The vector is populated with org.w3c.dom.Element objects which specify individual SOAP header blocks.

When a header entry includes the mustUnderstand attribute set to the value 1, the recipient must process the header entry. If the recipient cannot process the header entry, then a SOAP fault is returned with the value FAULT_CODE_MUST_UNDERSTAND.


See Also:

Section 4.2, "SOAP Header", in for information on header entries in SOAP 1.1 http://www.w3.org/TR/SOAP/.

12.3.1.1 Setting SOAP Headers in a Client-Side Proxy

This section shows a sample that uses the proxy class EmployeeProxy. The complete sample containing this code is available in the directory $ORACLE_HOME/web_services/demo/header_demo/client. In the sample, a single header block is added to the Header object. The Header object is then supplied as an argument to the proxy's _setSOAPRequestHeaders() method.

Example 12-4 Segment of Client Using Message with SOAP Request Header

.
.
.
// Create an intance of the proxy
EmployeeProxy proxy = new EmployeeProxy();
// Create a Header objecy
Vector v = new Vector();
v.add (e);
Header hdr = new Header();
hdr.setHeaderEntries(v);

// Set the Header
proxy._setSOAPRequestHeaders(hdr);
// Invoke the request
System.out.println("Salary of MILLER is: " + proxy.getEmployeeSalary("MILLER"));


12.3.2 Server Side SOAP Request Header Support

To process a SOAP request header on the server side, a Web Service needs to implement the oracle.j2ee.ws.HeaderCallback interface that is part of the Oracle Application Server Web Services supplied wsserver.jar. This interface includes one method that takes a single org.apache.soap.Header argument.

The Oracle Application Server Web Services infrastructure calls the processHeaders() method before every associated service method.

When an incoming SOAP request header includes one or more header entries with the mustUnderstand attribute set to either 1, true, or TRUE values, then the Web Service implementation must implement the oracle.j2ee.ws.HeaderCallback interface. If this interface is not implemented, Oracle Application Server Web Services throws a SOAP fault with the fault code set to FAULT_CODE_MUST_UNDERSTAND.

If a Web Service implementation implements the HeaderCallback interface, the implementation can throw a SOAP exception with the fault code set to FAULT_CODE_MUST_UNDERSTAND if the service does not know how to process a header entry with the mustUnderstand attribute set to 1, true, or TRUE. Oracle Application Server Web Services then translates the exception and Oracle Application Server Web Services throws a SOAP fault with the fault code set to FAULT_CODE_MUST_UNDERSTAND.

This section shows server-side Web Services code that provides the implementation for the Employee service. The complete sample containing this Web Service is available in the directory $ORACLE_HOME/web_services/demo/basic/header_demo/client (after unzipping $ORACLE_HOME/webservices/demo/demo.zip).

Example 12-5 shows an interface that extends HeaderCallback.

Example 12-6 shows a section of the service implementation for the sample getEmployeeSalery interface, including the processHeaders() method that can handle incoming SOAP request headers of the form:

<SOAP-ENV:Header>  <credentials>    <username>scott</username>    <password>tiger</password>   <datasource>jdbc/OracleCoreDS</datasource>  </credentials></SOAP-ENV:Header>

Example 12-5 Employee Interface Extending HeaderCallback

import oracle.j2ee.ws.HeaderCallback;
/**
 *  Employee java class being exposed as Web Services
 *  This service also extends HeaderCallback so as to
 *  access Headers.
 */
public interface Employee
  extends  HeaderCallback
{
  // Get the salary for a given Employee
  int getEmployeeSalary(String  ename);
}

Example 12-6 Including A HeaderCallback processHeaders() Implementation

  public void processHeaders(Header header)
     throws java.io.IOException,
            oracle.xml.parser.v2.XSLException
  {
    // Get all the Elements
    Vector entries = header.getHeaderEntries();
    Element e = (Element) entries.firstElement();
    System.out.println("Element received is: " );
    ((XMLElement)e).print(System.out);

    // Get independent nodes and retrieve node values.
    Node userNode;
    userNode = ((XMLNode)e).selectSingleNode("username");
    userName = ((XMLElement)userNode).getText();

    Node passwordNode;
    passwordNode = ((XMLNode)e).selectSingleNode("password");
    password = ((XMLElement)passwordNode).getText();

    Node dsNode;
    dsNode = ((XMLNode)e).selectSingleNode("datasource");
    datasourceName = ((XMLElement)dsNode).getText();

    System.out.println("User name is: " + userName);
    System.out.println("Password is: " + password);
    System.out.println("Datasource is: " + datasourceName);
  }

12.3.3 Limitations for SOAP Header Support

The following list contains limitations related to SOAP header support:

  1. Oracle Application Server Web Services does not provide support for processing or translating header information that is specified in a WSDL definition.

  2. Oracle Application Server Web Services does not provide validation, XML or otherwise, for SOAP request header information provided in the org.apache.soap.Header object. The user is responsible for populating this object with well-formed XML.

  3. Oracle Application Server Web Services does not provide support for SOAP response headers.

  4. When proxies are generated for JMS Document Style Web Services, the SOAP request header _setSOAPRequestHeaders() and _getSOAPRequestHeaders() methods are not supplied. Using JMS Web Services there are no server-side facilities for processing SOAP request headers.

  5. When proxies are generated for Stored Procedure Web Services, the SOAP request header _setSOAPRequestHeaders() and _getSOAPRequestHeaders() methods are not supplied. Using Stored Procedure Web Services there are no server-side facilities for processing SOAP request headers.