The generally accepted definition of a remote reference is an instance of a proxy that represents a particular instance of a remote object or service that can be transferred from one client to another. Remember that JAX-RPC doesn’t support remote references in its pre-1.0 rendition, largely because SOAP doesn’t have a model for remote references, either. A JAX-RPC client or server must be able to support any arbitrary SOAP message to or from a non-JAX-RPC entity.

In a WSDL operation, a message part can be specified to appear within the input message only. This message part is considered an In parameter. A WSDL message part appearing only within an operation’s output message can be thought of as an out parameter. Message parts appearing in both input and output messages within a WSDL operation can be called inout parameters.

A parameter marked as in indicates that the sending client has no further concern with what that remote procedure does with it once it is sent over the wire. This concept is commonly referred to as pass-by-value or pass-by-copy. An out parameter is a return value. An inout parameter is expected to be modified by the remote procedure, causing the calling client to see the modified value after the method invocation returns.

Generally speaking, you can support inout parameters in two ways: with pass-by-reference and Holder classes. In distributed-computing environments that support pass-by-reference, an object reference is a specific datatype that can be passed as a parameter to a remote object. It can be treated as the handle to an actual instance of the parameter. Once the remote method call is complete, it may be dereferenced by the client program to obtain the newly modified value. The underlying infrastructure marshalls the data over the wire to get the right result.

Java doesn’t support pass-by-reference natively for primitive types. Instead, JAX-RPC uses Holder classes, which are classes used by the underlying infrastructure to act as a place to hold the values. A stub uses a Holder to store the modified values after the method invocation so the calling client can then access them. Here’s an example illustrating the use of Holders:

public interface StockQuoteProvider extends java.rmi.Remote {
// Method returns last trade price
float getStockQuote(String tickerSymbol,
    javax.xml.rpc.holders.IntHolder volume,
    javax.xml.rpc.holders.FloatHolder bid,
    javax.xml.rpc.holders.FloatHolder ask)
  throws java.rmi.RemoteException;
}

//Java
package javax.xml.rpc.holders;
public final class IntHolder {
    public int value;
    public IntHolder(  ) { }
    public IntHolder(int value) {
    this.value = value;
    }
}

Holders are also used to represent complex data structures as parameters. The java.xml.rpc Holders package defines Holders for all the built-in Java primitives. Beyond that, the code generation tool is responsible for creating Holders for the parameters. In either case—whether using the supplied Holder classes or the custom generated ones—-the code generation tool is also responsible for creating the code that serializes and deserializes data sent across the wire.

JAX-RPC allows a code generation tool to create an implementation class for the Service interface based on an existing WSDL document. While the implementation details of the generated class are vendor-specific, the generated interface is required to adhere to the following design pattern:

public interface <ServiceName> extends javax.xml.rpc.Service {
    public <ServiceDefInterface> get<Name of the wsdl:port>(  )
        throws JAXRPCException;
    ...
}

In the previous listing, the <ServiceName> of the generated service interface is mapped from the name attribute of the corresponding wsdl:service definition. The <ServiceDefInterface> name is mapped from the portType, and the get <Name of the wsdl:port> ( ) method is mapped from the—you guessed it—wsdl:port definition’s name attribute. For example, given the following WSDL definition:

<service name="StockQuoteService">
    <port name="StockQuoteProviderPort" binding="tns:somebinding">
        <http:address location="http://example.com/"/>
    </port>
</service>

<portType name="StockQuoteProvider">
    <operation name="GetLastTradePrice"
        parameterOrder="tickerSymbol">
    ...
    </operation>
</portType>

a JAX-RPC implementation creates the following Java interface; the get method returns an instance of a stub class that implements the <ServiceDefInterface>:

package com.example;
    public interface StockQuoteService extends javax.xml.rpc.Service {
    public StockQuoteProvider getStockQuoteProviderPort(  )
        throws JAXRPCException;
    ...
}

Value types are specific to the generation of WSDL from a Java class. A value type is a special form of serializable class, containing data values that are capable of being marshaled between a client and a service. It must implement Serializable, but does not follow the standard rules for Java serialization. Only public, nontransient data members are mapped to the WSDL. A value type may also be a JavaBean, in which case, the WSDL generation may use bean introspection to identify the properties and map them to the WSDL. The methods in the value class are not mapped to the WSDL; it is strictly for data. Whether a value type should use the Serializable marker interface or whether a different interface should be defined is still undecided.