9.2 Meta Objects and Interfaces

   This sub clause describes the different kinds of meta-objects that represent MOF-based meta-data in a CORBA environment.

   The MOF to IDL mapping and the Reflective module share a common, object-centric model of meta-data with five kinds of M1-level meta-object; that is, “instance? objects, “class proxy? objects, “association? objects, “package? objects, and “package factory? objects. The relationships between M2-level concepts and M1-level objects is illustrated by the example in Figure 9.1.

   Figure 9.1 - Relationships between M1 and M2 level

   The example shows how a simple M2-level meta-model (on the left) maps onto the five kinds of M1-level meta-object (in the center). The right of the diagram shows the intrinsic conglomeration relationships that exist between the meta-objects in a Package “instance.? (As noted, in 8.8, “Extents,? on page 145, these relationships do not always have strict containment semantics.)

   NOTE: These intrinsic conglomeration relationships exist for all M1-level meta-objects. They have no explicit meaning in connection with the represented meta-data. Rather, they are provided to assist the management of meta-objects. (The intrinsic conglomeration relationships should not be confused with the M1-level composition relationships that correspond to M2-level composite Associations and Attributes.)

   The instances of an M2-level Package are represented as Package objects. A Package object is little more than a “directory? of read-only attributes that give access to a collection of meta-objects described by a meta-model. The attributes of a Package object refer to “static? objects. In particular, there is

   • one Package attribute for each M2-level Package that is nested or clustered by the Package (none are present in the example above),

   • one Class Proxy attribute for each M2-level Class in the Package, and

   • one Association attribute for each M2-level Association in the Package.

   The number and types of the static objects, and the corresponding attributes in an M1-level Package interface is determined by the M2-level Package specification. The objects cannot be directly created, destroyed, added, or removed by a client.

   While there is usually a one-to-one correspondence between the Packages’ reference attributes and the static objects, this need not be the case. The correspondence is actually determined by the extent relationships as described in 8.8.4, “Package Extents,? on page 147. Thus, for example, when an M2-level Package is clustered by more than one route, there should be one M1-level Package object that is accessed via two attributes.

   A Package object is typically obtained by invoking a “create? operation on Package Factory objects. This creates the Package object, and all of the necessary static objects. The arguments to the “create? operation are used to initialize any classifier-scoped Attributes defined within the M2-level Package.

   As stated above, a Package object contains one (and only one) Class Proxy object for each M2-level Class in the M2-level Package. A Class Proxy object serves a number of purposes:

• it is a factory object for producing Instance objects in the Package “instance,?

• it is the intrinsic container for Instance objects, and

• it holds the state of any classifier-scoped Attributes for the M2-level Class.

   The interface of a Class Proxy object provides operations for accessing and updating the classifier-scoped attribute state. Other operations allow a client to invoke classifier-scoped Operations.

   The interface also provides a factory operation that allows the client to create Instance objects. It also gives read-only access to the set of extant Instance objects contained by the Class Proxy object.

   The instances of an M2-level Class are represented by Instance objects. An Instance object holds the state corresponding to the instance-scoped M2-level Attributes for the Class, and any other “hidden? state implied by the Class specification. Generally speaking, many Instance objects can exist within a given Package “instance.?

   As described above, Instance objects are always contained by a Class Proxy object. The Class Proxy provides a factory operation for creating Instance objects that takes initial values for the instance-scoped Attributes as parameters. When an Instance object is created, it is automatically added to the Class Proxy container. An Instance is removed from the container when it is destroyed.

   The interface for an Instance object inherits from the corresponding Class Proxy interface. In addition it provides:

   • operations to access and update the instance-scoped Attributes,

   • operations to invoke the instance-scoped Operations,

   • operations to access and update Associations via Reference,

   • operations that support object identity for the Instance, and

   • an operation for deleting the Instance object.

   Links that correspond to M2-level Associations are not represented as meta-objects. Instead, an M1-level Association object holds a collection of links (i.e., the link set) corresponding to an M2-level Association. The Association object is a “static? object that is contained by a Package object, as described previously. Its interfaces provide:

   • operations for querying the link set,

   • operations for adding, modifying, and removing links from the set, and

   • an operation that returns the entire link set.

   This sub clause describes the patterns of interface inheritance in the CORBA IDL generated by the MOF to IDL mapping. The patterns are illustrated in Figure 9.2.

   Inheritance in Generated Interfaces

   Figure 9.2 - Generated IDL Inheritance Patterns

    Figure 9.2 shows an example MOF meta-model expressed in UML (on the left) that consists of two Packages P1 and P2. The first Package P1 contains Classes C1 and C2, where C2 is a subclass of C1 and an Association A that connects C1 and C2. The second Package P2 is then defined as a subpackage of P1.

   The UML class diagram (on the right) shows the inheritance graph for the generated interfaces corresponding to the example meta-model.

    The root of the inheritance graph is a group of four predefined interfaces that make up the Reflective module; see 10.2, “The Reflective Interfaces,? on page 248. These interfaces collectively provide:

   • operations that implement meta-object identity,

   • operations for finding a meta-object’s containing package instance(s),

   • an operation for finding a meta-object’s M2-level description, and• operations for exercising the functionality of a meta-object independent of its generated interface.

   NOTE: The interfaces in the Reflective module are all designed to be “abstract;? that is, it is not anticipated that they should be the “most derived? type of any meta-object.

   The interfaces for the Package objects, Association objects, Class Proxy objects, and Instance objects provide functionality as described previously. The inheritance patterns are as follows:

• All Package object interfaces inherit (directly or indirectly) from RefPackage.

• All Association object interfaces inherit from RefAssociation.

• All Class Proxy interfaces inherit (directly or indirectly) from RefObject.

• All Instance interfaces inherit from the corresponding Class Proxy interfaces.

• When an M2-level Package P2 inherits from another P1, the corresponding interface P2 inherits from P1.

• When an M2-level Class C2 inherits from another C1:

• the Class Proxy interface for C2 inherits from the Class Proxy for C1, and • the Instance interface for C2 inherits from the Instance for C1.

   The diamond pattern of interface inheritance is virtually unavoidable. The C2’s Class Proxy needs to inherit the interface features for C1’s classifier-scoped Attributes and Operations. Similarly, C2’s Instance interface needs to inherit the instance-scoped interface features.

   NOTE: The IDL mapping supports some Tags for specifying addition IDL supertypes of various generated interfaces; see “Tags for Specifying IDL Inheritance? on page 196. The effect of these Tags on the inheritance graph is defined by the relevant IDL templates; see “Package Template? on page 206, “Class Template? on page 209, “Class Proxy Template? on page 210, and “Association Template? on page 214.