| Previous | Table of Contents | Next |
The object model provides an organized presentation of object concepts and terminology. It defines a partial model for computation
that embodies the key characteristics of objects as realized by the submitted technologies. The OMG object model is abstract
in that it is not directly realized by any particular technology. The model described here is a concrete object model. A concrete
object model may differ from the abstract object model in several ways:
•It may elaborate the abstract object model by making it more specific, for example, by defining the form of request parameters or the language used to specify types.
•It may populate the model by introducing specific instances of entities defined by the model, for example, specific objects, specific operations, or specific types.
•It may restrict the model by eliminating entities or placing additional restrictions on their use.
An object system is a collection of objects that isolates the requestors of services (clients) from the providers of services
by a well-defined encapsulating interface. In particular, clients are isolated from the implementations of services as data
representations and executable code.
The object model first describes concepts that are meaningful to clients, including such concepts as object creation and identity,
requests and operations, types and signatures. It then describes concepts related to object implementations, including such
concepts as methods, execution engines, and activation.
The object model is most specific and prescriptive in defining concepts meaningful to clients. The discussion of object implementation
is more suggestive, with the intent of allowing maximal freedom for different object technologies to provide different ways
of implementing objects.
There are some other characteristics of object systems that are outside the scope of the object model. Some of these concepts
are aspects of application architecture, some are associated with specific domains to which object technology is applied.
Such concepts are more properly dealt with in an architectural reference model. Examples of excluded concepts are compound
objects, links, copying of objects, change management, and transactions. Also outside the scope of the object model are the
details of control structure: the object model does not say whether clients and/or servers are single-threaded or multi-threaded,
and does not specify how event loops are programmed nor how threads are created, destroyed, or synchronized.
This object model is an example of a classical object model, where a client sends a message to an object. Conceptually, the
object interprets the message to decide what service to perform. In the classical model, a message identifies an object and
zero or more actual parameters. As in most classical object models, a distinguished first parameter is required, which identifies
the operation to be performed; the interpretation of the message by the object involves selecting a method based on the specified
operation. Operationally, of course, method selection could be performed either by the object or the ORB.