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.