The OMG Object Model (OMG/OM) is the underlying specification for all OMG compliant technologies. It is not part of CORBA, but the CORBA object model is built from it. The goal of the OMG/OM is to support interoperability and application portability. The OMG/OM supports design portability by defining a base semantics that assure that applications designs based on this core will be portable across compliant systems. The OMG/OM is a model not an implementation syntax.
The OM provides the semantics that define the interfaces that are used to interact with the object. The semantics define objects as the instances of types. The types may be grouped allowing for higher-order structures.
The OMG/OM underlies a vast array of technologies. The model provides the commonality of these different technologies that are following an object oriented paradigm. In addition to the commonalties,the model must also support the differences. To handle this situation, the OMG defined the Core Object Model, which is a set of definitions that must be supported in any OMG/OM based system, profiles and components. Components are extensions to the core that are not necessarily supported by all systems. For example, the object database model has extensions for persistence and queries. Profiles are enhancements to the core model that are required for specific definitions. For example, distributed environments and ODBMS may share a profile that supports object relationships.
The basic core concepts of the OMG/OM are:
The CORBA Object Model is based on the OMG/OM. The OMG/OM is abstract and serves as a basic model. The CORBA/OM model maps these abstract concepts into concrete ideas. The model focuses on the interactions between clients and servers (object implementations).
Requests are made from clients. A request consist of the target object, the operation requested and any parameters. A Context Object may also be passed to the target object. A provided service is the result of the request.
An operation has a name and signature and denotes an operation that may be requested. An operation can be represented as follows:
[oneway](parameter1...parameterN)
[raises](exception1....exceptionK)
[context(contextName1...contextNameL)]
The signature consists of a name, result type and a parameters list of zero or more declarations. Each parameter declaration has a name, type and a mode. A parameter mode, may be in, out or inout. An 'in' parameter is passed from the client to the server. An 'out' parameter is passed from the server to the client. A parameter with the mode of 'both' is passed from the client and returned by the server. Exceptions are handled in the raises clauses. If an exception is raised, the results of the out and inout parameters are undefined. Oneway semantics do not include a raises clause. The operational signature also provides for a Context. A context can provide additional context information for both the ORB and object implementation.
CORBA/OM defines two operation execution semantics. The 'oneway' specifier (which is optional) is called a best-effort operation semantic. The requester does not wait for the provider to complete. The operation here does not return any results. The default operations semantic is at-most-once. If operation was successful it was performed exactly once. If an exception was raised, it may have been performed once, or not at all.
An interface is a set of operations that may be used by clients to issues requests. Interfaces are defined using the IDL (Interface Definition Language). Interfaces may also provide access to attributes. With each attribute, accessor functions, 'set' and 'get', are used to retrieve or set the attribute values. The 'set' function is omitted for read only data items.
The legal type values of the CORBA/OM fall into three categories: basic value, constructed value or object reference.
The basic values denote values that are of the basic type. These are non-object types which represent fundamental data types. There is an octet type (8 bit quantity) that does not undergo any conversion. Of special interest included in the basic types is the type 'any' which can represent any type. Constructed values denote structure, unions , arrays and sequences. Sequences are variable-length arrays with a maximum size. Sequences can be either bounded or unbounded. Bounded sequences have a maximal size, specified at time of declaration. Unbounded sequences do not have an explicit maximal size definition. Strings are similar to sequences of type char, and have both a bound and unbounded version. Object References are opaque references only uniform within an ORB implementation.
These are name value/pairs that can be passed to the target object. The objects usually contain environmental information, but there is not any restriction on this. Since the values pass through the ORB, the ORB may actually make use of the information. The context object interface includes methods for building and retrieving context information. The object can be dynamically created and destroyed. The interfaces support the use of wildcards when matching properties.
©1998, Sage Technologies