axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject RE: [axis2] dynamic client invocation w/o intermediate classgeneration
Date Thu, 15 Jun 2006 19:48:30 GMT
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

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='' 
> </definitions>
> Axis2 ADB generated coded that produces the following client invocation stream:
> <?xml version='1.0' encoding='UTF-8'?>
> <soapenv:Envelope xmlns:soapenv="">
>  <soapenv:Header />
>  <soapenv:Body>
>   <ns1:getQuote xmlns:ns1="">
>    <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 .. 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message