Issue 1505: MOF RTF Isue: Conflict between "Facility" and "Package Object " (mof-rtf) Source: (, ) Nature: Revision Severity: Critical Summary: Summary: There is a major conflict between the "Facility" Package described in Section 4 and the M1-level object model expressed in Section 7. Section 4 defines a concept of a "model repository", embodied by the Facility::ModelRepository class, as the boundary for M1-level associations and classifier level state. Indeed, this seems to be the main purpose of Facility::ModelRepository instances. On the other hand, the IDL mapping in Section 7 defines the M1-level <package-name>Package interface with the primary purpose of providing this boundary. [Section 5 is ambiguous.] This overlap in purpose and functionality is causing confusion, and is obscuring the need for standardisation of something to provide a container and a directory for a set of (possibly unrelated) models and meta-models. Resolution: Revised Text: Actions taken: June 5, 1998: received issue May 8, 2000: closed issue August 30, 2000: reopened Discussion: Discussion - crawley@dstc.edu.au: In recent between DSTC and UNISYS, these points have become clearer: 1. The Facility section tries to address the problem of clustering Packages. This prob-lem is really a core meta-modelling issue rather than a "repository" issue. UNISYS agree with this analysis, and DSTC and UNISYS have jointly developed the "Pack-age Clustering" Model extension (see issue 2176) to address this aspect. 2. The Facility "package" can also be understood as a design pattern that uses the MOF meta-modelling constructs to extend the interfaces of M1 level instances of a Package in a meta-model. For example, ModelRepository adds hierarchical nam-ing of Model::Package instances and some convenience functions, and MofPack-age adds support for external Tags. 3. The Facility section was not intended to define a MOF repository architecture. 4. UNISYS have (I believe) agreed that Facility can be an optional compliance point. Proposed partial resolution: 1. The Facilities chapter should be made an optional conformance point. 2. The use of MofRepository as Package clustering mechanism should be deprecated in favour of the proposed Model extension for Package consolidation. 3. MofRepository instances should contain (freezable) TagSets rather than Tags, and a mechanism should be implemented that allows a client to find the relevant Tags starting from an M1 level RefPackage instance. 4. The Facilities chapter should be updated to make it clearer what its purpose is. It is important to separate the "design pattern" from the "application" of that pattern to extend the functionality of the MOF Model. Further discussion - crawley@dsct.edu.au: 1. Does the MOF specification need to address conventional repository issues? For example, should it define interfaces that provide a "top level" naming structure for models and meta-models? Should it specify / discuss how to implement different re-pository architectures; e.g. "open", "closed" and "single model". 2. While it is appropriate using modelling to specify extensions to the functionality of Package instances, is it appropriate to use the MOF Model to IDL mapping to im-plement them?: • Pro: the Facility approach allows you to implement required "repository" extensions without changing the base meta-model. Using the MOF Model mappings to generate the interfaces and implementation avoids the need to hand write IDL, MDL, Java classes and so on. • Con: the Facility approach gives bloated IDL. For example, the IDL for Fa-cility contains 6 interfaces, where only one would be required to implement the same functionality extensions directly in IDL. 1. Is the Facility pattern the best way to extend functionality? Would alternative mod-elling patterns would give better interfaces? For example, if we defined Facility as a subtype package of Model and MofRepository as a subtype class of Package, we wouldn't need to have the "kludge" of a MofRepository object with a Model::Mod-elPackage object as an attribute. One way to "address" the repository architectures and interfaces requirements is to rule them out of scope for the RTF. We should then consider issuing a new RFP to address these issues. Washington - A proposal to support COS::Naming and JNDI for name service is being re-searched to address some the issues identified. Proposal to be made before March meeting. Post-Washington discussion: In view of resourcing this RTF, it was decided to defer this issue to MOF2. The existing Facility material will be removed to avoid people implement-ing it now and then objecting if we try to do something different in MOF2. Pre San Jose - The AB has (informally) intervened to point out that an RTF is not allowed to make major changes a CORBA spec. Dropping the Facility Package would be consid-ered by the AB to be a major change. The RTF has therefore reversed its decision to drop the Facility Package chapter. Instead it has decided to add a BIG NOTE saying that it recommends that the material be replaced at the earliest opportunity. Other references to the Facility Chapter have (already) been eliminated. It is sincerely hoped that MOF implementors will take the hint and not spend time trying to implement the current Facility Chapter material. Implementation: Moved Facility Package chapter to make it Chapter 7. Reinstated Facility to the definition of the first MOF compliance point. Added notes to say what the RTF recommends. [SC 24/9/99] Implementation: Deleted a paragraph describing the Facility Package from Section 3.3, “The Structure of the MOF Model,” on page 3-10. Re-moved mention of the Facility Package from first paragraph in Appendix “MOF IDL Summary”. Removed the Facility IDL section from Appendix “MOF IDL Summary”. Removed mention of the Fa-cility Package from first paragraph of Appendix “MODL Descrip-tion of the MOF”. Removed the Facility MODL section from Appendix “MODL Description of the MOF”. [KR] Implementation: Removed the reference to the Facility Package in the is_singleton attribute in Section 3.4.6, “Class,” on page 3-33. Done [SC] The problem of the Facility chapter not being "fit for purpose" remains. The revised MOF RTF 1.3 report says we intend to address this issue urgently. "A Strawman Proposal for MOF 1.4 Repository Framework" by Steve C is 15 page document proposing a solution. PLEASE READ IT! End of Annotations:===== Return-Path: To: mof-rtf@omg.org, issues@omg.org Subject: MOF-RTF Issue: Conflict between 'Facility' and 'Package object' Errors-to: request@omg.org Priority: bulk Date: Fri, 05 Jun 1998 14:22:06 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Critical Summary: There is a major conflict between the 'Facility' Package described in Section 4 and the M1-level object model expressed in Section 7. Section 4 defines a concept of a 'model repository', embodied by the Facility::ModelRepository class, as the boundary for M1-level associations and classifier level state. Indeed, this seems to be the main purpose of Facility::ModelRepository instances. On the other hand, the IDL mapping in Section 7 defines the M1-level Package interface with the primary purpose of providing this boundary. [Section 5 is ambiguous.] This overlap in purpose and functionality is causing confusion, and is obscuring the need for standardisation of something to provide a container and a directory for a set of (possibly unrelated) models and meta-models. Additional Text: The purpose of Facility::ModelRepository is expressed in section 4.1. This defines a 'metamodel' as having a class proxy instance for each Class, a (so called) association proxy instance for each Association, and a package proxy instance for each Package. It is not clear, but I believe that the intended meaning is that there is exactly one instance of each of the proxies per Facility::ModelRepository instance. The 'metamodel' is then defined as the boundary for associations and classifier-level attributes. [Aside: I think it is misleading to talk about 'association proxy' objects. An instance of an interface is best thought of as instances of the association itself; i.e. it "is" the collection of links. By contrast a 'class proxy' is clearly not an instance of a interface: it's an instance of a Class interface. The 'package proxy' case is more debatable ...] By contrast, the IDL mapping in Section 7 defines a M1-level Package interface for each M2-level Package. The sole function of Package instances is to collect together the Class proxy objects and the Association objects; i.e. the instances of the Class and interfaces respectively. Indeed, in the absence of Package nesting, a Package interface consists primarily of readonly IDL attributes giving the class proxy and association object references: see 7.3.1. [Aside 2: every Package interface inherits from the Reflective::RefPackage interface. Hence, some people refer to package proxy or package instance objects as "RefPackage" objects. I think this a bad idea to use this phraseology, since it hides the "type" / "instance" connection between a M2-level Package and its corresponding M1-level Package instances.] I believe that it is a bad to have this redundancy in the spec. It causes confusion for MOF users and problems for MOF implementors. In addition, the ambiguities (even contradictions) between these parts of the MOF spec potentially impact on SMIF! Eliminating the redundancy would entail either 1) removing the Package mapping rules and Reflective::RefPackage, or 2) removing / replacing Facility::ModelRepository and friends. Option 1) - Removing Package and RefPackage ========================================================= If we do this, we will have to add some extra interfaces to support instantiation of a 'model' (i.e. the set of class proxy and association objects defined by a M2-level Package). The current definition of Facility::ModelRepository is 'abstract' so there is no create operation. The Facility::MofRepository class actually depends on RefPackage, and assumes that something else is creating the Model::ModelPackage instance. [At least I think so. The current MOF spec has an Attribute on MofRepository called 'package' which must therefore be supplied as an argument to MofRepositoryClass::create_mof_repository().] At any rate, the M2-level Facility::MofRepository Class depends on both the Reflective::RefPackage and Model::ModelPackageFactory (and hence Model::ModelPackage) interfaces. These will have been removed. It is not clear from Section 4 how one would construct a repository for meta-models other than Model. I believe that the intention is that the meta-modeller should define his own equivalent of the Facility package, possibly importing Facility to allow the subclassing of Facility::ModelRepository. [IMO, this is a most unappealing solution ...] In both the MOFRepository case and the more general one, a ModelRepository object as conceived in Section 4 would need to address the problem of instantiating the class proxies and association objects prescribed by the meta-model. The current IDL mapping defines no way of instantiating class proxy or association objects explicitly. Instead, they are currently instantiated when the package object that 'owns' them is instantiated. In the case of class proxies, the initial values of classifier-level attributes are supplied via arguments to the factory operation for a package object. The types of these arguments are specific to the M2-level Model. Thus any factory operation for a model instance needs to be meta-model specific. In other words, unless we restory to using anys, we can never define a generic ModelRepository; i.e. one that is not specific to a single meta-model. In summary, this option has substantial impact, and leaves us in the situation in which the problem of repositories (i.e. in the sense of servers for meta-objects) supporting multiple / arbitrary meta-models is not addressed. Option 2) - Removing / Replacing Facility::ModelRepository and friends. ======================================================================= Since the current Package mapping and the corresonding Reflective::RefPackage interfaces fully address the "boundary" problem, no changes in that area would be consequent on this option. There remains the issue of finding appropriate replacements for the other functionality provided by the current Facility package; i.e. o supporting a notion of a 'model' o repository mechanisms for creating, managing and locating (by name) Package instances. o supporting transparent extensions to models after the fashion of MofRepository "pragmas". Repository Mechanisms ===================== The repository mechanism can be very light weight. I assume that a repository is an service for one or more instances of one or more meta-models. In the simplest case (one instance of one meta-model) we simply need to publish an object reference for an instance of the meta-model's Package in a name server. The package factory interface need not even be implemented. In other (non-trivial) cases, the repository can be implemented by reusing the CosNaming interface. Standardising the repository then reduces to standardising the naming heirarchy for repository. For example: /Factories /FooPackageFactory /BarPackageFactory /... /... In the above, the (currently) supported package factory objects are located in the Factories subdirectory (context). Instances of packages are located anywhere else, including in user defined subdirectories. There are one or two loose ends in the above ... but you get the picture. Models ====== The first thing to note is that the concept of a "model" is a very rubbery one. In the broadest sense, a "model" is a collection of information that describes something. Implicit in this is the idea that we are modelling the "something" for a particular purpose or from a particular point of view. Since different people (applications) have different points of view, it is not possible to say what is "the" model. Furthermore, we frequently want to take models and embed them in new ones. Thus, the conceptual boundaries of models are necessarily fluid. People who implement meta-data repositories would often like to be able to equate a "model" with an object containment. [It appears to make model interchange easier for example.] While this is technically feasible, doing so is harmful from the modeller's perspective, IMO. In particular it can force the model boundaries to become fixed when they should remain fluid, and forces duplication of meta-data and associated management problems. [I'm surmising this ... ] One of the things that Facility was trying to do was to tie down a 'model' to being the contents of a ModelRepository. IMO, this is a bad thing to do. There is no reason why a conceptual model could not span multiple repositories with distinct containments. My suggestion is that if a meta-model has a concept of a Model that needs to be represented, this can be done within the context of the meta-model definition ... or by a convention that equates a Package object with a model. If the meta-modeller want to combine multiple M2-level Packages into a "model" this can be done by judicious use of Package inheritence and / or cross package Associations: Example 1 package UML_Base { ... }; package UML_Core { import UML_Base_Types; ... }; ... package UML : UML_Core, UML_Base_Types, ... { }; Example 2 package DCE_Types { ... }; package CORBA_Types { abstract Type }; package DCE_CORBA_Mappings { import DCE_Types, CORBA_Types; association DCE_To_CORBA { ... }; association CORBA_To_DCE { ... }; }; In short, we do not need (and probably should not try to) define a meta-model independent notion of a "model". If we need one for the MOF Model itself, then it should be added to that (meta-)meta-model. Pragmas ======= It is impossible to generalise pragmas to work for every kind of model. However, there are two meta-model design patterns that should cover most cases. First is the Tags model as used in the MOF Model itself. The second is as follows: package Model_Ext_Tags { import Model; type Ext_Tag { readonly attribute string name; attribute any value; }; association { role single Model::ModelElement tagged_element; role set [0..*] of Ext_Tag tags; }; }; Return-Path: Date: Fri, 05 Jun 1998 07:46:45 -0700 From: GK Khalsa Organization: Object Radiance, Inc. To: mof-rtf@omg.org, issues@omg.org Subject: Re: MOF-RTF Issue: Conflict between 'Facility' and 'Package object' References: <199806050422.OAA19172@piglet.dstc.edu.au> [This message is a response to: MOF-RTF Issue: Conflict between 'Facility' and 'Package object'] It is important to separate the concept of repository from from the Facility module. Repository is a concept, defined in the MOF specification, used to describe certain MOF semantics. Facility is an optional portion of the MOF. The repository is a necessary concept, not redundant. If the MOF standard were changed to force every metamodel to be defined by a single instance of Package (and its extended contents), then the semantics described by repository could probably be stated in terms of RefPackage instances. This new restriction would require re-definition of the UML metamodel. If the issue is only addressing the optional Facility module, a severity of critical is dubious. Also, as an optional capability, the Facility module should have no bearing on the SMIF. --- GK Khalsa khalsa@objectrad.com Object Radiance, Inc. v: +1 909 677 2518 Murrieta, CA USA f: +1 909 677 1478