Previous | Table of Contents | Next |
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.