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/;
symbolIBM/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
