by Prithvi Rao
Prithvi Rao is the founder of Kiwilabs, which specializes in software
engineering methodology and Java training. He has worked on the
development of the MACH OS and a real-time version of MACH, and he
holds two patents resulting from his work on mobile robots.
Java RMI, CORBA or COM?
Java has been adding new packages to each release, and the JDK1.2beta3 release is no exception.
Most of the time the introduction of new packages is driven by the need to fill a gap. Some examples of packages that were not in the core release of the 1.0 release but were introduced later are JDBC, security, beans, and Remote Method Invocation (RMI).
The inclusion of CORBA (Common Object Request Broker Architecture) services in this release raises some pertinent questions such as "Should I use RMI?" "When should I use CORBA with Java?" "Should I use DCOM (Distributed Component Object Model) instead of RMI or CORBA?"
The answer to these and other related questions is not simple; however, we can ease that burden by knowing more about each of these technologies so we can make intelligent decisions based on what we know. The JDK1.1 release supported RMI, so there was no compelling reason to package CORBA and give it away for free. Or was there?
It is likely that Sun and OMG (Object Management Group, consisting of over 800 companies) had many discussions before this decision was made, and ultimately it does not matter why this decision was made. What does matter is which technology the user endorses.
This article provides a taxonomy of the "good," the "bad," and the "ugly" of CORBA, RMI, and DCOM. Although DCOM is a Microsoft product and currently is unavailable for UNIX platforms, some vendors have announced plans to support DCOM under Solaris, HP-UX, and Irix (and I would not be surprised if Linux support shows up shortly thereafter).
Traditional approaches to executing code residing on machines across a network have been confusing as well as tedious and error-prone to implement.
A useful way to look at this problem is that some objects reside on a machine across a network, and you can invoke methods on that object by sending messages to that object and have it return results as though it were running on your local machine.
The main goal of all three technologies is to provide an infrastructure to enable writing distributed applications with relative ease, although they do so in different ways.
In summary, Java RMI comes from JavaSoft, CORBA is a specification resulting from the OMG, and DCOM comes from Microsoft Corporation.
It is no secret that the CORBA specification is in response to Microsoft's COM and DCOM technology. Given that all of these technologies can be used on both UNIX platforms, we are faced with the dilemma stated previously, namely, "Which technology do we use?"
All of these technologies are similar insofar as they have some kind of registry for registering objects and use an interface definition language to generate stubs for the client code. I am not going to go into the details.
Remote invocation is nothing new. For instance, C programmers have used RPC (Remote Procedure Call) semantics to execute a C function on a remote host. What makes RMI different is that in Java it is necessary to package both data and methods and ship both across the network (RPC works on data structures primarily), and the recipient must be able to interpret the object after receiving it.
JavaSoft has announced that it will be making efforts to integrate RMI and CORBA but it is not clear what this really means.
So let's take a quick look at RMI.
The Common Object Request Broker Architecture is probably the most ambitious and important middleware project ever undertaken in the industry. The OMG consortium (Sun was one of the founding companies) represents a broad spectrum of the computing industry (with the notable exception of Microsoft).
The following is a summary of CORBA.
The Distributed Component Object Model is Microsoft's solution for supporting distributed computing with objects. Another way of looking at it is the DCOM is the foundation for Microsoft's Internet and component strategy. For instance, an ActiveX control is a DCOM object. The VJ++ package includes language bindings for DCOM. In fact, Microsoft is serious about distributed Java objects, but its solution is not based on the JavaSoft RMI/CORBA model. Instead, it is pushing for DCOM to be the alternative for its distributed Java.
The following are the salient points of DCOM.
What Does This All Mean?
Now that we have all this good stuff out in the open, what does it all mean? In order to do justice to that question, it is necessary to understand the way component-based system architectures using Java are being developed.
One key consideration is to create an evolvable systems architecture. This means that, by definition, the architecture will have to deal with legacy code for obvious reasons of reliability, high development cost, and other important considerations.
One important issue is running the same code on as many platforms as possible. If the requirement is that no recompilation should be required when moving applications to various platforms, then the Java/CORBA solution may be more appropriate then DCOM.
If the application requires interaction with DCOM objects, then, although it may still be reasonable to use Java and CORBA with a bridge technology to interface with DCOM, it may be a better choice to go with a pure DCOM solution.
If you anticipate that your distributed application is going to be written entirely in Java (for rapid prototyping, perhaps), then it is probably a good idea to use RMI for its ease of programming.
It may be necessary to plug in components created by third parties. These components may be based around a DCOM or CORBA interface.
The systems architect is faced with many challenges in defining an evolvable system. The architecture will need to support both short- and long-term goals in the absence of precise information.
The choice of hardware platform can be almost a trivial decision because it may be driven by cost. The software choices are somewhat more perplexing and critical. The hidden cost of maintaining software is a compelling reason to evaluate the various options as objectively as possible.
RMI, CORBA, and DCOM are all examples of middleware. The development of middleware will continue to play an important role in enabling the development of evolvable systems.
The JDK1.2 beta* release supports CORBA and RMI. The decision by JavaSoft to go with CORBA was necessary to not compete with the OMG. Given that DCOM is fundamental to Microsoft's future, it will be pervasive and is part of every Windows OS.
There are no simple choices, and the focus of this article has been to draw attention to the advantages and disadvantages of each technology to make it a little easier to define a system.
The ultimate responsibility falls on the shoulders of the systems architect, who must consider the options and make the best possible choice to meet the requirements of the project.