axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: Relationships between addParameter/setReturnType/invoke
Date Fri, 04 Jan 2002 16:38:59 GMT

Comments inline:

> -----Original Message-----
> From: Russell Butek [mailto:butek@us.ibm.com]
> Sent: Friday, January 04, 2002 8:54 AM
> 
> 1.  According to JAX-RPC, on the Call object you either MUST call
> addParameters/setReturnType or you CANNOT call them.  In 
> other words, the
> Call object either has no meta data, so you must provide it; 
> or it has meta
> data and you cannot mess with it.

This should, IMO, be brought up with JAX-RPC as an unnecessarily limited way of looking at
it.  I'll do so.

> 2.  AXIS also provides something in between.  A simple case 
> where the Call
> object does not have any meta data and the user doesn't have 
> to provide
> any.  The Call object makes an educated guess.  For example, 
> once you get a
> Call object you could immediately make a call like:
> 
>     javax.xml.rpc.Call call = get Call object
>     Integer i = (Integer)call.invoke("someMethod", args);
> 
> If the types of args and the return are primitive types, then 
> AXIS can do
> this.  This only works for primitive types.  Also, the 

This actually works for any type we have a mapping for, not just primitives.  The key is that
there must be an xsi:type attribute on the return value for us to be able to deserialize it.
 Since SOAP says xsi:type attributes are optional, we run into potential failure situations
in this situation when toolkits don't send it.

> parameter names are
> not given to AXIS and, since many SOAP engines require 
> parameter names in
> the SOAP message, this is not fully interoperable.  Since it's not
> interoperable it's very doubtful this added feature would 
> make it into the
> JAX-RPC spec, so this call is also non-portable.
>
> But just because it's not portable and not interoperable 
> doesn't mean we
> can't provide it, we just can't provide it within the bounds 
> of JAX-RPC
> (ie., we can't call javax.xml.rpc.Call.invoke).  But we 
> already have an
> AXIS-specific Call object - org.apache.axis.client.Call - so we could
> provide an AXIS-specific invoke on this object, say 
> axisInvoke, so users
> would call:
> 
>     org.apache.axis.client.Call call = get AXIS Call object
>     Integer i = (Integer)call.axisInvoke("someMethod", args);
> 
> A side-effect of this new method is that, while it warns 
> users that they're
> doing something non-portable, it's also explicitly telling 
> them they're
> using a useful AXIS shortcut feature.

Why is this necessary?  I don't see a need for a new invoke(), and I think putting one in
would be confusing.  It's not the semantics of invoke() that we're changing, it's simply that
the engine may help you out a little more than JAX-RPC specifies at present.

> 3.  Now, back to the comments in my previous note.  AXIS 
> currently turns
> the first output from the SOAP message (resArgs[0]) into the 
> return value
> and puts the rest into the outParams Vector.  We will 
> continue to do this
> if we are in scenario #2 (since it has no meta data AXIS must make an
> educated guess).  If we are invoking from a scenario in #1, 
> then we must
> use the meta data to determine what is returned and what is 
> placed in the
> outParams Vector/Map.

I think this summation is valid, except for the fact that I don't agree with the new axisInvoke()
method.  When invoke() is called, if we haven't called setReturnType() or addParameter(),
we behave like we do now (first param is return value).  If we HAVE called addParameter(),
we should respect all the specified out params.  The question is how to determine the return
value in this case.  I guess the return would be the first out param which isn't already specified
by an addParameter() (and matches any type set by setReturnType())?

--Glen

Mime
View raw message