Best practices in distributed object application development: RMI, CORBA and DCOM

This is the first article in a four-part series to be published over the next few weeks.

Section I. Distributed object model overview

Companies and developers are engaged in a major Internet-oriented thrust to build client-server applications based on distributed object models (fig. 1) using various implementations of RMI, CORBA and DCOM. The move away from large mainframe applications is explained by the advantages offered by distributed object technologies. Distributed object application development enables:

• the re-use of existing functionality promoting Rapid Application Development (RAD) with plug-and-play-type interaction of distributed objects.
• isolated development and implementation of objects without adversely affecting other components.
• effective code maintenance including code augmentation and systematic distribution of updates.
• lightweight (thin) client-side interfaces that connect to comprehensive server applications and data repositories in multiple locations.

Code re-use

As with object-oriented programming, a major benefit of distributed object development is the ability to re-use code. Code reutilization makes RAD a reality, empowering programmers to quickly and efficiently develop highly functional applications using existing plug-and-play components. Code re-use is also cost-effective, since developers are not required to reinvent the wheel (the entire wheel, anyway) for each instance of a client-server application or new piece of functionality. Finally, as a developer reincorporates components from a production environment, code re-use diminishes the amount of required system testing since these mature components have previously undergone extensive evaluation and testing.

Isolated development

Distributed object applications allow for isolated development and modification of components because of the approach’s modular design. Distributed object sytems are broken down into separate, self-contained modules that can be worked on independently of each other, yet are capable of inter-operating with other components. For inter-operation to occur, the modules must communicate using a common protocol or interface. But since the methods and functions existing within a module are isolated, they may be separately developed to meet system requirements without worrying about ramifications on code in other parts of the system. This feature facilitates large-scale projects by enabling multiple teams to work synchronously on distinct modules of an application, then pull the modules together via the agreed upon protocol or interface.

Code maintenance

Networked applications are extremely maintainable when developed using a distributed object approach. Once again, due to the modular design of distributed object applications, changing the functionality of an application to fix known problems or meet new requirements — a common occurrence in today’s constantly changing business world — does not require a complete application overhaul. Instead, the modules that need modification are carefully identified and then the required code changes are made exclusively on those identified modules. In this manner, the amount of time it takes to implement code changes in object-oriented applications is compressed from many months — as is the case with cumbersome legacy applications that do not take advantage of object-oriented design — to a couple days. This approach also reduces the number of potential errors introduced to a system with each code modification and release.

Another advantage of the distributed object framework relates to code distribution. With the majority of the distributed object application located on the server(s), distribution of code to the client is effectively handled by simply swapping the modified components on the server side, thus eliminating the need for massive updates to all clients. The next time a client accesses the server, the latest code releases will be provided automatically (and transparently), imposing no undo burden or grief on the end-user.

Thin clients

Since the major components of a distributed object application are located on a server (or a network of servers), the client-side application can be kept small and lightweight. This allows more of the clients’ system resources to remain free while the bulk of the application processing is performed on the high-end servers.

With objects distributed across a network of machines, the thin client can access an infinite number of data repositories and legacy applications of unlimited size, thus making disk space and memory on the client side a non-issue.

And with respect to the initial distribution of an application, lightweight clients (Applets, Active-X objects, stand-alone applications) are small enough that the Internet is an ideal distribution mechanism.

Section 2. Distributed object technologies: RMI, CORBA and DCOM

The three mainstream technologies that provide support for distributed object architectures are RMI, CORBA and DCOM. There is no simple answer to the question of which architecture is technologically superior or which to incorporate in a distributed-object system design. However, RMI, CORBA and DCOM each have some unique characteristics to consider in the decision-making process.

RMI overview

Remote Method Invocation (RMI), integrated with JDK1.1, is JavaSoft’s implementation of a distributed object design. RMI provides a way for client and server applications to invoke methods across a distributed network of clients/servers running the Java Virtual Machine. Despite the fact that RMI is considered to be lightweight and less powerful then CORBA and DCOM, RMI still brings to the table some unique features, like distributed, automatic management of objects and the ability to pass objects themselves from machine to machine¹.

In Figure 2, the client stub and server skeleton are created from a common interface object. The difference between the two components is that the client stub simply connects to the RMI Registry while the server skeleton is tied to the actual method operations.

Note: There is also a JDK1.0.2 version of RMI available for download: http://www.javasoft.com/products/jdk/rmi/download.html.

CORBA overview

The Common Object Request Broker Architecture (CORBA), developed by the Object Management Group (OMG) in 1990, enables invocations of methods on distributed objects residing anywhere on a network, just as if they were local objects. A CORBA implementation employs Object Request Brokers (ORBs), located on both the client and the server, to create and manage client/server communications between objects. ORBS are the key to the CORBA distributed object architecture. They allow objects on the client side to make requests of objects on the server side without any prior knowledge of where those objects exist, what language they are in, or what operating system they are running on². To facilitate these requests and provide ORB interoperability, the CORBA 2.0 specification outlines a protocol named Internet Inter-ORB Protocol, which has quickly been embraced by industry leaders (IBM , Netscape Oracle).

Dynamic Invocation Interface: enables the client to detect and invoke server objects at runtime. No IDL Stub is necessary for this type of object invocation.

IDL Stubs: define how clients invoke server objects.

ORB Interface: general services for both the clients and server.

IDL Skeleton: provides static interfaces to objects of a specific type.

Dynamic Skeleton Interface: a generic interface for objects, regardless of type, that are not specified in the IDL Skeleton.

Object Adapter: handles communication between an object and the ORB.

DCOM overview

Distributed Component Object Model (DCOM) was unveiled in 1996 as Microsoft’s solution to distributed object architectures, and now is CORBA’s biggest competitor. DCOM, previously known as Network OLE, is an extension of the COM design (Figure 4.) to networked applications. Although DCOM possesses its own core network protocol Object Remote Procedure Call (ORPC) and has major architectural differences from CORBA, it successfully duplicates the powerful CORBA capabilities within the Microsoft environment. Key features engineered into the DCOM architecture comprise language independence (including, interestingly enough, strong bindings with Java²), integrated Windows NT wire-level security, transport neutrality (with the ability to communicate using TCP/IP, UDP/IP, IPX/SPX, AppleTalk, and HTTP), and static/dynamic invocation of objects.

Section 3. Best practices in distributed object technologies

DCOM

DCOM is obviously a proprietary solution and is well-suited for the Microsoft-centric environment. If any operating systems other then Microsoft NT and Win95 are required in the application architecture, then DCOM is probably not the correct solution. This soon may change, however, as Microsoft attempts to make DCOM cross-platform compatible. A third-party vendor, Software AG, has released a version of DCOM for Solaris UNIX and plans to develop ports for other UNIX platforms as well⁴. Nevertheless, in its current state, DCOM is best implemented as a solution where the production environment is exclusively oriented around Microsoft products.

RMI

RMI is the simplest and fastest way to implement a distributed object architecture due to its easy-to-use native-Java model. Therefore, it is a good choice for RAD prototypes and small-sized applications that are implemented completely in Java. The main issue with RMI is that its not as robust or as scalable as CORBA or DCOM solutions. For example, RMI uses a native-transport protocol, JRMP (which is not currently CORBA/IIOP compliant), and can only communicate with other Java RMI objects. This “single-language” crutch makes it impossible for RMI to interact with objects not written in Java – like legacy applications – and prevents RMI from playing a more formidable role in large-scale enterprise solutions. (Note: JavaSoft did announce last year that they are fully committed to CORBA/IIOP and have plans to make RMI IIOP-compatible.)

CORBA

Why is CORBA the most effective tool, to-date, for developing a large-scale, open-architecture, distributed object systems? Even though CORBA and DCOM are extremely similar in functionality and capability (multilingual support, dynamic invocations, wire-level transactions, scale-ability, etc.,) DCOM is missing one crucial element – multi-platform support. The fact that DCOM does not currently support full operating system interoperability is sufficient justification to discount it as a viable, sole-source solution. Thus, CORBA is the logical technology of choice for truly enterprise-wide, open-architecture, distributed object applications.

References

1. JavaSoft
2. Client/Server Programming with Java and Corba, Orfali, Robert and Harkey, Dan; John Wiley & Sons, 1997
3. “DCOM Technical Overview,” White Paper, Microsoft
4. “DCOM Goes Cross Platform,” Object Magazine, January 1998

Tom Albertson is a senior associate at Coopers & Lybrand Consulting, Government Services Practice in Washington, D.C. He has four years of extensive Internet development experience enhanced by seven years of parallel experience in systems design and engineering, application/GUI development, computer programming and database management. You can reach Tom via email: Tom.Albertson@us.coopers.com.