Solstice Enterprise Manager 4.1 Developing CORBA Applications Doc Set ContentsPreviousNextIndex


Chapter 6

Accessing Information Through Metadata Gateway

The SEM CORBA Metadata Gateway (MGW) implements the Metadata Repository Interface (MRI), which provides methods to access the ASN1 metadata in Solstice Enterprise Manager (Solstice EM).

The purpose of the MGW is to make available IDLs with the following functionality:

This chapter discusses the MGW and how to access information through the MGW.

This chapter describes the following topics:

6.1 Browsing Metadata

The CORBA MGW object acts as a tree-structured repository for ASN1 types encapsulated in the Node IDL interface. The root of the tree is either a known ASN1 type or a type of class (attribute, actioninformation, eventtype or actionreply). Structured ASN1 types such as SET and SEQ contain Node structures as sub-components for ASN1 tree navigation.

The Node structure wraps the actual ASN1 type definitions in IDL format. The following code segment gives the definition of a Node structure.

// ASN1 Type node in the metadata tree/graph
    struct Node {
        Asn1Kind kind ;
        Asn1Kind base_kind ;
        any type_info ;

Each Node structure contains the underlying ASN1 type node in type_info. The kind is identified by the built-in type member.

The client program must connect to the MGW to use the IDL functions.

To connect to the MGW, the client application must initialize the ORB and resolve the root naming context before the MGW can be resolved, as shown in the following code example.

CODE EXAMPLE 6-1   Connecting to the MGW 
// Example to show how to get connected to Metadata Gateway.
#include <iostream.h>
#include <corba.h>
#include <cos/CosNaming_c.hh>
#include <metadata_gw/SEMMetaData_c.hh>
#include <pmi/hi.hh>
int
main(
    int argc,
    char **argv
) {
    CORBA::ORB_var orb;
    
    // CORBA Orb intialization
    try {
        orb = CORBA::ORB_init(argc, argv);
    }
    catch(const CORBA::Exception& e) {  
      cerr << "ORB Init FAILED: " ;
      exit(1);
    }
    
    // Get rootnaming context
    CosNaming::NamingContext_var root_nc;
    try{
        CORBA::Object_var object =
            orb->resolve_initial_references("NameService");
        root_nc = CosNaming::NamingContext::_narrow(object);
        if(CORBA::is_nil(root_nc)) {
            cerr << "FAILED: Unable to obtain root naming context\n" << flush;
            exit(2);
        }
    }
    catch(const CORBA::Exception& e) {   
        cerr << "FAILED: Unable to obtain root naming context:\n" ;
        exit(3);
    }
    SEMMetaData::MetaDataRepository_var meta_data_repository;
    try{
        CosNaming::Name name;
        name.length(1);
        name[0].id = CORBA::string_dup("SEMMetaData::MetaDataRepository");
        name[0].kind = CORBA::string_dup("");
        CORBA::Object_var object = root_nc->resolve(name);
        meta_data_repository =
            SEMMetaData::MetaDataRepository::_narrow(object);
        if (CORBA::is_nil(meta_data_repository)) {
            cerr << "FAILED: Unable to obtain correct MetaData Repository\n"
                 << flush;
            exit(4);
        }
        if(meta_data_repository->_non_existent()) {
            cerr << "FAILED: MetaData Repository does not exist\n" << flush;
            exit(5);
        }
    }
    catch(const CORBA::Exception& e) {
        cerr << "FAILED: Unable to resolve" SEMMetaData::MetaDataRepository:\n
        exit(6);
    }
 }

The ASN1 types follow an inheritance hierarchy. Individual ASN1 classes are modeled as structures when translated to IDL, and instances of a particular class are represented in IDL as a sequence of structures derived from the base class.

The following figure shows the class hierarchy followed in the IDL representation.


FIGURE 6-1   Class Hierarchy Followed in the IDL Representation

The following figure shows the decomposition of IDL data structures defined in metadatagw.idl


FIGURE 6-2   Decomposition of IDL Data Structures Defined in metadatagw.idl1

The following figure shows the mapping of ASN1 Defined Type into the IDL structure DefinedType.


FIGURE 6-3   The ASN1 Defined Type Mapped Into the IDL Structure DefinedType

The ASN1 Structured Types2 are used for building complex data types, and are mapped to IDL as follows. The four structured types SEQUENCE, SET, SEQUENCE OF, and SET OF are represented by ASN1 as ComponentType.

The following figure shows the decomposition of the IDL Component Type.


FIGURE 6-4   Decomposition of Component IDL Types

The Asn1SubType is derived from ParentType by restricting the set of values defined for ParentType. Six different forms of SubTypes are present in Asn1Type. The decomposition of these Asn1SubType mappings is shown in FIGURE 6-5 .


FIGURE 6-5   Decomposition of IDL Subtype

The NamedNumber format of ASN1 follows the IDL mapping decomposition shown in the following figure:


FIGURE 6-6   Decomposition of NamedNumber Format

6.2 Walking Through Metadata

When you wish to encode an IDL value for an attribute, you should get the type information for the attribute, walk3 the type, and encode IDL values based on the subtypes using the following methods:

  1. Node get_asn1_type (in string modname, in string label)

This method returns Node(ASN1Type) representing modname:label PMI: Asn1Type type(modname, label)

  1. Node lookup_node_by_name (in ObjectType object_type, in string gdmo_doc_name, in string name) raises (NotFound);

Node get_asn1_type (in string modname, in string label) gets the IDL type Node structure, which is a wrapper of the Asn1Type.
The following code segment is an example for Asn1SubType ValueRange.

 TopoNodeId ::= INTEGER 
(0..4294967295)

The BNF syntax for the ASN1Tree structure for the type Asn1SubType ValueRange is as follows:

Type::= DefinedType 
DefinedType::= 
ExternalvalueReference  | valueReference
Subtype ::=  SingleSubType | ValueRange| SizeConstrainst| 
SingleInnerSubType| Multiple.....

The Asn1 SubType ValueRange applies only to INTEGER/REAL. It is specified by giving numerical values of the end points of the range.
The following code segment gives the corresponding IDL type mapping wrapped into the Node structure.

Struct Node
{ 
      AsnKind kind,
      Asn1Kind base_kind,
      Any type-info
}



FIGURE 6-7   IDL Mapping Wrapped Into Node Structure

The following code example shows how to get the ASN1 type of an attribute from the metadata.

CODE EXAMPLE 6-2   Obtaining the ASN1 Type of an Attribute From the Metadata
 try {
       
         const char* asn1_module_name = "ASN-1-TEST";
        const char* label = "PatientIdentifier";
        SEMMetaData::ASN1ElementName input;
        input.asn1_module_name = CORBA::string_dup(asn1_module_name);
        input.label  =  CORBA::string_dup(label);
        SEMMetaData::Node_var node =
            meta_data_repository->get_asn1_type(
                input
            );
        CORBA::Any any ;
        any <<= node;
        cout << "Output : Contents of Node: " << endl;
        CORBAUtils::print_any(cout, any, orb, true);
       }
       catch( const SEMMetaData::NotFound& nfe)
       {
             .......
       }
       catch(const SEMMetaData::ProcessingException& 
pe)
       {
	 	 ........
       }

6.3 Obtaining Metadata Information

The MGW provides the following utility functions for obtaining information from the MDR:

You can use these interfaces (utility functions) to verify what is already loaded on the MDR before loading an updated object model.

6.3.1 Listing Documents in the MDR Using the get_doc_list() Method

The get_doc_list method lists all the documents loaded into the MDR.

The following code example shows how to invoke the MDR interface to list all documents loaded on MDR (it is assumed that the client has connected to the metadata_gw and has the object reference, meta_data_repository ready).

CODE EXAMPLE 6-3   Invoking the MDR Interface to List All Documents Loaded on MDR
 try {
       SEMMetaData::StringSeq_var attr_list =
            meta_data_repository->get_doc_list();
        cout << "OUTPUT Printing doc_list :" << endl;
        for (int j = 0; j < attr_list->length(); ++j) {
            cout << "OUTPUT: " << "attr_list" << "["
                 << j << "]  :" << attr_list[j] << endl << flush;
        }
    }
    catch(
        const SEMMetaData::NotFound& nfe
    ) {
     cerr << "FAILED: Request failed [Not Found]: " <<  endl;
        exit(7);
    }
    catch(
        const SEMMetaData::ProcessingException& pe
    ) {
   
        cerr << "FAILED: Request failed [Processing Failure]: " << endl;
        exit(8);
    }
 :
 :

6.3.2 Listing Managed Object Classes in the GDMO Document Name

get_moc_list() lists all the managed object classes defined in the GDMO document name.

6.3.3 Getting the Managed Object Class Attributes

You can use the get_moc_attributes_by_oid and get_moc_attributes_by_name IDL interfaces to obtain the attributes of the specified managed object class from the MDR.

The syntax for these interfaces is:

GDMOElementNameSeq 
  get_moc_attributes_by_oid (in string moc_oid) 
    raises( NotFound, ProcessingException)            
  GDMOElementNameSeq 
  get_moc_attributes_by_name( in GDMOElementName gdmo_element_name)
     raises ( NotFound, ProcessingException)

GDMOElementName is a struct type defined in the metadatagw.idl.

 struct GDMOElementName {
        string gdmo_doc_name;
        string label;
    };

The following code example shows how to obtain the managed object class attributes based on GDMO document name and object class.

CODE EXAMPLE 6-4   Obtaining Managed Object Class Attributes Based on GDMO Document Name and Object Class 
  try {
        const char* gdmo_doc_name = "'Rec. X.721 | ISO/IEC 10165-2 : 1992'" ;
        const char* name = "alarmRecord";
        SEMMetaData::GDMOElementName input;
        input.gdmo_doc_name = CORBA::string_dup(gdmo_doc_name);
        input.label  =  CORBA::string_dup(name);
        SEMMetaData::GDMOElementNameSeq_var attr_list =
            meta_data_repository->get_moc_attributes_by_name( input );
        for (int j = 0; j < attr_list->length(); ++j) {
            cout << "OUTPUT: " << "attr_list" << "["
                 << j << "]  :" << attr_list[j].gdmo_doc_name
                 << " : " << attr_list[j].label << endl << flush;
        }
       }
       catch( const SEMMetaData::NotFound& nfe)
       {
             .......
       }
       catch(const SEMMetaData::ProcessingException& pe)
       {
	 	 ........
       }

6.3.4 Getting Managed Object Class Notifications

You can use the IDL interfaces get_moc_notifications_by_oid and get_moc_notifications_by_name to get notifications defined in a managed object class from the MDR.

The following code example shows how to obtain notifications defined in a managed object class from the MDR.

CODE EXAMPLE 6-5   Obtaining Notifications Defined in a Managed Object Class From the MDR 
GDMOElementNameSeq
get_moc_notifications_by_oid(in string moc_oid)
  raises ( NotFound, ProcessingException) 
  
GDMOElementNameSeq
  get_moc_notifications_by_name(in GDMOElementName gdmo_element_name)
  raises ( NotFound, ProcessingException) 

The following code example shows how to get the notifications of a managed object class based on its oid.

CODE EXAMPLE 6-6   Obtaining Notifications of a Managed Class Object Based on Its oid
try {
        SEMMetaData::GDMOElementNameSeq_var notif_list =
            meta_data_repository->get_moc_notifications_by_oid(
                CORBA::string_dup("1.3.6.1.4.1.42.2.2.2.19.3.1") );
       }
       catch( const SEMMetaData::NotFound& nfe)
       {
             .......
       }
       catch(const SEMMetaData::ProcessingException& pe)
       {
	 	 ........
       }

6.3.5 Obtaining the Textual Representation of an Attribute

The ASN1 textual representation of class Attribute/EventType/ActionReply/ActionInfo can be obtained by providing the oid or name.

The following IDL interfaces are used in the operation:

TextualRepresentation 
   get_textual_rep_by_name(in ObjectType object_type,
                           in GDMOElementName 
gdmo_element_name)
 
    TextualRepresentation 
    get_textual_rep_by_name(in ObjectType object_type,       
	 	              in string oid)

TextualRepresentation is defined in metadatagw.idl as a sequence of strings.

The following code example shows how to obtain the ASN1 textual representation of an attribute.

CODE EXAMPLE 6-7   Obtaining the ASN1 Textual Representation of an Attribute
     try {
        const char* gdmo_doc_name = "'Rec. X.721 | ISO/IEC 10165-2 : 1992'" ;
        const char* name = "probableCause";
        SEMMetaData::MetaDataRepository::ObjectType object_type =
          SEMMetaData::MetaDataRepository::OT_ATTRIBUTE;
        SEMMetaData::GDMOElementName input;	 
     	  input.gdmo_doc_name = CORBA::string_dup(gdmo_doc_name);
        input.label  =  CORBA::string_dup(name);
        SEMMetaData::TextualRepresentation_var text_var =
          meta_data_repository->get_textual_rep_by_name( 
                object_type,
                input
                );
        
        cout << text_var[0] << endl;
}
        catch( const SEMMetaData::NotFound& nfe)
        {
             .......
        }
        catch(const SEMMetaData::ProcessingException& pe)
        {
	 	 ........
        }

1 In the arrow notation used in these figures, a diamond-shaped arrowhead indicates an "Aggregation" relationship; a triangular arrowhead indicates a "Generalization" relationship; a blank arrow between boxes indicates an association between them.

2 Structured types are those consisting of components.

3 "Walking" through the Metadata means traversing the subtypes based on ASN1 type.


Sun Microsystems, Inc.
Copyright information. All rights reserved.
Doc Set  |   Contents   |   Previous   |   Next   |   Index