Solstice Enterprise Manager 4.1 Developing CORBA Applications | ![]() ![]() ![]() ![]() ![]() |
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:
- Functionality to return the ASN1 type of a given attribute name or oid. This functionality is used to encode or decode an IDL value for an attribute and decode an event received as an IDL value.
- Functionality to extract information from the metadata. This functionality is used to verify what is already loaded into the Metadata Repository (MDR), before loading an updated object model.
- Utility functions to convert oid to name and vice versa.
This chapter discusses the MGW and how to access information through the MGW.
This chapter describes the following topics:
- Section 6.1 Browsing Metadata
- Section 6.2 Walking Through Metadata
- Section 6.3 Obtaining Metadata Information
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/graphstruct 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.
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 RepresentationThe following figure shows the decomposition of IDL data structures defined in metadatagw.idl
![]()
FIGURE 6-2 Decomposition of IDL Data Structures Defined in metadatagw.idl1The 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 DefinedTypeThe 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 TypesThe 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 SubtypeThe NamedNumber format of ASN1 follows the IDL mapping decomposition shown in the following figure:
![]()
FIGURE 6-6 Decomposition of NamedNumber Format6.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:
- This method returns Node(ASN1Type) representing modname:label PMI: Asn1Type type(modname, label)
- 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::= DefinedTypeDefinedType::= ExternalvalueReference | valueReferenceSubtype ::= 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:
- get_doc_list()
- get_moc_list()
- get_moc_attributes_by_name()
- get_moc_attributes_by_oid()
- get_moc_notifications_by_name()
< a name="10601">- get_moc_notifications_by_oid()
- get_textual_rep_by_name()
- get_textual_rep_by_oid()
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:
GDMOElementNameSeqget_moc_attributes_by_oid (in string moc_oid)raises( NotFound, ProcessingException)GDMOElementNameSeqget_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:
TextualRepresentationget_textual_rep_by_name(in ObjectType object_type,in GDMOElementName gdmo_element_name)TextualRepresentationget_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.
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.
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) { ........ }
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 |