8.8 Extents

   This sub clause introduces the concept of an “extent? in more detail, and then gives the formal definitions of the extent of a Class, an Association, and a Package.

   Current generation middleware systems typically aim to allow clients to use objects without knowledge of their locations or context. However, groups of objects generally exist in the context of a “server,? which has responsibility for managing them. The implementation of an object often uses knowledge of its shared context with other objects to optimize performance, and so forth.

   While statements about object location have no place in the MOF specification, the MOF Computational Model assumes a notion of context in many areas:

• The classifier-scoped features of an M2-level Class are notionally common to “all instances? of the Class.

• Mappings typically allow a client to query over “all links? in an Association instance.

   It is impractical to define “all instances? or “all links? as meaning all instances or links in the known universe. Therefore, the MOF specification defines logical domains of M1-level instances that are the basis of these and other “for all? quantifications. These domains of M1-level instances are called extents.

    Figure 8.3 shows the extents defined by two “instances? (on the right) of the example meta-model on the left. Notice that the static nesting of Packages, Classes, and Associations inside other Packages is mirrored in the extents (i.e., the dotted ovals).

   Figure 8.3 - Extents for two meta-model instances

   Every Class instance or link belongs to precisely one Class or Association extent. These extents are part of Package extents, depending on the “lexical? structure of the meta-model. This means that extents are strictly hierarchical in nature. As we shall see in 9.2.1, “Meta Object Type Overview,? on page 161 extents are related to the intrinsic container semantics of meta-objects.

   NOTE: There is no requirement that extents have any manifestation in the partitioning of objects between physical MOF servers. However, there are clear performance advantages in implementing such a partitioning.

   The extent of a Class is defined to be the complete set of M1-level instances of the Class that share classifier-scoped properties (e.g., Attribute values). A Class instance is created in the context of a Class extent and remains within that extent for its entire lifetime (i.e., until the instance is explicitly deleted).

   The extent of an Association is defined to be the complete set of M1-level links for the Association. A link is created in the context of an Association extent and remains within that extent for its entire lifetime.

   The extent of a Package is a conglomeration of the extents of Classes, Associations, and other Packages according to the following rules:

1. When an M2-level Package contains a Class or Association, an extent for the Package contains extents for the Classes and Associations.

2. When an M2-level Package contains nested Packages, an extent for the outer Package contains extents for the inner Packages.

3. When an M2-level Package clusters one or more other Packages, an extent for the cluster Package aggregates the extents for the clustered Packages.

4. When an M2-level Package inherits from another Package, an extent for the sub-Package:

a. contains an extent for each nested Package, Class, or Association in the super-Package, b. aggregates an extent for each Package clustered by the super-Package, and c. aggregates or contains extents by recursive application of rule Clause 4 to the super-Package’s super-Packages.

   When a Package inherits from another Package by more than one route, the sub-Package extent will contain one extent for each directly or indirectly inherited Class, Association, or nested Package. This is illustrated in Figure 8.4. Notice that the extent for Package P4 contains only one C1 extent.

   P1 extent

   P1

   P1::C1

   C1s

   P2 extent P3 extent

   C1s

   C2s

   C1s

   C3s

   P2

   P3

   P2::C2

   P3::C3

   P4 extent

   C1s

   C2s

   P4

   C3s

   C4s

   P4::C4

   Figure 8.4 - Extents for Multiply Inheriting Packages

   When a Package clusters other Packages by more than one route, the outer cluster Package will contain one extent for all directly or indirectly clustered Packages. This is illustrated in Figure 8.5. Notice that the relationship between the extents of a cluster Package and the extents of the clustered Packages is aggregation rather than strict containment. In particular, in the P4 case, the extent for P1 is not fully contained by either the P2 or P3 extents.

   P1 extent

   P1

   C1s P1::C1

   P2 extent P3 extent

«clusters»		«clusters»	P1 extent
P2		P3	C1s	C2s
P2::C2		P3::C3
				P4 extent
			P2 extent
«clusters»	P4 P4::C4	«clusters»	C2s	C1s P1 extent	C3s

   Figure 8.5 - Extents for Clusters of Clusters

   NOTE: The extent for an M2 Package that imports (rather than clusters) other Packages does not contain extents for the imported Packages or their contents.