: 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.
Clients find remote services by using a naming or directory service. A naming or directory service is run on a
host and port number that the client is already aware of (for example a well-known port on a public host).
The RMI naming service, a registry, is a remote object that serves as a directory service for clients by keeping a
hash table like mapping of names to other remote objects. It is not necessary to have a single registry on a
particular physical host. An object is free to start its own registry. The behavior of the registry is defined by the
. RMI itself includes a simple implementation of this interface
called the RMI Registry. RMI Registry runs on each machine that hosts remote objects and accepts queries for
services, by default on port 1099.
In Simple terms, a remote object is associated with a name in the registry. Any time the client wants to invoke
methods on this remote object it obtains a reference to it by looking up the name. The lookup returns a remote
reference, a stub to the object.
RMI also provides the java.rmi.Naming
class that serves as the client’s interaction point with the object
serving as the registry on the host for this lookup. This can be thought of as a client of the RMI Registry.
The naming class’s methods take, as one of their arguments, a name that is a URL-formattedjava.lang.String
The following diagram shows how the client uses the java.rmi.Naming
class to lookup the stub/proxy of the
The program which creates the instance of the remote object also makes use of the java.rmi.Naming class to
bind the remote object to the RMI Registry.The java.rmi.Naming class
This class behaves as a client to the RMI Registry. It is used on the server side as well as on the client side to
interact with the RMI Registry. On the server side it is used to bind the remote object to the RMI Registry. On
the client side it is used to lookup the remote object.MethodsAll the methods of this class are static.
• public static void bind (String name, Remote obj)
It binds the remote object to a string name. The name itself is in the RMI URL format.
• public static Remote lookup (String name)
It returns a reference, a stub, for the remote object associated with the specified name.
• public static void rebind (String name, Remote obj)
It rebinds (unbinds the name if it is already bound and binds it again) the specified name if it already in use
to a new remote object. This could be dangerous if different applications use the same name in the registry
but is helpful in development.
• public static void unbind (String name)
It removes the binding with specified name.
Once the client has a stub to the requested object, it can access the remote method transparently, just like local
The URL takes the form:
is a name recognized on the local area network (LAN) or a DNS name on the Internet.
needs to be specified only if the naming service is running on a port other than the default 1099
is the string name that the remote object is associated with in the registry.