Hi Tony,
> 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.
Absolutely; Axis2's client API does not limit what you can do at all.
> 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.
The encoding algorithm is a set of rules for how to map an abstract data
model into XML. WSDL 1.1 uses XML Schema as that abstract data model ..
which leads to issues. Consider a schema like this:
<element x>
<complexType>
<element a/>
<element b/>
<attribute c/>
<complexType>
</element>
SOAP Encoding (SOAP 1.1 section 5) does not use attributes .. so that
attr c must become a child element. Does it come first? Come last? What
if there was also a child element called 'c'?
Problem is there's no spec that defines what the rules are for how to
SOAP Encode any XML 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.
Nope, Axiom is just an XML representation. There's no case that cannot
be represented by that.
> 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>
That example is not valid for SOAP Enc. Its certainly fine as a bit of
XML- but not if you use SOAP Enc. So what I said is that *if* someone is
using SOAP Enc, then they don't use attrs because of the problem I
explained above.
> 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.
Oh so then there's no problem at all- construct the input to the service
as an Axiom element and use ServiceClient to send it off.
> 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.
Understood- that's exactly what ServiceClient is for.
Note that this is exactly how generated stubs work .. they fill in the
right kind of Axiom element and use ServiceClient underneath.
> Sorry to ramble here. Just trying to understand and figure out my best
> approach to this problem
The best approach for full function dynamic clients using Axis2 is to
formulate the messages as Axiom elements.
Hope this helps.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
