Object Management Architecture

In addition to the fundamental CORBA client/server architecture where the ORB^[1] functions as a request/reply communications mechanism, the CORBA specification also defines an overall architecture for building sophisticated applications. This overall architecture, called the Object Management Architecture (OMA), is designed to generically specify and provide a layered approach to building distributed applications using CORBA. The OMA is a simple but powerful architecture that uses the ORB as the basic distributed communications mechanism between all of its components. The applet below describes the aspects of this mechanism.

One of the primary goals of the OMA is reuse. Wherever possible, existing CORBAservices or CORBAfacilities components are used as building blocks to construct higher level functionality.
In the next lesson we will take a conceptual look at how this layering is designed.

1. The CORBAservices are designed to provide object-level services that will commonly be needed across many applications.
2. The CORBAfacilities are designed to provide application-level services such as system management, GUI services, and data translation services.
3. The CORBAdomains (or Domain Interfaces) are defined by Special Interest groups (SIGs) within the OMG. These CORBAdomains specify services specific to vertical market focus areas such as medical, financial, etc.
4. CORBA Application Objects are designed and developed by CORBA developers to meet the specific needs of their application.
5. The ORB makes it possible for the objects and services to communicate.

The Object Management Group (OMG) is a not-for-profit organization that promotes the use of object-oriented technologies. Among other things, it defines the CORBA and UML standards. The OMG web site (www.omg.org) provides all of its standards documents available free-of-charge in the form of downloadable PDF files. The OMG has a relatively small staff that focuses on administrative tasks, such as maintaining the OMG web site and organizing meetings of its members. The work of defining standards is carried out by the members of the OMG, of which there are about 600. Any organization (or individual) that is interested in the work of the OMG can become a member. Member organizations typically include universities, software vendors and software users. Members can volunteer to take part in task forces that have the goal of defining new OMG standards or enhancing existing OMG standards. It is through this work that the OMG standards evolve in directions directed by the real-world concerns of its members.

As object technology became more popular through the 1980s there was more interest in bundling the concept of objects with the concept of transparent distributed computing. Objects, with their inherent combination of data and behavior and their strict separation of interface from implementation, offer an ideal package for distributing data and processes to end-user applications. Objects became an enabling technology for distributed processing. In the early 1990s an international trade association called the Object Management Group (OMG) defined a standard for the distribution of objects. The OMG defined the Common Object Request Broker Architecture (CORBA), which provided a standard by which OT could be used in distributed computing environments. The latest version of this standard, CORBA 2.0, addresses issues related to interface, registration, databases, communication, and error handling. When combined with other object services defined by the OMG Object Management Architecture (OMA), CORBA becomes a middleware that facilitates full exploitation of object technology in a distributed system. However, if we were to characterize CORBA technology in the simplest possible language, it would be to say it is an object-oriented RPC.

Application Interfaces are developed specifically for a given application. They are not standardized by the OMG. However, if certain application interfaces begin to appear in many different applications, they become candidates for standardization in one of the other interface categories. As the OMG gradually populates the interface categories, the bulk of its standardization efforts will shift upward from the ORB infrastructure and Object Services levels into domain-specific object frameworks. The object framework concept builds from the interface categories just described, recognizing and promoting the notion that CORBA-based programs are composed of multiobject components supporting one or more of the OMA interface categories. Unfortunately, the term framework is overused in general, but used in this context it follows the classic definition of a software framework: a partial solution to a set of similar problems that requires application customization for completeness. The OMG is likely to standardize specifications for object frameworks for use in industries represented by its Domain Task Forces. These models may not seem very complicated or profound, but their apparent simplicity is misleading. Many pages of this book, as well as other books, articles, and specifications, are devoted to exploring the effects and consequences of these seemingly simple models, so this is all we will say about them for now.

[1] ORB: An Object Request Broker (ORB) is the programming that acts as a mediator between a client request for a service from a distributed object or component and the completion of that request. The ORB is the middleware that establishes the client-server relationships between objects.