Hello.
I'm not sure i have understood it all. Sincerly, i remember, years ago, i
had a look at the CORBA/GIOP/IIOP marshalling protocols, and finished the
day with the same headache ! But, once more, we were lucky : we had IDL to
write our interfaces...
As i understand, wsdl doesn't give a clear difference between strict
document style, and a wrapped form, and both client and server must have
some code to serialize or deserialize a multi-part body according to,
respectively, the client data form or the server implementation form. I
suppose stubs do that.
Despite my problems with the java2wsdl task, i have finally use a 'wrapped'
axis wsdl to generate my client stubs for a single operation service that
takes a simple javabean argument (a string and an int). I use the SUN WTK
2.1 with its first JSR172 implementation, that only supports the
document/literal as specified. The service interface has been generated with
2 arguments : the string and the int. In a former test, using a true
document/literal wsdl, generated with the SUN JWSDK 1.3, the generated
operation had a single argument of a generated javabean type, as expected.
In this test case, a 2 attributes bean generates a 2 parameters method, but
in a true project with 50 attributes javabeans... supposing client and
server can communicate !
My deduction : 'wrapped' is not 'document' for JSR172 ! I think i've read
the JSR172 requires WS-I Basic Profile compliance...
Philippe Maseres
<<<Philippe>>> -----Message d'origine-----
<<<Philippe>>> De : Jeff Greif [mailto:[EMAIL PROTECTED]
<<<Philippe>>> Envoyé : mardi 21 décembre 2004 17:07
<<<Philippe>>> À : [EMAIL PROTECTED]
<<<Philippe>>> Objet : Re: java2wsdl ant task for document/literal
<<<Philippe>>>
<<<Philippe>>>
<<<Philippe>>> Here is a wsdl-centric way of looking at the 'wrapped' form:
<<<Philippe>>>
<<<Philippe>>> If the wsdl is for a doc/lit operation, regardless
<<<Philippe>>> of wrapping, the wire
<<<Philippe>>> format is fixed by the wsdl. If the request message
<<<Philippe>>> has parts p1..n
<<<Philippe>>> specified by elements e1..n, the soap body must be
<<<Philippe>>> <Body>
<<<Philippe>>> <e1>...</e1>
<<<Philippe>>> ...
<<<Philippe>>> <en>...</en>
<<<Philippe>>> </Body>
<<<Philippe>>>
<<<Philippe>>> For doc/lit operations conforming to the WS-I Basic
<<<Philippe>>> Profile 1.0, there will
<<<Philippe>>> be only one part.
<<<Philippe>>>
<<<Philippe>>> Independent of the WSDL and one another, the client
<<<Philippe>>> or the server or both
<<<Philippe>>> may treat a one-part operation as wrapped. This
<<<Philippe>>> means that if element e1 is
<<<Philippe>>> of type T1, where type T1 is
<<<Philippe>>> <complexType name="T1">
<<<Philippe>>> <sequence>
<<<Philippe>>> <element name="a" type="A"/>
<<<Philippe>>> <element name="b" type="B"/>
<<<Philippe>>> <element name="c" type="C"/>
<<<Philippe>>> </sequence>
<<<Philippe>>> </complexType>
<<<Philippe>>>
<<<Philippe>>> then a client deployed as wrapped must provide 3
<<<Philippe>>> items serializable to type
<<<Philippe>>> A, type B and type C. The implementation of the
<<<Philippe>>> client will assemble them
<<<Philippe>>> into a proper e1 element to send to the server.
<<<Philippe>>>
<<<Philippe>>> Similiarly, if the server implementation is deployed
<<<Philippe>>> as wrapped, the server
<<<Philippe>>> implementation will disassemble the e1 element that
<<<Philippe>>> arrives over the wire
<<<Philippe>>> and call the implementation method with 3
<<<Philippe>>> programming language objects which
<<<Philippe>>> are deserialized representations of types A, B and C
<<<Philippe>>> respectively.
<<<Philippe>>>
<<<Philippe>>> The wrapped form makes either the client or the
<<<Philippe>>> server side look more like
<<<Philippe>>> an RPC call.
<<<Philippe>>>
<<<Philippe>>> If the client is not deployed as wrapped, it must
<<<Philippe>>> provide a single parameter
<<<Philippe>>> which serializes into an e1 element of T1 type. If
<<<Philippe>>> the server is not
<<<Philippe>>> deployed as wrapped, its implementation method is
<<<Philippe>>> called with a single
<<<Philippe>>> argument, a deserialized form of the e1 element
<<<Philippe>>> (usually a DOM Element).
<<<Philippe>>>
<<<Philippe>>> .Net and Axis contain what is essentially a
<<<Philippe>>> heuristic for having some
<<<Philippe>>> clients and services be deployed as wrapped by
<<<Philippe>>> default. One of the
<<<Philippe>>> conditions tested in this heuristic is that the e1
<<<Philippe>>> element of the request
<<<Philippe>>> have the same qname as the web service operation.
<<<Philippe>>>
<<<Philippe>>> Note that there is no way to indicate anything about
<<<Philippe>>> wrapping in the wsdl,
<<<Philippe>>> at least not without additional extensions. The
<<<Philippe>>> fixed wire format for the
<<<Philippe>>> transmitted SOAP decouples the client and server
<<<Philippe>>> from one another in whether
<<<Philippe>>> wrapping is used for a particular operation.
<<<Philippe>>>
<<<Philippe>>> Jeff
<<<Philippe>>>
<<<Philippe>>> ----- Original Message -----
<<<Philippe>>> From: "Daniel Beland" <[EMAIL PROTECTED]>
<<<Philippe>>> To: <[EMAIL PROTECTED]>
<<<Philippe>>> Sent: Tuesday, December 21, 2004 12:53 AM
<<<Philippe>>> Subject: Re: java2wsdl ant task for document/literal
<<<Philippe>>>
<<<Philippe>>>
<<<Philippe>>> >
<<<Philippe>>> >
<<<Philippe>>> > In fact, to be more precise, it means that there
<<<Philippe>>> is a schema element, with
<<<Philippe>>> > the same name as the operation, that contains
<<<Philippe>>> (wraps) the actual document
<<<Philippe>>> > element representing all the parameters.
<<<Philippe>>> >
<<<Philippe>>> > ie:
<<<Philippe>>> >
<<<Philippe>>> > wrapped
<<<Philippe>>> > <A>
<<<Philippe>>> > <AElement/> (of type X)
<<<Philippe>>> > </A>
<<<Philippe>>> >
<<<Philippe>>> > document
<<<Philippe>>> > <AElement/> (of type X)
<<<Philippe>>> >
<<<Philippe>>> > I believe this is not part of WS-I and was defined
<<<Philippe>>> by Microsoft only. I
<<<Philippe>>> > used to work this way but after some
<<<Philippe>>> incompatibilities I switched to plain
<<<Philippe>>> > doc/lit instead.
<<<Philippe>>> >
<<<Philippe>>> > If you start with a wsdl, I find it easier than
<<<Philippe>>> wrapped, and by having
<<<Philippe>>> > significant names for the elements you don't miss
<<<Philippe>>> any clarity in the SOAP
<<<Philippe>>> > body.
<<<Philippe>>> >
<<<Philippe>>> > The java portion is nearly identical (Single java
<<<Philippe>>> object with getX()
<<<Philippe>>> > methods instead of all unwrapped parameters directly).
<<<Philippe>>> >
<<<Philippe>>> >
<<<Philippe>>> > > Ephemeris Lappis a écrit :
<<<Philippe>>> > >
<<<Philippe>>> > >>I'm not a SOAP expert ! I think i had understood
<<<Philippe>>> the difference between
<<<Philippe>>> > >>document and wrapped styles, and i suppose tools
<<<Philippe>>> that will process the
<<<Philippe>>> > >>repective wsdl files will not generate similar
<<<Philippe>>> codes : both use xml
<<<Philippe>>> > >> messages
<<<Philippe>>> > >>without soap encoding, but in document mode the
<<<Philippe>>> javabeans arguments of
<<<Philippe>>> > >>operations must be made back from the wsdl as
<<<Philippe>>> is, and not as distinct
<<<Philippe>>> > >>primitive arguments...
<<<Philippe>>> > >>
<<<Philippe>>> > >>
<<<Philippe>>> > > Actually the only difference between wrapped and
<<<Philippe>>> document is the
<<<Philippe>>> following
<<<Philippe>>> > > :
<<<Philippe>>> > > in wrapped mode, you get the name of the
<<<Philippe>>> operation as the soap body's
<<<Philippe>>> > > root element.
<<<Philippe>>> > >
<<<Philippe>>> > > Then, you're still able to use either javabeans
<<<Philippe>>> arguments or primitive
<<<Philippe>>> > > arguments ... or both :)
<<<Philippe>>> > >
<<<Philippe>>> > >>In my case, i can't choose the encoding mode :
<<<Philippe>>> the targetted service
<<<Philippe>>> must
<<<Philippe>>> > >> be
<<<Philippe>>> > >>used by J2ME clients, and, if possible, using
<<<Philippe>>> the recent JSR172
<<<Philippe>>> > >>specification that only supports "document style
<<<Philippe>>> with literal use"..
<<<Philippe>>> > >>
<<<Philippe>>> > >>
<<<Philippe>>> > > Here, we all agree with you :)
<<<Philippe>>> > >
<<<Philippe>>> > > --
<<<Philippe>>> > > Julien
<<<Philippe>>> > >
<<<Philippe>>> >
<<<Philippe>>>
