Common Object Request Broker Architecture

By Kurt Wallnau, SEI

We recommend Object Request Broker, as prerequisite reading for this technology description.
The Common Object Request Broker Architecture (CORBA) is a specification of a standard architecture for object request brokers (ORBs) (see Object Request Broker). A standard architecture allows vendors to develop ORB products that support application portability and interoperability across different programming languages, hardware platforms, operating systems, and ORB implementations:

"Using a CORBA-compliant ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call, and is responsible for finding an object that can implement the request, passing it the parameters, invoking its method, and returning the results of the invocation. The client does not have to be aware of where the object is located, its programming language, its operating system or any other aspects that are not part of an object's interface". The "vision" behind CORBA is that distributed systems are conceived and implemented as distributed objects. The interfaces to these objects are described in a high-level, architecture-neutral specification language that also supports object-oriented design abstraction. When combined with the Object Management Architecture (see Technical Detail), CORBA can result in distributed systems that can be rapidly developed, and can reap the benefits that result from using high-level building blocks provided by CORBA, such as maintainability and adaptability.

The CORBA specification was developed by the Object Management Group (OMG), an industry group with over six hundred member companies representing computer manufacturers, independent software vendors, and a variety of government and academic organizations. Thus, CORBA specifies an industry/consortium standard, not a "formal" standard in the IEEE/ANSI/ISO sense of the term. The OMG was established in 1988, and the initial CORBA specification emerged in 1992. Since then, the CORBA specification has undergone significant revision, with the latest major revision (CORBA v2.0) released in July 1996.

Technical Detail

CORBA ORBs are middleware mechanisms (see Middleware), as are all ORBs. CORBA can be thought of as a generalization of remote procedure call (RPC) that includes a number of refinements of RPC, including:

• a more abstract and powerful interface definition language
• direct support for a variety of object-oriented concepts
• a variety of other improvements and generalizations of the more primitive RPC

CORBA and the Object Management Architecture. It is impossible to understand CORBA without appreciating its role in the Object Management Architecture (OMA), shown in Figure 1. The OMA is itself a specification (actually, a collection of related specifications) that defines a broad range of services for building distributed applications. The OMA goes far beyond RPC in scope and complexity. The distinction between CORBA and the OMA is an important one because many services one might expect to find in a middleware product such as CORBA (e.g., naming, transaction, and asynchronous event management services) are actually specified as services in the OMA. For reference, the OMA reference architecture encompasses both the ORB and remote service/object depicted in Middleware.

Figure 1: Object Management Architecture

OMA services are partitioned into three categories: CORBAServices, CORBAFacilities, and ApplicationObjects. The ORB (whose details are specified by CORBA) is a communication infrastructure through which applications access these services, and through which objects interact with each other. CORBAServices, CORBAFacilities, and ApplicationObjects define different categories of objects in the OMA; these objects (more accurately object types) define a range of functionality needed to support the development of distributed software systems.

• CORBAServices are considered fundamental to building non-trivial distributed applications. These services currently include asynchronous event management, transactions, persistence, externalization, concurrency, naming, relationships, and lifecycle. Table 1 summarizes the purpose of each of these services.
• CORBAFacilities may be useful for distributed applications in some settings, but are not considered as universally applicable as CORBAServices. These "facilities" include: user interface, information management, system management, task management, and a variety of "vertical market" facilities in domains such as manufacturing, distributed simulation, and accounting.
• Application Objects provide services that are particular to an application or class of applications. These are not (currently) a topic for standardization within the OMA, but are usually included in the OMA reference model for completeness, i.e., objects are either application-specific, support common facilities, or are basic services.

Table 1: Overview of CORBA Services

Naming Service	Provides the ability to bind a name to an object. Similar to other forms of directory service.
Event Service	Supports asynchronous message-based communication among objects. Supports chaining of event channels, and a variety of producer/consumer roles.
Lifecycle Service	Defines conventions for creating, deleting, copying and moving objects.
Persistence Service	Provides a means for retaining and managing the persistent state of objects.
Transaction Service	Supports multiple transaction models, including mandatory "flat" and optional "nested" transactions.
Concurrency Service	Supports concurrent, coordinated access to objects from multiple clients.
Relationship Service	Supports the specification, creation and maintenance of relationships among objects.
Externalization Service	Defines protocols and conventions for externalizing and internalizing objects across processes and across ORBs.

CORBA in detail. Figure 2 depicts most of the basic components and interfaces defined by CORBA. This figure is an expansion of the ORB component of the OMA depicted in Figure 1.

Figure 2: Structure of CORBA Interfaces

One element (not depicted in Figure 1) that is crucial to the understanding of CORBA is the interface definition language (IDL) processor. All objects are defined in CORBA (actually, in the OMA) using IDL. IDL is an object-oriented interface definition formalism that has some syntactic similarities with C++. Unlike C++, IDL can only define interfaces; it is not possible to specify behavior in IDL. Language mappings are defined from IDL to C, C++, Ada95, and Smalltalk80.

An important point to note is that CORBA specifies that clients and object implementations can be written in different programming languages and execute on different computer hardware architectures and different operating systems, and that clients and object implementations can not detect any of these details about each other. Put another way, the IDL interface completely defines the interface between clients and objects; all other details about objects (such as their implementation language and location) can be made "transparent."

Table 2 summarizes the components of CORBA and their functional role.

Table 2: Components of the CORBA Specification

ORB Core	The CORBA runtime infrastructure. The interface to the ORB Core is not defined by CORBA, and will be vendor proprietary.
ORB Interface	A standard interface (defined in IDL) to functions provided by all CORBA- compliant ORBs.
IDL Stubs	Generated by the IDL processor for each interface defined in IDL. Stubs hide the low-level networking details of object communication from the client, while presenting a high-level, object type-specific application programming interface (API).
Dynamic Invocation Interface (DII)	An alternative to stubs for clients to access objects. While stubs provide an object type-specific API, DII provides a generic mechanism for constructing requests at run time (hence "dynamic invocation"). An interface repository (another CORBA component not illustrated in Figure 2) allows some measure of type checking to ensure that a target object can support the request made by the client.
Object Adaptor	Provides extensibility of CORBA- compliant ORBs to integrate alternative object technologies into the OMA. For example, adaptors may be developed to allow remote access to objects that are stored in an object-oriented database. Each CORBA-compliant ORB must support a specific object adaptor called the Basic Object Adaptor (BOA) (not illustrated in Figure 2). The BOA defines a standard API implemented by all ORBs.
IDL Skeletons	The server-side (or object implementation-side) analogue of IDL stubs. IDL skeletons receive requests for services from the object adaptor, and call the appropriate operations in the object implementation.
Dynamic Skeleton Interface (DSI)	The server-side (or object implementation-side) analogue of the DII. While IDL skeletons invoke specific operations in the object implementation, DSI defers this processing to the object implementation. This is useful for developing bridges and other mechanisms to support inter-ORB interoperation.

Usage Considerations

Compliance. As noted, CORBA is a specification, not an implementation. Therefore, the question of compliance is important: How does a consumer know if a product is CORBA-compliant, and, if so, what does that mean? CORBA compliance is defined by the OMG:

"The minimum required for a CORBA-compliant system is adherence to the specifications in CORBA Core and one mapping" where "mapping" refers to a mapping from IDL to a programming language (C, C++ or Smalltalk80; Ada95 is specified but has not been formally adopted by the OMG at the time of this writing). The CORBA Core (not the same as the ORB Core denoted in Figure 2 and Table 2) is defined for compliance as including the following:

• the interfaces to all of the elements depicted in Figure 2
• interfaces to the interface repository (not shown in Figure 2)
• a definition of IDL syntax and semantics
• the definition of the object model that underlies CORBA (e.g., what is an object, how is it defined, where do they come from)

Significantly, the CORBA Core does not include CORBA interoperability, nor does it include interworking, the term used to describe how CORBA is intended to work with Microsoft's COM (see Component Object Model (COM), DCOM, and Related Capabilities). A separate but related point is that CORBA ORBs need not provide implementations of any OMA services.

There are as yet no defined test suites for assessing CORBA compliance. Users must evaluate vendor claims on face value, and assess the likelihood of vendor compliance based upon a variety of imponderables, such as the role played by the vendor in the OMG; vendor market share; and press releases and testimonials. Hands-on evaluation of ORB products is an absolute necessity. However, given the lack of a predefined compliance test suite, the complexity of the CORBA specification (see next topic), and the variability of vendor implementation choices, even this will be inadequate to fully assess "compliance."

Although not concerned with compliance testing in a formal sense, one organization has developed an operational testbed for demonstrating ORB interoperability. It is conceivable that other similar centers may be developed that address different aspects of CORBA (e.g., real time, security), or that do formal compliance testing. However, no such centers exist at the time of this writing.

Complexity. CORBA is a complex specification, and considerable effort may be required to develop expertise in its use. A number of factors compound the inherent complexity of the CORBA specification.

• While CORBA defines a standard, there is great latitude in many of the implementation details- ORBs developed by different vendors may have significantly different features and capabilities. Thus, users must learn a specification, the way vendors implement the specification, and their value-added features (which are often necessary to make a CORBA product usable).
• While CORBA makes the development of distributed applications easier than with previous technologies, this ease of use may be deceptive: The difficult issues involved in designing robust distributed systems still remain (e.g., performance prediction and analysis, failure mode analysis, consistency and caching, and security).
• Facility with CORBA may require deep expertise in related technologies, such as distributed systems design, distributed and multi-threaded programming and debugging; inter-networking; object-oriented design, analysis, and programming. In particular, expertise in object-oriented technology may require a substantial change in engineering practice, with all the technology transition issues that implies (see The Technology Adoption Challenge).

Stability. CORBA (and the OMA) represent a classical model of distributed computing, despite the addition of object-oriented abstraction. Recent advances in distributed computing have altered the landscape CORBA occupies. Specifically, the recent emergence of mobile objects via Java , and the connection of Java with "web browser" technologies has muddied the waters concerning the role of CORBA in future distributed systems. CORBA vendors are responding by supporting the development of "ORBlets", i.e., Java applets that invoke the services of remote CORBA objects. However, recent additions to Java support remote object invocation directly in a native Java form. The upshot is that, at the time of this writing, there is great instability in the distributed object technology marketplace.

Industry standards such as CORBA have the advantage of flexibility in response to changes in market conditions and technology advances (in comparison, formal standards bodies move much more slowly). On the other hand, changes to the CORBA specifications- while technically justified- have resulted in unstable ORB implementations. For example, CORBA v2.0, released in July 1995 with revisions in July 1996, introduced features to support interoperation among different vendor ORBs. These features are not yet universally available in all CORBA ORBs, and those ORBs that implement these features do so in uneven ways. Although the situation regarding interoperation among CORBA ORBs is improving, instability of implementations is the price paid for flexibility and evolvability of specification.

The OMA is also evolving, and different aspects are at different maturity levels. For instance, CORBAFacilities defines more of a framework for desired services than a specification suitable for implementation. The more fundamental CORBAServices, while better defined, are not rigorously defined; a potential consequence is that different vendor implementations of these services may differ widely both in performance and in semantics. The consequence is particularly troubling in light of the new interoperability features; prior to inter-ORB interoperability the lack of uniformity among CORBAServices implementations would not have been an issue.

Maturity

A large and growing number of implementations of CORBA are available in the marketplace, including implementations from most major computer manufacturers and independent software vendors. See Object Request Broker for a listing of available CORBA-compliant ORBs. CORBA ORBs are also being developed by university research and development projects, for example Stanford's Fresco, XeroxPARC's ILU, Cornell's Electra, and others.

At the same time, it must be noted that not all CORBA ORBs are equally mature, nor has the OMA sufficiently matured to support the vision that lies behind CORBA (see Purpose and Origin). While CORBA and OMA products are maturing and are being used in increasingly complex and demanding situations, the specifications and product implementations are not entirely stable. This is in no small way a result of the dynamism of distributed object technology and middleware in general and is no particular fault of the OMG. Fortunately techniques exist for evaluating technology in the face of such dynamism.

Costs and Limitations

Costs and limitations include the following:

• Real time. CORBA v2.0 does not address real-time issues.
• Programming language support. IDL is a "least-common denominator" language. It does not fully exploit the capabilities of programming languages to which it is mapped, especially where the definition of abstract types is concerned.
• Pricing and licensing. The price of ORBs varies greatly, from a few hundred to several thousand dollars. Licensing schemes also vary.
• Training. Training is essential for the already experienced programmer: five days of hands-on training for CORBA programming fundamentals is suggested.
• Security. CORBA specifies only a minimal range of security mechanisms; more ambitious and comprehensive mechanisms have not yet been adopted by the OMG. Deng discusses the potential integration of security into CORBA-based systems.

Dependencies include the following:

• TCP/IP is needed to support the CORBA-defined inter-ORB interoperability protocol (IIOP).
• Most commercial CORBA ORBs rely on C++ as the principal client and server programming environment. Java-specific ORBs are also emerging.

Alternatives

• The Open Group's Distributed Computing Environment (DCE) is sometimes cited as an alternative "open" specification for distributed computing (see Distributed Computing Environment).
• Where openness is not a concern and PC platforms are dominant, Microsoft's COM/DCOM (see Component Object Model (COM), DCOM, and Related Capabilities) may be suitable alternatives.
• Other middleware technologies may be appropriate in different settings (e.g., message-oriented middleware (see Message-Oriented Middleware)).

Complementary technologies include the following:

• Java and/or web browsers can be used in conjunction with CORBA, although precise usage patterns have not yet emerged and are still highly volatile.
• Object-oriented database management systems (OODBMS) vendors are developing object adaptors to support more robust three-tier architecture (see Three Tier Software Architectures) development using CORBA.