Remote method invocation allows applications to call
object methods located remotely, sharing resources and processing load across systems.
Unlike other systems for remote execution which require that only simple data types or
defined structures be passed to and from methods, RMI allows any Java object type to be
used - even if the client or server has never encountered it before. RMI allows both
client and server to dynamically load new object types as required.
RMI uses stub and skeleton object for communication with the remote object.
A remote object is an object whose method can be invoked from another JVM. JVMs can be located on separate computers - yet one JVM can invoke
methods belonging to an object stored in another JVM. Methods can even pass objects that a
foreign virtual machine has never encountered before, allowing dynamic loading of new
classes as required. This is a powerful feature! Let's understand the stub and skeleton objects:
stub
The stub is an object, acts as a gateway for the client side. All the
outgoing requests are routed through it. It resides at the client side
and represents the remote object. When the caller invokes method on the
stub object, it does the following tasks:
- It initiates a connection with remote Virtual Machine (JVM),
- It writes and transmits (marshals) the parameters to the remote Virtual Machine (JVM),
- It waits for the result
- It reads (unmarshals) the return value or exception, and
- It finally, returns the value to the caller.
skeleton
The skeleton is an object, acts as a gateway for the server side
object. All the incoming requests are routed through it. When the
skeleton receives the incoming request, it does the following tasks:
- It reads the parameter for the remote method
- It invokes the method on the actual remote object, and
- It writes and transmits (marshals) the result to the caller.
Consider the follow scenario :
- Developer A writes a service that performs some useful function. He regularly updates this service, adding new features and improving existing ones.
- Developer B wishes to use the service provided by Developer A. However, it's inconvenient for A to supply B with an update every time.
Java RMI provides a very easy solution! Since RMI can dynamically load new classes, Developer B can let RMI handle updates automatically for him. Developer A places the new classes in a web directory, where RMI can fetch the new updates as they are required.
Firstly, the client must contact an RMI registry, and request the name of the service. Developer B won't know the exact location of the RMI service, but he knows enough to contact Developer A's registry. This will point him in the direction of the service he wants to call..
Developer A's service changes regularly, so Developer B doesn't have a copy of the class. Not to worry, because the client automatically fetches the new subclass from a webserver where the two developers share classes. The new class is loaded into memory, and the client is ready to use the new class. This happens transparently for Developer B - no extra code need to be written to fetch the class.
References
No comments:
Post a Comment