by Prithvi Rao
<prithvi+@kiwilabs.com>

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).

Synopsis

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.

Java RMI

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 Good:

1. It is very easy to use.
2. Remoteable interfaces have a special exception.
3. It supports object-by-value.
4. Versioning is built into serialization.

The Bad:

1. Java call semantics are changed so that thread identity is not maintained.
2. Callbacks are blocked in synchronized methods.
3. It is not always intuitive.
4. It is not available to other languages.

The Ugly:

1. There are limited development tools.
2. Clients need access to the latest stubs.
3. Performance can be slow as you scale.

CORBA

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 Good:

1. It is an architecture for system composition.
2. It has a standard terminology for concepts.
3. Declarative interface separates the interface from the implementation.
4. It provides mappings from IDL to C, C++, ADA, SmallTalk, and Java.
5. Because it was designed for distribution first, there is support for evolvable and marshallable data.
6. It supports design portability.
7. It is scalable for large systems.
8. It supports standard interoperability protocols.

The Bad:

1. There is no inheritance for Exceptions.
2. Inheritance causes problems in versioning, so objects cannot support two versions of the same interface.
3. IDL is not internationalized.
4. There are divergent security mechanisms (kerberos, SSL).
5. There are basic standard service, but few advanced services.

The Ugly:

1. C++ mapping has complicated memory management rules.
2. There are limited developer tools (usually just an IDL compiler).
3. The limited concurrency model means there is no standard for thread priority, deadlines and timeouts.
4. Scalability can be an issue if design is not well thought out.

DCOM

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.

The Good:

1. There are lots of tools, books, and developers.
2. It solves many of the idl versioning problems by separating out the interface from the implementation.
3. There is good integration of automation objects with VisualBasic and Java.
4. There is a good set of compound document interfaces.
5. Microsoft depends on it working.

The Bad:

1. There is minimal support on non-Microsoft platforms. Although some UNIX vendors plan to support DCOM, this technology has not been proven stable enough to gain acceptance in the UNIX world if it were available today.
2. Automation versus MIDL type system (fairly restrictive) is an issue.
3. It cannot passify idle service so a reference to a service must stay in memory.
4. It is hard to keep registry consistent.

The Ugly:

1. Language mappings do not provide for automated UUID changes when an interface is revised.
2. Generated code is intermixed with user code. Headers are neither C or C++.
3. Reference counting is a problem; it is easy to have one too many or one too few releases.
4. The client has to choose the interaction model (CreateInstance, GetObject, Monikers). It is not clear which is the appropriate one for a given case.

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.

Summary

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.