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).
No comments:
Post a Comment