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 13:53:48 GMT
Glen and I had a bit of a chat and here's the upshot.  I'm taking some
liberties, Glen, so I expect some discussion - particularly on point #2.

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.

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 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.

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.

Russell Butek

Russell Butek/Austin/IBM@IBMUS on 01/03/2002 01:58:31 PM

Please respond to

Subject:  Relationships between addParameter/setReturnType/invoke

There are a lot of problems with the Call object and parameters in the
JAX-RPC spec.  Now that I'm trying to implement the parameterOrder updates
in JAX-RPC, I'm running into some of these problems.  Here's one.
JAX-RPC's Call object, as of version 0.6, now has a getOutputParams method.
This is good.  We already found a need for one in AXIS and implemented it,
so the spec is getting closer to reality.  They're a little different - the
AXIS one returns a Vector while the JAX-RPC one returns a Map - but that's
easy to remedy.  But there's another question about this method and the
return from invoke.

Say we call:

        new XMLType(new QName("", "int")),
        new XMLType(new QName("", "int")));

Then after calls to:

    Object ret = call.invoke(...);
    Map output = call.getOutputParams();

ret will be non-null and output would be a map that contains one element.

But if we did:

        new XMLType(new QName("", "int")),
        new XMLType(new QName("", "int")),

(notice there's no call to setReturnType) then after calls to:

    Object ret = call.invoke(...);
    Map output = call.getOutputParams();

I would expect ret to be null (since we didn't set a return type) and
output to be a map that contains two elements.  HOWEVER, our implementation
of Call ALWAYS returns the first resArgs element and puts the rest into the
outputParams Vector regardless of what addParameter/setReturnType calls
were made.

This seems wrong to me and I would like to fix it unless someone can
enlighten me on why I should leave it alone.

Russell Butek

View raw message