Distributed Objects Using CORBA

CORBA objects are distributed chunks of code that can live anywhere on a network. These objects are packaged as binary components that can be accessed by clients regardless of the programming language, compiler, operating system, or underlying hardware architecture used. What makes such a heterogeneous environment work transparently is CORBA's Interface Definition Language (IDL). Every CORBA object has an interface defined by IDL. The CORBA IDL is purely declarative; it specifies interfaces and not implementations . At present, CORBA IDL bindings have been written for C, C++, Ada, Smalltalk, COBOL, and most recently, Java. This means a COBOL programmer, with absolutely no knowledge of Java, can take advantage of the services provided by a Java object executing on a server halfway across the world. What makes this all possible are CORBA-compliant Object Request Brokers (ORBs) communicating via the CORBA Internet Inter-ORB Protocol (IIOP). Figure 21-1 shows how this works.

Figure 21-1. IIOP Enables Multi-Language Application Support

One of the keys to the Object Management Group 's success has been that it produces only CORBA specifications, not implementations. Any vendor is able to join OMG and create his or her own CORBA implementations. These implementations are all based on the Object Management architecture. There are four main components to this architecture:

An Object Request Broker, which implements the CORBA communication bus
CORBA Services, which define system level object frameworks that extend this bus
CORBA Facilities, which define vertical and horizontal application frameworks used by CORBA objects
CORBA Application Objects business objects and applications using the CORBA facilities and CORBA services

A CORBA Object Request Broker is similar to traditional Remote Procedure Call (RPC) mechanisms in that both create a communication channel between two software objects. However, this is where the similarities end. With a remote procedure call, a client program simply calls a specific function on a remote host. Following an object-oriented paradigm, an ORB is used to invoke a method within a specific object, typically on a remote host. Different object classes may respond to the same method invocation differently because of object polymorphism. In addition, CORBA ORBs provide an entire layer of additional services over and above the basic communication services provided by a remote procedure call mechanism. Here are some of the additional middleware services provided by CORBA ORBs.

Static and dynamic method invocations.

RPCs allow only static (pre-compiled) method invocations. An ORB allows clients to dynamically determine the methods callable on a remote object and the parameters necessary to invoke these methods .
High-level language bindings.

CORBA IDL bindings are available for C, C++, COBOL, Ada, Smalltalk, and Java. A client does not need to know, and in fact does not care, what language the server is written in. The CORBA IDL compiler creates the necessary code to translate method calls and parameters between the native language and a neutral intermediate format.
A self-describing interface repository.

Everything in a CORBA ORB is self-describing and kept in a public repository.
Local/remote transparency.

A CORBA client invokes server calls on a remote server exactly as it would on a local server. In fact, the client does not typically know if the server is local or remote.
Built-in security and transactions.

CORBA services provide such commonly required services as security and a transaction capability.
Polymorphic messaging.

The same method, sent to two different types of server objects, may have entirely different results. This type of polymorphism is a basic capability expected by most object-oriented systems.
Coexistence with existing systems.

Not only does CORBA provide different high level language bindings, it co-exists and interoperates with other object systems such as DCOM and Java.

CORBA Services

Every CORBA implementation provides a set of standard services packaged with IDL specified interfaces. These services are used, for instance, to create objects, name objects, and introduce them into the CORBA environment. The Object Management Group has specified fifteen standard CORBA services as of the CORBA 2.0 specification.

The Life Cycle Service defines operations for creating, deleting, moving, and copying CORBA components.
The Persistence Service defines a common interface for storing objects using a variety of underlying data stores including flat files, relational databases, and object databases.
The Naming Service defines a mechanism to locate objects by name. It supports interfaces to the most common existing name service protocols including X.500, DCE (from the OSF), NIS+ (from Sun), NDS (from Novell), and the internet standard LDAP.
The Event Service defines an "event channel" that allows objects to dynamically register or unregister for specific events. The event channel collects and distributes events among objects without requiring these objects to have any pre-determined knowledge about themselves .
The Concurrency Control Service defines a lock manager for use by either threads or transactions.
The Transaction Service defines a two-phase commit mechanism for use by objects.
The Relationship Service defines a mechanism for objects which know nothing about each other to create dynamic associations among themselves, allowing for referential integrity, object containment tracking, or other types of linkages as might be required by an object.
The Externalization Service defines a stream-like mechanism for object I/O.
The Query Service defines an object query mechanism. It is based on a combination of the SQL3 specification and the Object Query Language (OQL) of the Object Database Management Group.
The Licensing Service defines a mechanism for object licensing and metering, including support for various licensing schemes included per site, per node, per session, or per instance creation.
The Properties Service defines a mechanism for associating dynamic named values with any object.
The Time Service defines a time synchronization mechanism along with support for defining and managing time-triggered events.
The Security Service defines a framework for distributed object security. This includes authentication, access control lists, confidentiality, and non- repudiation .
The Trader Service defines a mechanism for objects to publicize their services and bid for jobs.
The Collection Service defines a mechanism for creating and manipulating common types of collections.

CORBA Facilities

CORBA Facilities form the next level of the OMG's Object Management architecture. Think of CORBA Facilities as groupings of CORBA objects organized into IDL-defined frameworks. There are two categories of CORBA Facilities, horizontal facilities and vertical facilities. These frameworks are intended to form an architecture upon which CORBA objects can effectively collaborate to perform some business function. To date, the common facilities being defined include mobile agents , data interchange, workflow, firewalls, business object frameworks, and internationalization. Further definition of these common frameworks will be included in the CORBA 3.0 specification.

CORBA Application Objects

Application objects are the business objects and applications that make up the final component of the OMG's Object Management architecture. Application objects are intended to describe application-independent concepts such as customers, orders, competitors , money, or payments. These business objects are intended to provide a development tool and application independent way of defining re-usable objects. The CORBA 3.0 specification will include additional work on the definition of application objects. This is one of the areas of CORBA technology that is most actively evolving. As this book goes to press, work is underway to link the definition of CORBA Application Objects to JavaBeans and Enterprise JavaBeans to provide a standard component model across both Java and CORBA.