Issue 2176: Add support for Package Consolidation / Clustering (mof-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: Summary: Package Clustering is a new composition mechanism that is proposed as a way to deal with anomolies that can arise when one Package imports another. Resolution: resolved and closed Revised Text: Actions taken: November 6, 1998: received issue May 8, 2000: closed issue Discussion: A number of restrictions apply to instances of Classes that are defined in different Package instances. For example, a Class instance from one Package instance may not contain a Class instance from another Package instance. The restrictions (see issue 1513) are required to avoid anomalies in the M1 level semantics, and to make federation feasible. These issues arise because we cannot assume that an M1 level server implementation for an imported Package has any knowledge that it has been imported. Unless we do something about it, these restrictions make various constructs involving im-ported elements impossible to use. For example, if a Package P1 defines a Class C1 with a composite Attribute where the Attribute's type is a Class C2 imported from P2, it will be impossible to create instances of C1 that do not break the composition restriction. The solution to this to add a new Package composition mechanism that "consolidates" a group of Packages into a "cluster". (The terms consolidate and cluster are provisional.) A Package can consolidating a number of other Packages. The effect of doing this is similar to nesting the Packages, with the following important distinctions: • A Package may be a member of many M2 level cluster Packages. • A Package placed in a cluster can generalize and be generalized by other Packag-es. At the M1 level, creating an instance of a cluster Package automatically creates a single instance of each Package in the cluster. However, this does not prevent the creation of in-dependent instances of those Packages. The dependent and independent instances will have the same interfaces; e.g. the same mapped IDL. The difference between the two cases is that a cluster Package instance and its dependent Package instances all belong to the same package extent. This means that the extent-based restrictions work differently. Thus if we make Packages P1 and P2 members of a Package cluster PC, we can now create instances of C1 and C2 that belong to the same extent, and hence we assign to the composite at-tribute. Proposed resolutions: 1. Add a definition of extents, and rework / rename the type closure rule based on this rule. 2. Extend MOF Model to allow definition of consolidation Packages. The low impact approach is to add a boolean attribute to Import and renaming it to (say) External. 3. Decide once and for all on the terms we are going to use to describe this mecha-nism. Burlingame - Discussion : Research Subsystems in UML and see if these concepts are re-lated. Implementation: The preferred term is "cluster" / "clustering". Added boolean at-tribute ’is_clustered’ to Import model element and in IDL and MODL. Ammended the Package and PackageFactory templates. [SC] Implementation: Added an OCL rule to take account of clustering. [SC] Implementation: Added some extra text explaining Package composition: Section 4.5, “Package Composition,” on page 4-7. Added extra text explaining the M1 level interactions of generalization and clustering to Section 4.6, “Extents,” on page 4-9 and Section 5.2.1, “Meta Ob-ject Type Overview,” on page 5-2. [SC] Implementation: Ammended description of refImmediatePackage to account for the aggregate nature of Package extent relationships: Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5. Done. [SC] End of Annotations:===== Return-Path: X-Exmh-Isig-CompType: unknown X-Exmh-Isig-Folder: inbox To: mof-rtf@omg.org, issues@omg.org Subject: Add support for Package Consolidation / Clustering Date: Fri, 06 Nov 1998 14:16:03 +1000 From: Stephen Crawley ["new issue 7" from Seattle RTF doc.] Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Significant Summary: Package Clustering is a new composition mechanism that is proposed as a way to deal with anomolies that can arise when one Package imports another. Additional Text: A number of restrictions apply to instances of Classes that are defined in different Package instances. For example, a Class instance from one Package instance may not contain a Class instance from another Package instance. [See also issue 1513.] The restrictions are required to avoid anomalies in the M1 level semantics, and to make federation feasible. The issues arise because we cannot assume that an M1 level server implementation for an imported Package knows that it has been imported. Unless we do something about it, these restrictions make various constructs involving imported elements impossible to use. For example, if a Package P1 defines a Class C1 with a composite Attribute where the Attribute's type is a Class C2 imported from P2, it will be impossible to create instances of C1 that do not break the composition restriction. The solution to this to add a new Package composition mechanism that "consolidates" a group of Packages into a "cluster". (The terms consolidate and cluster are provisional.) A Package can consolidating a number of other Packages. The effect of doing this is similar to nesting the Packages, with the following important distinctions: * A Package may be a member of many M2 level cluster Packages. * A Package placed in a cluster can generalize and be generalized by other Packages. At the M1 level, creating an instance of a cluster Package automatically creates a single instance of each Package in the cluster. However, this does not prevent the creation of independent instances of those Packages. The dependent and independent instances will have the same interfaces; e.g. the same mapped IDL. The difference between the two cases is that a cluster Package instance and its dependent Package instances all belong to the same package extent. This means that the extent- based restrictions work differently. Thus if we make Packages P1 and P2 members of a Package cluster PC, we can now create instances of C1 and C2 that belong to the same extent, and hence we assign to the composite attribute. Proposed resolutions: * Add a definition of extents to the MOF spec, and rework / rename the type closure rule based on this rule. * Extend MOF Model to allow definition of consolidation Packages. The low impact approach is to add a boolean attribute to Import and renaming it to (say) External.