[Up: Design and Implementation of]
[Previous: Evaluation] [Next: Interface Definition]

Object Request Broker

The Object Management Group (OMG) is a consortium comprised of both companies and institutions, with more than 700 members. Founded in 1989, the focus of the OMG is the continued work on the Object Management Architecture (OMA), an open specification of an infrastructure for distributed objects [62].

The OMG's approach [40] is unique in that it does not publish products, but specifications which are based on the experience of its members. When the need for a new specification arises, a Request for Proposal (RFP) is issued. OMG members can then submit proposals which are discussed in a forum, improved upon, and finally published or rejected. While votes are taken only from members, the resulting documents are freely available on the Internet and can be inspected, commented on and adapted by everyone.

In this process the OMG tries to achieve useful compromises between versatility and complexity. Solutions that have already been implemented are preferred, to avoid overly academic specifications that would be hard or impossible to implement. On the other hand, the discussion and peer review among the many OMG members tries to ensure that such a solution is fit for general use rather than only solving the problems seen by the submitters themselves.

Figure 3.1: The Object Management Architecture Reference Model

The basic structure of the Object Management Architecture is shown in figure 3.1. The building blocks of the OMA are objects belonging to one of four categories: system-oriented object services (for example, the Naming Service), horizontal common facilities (like collaboration), vertical domain-specific interfaces (like architectures for medical applications or air-traffic control systems) or application-specific interfaces [64].

The key component of the Object Management Architecture is the Object Request Broker, often called ``object bus,'' which allows communication among these objects by directing remote method invocations from client to server.

According to the requirements for a distribution platform as described in section 2.1, means for addressing, synchronization and encoding must be provided. CORBA uses the middleware approach as presented in section 2.4.2 employing three main concepts:

Interface Definition:

Fundamental to object-oriented programming, a client needs to know an object's public interface, so that it can invoke available methods with the appropriate parameters. Internal details are private to the object implementation and need not be described or published. In CORBA, interfaces are described using the Interface Definition Language, and information about interfaces can be stored in an Interface Repository.

Addressing:

A client needs some kind of address so that it knows where to send requests to. This address must contain enough information to identify one particular servant - a piece of user-provided code - that the client wants to communicate with. CORBA uses object references to address an object.

Invocation:

A client needs to be able to construct a request which is then transported to the server, evaluated, and returned. This can be done transparently with stub objects, which are generated from the interface definition. Invocations on a stub objects cause all parameters to be packaged into a request which is then transparently sent to the object implementation. Another option is the usage of the Dynamic Invocation Interface to build requests at runtime, possibly using runtime type information from the Interface Repository. Both means of invocation provide the required abstraction for synchronization and encoding.

Orthogonal to all of these three concepts is Interoperability, which, according to section 2.5, refers to the ability to communicate regardless of programming language, operating system or hardware.

[Previous: Evaluation] [Next: Interface Definition]
[Up: Design and Implementation of]