Legacy Mechanisms for Cross-Platform Development

As long as computing systems have lived on networks, there has been a need for those systems to communicate with each other at the application level. Network protocols such as TCP and UDP provided a way for programmers to build in client/server and peer-to-peer communication. Programming these protocols directly, however, could be a daunting task, so layers appeared above these protocols that eased the task of writing distributed applications. In this section we review several of these layers that support cross-platform application development, including UNIX Sockets, the Distributed Computing Environment (DCE), CORBA, Java RMI, and DCOM.

UNIX Sockets

UNIX sockets might have been the first standard built on top of the basic protocols that provided an interface for programmers to write the communication component of client/server applications at a more abstract level. A programmer could specify a connection-oriented socket when a persistent connection was needed, or a connectionless socket for sending messages, and the socket would perform the right function with the underlying protocol.

Even with UNIX sockets, however, many problems remained for the application programmer. Although UNIX sockets presented a layer of abstraction above the underlying protocols, the socket interface still required low-level programming. As for platform interoperability, UNIX sockets work as long as you only want to communicate with UNIX systems. (Similar implementations for other platforms, like WinSock for Microsoft Windows, were developed later.)

UNIX sockets (and other related implementation) provided raw data-transfer capability only, and lacked the ability to invoke remote procedures or functions. Any processing of the incoming data stream had to be hard-wired into the client applications. Sockets provided no capability to, for example, pass method or function arguments between systems.

Distributed Computing Environment

While UNIX sockets provided the ability to pass monolithic data streams between systems, designers of distributed systems needed a more platform-independent mechanism that supported actual remote procedure calls. One attempt to provide RPC capability was known as the Distributed Computing Environment, or DCE. This environment provides a theoretically platform-independent infrastructure for implementing and managing distributed applications. It also provides directory and security services, as well as distributed file system and RPC capabilities (it even provided a time-synchronization mechanism for "cell" members). DCE also correctly handled the marshaling of RPC data as appropriate to match the expected data format of the calling or receiving OS.

Unfortunately, DCE was only platform-dependent to the extent that relatively heavyweight client software existed for the target platform. To participate in these services a platform had to be configured (again, a potentially complex operation) into a DCE cell. Later DCE implementations allowed the user to conFigure only certain services, such as the RPC mechanism. However, the overhead in purchasing, configuring, and maintaining a cell, as well as the lack of general availability of the client software, prevented DCE from becoming a general-purpose solution for distributed computing.

CORBA

CORBA provides a platform- and language-independent infrastructure for building distributed applications and invoking remote procedure calls from client systems. CORBA presents fine-grained distributed objects within heterogeneous computing networks. Applications can identify and use available business software components via a network of ORBs. The standards body behind CORBA, the Object Management Group (OMG), originally believed that large numbers of ORBs would exist on the Internet, transparently channeling object requests to the appropriate server resource.

CORBA objects are essentially language-independent. CORBA servers present their interfaces in the form of an IDL, which defines the methods supported by the CORBA server and the expected arguments to those methods. Client programs interact with these objects via stub interfaces that execute an object's methods remotely on the machine hosting the software. The ORB sits in the middle and dispatches all intermachine communication. ORBs around the Internet can share information about the objects they manage. The IIOP was developed for this purpose.

Java RMI

Like CORBA, Java's RMI subsystem allows objects to be distributed across a network. Unlike CORBA, Java RMI can transport an entire class, software and all, across application boundaries (via either RMI or IIOP protocols). This communication is possible because all Java applications must run on the Java Virtual Machine. This enables distributed Java applications to safely download compiled byte streams and execute them locally.

Although the ability to share executable objects dynamically over the Internet opens some exciting possibilities, Java RMI has its shortcomings. Most notably, the technology only works if the applications involved in the exchange are both written in Java. Programs written to use RMI also require a fair amount of preparation. Remote stub classes need to be generated statically or downloaded dynamically for remote methods to work properly. Finally RMI uses a proprietary protocol to exchange information, which means more server software and firewall tuning.

DCOM

DCOM is a Windows implementation of a distributed-application development environment, based on Microsoft's COM. DCOM uses DCE RPC as the underlying remote object-support mechanism.

Unlike CORBA, a DCOM object can present multiple interfaces, which in turn can provide multiple object behaviors. A COM client invokes a COM object by acquiring a pointer to the object's interface. The client invokes methods through that pointer; from the perspective of the client, the object appears to reside in the client's address space. Because DCOM is tightly integrated with the Windows operating system, DCOM provides a solution for Windows-based distributed applications only. Table 11-1 provides a comparison of the several distributed-application infrastructures.