Output parameters

[Russell Butek <bu...@us.ibm.com>]

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