Meta-meta is better-better!

Meta-meta is better-better! S. Crawley, S. Davis, J. Indulska, S. McBride, K. Raymond CRC for Distributed Systems Technology (DSTC) University of Queensland, Qld 4072, Australia crawley@dstc.edu.au Abstract The increasing openness and heterogeneity of distributed computing systems requires the representation of meta-information in distributed environments. Most type management systems can only define types within particular type systems. In contrast, the DSTC s Meta-Object Facility (MOF) first defines a type system as a set of meta-meta-objects, and then defines types as meta-objects which are described by those meta-meta-objects. This approach enables the definition of many type systems in one MOF, the composition of type systems, and the federation of type systems. This paper presents a conceptual framework for discussing metainformation and the meta-meta-objects that are the foundation of the DSTC s Meta- Object Facility (MOF), which is a tool for enabling heterogeneity, extensibility and openness. Keywords Distributed systems (C.2.4), programming environments (D.2.6). 1 INTRODUCTION The increasing openness and heterogeneity of distributed computing systems requires the representation of meta-information in distributed environments. Metainformation is information that describes other information. Everyday examples of meta-information include programming language data types, CORBA or DCE

interface definitions, formal specifications and design diagrams, and schemas for databases. In June 1996, the Object Management Group (OMG) issued a Request for Proposal (RFP) for a Meta-Object Facility (MOF) [1] to provide a repository for metainformation in a CORBA-based environment. The OMG MOF needs to support a wide range of clients, including infrastructure services, domain specific services and end user applications; for example, trader service types, interface types, database schemas, user profiles in a command interpreter. DSTC submitted a response [2] to the RFP in January 1997. Some specific functional goals of the DSTC MOF are: 1) to represent types, type relationships and schemas as meta-objects in a form that is convenient for other service and application programs to use, 2) to represent MOF type system definitions as meta-meta-objects, and support the generation of meta-object interfaces from them, 3) to allow the provision of computed type relationships (e.g. subtyping) between types in the same or different MOF type systems. The focus of this paper is the meta-meta-objects in the MOF (item 2 above). An overview of the meta-objects (item 1 above) is given in [3], while the complete specification of the DSTC s MOF submitted to the OMG is in [2]. 1.1 Previous work The DSTC MOF is the third generation of universal meta-information or type managers designed and developed by the DSTC [4][5][6]. The DSTC MOF described here differs from earlier DSTC work in that it represents types in structured form. This entails adding a well defined meta-meta-information level to the type management model to allow the representational aspects of each target type system to be modelled. One consequence is that the MOF can produce specific meta-information interfaces that are tailored to each target type system. Apart from the DSTC work, there is little published material on universal type management. A few type managers have been designed to support a single interface type system; for example the CORBA Interface Repository [7] supports CORBA interface definitions, and the Commandos Type Manager [8] supports a canonical type model for the Comandos supported languages. The only other example of such a facility is the UNISYS Universal Repository [9], which is designed primarily as a repository for software design tools. There is a substantial body of work on the related topic of computational reflection; e.g. [10]. While the MOF uses concepts and terminology from this field, it differs from mainstream reflection in two important respects. First, the DSTC MOF does not support reflection at the lowest meta-level; e.g. the MOF neither creates

instances of the objects whose types it represents, or modifies their behaviour. Second, the MOF takes a top-down view of the meta-level stack, using the upper meta-levels to define lower meta-level object interfaces and (in the future) implementations. By contrast, the mainstream approach to reflection is bottom-up, with upper meta-levels adapting the behaviour of lower meta-level objects. 2 OVERVIEW OF THE META-OBJECT FACILITY The terminology of this document frequently prefixes words with meta-. In general, the meta- prefix indicates that the term denotes a description of a something. In some cases the prefix is repeated; for example, a meta-meta-object is an object that describes a meta-object. 2.1 Abstract Overview The DSTC MOF is based on the abstract model of meta-information as illustrated in Figure 1. The universe of entities ( things ) in a given domain of interest can be classified into types; i.e. sets of entities that share some property or properties of interest. The types for a given domain of interest are defined in some formal or informal type language. The types will have associated domain specific semantics, some of which can be expressed as type relations, consisting of tuples of related types (type relationships). For example, the notion of subtyping in a programming language can be modelled as a binary relation between types; i.e. the set of valid subtype / supertype pairs. A type system consists of a type language for a domain of types, and a definition of the type relations that are meaningful over those types. Finally, a type schema is a collection of types and relationships between them that jointly describe some system of interest. meta-types meta-relations meta-schemas mt ms mr meta-meta-information ts-x ts-y types type relations type schemas t1 tr1 t2 t3 meta-information entities information Domain X Domain Y Figure 1 Meta-meta-information, meta-information and information.

Analogously, a type system can be said to define a domain of meta-information whose values are the types and relationships expressible in the type system. By applying the approach above, it can be reasoned that the values in the metainformation domain can themselves have types. These types over the metainformation domain (i.e. the types of types, relationships) are known as meta-types and relation or relationship types, and are examples of meta-meta-information. The meta-meta-information domain is the one in which MOF type system definitions would be expressed. Further layers may be added to the abstract model, though three layers are generally sufficient for practical purposes. The meaning of the abstract concepts in Figure 1 may be understood using some real world illustrations. If the meta-meta-information layer defined a type system for CORBA IDL, then the meta-information layer would contain schemas of CORBA IDL types and relationships between them, and the entities in the information layer would be CORBA objects. Alternatively, if the meta-metainformation layer defined a type system for design notations, then the metainformation layer would define specific notations, and the entities in the information layer would be design diagrams. 2.2 Concrete Overview The DSTC MOF needs to represent types, relations and schemas in a form that is convenient for client programs. Since the MOF is intended to be universal, it also needs to represent type system definitions and provide a mapping from these to meta-information interfaces. It needs to allow derived relationships between types; e.g. based on analysis of the types or on inference from type system properties. Finally, the MOF needs to allow type system definitions to be augmented with semantics. The DSTC MOF interfaces are all expressed in terms of the CORBA object model, and defined in CORBA IDL. Meta-information is represented as CORBA objects that are called meta-objects. Types and components of types are represented by meta-objects called type objects that have a fixed set of strongly typed properties. Relations are represented by meta-objects called relation objects. Collections of related types and relations are represented by schema objects. Meta-meta-information is represented as CORBA objects that are called metameta-objects. Each kind of MOF type, relation and schema object in a type system is defined by a meta-meta-object; i.e. a meta-type object, meta-relation object or meta-schema object respectively. The closure of a meta-schema (i.e. the set of metameta-objects it depends on) constitute a MOF type system definition. 2.3 Type System Instantiation The main reason that the DSTC MOF represents meta-meta-information is to allow programmers to define their own type systems. The programmer first defines a type system using a language and tools provided with the MOF. The type system

definition is then instantiated to produce a group of CORBA services that manage the meta-objects which represent types, relationships and schemas. The programmer would then develop the tools to populate the meta-object services, and use the meta-information as required. Type system instantiation is illustrated in Figure 2. type system compiler meta-metaobjects type system definition (objects) type system definition (text) meta-object server skeletons IDL compiler meta-object IDL generator meta-object IDL meta-object client stubs, header files, etc. complete meta-object server source code compilation and linking executable meta-object server Figure 2 tool source code MOF type system instantiation and tool building. When the type system has been instantiated, the programmer needs to implement any tools (e.g. browsers, compilers, type checkers, design tools, etc.) needed to create and use meta-information for the new type system. Once again, this could be automated using tools in the MOF toolkit. 3 META-META-OBJECTS AND RELATED CONCEPTS This section describes the MOF objects that are used to define type systems, and thus (indirectly) the interfaces for the meta-objects that represent them. 3.1 Overview of Meta-Meta-Objects compilation and linking type system executable specific tools (e.g. compiler, browser, type checker) The MOF represents type system definitions using CORBA objects called metameta-objects. There are four significant subclasses of the meta-meta-object abstract base class (MMO); these are the meta-type object class (MTO), the meta-relation object class (MRO), the meta-schema object class (MSO) and the meta-data object class (MDO). The first three classes describe MOF meta-object classes, and the

fourth describes data types used within meta-information. The OMT [10] diagram in Figure 3 shows how the meta-meta-object classes relate to each other. MMO MO_name, etc. inherits MTO properties Property Desc. property name type code readonly, derived MRRO knowns MDO type code Known Desc. known name role name known relation role type roles Role Desc. role name role Role Type type label MRO local, derived, readonly types all mtos all mros unique keys Unique Key key roles Key Role role name MSO Specialised Relation MROs Figure 3 The DSTC MOF defines meta-meta-objects to be immutable. No client update operations are provided, and a meta-meta-object server must ensure that the objects cannot be altered by other means. This means that they will be reliable type descriptions of meta-objects, and makes it easier to implement scalable federation (see Section 4.2). All meta-meta-objects provide an equivalent () operation to determine structural equivalence of meta-meta-objects (i.e. isomorphism of the respective object closures) at the most derived level. 3.2 Meta-type objects The meta-meta-object OMT diagram The MOF meta-meta-objects that describe type object interfaces are called metatype objects (MTO). As illustrated in Figure 3, a meta-type object: defines the names and types for all of the properties of its corresponding typeobjects. For example, a DCE interface meta-type would define a UUID property (of type string ). The types of properties can be defined by meta-dataobjects (see Section 3.5). can be aware of the roles that the meta-objects are playing in relationships. Since the meta-objects might be capable of participating in different roles of a relationship, the awareness must be specified on per-role basis. For example, a CORBA interface meta-type might specify that interfaces are aware of being subtypes of another interface, but not of being supertypes of another interface

(i.e. it is aware of its participation in only one role of the subtype relationship). When the meta-object is aware of its participation in a role, the role is called a known role for the meta-object. can inherit from other meta-type objects. Meta-type inheritance simply aggregrates the set of properties and participation awareness. Multiple inheritance is permitted. Normally, a property of a type can be updated. However, a meta-type can define properties as being readonly and/or derived. A readonly property has a value which is supplied at type creation time and is immutable. The types of most programming languages can be expressed using readonly properties. Only languages which permit the run-time redefinition of types would require updatable properties for types. A derived property has a value which is computed from other information; no value is supplied at initialisation time, and the value returned may change if the base information changes. For example, the number of fields property of a Pascal record would be computed by analysing the definition of the record itself. 3.3 Meta-relation objects Meta-meta-objects that describe relationships between meta-objects are called meta-relation objects (MRO). As illustrated in Figure 3, a meta-relation object: defines a set of named roles for the relationship determines which meta-objects (as described by their meta-type) can participate in each role determines which roles or combination of roles must be unique in the set of relationship. For example, the MRO for Java class inheritance would have two roles base and derived. Both roles would be populated by instances of the Java class metatype. As Java permits only single-inheritance of classes, the derived role would be unique (i.e. a derived class can inherit from at most one base class). While relationships are primarily intended to be between types, roles may also contain data values (e.g. names) to describe properties of the relationship itself (as opposed to the properties of types in the roles). For example, the relationship between a C function and its parameters with a third role containing the position of that parameter (i.e. first, second, etc). In this case, the role is associated with a metadata-object rather than a meta-type-object. It is possible for several meta-types to play the same role. However, stylistically, it is preferable to create a single super-meta-type to play the role, and then inherit this super-meta-type into each participating meta-type. In addition, a MRO can describe a relationship as being readonly, derived, or local. Readonly relationships are established at initialisation time and no new

relationships can be added (or deleted) within a particular set of types at run-time. Derived relationships are not added/deleted but are computed from other information held in the MOF. For example, a Java is_a meta-relationship could describe the indirect inheritance between Java classes, which could be derived by recursive use of the Java class inheritance relationship. Normally, the set of relationships between meta-objects can support two styles of queries, relational style and navigation style. Relational-style queries can refer to the complete set of relationships, e.g. which Java classes inherit from the applet class?. Navigational queries are asked relative to a particular meta-object, e.g. a Java class can be asked which classes do you inherit from?. A local relationship does not support relational-style queries. Navigation-style queries are only permitted on known roles (see Section 3.2). It is pointless to have a local relationship without any known roles, as it cannot be accessed! 3.4 Specialised meta-relationship objects The concepts of types containing other types and of giving names to types are prevalent in so many type systems that the DSTC MOF provides specialised metarelationships to describe them. A meta-containment-relationship is a meta-relationship, which additionally nominates one role as the container role and a second role as being the contained role. The contained role must be unique (i.e. there is at most one container for each contained type). For example, in C++, a class contains its methods. A meta-naming-relationship is a meta-relationship, which additionally nominates one role as the namer (which defines the scope of the name), another as the named role, and a third as the name itself. The combination of namer and name must be unique (i.e. the name can be used only once in that scope). For example, in C++, a class is the scope in which its methods are named. Furthermore, the MOF offers a meta-naming-containment-relationship as the two concepts are frequently combined, as our C++ example illustrates. Specialised meta-relationships do not form part of the core MOF but are created by subtyping meta-relationships. The MOF is designed to allow the future addition of any common style of meta-relationship that an implementation wishes to support. 3.5 Meta-data objects In terms of Figure 1, meta-data objects (MDO) are meta-meta-information describing data in the meta-information layer. To be exact, meta-data objects describe the types of the properties of a meta-type and the data-valued roles in a meta-relationship. It is important to understand that meta-data objects do not describe data (or anything else) in the information layer of Figure 1. Data in the information layer is

described by type objects in the meta-information layer which are described by meta-type objects in the meta-meta-information layer. Because the MOF itself is a CORBA-based tool, the types of the properties must be defined using CORBA TypeCodes. This is only an implementation issue and does not limit the ability of the MOF to describe non-corba type systems. 3.6 Meta-schema objects A meta-schema object describes a type system; it is simply a collection of metatypes, meta-relationships, and meta-data objects used to describe that type system. Since meta-meta-objects are permitted to reference meta-meta-objects in other meta-schemas, the complete set of meta-information described by a meta-schema is obtained by taking the closure of all referenced meta-meta-objects. For example, there could be a meta-schema giving access to all DCE types and another meta-schema giving access to all ANSAware types. A new meta-schema for an interoperating DCE-ANSAware environment would only need to contain a single meta-relationship which defined the equivalence of the DCE interface and the ANSAware interface (defined in their respective meta-schemas). It is not necessary to redefine any DCE and ANSAware meta-meta-objects in the new metaschema. 3.7 The Meta-Meta-Object Factory The MOF defines a factory interface with operations for creating each of the supported kinds of meta-meta-object. These operations take parameters that define the resulting meta-meta-objects, and perform a range of consistency checks to ensure that a type system definition will translate into valid IDL for the metaobjects. For example: Every MMO s interface name must be a valid, unique CORBA interface identifier. A local relation must be known to at least one type object in the type system. Consistency checking is performed incrementally as meta-meta-objects are created, and should be completed at the point that the meta-schema object is created. 4 MAKING META-OBJECTS FROM META-META-OBJECTS Having described a type system as a set of meta-meta-objects in the MOF, the next stage is enabling the description of types within that type system by the creation of meta-objects. The DSTC MOF can substantially automate this process by generating the IDL and the skeleton code for the meta-objects from the meta-metaobjects. The full (i.e. most derived) interface for any MOF meta-object will inherit from two distinct kinds of interfaces. The generic meta-object interfaces provide a type-

system-independent view of the meta-information, using textual names, unbounded sequences and the CORBA any type to achieve genericity. These interfaces are provided to support generic tools such as meta-information browsers that work with all kinds of meta-information. The specific meta-object interfaces provide a view that is tailored to each specific type system. These interfaces provide specifically named operations and attributes with ordinary (static) CORBA types, and are designed to be more user friendly for applications working in a particular type system. The specific interfaces are generated from the meta-meta-objects for this type system. For example, a property defined in a meta-type object (see Section 3.2) is mapped by the IDL generator into an attribute of the type object. So, the UUID property of a DCE interface would be accessed through the following CORBA IDL: readonly attribute string UUID; If the type object is aware of its participation as a subtype of other interfaces (see Section 3.2), then it is possible to navigate from subtypes to supertypes using the following attribute: typedef sequence <CORBA_interface> CORBA_interface_seq; readonly attribute CORBA_interface_seq super_type; Note that the lack of uniqueness of the subtype role in the meta-relationship object means that there can be many supertypes to be returned. If the type system involved supported only single inheritance, then the subtype role would be defined to be unique and the generated IDL would reflect this by permitting only a single supertype to be returned: readonly attribute CORBA_interface super_type; Complete details of the generic interfaces and the mapping rules to generate the specific interfaces are given in [2]. 5 MOF ISSUES 5.1 Type System Extensibility and Composibility The DSTC MOF is designed with extension and composition of type systems in mind. The meta-meta-information model allows new meta-type classes to be defined by inheriting from existing ones. Furthermore, since meta-meta-objects are immutable and can be shared by multiple meta-schemas, it should be possible to support composition of type system definitions. For example, a type system designer could compose CORBA and DCE type system definitions to produce a hybrid type model that could be used to describe CORBA / DCE interface mappings.

5.2 Federation of Meta Object Facilities The DSTC MOF is defined with a view to supporting federation of type systems and type schemas across multiple servers. At a shallow level, since meta- and metameta-information is represented as CORBA objects with representationaly complete interfaces, type system definitions and type schemas can be distributed seamlessly across multiple servers, using standard CORBA facilities. At a deeper level, a scheme for federating meta-information must be scalable and robust to be truly viable. Any scheme with bottlenecks or single points of failure would be less than satisfactory. To avoid these problems, a federated meta-object service needs to replicate both meta-information and meta-meta-information. Replication of MOF meta-meta-information is easy. Since MOF meta-meta-objects are immutable, and they provide an equivalent() operation for comparison, metameta-information can be replicated by duplicating the meta-meta-objects. 6 CONCLUSIONS The DSTC has developed a prototype based on the MOF design described here using IONA Technology s ORBIX product [11]. This prototype consists of: a meta-meta-object server, a textual Meta Object Definition Language (MODL) and associated compiler, an IDL generator (to validate the IDL mapping rules), and the generic code for a meta-object server. Future work will include the automatic generation of the type-system-specific code for meta-object servers. The work described in this paper is currently being considered by the Object Management Group for their Meta Object Facility (MOF) [1], i.e. as the standard meta-information service for the CORBA environment. The MOF standard is likely to be a cornerstone for other OMG standards, including the Business Object Facility (BOF) and Object Analysis and Design Facility (OA&DF). The DSTC s initial submission to the OMG [2] and related information is available online from the DSTC s WWW service [12]. It is also intended to submit the MOF design as input to the ISO effort on standardising the ODP Type Repository Function [4][13]. In summary, this paper has introduced a conceptual framework for describing metainformation and meta-meta-information, based on a foundation of meta-metaobjects. The key features that differentiate the DSTC MOF design from previous type management and repository research are as follows: Heterogeneity: the design supports multiple, arbitrary type systems. Extensibility: the design allows new type systems to be added at any time, either starting from scratch or by composing or extending existing type systems.

Openness: the design allows multiple MOF servers to be federated into a seamless distributed meta-information service. ACKNOWLEDGEMENTS The work reported in this paper has been funded in part by the Cooperative Research Centres Program through the Department of the Prime Minister and Cabinet of the Commonwealth Government of Australia. REFERENCES [1] Common Facilities RFP-5: Meta-Object Facility, OMG TC document cf/96-05-02, Object Management Group, June 1996. [2] Meta-Object Facility, OMG TC document cf/97-01-01, Linnæus Project, DSTC, January 1997. [3] Meta Information Management, S. Crawley, S. Davis, J. Indulska, S. McBride, K. Raymond, Proc. Second IFIP International conference on Formal Methods for Open Object-based Distributed Systems (FMOODS 97), Canterbury, United Kingdom, 21st- 23rd July, 1997 (to appear). [4] A Type Management System for an ODP Trader, by Jadwiga Indulska, Mirion Bearman and Kerry Raymond, in Proc. of the IFIP TC6/WG6.1 Int. Conf. on Open Distributed Processing (ICODP-93), Berlin, Sept 1993, North-Holland, pp. 169-180. [5] Types and Their Management in Open Distributed Systems by Wayne Brookes, Stephen Crawley, Jadwiga Indulska, Douglas Kosovic and Andreas Vogel, Journal of Distributed Systems Engineering (to appear in 1997). [6] Type Management using Type Graphs by Stephen Crawley, in Proc. DSTC Symposium 96, Brisbane. 11-12 July 1996. [7] The Common Object Request Broker: Architecture and Specification, Revision 2.0, Object Management Group, April 1995. [8] The COMANDOS Distributed Application Platform, Vinny Cahill, Roland Balter, Neville Harris and Xavier Rousset de Pina (eds.), ESPRIT Research Reports (Project 2071), Volume 1, Springer-Verlag, 1993. [9] Universal Repository (UREP) (web pages), UNISYS. http://www.unisys.com/marketplace/products/urep/ [10] Meta-Architectures and Reflection, Pattie Maes and Daniele Nardi (eds), North- Holland, 1988. [11] Object Oriented Modelling and Design, J. Rumbaugh et al, Prentice Hall, 1991. [12] IONA s Orbix, IONA Technologies. http://www.iona.com/orbix [13] CORBA Meta-Object Facility Specification Development (web pages), Linnæus Project, DSTC. http://www.dstc.edu.au/meta-object-facility/ [14] ODP Type Repository Function ISO/IEC CD 14769, 1997.