Management Information Model

0. Intended Use

1. Basic Concepts

Managed objects are abstractions of data processing and data communicationsresources for the purposes of management... The design of systems managementrequires that an approach be adopted that will allow the specificationsto be standardized in a modular fashion and provide the extensibility ofthe protocol and procedures. The information model makes use of object-orienteddesign principles because they provide the above capabilities and providefor reuse of pieces of specification. [Part 1]

Managed objects are defined for the purpose of managing systems. Eachmanaged system may contain a Management Information Base (MIB). In theMIB, managed objects are used to represent the resources that may be managedwithin the system. A MIB is the conceptual repository of the managementinformation within an open system. It represents the resources in a managedsystem that have been externalized for communication with a managing system.They are externalized in the sense that a managing system has knowledgeof the MIB, not of the actual data structures of the managed system's internaldatabase; and the two may be vastly different. Resources that are not manageddo not need managed object representations. By managing this MIB, a managingsystem can control the managed system's actual resources. This controlincludes the ability to retrieve information about the resources and toprovision, reconfigure, or inhibit the capabilities of the resources withina managed system.

2. Objects

A managed object is an abstraction of a physical or logical entityfor the purpose of management. It contains the specific information associatedwith the management of that physical or logical entity.

A managed object class defines the characteristics of a typeof physical or logical resource. Instances of a managed object class existto represent specific instances of a resource. Therefore, a managed objectis an instance of a managed object class. The terms "object"and "object instance" are synonymous.

2.1 Operations

Operations may be directed to managed objects and notifications maybe emitted from managed objects. Operations and notifications apply acrossa managed object boundary and map onto underlying communications services,which for the purposes of systems management are the CMIS services definedin [ISO/IEC 9595].

All operations performed on a managed object are visible at the managedobject boundary and can succeed only if consistency constraints of themanaged object are not violated. An operation definition includes the directeffect of the operation on the managed object. In addition to the directeffects of an operation on a managed object, which are defined by the operation,indirect effects may also occur as a result of the relationships in theunderlying resource.

There are two types of operations that may be directed to a managedobject: attribute-oriented operations and object-oriented operations (describedbelow). Notifications are information emitted from managed objects uponan occurrence of an event.

Attribute-oriented operations are applied to the attributes of an object,and their impact is generally confined to the modification of attributevalues. The possible attribute-oriented operations are retrieve (get) anattribute value, set an attribute value, replace an attribute value withthe default value and, for set-valued attributes, add and remove attributevalues.

The operations that are valid for a particular attribute in a managedobject are part of the package definition that references that attribute.Operations to retrieve attribute values map onto the CMIS M-GET service,while operations to set, replace with default, add and remove attributevalues use the CMIS M-SET service.

Object-oriented operations are applied to the object as a whole. Thepossible object-oriented operations are create, delete, and action. Thecreate and delete operations are used to create and delete specific instancesof a managed object class; however, managed objects also may be createdor deleted as side-effects of other normal resource operations. The createand delete operations use the CMIS M-CREATE and M-DELETE services, respectively.

An action is defined to elicit a specific response that is not obtainablethrough the use of the other operations. Action operations use the CMISM-ACTION service. An action defines an operation that may be directedto a managed object to perform a specific operation. An action definitionincludes its behavior (optional), whether it is always confirmed or not,the syntax of any information (if any) in the action request or response,and any specific errors.

A notification defines information that may be sent when a managedobject emits a notification as a result of an event. A notification definitionincludes its behavior (optional), the syntax of any information (if any)in the report or response, and any specific errors. Whether a notificationis confirmed or unconfirmed is implementation dependent but also may beconfigurable by a manager (i.e., Event Forwarding Discriminator objectclass provides a mechanism [ISO/IEC 10164-5]). Notifications use the CMISM-EVENT-REPORT service.

The syntax of the information in the request or response of actionsand notifications is defined using ASN.1 notation [CCITT X.208, ASN.1].It is possible to leave the syntax of these data fields as an open type,such that the syntax is specified using parameters when defining a managedobject class containing the action or notification.

...An operation performed on a managed object can succeed only if theinvoking managing system has the access rights necessary to perform thisoperation, and consistency constraints are not violated. ...Consistencyconstraints are specified as a part of the behavior definition of the attributeor managed object class definition. When performance of an operation, e.g.,replacing an attribute value, would violate a defined constraint, the operationis not performed and a "failure in processing" indication isreturned. [Part 1]

2.2 requests

Not applicable.

2.3 messages

Not applicable.

2.4 specification of behavioral semantics

Part of the definition of a managed object class is behavior. The behaviorcan define:

(a) the semantics of the attributes, operations and notifications;

(b) the response to management operations being invoked on the managedobject;

(c) the circumstances under which notifications will be emitted;

(d) dependencies between values of particular attributes, which mustbe expressed in a way that takes account of the possible presence or absenceof conditional packages;

(e) the effects of relationships on the participating managed objects;

(f) consistency constraints on attributes;

(g) preconditions that identify the conditions when operations and notificationscan be assumed to have valid meaning;

(h) postconditions that identify the results of the processing of amanagement operation or the emission of a notification;

(i) invariants that are in effect for the entire lifetime of the managedobject and that describe conditions that are true for an operation of themanaged object;

(j) synchronization properties of the managed object. [Part 1]... Thebehavior <of a relationship> specified by means of the invariantdefines, in particular, any dependencies this relationship class has onother relationship classes. [US Comments]

Behavior definitions specify behavioral aspects of managed object classesas a whole and also those specific to their characteristics (e.g., packages,attributes, actions, notifications, parameters, etc.). Behavior definitionsare essential to the understanding of an information model and are intendedto supplement the more formal specifications (i.e., template definitions)for which the behavior is provided.

A behavior definition is a string of text (that may be delimited) specifyingthe behavior of the managed object class. The most commonly used delimitersinclude double quotes (") and exclamation points (!). NOTE: It isstrongly recommended that specification authors use delimited text to facilitatemachine parsing and human readability.

The behavior definitions are intended to provide a wide variety of information,including, but not limited to, invariants for the managed object, preconditionsand postconditions for performing operations on the managed object, attributeusage restrictions, integrity constraints between attributes of the sameobject or interactions with other managed objects, instantiation rules,and rules for conditional package inclusion.

The text of a behavior definition may also include a reference to anotherpart of the same document or to another document. The current approachis to specify a behavior definition using text, although a formal descriptionlanguage, such as [Z], [LOTOS], or [ESTELLE] may be used in the future.The use of formal description languages in the context of OSI/CMISE informationmodels is currently under consideration as a new work item in ISO. Thiswill provide a precise method to specify the semantics associated withan OSI/CMISE information model just as the syntax associated with an OSI/CMISEinformation model is currently specified using ASN.1 [CCITT X.208, ASN.1].

Part of the definition of a managed relationship class is a relationshipdescription which can be used to describe:

(a) invariants: the consistency constraints that are in effect for theentire lifetime of the relationship. These are the constraints that mustbe maintained among the participants of the managed relationship....

(b) pre-conditions for operations: the conditions that must be met beforeinvoking operations that are used to manage the managed relationship...

(c) post-conditions for operations: the conditions that must be metimmediately following the operations that are used to manage the managedrelationships... [GRM 93, Clause 7.1.2]

For a formal technique to be appropriate for the description of managedobjects, it must fit into the framework prescribed in the standards. Thismeans that the method must deal with operations as a key concept.The method must be able to handle inheritance, and it must be compatiblewith ASN.1 data descriptions. Also, for a formal technique to beuseful and appropriate for use in standards, it must be based onmathematical concepts and have a well-defined meaning orsemantics. ... The appropriateness of a method depends very much on theapplication. For the description of formal methods from the criteria outlinedabove, we conclude that a logic-based method seems most suitable. ... Sinceinheritance is important, object-oriented flavors of either VDM or Z wouldbe most suitable for this task. Standardization of the methods, includingthe object-oriented extensions, is also necessary. Since Z is gaining popularitymore quickly than VDM, we recommend that the standards bodies choose anobject-oriented version of Z, such as Object-Z, for the formal descriptionof managed objects and managed relationships. [SMI Rapporteur Group 93]

See [X3T5.4] 1.1., 4., 9.4., 9.5. <where invariants, preconditionsand postconditions are proposed and used for defining behavior>

2.5 methods

Not applicable.

2.6 state

Some state attributes have been defined for managed objects in [ISO/IEC10164-2]. The three primary state attributes are the operational state(valid values are enabled and disabled), administrative state (valid valuesare locked, unlocked and shutting down) and usage state (valid values areidle, active and busy). These state attributes may be used in managed objectclass definitions.

2.7 object lifetime

Instances of an object class may be created or deleted either explicitlyor automatically. Yet, once created these instances have identical behaviors.Explicit creation or deletion means that instances are created using theCMIS M-CREATE service or deleted by using the CMIS M-DELETE service atthe request of a managing system.

The create operation creates a managed object of the specified managedobject class, or a managed object of a compatible managed object class(if allomorphism is supported). The containing (superior) managed objectmust already exist before a contained managed object can be created. Ifthe superior managed object is not specified in the create request (eitherdirectly through the Superior object instance parameter or indirectly throughthe instance name specified in the Managed object instance parameter),the managed system assigns a superior object instance as well as the instance'sRDN. If the Superior object instance is specified in the create request,the managed object is created within that superior managed object.

Automatic creation or deletion refers to an object instance being eithercreated or deleted automatically by the managed system (e.g., NE) basedon some predefined occurrence. These object instances are created withthe conditional packages that the managed system supports and with allof the mandatory packages. Depending on the managed object class definition,the objectCreationNotification and the objectDeletionNotification may beemitted upon automatic creation and deletion to notify the managing system.

Creation and deletion rules of a subordinate object may be specifiedvia the name binding template. Multiple name bindings may be defined foran object class with the same superior object class but with differentcreation and deletion behavior.

2.8 behavior/state grouping

The management model in MIM [Part 1] is classical due to constraintsof the underlying CMIS services. However, the GRM model [GRM 93] is generalized.

2.9 communication model

Not applicable.

2.10 events

2.11 transition rules

3. Binding

Not applicable.

4. Polymorphism

For a managing and managed system to interoperate, they must both beaware of the managed object classes that will be used during communication.However, there is also a requirement to maintain interoperability wheneither the managed system or the managed object class definitions are enhanced.Allomorphism allows newly defined object classes (which are extensionsof more general object classes) to be instantiated to satisfy specificmanagement needs, while still permitting communication based on the definitionsof the more general object classes. This concept is valuable for upgradingmanaged object class definitions in one system without simultaneously upgradingthe other system. For example, if a managed object class definition isupgraded in a managed system, but the managing system has not been upgraded,allomorphism allows both systems to be able to communicate using the formermanaged object class definition. In this example in the managed system,the managed object class is changed (as far as the interface is concerned),but still compatible with a former managed object class and instances stillmay behave as if they are instantiations of the former managed object class.

Allomorphism is a property of a managed object instance, not of a managedobject class; that is, the object classes that an object instance may beallomorphic to is decided at the time of the creation of the instance andnot at the time of the instance's class definition. An instance of a managedobject class may only behave allomorphically with instances of a compatibleobject classes.

By use of allomorphism, it is possible to treat a managed object asif it were a member of a class other than the actual instantiated class.Thus, allomorphism simply refers to the capability of a managed objectto "act" as if it were a member of another class. An instanceof a managed object class (the extended managed object) may behave as allomorphicto a compatible object class. The behavior definition of the extended managedobject class should not contradict the behavior of the compatible objectclass.

5. Encapsulation

A facet of object-oriented design is that of encapsulation. Encapsulationensures that the integrity of an object is preserved. This requires thatall operations to be performed are accomplished by issuing a "message"to the object. That is, the internal operation of a managed object is notvisible at the object boundary unless attributes, operations, or notificationsare defined to expose this information. The definition of the managed objectclass specifies what operations can be performed and what consistency constraintsare required to maintain the integrity of the managed object. [Part 1]

6. Identity, Equality, Copy

The process of defining managed object classes requires the assignmentof globally unique identifiers, known as object identifiers, to variousaspects of the managed object class, such as managed object class name,attribute types, etc. The values of these identifiers are used in managementprotocols to uniquely identify aspects of managed objects and their associatedattributes, operations, and notifications. It is therefore a necessaryprecursor to the development of a managed object class definition thatthe standards body or organization concerned should identify or establisha suitable registration mechanism that is capable of issuing object identifiervalues for its use...Once an item of management information has been assignedan object identifier value, it is a requirement that any revision of thedefinition of that item shall not alter the semantics of the information...Allobject identifier values registered in systems management Recommendations/Standardsare allocated under the arc (joint-iso-ccitt ms(9))

[Part 4]

A managed object of one class can contain managed objects of the sameor different classes. This relationship is called containment. This containmentrelationship is a relationship between managed object instances, not classes.A managed object is contained within one and only one containing managedobject. Containing managed objects may themselves be contained in anothermanaged object...The containment relationship is used for naming managedobjects. Names are designed to be unambiguous in a specified context; formanagement this context is determined by the containing object... The nameof an object that is unambiguous in a local naming context, may not beso in some larger naming context... The top level of the naming tree isreferred to as root which is a null object (i.e., an object with no associatedproperties) that always exists....Supported name bindings are not a propertyof the object class as a whole, and individual instances of the same objectclass may use different name bindings. ...Each managed object class thatcan be instantiated must include at least one attribute suitable for ...unambiguouslyidentifying a single managed object within the scope of its superior object...Such an attribute must be part of a mandatory package, it must be testablefor equality and its semantics must permit its value to remain fixed forthe lifetime of each managed object that uses it for naming. When a managedobject is deleted, the value assigned to its naming attribute becomes availablefor reuse, to identify subsequent managed objects created within the samesuperior object. [Part 1]

7. Types and Classes

Each managed object is an instance of a class that includes all managedobjects that share the same definition. A distinguished name is used toname each managed object unambiguously...The definition of a managed objectclass ... consists of:

- The position of the managed object class in the inheritance hierarchy.

- A collection of mandatory packages of attributes, operations, notifications,and behavior.

- A collection of conditional packages of attributes, operations, notifications,and behavior, together with the condition under which each package willbe present. [Part 1]

One managed object class is specialized from another managed objectclass by defining it as an extension of the other managed object class.Such an extension is made by defining further packages that include oneor more of the following:

-new management operations
-new attributes
-new notifications
-new behavior
-extensions to the characteristics of the original managed object class.

A managed object class that is specialized from another managed objectclass is known as a subclass of that class (its superclass). One managedobject class, called top, is designated as the ultimate superclass in theclass hierarchy. Top is an uninstantiable managed object class. [Part 1]

A managed object class defines the characteristics of a typeof physical or logical resource. Instances of a managed object class existto represent specific instances of a resource. Therefore, a managed objectis an instance of a managed object class. The terms "object"and "object instance" are synonymous.

A managed object class is characterized by one or more packages. A packageis a collection of properties of that managed object class. Each consistsof behavior definitions, attributes, attribute groups, actions, and notifications.When a managed object class definition includes a package, a managed objectof that class exhibits all the characteristics stated in the package. Additionally,a package included in a managed object class definition may be mandatoryor conditional.

If the same characteristic, e.g., attribute, is present in two or morepackages of the same managed object class definition, only one copy ofthe characteristic may be present in an instance of that class.

A managed object class may be compatible with another managedobject by having the same characteristics as that other managed objectclass (the compatible class), and optionally extended characteristics.The compatible class may be one of the superclasses of that managed object'sclass in the inheritance hierarchy; however, this is not a requirement.The extended managed object must include all of the mandatory characteristics(i.e., attributes, attribute groups, management operations, and notifications)that would be present in an instance of the compatible managed object class;however the mandatory packages of the extended managed object do not haveto be related to the mandatory packages of the compatible class. Additionalrules of compatibility are found in [ISO/IEC 10165-1, MIM].

8. Inheritance and Delegation

The subclass inherits the operations, attributes, notifications, packagesand behavior of the superclass. This specification allows only for strictinheritance of characteristics... Specialization by deleting any of thesuperclass characteristics is not allowed. Multiple inheritance is theability of a subclass to be specialized from more than one superclass.The subclass inherits the operations, attributes, notifications, packagesand behavior from more than one superclass. When a class has multiply inheritedthe same characteristic from multiple superclasses, then that class isdefined as though that characteristic were inherited from only a singlesuperclass. Specialization shall not introduce contradictions in the subclass'sdefinitions. [Part 1]

9. Noteworthy Objects

9.1 relationships

The inheritance and containment relationships are explicitly representedin the management information model by subclassing and name binding, respectively.Currently, other relationships are represented by the use of attributeswhose values are pointers to related objects. Although these methods havebeen effective so far, much of the semantics of the relationships is hidden.

However, there is currently significant work going on in standards tospecify how a relationship between objects may be defined independentlyof the particular managed object classes that take part in it and independentlyof attributes that may be used to represent it [ISO/IEC CD 10165-7, GRM].It provides a general model and specification tools for the definitionof relationships among managed objects in order to promote a better understandingof relationships.

The MIS-User needs the ability to manage relationships that exist betweenmanaged objects. In order to provide a standardized technique for managingrelationships, a relationship model must be defined. The relationship modelmust satisfy the following requirements: [GRM]

- provide notational tools for specifying behavioral properties of arelationship, such as roles, cardinality and consistency constraints; [GRM+ US Comments]

- provide a mechanism to specify new relationship classes based on existingrelationship classes;

- provide a mechanism to specify generic reusable relationship classes(e.g., composition, dependency) that are common to multiple applications...[GRM]

A managed relationship is a manageable binding between managed objects,where the characteristics of at least one of the participating managedobjects, such as attribute values and behavior, are affected by characteristicsof the other participating managed objects. [GRM]

The GRM work also involves the definition of a Relationship Template,which defines the characteristics of a relationship and its roles, anda Relationship Binding Template, which defines the object classes thatmay be used to fulfill the roles of a relationship.

The general relationship model and specification tools are applicableon two levels:

- The specification of generic, re-usable relationship classes (e.g.,composition, dependency) that are common to multiple applications and thatare specified independent of how the relationship is represented in managedobject class definitions.

- The specification of relationships in terms of the characteristicsthat must be present in the managed objects participating in a relationship,including the specification of the characteristics required for the managementof the relationship.

Relationship behavior includes, for example, roles, cardinalities, andentry/departure rules. The relationship behavior is specified in termsof:

- Invariants that are in effect for the entire lifetime of the relationship

- Preconditions that identify the conditions valid just before the operations(e.g., adding, removing, and changing participants) used to manage therelationship can be carried out

- Postconditions that identify the conditions which must hold followingthe processing of an operation used to manage the relationship.

The specification tools in [ISO/IEC CD 10165-7, GRM] include the definitionof a relationship template, and a role binding template. Relationship templatesare defined for formally specifying the behavior of a relationship classand its supporting roles. Role behavior includes relationship cardinality,role cardinality, object class cardinality, whether dynamic entry and departureis allowed, and the packages that are (sometimes conditionally) presentin a managed object that fulfills this role. Additionally, a role bindingtemplate is defined for specifying which object classes may be used tofulfill the roles of a relationship class.

9.2. attributes

Managed objects have attributes. An attribute has an associated value,which can exhibit structure, i.e., it can consist of a set or sequenceof elements... The value of an attribute may be observable (at the managedobject boundary). The value of an attribute can determine or reflect thebehavior of the managed object. ...Operations on attributes are definedto be performed upon the managed object that contains the attributes andnot directly upon the attributes. The managed object is able to enforceconstraints on attribute values to ensure internal consistency. The definitionof a managed object class can specify constraints between the values ofthe individual attributes. The operations that can be performed on a particularattribute are specified in the definition of the managed object class.[Part 1]... A management operation that is performed on one or more attributesof a managed object can result in other observable changes; these are calledindirect effects. Indirect effects are the result of the relationshipsin the underlying resource. The following indirect effects can occur:

- a modification of an attribute value within the same managed object;

- a change in behavior of the managed object;

- a modification of an attribute in a related managed object;

- a change in the behavior of a related managed object caused by themodification of one or more attributes in the target managed object. [Part1]

Attributes are properties of an object class and characterizesome aspect of it. For the operations interface, attributes represent informationthat is essential to the management of the network. An attribute is notnecessarily a record field (i.e., actual stored value) in a system and,for example, may be computed or derived from one or more stored values.An object instance may differ from another instance of the same objectclass in its attribute values and, because of conditional packages, inthe actual set of attributes that it contains.

An attribute is defined in terms of its behavior, the possible valuesit may exhibit, the valid tests (matching rules) that may be performedon its value, and any specific errors that may cause a processing failureas a result of performing attribute-oriented management operations. Theattribute syntax defines the possible values an attribute may exhibit andis defined using ASN.1 notation. An attribute definition may also be derivedfrom another attribute definition. In this case, the derived attributehas the same syntax as the attribute from which it is derived, but mayadd additional behavior , matching rules or specific errors.

The attribute syntax identifies the common properties of the collectionof values that an attribute may have and is defined using ASN.1 [CCITTX.208, ASN.1]. Examples of attribute syntax that may appear in an ASN.1notation are INTEGER and BOOLEAN. In addition, the attribute may be definedto assume either only one value (single-valued) or multiple values (set-valued).

An attribute group defines a collection of attributes on whicha single operation may be applied to affect the member attributes of thegroup. Allowable operations on an attribute group are retrieving attributevalues and replacing the attribute values with their default values. Theattribute group defines the minimum set of attributes of the group andmay be extended by adding new attributes in a managed object class definition.However, an attribute group may also be defined as FIXED, in which casethe attribute group is not extendible.

9.3 literals

Abstract Syntax Notation One (ASN.1) [CCITT X.208] is the formal notationused to abstractly describe the syntax of information structures to beexchanged between managing and managed systems. It enables the definitionof types of information that need to be transferred using the CMISE services.The information model and the information associated with specific attributes,actions and notifications are definitively described using ASN.1. The full,detailed set of requirements for the operations interface, therefore, includesnot only the textual descriptions of the information model and the specificinformation of Actions and Notifications, but also their ASN.1 definitions.

The ASN.1 definitions used in a document that defines a management informationmodel using the GDMO templates are found in ASN.1 modules. ASN.1 modulescontain both type references and value references. In the GDMO templates,type references are used to define the syntax of attributes (includingpermitted values and required values which are subtypes of the attributetype), action information and reply syntax, notification information andreply syntax, and parameter syntax. Value references are used to definespecific values of defined ASN.1 types. In the GDMO templates, value referencesare used to define attribute default values and attribute initial values.

9.4 containment

(See entry under 9.1 relationships for an overview of relationships.)

The managed objects in an information model are often interrelated.(Note that inheritance is a relationship between managed object classesnot objects.) The relationships between managed objects are a criticalaspect of the information model. Modification to these relationships requireintegrity constraints to be maintained. Currently, there are three waysto represent relationships in an information model: a) containment throughnaming, b) relationship attributes, and c) relationship objects. However,within ISO, a model [ISO/IEC GRM] for formally specifying the behaviorof relationships between managed objects is being developed independentof how the relationships are represented.

a) Containment

Containment describes how an object may physically or logically be partof another object. An object may only be contained in one other object.Containment relationships are formally defined by the use of name bindings,which specify the superior and subordinate objects, the attribute usedfor naming, and any creation and deletion rules. More than one name bindingmay be defined for a particular object class, but only one name bindingmay be supported by an instance of the object class.

To allow access or referencing of managed objects, common unique namesare needed for the objects. The management information model adopts thecontainment relationship for naming managed objects within a givencontext. This relationship describes how an object may be, physically orlogically, part of another object.

The contained object is termed the subordinate object, and thecontaining object is termed the superior object. Superior and subordinateobjects may be instances of the same object class or different object classes.Additionally, an object class may have more than one containment relationship,depending on the application. However, each subordinate object instanceis directly contained within one, and only one, superior object instance.The hierarchy of superior and subordinate object instances is used fornaming object class instances and is called the Naming Tree, orContainment Tree.

A name binding identifies a valid naming relationship in whichinstances of the subordinate object class may be named with respect toinstances of the superior object class. Along with the names of the subordinateand superior object classes, a name binding definition includes the attributeused for naming, and information about how instances that use this namebinding may be created and deleted. Additionally, a name binding definitionmay indicate if the name binding also applies to all subclasses of thesubordinate and to all subclasses of the superior object classes.

b) Attributes

Other relationships are defined using relationship attributes, alsocalled "keys". Relationship attributes are not differentiatedfrom other attributes in the templates but are attributes that interrelatemanaged objects. The attribute values, having ASN.1 syntax of Object Instance(which is either Distinguished Name [DN] or local name), are pointers toobjects to which the managed object is related to. The behavior definitionsof the relationship attribute and the related objects are used to characterizethe behavior of the relationship.

c) Relationship Objects

Objects can also be used to represent relationships when a relationshipitself has information associated with it. Objects of this type are called"relationship objects", and the information associated with therelationship is made visible through the attributes. Operations that affectthe relationship may be directed to this object.

Relationship objects may also have relationship attributes that pointto the objects participating in the relationship. The behavior of a relationshipobject is used to indicate the behavior of the relationship itself. However,relationship objects are not differentiated from the other managed objectsin a managed system.

General Relationship Model

However, using the model in [ISO/IEC CD 1016507, GRM], relationshipclasses may be explicitly defined independently of managed object classdefinitions. These relationship class definitions may be used to providegeneric reusable relationship classes that are common to multiple applications.These relationship classes may be reused by many applications via subclassing.Examples of these relationship classes include:

General Composition: There exists two roles for the general compositionrelationship class: composite role and component role. Exactly one participantin the composite role must exist and correspond to one or more participantsin the component role for an instance of the general composition relationshipclass to exist. Participants in the component role may be of differentmanaged object classes with 0 or more instances of each of the managedobject classes bound to the component role. At least one property of acomposite participant exists such that it depends upon properties of itscomponents. A composite must also have at least one property that is independentof its components' properties (at least, identity). Creating updating ordeleting a component does not change the identity of the composite.

Dependency Relationship: There exist two roles in the dependency relationshipclass: parent role and dependent role. The existence of a participant inthe dependent role implies the existence of a corresponding participantin the parent role. The participant fulfilling the parent role must existbefore another participant can fulfill the dependent role. In other words,a participant in the dependent role cannot exist by itself. The objectclass cardinality of the dependent role is exactly equal to one, that isparticipants fulfilling the dependent role must all belong to the sameobject class.

Symmetric Relationship: There exists two roles for the symmetricRelationshiprelationship class: sR role and participating entity role. Exactly oneparticipant in the sR role must exist and correspond to two or more participantsin the participating entity role for an instance of the symmetric relationshipclass to exist. Both roles in the symmetricRelationship are static: onceestablished, nothing can be changed.

9.5 aggregates

Not applicable.

9.6 other

10. Extensibility

New managed object classes may be defined. These managed object classesmay be subclasses of existing managed object classes. However, the definitionof a managed object classes is not dynamic and each managed object classdefinition must be registered with a unique object identifier.

Managed object classes and other information associated with the informationmodel is registered through the assignment of a globally unique identifier,known as an object identifier. An object identifier allows uniqueidentification via a hierarchical identification authority structure, knownas the object identifier tree or registration tree. Object identifiersare used in a management protocol to uniquely identify aspects of the informationmodel. Once an object identifier is assigned, it cannot be reused.

10.1 dynamic

Not dynamic.

10.2 metaclasses/metaobject protocol

Not applicable.

10.3 introspection

Scoping allows multiple managed objects to be selected so that multipleidentical operations can be performed on all of them. Scoping allows asubset of the objects in a Management Information Tree of an open systemto be selected for the application of a specified operation.

Filters allow for the specification of criteria that managed objectsmust meet in order to have a management operation performed. A filter isan assertion about the presence or value of an attribute in a managed objectand is satisfied if, and only if, the assertion evaluates to TRUE. Theselection criteria is a set of one or more assertions about the presenceof attributes, or the values of attributes in a managed object.

Also, [ISO/IEC CD 10164-16, MKMF] defines managed object classes forrepresenting schema information (e.g., managed object classes supported,managed object class definitions and their associated characteristics).

11. Object Languages

An information model is described using the template notation definedin [ISO/IEC 10165-4, GDMO]. Guidelines for the Definition of Managed Object(GDMO) templates provide a formal representation for the definitions ofthe managed object classes. Additionally, to re-use the descriptions ofcertain characteristics of managed object classes, additional templatesare defined for packages, behaviors, attributes, attribute groups, actions,notifications, name bindings, and parameters. Complete details of the templatedefinitions, including a description of the syntactical conventions, maybe found in [ISO/IEC 10165-4, GDMO]. Templates may reference ASN.1 definitions[CCITT X.208, ASN.1].

12. Semantics of Base Classes (+type constructors)

Not applicable.

13. Background and References

References:

NOTE: Most of the text is abstracted from [ISO/IEC 10165-1, MIM] and[ISO/IEC CD 10165-7, GRM].

[CCITT X.208, ASN.1] CCITT Recommendation X.208 (1989) | ISO/IEC 8824: 1990, Information Technology - Open Systems Interconnection -Specificationof Abstract Syntax Notation One (ASN.1).

[CCITT X.209, BER] CCITT Recommendation X.208 (1989) | ISO/IEC 8824: 1990, Information Technology - Open Systems Interconnection -Specificationof Basic Encoding Rules For Abstract Syntax Notation One (ASN.1).

[ISO/IEC 9595] ISO/IEC 9595, Information Technology - Open Systems Interconnection- Common Management Information Service Definition.

[ISO/IEC 9596-1] ISO/IEC 9596-1, Information Technology - Open SystemsInterconnection - Common Management Information Protocol: Specification.

[ISO/IEC 10040, SMO] CCITT Recommendation X.701 (1992) | ISO/IEC 10040: 1992, Information Technology - Open Systems Interconnection - SystemsManagement Overview.

[ISO/IEC 10164-2] CCITT Recommendation X.731 | ISO/IEC 10164-2, InformationTechnology - Open Systems Interconnection - Systems Management - Part 2:State Management Function.

[ISO/IEC CD 10164-16, MKMF] CCITT Draft Recommendation X.xxx | ISO/IECCD10164-16, Information Technology - Open Systems Interconnection - SystemsManagement - Part 16: Management Knowledge Management Function.

[Part 1] or [ISO/IEC 10165-1, MIM] CCITT Recommendation X.720 (1991)| ISO/IEC 10165-1 : 1991, Information Technology - Open Systems Interconnection- Structure of Management Information - Part 1: Management InformationModel.

[Part 4] or [ISO/IEC 10165-4, GDMO] CCITT Recommendation X.722 (1992)| ISO/IEC 10165-4 : 1992, Information Technology - Open Systems Interconnection- Structure of Information - Part 4: Guidelines for the Definition of ManagedObjects.

[GRM 93] or [ISO/IEC CD 10165-7, GRM] CCITT Draft Recommendation X.xxx| ISO/IEC CD 10165-7, Information Technology - Open Systems Interconnection- Structure of Management Information - Part 7: General Relationship Model

[X3T5/93-324] ANSI X3T5. US Comments on ISO/IEC CD 10165-7.2 GeneralRelationship Model. (Authors: Haim Kilov, Laura S. Redmann).X3T5/93-324,December 3, 1993.

[SMI Rapporteur Group 93] ISO/IEC JTC1/SC21. Open Systems Interconnection,Data Management and Open Distributed Processing. Liaison Statement to ITU-TSSG7 on FDT Use of Specifying Managed Object Behavior. ISO/IEC JTC1/SC21N 7981. August 9, 1993.

featuresmatrix intro page