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>>>
