Business Object Design and
Implementation Workshop
Business Object Design and
Implementation Workshop
Position Paper Semantics: the key to interoperability
Stéphane Poirier (spoirier@bnr.ca)
Colin Ashford (ashford@bnr.ca)
Organization
Date/Place: 16 October 1995/Austin, TX
The problem of true interoperability between distributed systems and portability of applications has been only partially solved. We have agreed protocol stacks and agreed APIs, but these are only part of the solution. The remaining road block is an agreement of shared semantics in the form of common information models.
Interoperability is a software architecture issue and, as such, pervades all aspects of software engineering. Agreed protocols and API only provide a syntactical solution to interoperability.Protocols for interoperability have been developed but, rather than providing interoperability, the result has largely been islands of interoperability. Where more than a single interoperability protocols has evolved for the same problem space, the interoperability protocols have been used as competing technological solutions. However, after many years of coping with multi-protocol environments, we have learned how to automatically convert message syntaxes for one protocol to another. Similarly, portability has been addressed by the computer industry by a number of interface definitions both de-facto and standardized. Nonetheless the following key issues persist:
1. Interface languages often have technology specific content imbedded in their syntax. In some cases this requires solving some technological translation problems before the problem of translation from one syntax to another can be attempted.
2. The focus of interface definitions languages, for example IDL [CORBA 1.2], is syntactical description. Semantics are ignored. An example where confusion might occur as a result of this situation, is between the signatures of stacks and queues. Stacks and queues behave differently but have nonetheless the same interface signature. Without a statement to indicate functional intent/contract, unexpected behavior is possible.
Without a common understanding of the semantics of data and the semantics of changes to that data, real interoperability is unachievable. Regardless of interface description language, regardless of protocols: a common understanding of the information models is required for true interoperability. Incompatible models will prevent interoperability even with the use of the same carriage protocol and the same APIs. However, with a common information model, interoperability can be achieved even if protocols and APIs are different.
As an example we can cite the XJIDM management interoperability work [XJIDM]. This work provides a mapping between GDMO, the notation used in OSI Systems Management (SM), and OMG IDL. The key for this interoperability work is that OSI SM has a model of management systems and that the OMG has no such model. The OSI SM model could thus be expressed as easily in GDMO or IDL. Had the OMG defined a systems management model the mapping would have been that much more difficult. As a counter example of where interoperability is not as obvious we can cite the mapping between SNMP and OSI SM where different models of network management do exist. Although using the SNMP model in an OSI environment is not difficult, the solution has to be nonetheless creative [NMForum].
Providing an information model is ultimately providing successive level of semantics with, at the core, a common understanding of the goals of a system.
Some of the components of an information model are well known and require little expansion. The initial components of identification of purpose through to the analysis of requirements, and the final component of building the hardware and software solution have been well explored. The intermediate components of conceptual design and stylistic design have been less well explored.
In the following we will examine the components of an information model which includes provisions for semantic description. We will illustrate the different components of the model by drawing an analogy between building architectures and telecommunication architectures.
Building: A church to meet the requirement of communal worship.
Telecommunications: AManagement System to meet the requirement of remotely managing distributed systems.
In any development process the first step is requirements analysis. As mentioned requirements analysis is well understood [Jacobson, Brooks]. The importance of this phase of development to our current argument is in insuring that the rest of the information model meets these requirements.
Building: An arch provides support allowing the creation of open space within a building.
Telecommunications: a notification is an event report originating from a managed object reporting its status to a managing object.
An architectural concept identifies a particular mechanism required to meet one or more requirements. Its semantics must be well defined.
The identification of architectural concepts does not necessarily preclude any implementation technology-it should be technology independent. It does however provide a point to which different implementation can trace common semantics.
We know that an arch will provide support to an overhanging structure. Conceptually it is irrelevant if the arch is round, lancet or basket-handle. Similarly we know that a notification will carry information from a managed object to a managing object. The exact manner in which this interaction is begun and carried out does not enter into consideration in this component of the model.
Building: Gothic -a recognizable architectural style with provides a certain form and function.
Telecommunications: alarm notifications by event forwarding.
Style is an important step in model refinement. It is akin to design patterns [Gamma, JOOP] with the exception that the semantics are an integral part of the style. Design patterns are normally devoid of semantics to enhance reusability.
Choice in building style may affect effectiveness (width and weight ratios in the case of our Gothic arch), similarly the choice of software style (notifications by event forwarding versus notifications by polling) also affect the effectiveness of the solution. For example in large networks, alarm notification by polling would generate a large traffic load and alarm notifications by event forwarding will be the preferred solution in this environment.
The degree to which interoperability can be achieved between implementations is also subject the diversity of styles chosen. With greater degrees of stylistic variations the bridge between two protocols will be required to do more than simple message translation. As an example, consider a bridge between a domain where alarm notifications occur through polling and a domain where alarm notifications occur through event forwarding. The bridge would be required to:
1. buffer alarm notifications emitted from the event forwarding domain until the polling domain polls for the information; and
2. poll for alarm notifications in the polling domain and forward these notifications to the event forwarding domain.
Building: marble, bricks.
Telecommunications: CORBA, OSI SM.
The final component of the information model is the selection of the elements that will allow the creation of an actual software system.Not all software elements fit all architectural styles. But as long as the elements do support the style, it will be relatively straightforward to provide interoperability between two systems using a same style but different elements.
As marble and bricks can be joined using mortar to fabricate a Gothic arch, so can different software elements that support the same style can be made to easily interoperate. As an example in network management: it has been demonstrated that the OMG CORBA model can carry OSI SM information easily. While OSI SM is conceptually richer than OMG CORBA the basic object models are nearly identical and the management specific models can be assembled from the basic CORBA models.
We have argued that:
GDMO Guidelines for the Definition of Managed Objects.
SNMP Simple Network Management Protocol
IDL the Interface Description Language
XJIDM X-Open Joint Interdomain Management Group
SM Systems Management
[OMG IDL] The Common Object Request Broker: Architecture and Specification, OMG Document Number 91.12.1
[JOOP] Robert Martin, Patterns: PLoP, PLoP, fizz, fizz. Journal of Object-Oriented programming Vol.7, No. 8
[Brooks] Brooks, Frederick P. ,The mythical Man-Month, Addison-Wesley Publishing Company 1975.
[Gamma] Gamma, Helm, Johnson, Vlissides, A catalog of Object-Oriented Design Patterns.
[XJIDM] XJIDM Taskforce, Translation of GDMO Specifications into CORBA-IDL, Sept 9 94.
[TR107] ISO/CCITT and Internet Management Coexistence and Interworking Strategy, Forum TR107, Issue 1.0, 1992.
[Jacobson] Jacobson, Ivar. Object-oriented software engineering; a use case driven approach.Wokingham, England, Addison-Wesley. 1992.
Business Object Design and
Implementation
Page hits
since 6/17/95