WEB SERVICES MESSAGES FOR BPEL, JBI, AND JAX-RPC

It is interesting how applications differ when modeling WSDL messages.

WS-BPEL 2.0:

For instance, BPEL 2.0 represents a WSDL (1.1) message by conceptually materializing each WSDL message part into a separate Xml document. In this case, the document element corresponds to either a synthesized element whose type is equal to the part's type attribute, or the document element is the element referenced by the part's element attribute itself (in summary).

For example, consider the following WSDL definition:

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
    targetNamespace="urn:sample" 
    xmlns:tns="urn:sample"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" >

    <types>
        <xsd:schema targetNamespace="urn:sample">
            <xsd:element name="value" type="xsd:string" />
        </xsd:schema>
    </types>

    <message name="sampleMessage">
        <part name="part1" type="xsd:string" />
        <part name="part2" element="tns:value" />
    </message>
</definitions>

Note that we are not worried about a particular binding in the context of this scenario. For example, a SOAP literal binding would only allow messages to have one part if it uses the type attribute.

One example of a message instance for this definition is the following set of two document instances:

<ns2:message xmlns:ns2="http://com.bea.sample.bpelmessage">first value!</ns2:message>

and

<ns1:value xmlns:ns1="urn:sample">second value!</ns1:value>

JBI:

As for JBI, WSDL (1.1) messages are materialized into a single Xml document whose document element ‘wraps’ each message part as a child element.

So, for the previous WSDL definition, one example of a message instance is:

<jbi:message version="1.0" type="ns1:sampleMessage"
    xmlns:ns1="urn:sample" xmlns:jbi="...">
    <jbi:part>first value!</jbi:part>
    <jbi:part>
        <ns1:value>second value!</ns1:value>
    </jbi:part>
</jbi:message>

JAXRPC 2.0:

JAXRPC approach is slightly different, as JAXRPC binds the WSDL message to Java instead of representing it in a Xml document. Still, it’s approach is somewhat similar to that of BPEL, as it binds each WSDL message part into a separate Java method argument.

In this case, lets consider a slightly modification of the previous WSDL definition, which is more appropriate for RPC:

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
    targetNamespace="urn:sample" 
    xmlns:tns="urn:sample"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" >
    <types>
        <xsd:schema targetNamespace="urn:sample">
            <xsd:element name="value1" type="xsd:string" />
            <xsd:element name="value2" type="xsd:string" />
        </xsd:schema>
    </types>

    <message name="sampleMessage">
        <part name="part1" element="tns:value1" />
        <part name="part2" element="tns:value2" />
    </message>

    <portType name="samplePT">
        <operation name="sampleOper">
            <input message="tns:sampleMessage" />
        </operation>
    </portType>
</definitions>

The corresponding Java binding would be:

void sampleOper(java.lang.String part1, java.lang.String part2)
    throws RemoteException

WSDL 2.0:

Finally, WSDL 2.0 solves this problem by getting rid of the WSDL message part concept and hence specifying WSDL messages using W3C Schema element, which already has a obvious mapping when materialized into a document instance.

Conclusion:

The result of these differences is that one would have to transform/adapt the same WSDL (1.1) message when routing it within a JBI implementation through a BPEL service engine, JAXRPC applications, etc.

Advertisement