New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

The OMG Object Model

 

Course Title: Application Servers                                           Course Number: g22.3033-011

Instructor: Jean-Claude Franchitti                                            Session: 4

 

 

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:

 

·        Objects - Objects are instances of types. Types groups objects which represent entities belonging to a group. Types may be related through subtype/supertype relationships. A subtype is a specialization of a supertype. The subtype can also be seen as an instance of the supertype. The subtype/supertype form a type hierarchy. The core model also defines another set of entities called nonobjects. The concept was included within the core model to be used by component and profiles builders. Some examples of nonobjects would be the basic data types (short , long, etc.) defined within CORBA.

 

·        Operations - Operations are defined by a signature, which includes the name, parameters and a set of return values. Operations are always associated with a controlling parameter such as 'this' in C++ or 'self' in Smalltalk. The OMG/OM does not include many restrictive definitions. It does not address exception handling, atomic operations or the concept of public, private or protected operations. Profiles would be needed to extend the core model to support these operations.

 

·        Subtyping -The core model support both subtyping and inheritance. Subtyping is a relationship between types. It defines when constructs of one type can receive objects of another type. Inheritance is supported through the use of subtype/supertype relationships.

 

The CORBA Object Model

 

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 consists 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.

 

Operations

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.

 

Types

The legal type values of the CORBA/OM fall into three categories: basic value, constructed value or object reference.

 

CORBA 3 introduces a new legal type value termed “valuetype” to support objects passable by value. Valuetypes inherit from the ValueBase base class, and do not have object references. Concrete valuetypes (i.e., valuetypes that have state, constructors, and operations) can inherit singly (not multiply) from other valuetypes, but can only support interfaces. Abstract valuetypes (i.e., valuetypes that have no state or constructors) are declared abstract instead of valuetype. Abstract interfaces can multiply inherit.

CC

 

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.

 

Context Objects

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.