: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in
The Java allows us to develop distributed applications using RMI. Distributed computing refers to the
application design paradigm in which programs, the data they process, and the actual computations are spread
over a network either to leverage the processing power of multiple computers or due to the inherent nature of an
application computing different modules.
RMI (Remote method Invocation) allows object-o-object communication between different Java Virtual
JVMs can be distinct entities located on the same or separate computers –yet one JVM can invoke methods
belonging to an object stored on another JVM. This enables applications to call object methods located
remotely, sharing resources, and processing load across systems. Methods can even pass objects that a foreign
virtual machine has never encountered before, allowing the dynamic loading of new classes as required. This is
really a quite powerful feature.
Other Alternatives to RMI:
Basic network programming with sockets is flexible and sufficient for communication between programs.
However, it requires all the involved parties to communicate via application-level protocols, the design of
which is complex and can be error prone. For example, consider a collaborative application like a simple chat
application for instance: for multiple clients to participate we would first need to design some sort of protocol,
and then use sockets to communicate in that protocol with the server. RMI, on the other hand, is a distributed
system that internally uses sockets over TCP/IP.
RMI’s purpose is to make objects in separate JVM’s look alike and act like local objects. The JVM that calls the
remote object is usually referred to as a client and the JVM that contains the remote object is the server.
One of the most important aspects of the RMI design is its intended transparency. Applications do not know
whether an object is remote or local. A method invocation on the remote object has the same syntax as a method
invocation on a local object, though under the hood there is a lot more going on.
• In RMI the term “Server” does not refers to a physical server or application but to a single remote objecthaving methods that can be remotely invoked.Similarly the Term “Client” does not refer to a client m/c but actually refers to the object invoking a remote method on a remote object.
• The same object can be both a client and a server.
Although obtaining a reference to a remote object is somewhat different from doing so for local objects. Once
we have the reference, we use the remote object as if it were local. The RMI infrastructure will automatically
intercept the method call, find the remote object and process the request remotely. This location transparency
even includes garbage collection.
A remote object is always accessed via its remote interface. In other words the client invokes methods on the
object only after casting the reference to the remote interface.
The RMI implementation is essentially built from three abstraction layers:
• The Stub/Skeleton Layer
• The Remote Reference Layer
•The Transport Layer
The following diagram shows the RMI Architecture:The Stub/Skeleton Layer
This layer intercepts method calls made by the client to the interface reference and redirects these calls to a
remote object. Stubs are specific to the client side, whereas skeletons are found on the server side.
To achieve location transparency, RMI introduces two special kinds of objects known as stubs and skeletons
that serve as an interface between an application and rest of the RMI system. This Layer’s purpose is to transfer
data to the Remote Reference Layer via marshalling and unmarshalling. Marshalling refers to the process of
converting the data or object being transferred into a byte stream and unmarshalling is the reverse - converting
the stream into an object or data. This conversion is achieved via object serialization.
The Stub/ Skeleton layer of the RMI lies just below the actual application and is based on the proxy design
pattern. In the RMI use of the proxy pattern, the stub class plays the role of the proxy for the remote service
implementation. The skeleton is a helper class that is generated by RMI to help the object communicate with the
stub; it reads the parameters for the method call from the link, makes the call to the remote service
implementation object, accepts the return value and then writes the return value back to the stub.
In short, the proxy pattern forces method calls to occur through a proxy that acts as a surrogate, delegating all
calls to the actual object in a manner transparent to the original caller.Stub
The stub is a client-side object that represents (or acts as a proxy for) the remote object. The stub has the same
interface, or list of methods, as the remote object. However when the client calls a stub method, the stub
forwards the request via the RMI infrastructure to the remote object (via the skeleton), which actually executes
it.Sequence of events performed by the stub:
• Initiates a connection with the remote VM containing the remote object
• Marshals (writes and transmits) the parameters to the remote VM.
• Waits for the result of the method invocation.
• Unmarshals (reads) the return value or exception returned.
• Return the value to the caller
In the remote VM, each remote object may have a corresponding skeleton.Skeleton
On the server side, the skeleton object takes care of all the details of “remoteness” so that the actual remote
object does not need to worry about them. In other words we can pretty much code a remote object the same
way as if it were local; the skeleton insulates the remote object from the RMI infrastructure.Sequence of events performed by the skeleton:
• Unmarshals (reads) the parameters for the remote method (remember that these were marshaled by the stub
on the client side)
• Invokes the method on the actual remote object implementation.
• Marshals (writes and transmits) the result (return value or exception) to the caller (which is then
unmarshalled by the stub)The Remote Reference Layer
The remote reference layer defines and supports the invocation semantics of the RMI connection. This layer
maintains the session during the method call.
The Transport Layer
The Transport layer makes the stream-based network connections over TCP/IP between the JVMs, and is
responsible for setting and managing those connections. Even if two JVMs are running on the same physical
computer, they connect through their host computers TCP/IP network protocol stack. RMI uses a protocol
called JRMP (Java Remote Method Protocol) on top of TCP/IP (an analogy is HTTP over TCP/IP).
From the JDK 1.2 the JRMP protocol was modified to eliminate the need for skeletons and instead use
reflection to make connections to the remote services objects. Thus we only need to generate stub classes in
system implementation compatible with jdk 1.2 and above. To generate stubs we use the Version 1.2 option
The RMI transport layer is designed to make a connection between clients and server, even in the face of
networking obstacles. The transport layer in the current RMI implementation is TCP-based, but again a UDPbased
transport layer could be substituted in a different implementation.