While I understand that the BP recommends document-literal, in reality most of the vendors use the 'wrapped' style when generating document-literal service. I do not know of any vendor to generate pure doc-lit when configuring a web service using an IDE (e.g. WebLogic 8.1). Possibly this is because of the fact that 'wrapped' produces the best shot of being iteroperable with .NET?
So, even thought document-literal is the choice, it may not be practical to use it yet. Any comments on this? Shantanu --- Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > 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 > >
