Previous section.

Inter-domain Management: Specification Translation

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

GDMO to CORBA-IDL Translation

In this chapter, the Specification Translation process is described in terms of inputs and outputs and a rough outline of the process is given. The process will be implemented via a compiler which operates on a set of input files and results in some output files. Since IDL definitions are processed in terms of files which determine the granularity and reusability of the IDL definitions, it is necessary to specify which definitions are generated and what files they are defined in. In addition, GDMO adds some complexities since GDMO specifications use full text names, for example, CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992. Since such names are used to import parts of specifications, there must be a way for the translation process to access the files containing these specifications. In addition, it is desirable to be able to associate the resulting IDL files with the original GDMO to facilitate browsing and reuse. This is achieved by providing a "nickname database" which maps from the unique registered name of the GDMO document (or relevant Object Identifier) to a short nickname suitable for use as a filename base. This nickname is used to find imported files and to control the names of the generated IDL files.

Figure: Inputs and Outputs for GDMO Specification Translation

Since nicknames will be used as the basis for naming files, generated IDL files will only be reusable in an environments where identical nickname databases are used. Therefore, it is desirable to make the nickname database as standard as possible (for example, have standard nicknames for all registered GDMO documents and their ASN.1 modules). In order to facilitate this, the following nickname selection method is recommended (but not mandatory):

As it is illegal to modify the existing contents of a standard in this context, it is assumed that the nickname always refers to the latest version of the standard. If, for any reason, parts of the original standard are modified in a revision, the last 2 digits of the revision year can be appended to the nickname.

Outline of Translation Algorithm

The algorithm for translating a GDMO specification to a CORBA-IDL specification is fully detailed in Mapping GDMO Templates to IDL Interfaces . It assumes that GDMO will not allow the use of CMIP version 2 to support extensible types. The basic approach is as follows:

  1. Generate an OMG IDL file for each ASN.1 module that is contained in a given GDMO document and name it with the nickname that has been assigned to the module (see ASN.1 Type to CORBA-IDL Translation ).

  2. Generate an OMG IDL file for each GDMO document and name it with the nickname assigned to the document. That file will contain a module that is named the same as the file and contains interfaces generated for each managed object class template defined in the GDMO document and other information described below.

  3. Generate up to two OMG IDL files containing interfaces for handling Notifications via push and/or pull model when requested.

It should be noted that the mechanism used to handle Notifications is designed to work with OMG Event Services (see reference COSS). It enables the use of typed or untyped events delivered via push or pull models. This gives maximum flexibility to implementors to select the most appropriate mechanisms.

File Names and IDL Modules

The output of the above translation is a set of IDL modules and interfaces. These must be organised into files in a way which facilitates reuse and effective generation of code by the CORBA IDL compiler. Thus the Specification Translation process results in potentially many IDL files. During that process, the following rules determine the number and content of each file:

This approach results in many IDL files being generated. However, the _N and _NP files are generated to provide implementation choice and could all be omitted if untyped event delivery mechanisms are used. In addition, the other files need only be generated once and may be reused by many translated documents. This in turn allows more efficient code generation by the IDL compiler. Since files are of a finer granularity, documents which build on earlier definitions may extract only the portions that they use by import rather than requiring the whole referenced document to be reviewed. As a side benefit, collision between identically named ASN.1 modules may be avoided by using different nicknames for those modules. Module nicknames are not guaranteed to be unique unless they have the unique <nickname> of their containing GDMO document as a prefix. Another side-effect is that references to types imported from other documents need only be scoped by the module's nickname, which must be unique in the environment.

Standard Files for Specification Translation

The specification translation assumes the existence of a number of standard files containing base definitions and classes. These are as follows:

ASN1Types.idl
contains the base definitions for translating ASN.1 types (see IDL Modules for Builtin ASN.1 Types ).

ASN1Limits.idl
contains the definitions for ASN.1 limits (see ASN1Limits.idl File ).

OSIMgmt.idl
contains everything which is needed to use CMIS services based on the mapping defined in this document.

In addition, the following standard files, should be delivered with an implementation of the GDMO to IDL translator:

X219Rem.idl
ROSE errors

X227ACS.idl
ACSE types

X711CMI.idl
CMIP types

X501Inf.idl
Information framework

Example

Using the recommended nickname convention:

resulting in the following IDL files:

Example: File X721Att.idl

// Generated from X721.gdmo
// X721Att.idl file:
 
#ifndef _X721ATT_IDL_
#define _X721ATT_IDL_
 
#include <ASN1Types.idl>
#include "X711CMI.idl"
#include "X227ACS.idl"
#include "X501Inf.idl"
 
module X721Att {
<exports-imports-clause-mapping>
<ASN.1-definition-mapping-list>
};
 
#endif /* _X721ATT_IDL_ */


Example: File X721Not.idl

// Generated from X721.gdmo
// X721Not.idl file:
 
#ifndef _X721NOT_IDL_
#define _X721NOT_IDL_
 
#include <ASN1Types.idl>
#include "X721Att.idl"
#include "X711CMI.idl"
 
module X721Not {
<exports-imports-clause-mapping>
<ASN.1-definition-mapping-list>
};
 
#endif /* _X721NOT_IDL_ */


Example: File X721Par.idl

// Generated from X721.gdmo
// X721Par.idl file:
 
#include <ASN1Types.idl>
#ifndef _X721PAR_IDL_
#define _X721PAR_IDL_
 
module X721Par {
<exports-imports-clause-mapping>
<ASN.1-definition-mapping-list>
};
 
#endif /* _X721PAR_IDL_ */



Example: File X721.idl

// Generated from X721.gdmo
// X721.idl file:
 
#ifndef _X721_IDL_
#define _X721_IDL_
 
#include <OSIMgmt.idl>
#include "X721Att.idl"
#include "X721Not.idl"
#include "X721Par.idl"
 
module X721 {
...........................
};
 
#endif /* _X721_IDL_ */


Example: File X721_N.idl

// Generated from X721.gdmo
// X721_N.idl file:
 
#ifndef _X721_N_IDL_
#define _X721_N_IDL_
 
#include "X721Not.idl"
 
module X721_N {
interface Notifications {
...........................
};
};
 
#endif /* _X721_N_IDL_ */



Example: File X721_NP.idl

// Generated from X721.gdmo
// X721_NP.idl file:
 
#ifndef _X721_NP_IDL_
#define _X721_NP_IDL_
 
#include <OSIMgmt.idl>
#include "X721Not.idl"
 
module X721_NP {
interface PullNotifications {
...........................
};
};
 
#endif /* _X721_NP_IDL_ */




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