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
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.
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.
See basically there is difference in WSDL and SOAP messages. Now we know there are different parts in WSDL file , the specific pasts having difference are
- <message>: and
- <binding>:
here is how
A message part may declare either a type attribute or an element attribute, but not both. Which to use depends on the kind of messaging you're doing. If you're using RPC-style messaging, the part elements must use the type attribute; if you're using document-style messaging, the part elements must use the element attribute
RPC Style
<definitions name="BookPrice" ...>
...
<message name="GetBulkBookPriceRequest">
<part name="isbn" type="xsd:string"/>
<part name="quantity" type="xsd:int"/>
</message>
<message name="GetBulkBookPriceResponse">
<part name="price" type="mh:prices" />
</message>
...
</definitions>
Document Style
<message name="SubmitPurchaseOrderMessage">
<part name="order" element="mh:purchaseOrder" />
</message>
The soapbind:binding and soapbind:body elements are responsible for expressing the SOAP-specific details of the Web service.
• soapbind:binding tells us that the "messaging style" is RPC (or document) and that the "network application" protocol is HTTP.
• The soapbind:body element tells us that both the input and output messages use literal encoding.
You may have noticed that attributes of the soapbind:body element change depending on whether you use RPC- or document-style messaging. The soapbind:body element has four kinds of attributes:
1. use :- required to be literal ( ?? can it be document?? ) if absent default=literal
2. namespace :- In "rpc"-style messages, the namespace attribute must be specified with a valid URI. In document style it must not be specified.
3. part :- specifies which part elements in the message definition are being used. necessary only if you are using a subset of the part elements declared by a message
4. and encodingStyle : - never used
RPC Style
<definitions name="BookPrice" ...>
...
<message name="GetBulkBookPriceRequest">
<part name="isbn" type="xsd:string"/>
<part name="quantity" type="xsd:int"/>
</message>
<message name="GetBulkBookPriceResponse">
<part name="price" type="mh:prices" />
</message>
...
</definitions>
Document Style
<message name="SubmitPurchaseOrderMessage">
<part name="order" element="mh:purchaseOrder" />
</message>
The soapbind:binding and soapbind:body elements are responsible for expressing the SOAP-specific details of the Web service.
• soapbind:binding tells us that the "messaging style" is RPC (or document) and that the "network application" protocol is HTTP.
• The soapbind:body element tells us that both the input and output messages use literal encoding.
You may have noticed that attributes of the soapbind:body element change depending on whether you use RPC- or document-style messaging. The soapbind:body element has four kinds of attributes:
1. use :- required to be literal ( ?? can it be document?? ) if absent default=literal
2. namespace :- In "rpc"-style messages, the namespace attribute must be specified with a valid URI. In document style it must not be specified.
3. part :- specifies which part elements in the message definition are being used. necessary only if you are using a subset of the part elements declared by a message
4. and encodingStyle : - never used
RPC style specify the namespace attribute in the soapbind:body. In contrast, document-style messages must not specify the namespace attribute in the soapbind:body element. The namespace of the XML document fragment is derived from its XML schema
Example of a rpc style
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="BookQuoteWS"
targetNamespace="http://www.Monson-Haefel.com/jwsbook/BookQuote"
xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/">
...
<!-- binding tells us which protocols and encoding styles are used -->
<binding name="BookPrice_Binding" type="mh:BookQuote">
<soapbind:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getBookPrice">
<soapbind:operation style="rpc"
soapAction=
"http://www.Monson-Haefel.com/jwsbook/BookQuote/GetBookPrice"/>
<input>
<soapbind:body use="literal"
namespace="http://www.Monson-Haefel.com/jwsbook/BookQuote" />
</input>
<output>
<soapbind:body use="literal"
namespace="http://www.Monson-Haefel.com/jwsbook/BookQuote" />
</output>
</operation>
</binding>
...
</definitions>
In contrast, document-style messages must not specify the namespace
attribute in the soapbind:body element. The namespace of the XML document
fragment is derived from its XML schema
<!-- binding tells us which protocols and encoding styles are used -->
<binding name="SubmitPurchaseOrder_Binding" type="mh:SubmitPurchaseOrder">
<soapbind:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="submit">
<soapbind:operation style="document"/>
<input>
<soapbind:body use="literal" />
</input>
<output>
<soapbind:body use="literal" />
</output>
</operation>
</binding>
As an example lets consider one java method in all four ways
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 below.
<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>
- 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.
Weakness
·
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 5 and 5.0 lines contain things defined in a schema; the rest of
the soap:body contents comes from WSDL definitions.
·
Although it is legal WSDL, RPC/encoded is not
WS-I compliant.
RPC Literal
The RPC/literal WSDL for this method looks almost
the same as the RPC/encoded WSDL (see Listing 4). The use in the binding is changed
from encoded to literal. That's it.
<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/literal. -->
Strengths
·
The WSDL is still about as straightforward as it
is possible for WSDL to be.
·
The operation name still appears in the message.
·
The type encoding info is eliminated.
·
RPC/literal is WS-I compliant.
·
You still 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
the soap:body contents comes from WSDL definitions.
Document Encoded
Nobody follows this style , it's not WSI compliant
Document Literal
The WSDL for document/literal changes somewhat from the WSDL for
RPC/literal. The differences are highlighted in bold - There is no type encoding info.
- You can finally validate this message with any XML
validator. Everything within the soap:body is defined in a
schema.
- Document/literal is WS-I compliant, but with
restrictions (seeweaknesses).
- The WSDL is getting a bit more complicated. This is a
very minor weakness, however, since WSDL is not meant to be read by
humans.
- The operation name in the SOAP message is lost. Without
the name, dispatching can be difficult, and sometimes impossible.
- WS-I only allows one child of the soap:body in
a SOAP message. As you can see in Listing 7, this
example's soap:body has two children.
No comments:
Post a Comment