OOPSLA'96Business Object Workshop III


Developing an Ontology Service for Business Object Frameworks

Ajay Khater, Raphael Malveaux, Robert Silvetz
Eidea Labs (http://www.eidea.com)
{akhater, raphael, bob}@eidea.com


Abstract

Business objects are independent entities which perform specialized functions with minimal knowledge about other components in a domain. However, in order to collaborate with other domain objects, they require a common frame of reference which clarifies how object categories are related to one another. An ontology resolves this problem by serving as an external hierarchy of descriptive information which can be utilized by independent components for the coordination and cooperation between components at run-time. This allows for greatly flexibility and extensibility than currently possible with existing business object frameworks.


The Need for an Ontology Service

The OMG Business Object Facility (BOF) is an essential step in representing real world concepts and business processes in a natural manner. In order to enable organizations to develop cooperative business models, standards interfaces, such as those defined in the OMG BOF submissions, are both necessary and desirable. Furthermore, the submissions share an architecture where the business object framework supports common or generic business components which are used to develop, or are customized into, domain specific components. However, the current BOF designs are insufficient for modeling the semantics of different business environments. They are lacking in providing all of the services necessary to dynamically interoperate with previously unknown components created within similar domains. It is necessary to further advance the evolution of business objects into the development of semantically-enabled, independent common business components, whose primary design goals support radical reconfiguration and customization into domain-specific components.

Business objects exist at the micro and macro-levels of system architecture [Malveau 1997]. They are designed to plug-and-play into a larger architecture, with perhaps a few minor customizations. They are intrinsically dependent on the framework which acts as their operating environment for portions of their functionality (utilities, services, etc.). Everything but the actual business logic is really external and embodied in the framework. However, as will be described later, it is still necessary for the components to know how they relate hierarchically to one another within a particular domain model. In contrast to object-oriented programming where the hierarchy of the model is statically known at compile time, within component programming the hierarchy is external and should be embodied in a separate and distinct facility. This paper proposes a line of research into an Ontology Service to contain and disseminate information about a domain model to enable cooperative, yet independent, domain business components.

Ontology Service

With independent components, objects must carry on a real-time conversation to service each other requests for data and to establish run-time relationships. Assuming that the objects engage in the same protocol and that the conversation is a semantic one, then an external service will be required to provide meaning for the semantic tokens that are exchanged. The ontology will provide such a dictionary and standard of reference. Just as loose run-time binding between objects (via messages or remote invocation) provides the means of communication, the standard of reference provides the meaning/what of the communication.

Additionally, the Ontology Service will also provide for dynamic acquisition. This is also a loose, run-time binding between objects based on the external ontology or model of the essential qualities of the domain. It is a mechanism to enforce the deep relationships of knowledge in the domain. It is, at the scale of components, similar to the function of inheritance at the object-oriented design and coding level. However, like components, it uses the interface/implementation paradigm to minimize the level of implementation detail necessary for component reuse.

Establishing a Common Frame of Reference for Component Systems

In object-oriented programming, the binding between classes is established at compile time. The use of superclass functions by subclassing is an easily mediated inheritance intended to support code reuse. However, component-based programming is orthogonal to this paradigm even though components themselves are objects. The features in question that are orthogonal are:

This introduces the problem, that in organizing the components and their functions for a particular domain model, the hierarchical arrangement of the components is not intrinsic to the component itself. Otherwise, it would violate the constraints listed above. Thus, the need to externalize the hierarchy information into a service and allow independent components to have or derive domain-model driven relationships. This external hierarchy of formalized definitions of the domain model is the ontology and the components access it at run-time via an ontology service.

An ontology service is a specialized cross between a traditional relationship service and a rule base. It is, in essence, the rules which pertain to the object components qua components in the domain model. To differentiate - the ontology characterizes the essential characteristics of a component relative to the domain being modeled. A rules service traditionally mediates relationships between components and the business rules operating on components.

Smart components will interact in ways permitted by the ontology. The ontology will have two functions in this area:

This common frame of reference allows components to discover the run-time frame of reference of other components and utilize the Ontology Service to access an entire hierarchy of information concerning component categories and their relationships to one another. This information is invaluable to independent components which must collaborate in order to implement system and enterprise level applications and component systems. Along with the forthcoming OMG BOF Rules and Metaobject facilities, the Ontology Service provides a great deal of semantic information which can be used to increase the functionality of smart clients designed for the intelligent use of newly discovered components.

Currently, Eidea Labs in the process of researching and developing an Ontology Service and will include it in our Business Object Framework. Once we have demonstrated the utility of an Ontology Service in domain applications, our business strategy is to make it, along with our Common Business Objects layer, available to system integrators and also to submit an ontology specification with a proof of concept implementation to the OMG for ratification.

About Eidea Labs

The Eidea Labs distributed enterprise architecture is an environment within which system independent business objects can acquire knowledge, collaborate, and represent themselves both syntactically and semantically. Our framework architectures contain common component sets which are customized to develop applications within the scientific and engineering domains. The technologies we employ include: Business Objects, Java/JavaBeans, CORBA/IDL, Smart Agents, 2D/3D Graphics, OODBMS, ORDBMS.



 

OOPSLA'96Business Object Workshop III