Issue 1501: MOF RTF Issue: aggregations crossing M1 and M2 package boundary (mof-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: Summary: The current MOF spec allows Associations to be defined such that a Class in one Package to be "composed of" a Class in another Package. Similar "compositions" at the M1 level; i.e. can occur across "package object" boundaries. We propose to restrict such compositions since we believe that they make implementation of object life-cycle operations problematical in a federated environment. Resolution: resolved and closed Revised Text: Actions taken: June 4, 1998: received issue May 8, 2000: closed issue Discussion: Proposed resolutions: 1. This issue only applies to Associations / AssociationEnds with aggregation == composite case (and the similar case for Attributes: see Issue 1770). 2. This is valid at the M2 level, assuming that the proposed "Package cluster / consol-idation" resolution to Issue 2176 is adopted. 3. At the M1 level, if we replace "package boundary" with "package extent" and define the extent of a clustered package to be the cluster, then composite aggregations can be legal if-and-only-if they don't cross an outermost extent boundary. [The same rule that applies to composite Attributes.] Implementation: Definitions of extents appear in Section 4.6, “Extents,” on page 4-9. Composite aggregations crossing extent boundaries forbidden at the M1 level by Section 4.9.2, “The Composition Closure Rule,” on page 4-19. Implementation: Aggregation semantics of Attributes and Associations discussed in Section 4.8, “Aggregation Semantics,” on page 4-16 and Section 5.3, “Computational Semantics for the IDL Mapping,” on page 5-6. Done [SC]. End of Annotations:===== Return-Path: To: mof-rtf@omg.org, issues@omg.org Subject: MOF-RTF Issue: Aggregations crossing M1 and M2 package boundaries errors-to: request@omg.org priority: bulk Date: Thu, 04 Jun 1998 16:46:57 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Major Summary: The current MOF spec allows Associations to be defined such that a Class in one Package to be 'composed of' a Class in another Package. Similar 'compositions' at the M1 level; i.e. can occur across 'package object' boundaries. We propose to restrict such compositions since we believe that they make implementation of object life-cycle operations problematical in a federated environment. Additional Text: Scenario 1 - Aggregation crossing M2 level package boundaries ------------------------------------------------------------- package P1 { type T1 { ... }; }; package P2 { import P2; type T2 { ... }; association A { role single P1::T1 thing; composite role set [0..*] of T2 thing_components; }; }; A client (in Java) for the IDL interfaces generated from the above might do the following: // Create a T1 instance P1.P1Package p1_pkg = ... P1.T1Class t1_class = p1_pkg.t1_class_ref; P1.T1 t1 = t1_class.create_t1(...); / Create a T2 instance P2.P2Package p2_pkg = ... P2.T2Class t2_class = p2_pkg.t2_class_ref; P2.T2 t2 = t2_class.create_t2(...); // Make t2 a component of t1 P2.A a = p2_pkg.a_ref; a.add_link(t1, t2); // Delete t1. By the definition of 'composite' aggregations, // this should also delete all of t1's components; i.e. t2. t1.delete(); There are a number of problems with implementing the behavior required by the MOF for the above: a) Unless the implementation of the P1::T1 interface has knowledge of the P2::T2 and P2::A interfaces, it cannot 'know' to delete the components of 't1', or what operations to call to do it. This problem will arise in both federated and non-federated environments. In the latter case, it can happen if the implementation of P1 is built before the P2 Package was defined. The root problem is that P1's implementation requires knowledge of P2, despite the fact that Package P1 does not 'depend on' Package P2. If we change the P2::A definition so that T2 is 'composed of' T1's, then this problem disappears. However, other problems remain in the case where the objects live in different servers. See below. b) Suppose that 'p1_pkg' and 't1' live in server S1, and 'p2_pkg', 't2' and 'a' live in server S2. Now suppose that we call 'delete' on 't1' as above. If server S1 can contact S2, it can invoke 't2.delete()' to remove 't2' (as required by the semantics of composites). If server S1 CANNOT contact S2, it has two choices. Either it aborts the deletion of 't1' (which implies transactions!) or it carries on regardless. In the latter case, 't2' is left as an orphan and 'a2' is left containing a bogus link between 't2' and the non-existent 't1'. To prevent this causing long term problems you need a mechanism for queuing up deletes on S1, and / or a garbage collector for S2 ... that knows about P1! c) Suppose that in b) above that S1 and S2 have different policies governing who is allowed to create / modify / delete meta-data. Suppose that a user Fred has update access on S1, but read only access on S2. Similarly Jim has update access on S2 and read only access on S1. Now suppose that Fred creates 't1' on S1, and Jim creates 't2' on S2 and creates the link to make 't2' a component of 't1'. If Fred decides to delete 't1' we have a problem. S1 has to invoke 't2.delete()' on Fred's behalf, but S2 should deny the request. Once again, 't2' gets orphaned, etc. But this time, it is not clear what S2 should do with 't2'. If S2 leaves the object, garbage will accumulate. If S2 garbage collects the object, we've allowed Fred to cause one of Jim's objects to be deleted. Note that in the above, Jim had to do something (create the link) to make this happen. If A had defined in P1 rather than P2, Fred could delete Jim's objects without any action by Jim!!! Scenario 2 - Aggregations crossing M1 level package boundaries -------------------------------------------------------------- package P1 { type T1 { ... }; type T2 { ... }; association A { role single T1 thing; composite role set [0..*] of T2 thing_components; }; }; Problem a) above does not arise here, since any P1 implementation has full knowledge of its own interfaces ... at least its 'public' ones. Problem b) and c) both arise here. [Exercise for reader :-)] Proposed Solution: ------------------ Problem a) alone can be solved by making the following restriction on Associations in the MOF Model; i.e. expressed as an additional constraint on Model::Association: If an Association is defined with a composite aggregation, the Class of the 'composite object' AssociationEnd must be defined in the Package defining the Association or a super-type Package. However this leaves b) and c) unsolved. To solve these you must forbid Associations across Package boundaries at the M2 level; i.e. An Association with composite aggregation can only be defined between Classes defined in the Association's Package or super-types of that Package. In addition, we need a runtime restriction at the M1 level that says: A composite link can only be created between M1 instances of M2 Classes that were created by the same M1 instance of an M2 Package. Violations will raise StructuralError with (new) kind ... [Note that we don't need to talk about object locations in the above rule. An instance of a Package is allowed to create Type instances anywhere it feels like. However, if it does this, it needs to address the problems of life-cycle management by some other means ... which does not need to be standardized. Happy Kerry?]