axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Thomas Manes <a...@manes.net>
Subject Re: Document (Vs) RPC style services
Date Wed, 31 Mar 2004 02:28:50 GMT
Vivek,

One thing you need to understand is that, in SOAP, the programming style is 
abstracted from the message structure style. There are two types of 
programming styles: RPC and messaging. In the RPC style (JAX-RPC), you let 
the SOAP runtime environment convert the SOAP message to Java objects. In 
the messaging style (JAXM), the SOAP runtime delivers the message to the 
application as raw XML. (Axis doesn't implement JAXM, but it provides a 
comparable messaging API.)

There are also two types of message structure styles: RPC/encoded and 
Document/literal. RPC/encoded constructs the message according to the SOAP 
encoding data model. Document/literal constructs the message according to a 
supplied schema definition. There's also something called  RPC/literal, 
which is a subset of Document/literal.

The SOAP Encoding model is not completely specified, and as a result, it 
causes a lot of interoperability issues. The WS-I Basic Profile prohibits 
using RPC/encoded. I also recommend that folks not use RPC/Literal, either, 
because .NET doesn't support it (and neither does Axis). So in other words, 
you should only use Document/Literal.

 From the application's point of view, you can use an RPC-style programming 
interface (JAX-RPC) and generate either an RPC or Document style message. 
Likewise, you can use a messaging style interface (JAXM) and generate 
either an RPC or Document style message.

James McCarthy's article is actually talking about using a messaging 
interface rather than an RPC interface. You'll notice that the article is 
pretty old -- June 2002 -- which predates JAX-RPC or JAXM.

Anne

At 04:38 PM 3/30/2004, you wrote:

>Hello Jim,
>
>Thanks for explaining some of the issues which were totally esoteric to me.
>Off late, I have been into lot of tutorials and low-level details which 
>forced me to develop this notion. Can you please clarify me on the 
>following issue.
>
>http://www-106.ibm.com/developerworks/webservices/library/ws-docstyle.html
>
>In this article, James Mc.Carthy discusses the benefits of doc style web 
>services. Following is the  excerpt from the article.
>-----------------------------------------------------------------------------------
>Use document style to minimize in-memory processing
>One final consideration when choosing between document and RPC messaging 
>is the amount of information that may need to be handled. Since most if 
>not all of the implementations that marshal parameters in RPC messaging 
>perform this operation in-memory, memory constraints may make RPC 
>messaging unfeasible. Many document-messaging services are able to choose 
>between DOM and SAX handling of the document and as a result are able to 
>minimize in-memory processing. This is particularly critical for a Web 
>service that may be required to handle thousands of requests, many 
>simultaneously.
>-----------------------------------------------------------------------------------
>
>Do you think that memory processing would be an overhead for RPC styled 
>web service due to    (un)marshalling of parameters?
>
>Thanks a ton,
>Vivek
>
>
>>From: Jim Murphy <jmurphy@mindreef.com>
>>Reply-To: axis-user@ws.apache.org
>>To: axis-user@ws.apache.org
>>Subject: Re: Document (Vs) RPC style services
>>Date: Tue, 30 Mar 2004 14:44:30 -0500
>>
>>Vivek Nagulapati wrote:
>>
>> > MS web services are document-styled web services. But you still 
>> have > >the overhead of (de)serializing your XML request to parameters.
>> > When you have a service which takes 5 parameters as input, you 
>> would >have to deal with the (de)serializing/mapping of the XML to 5 
>> different >parameters. Instead if you want to map your XML request to a 
>> "Document" >object, you would be circumventing the overhead of these 
>> many >(de)serializations but you would have the overhead of 
>> custom >marshalling of the raw XML which I think is considerable.
>>
>>
>>Not!  Deserializing 5 simpleTypes is damn fast.  Since you'd have to do 
>>the same thing if you sax parsed I'd say its identical!
>>
>>BTW, you don't have to deserialize the XML in ASMX based services at al.. 
>>You can consume the XML as a stream.  Just write your [WebMethod] differently.
>>
>>
>>
>> > I understand that Microsoft uses Doc-style as default SOAP binding. 
>> But how does the mapping of XML to COM objects occur? I have a very 
>> vague idea of Microsoft's web services, please correct me if I am wrong.
>>
>>
>>Whoa - IIRC, the COM based SOAP toolkit will be retired this summer and 
>>no longer supported.  Not that its really that well supported now with 
>>great alternatives like ASMX and WSE 2.0.
>>
>>M apping XML to CLR types occurs via the .NET Framework XMLSerialization 
>>stack which is plenty fast and a nice API I might say.
>>
>>
>> > Document styled web services in .NET differ only in the way SOAP 
>> requests are formatted BUT the underlying mechanism is similar to a RPC 
>> styled web service. In .NET web services you could use SOAP extensions 
>> to intercept the incoming SOAP requests and map them to objects.
>>
>>
>>I don't know what you're getting at.
>>
>>ASMX (and Axis) uses wrapped doc/lit to married the worlds of RPC 
>>oriented consumption with literal wire format.  The messages are entirely 
>>doc lit but the message schema is designed to mosel an RPC invokation 
>>that can be mapped comfortably to OO languages like Java and C#.
>>
>>
>>Jim Murphy
>>Mindreef, Inc.
>
>_________________________________________________________________
>Get rid of annoying pop-up ads with the new MSN Toolbar ­ FREE! 
>http://toolbar.msn.com/go/onm00200414ave/direct/01/

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group 


Mime
View raw message