axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Hendry <>
Subject Re: rpc-literal and document-literal
Date Mon, 22 Jul 2002 02:08:29 GMT
Ted Neward wrote:

>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 

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 

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.

>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.


>----- Original Message -----
>From: "Sam" <>
>To: "axis" <>
>Sent: Sunday, July 21, 2002 5:16 PM
>Subject: rpc-literal and document-literal
>>I 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 ?

View raw message