axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Cohen <>
Subject Re: rpc-literal and document-literal
Date Tue, 27 Aug 2002 16:39:29 GMT
>From my big bag o' shameless plugs...

Chapter 7 explains the different encoding styles. Chapter 9 shows how .NET
adds its own twist to document-literal.

The chapters are up there for free download. All I ask in return is that you
help me promote the book by telling your friends. And, feedback is welcome


Frank Cohen, CEO, PushToTest,, phone: 408 374 7426
Come to PushToTest for free open-source Active Security solutions that test,
monitor and automate Web Service systems for functionality, scalability and

> From: <>
> Reply-To:
> Date: Tue, 27 Aug 2002 15:20:00 +0200
> To: <>
> Subject: RE: rpc-literal and document-literal
> which one is default in Axis? RPC-soapEncoded?
> How many forms are there? I have gathered from this and the previous thread
> that we have
> rpc-literal
> rpc-soapEncoded
> document-literal
> Is this correct?
> Does anybody know about a document which explains briefly the difference
> between them?
> tahnx/AM
> -----Original Message-----
> From: Ricky Ho []
> Sent: 26. august 2002 05:35
> To:
> Cc: Ted Neward
> Subject: Re: rpc-literal and document-literal
> Eric,
> 1) In "rpc/lit", you are exposing a Java method that only has one or more
> "Element" as input parameters and only one "Element" class as return
> value.  You only need to define the schema of your parameters and return
> value.  But you don't need to define the schema of the whole SOAP body
> because the method name and parameter name will "automatically" be included.
> 2) In "doc/lit", you are exposing a Java method that only has one "Element"
> as input parameter and only one "Element" class as return value.  The
> method name and parameter name will NOT be included, and the single input
> parameter will appear as the direct child of the SOAP body.  Therefore, you
> need to define the schema for the whole SOAP body.
> I agree with you that "rpc/lit" has a better reuse of schema
> definition.  It also has a tighter coupling with the method signature.
> Best regards,
> Ricky
> At 03:06 PM 8/23/2002 -0700, Eric Rajkovic wrote:
>> 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
>> (
>> Eric
>> 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 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?
>>>> 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.)
>>>> 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