The "wrapped" style *is* pure document/literal. The "wrapped" style is simply a programming convention that allows developers to use an RPC/RMI-style programming model to produce document/literal messages. In a "wrapped" style service, the WSDL specifies style="document" and use="literal". The SOAP message is encoded according to the literal schema definition you've specified in the WSDL. Nothing in the WSDL specifies "wrapped". It *is* document/literal.
Please see my blog entry (http://www.burtongroup.com/weblogs/annethomasmanes/archives/cat_apache_axis .html) for an explanation of the difference between programming style (rpc vs wrapped vs document vs message) versus wire encoding style (rpc/encoded vs rpc/literal vs document/literal). You can only use the wrapped style if the WSDL conforms to the "wrapped" convention. If it doesn't conform (for example, if the WSDL defines attributes rather than elements, it uses a choice group rather than a sequence group, or if the input element name is not the same as the operation name), then the developer has to invoke operations using objects rather than parameters. But most tools generate the wrapped convention because it makes it easier for the developer. Anne -----Original Message----- From: Shantanu Sen [mailto:[EMAIL PROTECTED] Sent: Friday, September 24, 2004 8:28 PM To: [EMAIL PROTECTED] Subject: RE: message style SOAP service 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 > >
