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.
Object Management Architecture consisting of 1) CORBAServices , 2)CORBAfacilities, 3) CORBAdomains, and 4) CORBA Application Objects
The CORBAservices are designed to provide object-level services that will commonly be needed across many applications.
The CORBAfacilities are designed to provide application-level services such as system management, GUI services, and data translation services.
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.
CORBA Application Objects are designed and developed by CORBA developers to meet the specific needs of their application.
The ORB makes it possible for the objects and services to communicate.
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. Object Management Architecture
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.
[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.