Wrapped is doc/lit - its just a style that makes rpc-like usage natural.
Jim Murphy Mindreef, Inc.
Shantanu Sen wrote:
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
