axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shah, Soniya M. [RA]" <>
Subject RE: message style SOAP service
Date Fri, 24 Sep 2004 19:02:34 GMT


Thanks. From the list of points you mentioned, the performance difference
will be negligible between the two approaches if the size of the message is
not too bib.

Does anyone have a simple sample WSDL for message based service? The example
with Axis 1.1 does not have a WSDL.


-----Original Message-----
From: Jim Murphy [] 
Sent: Friday, September 24, 2004 2:46 PM
Subject: Re: message style SOAP service

Shah, Soniya M. [RA] wrote:

> 1. Could message-based service have WSDL?  Could we generate code 
> based
> on WSDL like we do for RPC based? I would think that this is not the 
> case as with document style you will have parse your own xml data. So 
> all you would need to publish is the schema for your xml?

Yes it has a WSDL - infact it will likely have more XSD since you might 
be modeling the XML a little more.

Yes you can generate code from this new doc/lit WSDL.  You can use 
WSDL2Java that ships with Axis or even customize your XML-Java 
marshaling with a custom serialization library like Castor or XMLBeans.

> 2. If you need attachements, is message based better approach or rpc? 
> OR
> that does not matter as attachements are not part of SOAP XML?

Not sure on this.

> 3. Is performance better with message based? I read some articles
> indicating that it is.

This really depends.  Performance can be hurt int he following areas:

1.  Request message serialization - translate from Java/C# objects to XML.
2.  Request Transfer - send/receiving the request XML 3.  Request
deserialization - parsing the XML on the server into XML 
and/or marshaling to Java/C# objects.
4.  The service work itself
5.  Response serialization - Java/C# objects to XML
6.  Response Transfer - send/receive the response XML
7.  Response deserialization - marshal the response XML to Java/C# objects

Whew.  Its really tough to tell which one(s) of those steps dominates in 
your case.  Notice that step #3 and 5 are soemwhat optional if you chose 
to process the XML directly so huge gains can  be made there but at the 
expense of programming convenience - if you're not and XML wonk.

The practical areas that affect perf:

1.  XML parsing - make a DOM vs. Stream (Sax) the XML.   For large 
documents > 1MB perf drops off really fast if you make a DOM. 2.  Message
size - more XML = more time to transmit.  But this is not as 
much of a problem as you'd think.  For small messages its negligible.

Hope this Helps,

Jim Murphy
Mindreef, Inc.

> 4. If your SOAP service needs to return some response, rpc based is
> better? In message based it is supported by HTTP protocol but is it just 
> better to with rpc in this case?
> Thanks,
> Soniya

View raw message