HI,
I would like know the difference between Style formats of the WSDL (RPC & DOCUMENT). And its use attributes (LITERAL/ENCODED) ? I've gathered some info, but not yet cleared doubt?
Any one can give correct solution, in which case we can use them?
Thanx
Vasu
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Figure 3: Document vs. RPC. Unlike document style messaging, RPC messaging requires an immediate response from the recipient
Figure 3:
Read this article its the best one which can clearly explain the difference with respect to SOAP along with examples
http://www.ibm.com/develop
Hi Shiva,
I've studied the link already, which u've given. But, i'm confusing about USE attribute " literal/encode".
My understanding is:
If it is literal, then values are going in a plain format.
If it is encoding, then the values are going in the defined format like:
<x xsi:type="xsd:int">5</x>
<y xsi:type="xsd:float">5.0</y>
My understanding is correct or not? Pls correct me???
Thnx
Vasu.
When you say they are encoded that means that those varible have specific XSD type for them like your example shows a int and float, When you say a literal its can only be a single complex element.
See the article
RPC Encoded :
<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>
RP
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
No
<message name="myMethodRequest">
<part name="x" type="xsd:int"/>
<part name="y" type="xsd:float"/>
</message>
<m
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/
<output message="empty"/>
</operation>
</portType>
So the complex element in our case is myMethodRequest which represents the actual input.
Similarly look at Document/literal wrapped in the article you will find same above structure of literal. Hope this helps.
one more good URL to know diff between RPC/Document Web services:
http://www.oracle.com/tech
Vasu
Business Accounts
Answer for Membership
by: Michael_MCDSTPosted on 2009-02-25 at 02:09:57ID: 23731955
Document Exchange vs. RPC models
One of the very first things that must be decided in your architecture is whether you will use RPC-encoded or document-style interactions. Your choice can impact the level of coupling present in your architecture.
An RPC (remote procedure call) is essentially a call to a remote method. Web services are XML-based, but you can still interact with the back-end service in an RPC-like fashion. Typically, the interaction is a very simple request/response, where the client sends a SOAP message that contains a call to a method. The application server receiving this request can then translate this request into the back-end object (e.g., a Java object, EJB method, or C# method). There is very little that developers have to do to build an RPC-based Web service because everything is mapped for them. Note that even in this approach XML is used to contain the call.
With document style, XML "business documents" are transmitted across the wire. They do not map directly to back-end method calls; they are actually complete, self-contained business documents. When the service receives the XML document, it might do some pre-processing on the document, perform some work, and construct the response back. There is usually no direct mapping to a back-end object. In fact, a request might invoke multiple components on the back end. The developer has to do much of the work in processing and mapping the XML data received, and there are very few tools on the market that can do this automatically. The document style is typically used in conjunction with asynchronous protocols to provide reliable, loosely coupled architectures.
A good analogy for illustrating RPC vs. document style is the difference between making a phone call and sending an email message. When making a phone call with no voicemail available, you are expecting some one on the other end to pick up and begin talking to you. This is very much a request-response paradigm and maps well to RPC-style messaging. On the other hand, sending an email doesn't require the sender to be there. The email, or business document, which has all the information it needs, can wait in a queue or mail server until the receiver wants to read it. This is analogous to the document style interaction.
The general recommendation is to use document style messaging in your architectures. While an RPC approach can be implemented rather quickly, it will not be sufficient down the road when you have to interact with suppliers, customers, and partners who are beyond your control. In these situations, you will want an architecture that shields you (and the clients) as much as possible from the back-end implementation. Figure 3 shows the architectural differences between RPC and document style messaging.
Figure 3: Document vs. RPC. Unlike document style messaging, RPC messaging requires an immediate response from the recipient.Document style messaging delivers a number of benefits:
With document style, you can utilize the full capabilities of XML to describe and validate a business document. With the RPC approach, the XML typically just describes the methods and parameters of the method call. It does not require a tight contract between the client and the service provider. RPC is typically static, requiring changes to the client when the method signature changes. With document style, the rules can be less rigid. Because it is self-contained, document style is typically better suited for asynchronous processing.
There is one key disadvantage to document styleit is typically more difficult to implement than an RPC approach. Despite this fact, the flexibility gains well outweigh the implementation costs. And more and more vendors are beginning to provide some support for the document style approach. Document style is also recommended over the RPC approach by organizations such as the WS-I.