 |
Explain RMI Architecture?
|
RMI uses a layered architecture,
each of the layers could be enhanced or replaced without affecting the
rest of the system. The details of layers can be summarised as follows:
Application Layer: The client and server program
Stub & Skeleton Layer: Intercepts method calls made by the
client/redirects these calls to a remote RMI service.
Remote Reference Layer: Understands how to interpret and manage
references made from clients to the remote service objects.
Transport layer: Based on TCP/IP connections between machines in a
network. It provides basic connectivity, as well as some firewall
penetration strategies.
|
Explain
about RMI and it's usage
|
RMI is one of the distributed
computing technology alternative powered by Java . RMI stands for
Remote Method Invocation ,to keep it simple it means accessing a
service from different node ( i.e., accessing a service provided by an
object on server machine , here an object in client JVM talks with
object in the server JVM ). Java provides an API and base some classes
( in package java.rmi ) to perform these kind of operations
.
We basically use this methodology when we need to publish an object at
server side which exposes set of services ( as methods in Object
oriented programming terminology ) and where in one or more clients
access these services from remote machines. By this we are distibuting
a common code in two different JVM's and we are able to access the code
on different JVM.
|
How
do RMI clients contact remote RMI servers?
|
For an RMI client to contact a
remote RMI server, the client must first hold a reference to the
server. The Naming.lookup method call is the most common mechanism by
which clients initially obtain references to remote servers. Remote
references may be obtained by other means, for example: all remote
method calls can return remote references. This is what Naming.lookup
does; it uses a well-known stub to make a remote method call to the
rmiregistry, which sends back the remote reference to the object
requested by the lookup method.
Every remote reference contains a server hostname and port number that
allow clients to locate the VM that is serving a particular remote
object. Once an RMI client has a remote reference, the client will use
the hostname and port provided in the reference to open a socket
connection to the remote server.
Please note that with RMI the terms client and server can refer to the
same program. A Java program that acts as an RMI server contains an
exported remote object. An RMI client is a program that invokes one or
more methods on a remote object in another virtual machine. If a VM
performs both of these functions, it may be referred to as an RMI
client and an RMI server.
|
Why
do I get the exception "java.net.SocketException: Address already in
use" when I try to run the registry?
|
This exception means that the
port that the RegistryImpl uses (by default 1099) is already in use.
You may have another registry running on your machine and will need to
stop it.
|
How
can I make outgoing RMI calls through a local firewall?
|
There are three main methods:
HTTP tunnelling, SOCKS, and downloaded socket factories.
HTTP tunnelling
This well-worn method is popular since it requires almost no setup, and
works quite well in firewalled environments which permit you to handle
HTTP through a proxy, but disallow regular outbound TCP connections.
If RMI fails to make a normal (or SOCKS) connection to the intended
server, and it notices that a HTTP proxy server is configured, it will
attempt to tunnel RMI requests through that proxy server, one at a
time.
There are two forms of HTTP tunnelling, tried in order. The first is
http-to-port; the second is http-to-cgi.
In http-to-port tunneling, RMI attempts a HTTP POST request to a http:
URL directed at the exact hostname and port number of the target
server. The HTTP request contains a single RMI request. If the HTTP
proxy accepts this URL, it will forward the POST request to the
listening RMI server, which will recognize the request and unwrap it.
The result of the call is wrapped in a HTTP reply, which is returned
through the same proxy.
Often, HTTP proxies will refuse to proxy requests to unusual port
numbers. In this case, RMI will fall back to http-to-cgi tunneling. The
RMI request is encapsulated in a HTTP POST request as before, but the
request URL is of the form
http://hostname:80/cgi-bin/java-rmi.cgi?port=n (where hostname and n
are the hostname and port number of the intended server). There must be
a HTTP server listening on port 80 on the server host, which will run
the java-rmi.cgi script (supplied with the JDK), which will in turn
forward the request to an RMI server listening on port n. RMI can
unwrap a HTTP-tunneled request without help from a http server, CGI
script, or any other external entity. So, if the client's HTTP proxy
can connect directly to the server's port, then you don't need a
java-rmi.cgi script at all.
To trigger the use of HTTP tunneling, the standard system property
http.proxyHost must be set to the hostname of the local HTTP proxy.
(There are reports that some Navigator versions do not set this
property.)
The major disadvantage of HTTP tunneling is that it does not permit
inward calls or multiplexed connections. A secondary disadvantage is
that the http-to-cgi method opens a dramatic security hole on the
server side, since without modification it will redirect any incoming
request to any port.
SOCKS
The default implementation of sockets in the JDK will use a SOCKS
server if available and configured. The system property socksProxyHost
must have been set to the hostname of the SOCKS server; if the port
number of the SOCKS server is not 1080, it must be specified in the
socksProxyPort property.
This approach would appear to be the most generally useful solution. As
yet, ServerSockets do not use SOCKS, so incoming calls must use another
mechanism.
Downloaded socket factories
This is an innovation in the Java 2 SDK, allowing the server to specify
the socket factory that the clients must use. The clients must be
running Java 2 SDK, Standard Edition, v1.2 or later. See the tutorial
Using a Custom RMI Socket Factory for details.
The disadvantage of this approach is that the traversal of the firewall
must be done by code provided by the RMI server side, which does not
necessarily know how that traversal must be done, nor does it
automatically have sufficient privilege to traverse the firewall.
|
How
can I receive incoming RMI calls through a local firewall?
|
There are three main methods:
known ports, transport-level bridges, and application-level proxies.
Known Ports
If the exported objects are all exported on a known port on a known
host, then that host and port can be explicitly permitted at the
firewall. Normally, RMI asks for port 0 (which is code for "any port").
In the Java 2 SDK, there is an extra argument to the exportObject
method to specify the exact port number. In JDK v1.1, the server must
subclass the RMISocketFactory and intercept requests to
createServerSocket(0), replacing it with a request to bind to a
specific port number.
This approach has the disadvantage that it requires the assistance of
the network administrator responsible for the local firewall. If the
exported object is being run in a different location (because code was
downloaded to that site), then the local firewall may be run by network
administrators who don't know who you are.
Transport-level bridges
A transport-level bridge is a program that reads bytes from one TCP
connection and writes them to another (and vice versa) without knowing
or caring what the bytes represent.
The idea here is to export objects in such a way that anyone outside
the firewall who wants to call remote methods on that object instead
contacts a different port (perhaps on a different machine). That
different port has a running program which makes a second connection to
the real server and then pumps bytes each way.
The tricky part is convincing the client to connect to the bridge. A
downloadable socket factory (Java 2 SDK, v1.2 or later) can do this
efficiently; otherwise, it is possible to set the
java.rmi.server.hostname property to name the bridge host and arrange
for port numbers to be the same.
Application-level proxies
This approach is quite a bit of work, but leads to a very secure
arrangement. A proxy program runs on a firewall host (one which can be
accessed from outside as well as inside). When an internal server
intends to make an exported object available to the world, it contacts
the proxy server and gives it a remote reference. The proxy server
creates a proxy object (a new remote object residing in the proxy
server) which implements the same remote interfaces as the original.
The proxy server returns a remote reference for the new proxy object to
the internal server, which communicates it to the outside world
(somehow).
When an outsider makes a call on the proxy, the proxy immediately
forwards the call to its original object on the internal server. The
use of the proxy is transparent to the outsider (but not to the
internal server, who has to decide whether to pass the original
reference or the proxy reference when talking to anyone).
Needless to say, this requires considerable setup and the cooperation
of the local network administrators.
|
|
|
Does
RMI handle "out" and "inout" parameters (like CORBA)?
|
RMI does not support "out" or
"inout" parameters, just like the rest of the core Java programming
language. All remote calls are methods of a remote object. Local
objects are passed by copy and remote objects are passed by reference
to a stub.
|
Normally
in the Java programming language, it is possible to cast an interface
instance to an instance of the class from which it was created and use
the result. Why doesn't this work in RMI?
|
In RMI the client sees only a
stub for the original object. The stub implements only the remote
interfaces and their remote methods and cannot be cast back to the
original implementation class because it's just a stub.
So, you cannot pass a remote object reference from a server to a
client, and then send it back to the server and be able to cast it back
to the original implementation class. You can, though, use the remote
object reference on the server to make a remote call to the object.
If you need to find the implementation class again, you'll need to keep
a table that maps the remote reference to the implementation class.
|
What
is the difference between RMI & Corba ?
|
The most significant difference
between RMI and CORBA is that CORBA was made specifically for
interoperability across programming languages. That is CORBA fosters
the notion that programs can be built to interact in multiple
languages. The server could be written in C++, the business logic in
Python, and the front-end written in COBOL in theory. RMI, on the other
hand is a total Java solution, the interfaces, the implementations and
the clients--all are written in Java.
RMI allows dynamic loading of classes at runtime. In a multi-language
CORBA environment, dynamic class loading is not possible. The important
advantage to dynamic class loading is that it allows arguments to be
passed in remote invocations that are subtypes of the declared types.
In CORBA, all types have to be known in advance. RMI (as well as
RMI/IIOP) provides support for polymorphic parameter passing, whereas
strict CORBA does not. CORBA does have support for multiple languages
which is good for some applications, but RMI has the advantage of being
dynamic, which is good for other applications.
|
What
are the services in RMI ?
|
An RMI "service" could well be
any Java method that can be invoked remotely. The other service is the
JRMP RMI naming service which is a lookup service.
|
Does
RMI-IIOP support code downloading for Java objects sent by value across
an IIOP connection in the same way as RMI does across a JRMP connection?
|
Yes. The JDK 1.2 and above
support the dynamic class loading.
|
How
many types of protocol implementations does RMI have?
|
RMI has at least three protocol
implementations: Java Remote Method Protocol(JRMP), Internet Inter ORB
Protocol(IIOP), and Jini Extensible Remote Invocation(JERI). These are
alternatives, not part of the same thing, All three are indeed layer 6
protocols for those who are still speaking OSI reference model.
|
Does
RMI-IIOP support dynamic downloading of classes?
|
No, RMI-IIOP doesn't support
dynamic downloading of the classes as it is done with CORBA in DII
(Dynamic Interface Invocation).Actually RMI-IIOP combines the usability
of Java Remote Method Invocation (RMI) with the interoperability of the
Internet Inter-ORB Protocol (IIOP).So in order to attain this
interoperability between RMI and CORBA,some of the features that are
supported by RMI but not CORBA and vice versa are eliminated from the
RMI-IIOP specification.
|
Can
RMI and Corba based applications interact ?
|
Yes they can. RMI is available
with IIOP as the transport protocol instead of JRMP
|
Explain
lazy activation
|
Lazy activation of remote
objects is implemented using a faulting remote reference (sometimes
referred to as a fault block). A faulting remote reference to a remote
object "faults in" the active object's reference upon the first method
invocation to the object. Each faulting reference maintains both a
persistent handle (an activation identifier) and a transient remote
reference to the target remote object. The remote object's activation
identifier contains enough information to engage a third party in
activating the object. The transient reference is the actual "live"
reference to the active remote object that can be used to contact the
executing object.
In a faulting reference, if the live reference to a remote object is
null, the target object is not known to be active. Upon method
invocation, the faulting reference (for that object) engages in the
activation protocol to obtain a "live" reference, which is a remote
reference (such as a unicast remote reference) for the newly-activated
object. Once the faulting reference obtains the live reference, the
faulting reference forwards method invocations to the underlying remote
reference which, in turn, forwards the method invocation to the remote
object.
In more concrete terms, a remote object's stub contains a "faulting"
remote reference type that contains both:
an activation identifier for a remote object, and
a "live" reference (possibly null) containing the "active" remote
reference type of the remote object (for example, a remote reference
type with unicast semantics).
|
Why
does the RMI implementation create so many sockets when my application
uses custom socket factories; or why are stubs (using a custom socket
factory) that refer to the same remote object not equal; or why does
the RMI implementation not reuse server-side ports when I use a custom
server socket factory?
|
The RMI implementation attempts
to reuse open sockets where possible for remote invocations. When a
remote method is invoked on a stub that uses a custom socket factory,
the RMI implementation will reuse an open connection (if any) as long
as that socket was created by an equivalent socket factory. Since
client socket factories are serialized to clients, a single client may
have several distinct copies of the same logical socket factory. To
ensure that the RMI implementation will reuse sockets created by custom
socket factories, make sure your custom client socket factory classes
implement the hashCode and equals methods appropriately. If the client
socket factory does not implement these methods correctly, another
ramification is that stubs (using the client socket factory) that refer
to the same remote object will not be equal.
The RMI implementation attempts to reuse server-side ports as well. It
will only do so if there is an existing server socket for the port
created by an equivalent socket factory. Make sure the server socket
factory class implements the hashCode and equals methods too.
If your socket factory has no instance state, a trivial implementation
of the hashCode and equals methods are the following:
public int hashCode() { return 57;
}
public boolean equals(Object o) { return
this.getClass() == o.getClass() }
|
What
is difference RMI registry and OSAgent ?
|
RMI
Registry
The rmiregistry command creates and starts a remote object registry on
the specified port on the current host. If port is omitted, the
registry is started on port 1099. The rmiregistry command produces no
output and is typically run in the background. For example:
start rmiregistry
A remote object registry is a bootstrap naming service that is used by
RMI servers on the same host to bind remote objects to names. Clients
on local and remote hosts can then look up remote objects and make
remote method invocations.
The registry is typically used to locate the first remote object on
which an application needs to invoke methods. That object in turn will
provide application-specific support for finding other objects.
The methods of the java.rmi.registry.LocateRegistry class are used to
get a registry operating on the local host or local host and port.
The URL-based methods of the java.rmi.Naming class operate on a
registry and can be used to look up a remote object on any host, and on
the local host: bind a simple (string) name to a remote object, rebind
a new name to a remote object (overriding the old binding), unbind a
remote object, and list the URLs bound in the registry.
OSAgent
The osagent is a process that allows CORBA servers to register their
objects and assists client applications in the location of objects. To
avoid a single point of failure, the osagent is designed to be operated
on more than one node. Osagent processes (and the clients and servers
that access them) follow a set of rules to discover each other and
cooperate in the location of registered objects.
|
Difference
in between Unicast and Multicast object ?
|
A unicast packet is the complete
opposite: one machine is talking to only one other machine. All TCP
connections are unicast, since they can only have one destination host
for each source host. UDP packets are almost always unicast too, though
they can be sent to the broadcast address so that they reach every
single machine in some cases.
A multicast packet is from one machine to one or more. The difference
between a multicast packet and a broadcast packet is that hosts
receiving multicast packets can be on different lans, and that each
multicast data-stream is only transmitted between networks once, not
once per machine on the remote network. Rather than each machine
connecting to a video server, the multicast data is streamed
per-network, and multiple machines just listen-in on the multicast data
once it's on the network.
|
What
is the main functionality of the Remote Reference Layer ?
|
RRL exists in both the RMI
client and server. It is used by the stub or skeleton protocol layer
and uses the transport layer. RRL is reponsible for
transport-independent functioning of RMI, such as connection management
or unicast/multicast object invocation.
|
|
|
|
|
