Client Server : Object Request Brokers

The Importance of Middleware

Middleware is the connective layer in client-server models. The multi-vendor software is compiled by designers to enable services that allow multiple machines to process multiple requests and interact across a network. It also allows communication across platforms. It is like a translation layer that liberates the client-server model by allowing it to communicate more freely across platforms and networks in standardized languages comprehensible across software or hardware differences.

Middleware provides a more effective API (Application Programming Interface) than operating systems (OS) or network services. APIs are important to middleware because they provide the interface through which clients communicate with servers. APIs aid middleware as a type of programming that allows for data sharing across platforms. It helps toward the open systems goal of complete cross-platform consistency. The most popular types of APIs used in client-server models are RPCs (Remote Procedure Calls), SQL (Standard Query Language), and message delivery. The primary goal of middleware is to allow application to find what they need from another application located on another server or on the Web and interact with that application (or service) to perform a requested task. Middleware is also liberated from network services, not requiring them to communicate with servers across networks.

For the purpose of this article, the type of middleware we will be investigating is ORB (Object Request Broker). ORBs manage communication and the exchange of data between objects on distributed systems. This promotes interoperability by allowing users to piece together objects, possibly from different vendors, on different computers that will work together through ORBs. Since ORBs are object-oriented programming, another feature is the hiding of all communication details from users or developers. This allows for easy transparent communication. Users experience a single interface, while applications are being accessed from different locations. This feature enhances maintainability, which is a software application’s ability to detect error and improve performance ‘behind the scenes’ or in the ‘back office’ on the server. ORB technology defines interface features, locates and activates remote objects/services, and provides communication between client and object.

This article will discuss ORB functions and major ORB technologies like OMG’s CORBA, Microsoft’s COM/DCOM, and Java’s RMI.

OMG’s CORBA

CORBA stands for Common Object Request Broker Architecture. It was developed as a product by Object Management Group (OMG) soon after it formed in 1989. OMG’s aim is to develop an open distributed object infrastructure. Distributed objects are software modules that exist on different computer systems on, for example, a private network or the Web. These objects ‘distributed’ across different locations are designed to work together to meet users’ needs. A program on one machine sends a request to an object on another machine in another location to perform some processing task. The results are then sent back to the client’s machine that made the request. CORBA is the software interface that supports this communication. It allows communication between objects regardless of their location on a network on the World Wide Web.

CORBA was the first specification OMG instituted as it developed its Object Management Architecture (OMA). The object architecture model can be described roughly as follows: On the top layer application interfaces, domain facilities and common facilities communicate with the ORB core. The ORB communicates processing requests to object services. Object services/processes return a response to the ORB core, which, in turn, returns the response to users. CORBA programming makes this rough model more sophisticated.

Let us use as an example of object type, the shopping cart function on so many e-commerce web sites. Each object type requires an OMG IDL (Interface Description Language). This IDL offers syntax from the server to specify the task it wants performed. This same interface syntax is used when the response is returned to the client. IDL is an independent programming language, but maps to the most used programming languages, like C, C++, Java, and Python, through OMG standards.

The key to CORBA is the “separation of interface from implementation”. This is facilitated by OMG IDL. It is this separation that produces the interoperability and transparency that mark CORBA. The specificity of interfaces and the object contained within them maintain control. All implementation takes places behind a barrier the client cannot cross.

IDL is compiled into client stubs and object skeletons (also written in IDL), which substitute client requests and server responses, respectively. Implementation and processing objects are written on the server side. Because IDL interfaces are so specific, the client stub has a perfect match or specific function to which it is attached. The interface definition is so strictly defined that the two can originate from different programming languages from different vendors.

Microsoft’s COM

COM or Common Object Model was developed and introduced by Microsoft. It is also known as DCOM (Distributed Common Object Model). Its goal was to create objects that were language-neutral, so that implementation could take place in different environments across hardware and software differences. Much like CORBA, much of the control and specificity of this technology is strictly defined by the interface, whose object must be written in binary code to insure intelligibility across languages and environments. COM defines an API (Application Program Interface), which allows certain data to be entered and processed. These interfaces are written in Microsoft’s IDL, which is an elaboration of the more standardized DCE (Distributed Computer Environment) IDL.

Also like CORBA, COM objects run on the server. These objects can be accessed in three ways: through an in-process server, a local object proxy, and a remote object proxy. Accessing objects through in-process servers is the simplest way because both client and server are in the same process. The client links directly to a library in the in-process server and locates an in-process object that can return the desired processed object. However, when server and client processes are separate, COM must ‘marshal’ or bundle and format data before it can be intelligible to the server, whether local or remote. This is accomplished through ‘proxy’ or ‘stub’ objects. The client communicates with the server interfaces through a proxy object. The proxy marshals the request object and communicates it to the server stub. The server stub unmarshals the proxy object information and executes processing. This completed request is then marshaled by the server stub and returned to the proxy object which then returns the processed object back to the client. When the client and server operate on the same machine COM is used. When they operate on different machines DCOM (Distributed Common Object Model) is used.

COM has several associated technologies. These include OLE (Object Linking and Embedding), a compound document technology that immediately runs respective media players when, for example, video, audio, or graphics are embedded into a document. Other ones include DCOM (discussed above), ActiveX and COM+. There is speculation that COM is being, at least partially, replaced by .NET framework and Microsoft’s increasing support of web services.

Java’s RMI

Java’s RMI stands for ‘remote method invocation’. It is a protocol developed by Sun Microsystems for Java. It is an API that uses RPC (Remote Procedure Call) to allow Java objects to be located and stored in a network to be remotely accessed. RPCs are a little old-fashioned since they are synchronous and require client applications to be suspended until the response is returned. However, threads, or parts of programs that can be executed independently, allow for concurrent processing. Like the two other ORB technologies we discussed, it increases interoperability.

However, unlike other ORB technologies, like CORBA and DCOM, RMI can only be used for objects written in Java. It is a means for java applets to communicate with server applications, especially those on the Internet. Also, like other ORB technologies, it is concerned primarily with interface details to create specific stubs and skeleton. Clients create stubs that facilitate communication with the network. The network then creates a skeleton of the processing object requested. The skeleton communicates with the server to complete the request. It is returned to the client through the network to the stub and then to the client.

There are two implementations for this technology. Originally, this technology only supported communication between two JVMs (Java Virtual Machines). Virtual machines are independent operating environments that that function as separate computers. These have no access to host operating systems. They provide system independence and increased system security. JVMs are platform independent and translate Java bytecode into language that is intelligible to the machines that can process its requests. These requests can be processed regardless of server operating systems. Through this sort of RPC implementation, JVMs can only communicate with other JVMs.

The original protocol supporting this sort of communication is Java Remote Method Protocol or JRMP. CORBA developed a protocol later to run in non-Java environments. RMI is used to suggest either the API or the JRMP or both at the same time. The second implementation is RMI-IIOP Internet Inter-ORB Protocol. It refers to the implementation of RMI over CORBA systems. By replacing the Object by Value (OBV) concept that contains CORBA structures, arrays, strings and sequences, RMI-IIOP generates code from remote objects. By using the same GIOP (General Inter-ORB Protocol). Therefore, while IDL is not the main language creating interfaces for this type of exchange, it can be mobilized for increased interoperability between RMI-IIOP and CORBA applications.