Sanjiva, Thanks for responding...i'm trying to digest your comments.
1. OK, so Axis2 was designed with wsdl 2.0 in mind. And, thus you have a single input document and a single output document. We will most likely be interoperating with wsdl 1.1 services for a long while so I must remain compliant in my client application of choice. You said below since the input "model is defined as an XML element of type xsd:string, there's no mapping to do." I'm fuzzy on this... can you give me an example where a mapping is required? I just thought use="encoded" mean't that the encoding must be inlined with the soap message itself and use="literal" mean't that the encoding is specified in the schema. So bottom line, when will the Axiom model (doc/lit) not work with a particular wsdl 1.1 service type? Sorry to be so hard-headed on this encoding issue. An example may help me. Can you also explain your statement about having attrs in your schema making for interoperable issues? I'm not following. Attributes can be typed in schema. What's wrong with the following for instance: <Data name="string-representing-name-of-data"> <Float>xsd:float type<Float> </Data> 2. I don't really have my data in any particular form. I will gather information from a running system in order to inject values into a particular model based on the wsdl message, then send the request to a service endpoint. Basically, my goal is to dynamically, programatically interact with arbitrary service endpoints sort of the same way a bpel engine does with the invoke activity. These endpoints will most likely by created from wsdl 1.1 toolkits for the forseeable forture so I need to be able to interop with them as a client. 3. If all input/output is treated as a document, WSIF/JROM becomes less important, right (at least for Axis2)? JROM is basically a DOM representation of a complexType I thought. What value-add can you provide for Axis2? I guess creating an in-memory Axiom/DOM representation of the input complex type would be helpful. Then the application could fill in the pertinent data; otherwise, the application would have to read the wsdl and do this itself before it now how to create the input representation. I am talking about dynamic invocation only here. Sorry to ramble here. Just trying to understand and figure out my best approach to this problem -Tony -----Original Message----- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 3:49 PM To: axis-dev@ws.apache.org Cc: axis-user@ws.apache.org Subject: RE: [axis2] dynamic client invocation w/o intermediateclassgeneration 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
