Concept of Marshalling and Un-marshalling

Marshaling is process of encoding object to put them on the network (on one end) (and then Unmarshal the object to decode the object and place it in the address space on the other end).

In distibuted environment, while sending the object from client to server side, the object is marshelled on stun side , sent across the network and on skeleton side its unmarshelled (given to server for necessory processing).

Once the processing is done by server the response object is marshelled by the skeleton , sent across the network to the client and hece to stub and again unmarshelled and given to client.

So basically marshelling is encrypting phenomenon while transeferring the object on network.


Serialization is process of breaking the object(to be sent across network) into form that can be sent across the network (that is converting it into to a sequence of bytes).

Necessarily, before sending the object across network , it must be serialized.

And Marshelling is next step of sending the encrypted object(which is serialized) across the network.

RMI uses a standard mechanism (employed in RPC systems) for communicating with remote objects: stubs and skeletons. A stub for a remote object acts as a client's local representative or proxy for the remote object. The caller invokes a method on the local stub which is responsible for carrying out the method call on the remote object. In RMI, a stub for a remote object implements the same set of remote interfaces that a remote object implements.
When a stub's method is invoked, it does the following:

* initiates a connection with the remote JVM containing the remote object,
* marshals (writes and transmits) the parameters to the remote JVM,
* waits for the result of the method invocation,
* unmarshals (reads) the return value or exception returned, and
* returns the value to the caller.

The stub hides the serialization of parameters and the network-level communication in order to present a simple invocation mechanism to the caller.
In the remote JVM, each remote object may have a corresponding skeleton (in Java 2 platform-only environments, skeletons are not required). The skeleton is responsible for dispatching the call to the actual remote object implementation. When a skeleton receives an incoming method invocation it does the following:

* unmarshals (reads) the parameters for the remote method,
* invokes the method on the actual remote object implementation, and
* marshals (writes and transmits) the result (return value or exception) to the caller.

In the Java 2 SDK, Standard Edition, v1.2 an additional stub protocol was introduced that eliminates the need for skeletons in Java 2 platform-only environments. Instead, generic code is used to carry out the duties performed by skeletons in JDK1.1. Stubs and skeletons are generated by the rmic compiler.