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.

The Object Management Group (OMG) is a non-profit organization dedicated to promoting object-oriented technologies. It is best known for defining standards like CORBA and UML. The OMG’s standards documents are freely available on its website (www.omg.org) as downloadable PDFs. With a small administrative staff, OMG relies on its approximately 600 members, comprising universities, software vendors, and software users, to define and evolve its standards. Members can join task forces to develop new standards or enhance existing ones, ensuring OMG standards address real-world concerns. When the OMG issued a Request for Proposals (RFP) for a standard CORBA-to-C++ mapping in 1993, multiple groups submitted proposals. These groups later collaborated to consolidate their efforts into a single specification. This process, spanning 18 months, faced challenges due to C++'s complexity, competing interests, and political dynamics among participants. At one point, the effort stalled, but the necessity of a standard overcame these hurdles, and the C++ mapping was finalized in late 1994, published with CORBA 2.0. Since its adoption, the C++ mapping has undergone minor revisions to address flaws and introduce small enhancements, yet it remains stable and portable, even as C++ itself evolved through standardization. This mapping significantly improved CORBA's adoption by enabling source code portability on the client side, although server-side portability issues persisted until CORBA 2.2.

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: 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.
  In the next lesson we will take a conceptual look at how this layering is designed.

[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.