axis-java-user mailing list archives

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

http://www.pushtotest.com/ptt/thebook.html

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

-Frank

-- 
Frank Cohen, CEO, PushToTest, www.pushtotest.com, 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
performance.


> From: <annemarie.hartvigsen@telenor.com>
> Reply-To: axis-user@xml.apache.org
> Date: Tue, 27 Aug 2002 15:20:00 +0200
> To: <axis-user@xml.apache.org>
> 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 [mailto:riho@cisco.com]
> Sent: 26. august 2002 05:35
> To: axis-user@xml.apache.org
> 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
>> (http://otn.oracle.com/ws/deptemp?WSDL).
>> 
>> 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
>>>> (http://www.develop.com)
>>>> http://www.javageeks.com/tneward
>>>> http://www.clrgeeks.com/tneward
>>>> 
>>>> ----- Original Message -----
>>>> From: "Sam" <bytecode@Phreaker.net>
>>>> To: "axis" <axis-user@xml.apache.org>
>>>> 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
>>>>> 
>>>>> 
> 


Mime
View raw message