Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Importance: Normal
Subject: Re: Output parameters
To: axis-dev@xml.apache.org
Message-ID: <OFC75FE158.5F3CD7BC-ON86256AA8.0075010D@raleigh.ibm.com >
From: "Russell Butek" <butek@us.ibm.com>
Date: Tue, 14 Aug 2001 16:25:46 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Unfortunately the draft JAX RPC spec isn't publicly available.  Sun owns it
and has submitted it to an expert group for review.  Only expert group
companies can see it now.  We (Sam and I and maybe others) are trying to
get Sun to open it up to axis-dev, but the best prognosis at this point is
that it won't happen for at least a week, if at all.

The joys of living on the bleeding edge.

Russell Butek
butek@us.ibm.com


Richard Emberson <emberson@contact.com>@contact.com on 08/14/2001 05:25:47
PM

Please respond to axis-dev@xml.apache.org

Sent by:  emberson@contact.com


To:   axis-dev@xml.apache.org
cc:
Subject:  Re: Output parameters


Thank you. I am corrected.

There there somewhere one can go and see the draft JAX RPC?

Thanks

RME


Russell Butek wrote:

> Yeah, this might appear a little too cute.  But the holders and the
> cuteness of inout parameters are what the draft JAX RPC spec calls for,
so
> that bit isn't anything that I'm inventing.  If there is a big aversion
to
> it here, I can certainly have our expert group rep bring it up to Sun and
> see whether they'll change the spec, but I rather doubt that'll happen.
> They COULD change it, for example, such that all methods take a single
> Vector of input parameters and return a single Vector of output
parameters.
> But that isn't very Java-like.  The cuteness of the spec is more-or-less
an
> attempt to keep things looking as Java-like as possible.  And considering
> that most operations likely won't have overlapping input/output parts and
> likely won't have more than one output part, then their mapping becomes
> something that is exactly Java-like.
>
> Russell Butek
> butek@us.ibm.com
>
> Richard Emberson <emberson@contact.com>@contact.com on 08/14/2001
04:07:46
> PM
>
> Please respond to axis-dev@xml.apache.org
>
> Sent by:  emberson@contact.com
>
> To:   axis-dev@xml.apache.org
> cc:
> Subject:  Re: Output parameters
>
> Me thinks its a little too cute.
>
> First, the vast majority of the time when there are multiple return
values,
> out
> values - outies, they will not overlap with the input values. To add both
> the
> code
> and conscept of a different return mechanism when the just happen to
> have the same type name and parameter name is unnecessary; cute but
> added complexity. If a user in their code you are toggling between
> (tradding
> off)
> have a return parameter (out parameter) having the same name as an in; if
> all outies are return in a Vector, then very little code has to be
changed
> by
> the
> user to do it; on the otherhand if outies have two totally different ways
> of
> being returned depending on whether they happen to match type and name,
> then the user's code has to have larger modification just because of a
name
> change.
>
> Secondly, Sun has toyed around with someday adding multi-return values to
> Java. This would be accomplished by code generated by the compiler.
Within
> the method it would create an Object array, stuff the return value
objects
> into it
> and return the array. The code that called the method would have code
> generated
> that takes the objects out and sets the local object to them (special
work
> for
>
> primitive types but still possible). So, if they ever get around to it,
> then
> not
> implementing "holders" would be the correct solution.
>
> RME
>
> Russell Butek wrote:
>
> > Here is a version of my suggestion from last week on output parameters
> > that's a bit more concrete.  At the end is the code in AXIS that would
> have
> > to change to make this model of output parameters work.
> >
> > The first realization I get is that AXIS doesn't know anything about
> > holders and Java doesn't know anything about multiple outputs.  Let's
> leave
> > it that way.  Java signatures can have holders, but these holders
> shouldn't
> > get down to AXIS.  Therefore, the stub must translate from Java to AXIS
> and
> > back to Java.  Ditto on the server side:  the skeleton must translate
> from
> > AXIS to Java and back to AXIS.
> >
> > In general, this would mean that within the stub:
> > - ServiceClient.invoke takes an array of Objects.  These objects are
all
> > the input parameters, both input and inout.
> > - ServiceClient.invoke returns an Object.  This object is either:
> >   - a RemoteException;
> >   - a single Object if there is only one output (output or inout)
> > parameter;
> >   - a Vector of output parameters if there are more than one.  (I
thought
> > invoke could ALWAYS return a Vector, but since a single output is
> probably
> > the most common case, I thought we could make that case simpler; one
less
> > object, less calls, etc.)
> >
> > And in general, this would mean the skeleton contains methods that AXIS
> > would understand, ie, they have no holders.  These methods would look a
> lot
> > like ServiceClient.invoke, meaning that they take only input parameters
> and
> > return either a single Object or a Vector.  Each of these skeleton
> methods
> > delegates to the implementation's real methods.
> >
> > For example, given the following WSDL snippet:
> >
> >   <message name="in">
> >     <part name="name" type=xsd:string"/>
> >     <part name="phone" type="typens:phone"/>
> >   </message>
> >
> >   <message name="out">
> >     <part name="address" type="typens:address"/>
> >     <part name="phone" type="typens:phone"/>
> >   </message>
> >
> >   <portType name="Inout">
> >     <operation name="method">
> >       <input message="tns:in"/>
> >       <output message="tns:out"/>
> >     </operation>
> >   </portType>
> >
> > There is one input parameter - name - one inout parameter - phone - and
> one
> > output parameter - address.  This maps to the java interface:
> >
> > public interface Inout extends Remote
> > {
> >   public Address method (String name, PhoneHolder phone) throws
> > RemoteException;
> > }
> >
> > The stub code for this method could be:
> >
> >   public Address method (String name, PhoneHolder phone) throws
> > RemoteException
> >   {
> >     Object resp = call.invoke (serviceName, "method", new Object[]
{name,
> > phone._value});
> >     if (resp instanceof RemoteException)
> >       throw (RemoteException)resp;
> >     else
> >     {
> >       java.util.Vector output = (java.util.Vector)resp;
> >       phone._value = (Phone)output.get (0);
> >       return (Address)output.get (1);
> >     }
> >   }
> >
> > The skeleton's method signature would be slightly different, it would
be
> > one that Axis understands (ie., one that doesn't contain holders).  It
> > would delegate to the actual implementation's real method.
> >
> >   public Object method (String name, Phone phone) throws
RemoteException
> >   {
> >     PhoneHolder h0 = new PhoneHolder (phone);
> >     Object o = impl.method (name, h0);
> >     Vector v = new Vector ();
> >     v.add (h0._value);
> >     v.add (o);
> >     return v;
> >   }
> >
> > I only had to change a couple dozen lines in Axis to get this model of
> > multiple output parameters to work.  In detail, I changed the following
> > near the bottom of ServiceClient.invoke:
> >
> >         if (resArgs != null && resArgs.size() > 0) {
> >             RPCParam param = (RPCParam)resArgs.get(0);
> >             result = param.getValue();
> >         }
> >
> > to:
> >
> >         if (resArgs != null)
> >         {
> >             if (resArgs.size () == 1) {
> >                 RPCParam param = (RPCParam)resArgs.get(0);
> >                 result = param.getValue();
> >             }
> >             else if (resArgs.size () > 1)
> >             {
> >                 Vector v = new Vector ();
> >                 for (int i = 0; i < resArgs.size (); ++i)
> >                     v.add (((RPCParam)resArgs.get (i)).getValue ());
> >                 result = v;
> >             }
> >         }
> >
> > And in RPCProvider.processMessage, again near the bottom, I changed:
> >
> >             if ( objRes != null ) {
> >                 RPCParam param = new RPCParam(mName + "Result",
objRes);
> >                 resBody.addParam(param);
> >             }
> >
> > to:
> >
> >             if ( objRes != null ) {
> >                 if (objRes instanceof Vector)
> >                 {
> >                     Vector v = (Vector)objRes;
> >                     for (int i = 0; i < v.size (); ++i)
> >                         resBody.addParam (new RPCParam (mName +
"Result"
> +
> > i, v.get (i)));
> >                 }
> >                 else
> >                 {
> >                     RPCParam param = new RPCParam(mName + "Result",
> > objRes);
> >                     resBody.addParam(param);
> >                 }
> >             }
> >
> > Does this look like a reasonable change to folks?
> >
> > Russell Butek
> > butek@us.ibm.com
> >
> > Russell Butek/Austin/IBM@IBMUS on 08/10/2001 08:12:04 AM
> >
> > Please respond to axis-dev@xml.apache.org
> >
> > To:   axis-dev@xml.apache.org
> > cc:
> > Subject:  Output parameters
> >
> > For output and inout parameters, JAX RPC defines holders.  Just like
> CORBA.
> > As an example, here's a holder for a String:
> >
> >    public final class StringHolder implements java.io.Serializable
> >    {
> >      public String _value;
> >
> >      public StringHolder () {}
> >
> >      public StringHolder (String value)
> >      {
> >        this._value = value;
> >      }
> >    }
> >
> > Say we have:
> >
> >      <message name="Msg">
> >        <part name="name" type="xsd:string"/>
> >        <part name="address" type="typens:address"/>
> >      </message>
> >
> >      <portType name="Inout">
> >        <operation name="method">
> >          <output message="tns:Msg"/>
> >        </operation>
> >      </portType>
> >
> > This probably translates to the following Java method signature:
> >
> >    public String method (AddressHolder address);
> >
> > The first output parameter becomes the method's return value and
> successive
> > ones are holders in the parameter list.
> >
> > The current implementation of ServiceClient.invoke takes a list of
input
> > parameters and returns a single Object.  This will have to change.
> >
> > One possibility:  invoke could return a Vector (or something) of
Objects.
> > The stub could then pull out the output values from this Vector, plug
> 1..n
> > into the appropriate Holders, and return the 0th one.  This is very
> similar
> > to how CORBA handles this (which doesn't mean that it's good, just that
> > it's proven).  Instead of lists of parameters, CORBA stubs use input
and
> > output streams, but the result is roughly the same.
> >
> > It would take very little to change ServiceClient.invoke.  It's already
> > dealing with a Vector of RPCParams.  Right now it only returns the
value
> of
> > the 0th element and ignores anything else that might be in the Vector.
> All
> > it would have to do is stop ignoring the rest.
> >
> > That's the client side.  I'm not very familiar with the server side,
yet.
> >
> > Sam, you said you and Glen have been discussing this.  Any words of
> wisdom?
> >
> > Russell Butek
> > butek@us.ibm.com