Which style of WSDL should I use? (reship)
Date: 24 May 2005 (Published 31 Oct 2003)
Level: Advanced
Summary: A Web Services Description Language (WSDL) binding style can be RPC or document. The use can be encoded or literal. How do you determine which combination of style and use to use? The author describes the WSDL and SOAP messages for each combination to help you decide.
Introduction
A WSDL document describes a Web service. A WSDL binding describes how the service is bound to a messaging protocol, particularly the SOAP messaging protocol. A WSDL SOAP binding can be either a Remote Procedure Call (RPC) style binding or a document style binding. A SOAP binding can also have an encoded use or a literal use. This gives you four style/use models:
- RPC/encoded
- RPC/literal
- Document/encoded
- Document/literal
Add to this collection a pattern which is commonly called the document/literal wrapped pattern and you have five binding styles to choose from when creating a WSDL file. Which one should you choose?
Before I go any further, let me clear up some confusion that many of us have stumbled over. The terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style should be used for RPC programming models and that the document style should be used for document or messaging programming models. That is not the case at all. The style has nothing to do with a programming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothing more. You can use either style with any programming model.
Likewise, the terms encoded and literal are only meaningful for the WSDL-to-SOAP mapping, though, at least here, the traditional meanings of the words make a bit more sense.
For this discussion, let’s start with the Java method in Listing 1 and apply the JAX-RPC Java-to-WSDL rules to it (see Resources for the JAX-RPC 1.1 specification).
public void myMethod(int x, float y); |
RPC/encoded
Take the method in Listing 1 and run it through your favorite Java-to-WSDL tool, specifying that you want it to generate RPC/encoded WSDL. You should end up with something like the WSDL snippet in Listing 2.
Listing 2. RPC/encoded WSDL for myMethod
<message name="myMethodRequest">
<part name="x" type="xsd:int"/>
<part name="y" type="xsd:float"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's RPC/encoded. -->
|
Now invoke this method with “5″ as the value for parameter x and “5.0″ for parameter y. That sends a SOAP message which looks something like Listing 3.
Listing 3. RPC/encoded SOAP message for myMethod
<soap:envelope>
<soap:body>
<myMethod>
<x xsi:type="xsd:int">5</x>
<y xsi:type="xsd:float">5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
|
There are a number of things to notice about the WSDL and SOAP message for this RPC/encoded example:
Strengths
- The WSDL is about as straightforward as it’s possible for WSDL to be.
- The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.
Weaknesses
- The type encoding info (such as
xsi:type="xsd:int") is usually just overhead which degrades throughput performance. - You cannot easily validate this message since only the
<x ...>5</x>and<y ...>5.0</y>lines contain things defined in a schema; the rest of thesoap:bodycontents comes from WSDL definitions. - Although it is legal WSDL, RPC/encoded is not WS-I compliant.
Is there a way to keep the strengths and remove the weaknesses? Possibly. Let’s look at the RPC/literal style.
Pages: next page
Categorized in: SOA · Tagged with: schema, SOAP, UDDI, Webservice, WSDL, XML
(No Ratings Yet)
Loading ...
(
