Here is a wsdl-centric way of looking at the 'wrapped' form:
If the wsdl is for a doc/lit operation, regardless of wrapping, the wire
format is fixed by the wsdl. If the request message has parts p1..n
specified by elements e1..n, the soap body must be
<Body>
<e1>...</e1>
...
<en>...</en>
</Body>
For doc/lit operations conforming to the WS-I Basic Profile 1.0, there will
be only one part.
Independent of the WSDL and one another, the client or the server or both
may treat a one-part operation as wrapped. This means that if element e1 is
of type T1, where type T1 is
<complexType name="T1">
<sequence>
<element name="a" type="A"/>
<element name="b" type="B"/>
<element name="c" type="C"/>
</sequence>
</complexType>
then a client deployed as wrapped must provide 3 items serializable to type
A, type B and type C. The implementation of the client will assemble them
into a proper e1 element to send to the server.
Similiarly, if the server implementation is deployed as wrapped, the server
implementation will disassemble the e1 element that arrives over the wire
and call the implementation method with 3 programming language objects which
are deserialized representations of types A, B and C respectively.
The wrapped form makes either the client or the server side look more like
an RPC call.
If the client is not deployed as wrapped, it must provide a single parameter
which serializes into an e1 element of T1 type. If the server is not
deployed as wrapped, its implementation method is called with a single
argument, a deserialized form of the e1 element (usually a DOM Element).
.Net and Axis contain what is essentially a heuristic for having some
clients and services be deployed as wrapped by default. One of the
conditions tested in this heuristic is that the e1 element of the request
have the same qname as the web service operation.
Note that there is no way to indicate anything about wrapping in the wsdl,
at least not without additional extensions. The fixed wire format for the
transmitted SOAP decouples the client and server from one another in whether
wrapping is used for a particular operation.
Jeff
----- Original Message -----
From: "Daniel Beland" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 21, 2004 12:53 AM
Subject: Re: java2wsdl ant task for document/literal
>
>
> In fact, to be more precise, it means that there is a schema element, with
> the same name as the operation, that contains (wraps) the actual document
> element representing all the parameters.
>
> ie:
>
> wrapped
> <A>
> <AElement/> (of type X)
> </A>
>
> document
> <AElement/> (of type X)
>
> I believe this is not part of WS-I and was defined by Microsoft only. I
> used to work this way but after some incompatibilities I switched to plain
> doc/lit instead.
>
> If you start with a wsdl, I find it easier than wrapped, and by having
> significant names for the elements you don't miss any clarity in the SOAP
> body.
>
> The java portion is nearly identical (Single java object with getX()
> methods instead of all unwrapped parameters directly).
>
>
> > Ephemeris Lappis a écrit :
> >
> >>I'm not a SOAP expert ! I think i had understood the difference between
> >>document and wrapped styles, and i suppose tools that will process the
> >>repective wsdl files will not generate similar codes : both use xml
> >> messages
> >>without soap encoding, but in document mode the javabeans arguments of
> >>operations must be made back from the wsdl as is, and not as distinct
> >>primitive arguments...
> >>
> >>
> > Actually the only difference between wrapped and document is the
following
> > :
> > in wrapped mode, you get the name of the operation as the soap body's
> > root element.
> >
> > Then, you're still able to use either javabeans arguments or primitive
> > arguments ... or both :)
> >
> >>In my case, i can't choose the encoding mode : the targetted service
must
> >> be
> >>used by J2ME clients, and, if possible, using the recent JSR172
> >>specification that only supports "document style with literal use"..
> >>
> >>
> > Here, we all agree with you :)
> >
> > --
> > Julien
> >
>
