axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: rpc-literal and document-literal
Date Fri, 23 Aug 2002 22:28:32 GMT

I'm a little late to this rpc/lit vs. doc/lit conversation, but I'm trying
to understand it.  Could someone clear up a few things for me.  First of
all is messaging the same thing as doc/lit?  Second, what impact does
rpc/lit and doc/lit have on the formation of a SOAP message.  Eric
mentioned wrapper elements, but I'm not sure to what he is referring.  Also
could someone clarify "routing information is part of the data" and
"operation name is embeded for be by the framework"


                    Eric Rajkovic                                                        
                    <eric.rajkovic@o       To:           
          >             cc:     Ted Neward <>
                                           Subject:     Re: rpc-literal and document-literal
                    08/23/2002 04:06                                                     
                    Please respond                                                       
                    to axis-user                                                         

One way I like to think about rpc/lit vs. doc/lit is in the design of the
schema that will be used.

With document/literal the routing information is part of the data.
With rpc/literal the operation name is embeded for me by the framework. I
do not have to craft a separate schema
for each operation I have to expose.

On the wire, we can argue that both are identical and we do not need
rpc/literal as the tools can generate
the wrapper elements.

A concrete example where I'll expose a service as rpc/lit instead of
doc/lit is a case where I have to expose
multiple operations that use the same schema (the classic getEmployee /
getManager or select/update/insert
using Oracle XML SQL Utility -XSU).

You can find a live example of rpc/lit endpoint on OTN (


Sam wrote:

> That sounds like the rpc v/s messaging discussion.
> I was taling more specifically about the encoding issue, unless youre
> saying that doc-literal is same as messaging. Which i think is not
> the case
> /s
> 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
> > same differentiation between RMI and JMS. In many ways, one can look at
> > 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
> > question, what's the choice between RMI and JMS? Or, in short, what's
> > choice about between any messaging-based application, and an RPC-based
> >
> > A messaging-based app usually offers more in the way of
> > example, a messaging-based app can do all sorts of "oneway" actions
> > requiring a response, and can offer store-and-forward kinds of
> > as a result. (Think of the difference between email--messaging--and a
> > call--RPC. One requires only some supporting plumbing to make sure the
> > message gets there; the other requires the same plumbing, but also that
> > recipient be there, ready to answer the incoming request and send back
> > response.) The commensurate cost that goes with a messaging application
> > the overhead of tying "request" and "response" together--identifying
> > *this* response goes with *that* request five minutes ago, and so on.
> > has some headers they reserve for precisely this purpose.)
> >
> > Ted Neward
> > {.NET || Java} Course Author & Instructor, DevelopMentor
> > (
> >
> >
> >
> > ----- 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 ?
> > >
> > >
> > > Thanks
> > > /s
> > >
> > >

View raw message