Which style of WSDL should I use?

 http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/#listing1

 

 

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.

 

1. RPC/encoded:

method name is there; traditional data (such as arrays)

1. RPC/literal: method is there; xml data
2. Document/encoded
3. Document/literal: has schema; developer handles everything, including determining the transport (e.g., HTTP, MQ, SMTP), marshaling and unmarshaling the body of the SOAP envelope, and parsing the XML in the request and response to find the needed data.

 

RPC or Doc

The significant difference is that the former can't

be validated with a schema while the latter can. Therefore, document style

web service is becoming the dominant style.

 

Encoding

  

What does literal means? If you don't use literal, you may set it to "encoded".

Then Axis will perform some extra encoding of the data in order to convert it

into XML. For example, it will be able to handle multi-dimension arrays and

data structures containing loops (e.g., a circular linked-list). These kind of data

structures don't have direct counter-parts in XML. In fact, if you start from a

WSDL, you will never get these data types from WSDL2Java. So, "encoded"

is useful only when you have some legacy code that uses such data structures

and you'd like to expose it as a web service.

The resulting XML is XML but can't be validated by any schema. This is

prohibited in document style services. Therefore, in order to use "encoded",

you must use the RPC style.

To use RPC+encoded, after changing the WSDL, just generate the stubs

again, deploy it again and it will work. You won't notice any difference unless

you look at the messages or encounter interoperability problems (remember,

RPC style is not good for interoperability).

 

 

 

 

 

Before I discuss SOAP encoding style's impact on performance, you should understand the differences between the three styles. SOAP RPC is the encoding style that offers you the most simplicity. You make a call to a remote object, passing along any necessary parameters. The SOAP stack serializes the parameters into XML, moves the data to the destination using transports such as HTTP and SMTP, receives the response, deserializes the response back into objects, and returns the results to the calling method. Whew! SOAP RPC handles all the encoding and decoding, even for very complex data types, and binds to the remote object automatically.

 

Now, imagine that you have some data already in XML format. SOAP RPC also allows literal encoding of the XML data as a single field that is serialized and sent to the Web service host. This is what's referred to as RPC-literal encoding. Since there is only one parameter -- the XML tree -- the SOAP stack only needs to serialize one value. The SOAP stack still deals with the transport issues to get the request to the remote object. The stack binds the request to the remote object and handles the response.

Lastly, in a SOAP document-style call, the SOAP stack sends an entire XML document to a server without even requiring a return value. The message can contain any sort of XML data that is appropriate to the remote service. In SOAP document-style encoding, the developer handles everything, including determining the transport (e.g., HTTP, MQ, SMTP), marshaling and unmarshaling the body of the SOAP envelope, and parsing the XML in the request and response to find the needed data.