009c01c23117$d45256d0$[EMAIL PROTECTED]">It's really more of a "Zen" thing--rpc/encoded is the act of replicating a
call stack, whereas doc/literal is the act of passing messages, much in the
same differentiation between RMI and JMS. In many ways, one can look at RMI
and simply say, "Oh, that's easy, that's just passing an 'input' message to
an endpoint, and receiving an 'output' message back." This in turn begs the
question, what's the choice between RMI and JMS? Or, in short, what's the
choice about between any messaging-based application, and an RPC-based one?
I don't think there is a current definitive answer to when to use what, but here are my opinions.
The main encodings are rpc/encoded and doc/literal (with wrapped doc/lit now on the scene). The difference between these is in how the content is defined and the ability to validate the messages. With rpc/encoded the message follows the section 5 encoding rules which, although they have a schema associated with them, have some flexibility which goes beyond the schema definition. Also, the body element (the method definition) does not appear in the schema and so cannot be validated without a toolkit going to some lengths to implement soap-enc validation (but even then there is flexibility in the soap-enc spec which means the message is not fixed).
The idea with literal is that a message can be directly validated against the a schema by an XML parser. However, literal can make it more difficult for the soap node to match the method being called (as well as a human looking at the message), and the message might not look like the data model that is built from it (soapenc is designed to directly map to the most common programming language data constructs).
The 2 encodings which tend not to be used (rpc/literal and doc/encoded) do not really add any value to the other encodings. document style combined with literal allows validation, but changing that to rpc/literal takes away validation because the rpc surrounding element which does not appear in the schema (although it does make dispatching easier and make the messages intention easier to read). document/encoded takes away the benefits of rpc/encoded (easier dispatching based on root body element and easier to read intention) but does not add anything in return.
The "new boy on the block" which is not a style per-se is wrapped doc/lit (or wrapped-literal). In this case, the drawbacks of document literal are addressed (harder to dispatch and harder to read intention) by wrapping the arguments in a top-level body element. This makes the message look very much like an rpc/encoded message but still allows validation to take place as the top-level elements appear in the schema (not the case with rpc). This seems to be becoming popular as it has the best of both worlds (and it is the default .NET encoding I believe).
Use cases include: whether you want to validate the message content precisely (literal); whether the application is working on a data graph (encoded) or the XML message directly from the body (literal). Your toolkit may recommend the use of wrapped-literal to allow it to dispatch more easily (although I believe at least one toolkit does not use wrapped for this purpose by having all the wrapping elements all have the same name).
Note that the soapenc data model is optional in SOAP1.2 so a toolkit need not implement it to be compliant with the soap spec. This may mean toolkits moving towards literal as their default with soapenc as an option.
009c01c23117$d45256d0$[EMAIL PROTECTED]">
A messaging-based app usually offers more in the way of flexibility--for
example, a messaging-based app can do all sorts of "oneway" actions without
requiring a response, and can offer store-and-forward kinds of functionality
as a result. (Think of the difference between email--messaging--and a phone
call--RPC. One requires only some supporting plumbing to make sure the
message gets there; the other requires the same plumbing, but also that the
recipient be there, ready to answer the incoming request and send back a
response.) The commensurate cost that goes with a messaging application is
the overhead of tying "request" and "response" together--identifying that
*this* response goes with *that* request five minutes ago, and so on. (JMS
has some headers they reserve for precisely this purpose.)
This is at a higher layer than the wire encoding. Although what you say is true, I don't think it relates to the question.
009c01c23117$d45256d0$[EMAIL PROTECTED]">Pete
009c01c23117$d45256d0$[EMAIL PROTECTED]">
----- Original Message -----
From: "Sam" <[EMAIL PROTECTED]>
To: "axis" <[EMAIL PROTECTED]>
Sent: Sunday, July 21, 2002 5:16 PM
Subject: rpc-literal and document-literalI was trying to think of the use cases where one would prefer
to use document-literal over rpc encoded and drew a blank.
Can anyone highlight why an application would choose
document-literal or rpc-literal as the message format ?
What would such a use case look like ?
Thanks
/s
