| Previous | Table of Contents | Next |
The OMG Object Model defines a core set of requirements that must be supported in any system that complies with the Object Model standard. This set of required capabilities is termed the Core Object Model. The core serves as the basis for portability and interoperability of object systems across all technologies, as well as across implementations within technology domains.
While the Core Object Model serves as the common ground, the OMG Object Model also allows for extensions to the core to enable even greater commonality within different technology domains. The Object Model defines the concept of components that are compatible extensions to the core Object Model, but are not required to be supported by all systems. For example, relationships are defined as components. The OMG Object Model Components guide contains descriptions of components that are accepted as a standard.
The Object Model also defines a mechanism, referred to as profiles, for technology domains to group pertinent components. Profiles are groups of components combining as a useful set of extensions for particular domains.
An OMA-compliant application consists of a set of interworking classes and instances interacting via the ORB (as defined in a later section). Compliance, therefore, means conformance to the OMA and the protocol definitions. Using ORB, objects make and receive requests and responses. The Object Management Architecture consists of the following components:
In general terms, the Application Objects and Common Facilities have an application orientation, but the ORB and Object Services are oriented more with the system or infrastructure aspects of distributed object management. However, Common Facilities provides higher-level services, such as transactions and versioning, that use primitives provided within Object Services.
The three categories reflect a partitioning in terms of functions—from those basic to most applications or sufficiently common to broad classes of standardized applications, to those that are too application-specific or special-purpose to be standardized today. Therefore, the ORB, Object Services, and Common Facilities are focal to OMG standardization efforts.
Object Services, Common Facilities, and Application Objects intercommunicate using the Object Request Broker. Objects may also use non-object interfaces to external services, but these are outside the scope of the OMA. Although not explicitly stated in the Reference Model, objects may (or may not) communicate with the Object Services via object interfaces. For example, the addition of a new class is a request to an object providing this service. If this were done manually, it would be performed by editing a class definition script or a C++ include file.
Application Objects and Common Facilities use and provide functions and services via object interfaces. In general, objects issue as well as process requests for services, and Application Objects provide services for other applications or facilities. For example, an application-specific service such as printer rendering is cast as an application object invoked by a Common Facility like print queue. Common Facilities objects use services provided elsewhere.
Note that applications need only provide or use OMA-compliant interfaces to participate in the Object Management Architecture. Applications do not have to be constructed using the object-oriented paradigm, which also applies to the provision of Object Services. For example, existing relational or object-oriented database management systems provide some or all of the Object Services. Existing applications, external tools, and system support software are embedded as objects participating in the Object Management Architecture, using class interface front ends, also known as adapters or wrappers.
The Reference Model does not impose any restrictions on how applications and common facilities are structured and implemented. Objects of a given application class deal with the presentation of information, interaction with the user, semantics, functionality, the persistent storage of data, or a combination of the above.
The OMA assumes that underlying services provided by a platform’s operating system and lower-level basic services (such as network computing facilities) are available and usable by OMA implementations. Specifically, the Object Management Architecture does not address user interface support. The interfaces between applications and windowing systems or other display support are the subjects of standardization efforts outside the OMG. Eventually, however, Common Facilities may provide standard user interface classes. In addition, the Reference Model does not deal explicitly with the choice of possible binding mechanisms such as compile time, load time, and run time.
The ORB provides mechanisms by which objects transparently make and receive requests and responses. In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.
The OMG Object Model defines an object request and its associated result (response) as the fundamental interaction mechanism. A request names an operation and includes zero or more parameter values, any of which may be object names identifying specific objects. The ORB arranges processing of the request. This entails identifying and calling some method to perform the operation using the parameters. After the operation terminates, the ORB conveys results to the requester.
The ORB itself may not maintain all the information needed to carry out its functions. The ORB may generate requests of its own to Object Services or use them in the process of conveying a request. For example, to find the specific method executed for a given request, the ORB uses a class dictionary service or searches runtime method libraries.
| Previous | Table of Contents | Next |