axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vivek Nagulapati" <vivek_nagulap...@hotmail.com>
Subject Re: Document (Vs) RPC style services
Date Tue, 30 Mar 2004 20:37:43 GMT

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/


Mime
View raw message