Previous section.

Inter-domain Management: Specification Translation

Inter-domain Management: Specification Translation
Copyright © 1997 The Open Group

Reconciling the Models

In the previous chapters of this Object Model Comparison report, it has been established that, in spite of some differences, the OSI and OMG models are fundamentally in alignment.

This chapter explores how some of the differences can be exploited, and how the remainder can be reconciled.

Changing the Models

In principle, the models could be reconciled by demanding changes to one or the other, in order to simplify the mappings between them.

The JIDM working group decided that such an approach is not practical, in that large investments have been made based on each of the existing models. It was assumed that mappings between specifications in each model are constrained to the existing definitions of each model.

However, it is anticipated that this JIDM work might be used to suggest enhancements in future revisions to the models, to aid mappings of specifications between each other.

Exploiting the Differences

Two of the differences between the models (the intended use and interface type) are, as has been pointed out earlier, complementary. Network management systems have to be implemented, ideally using object-oriented software-development tools.

The system aspects of the OMG model can be represented as an invoker invokes operations on a performer (one or more objects), using an abstract procedure-call protocol (abstract in the sense that the syntactical details of what is sent on the wire are not specified). The OSI and Internet Management models exhibit similar invoker/performer characteristics but using a precisely-specified message-passing protocol. Conceptually, the models could be merged, with management protocol intervening between OMG programmatic interface service boundaries.

This approach would satisfy both models. The OMG model would be unaware of the intervening Management protocol, and the end-systems would conform to MGMT protocols. Of course it not quite that simple. Difficult issues such as support for asynchronous operation of the OSI Management model with the potentially synchronous operation of the OMG model would have to be resolved.

Asynchronous OSI MGMT versus synchronous OMG is not a problem if an OMG implementation supports concurrency and/or deferred synchronous calls.

Reconciling the Differences

Having exploited the complementary differences, it is next necessary to reconcile fundamental and incidental differences. There are a number of approaches:

  1. align the models

  2. provide run-time mediation between implementations of the models

  3. provide notational mapping tools.

The following sections explore each of these approaches.

Model Subset Alignment

Ideally, all of the conflicting differences between the models would be resolved by complete alignment. However, this is impractical. Each model is the result of many man-years of unrelated consensus-building, and it is unlikely that agreements to align the models can be quickly reached. Nevertheless, attempting to develop more compatible subsets of the two models is feasible.

The OMG is restructuring its documentation (see reference OOM) to reflect the notion of a core part and a number of component parts, and it is envisaged that profiles based upon this structure will be defined for various applications.

OSI Management has, in its turn, a similar concept. Standards define kernel functionality to guarantee a basic level of interoperability, and a number of additional functional units to permit extended capabilities. Indeed, OMNIPoint is itself a set of agreements based on OSI standards.

This has the practical disadvantage that there are a multitude of existing definitions of managed objects using all of the glory of GDMO. Profiling would not allow interoperability for systems which must implement heavier object definitions than allowed by the profile.

In particular, since recursive attribute SYNTAX structures cause problems for translation to OMG IDL, they should be used with caution in Managed Object definitions. Such recursive structures may require special consideration for mapping to CORBA IDL, and may in some cases require manual intervention in the translation process.

Run-time Mediation

Run-time mediation essentially requires the development of incidental software to match the differences between the specification (for example, OSI Management) model to the implementation (for example, OMG) model. In particular software needs to be developed to handle notifications, late binding, and multiple replies. It is anticipated that agreed approaches to developing such software will be developed.

The IIMC work, which deals with OSI Management and Internet Management coexistence, has used the term proxy to describe devices which perform such run-time mediation. The proxy needs to translate service requests and messages from one domain format to that of another.

Mechanisms for run-time mediation, in general, will depend on tools for notation translation. It is likely that to work properly, any run-time mediation mechanism will require knowledge of the base notation in both the original notation form and the translated notation form. With such knowledge of the notation translation, the run-time mediation mechanisms could dynamically translate messages and service invocations from either form to the other. Thus, the dynamic message translation process may work in either direction, although one notation was chosen as the base and the other notation was derived by notation translation.

Notation Translation Tools

Considerable investment has been made in the notational tools:

This investment takes the form of syntax checkers, data-structure generators, and ASN.1 compilers, and also published specifications giving definitions of object types. Alignment of the tools is thus impractical. However, there is good reason to believe that automatic, or at least semi-automatic, translation between any two models is feasible.

The IIMC has specified translation algorithms between Internet Management and OSI Management formal definitions. Their experience has proved that the concept is practical. However the static notational mappings are not invertible, that is, taking a translated definition through the reverse algorithm does not bring back the original definition. Thus, care must be taken as to which notation is selected as the base. However, once a translation of notation from the base to the derived notation is developed, it may be used by the run-time mediation process to convert services/messages from one domain into those of the other.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index