A WSDL describes a web service. A WSDL binding describes how the service is bound to a messaging protocol. SOAP is a prominent binding used in WSDLs. WSDL 1.1 distinguishes between two message styles: document and RPC.
* Document: contains one or more child elements called parts. There are no SOAP formatting rules for what the contains; the content is to be interpreted by endpoints as they have agreed prior to the communication.
* RPC: RPC implies that contains an element with the name of the method or remote procedure being invoked. This element in turn contains an element for each parameter of that procedure.
There are two serialisation formats of the SOAP message as well.
* Encoded: If the format is encoded the SOAP message is encoded with SOAP encoding. This was predominantly used with RPC style since it uses the names of the method and its parameters to generate structures that represent a method’s call stack. These structures can then be serialized into the SOAP message according to a set of encoding rules defined by the SOAP encoding.
* Literal: Message payload is plain XML data adhering to WSDL/XML Schema rules, requiring no additional encoding/decoding.
The combination of these styles and serialisation formats (uses) give rise to four style/use scenarios.
1. RPC/encoded
2. RPC/literal
3. Document/encoded
4. Document/literal
Additionally there is a defacto model in uasge named document/literal wrapped as well. There is potential for confusion over the wordings here. The definition of styles may be suggestive of the fact that, RPC style is used in RPC programming models and document style should be used for document or messaging programming models. This may not be the case at all. You can use RPC style with document model vice versa. Latter sections of this post describe how this can be done. The style merely says how the WSDL messages should be bound to the SOAP message.
RPC/encoded
WSDL Message
<message name="details">
<part name="name" type="xsd:string">
<part name="id" type="xsd:int">
</message>
<message name="balance">
<part name="balance" type="xsd:int">
</message>
<portType name="myPT">
<operation name="getBalance">
<input message="details">
<output message="balance">
</operation>
</portType>
SOAP Message
<soap:envelope>
<soap:body>
<getBalance>
<name xsi:type="xsd:string">hill</x>
<id xsi:type="xsd:float">1284</y>
</getBalance>
</soap:body>
</soap:envelope>
Important Notes
* WSDL message consist of one or more type declarations. They can be simple or complex types.
* SOAP body’s root element is the operation name. This is helpful for dispatcher mechanisms.
* Type information are present in the as they are present in SOAP encoding specification. This information most of the times an overhead but can become useful when the types have to be determined polymorphically.
* Not WS-I complaint. So not much used now.
RPC/literal
WSDL Message
Same as RPC/encoded style.
SOAP Message
<soap:envelope>
<soap:body>
<getBalance>
<name>hill</x>
<id>1284</y>
</getBalance>
</soap:body>
</soap:envelope>
Important Notes
* Type encoding is not present in the SOAP body.
* RPC/literal is WS-I complaint.
* As RPC/encoded this style also has the disadvantage that the SOAP body cannot be validated entirely on a schema since the root element (operation name) assumes a knowledge about the WSDL although elements under the root are derived from a schema.
Document/encoded
WSDL Message
<types>
<schema>
<element name="nameELement" type="xsd:string"/>
<element name="idElement" type="xsd:int"/>
<element name="balanceElement" type="xsd:int">
</schema>
</types>
<message name="details">
<part name="name" element="nameElement">
<part name="id" element="idElement">
</message>
<message name="balance">
<part name="balance" element="balanceElement">
</message>
<portType name="myPT">
<operation name="getBalance">
<input message="details">
<output message="balance">
</operation>
</portType>
SOAP Message
<soap:envelope>
<soap:body>
<nameElement xsi:type="xsd:string">hill</nameElement>
<idElement xsi:type="xsd:int">1284</idElement>
</soap:body>
</soap:envelope>
Important Notes
* Not WS-I complaint. Not used at all.
Document/literal
WSDL Message
Same as Document/encoded.
SOAP Message
<soap:envelope>
<soap:body>
<nameElement>hill</nameElement>
<idElement>1284</idElement>
</soap:body>
</soap:envelope>
Important Notes
* No type coding information present.
* XML validation of SOAP body can be done.
* Operation name is lost making it harder for dispatchers.
* This specific WSDL is not WS-I compliant since SOAP body can only contain one child as per WS-I. This specific SOAP message contains two children. Had the message contained one part this would become WS-I complaint.
Document/literal wrapped
WSDL Message
<types>
<schema>
<element name="getBalance">
<complexType>
<sequence>
<element name="nameElement" type="xsd:string"/>
<element name="idElement" type="xsd:int"/>
</sequence>
</complexType>
</element>
<element name="balanceElement" type="xsd:int">
</schema>
</types>
<message name="details">
<part name="name" element="getBalance">
</message>
<message name="balance">
<part name="balance" element="balanceElement">
</message>
<portType name="myPT">
<operation name="getBalance">
<input message="details">
<output message="balance">
</operation>
</portType>
SOAP Message
<soap:envelope>
<soap:body>
<getBalance>
<nameElement>hill</nameElement>
<idElement>1284</idElement>
</getBalance>
</soap:body>
</soap:envelope>
Important Notes
* The SOAP body looks more less the same as the RPC/literal SOAP body format. The idea here is to insert the operation name lost in other Document styles using a single message part name similarly to the operation name. While this make the SOAP conformant with WS-I basic profile rule that a message can only contain one element part, it also solves the issue of missing operation data making it easier to dispatch for SOAP nodes. This is not a standard rule per se, but more or less a norm to get the best of both RPC and Document styles.
* This usage also reflects the fact that the style employed does not necessarily convey the type of programming model used. Here the Document style is used in a similar setup like RPC since at the end of the day SOAP body conveys exactly the same information that RPC style does. (operation parameters wrapped inside the operation name element) In this setup it is up to the nodes to identify the fact that root element name is similar to that of the operation name and use this information appropriately when SOAP generation and dispatching whereas in RPC style this is implicitly implied. But however looking at the SOAP body it is not possible to conclude the style employed since nodes communicating with Document style messages can agree upon to format SOAP messages that of similar to RPC style which is the case with Document/literal wrapped style.
BPEL Data Manipulation
How does this knowledge about WSDL binding styles has any bearing on data manipulation within a BPEL process? In a BPEL process every piece of data is represented using XML. XPath is typically used in traversing XML data. Since BPEL process itself is exposed as a web service it’s WSDL binding style determines how the XML data coming in to and from the process is to be formatted. This make it necessary to have a knowledge about the binding styles since required XPath queries change according to the binding styles. Since WS-I basic profile only allows RPC/literal and Document/literal styles only data manipulation scenarios with respect to those two styles will be discussed.
One of the key constructs used in BPEL data manipulation is assign.A copy element within the assign activity specifies the source and target of the assignment (what to copy from and to), which must be of compatible types. The formal syntax as shown in the Business Process Execution Language for Web Services Specification is as follows:
standard-elements
+
from-spec
to-spec
Both from-spec and to-spec can contain variable, part and query attributes corresponding to variable name, wsdl part and query within the part as follows.
The discussion below will focus how the corresponding queries should be built according to the given WSDL styles.
RPC style
WSDL Message
<types>
<schema>
<complexType name="DetailType">
<sequence>
<element name="name" type="xsd:string"/>
<element name="id" type="xsd:int"/>
</sequence>
</complexType>
</schema>
</types>
<message name="details">
<part name="detail" type="DetailType">
</message>
RPC style BPEL File
<variable name="input"
messageType="tns:details"/>
...
<assign>
<copy>
<from>hill</from>
<to variable="input" part="detail" query="/detail/name"/>
</copy>
</assign>
Document Style
WSDL Message
<types>
<schema>
<element name="DetailElement">
<complexType>
<sequence>
<element name="name" type="xsd:string"/>
<element name="id" type="xsd:int"/>
</sequence>
</complexType>
</element>
</schema>
</types>
<message name="details">
<part name="detail" element="DetailElement">
</message>
Document Style BPEL file
<variable name="input"
messageType="tns:details"/>
...
<assign>
<copy>
<from>hill</from>
<to variable="input" part="detail" query="/DetailElement/name"/>
</copy>
</assign>
* For an RPC-style message, the top-level element (and therefore the first node in an XPath query string) is the part name (deail in this example). In document-style, the top-level node is the element name (for example, DetailElement)
Source Open 