The Object Web technologies overview and comparison: CGI, RMI, CORBA and DCOM

CGI overview

The Common Gateway Interface (CGI) is a means for the HTTP server to talk to programs on your, or someone else's, machine.

Common  The idea is that each server and client program, regardless of the operating system platform, adheres to the same standard mechanisms for the flow of data between client, server, and gateway program. This enables a high level of portability between a wide variety of machines and operating systems.

Gateway  Although a CGI program can be a stand-alone program, it also can act as a mediator between the HTTP server and any other program that can accept at runtime some form of command-line input (for example, standard input, stdin, or environmental variables). This means that a SQL database program that has no built-in means for talking to an HTTP server can be accessed by a gateway program, for example. The gateway program usually can be developed in any number of languages, regardless of the external program.

Interface  The standard mechanisms provide a complete environment for developers. There is no need for a developer to learn the nuts and bolts of the HTTP server source code. After you understand the interface, you can develop gateway programs; all you need to know in terms of the HTTP protocol is how the data flows in and out.

CGI programs go beyond the static model of a client issuing one HTTP request after another. Instead of passively reading server data content one prewritten screen at a time, the CGI specification allows the information provider to serve up different documents depending on the client's request. The CGI spec also allows the gateway program to create new documents on-the-fly-that is, at the time the client makes the request. A current Table of Contents HTML document, listing all HTML documents in a directory, easily can be composed by a CGI program.

Note particularly the synergism between organizations permitted by the capability of CGI programs to call each other across the Internet. By mutual agreement, companies can feed each other parameters to perform ad-hoc queries on proprietary data stores.

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. The RMI diagram show 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.

RMI diagram


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). The CORBA diagram shows the basic structure of the CORBA 2.0 ORB Specification.

Basic CORBA 2.0 Orb architecture

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.

The DCOM diagram illustrates how the COM run-time environment provides distributed object services to clients and components and uses DCE RPC and the security provider to create standardized network packets that correspond to the DCOM wire-protocol standard3.

Basic DCOM architecture

Pros and Cons

DCOM is 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 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 is 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.

The advantages of CORBA over CGI and Java.net.* for server communication center around the simplicity of basic CORBA-based client/server interactions and the wide applicability of a CORBA-based server. This is in contrast to the cumbersome nature of CGI and Java.net.* client/server interactions and the limited applicability of a CGI-based server. More specifically, because the CGI protocol only supports input and output parameters by way of environment variables and standard input/output, all parameters must be packaged into and out of string form. Of course, CORBA has no such limitation. Parameters may be passed as any of the basic IDL types (short, float, string, sequence, and so on), or as any complex type defined in the server's interface definition. The CGI protocol does not inherently support the invocation of a specific function. As a result, the Web site designer must build and manage several CGI programs, each specifically designed either to perform a single function or write one or more multipurpose CGI programs. In the latter case, the invoked CGI program must parse the string-based input parameters passed to it in order to determine the desired function.

CORBA allows a Web client to make a very specific function call to a very specific object in a server program using a very natural syntax. Additionally, most existing server applications were not written to support CGI access, and modifying a server application to support CGI access seems to be an unnecessarily narrow and cumbersome solution to the broader problem of supporting client interactions with a given server. On the other hand, many existing server applications already provide client access via a CORBA layer. But even where a server application is not CORBA-enabled, CORBA is a much more generic, extensible, and efficient solution to providing client/server access to data and functionality. The final benefit of CORBA over CGI and Java.net.* is that making a CORBA call in Java is simply less problematic than the corresponding Java.net.* calls. There is no need for the use of the URL, URLConnection, DataInputStream, and DataOutputStream classes.

Comparison rating

Table shows below is from the Java and CORBA book by Robert Orfali and Dan Harkey. Table illustrated the six contending Object Web technologies. Four stars is the hightest rating. A Red star is the worst rating; it means the function is not available.

Feature

CORBA/IIOP

DCOM

RMI/RMP

HTTP/CGI

Servlets

Sockets

Abstraction level **** **** **** ** ** *
Seamless Java integration **** **** **** ** ** **
OS platform support **** ** **** **** **** ****
All-Java implementation **** * **** ** **** ****
Typed parameter support **** **** **** * * *
Ease of configuration *** *** *** *** *** ***
Distributed Method Invocation **** *** *** * * *
State across invocations **** *** *** * ** **
Dynamic discovery and metadata suport **** *** ** * * *
Dynamic invocations **** **** * * * *
Performance (Remote Pings) ***

3.5 msecs		 ***

3.8 msecs		 ***

3.3 msecs		 *

827.9 msecs		 *

55.6 msecs		 ****

2.1 msecs
Wire-level security **** **** *** *** *** ***
Wire-level transactions **** *** * * * *
Persistent object references **** * * * * *
URL-based naming **** ** ** **** **** ***
Multilingual object invocations **** **** * *** * ****
Language-neutral wire protocol **** **** * **** **** *
intergalactic scaling **** ** * ** ** ****
Open standard **** ** ** **** ** ****

by Pui Sum Lui


BIBLIOGRAPHY

Tom Albertson is a senior associate at Coopers & Lybrand Consulting, Government Services Practice in Washington, D.C.

HTML 3.2 and CGI Professional Reference Edition UNLEASHED
Author: John December and Mark Ginsburg

Client/Server Programming with Java and CORBA by Robert Orfali and Dan Harkey