axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <>
Subject RE: Relationships between addParameter/setReturnType/invoke
Date Fri, 04 Jan 2002 19:25:38 GMT
If you're willing to take this to JAX-RPC, that's fine.  One concern I
have, though, in using the same invoke method for both the JAX-RPC model
AND the AXIS model, is letting an error slip through.  Scenario:

- method "x" takes no parameters and returns nothing.
- since there are no parameters or return values, neither addParameter nor
setReturnType is called.
- following JAX-RPC, if there is ANY return value, then it is an error
because we never told AXIS there would be one.
- following the AXIS model, since neither addParameter nor setReturnType
was called, AXIS must assume it's allowed to guess, and it guesses that it
can return something, rather than fail.

The runtime cannot tell whether it should have failed or not.  Now if there
were some XML type such as xsd:void, then we could require the user, in the
JAX-RPC model, to call setReturnType(new QName("...", "void")), but I don't
think such a beast exists.

Russell Butek

Glen Daniels <> on 01/04/2002 10:38:59 AM

Please respond to

To:   "''" <>
Subject:  RE: Relationships between addParameter/setReturnType/invoke

Comments inline:

> -----Original Message-----
> From: Russell Butek []
> 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())?


View raw message