OMG Mapping

OMG Object Model

The Object Management Group (OMG) is a non-profit international trade association formed to promote new interoperable software solutions to reduce the cost of software development. The OMG has defined an object reference model and architectural framework with supporting detailed interface specifications. The object model and architecture is defined in the Object Management Architecture Guide (see reference OMAG) and the OMG Object Model (see reference OMGOM) and the interface specifications are defined in the Common Object Request Broker Architecture¹ (see reference CORBA).

The OMG object reference model identifies and characterises the components, interfaces, and protocols that compose OMG's object management architecture (OMA). The reference model addresses how objects make and receive requests and responses, the basic operations that must be provided for every object, and the interfaces that provide common facilities useful in many applications. The OMA supports the object architecture described in OMG Object Model , defining an infrastructure with an object request broker (OMG's implementation of the Communications Service) and object services.

The three categories of objects (Object Services, Common Facilities, Application Objects) reflect a partitioning in terms of functions from most basic and common to application specific. Note that objects can issue as well as process requests (act as clients as well as servers). Thus application objects can provide services for other application objects, can access common facilities and object services objects; common facilities can use object services as building blocks, and so forth.

The OMG reference model and architecture defines the following major components:

Object Request Broker

The ORB provides the mechanisms by which objects transparently make and receive requests and responses. It is intended to provide interoperability between applications on different machines in heterogeneous distributed environments. An object request (and its associated response) is the fundamental interaction mechanism. A request names an object, an operation and includes zero or more parameter values, any of which may be object handles identifying specific objects. The ORB delivers the request to the appropriate object implementation server and causes a method representing the operation to be executed.

Object Services

Object services provides basic operations for the logical modeling and physical storage of objects. It defines a set of intrinsic or root operations that all classes of objects should implement or inherit. Object services operations are made available through the ORB (that is, ORB compliant interfaces are defined for each object service). The operations supplied by object services are typically used as the building blocks for extended functionality provided by Common Facilities. The operations that object services can provide include life cycle, naming, persistence, event, security, relationships, transactions, and concurrency control.

Common Facilities

Common Facilities provide optional, extended services that are useful for many applications. They are made available through ORB compliant object interfaces. Their purpose is to reduce the effort needed to build OMG compliant applications through reusability. Examples of common facilities include cataloguing and browsing objects, error reporting, help facilities, object querying facilities, and user profiles.

Application Objects

Application objects correspond to the traditional notion of an application; that is, individual related sets of functionality that are implemented using the OMG architecture. Such an application consists of a set of interworking OMG compliant objects. These objects communicate using the ORB and make use of the objects comprising the Common Facilities and Object Services.

OMG Object Request Broker

The OMG Object Request Broker (ORB) is that component of the object management architecture which is responsible for accepting a client object request, finding the object implementation for the request, preparing the object implementation to receive the request, and communicating the data making up the request and response. OMG Object Request Broker shows the architecture and components of the ORB.

The ORB is composed of the following components:

ORB Core

The ORB Core provides the basic representation of objects and communications of requests. It provides transparent object location for the client making the request given an object reference consistent with the ORB implementation.

Object References

An Object Reference is the information needed to specify an object within an ORB. Clients and object implementations are insulated from object reference representation through the use of an opaque object referent consistent with the client or implementation language mapping. An object reference is an object handle in the OMG model.

IDL Interface Definition Language

IDL defines the types of objects by specifying their interfaces in terms of data types, operations, parameters, and exceptions. It describes a conceptual framework for executing operations on objects. Most ORB implementations supply IDL compilers, which generate the stub routines, skeleton routines, and argument encoding and decoding routines needed to execute requests on the object interface. These routines are expressed in a specific programming language, or language binding.

Programming Language Binding

Different programming languages will access CORBA objects in different ways. CORBA defines a language mapping for each supported programming language, which includes language-specific data types and procedural interfaces to access objects through the ORB.

Client Stubs

Client stubs are programs usually generated by IDL compilers with a specific language binding and are used by client programs to make object requests to the ORB. Client stubs are private to a particular ORB implementation and specific to a particular interface definition.

Dynamic Invocation Interface

The dynamic invocation interface (DII) is an interface to the ORB that allows the dynamic construction of object invocations. The client builds up the object request by specifying the object to be invoked, the operation to be performed, and the set of parameters for the operation. The DII serves as an alternative client interface to client stubs.

Implementation Skeleton

Skeletons are programs usually generated by IDL compilers with a specific language binding and are used by object adaptors to make up-calls to the object implementation in the object server. That is, the object implementation writes routines to conform to the skeleton interfaces and the ORB calls them through the skeleton.

Object Adaptors

The object adaptor is the primary way object implementations access services provided by the ORB. A few object adaptors will be implemented that are appropriate for specific kinds of objects. Services provided through an object adaptor includes generation and interpretation of object references, object invocations, object and implementation activation and deactivation, mapping object references to implementations, and registration of implementations.

ORB Interface

The ORB interface provides a few operations common for all ORB implementations, and are thus implemented directly by the ORB core.

Interface Repository

The Interface Repository is an ORB service that provides IDL information about OMG compliant objects in a form available at run time. The interface repository may be used by the ORB to perform requests, or by a browser application to form object requests dynamically.

Implementation Repository

The Implementation Repository contains information that allows the ORB to locate and activate implementations of objects. Installation of object implementations and control of policies related to the activation and execution of object implementations are typically done through operations on the implementation repository.

OMG Interface and Implementation Repositories shows the relationship between the ORB components used to create client and object implementations.

Realisation of the Reference Model

The reference model supports distribution of management functionality and objects. The object request mechanism provided by the ORB's communications service invokes operations on objects independently of their location on the systems within the network. Information associated with an object reference is used by the ORB to determine the system upon which the object implementation is to be executed. ORB process management mechanisms can automatically instantiate an appropriate server process on that system and call the activation functions needed to make the object state available. Object implementation code is then called within the server process to respond to the object request (the exact mechanism for calling a method depends upon the IDL language binding used to implement the object implementation code).

Because a single object request mechanism is used by the ORB for both "local" and "remote" request invocations for all ORB compliant objects, the management application can be distributed at many levels. For example, the application client code and task-oriented management functions could be located on the client's system, while the Managed Objects are located on a remote system. Implementations of the Management Services and object services could be executed on yet other systems. It is possible that the task-oriented management function objects can be executed on systems remote from the management application's client code, thus supporting high level management functionality "closer to" the managed Resources. OMG Mapping to the Reference Model shows the distributed management architecture using the OMG based system management reference model.

Footnotes

1.

The description in this Appendix is based on the stated direction of CORBA 2.0 and OMG Object Services which are still in the process of definition.