8.11 Closure Rules

   The MOF’s support for multiple Package “instances? introduces some potential anomalies into the computational model. These are resolved by three “closure? rules based on the definitions of extents in 8.8, “Extents,? on page 145.

   Recall that a Reference value is defined as a projection of an M1-level Class instance in an Association. Given that Association link sets are not global, a reference’s value must be a projection in a particular link set. There is an “obvious? candidate link set for typical M1-level Class instances, namely the link set belonging to the Package “instance? that contains the Class instance. This is shown in Figure 8.7.

   Figure 8.7 - References for multiple Package instances

    Figure 8.7 shows the Y instances visible to each X instance in two Package instances. Notice that the link set in the second Package instance contains a link to a Y instance belonging to the first Package instance; that is, “<x5,y2>.? This presents no particular problems, since the “x5? object can find the link to “y2? by looking in the A link set for its containing Package instance.

   However, suppose that the “<x5,y2>? had been in the A link set for the first Package instance. Now an instance of the X Class has to look in the link sets of both (or in the general case, all) Package instances to find all of the links. Alternatively, an X instance might only look in the link set for its owning Package instance, leading to non-intuitive computational semantics for Reference values. (Consider the case where there are References for both Association Ends.)

   To avoid such non-intuitive (and arguably anomalous) semantics, the computational semantics for Associations includes a runtime restriction that prevents the problematic links from being created. This restriction is called the Reference Closure Rule:

   “If Class C has a Reference R that exposes an Association End E in an Association A, then it is illegal to cause

   a link to be constructed such that an instance of C (or a sub-class of C) at the exposed End belongs to a

   different outermost extent to the A link set containing the link.?

   The Reference Closure Rule is shown graphically by Figure 8.8 for the case of an Association with a Reference to one end. The Reference Closure Rule is enforced by runtime checks on M1-level operations that construct links (e.g., the link add and modify operations). This can be achieved by using the “outermost_containing_package? operations on the respective meta-objects; see 10.2, “The Reflective Interfaces,? on page 248.

   Figure 8.8 - The Reference Closure Rule

   The MOF Model provides constructs for declaring that the instances of one meta-model element are “composed of? instances of another; see 8.10, “Aggregation Semantics,? on page 152.

   One of the key properties of composites is that a composite instance and its component instances have the same lifetime; that is, when a composite meta-object is deleted, all of its components are also deleted. This is not difficult to implement when the composite instance and its components all belong to the same Package instance. However, a range of problems can arise when a composition crosses one or more outermost Package extent boundaries. For instance:

• How do the server implementations for the respective extents ensure that deletion is reliable in the face of server crash, network partition, and so on?

• What are the access control implications of compositions? For example, should a client of one server / extent be able to implicitly delete components held in another server / extent?

   To avoid having to deal with these difficult questions, the MOF computational model restricts the situations in which compositions may be formed. This restriction is called the Composition Closure Rule:

   “The composite and component instances in a composition along with any links that form the composition

   must all belong to the same outermost Package extent.?

   The Composition Closure Rule is shown graphically by Figure 8.9. This shows the rule as it applies to both composite Attributes and composite Associations.

   Figure 8.9 - The Composition Closure Rule

   The Composite Closure Rule is enforced by runtime checks on M1-level operations that construct links in an Association with Composite semantics; e.g., the link add and modify operations. Similar checks are required for operations that update composite Attributes. The checks can be implemented by using the “immediate_container? and “outermost_containing_package? operations on the relevant meta-objects; see 10.2, “The Reflective Interfaces,? on page

    248 .

   Since the null instance of a Class is defined to notionally belong to all extents for the Class, the Composition Closure Rule does not apply to Attributes with null values.