Business Object Design and Implementation Workshop

Position Paper

Semantic Inter-Operability Framework

Rainer Kossmann (


P.O. Box 3511, Station C
Ottawa Ontario
Canada, K1Y 4H7
Voice: (613) 765-5915
Fax : (613) 763-7066

Date/Place: 16 October 1995/Austin, TX

This research paper proposes a framework for globally interconnected distributed heterogeneous object-oriented systems and the problem of semantic interoperability.


The proposed framework is depicted in Figure 1 as a globally interconnected set of objects positioned in a huge address space referred to as the ObjectCosmos. Each object is identified by an immutable ObjectIdentity consisting of a unique CosmicAddress within the ObjectCosmos. CosmicAddresses assigned to objects are never reused. The collection of all objects in the ObjectCosmos is referred to as the ObjectUniverse.

 ------------------------------------------------- <-- ObjectCosmos
| -------         -------          +      ------- |    Address Space
|| *  +  |  *    |   ~*  |  +  *      *  | +     ||
|| ----- |       | --  - |               |   --  ||
||| -  +||       ||* ||*||    *  ...     |* | *<------ Objects make up
||||+|*~|| +  +  || +||+|| +    +        |  |+ |+||    ObjectUniverse
||| -  +||       ||+ | - |               |  | *| ||
|| ----- |       | --  - |               |   --  ||<-- Covers
| -------         -------           *     -------<-----|

Figure 1: The ObjectUniverse

Objects are of two major types:

A sparc is an abstraction of the primary source or causal agent of any activity such as a process, thread, coroutine, actor, etc. Sparcs have their own ObjectIdentity, ie. immutable CosmicAddress, and are the causal agents of all activity in the ObjectCosmos. When a sparc invokes an operation on an object, it is driving a thread (~) through that object. Objects which have no thread operating in them are called passive objects, whereas objects which have threads being driven through them by sparcs are called active objects.

Objects are covered by covers (boxed figures) discussed further below.


2.1 Introduction

The ObjectUniverse is covered by semantic covers. A semantic cover contains information about the objects that it covers, ie. it is a meta-object. Four major orthogonal covers are examined: [Being[*]],

[Doing[*]], [Consistency[*]] and [Security[*]].

The simplest semantic cover that exists is a composition cover that partitions the ObjectUniverse into collections of objects. In its simplest form, a composition cover simply lists the CosmicAddresses of the objects it collects. The composition cover is itself an object having CosmicAddress. Composition covers are self-descriptive, ie. they contain not only the CosmicAddresses of the objects they cover, but also contain their own CosmicAddress.

Covers may be hierarchically nested as shown in Figure 1, which depicts a composition cover over the ObjectCosmos. The outermost cover is referred to as the ObjectUniverseCover. The next level of [Composition[*]] subcover is referred to as an EnterpriseCover. It represents enterprises recognized as legal independent entities in international law such as persons, organizations and nations. The notion of a legally recognized enterprise is important because it is associated with security and authentication mechanisms that are required to be able to fully specify security semantics for the ObjectCosmos.

We utilize the notation [Cover[*]] to represent a cover in a textual description. For example, Figure 1 depicts the [Composition[*]] cover over the ObjectUniverse. The [*] notation is suggestive of hierarchical nesting of covers. The notation is capable of unambigously identifying a specific cover as in for example [Composition[BNR[Ottawa]]] which identifies the composition cover identifying the BNR-Ottawa objects. A separate cover over the ObjectCosmos which is orthogonal to [Composition[*]] is [Class[*]]. [Class[*]] consists of meta-information specifying the class or type information for the ObjectUniverse.

We note that OMG's IDL MODULE construct is capable of specifying [Class[*]] over the ObjectCosmos.

2.2 [Being[*]]

We refer to [Composition[*]] and [Class[*]] as [Being[*]]; ie. it specifies completely the existential semantics for the ObjectUniverse. These existential semantics are in a sense analogous to the notion of objects and their distribution in space in the real cosmos.

2.3 [Doing[*]]

Each sparc operative as a causal agent in the ObjectCosmos is coupled to a [Doing[*]] meta-object that describes its current state and sphere of influence in the ObjectCosmos. A [Doing[*]] cover effectively describes sparcs and their operations on objects within the lifetime of each sparc. [Doing[*]] effectively completely specifies the operational semantics for the ObjectUniverse. These are in a sense analogous to the notion of causal change agents and their effects in time in the real cosmos.

Sparcs are ultimately traceable to persons having legal authority within an Enterprise cover. Sparcs are also primitives used to specify [Consistency[*]] and [Security[*]] semantics further described below.

2.4 [Consistency[*]]

[Consistency[*]] deals with consistency semantics in the ObjectCosmos under conditions of sparcs with intersecting / colliding [Doing[*]] meta-objects.

2.5 [Security[*]]

[Security[*]] semantics specify the security semantics operative in the ObjectCosmos, by specifying the 'keys' held by sparcs that permit them to open the appropriate 'locks' covering the objects they wish to access.

3. Object-Schema

The framework deals with multiple schema analogous to the ANSI / SPARC 3-schema model for data. These schema are a CosmicSchema, an ImplementationSchema and a ViewSchema. These correspond approximately to the ANSI / SPARC conceptual schema, internal schema and external sub-schema.

3.1 CosmicSchema

The CosmicSchema is a description of the ObjectCosmos in terms of its orthogonal covers of [Being[*]], [Doing[*]], [Consistency[*]] and [Security[*]]. Figure 1 above is a CosmicSchema representing the [Composition[*]] sub-cover of [Being[*]]. It deals with conceptual notions rather than implementation notions.

3.2 ImplementationSchema

Figure 2 depicts the ImplementationSchema. It is a separate independent layer on top of which resides the CosmicSchema represented by Figure 1. The CosmicSchema is mapped into the ImplementationSchema by the various implementations of portions of the ObjectCosmos.

                 -----                           -----
                | AE  |          . . .          | AE  |
                |     |                         |     |
                 -----                           -----
                   |                               |
                   |                               |
                   |            -------            |
                 -----         |       |         -----
    ---         |     |        |   M   |        |     |         ---
   | m |--------| DE  |--------|       |--------| DE  |--------| m |
    ---         |     |        |       |        |     |         ---
                 -----         |       |         -----
                   |            -------            |
                   |                               |
                   |                               |
                   |                               |
                   |                               |
                   |            -------            |
                 -----         |       |         -----
    ---         |     |        |   M   |        |     |         ---
   | m |--------| DE  |--------|       |--------| DE  |--------| m |
    ---         |     |        |       |        |     |         ---
                 -----         |       |         -----
                   |            -------            |
                   |                               |
                   |                               |
                 -----                           -----
                | AE  |                         | AE  |
                |     |          . . .          |     |
                 -----                           -----

Figure 1: Internal Schema Platform

At the InternalSchema, there are a number of activity engines (AE) which can be loaded with sparcs in order to perform the sparc's activity. Activity engines are generally limited to being able to perform only a few types of activity covers from the total set of activity cover types in the ObjectCosmos (eg. UNIX SUN/OS process, active Microsoft Window, ...).

Local private memories m and local shared memories M are high-level memory abstractions where objects are located. Each such memory is referred to as an ObjectSpace. Objects have an ImplementationAddress within an ObjectSpace

Dispatching Engines DE perform dispatch of operations on objects originating from an activity running on an activity engine AE. Such operations use a CosmicAddress as the ObjectIdentity. DE maps that CosmicAddress into an ImplementationAddress of the local ObjectSpace and performs the dispatching operation. DE is therefore very similar to an OMG ORB. If the object is not local to DE (ie. it is not contained in a local ObjectSpace), then DE will interact with other DE's supporting the ObjectCosmos to locate the object in order to perform the dispatch.

DE has knowledge of the semantic covers over each of its ObjectSpaces. DE also performs the semantic transformations required to support semantic inter-operability between two objects, whereever such semantic inter-operability is indeed possible. Ie. DEs implement an object's semantic covers.

Objects may also be replicated, relocated or moved within the above InternalSchema Platform. Such mechanisms are managed by the DEs. Failures and restarts are performed by DEs or with their assistance, and generally involve relocating objects to avoid failed components AE, DE and ObjectSpace.

The InternalSchema identifies the distribution of the CosmicSchema over the InternalSchema Platform. Ie. it identifies the distribution of the objects of the CosmicSchema over the activity engines, dispatching engines and ObjectSpaces of the InternalSchema platform.

3.3 ViewSchema

A ViewSchema resides above the CosmicSchema and provides different perspectives and views of the CosmicSchema in accordance with the requirements of a viewer.

4. Enterprise Repository Engine

The first level of [Composition[*]] below the ObjectUniverseCover of Figure 1 is the EnterpriseCover. Each enterprise has an Enterprise Repository Engine that manages the Enterprise Cover. An Enterprise Cover is semantically complete and operationally accessible from other EnterpriseCovers in the ObjectCosmos in order to support inter-enterprise operation.


Rainer Kossmann is an architect at Bell Northern Research in Ottawa, Canada working on telephony switching system software. His interests include distributed heterogenous object oriented systems, OMGs OMA architecture as well as repository architectures.

Business Object Design and Implementation

Page hits since 8/21/95