Message:
Jini versus CORBA
Posted by Bill Venners on August 11, 1999 at 7:10 PM
> It is probably my lack of understanding of the JINI technology,
> but I am finding it hard to figure out what JINI gives you that
> CORBA doesn't already have ? It just so happens that I wrote a FAQ entry last week that I
think should answer your question. I haven't had a chance to
put it up on the FAQ, but it did go out last week in the Jini
Advisor newsletter. Here it is: 1. What is the difference between Jini and CORBA? CORBA is perhaps more akin to RMI than Jini, but CORBA includes a
service called the trader service that is somewhat reminiscent of the
Jini lookup service. CORBA, which stands for Common Object Request
Broker Architecture, enables you to invoke methods on remote objects
written in any programming language. RMI, which stands for Remote
Method Invocation, enables you to invoke methods on Java objects in
remote virtual machines. The objects needn't have been written in
the Java programming language, but they do need to be running in a
Java virtual machine. Thus, they most likely were written in some
language that was compiled to Java class files, and by far the most
common language compiled to Java class files is Java. CORBA has a naming service that lets you look up a remote object by
name and obtain a remote reference to it. RMI has a registry server
that let you do the same thing: look up a remote object by name and
obtain a remote reference to it. CORBA departs from RMI, however, in
that to use the remote reference by invoking methods on a local stub,
CORBA requires that the client have the definition of the stub
locally. (In other words, CORBA requires that the code for the
stub object be known to the developers that create the client.) RMI,
by contrast, can send the class files for a stub object across the
wire. Because an RMI client can dynamically load the code for a stub
object, that code need not be known to the developers of the client.) CORBA does offer a "dynamic invocation interface" that enables clients
to use remote objects without the stub definition, but it is more
complex to use than just invoking methods on a local stub. The
difference in complexity is similar to the difference between using
a Java object through its interface and using the same Java object
via the reflection API. Another difference between CORBA and RMI is that RMI lets you pass
objects by value as well as by reference when you invoke a remote
method. Up until the CORBA/IIOP 2.2 specification was released in
1998, CORBA only allowed you to pass objects by reference. The 2.2
specification added support for objects by value, but this
functionality yet may not be supported in many CORBA implementations. A significant difference between CORBA and RMI is that when a subclass
object is passed to a remote method by value, CORBA will truncate
the object to the type declared in the method parameter list. For
example, if a CORBA remote method expects an Animal and the client
passes a Dog (a subclass of Animal), the remote object will receive
an Animal (a truncated Dog), not a Dog. Because RMI can send the
class files for the Dog across the network, the RMI remote object
will receive a Dog. If the remote virtual machine has no idea what
a Dog is, it will pull the class file for Dog down across the
network. As mentioned previously, CORBA does include one service that is
reminescent of Jini's lookup service: the CORBA trader service.
Instead of just supplying a name with which a remote object is
associated, as you do with the CORBA naming service (or the RMI
registry), you describe the type of remote object you are seeking.
Similarly, you can look up a Jini service by type. The Jini lookup
service offers a bit more flexibility in searching, however, because
you can also search by a globally unique service ID and by
attributes. But the most important difference between the CORBA
trader service and the Jini lookup service lies in what they return
as a result of the query. The CORBA trader service returns a remote
reference to a matching remote object. The Jini lookup service
returns a proxy object by value. Thus, when you get a remote reference back from the CORBA trader
service (assuming you have the stub definition), you can talk to
the remote object by invoking methods on the local stub. The local
stub will talk across the network to the remote object via CORBA.
When you talk to a Jini service object, on the other hand, that
service object may not talk across the network at all. It may
implement the service in its entirety locally in the client's
virtual machine. Or, it may talk across the network to a server,
servers, or some hardware via sockets and streams. Or, the service
object may actually be an RMI stub that communicates across the
network to a remote RMI object via the RMI wire protocol. The
service object returned by Jini can use any network protocol to
communicate across the network. It could even use CORBA. bv
Replies:
|
