Hi Tony, > Can you speak to what Dims eluded to... how to use complexTypes w/o > generating helper classes to perform serialization/deserialization. I > want to do what WSIF and JROM started out to do.
Yep I understand ... FYI Paul, Alek and I created WSIF. I created JROM originally (and Rania Khalaf from my old group in IBM took it to completion). So I know exactly what you want to do .. > Also, with the current ServiceClient API, I don't see a way distinquish > between the style of service that you want to invoke. That's by design: ServiceClient is designed to follow WSDL 2.0 model .. where the entire input is always a single element. That element plays the same role that WSIFMessage did- provides a runtime representation for the WSDL <message> instance that's to be sent as input for the operation. At that level, there's no concept of RPC vs document style nonsense. > Basically, you > just pass in an OMElement as the payload. I used WSDL2Java to see > what kind of code would be generated from a simple RPC stockquote > wsdl. The wsdl is as follows: > > <?xml version='1.0' encoding='UTF-8'?> > <definitions name='net.xmethods.services.stockquote.StockQuote' ... > </definitions> > > Axis2 ADB generated coded that produces the following client invocation > stream: > > <?xml version='1.0' encoding='UTF-8'?> > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> > <soapenv:Header /> > <soapenv:Body> > <ns1:getQuote > xmlns:ns1="http://www.themindelectric.com/wsdl/net.xmethods.services.stockquote.StockQuote/";> > <symbol>IBM</symbol> > </ns1:getQuote> > </soapenv:Body> > </soapenv:Envelope> > > This is wrong. First, for rpc style services, the namespace of the > wrapper element (operation) must be specified with the binding > soap:body extension namespace attribute. In the wsdl above, this > namespace is "urn:xmethods-delayed-quotes". Yes this is a bug- please do file an issue for it. A simple patch to the XSLT templates will fix this. > Second, since use is > encoded, don't you have to encode the data that you send? A correct > stream would look something like this: Nope, that part is correct. SOAP Encoding was an algorithm which described how to take a struct like data model and map it to an XML instance. In this case, since the model is defined as an XML element of type xsd:string, there's no mapping to do. Whether one generates xsi:type or not is a totally orthogonal issue .. having that will allow someone who doesn't have the full schema handy on the other side to do something. (There are scenarios where xsi:type is required (if there's a subtype involved) but that's not the case here.) > It seems that with Axis2 everything is treated as a document with > literal encoding. That is, both input/output of ServiceClient > invocation is OMElement. And is it the user's responsibility to > encode the data if necessary (use="encoded") within the payload? Encoding is such a poorly understood thing .. the basic rules of SOAP Enc was that you didn't use attributes but rather element children. If the schema you're dealing with is like that already then a literal "encoding" of a doc conforming to that schema an an SOAP-Enc encoding of that doc will give the same thing. IMO 100% of schemas people use with use='encoded' follow this pattern already. Why? Because the WSDL 1.1 spec does not define how to map an arbitrary XML Schema in to the SOAPEnc data model .. which means if you have an attr in the schema there's no spec which tells where to put that in the message. Not very interoperable, so smart people don't use it. As one of the authors of WSDL 1.1 I accept this as a royal screwup .. we used XML Schema as an abstract representation of any data model including a SOAPEnc one and that's not quite right :(. That's why RPC/Encoded (especially with SOAPEnc) is dead. (There are other reasons too but that's a HUGE reason.) The people who are doing RPC/Enc with SOAPEnc are actually doing RPC/Lit but they don't know it. (The other interesting part of SOAPEnc was the graph encoding stuff .. which people do care about at times. However, IMO if you care about that your services aren't designed right .. XML and Web services should not be sending graphs of data around .. but that's just me :).) > Hopefully, not. In the old Axis 1.x codebase, you could pass in input > data (along with type) and set the operation style that you wanted to > use. How do you do this in Axis2? What is the new paradigm here for > client invocation such that I can code a client with a given set of > data and work with services that are designed as rpc/literal, > rpc/encoded, doc/literal, or doc/literal/wrapped? In what form do you have the data you want to send? Is it as JavaBeans? If so Paul gave you the answer. It can be improved further with annotations to help control the mapping into XML but the idea is correct. Do you want to store them as something like JROM? If so AXIOM fits the bill. In fact I have a student working with me (yes Alek he's alive and kicking again) to bring WSIF to Axis2 .. basically redo WSIF using AXIOM and Axis2. [The only missing thing in AXIOM is type-aware storage .. which JROM had. We talked about that in the early days of AXIOM but let it go .. we will go back and add that at some point maybe but there's no rush AFAICT.] > And my initial question was... if I have custom complexTypes, can I get > Axis2 to interact with them some way without generating the helper > classes. I want to perform dynamic generation. Again, what form do you have those custom complexTyped values in? > Please, help to clear this up a bit for me. Glad to help .. Sanjiva. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
