A more indirect end-user benefit of object-oriented applications, provided that they cooperate according to some standard, is that independently developed general-purpose applications are combined in a user-specific way. OMG’s central purpose is to create a standard that allows interoperability between independently developed applications across heterogeneous networks of computers. This means that multiple software programs appear as one to the user of information, regardless of where the programs reside.

Common functionality in different applications—storage, retrieval, mailing, printing, creation, and deletion of objects, or help and computer-based training—is realized by common shared objects leading to a uniform and consistent user interface. Sharing of information drastically reduces documentation redundancy. Consistent access across multiple applications allows increased focus on application creation, as opposed to application education.

Transition to object-oriented application technology does not make existing applications obsolete. Existing applications can be embedded (with different levels of integration) in an object-oriented environment.

Pragmatic migration of existing applications gives a user control over computing resources, as well as how quickly these resources change. Likewise, application developers benefit from object technology and object-oriented standards. These benefits fall into the two general categories of modular architecture and reuse of existing components.

Encapsulation of object data applications are built in a truly modular fashion, preventing unintended interference. In addition, it is possible to build applications in an incremental way, preserving correctness during the development process.

Reusing existing components, specifically when the OMG standard is in effect, standardizes interaction between independently developed applications (and application components). Cost and lead time can be saved by using existing object class implementations.

In developing standards, OMG keeps these benefits of object orientation in mind, together with a set of overall goals:

•  Heterogeneity—Integration of applications and facilities are available across heterogeneous networks of systems, independent of networking transports and operating systems.

•  Customization options—Common facilities are customizable to meet specific end-user or organizational requirements and preferences.

•  Management and control—Examines issues such as security, recovery, interruptability, auditing, and performance.

•  Internationalization—OMG is an international group, and its standards reflect built-in support for internationalization of software.

•  Technical standards—Standards that meet user goals are the central focus of the OMG.

The Object Management Architecture Components

The Object Request Broker (ORB) component of the Object Management Architecture (OMA) is the communications heart of the standard, referred to commercially as CORBA. It provides an infrastructure that allows objects to communicate independently of specific implementation platforms and techniques for addressed objects. The Object Request Broker component guarantees portability and interoperability of objects over a network of heterogeneous systems.

The Object Services component standardizes the life cycle management of objects. Functions create objects (the Object Factory), control access to objects, keep track of relocated objects, and control relationships among species of objects (class management). The Object Services component provides the generic environment in which single objects perform their tasks. Standardization of Object Services leads to consistency over different applications and improved productivity for the developer.

The Common Facilities component provides a set of generic applications functions configured to the individual requirements of a specific configuration. Examples are printing, database, and email facilities. Standardization leads to uniformity in generic operations and allows end users to manipulate their configurations as opposed to configuring individual applications.

The Application Objects part of the architecture represents those application objects performing specific tasks for users. One application is typically built from a large number of basic object classes—partly specific for the application, partly from the set of Common Facilities. New classes of application objects are built by modification of existing classes through generalization or specialization of existing classes (inheritance) as provided by Object Services. This multiobject class approach to application development leads to improved productivity for the developer, and enhances the ability of end users to combine and configure their applications.

The OMG Object Model

This model defines a common object’s semantics, specifying the externally visible characteristics of objects in a standard and implementation-independent way. The common semantics characterize objects existing in an OMG-compliant system, which performs operations and maintains states for objects.

An interface describes the externally visible characteristics of objects, consisting of operation signatures. The external view of both object behavior and object state (information needed to alter the outcome of a subsequent operation) are modeled in terms of operation signatures.

Objects are grouped into types, and individual objects are instances of their respective types. A type determines which operations are applied to its instances. Types participate in subtype/supertype relationships that affect the set of operations applicable to their instances.

Types also have implementations. An implementation of an object type is typically a set of data structures constituting a stored representation and a set of methods or procedures that provide the code to implement each of the operations’ defined type.

Implementation details are encapsulated by operations and are never directly exposed in the external interface. For example, the stored representation is only observable or changeable through an operation request. Formally, the OMG Object Model states nothing regarding implementations of a type. It only claims their existence and the possibility that a given type can have multiple implementations (note that systems are not required to support multiple implementations).