This chapter explores how some of the differences can be exploited, and how the remainder can be reconciled.
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.
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.
The following sections explore each of these approaches.
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.
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.
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.
| Contents | Next section | Index |