To the client routines , the client stub is the actual routine to call. Any marshalling , that is packing the client's argument data into network packets that the server stub can understand, is done transparently.
The analog concepts is valid for the server routines . They only interface with the server stub.
It is often not allowed in RPC to use call by reference, because of it's tricky implementation. But it is often emulated by assigning the return value of a procedure/function call back to an argument variable.
The question "how does the client contact the appropriate remote system to have a particular RPC executed?" can be divided into two subquestions:
The first step is usually done with a central naming service to which a connection is established at boot time. The second step is usually archieved by a special RPC service with a known port, who serves the purpose of a local naming service. Local services register with there ports etc. when starting up and deregister when they are shut down.
Of course, a "universal language" is needed which is understood by all parties and should be platform independent. Examples are:
| RPC Framework Name | Typically Used Underlying Protocol(s) |
|---|---|
| Sun RPC | UDP, TCP |
| Xerox courier | SPP |
| Apollo RPC | UDP, PPS |
| Java (RMI) | TCP, UDP or a mix of both (since JDK 1.2) |
The underlying data types have to use exactly the same bitwise presentation. For example, there are several different types of standarized floating point representations or character representation (EBDIC vs ASCII vs Unicode). Byte ordering is naturally of importance, too.
Procedure calls in a LPC framework are usually executed without problems. With RPC various different error conditions can occur, e.g.:
With LPC it is usually no problem to guarrantee that a procedure call was executed once and exactly once. Over RPC a problem occurs, if the client receives no answer: Was the procedure executed or not?
There is no problem with so called idempotent calls . It does not matter how often they are called, since calling them does not change any global state, e. g.:
Calls that are not idempotent:
Different semantics for RPC calls, of course exactly once is the most difficult one:
| Semantic | Example |
|---|---|
| exactly once | bank transaction |
| at most once | audio transmit |
| at least once | return date |
As the underlying data representation XDR is used in Sun RPC. Since it is from Sun, it is naturally big-endian. In addition to this, every data field is at least 32 bits in size.
Java RMI is comparable with CORBA (Common Object Request Broker Architecture), but is more tightly integrated with the language and thus only usable with Java.
There has to be an interface specification for the server object which is used by the server and the client.
It extends java.rmi.Remote .
The implementation of the server object (which is only run and needed on the server side) extends this interface.
Usually the implementation also implements java.rmi.server.UnicastRemoteObject or java.rmi.activation.Activatable which are both subclasses of java.rmi.server.RemoteServer.html .
These classes already contain the code to make the server object automatically available for clients.
(Registering the object via the naming service for which a special daemon called "rmiregistry" or even activating it on demand.)
The client may use a special client stub.
The Java RMI stub compiler (rmic) may be used to generate client stub and server skeleton automatically.
A special remote reference abstraction layer is used to make it transparent, if the object is local or remote and has to be initialized or not.
All arguments to remote object methods have to be serializable because the native java serialization facility is used to transport the data over the network.
That usually means that any objects passed as arguments have to be instantiations of a subclass of java.io.Serializable .
Fortunately all advantages of Java also work with Java RMI:
In addition, it should be noted that certain security restrictions might apply, if Java RMI is used in applets.
Please have a look at Sun's Java RMI documentation for further information.