More comments bracketed by <atm> ... </atm>. -----Original Message----- From: Jim Murphy [mailto:[EMAIL PROTECTED] Sent: Friday, September 24, 2004 2:46 PM To: [EMAIL PROTECTED] 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. <atm> First some clarification: Your questions seem to imply that you associate "RPC based" with RPC/encoded style and "message based" with document/literal style. This is a common mistake. Unfortunately, the situation is a little more complicated. Please see my blog (http://www.burtongroup.com/weblogs/annethomasmanes/archives/cat_apache_axis .html) for an explanation of the difference between Axis's programming styles (RPC, WRAPPED, DOCUMENT, and MESSAGE) and the WSDL encoding styles (rpc/encoded, rpc/literal, and document/literal). Please understand that the difference between RPC style and Document style applies to the format of the message on the wire, and it doesn't necessarily impact the way you write your application -- particularly if you are using the Axis "WRAPPED" style. The JAX-RPC API supports RPC/encoded, RPC/literal, and Document/literal styles. Just because you are using document/literal, that doesn't mean that you have to parse your own XML data. You only need to parse the XML yourself if you are using the Axis "MESSAGE" style (equivalent to the JAXM API). You want to use the MESSAGE style interface if your application prefers to parse the XML itself or if you need to send one-way messages. In all cases, whether using an RPC-style API (JAX-RPC or .NET) or a messaging API (JAXM), you should have a WSDL. The WSDL includes the message schema, and it includes binding information that the client needs to connect to your service. Note that even if you create a service using a messaging API, the application consuming the service may use an RPC-style programming interface or vice versa. If you read through the archives, you'll see that I consistently recommend that people always use document/literal for all services. If you want to simulate an RMI-like programming experience, then use the "WRAPPED" programming style. (The "WRAPPED" style generates a document/literal message.) </atm> > 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. <atm> It doesn't matter. </atm> > 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? <atm> It doesn't matter. Both RPC and Messaging support request/response. </atm> > > Thanks, > Soniya
