Common Object Request Broker Architecture (CORBA) is a specification proposed by the Object Management Group (OMG)–a nonprofit industry consortium formed in 1989 with the following goals [Soley 1994]:

Figure 7.3 Interface Definition Language in Action

DEC, HP, IBM, and Sun were among the original members of OMG, which has exceeded more than 500 members ranging from hardware vendors to end users. Interestingly, OMG was formed before any major products were introduced. (Most standards bodies are formed to develop standards after products are already in use. For example, ISO/OSI Reference Model for networks was introduced in 1977, almost five to seven years after the introduction of SNA, Decnet, and TCP/IP.) OMG’s first attempt at meeting its goals resulted in an Object Management Architecture (OMA), released in 1990; it was revised in 1992. OMA specified the overall object model for distributed-object computing environments, including how objects are defined and created, how client applications invoke objects, and how objects can be shared and reused.The four components of this management architecture are (see Figure 7.4):

Figure 7.4 Object-Management Architecture

It is important to note that the Application Objects, Common Facilities, and Object Services are simply categories of objects. Every piece of software in the OMA model is represented as an object that communicates with other objects via the object-request broker. These objects were grouped into three broad categories to ease the standardization process.

CORBA was introduced in 1991 by OMG to go a step beyond OMA to specify the technology for interoperable distributed OO systems. CORBA specifications represent the ORB technology adopted by OMG and are published as OMG documents. The key concepts of CORBA are (see Figure 7.5):

Let us now go through the main components of Figure 7.5 and show how they interrelate with each other. Let us start from the left.

Figure 7.5 CORBA Components and Interfaces

Dynamic Invocation Interface. This interface allows dynamic construction of object invocation. The interface details are filled in by consulting with the interface repository and or other run-time sources. By using the dynamic invocation, client application 1 can interact with server objects (provided descriptions of these server objects could be found in the interface repository).

Client IDL Stubs. The client stubs make calls to the ORB core. These precompiled stubs make it easier for the clients to issue static requests to objects across a network (see the sidebar "What Are Stubs?") Client application 2 uses this option.

Object Adapters. An object adapter allows an object implementation to access the ORB services. Services provided by the ORB through an adapter often include security interaction, method invocation, and generation of object IDs (object references). CORBA specifies that each ORB must support a standard adapter called the basic object adapter (BOA). Server objects use object adapters. CORBA supports different kinds of object adapters.

Server IDL Stub. These stubs, also known as server skeletons, provide the code that invokes specific server methods. These stubs are generated as part of the IDL compilation and are very similar to the client IDL stubs. They provide the interface between object adapters and the server application code. Server Objects use this stub.

Object-Request Broker (ORB). ORB is obviously at the heart of CORBA. ORB acts as a switch in a CORBA environment–it sets up links between remote objects and routes the messages between objects. Any client object can make a request from a server object through the ORB and any server object can send responses back to the client objects through ORB. We will discuss ORB in more detail in the next section.

Interface Repository. A dynamic representation of available object interfaces is provided in an interface repository. This repository represents the interfaces (or classes) of all objects in the distributed environment. The clients access the interface repository to learn about the server objects and determine what type of operations can be invoked on an object.

Implementation Repository. Implementation details of each interface, including the operating-system-specific information used for invocation, the attributes used for method selection, and the methods that make up the implementation, are loaded into the implementation repository. The implementation repository can be implemented differently by different vendors. Some implementations of CORBA support IML (implementation mapping language) to describe the implementation details.

As defined by the OMG, the ORB provides mechanisms by which objects transparently interact with each other. It enables the objects to establish connections, communicate with one another, make requests, and receive responses. To achieve this, ORB sets up communications links and routes information between objects as needed. It literally provides brokerage services between clients and servers by determining the most efficient way for a client to receive a service and for a server to provide the service. The interfaces to the ORB and the interfaces to the objects built using the ORB are well defined. The underlying implementation of the ORB is not important to the developers building distributed-object-oriented applications. Different interfaces can be defined for an object, and multiple ORBs can exist in a system. Thus different client applications can refer to the same object residing on a server, but each client application can be given its own interface.

Figure 7.6 shows a few more details about the structure of an object-request broker (ORB) and the interfaces to the ORB. The arrows indicate whether the ORB is called or performs an up-call across the interface. The client can use the dynamic invocation interface or an IDL stub (determined at compile time). The client can also directly interact with the ORB for operations. The object implementation (the server) receives a request from the ORB through the IDL-generated skeleton. The object implementation may need to call the object adapter and the ORB while processing a request.

Figure 7.6 The Structure of Object-Request Broker Interfaces

We have already reviewed most of the ORB interfaces shown in Figure 7.6. However, we have not yet described the ORB interface. Basically, this interface goes directly to the ORB for operations that are common across all objects. It consists of a few APIs to local services that may be of interest to some applications. The interface is commonly used by a server object to tell the ORB that it is running and ready to accept calls.

Static versus Dynamic Binding. CORBA ORBs allow static as well as dynamic binding between objects. From a developer’s point of view, each serves the same purpose (i.e., establishes a link between a client and server object for invoking an operation). However, a developer chooses between these two options, depending on how much information is available at compile time. The static binding between objects is based on compile-time specification of objects and parameters. Static binding, initially proposed by HP and Sun, is more efficient at run time because all needed libraries are included at compile time. It is also quite simple (a C call with parameters which specify the object to be invoked, the environment of the object, and any other values needed by the server object). On the other hand, dynamic binding between objects uses run-time identification of objects and parameters. Dynamic binding, initially proposed by DEC, incurs more overhead at run time but is very flexible (it can be used when some of the information needed to complete an operation is not available at compile time). Dynamic binding needs extensive run-time support (i.e., a repository that can be accessed at run time to locate objects). It is particularly useful for applications that are undergoing rapid changes or for a tool to support interactive browsing.

Interface Definition Language. CORBA includes a single object model embodied in IDL and uses a single specification language, the OMG Interface Definition Language (IDL), to specify the services provided by an object. The CORBA IDL is similar in principle to the OSF DCE IDL, especially when static binding is used. The parameters needed for each task are specified for static as well as dynamic binding. OMG IDL syntax resembles C++. IDL compilers are being provided by vendors. CORBA API is also defined in IDL. The IDL itself does not say anything about implementation of an interface; however, all CORBA products generate bindings in languages such as C, C++, and Smalltalk. IDL definitions are stored in a public interface directory. Access to this repository can be controlled through access control lists (ACLs). CORBA also specifies language bindings, i.e., mapping of IDL constructs to programming languages.

Object adapters provide the primary mechanism for an object server to access the ORB services. Specifically, object adaptors provide services such as registering server classes with the implementation repository; creating object instances to handle incoming client calls; assigning unique IDs, known as object references, to the newly created objects; broadcasting the availability of object servers; and handles the incoming client calls by passing them along to the server stub (skeleton).

A variety of object adapters can be envisioned to support different types of requests (see Figure 7.7). To avoid proliferation of too many object adapters, OMG has specified a basic object adapter (BOA) that can be used for most ORB object servers. A BOA is required by CORBA in every ORB, so that an object server based on BOA can be used by any ORB. A BOA provides functions such as support of an implementation repository, facilities for generating and interpreting object references, identification (authentication) of the client (or principal) who submitted the request, activation and deactivation of server objects, and method invocation through the server stubs. BOA supports many scheduling policies to support different types of object servers. Examples of the scheduling policies are shared server (i.e., one server handles multiple clients calls), unshared server (i.e., new server is started when a request is made for an object that is not yet active), server per method (i.e, new server is started each time a request is made), and persistent server (servers are activated by means outside BOA).

Some object adapters are being developed for specialized CORBA situations. For example, an adaptor for accessing objects in OODBMs is being considered. In addition, a "streams adaptor" has been proposed to OMG to handle distributed-multimedia applications over CORBA (see next chapter for additional information).

Figure 7.7 Object Adapter in CORBA

Let us quickly review the overall process used in building CORBA applications to illustrate the key concepts. (A more detailed example with code samples is given in Section 7.15.) The activities involved in developing OO applications in CORBA environments involve the following major activities (see Figure 7.8):

Figure 7.8 CORBA Application Development

Create CORBA Definitions. The main activity in this step is creation of interface definitions in the CORBA IDL format by using a text editor. The IDL statements are compiled by using an IDL compiler. The IDL definitions can be kept in text files or be stored in an interface repository, so that the clients can learn about the server objects and determine what type of operations can be invoked on an object. As stated previously, the interface of an object is used to declare the operations supported by an object. It consists of a collection of the operations and their signatures, i.e., the operation’s name, its arguments, and argument types. For example, the following statements specify the interface for a bank-account object in CORBA IDL (we have simplified it somewhat for illustrative purposes):

The interface statement shows what operations can be performed on the order object. Each interface statement defines an interface and contains the descriptions of the operations (operation signatures).

In addition to IDL, the implementation details of each interface are created. You can use CORBA commands to generate a default implementation description from the interface definition.These implementations are loaded into the implementation repository.

After you create the interface definition using IDL, you compile the IDL file to create two very important components for building your application: the client stub and the server skeleton. The client stub and server skeleton are the code templates for building CORBA client and server programs (see Figure 7.8). The client stub is used only to build client programs that use static binding, i.e., the client code is linked with the client stub to form the client application. The client stub is not used to build client programs that use dynamic invocation. The server skeleton is always used as the framework for building the server application, regardless of the invocation type used by the client.

Build the Server. CORBA servers can be quite complex and diverse. Building of program servers requires the following steps:

Build Clients (Static and Dynamic). After a server has been built and registered, clients can be built to invoke the servers. As stated previously, CORBA clients can use static invocations (i.e., clients know at compile time the objects and the operations on these objects) or dynamic invocation (i.e., the clients determine at run time the objects and the operations on these objects). Static invocation has several advantages over dynamic invocations. First, it is easier to program–you call the remote method by simply invoking it by name and passing it the parameters. Second, it provides more robust type checking, because the compiler enforces type checking at build time. Finally, it performs well and is self-documenting. The main steps involved in building a static invocation CORBA client are (a) generate client stub from IDL or from the interface repository (b) build the client code, and (c) compile and link the client. Building a client for dynamic invocation involves the following steps: (a) obtain the method description from the interface repository (b) create the argument list (c) create the request, and d) invoke the request. CORBA specifies a set of API calls for locating and obtaining objects from the repository.

Deploy and Run the Application. CORBA applications can be packaged and shipped as server only, client only, or a collection of clients and servers. To accomplish this, you need to send your IDL implementation specifications, in addition to the executables. The application is installed and used in a CORBA run-time environment (see Figure 7.9). The IDLs and IML (implementation mapping language) are loaded into the interface and implementation repositories first. Then the server is installed. At server start-up, it registers itself so that the invoking clients can locate it. The dynamic invocation interface allows dynamic construction of object invocation. The interface details are filled in by consulting with the interface repository and or other run-time sources. The client IDL stubs make calls to the ORB, using interfaces, and make it easier for the clients to issue static requests to objects across a network. Object adapters allow an object implementation to access the ORB services. CORBA specifies that each ORB must support a standard adapter called the basic object adapter (BOA). Server skeletons (server IDL stubs) provide the static interfaces to each service supported by the server.

Figure 7.9 CORBA Run-Time Environment

Initial specifications of CORBA (i.e., CORBA 1.1 and 1.2) did not specify many important services, such as security, concurrency, and transaction processing. This had two major consequences. First, the CORBA-based applications were limited in scope (e.g., they provided no security). Second, different vendors chose to plug different services (many built ORBs on top of OSF DCE, thus using the DCE facilities of security, etc.). This has led to CORBA implementations by vendors that do not interoperate with each other (recall that interoperability is the main goal of CORBA!). ORBs from different vendors interoperate with each other only through deliberate efforts and joint agreements between vendors.

CORBA 2.0, introduced in December 1994, addressed these problems by adding many new services. Examples of CORBA 2.0 services are shown in Figure 7.10 (CORBA 2.0 is a superset of CORBA 1.2). Basically, the ORB 2.0 has added some capabilities. However, most of the new capabilities have been added in the distributed-object services of CORBA. These capabilities are discussed in Sections 7.3.7 through 7.3.9.

CORBA 2.0 addresses the problem of ORB interoperability by defining inter-ORB protocols (IOPs) for interoperability of object-request brokers. Although the IOPs do not impact application software development (IOPs are too low level for applications), they play a key role in an overall middleware architecture. We briefly review IOPs in Section 7.3.10.

Figure 7.10 CORBA 2.0 Facilities (The Object-Management Architecture

ORB 2.0 has extended the features of earlier ORBs (see Figure 7.11). Basically, the interface repository has been expanded and a new interface (dynamic skeleton interface) for servers has been added.

ORB 2.0 Interface Repository. CORBA provides an interface repository that keeps track of all registered interfaces, the methods provided by each interface, and the parameters required for each method (these are the method signatures). A set of APIs are provided so that application programs can retrieve, and if authorized, modify the interface definitions. With CORBA 2.0, the interface repositories provide global identifiers to uniquely and globally identify a component and its interface across multivendor ORBs. This is accomplished through repository IDs. A repository ID is a unique, system-generated, string that is used across interface repositories. You can generate repository IDs by using the DCE Universal Unique Identifiers (UUIDs) or via a user-supplied unique prefix that is appended to IDL generated names.

Dynamic Skeleton Interface (DSI). The DSI provides a run-time binding for servers that do not have IDL generated stubs. These dynamic skeletons can be very useful for scripting languages to dynamically generate server objects. When invoked, the DSI determines the server object to be invoked and the method to be invoked (the selection is based on parameters values supplied by an incoming message). In contrast, the server skeletons generated through IDL compiles are defined for a certain object class and expect a method implementation for each method specified in the IDL. The DSI can receive calls from static or dynamic client invocations.

Figure 7.11 ORB 2.0 Structure

The (distributed) object services are packaged as components with IDL-specified interfaces. These services augment the ORB functionality by providing easy mechanisms for creating,

naming, and including new components into the CORBA environment. CORBA 2.0 specifies standards for the following object services:

Other object services such as change management, trader, and collections are being defined at the time of this writing.

You may be thinking that not all applications need all these services. In fact, only needed services can be included at system-configuration time. These object services provide a powerful set of capabilities for creating customized middleware. For example, a CORBA "heavy" middleware can be built for transaction management with high security and concurrency requirements by including the CORBA transaction, security, and concurrency-control services. On the other hand, a CORBA "light" middleware can be created by ignoring many object services.

The CORBA common facilities are IDL-defined components that are common to different classes of applications. The line between common facilities and object services is somewhat fuzzy. Basically, OMG is defining vertical as well as horizontal facilities. For example, vertical facilities will provide IDL-defined interfaces for vertical markets such as finance, telecommunications, and health. Examples of horizontal facilities are user interfaces, information-management services such as compound documents, systems management facilities for managing distributed systems, and task management such as workflow. The vertical as well as horizontal facilities are being developed gradually.

As specified previously, initial specifications of CORBA (i.e., CORBA 1.1 and 1.2) did not specify many implementation details such as security. This has led to CORBA implementations by vendors that do not interoperate with each other. In particular, ORBs based on CORBA 1.1 and 1.2 from different vendors interoperate with each other only through joint agreements and partnerships between vendors. CORBA 2.0 addressed this problem by defining inter-ORB protocols (IOPs) for interoperability of object-request brokers. For existing ORBs that do not interoperate, OMG is specifying an API for adding bridges between ORBs.

The IOP specifications are significant feature of CORBA 2.0 because they allow ORBs, potentially from different suppliers, to interoperate with each other. These specifications do not impact application developers (application programmers will typically not write code at

this level), but they do play an important role in how an application developed on one ORB can interoperate with an application developed on another ORB. Figure 7.12 shows the principal IOPs and depicts how they interrelate with each other.

Figure 7.12 CORBA 2.0 Inter-ORB Architecture

General Inter-ORB Protocol (GIOP). This IOP specifies a set of message formats and common data representations for interactions between ORBs. The GIOP is especially designed for ORB-to-ORB communications. It is intended to operate over any connection-oriented transport protocol. The common data representation (CDR) is used to map OMG IDL data types (pointers and linked lists) into a "flattened" network message that can be transported over the network. GIOP also specifies a format for interoperable object references so that a given object can be accessed from different ORBs.

Internet Inter-ORB Protocol (IIOP). This IOP specifies how GIOP messages are exchanged over a TCP/IP network. IIOP allows a lightweight implementation of CORBA so that CORBA can operate directly on top of TCP/IP and not on top of DCE. IIOP is a required feature of CORBA 2.0. In other words, an ORB must support IIOP to be CORBA 2.0 compliant. In the future, GIOP specifications on top of IPX/SPX and OSI may be developed.

Environment-Specific Inter-ORB Protocols (ESIOPs). These IOPs are an alternative to GIOP and are specified for specific environments. CORBA 2.0 has specified DCE as the first of many optional ESIOPs. DCE/ESIOP does not require DCE IDL (OMG IDL does the job). The DCE/ESIOP includes many features that are important for mission-critical applications. Examples of these features are the DCE security, cell and global directories, authenticated RPCs, and distributed time services (all these features are part of OSF DCE). However, this makes CORBA 2.0 applications heavyweight ("CORBA Heavy"). In the future, ESIOPs may be specified for other environments.

CORBA 2.0 provides facilities for developing generic ORB-to-ORB bridges. These bridges come in two flavors: half bridges and full bridges. Figure 7.13 shows these bridges.

ORB Half Bridges. An ORB half bridge relies on a common ORB (the "backbone" ORB) to interconnect different ORBs. For example, Figure 7.13(a) shows how an IIOP backbone can be used to interconnect different proprietary ORBs. The key point is that your ORB needs to communicate with an IIOP through a half bridge that translates your ORB to IIOP. After this, the IIOP can be used as a "global ORB" bus. Keep in mind that IIOP runs on top of the Internet. The ORB half bridges are similar to the gateways used in networks that convert different network protocols (e.g., SNA, SPX/IPX, OSI) to a backbone network protocol (e.g., TCP/IP). Half bridges allow a federation of different ORBs around an IIOP backbone.

Figure 7.13 ORB-to-ORB Bridges

ORB Full Bridges. The full bridges directly convert one ORB to another without requiring a common backbone ORB. The CORBA 2.0 Dynamic Skeleton Interface (DSI) is used to receive outgoing messages and the Dynamic Invocation Interface (DII) is used to receive inputs and invoke destination objects–see Figure 7.13(b). Thus an ORB from one vendor can communicate with an ORB from another vendor directly. This approach is used in some bridges such as CORBA/OLE bridges [Orfali 1996].

Object-oriented technologies and techniques have natural applications in distributed systems. Entities in distributed systems can be viewed as objects exchanging messages. OMG was formed to create a suite of standard languages, interfaces, and protocols for interoperability of applications in heterogeneous distributed environments. CORBA is an OMG specification for invoking objects in a distributed environment.

Initial specifications of CORBA did not specify many implementation details such as security and transaction processing protocol. This has led to CORBA implementations by vendors that do not interoperate with each other. CORBA 2.0 has added many additional capabilities and has specified APIs for adding bridges between ORBs. For example, CORBA 2.0 specifies several important areas such as security, concurrency, transactions, and replication. There are different opinions about how CORBBA 2.0 will actually succeed (see Orfali [1996] and Shelton [1994] for an analysis of CORBA 2.0).

Many vendors are announcing CORBA-compliant software. Examples are the Distributed Systems Object Model (DSOM) from IBM, Distributed Objects Everywhere (DOE) from SUN, ObjectBroker from Digital, and Object Request Broker (Orbix) from Iona Corporation. In addition, as we will see in the next section, CORBA plays an important role in the composite document standards, because these standards are based on object-oriented concepts. An area of considerable activity is combining CORBA with the Web (see the sidebar "CORBA and the Web").

Additional details about CORBA can be found in the books [Siegel 1996, Orfali 1996, Mowbray 1995, Otte 1996]. The OMG home page (http://www.omg.org) is an excellent source of the recent activities in CORBA.

Although we have concentrated on the object-request brokers so far, the concept of brokers is general and is currently exploited in the message broker architectures (see sidebar "Message Broker: Another Kind of Broker").