ORB, ORB architecture, middleware

Our goal is to merge the two core software technologies of the 1990s: object-oriented programming and client-server programming. Designing object-oriented client-server applications requires remote method invocation (RMI): the ability to communicate with remote objects using ordinary method invocation syntax. Assume process, machine, or network boundaries separate three objects: client, server1, and server2:

Here is what a fragment of client code should look like:

RMI raises three problems:

The client references server1 and server2 by name. These names must be transparently resolved into IP addresses and port numbers. Even if the servers move to another host.

Communication between the client and the servers-- sending x, y, and z from the client to the servers and sending a result from the servers back to the client --probably uses serialization/deserialization and some Inter Process Communication (IPC) mechanism such as sockets or pipes, but this is hidden from the programmer.

The three objects may be implemented in different languages. For example, the client may be implemented in C++, while server1 is implemented in Java and server2 is implemented in Smalltalk. Not only are there syntactic difference between these languages, there are also semantic differences, even semantic differences dealing with the nature of objects and classes. In this case x, y, and z must be translated into the language of server1 and server2, and result1, result2, and result3 must be translated into the language of the client. However, the programmer implementing the client may not know what language was used to implement server1 and server2, and the programmers who implemented server1 and server2 certainly didn't want to make any assumptions about the implementation language of their clients.

The ORB architecture uses a variant of the Dispatcher (used in the Message Passing Architecture) to provide location transparency. Recall that the dispatcher—called the Broker in this pattern –is simply an object that maintains a table containing associations between the names of remote objects and their locations. DNS, portmapper, and the Windows Registry are examples of dispatchers.

Remote proxies—both on the server and client side --are used to provide transmission transparency. These proxies implement the same interface as a server, but they perform serialization/deserialization, name-location resolution—with the help of the broker, and ultimately delegate work to the real server through some IPC mechanism.

The proxies can also help with language transparency by translating the objects they transmit (x, y, z, result1, result2, and result3) from the local language into a common object oriented language (COOL)—this is called parameter marshalling; and translating the objects they receive (x, y, z, result1, result2, and result3) from COOL to the local language—this is called parameter demarshalling.

The broken lines indicate possible process, computer, or network boundaries. The server interface is specified in COOL. Ideally, the Stub and Skeleton can be automatically generated from the server interface using the appropriate COOL to XXX compiler, where XXX is the implementation language of the client or server. If the broker can't locate a server, it may seek the help of a neighboring broker through a bridge:

The biggest hurdle is COOL, our common object oriented language. First, COOL must be sufficiently general that all major object oriented languages can be compiled into COOL and vice-versa. Second, and most difficult, everyone must agree to use COOL.

OMG (Object Modeling Group) is a consortium of companies that is trying to set standards for object oriented programming. Among their proposals is a standard for ORB architectures called CORBA (Common ORB Architecture). Their common object oriented languages is called IDL (Interface Description Language). IDL interfaces are very similar to C++ header files. Compilers are available that translate between IDL and various object oriented languages.

Microsoft is moving all of their distributed programming features over an ORB foundation called ActiveX. OLE (the new Object Linking and Embedding), Automation (the DDE replacement), DAO (the ODBC replacement), and ActiveX controls (the Applet "replacement") are all ActiveX-based technologies. In this context the system registry maintains associations between the names of remote objects and their locations. The common object-oriented language being proposed by Microsoft as an industry standard is COM (Common Object Model) and its distributed version DCOM. (COM only handles communication across process boundaries. DCOM is needed to cross machine and network boundaries.) Unfortunately, there are no COM to XXX cross compilers. You'll need to implement your own stub and skeleton if your application doesn't fit into one of the frameworks mentioned above.

If clients and servers are always Java objects, then Java RMI can be used as middleware. It provides a broker, and automatic generation of stubs and skeletons. In this case COOL is simply Java.

In the real world we need to integrate legacy systems into our distributed applications, and not many of them are object-oriented. This eliminates CORBA, ActiveX, and Java RMI as middleware candidates and opens the door for products that provide ORBs that can talk to adapters that can make legacy systems behave like objects.