Making Sense of Distributed Objects

David Chappell - December 1997

Given the popularity of both distributed computing and object technology, it’s not surprising that distributed objects are hot. But understanding this technology can be challenging, since it requires some grasp of both networking and objects. And as if the technical issues weren’t tough enough, distributed objects have also engendered some of the most confusing vendor marketing of the decade.

But with a little care, sorting through both the technologies and the competing claims of their proponents is not so hard. And the payoff is worth it—despite the overblown hype, distributed objects really do matter.

Allowing objects on different systems to work together requires addressing some fundamental questions. First, and most important, what exactly is an object? What does one look like, and how is it defined? Once these questions are answered, the next problem is to figure out how these objects should communicate. And once we've specified a basic communication mechanism, other issues arise, such as how objects find each other and how secure interaction among objects can be guaranteed.

The Object Management Group (OMG), a consortium of vendors and user organizations, has defined the Common Object Request Broker Architecture (CORBA) as a vendor-neutral standard that addresses these questions. Microsoft, officially a member but not really a supporter of OMG, has defined its own solutions, embodied in the Component Object Model (COM) and its networked cousin, Distributed COM (DCOM). And more recently, Sun Microsystems has provided solutions to many of these same problems within the environment provided by Java. In particular, Sun has defined a technology called Remote Method Invocation (RMI) for accessing Java objects across a network.

Both CORBA and COM/DCOM provide a language-independent object model, a protocol for communication between objects on different systems, standard interfaces for accessing useful services, and more. The Java camp also provides most of these things, with the notable exception that there's nothing at all language-independent about their work: everything assumes use of the Java language. Since all three technologies provide solutions to the same set of problems, they can appear to be competitive with one another. When you get right down to it, though, it's usually fairly obvious which one you ought to use to solve a particular problem. To see why this is so, it's useful to examine them one at a time.

It’s hard to argue with the idea of defining vendor-neutral standards for distributed objects. Open standards in networking have made today’s connected world possible, with the global Internet providing the most visible example. Without standards, the best we can hope for is a diverse set of single-vendor islands.

But in their hearts, most vendors hate standards. Given a choice, any vendor would prefer to have its own proprietary technology become dominant. This is neither surprising nor immoral—vendors are in business to make money, after all, and the commoditization wrought by multi-vendor standards works against high profit margins. Yet users love standards, and are often reluctant to buy technology produced by just one company. What’s a vendor to do?

The answer is simple: create CORBA. From a vendor’s point of view, CORBA is perfect. The OMG has produced a host of standards, all created using a relatively open process, to which each vendor’s products must conform. Companies selling products based on CORBA can quite honestly tout their compliance with these standards. At the same time, however, the technologies defined in those standards are so loosely specified that vendors are encouraged (and often even required) to add proprietary elements. This looseness is rarely mentioned by CORBA’s promoters, and since very few customers actually read the specifications, the illusion of standardization remains.

The reality, though, is that each vendor’s CORBA-based product is quite different from the others. While some products can interoperate for straightforward requests via CORBA’s Internet Inter-ORB Protocol (IIOP), vendors commonly add extra features that rely on their own proprietary protocols. Furthermore, the application programming interfaces seen by developers vary significantly. This is why there is today no serious third-party market in CORBA-based applications—a different version would need to exist for each vendor’s product.

Does this lack of standardization mean that CORBA is useless? Of course not. Many organizations have successfully used CORBA-based products to integrate diverse systems. The technology’s great strength is that the successful CORBA-based products—Iona’s Orbix, BEA’s ObjectBroker, and others—all run on a wide range of operating systems. If the goal is to connect a diverse set of machines together using distributed objects, CORBA-based products can be an excellent solution.

But they’re not standard. When you buy a CORBA-based product, make very sure that you like both the product and the company that makes it. While it is possible to create a multi-vendor ORB environment, doing so intentionally makes no sense. Since different products have different programming APIs, different security schemes (when they have security at all), different administrative interfaces, and other variations, sticking with a single vendor’s product will make your life much easier. And since all of the leading CORBA-based products run on most popular operating systems, there’s typically no need to use more than one of them.

Some CORBA fans argue that, while CORBA began as a very loosely defined set of standards, it has gotten more completely defined over time. To these true believers, it’s only a matter of time before the OMG defines everything, and CORBA emerges as a true standard. But we’ve been hearing this for several years, and while some of the newer standards are better defined, others are not. There’s no reason to believe that the vendors who control the process will ever allow true, complete standards to emerge—it’s just not in their interest to do so. The aura of standardization that CORBA carries is a tremendously useful marketing tool, one that true standards would do little to improve.

If CORBA-based products are largely single-vendor solutions (and they are), then they would appear to compete directly against Microsoft, the biggest single vendor of them all. But, in fact, one can make a very good case that CORBA and COM/DCOM aren’t competitors at all. If they were, a user would be faced with choosing between these two technologies to solve a particular problem. In the event, though, this virtually never happens.

To understand why, think about the strengths of Microsoft’s approach. First of all, unlike the diversity that exists in the CORBA world, there’s only one implementation of COM and DCOM (this is true even on non-Microsoft operating systems, a topic I’ll return to in a moment). This homogeneity, together with the tremendous popularity of Windows and Windows NT, has led to an enormous third-party application market. Furthermore, COM is installed today on literally hundreds of millions of machines—it’s a standard part of the operating system. While DCOM’s penetration lags somewhat (it’s built into Windows NT 4.0 but must be downloaded from Microsoft’s web site for Windows 95), it still greatly exceeds the installed base of all CORBA products combined. And although CORBA fans like to criticize COM and DCOM on technical grounds, claiming that they’re not really object oriented and more, the truth is that from a purely technical perspective, both technologies work quite well. In some areas, in fact, DCOM is clearly ahead (every copy of DCOM includes solid security services, for example, while most CORBA products provide little or nothing in this area).

Microsoft’s approach suffers from one obvious weakness, though, and it’s a big one: for the most part, COM and DCOM only run on Windows and Windows NT. There is a quite good implementation of COM for the Macintosh, and Software AG is valiantly porting DCOM to various Unixes and to MVS, but it’s hard to believe that Microsoft will ever be seriously concerned about operating systems they don’t own. (In fact, in looks like Microsoft's recently-announced COM+, while it will interoperate with existing COM and DCOM systems, will itself be available only on Microsoft platforms.) Yet most organizations have a multi-operating system environment, and although Windows NT seems likely to become dominant over the next few years, diversity will never completely go away.

Given all of this, it should be obvious why CORBA and COM/DCOM aren’t really competitors. If the problem you’re trying to solve requires connecting objects implemented solely on Windows and Windows NT, use DCOM. CORBA-based products make no sense here, if only because DCOM is free while most CORBA vendors (not unreasonably) actually expect to make a profit on their products. If, on the other hand, you need to communicate between objects written in multiple languages in a diverse environment that includes Unix and other non-Microsoft systems (and probably Windows/Windows NT as well), then you must use a CORBA-based product today—it's the only game in town. The choice is simple, and religious debates about which is the better technology are entirely beside the point. Instead, it’s purely a platform issue: the operating systems you’re running make the choice for you. If Software AG and others can make a go of their DCOM-on-other-platforms strategy, this may change. For the moment, however, the decision is easy.

And speaking of platforms, there's a new one on the block: the Java environment. It's entirely possible to write Java applications that run only on a single operating system, something Microsoft is doing its best to foster. Sun discourages this, however, suggesting instead that all Java applications be written solely to the operating system-independent Java environment instead.

Part of this environment is RMI. RMI is significantly easier to use than either CORBA or DCOM, and so developers have flocked to it. Neither the leading CORBA vendors nor Microsoft are big RMI boosters, however, since it competes with each party's favored solution. Accordingly, both have tried to discourage its growth. Under pressure from the CORBA world, Sun has announced its willingness to somehow merge RMI with CORBA's IIOP. But because RMI is designed solely for Java while IIOP is more generic, there are technical issues that make this less than a perfect solution. We will probably see some combination of the two protocols emerge at some point, but don't hold your breath: OMG is doing the work, and standards bodies are seldom speedy. For the next year or two, expect RMI and IIOP to remain distinct, potentially competing protocols.

Microsoft has offered a much more direct expression of its dislike for RMI: they've simply refused to support it. Given that Microsoft provides the operating system for the vast majority of desktops in the world today, this poses a bit of a problem for organizations that wish to use RMI. One solution for companies that choose Java is to use Netscape's browser, which includes RMI support, rather than Microsoft's Internet Explorer, which does not. For organizations standardizing on the Microsoft browser, however, using RMI means installing the necessary library yourself on every client--it won't be built in.

When should you use RMI rather than CORBA or DCOM? The answer is easy: whenever you can. RMI is simple and straightforward to use, but it lacks security and other often important services. But if these limitations are acceptable, if you have a way to guarantee the availability of the RMI libraries on both your clients and servers, and, most important, if the objects on both sides will be written in Java, RMI is the way to go. Its simplicity and support for multiple platforms make it too attractive to ignore.

But suppose I choose CORBA, you say, because I want to include some Unix servers and I can't write everything in Java. Don’t I still have to work well with the desktop, i.e., with the Windows environment? You certainly do, and the CORBA vendors realize this. Accordingly, they all provide bridges between CORBA and COM. This allows tools supporting COM, such as Visual Basic and virtually all other Windows development tools, to use CORBA over the wire. It’s even possible to create specialized ActiveX controls, components that encapsulate remote access to various pieces of server functionality. Once this has been done, those components can be easily plugged into any number of desktop applications, providing a straightforward and reusable mechanism for accessing legacy applications.

But the story isn’t perfect. While the way CORBA and COM look at objects is quite similar, it’s not the same. The mapping between these two object models, then, has a few problems. As is so often the case in situations like this, basic functions can work quite well, but more advanced uses become problematic. Gateways between similar but different solutions have historically suffered from these kinds of problems, and the COM/CORBA gateway is no exception. While its creators did an excellent job, the goal of perfect, transparent interoperability just isn’t reachable.

COM and CORBA aren’t the only two object technologies that can be usefully combined. It’s also quite useful to combine both COM and CORBA with Java. As mentioned earlier, CORBA's IIOP will probably be folded into Java's RMI, making it easy to use IIOP beneath today's RMI API. Somewhat surprisingly, Microsoft goes even further--its Java virtual machine includes a transparent two-way mapping between Java objects and COM objects. While Microsoft doesn't ship RMI, this does make it relatively straightforward to use DCOM from Java.

If the OMG, back in 1991, had chosen to define and publish complete standards for distributed objects, the world today might be a very different place. As it is, they choose to create something that was closer to a marketing exercise than a true technology standard. The result is predictable: a good deal of fragmentation in the CORBA market, with the eventual emergence of a few major players: Iona, BEA, Visigenics, Expersoft, and a couple of others. But compare the size and strength of these "major" players with that of their primary competitor, Microsoft. Despite years of pro-CORBA hype, market realities tend to have the last word.

Furthermore, COM and DCOM are given away for free, always a tough price point to beat, and they are very well integrated with the dominant tools and application on their target platforms (which is no surprise since Microsoft produces the dominant tools and applications on those platforms). For shops that are committing to Windows NT as a server platform for new applications, DCOM will be by far the dominant choice for distributed objects. If your organization plans to move to NT as your primary server operating system for new applications, plan to move to DCOM, too.

For shops that choose to continue to build new applications on Unix servers and want to use distributed object technology, CORBA can be the right choice. Choose your vendor carefully, however, because once you’ve installed their product, it won’t be easy to change. There’s another use for CORBA, too, one that has perhaps been the most common so far: integration of existing applications on diverse systems. Even organizations that aren’t building new applications on non-Microsoft operating systems can make use of CORBA-based products to tie together existing applications, something they can do very well.

And finally, if your organization has jumped on the Java bandwagon in a major way, get used to RMI. Its simplicity has some drawbacks, such as limited support for security, but Java developers are almost sure to like it. Microsoft's lack of support will be an annoyance, but it's not an insurmountable problem. Java's promise of being able to run more or less the same code on all kinds of systems is undeniably very attractive.

Ultimately, which technology dominates will depend on how popular Windows NT becomes as a platform for building new server applications. In my view, the advantages of NT—price, ease of use, a plethora of available applications, and better integration with Windows clients—will eventually lead to its dominance. If (or perhaps when) this happens, the installed based of DCOM will far outweigh that of the alternatives. Until that day arrives, though, CORBA and Java's RMI still have a role to play in many organizations.

This article originally appeared in the December 1997 issue of Ed Yourdon's American Programmer.

• CORBA
   
• COM
   
• Java

Website design and development by kmcreative.
KMCREATIVE is a Silicon Valley based graphic design firm specializing in corporate collateral, web design, web development, identity, medical illustration and product illustration.