Message Passing and Remote Procedure Call

• rmi-coding.html
• http://java.sun.com/docs/books/tutorial/rmi/index.html
• http://carpanta.dc.fi.udc.es/docs/java-courses/sdsu/www.eli.sdsu.edu/courses/spring99/cs696/notes/rmiIntro/rmiIntro.html

Purpose:  To enable processes on different machines to cooporate to solve a common problem.

Message Passing Basics

Generally there are two types of primatives: send(message, to) and receive(message, from).
Receive can be blocking,  non-blocking, and often you get both choices.
Send can be blocking, buffered, non-blocking, or any combination.

Messages can be though of as being sent via channels (or to addresses).  Some designs allow multiple receives.  If so, you must ask the question if only one receiver gets a message (best for simple quetries, like HTTP) , or all receives get a message (best for shutdown messages, etc.).

Finally, some systems package the whole thing up to look like a RPC.  This gets implemented via blocking sends/receives, and some marshalling.  Generally speaking RPC is less flexible than message passing, but easier for the programmer.  And normally saving programmer time is more impartant than saving execution time (normally).

Marshalling is the act of bundling up all the parameters to a procedure call into one message, and then unbundling them on return.  Generally speaking this is difficult but doable.  If a procedure wants to send 3 ints, it can send the 12 bytes.  If another procedure wants to send 3 floats, it can also send 12 bytes.  The receiver needs to know how to decode these 12 bytes.  Normally this is done by having each function (name, signature) map to an integer, and prepending this int onto the message.  But how can you handle default parameters?  And what about pointers?  The Java answer is to use the Serializable inteface.

Generally speaking, this is how it all works.
The server creates some objects, and tells the registry about them.
The server creates skels for those objects, and those skels begin lisstening for requests.
The client asks the registry where to find the objects and is told the server's address
The client creates stubs for each remote object found, and these stubs ask the skels to ask the server to preform some operations on the clients behalf. 
The objects can live beyond their use by any one client.
The server can accept bytecode that manipulates objects for the client.  That's a Java Unique Advantage (tm).

A method might receive as an argument a object type it's never heard of before.  How:  inheritence.
Nevertheless, the receiver will need to use the methods associated with that object, so will need the code that implements those methods.  Since Java bytecode is portable, this can be done.  But think of the marshalling headaches.  And think of the security risks!

A local object is an object just like we had in CS120.  When a local object is sent to a receiving JVM, the JVM gets a copy of the whole object and any needed bytecode as described above.  When a remote-able object gets sent to a receiving JVM, the JVM just gets a stub, and all operations on the remote object are sent via the stub to the objects original location.

An object becomes remote-able implementing remote interfaces.  Only methods defined in remote interfaces can be called remotely.  Remote interfaces are created by

• A remote interface extends the interface java.rmi.Remote.
• Each method of the interface declares java.rmi.RemoteException in its throws clause, in addition to any application-specific exceptions.

Remote objects should

• Declare the remote interfaces being implemented
• Define the constructor for the remote object
• Provide an implementation for each remote method in the remote interfaces

Arguments to or return values from remote methods can be of almost any type, including local objects, remote objects, and primitive types. More precisely, any entity of any type can be passed to or from a remote method as long as the entity is an instance of a type that is a primitive data type, a remote object, or a serializable object, which means that it implements the interface java.io.Serializable.

A few object types do not meet any of these criteria and thus cannot be passed to or returned from a remote method. Most of these objects, such as a file descriptor, encapsulate information that makes sense only within a single address space. Many of the core classes, including those in the packages java.lang and java.util, implement the Serializable interface.

The rules governing how arguments and return values are passed are as follows.

• Remote objects are essentially passed by reference. A remote object reference is a stub, which is a client-side proxy that implements the complete set of remote interfaces that the remote object implements.
• Local objects are passed by copy, using object serialization. By default all fields are copied, except those that are marked static or transient. Default serialization behavior can be overridden on a class-by-class basis.
• Passing an object by reference (as is done with remote objects) means that any changes made to the state of the object by remote method calls are reflected in the original remote object. When passing a remote object, only those interfaces that are remote interfaces are available to the receiver; any methods defined in the implementation class or defined in nonremote interfaces implemented by the class are not available to that receiver.