Business ObjectsThe OMG Meta Object Facility

David S. Frankel is Director of Advanced Architectures for Genesis Development Corporation of West Chester, PA. He is a member of the OMG Architecture Board. He can be contacted at [email protected].

UML IS KNOWN to most people who use it as a standard notation for describing object models. It is not commonly known that UML has a rigorously defined meta-model.

A high-level view of the UML meta-model (Table 1) reveals three levels we discussed last time:

Table 1. Levels of Classification.


User Objects

The UML meta-model.

A model of a specific information domain. Consists of instances of the UML elements. These instances are called meta-objects.

Instances of the elements of a model.

Class, Attribute, Operation, etc.

UML Classes: Customer, Policy, etc.
UML Associations: The Association between Customer and Policy, etc.

Customer #123, Customer #456, Policy #ABC, Policy #DEF, Association between Customer #123 & Policy #ABC

The level at which the meta-model is defined. The UML meta-model defines a number of elements such as Class, Operation, Attribute, Association, etc. We call each of these elements a meta-class.

The level at which meta-objects are instantiated. Instances of UML Class represent business entities and processes. For example, in the insurance industry we would identify Classes such as Customer, Policy, PolicyReview, etc. Instances of the UML meta-class Association can be defined among Classes, such as an Association that might be defined between Customer and Policy. We call instances of the UML meta-classes meta-objects.

The level at which business objects are instantiated. Instances of UML Classes, such as instances of the Class Customer, are objects rather than meta-objects.

We call UML object models of particular domains, such as of the insurance industry, domain object models or simply domain models.

As we also discussed last time, other meta-models exist, most notably meta-models for database systems. A database meta-model defines basic elements such as database, table, column, key, etc. that are used to define specific data models. A data model based on a typical database meta-model would define specific databases, tables, columns, keys, etc.

Domain object models and data models are stored in specialized databases called meta-data repositories, sometimes referred to simply as repositories. Repository administrators typically would like to manage domain models and data models in a unified fashion, but the disparate nature of the meta-models on which they are based present a formidable obstacle.

The OMG Meta-Object Facility (MOF) bridges the gap between dissimilar meta-models by providing a common basis for meta-models. If two different meta-models are both MOF-conformant, then models based on them can reside in the same repository.

The UML meta-model is based on the MOF standard. UML's MOF conformance is a crucial piece of the OMG's strategy for supporting integrated repositories.

The MOF was officially approved as an Object Management Group (OMG) standard in late 1997. It defines a set of constructs that can be used to describe meta-models. It was submitted by Unisys, IBM, Oracle, and several other companies. OMG rules require the submitters of a successful proposal to produce a conformant shipping product within 18 months.

The MOF is independent of CORBA IDL. It has a set of core constructs that are independent of any standard representation format and has a mapping from the core to IDL.

Basing a meta-model on the MOF entails defining the meta-model in terms of the MOF core constructs. The UML meta-model is based on the MOF, meaning that its constructs are defined in terms of the MOF core elements. Applying the MOF-IDL mapping yields, effectively, a representation of the UML meta-model in IDL.

The existence of this IDL representation of UML means that each element in the UML meta-model has an IDL description. For example, two elements of the UML meta-model are Class and Association. The UML specification maps each of these to the MOF core. In turn, the application of the MOF-IDL mapping yields CORBA IDL for UML Class and UML Association, as depicted by Figure 1.

Figure 1
Figure 1. The IDL for elements of the UML meta-model are determined by the MOF-IDL mapping.

Whenever we specify an object model, we expect to be identifying classes and associations among the classes. The MOF core is object-oriented, so it should come as no surprise that MetaClasses and MetaAssociations are the primary building blocks offered by the MOF core for describing meta-models. The mapping shown by Figure 1 can be confusing unless it is seen in this light.

From the point of view of the MOF core, UML Class and UML Association are both instances of the MOF's MetaClass construct. It is a little tricky to keep track of the fact that what is an Association from UML's point of view is a MetaClass from the MOF's point of view. Moreover, there is a MetaAssociation between UML Class and UML Association, which we call Class-Association! The IDL mapping rules produce IDL of a somewhat different character for instances of MetaAssociation than they do for instances of Meta-Class.

Assume that an analyst uses a MOF-compliant UML tool to define a Class called Policy and a Class called Customer. The tool would store the Policy and Customer Classes in its repository as meta-objects that expose the CORBA IDL for Class, as shown by Figure 2. Assume further that an Association named "Protects" between Policy and Customer is defined. The tool would store the Association in its repository as a meta-object that exposes the CORBA IDL for Association, as also illustrated by Figure 2.

Figure 2
Figure 2. Storing a UML-based domain model in a MOF-compliant repository.

Now, remember the MetaAssociation Class-Association from Figure 1? Class-Association is an element of the UML meta-model. There are two instances of it in the repository shown in Figure 2. The first one represents the Class-Association Policy-Protects—in other words the relationship between the UML Class Policy and the UML Association Protects! The second one, Customer-Protects, represents the relationship between Customer and Protects. You may have to go over this a few times before it really sinks in.

Thus, the UML-MOF and MOF-IDL mappings allow UML-based domain models to be stored as sets of meta-objects that expose industry-standardized CORBA IDL interfaces.

Because CORBA IDL has Java bindings, the IDL interfaces for the UML elements can be implemented in Java. Thus, the meta-objects can be Java-based CORBA objects, as depicted by Figure 2. Because CORBA IDL also has bindings to other programming languages, the meta-objects can also be CORBA objects programmed in other languages. Regardless of the language in which CORBA objects (and thus our meta-objects) are programmed they can be accessed by CORBA clients written in Java.

The MOF essentially adds a fourth meta-level to the classification system described earlier. The MOF calls these levels M0, M1, M2, and M3, as indicated in Table 2.

Table 2. The four meta-levels.
"M3" MOF Core

"M2" Meta-Model

"M1" Model

"M0" User Objects
or User Data

Defines the elements used to specify meta-models.

A meta-model defined in terms of the MOF core elements. Consists of MetaClasses, MetaAttributes, etc.

A model expressed in terms of a meta-model. Models a specific information domain. Consists of instances of the elements of a meta-model (i.e., meta-objects).

Instances of the elements of a model.

MetaClass, MetaAttribute, MetaAssociation Mof::Class, Mof::Attribute, Mof::Association

UML: Class, Attribute, Operation Data Warehousing: Database, table, row
UML Classes: Customer, Policy UML Associations: Protects

Data Warehousing Table: Policy Data Warehousing Row: Address

Customer #123, Customer #456, Policy #ABC, Policy #DEF, Association between Customer #123 & Policy #ABC

The OMG has issued an RFP for a common meta-model for data warehousing. This meta-model will be MOF-compliant. It will surely define elements such as database, table, row, etc., as well as the associations among these elements.

Figure 3 shows how the data warehousing meta-model will be defined in terms of the MOF core elements and how the MOF-IDL mapping will be applied to derive the CORBA IDL interfaces for the elements of the meta-model. Figure 4 shows how a particular data model expressed in terms of the MOF-compliant data warehousing meta-model will be stored in a MOF-compliant repository and accessed by clients.

Figure 3
Figure 3. The IDL for elements of the data warehousing meta-model will be determined by the MOF-IDL mapping.

Figure 4
Figure 4. A data model stored in a MOF-compliant repository.

The fact that the IDL representation of the data warehousing meta-model will be derived via the same MOF-IDL mapping that was used to derive the IDL for UML means that there will be commonalities among meta-objects comprising domain object models on the one hand and meta-objects comprising data models on the other. These commonalities will allow MOF-based repositories to manage domain object models and data models in an integrated fashion.

For example, the MOF-IDL mapping dictates that all meta-object interfaces derive from a common set of interfaces called the Reflective interfaces. The Reflective interfaces allow a tool that does not know the meta-model on which a model is based to probe and iteratively discover the structure of the model.

Furthermore, the common design pattern of the meta-model-specific interfaces derived via the mapping makes it easy for tools that know about one meta-model to be upgraded to know about another meta-model. If a tool knows the UML meta-model, for example, it can read and manipulate UML-based domain models more intelligently than can a generic MOF tool. It will be much easier to upgrade a UML-aware tool to understand a MOF-based data warehousing meta-model than it would be for it to support a non-compliant meta-model.

The MOF also specifies interfaces to a repository. These interfaces are called the Facility interfaces. The Facility interfaces allow a repository client to interact at the repository level—that is, they provide a standard means for a client to get a first reference to a repository at the highest level and to get a high-level picture of its contents. The client, in turn, can use the Reflective and/or meta-model-specific interfaces to browse the repository. (This scenario contrasts with another common one in which a client asks an object for a meta-object that describes its structure and behavior. In that case the client gets a reference to a meta-object deep within the repository structure without having to start at the top level.)

The Reflective interfaces inherited by all meta-objects, the common design pattern of specific interfaces for particular meta-models and the Facility interfaces together form the foundation on which we can build or use repositories that integrate domain object models and data models as illustrated by Figure 5.

Figure 5
Figure 5. An integrated meta-data repository.

The MOF supports standard object principles of substitutability and encapsulation. Therefore, the MOF enables separate but compliant meta-models to be integrated. One meta-model can subclass elements of other meta-models and associations can be established between elements of different meta-models, all without changing the existing meta-models.

Integrated repositories based on a common architecture for meta-models already exist, but none are as yet MOF-compliant. Repository vendors that submitted the MOF specification to the OMG are currently upgrading their products to conform to the MOF.

The OMG has issued an RFP for a Stream-Based Model Interchange Format (SMIF). Unisys, IBM, Oracle, and others responded with the XMI proposal. XMI takes advantage of the independence of the MOF core from any particular representation format such as IDL. It defines a mapping from the MOF core to XML Data Type Dictionary (DTD) format.

Just as the MOF-IDL mapping provides a formula for deriving the IDL for all of the constructs of a MOF-compliant meta-model, XMI provides a formula for deriving an XML DTD representing the constructs of a MOF-compliant meta-model.

With an industry-standardized MOF-XML mapping coming into place, all MOF-based domain meta-models can apply this mapping to produce an XML DTD representing their elements. Figure 6 demonstrates the application of the mapping to the UML meta-model.

Figure 6
Figure 6. The MOF-XML mapping maps elements of the UML meta-model to XML DTD elements.

A MOF-compliant tool can thus represent and stream a UML-based domain model in the form of XML whose structure is dictated by an industry-standardized XML DTD (Figure 7). The intention of the XMI submitters is that XML be used to import and export models to and from a persistent repository. Some developers are using XML text files as repositories, but employing unparsed XML text files as online repositories might not scale as the number and size of models in large enterprises grows.

Figure 7
Figure 7. The MOF-XML mapping specifies how to represent UML-based domain models in XML.

Deriving the XML DTD for the meta-objects via the MOF enhances interoperability between IDL-based meta-objects on the one hand, and XML representations of meta-objects on the other. The XMI submission to the SMIF RFP not only defines the MOF-XML mapping, but also applies that mapping to the UML meta-model. Thus, one of the submission's appendixes contains a complete XML DTD for the UML meta-model.

The XMI's MOF-XML DTD mapping will also be applied to the emerging OMG-standard data warehousing meta-model to define the DTD for XML streams that could be used to import and export compliant data models into and out of repositories in a MOF-compliant fashion.

Because it is possible to map the independent MOF-core to many different representation formats, a mapping from MOF to Enterprise JavaBean (EJB) interfaces is a logical next step. Such a mapping would make it possible to implement MOF-compliant meta-objects as EJBs in a standard, interoperable manner. Thus, UML-based domain models as well as data models could be stored as sets of meta-objects implemented as EJBs.

With an industry-standardized MOF-EJB mapping in place, all MOF-based meta-models could apply this mapping to produce EJB interfaces representing their elements. The OMG specification for UML (Figure 8) could be updated to contain the EJB interfaces and the data warehousing meta-model specification could likewise define EJB interfaces derived via the mapping.

Figure 8
Figure 8. An MOF-EJB mapping would determine the EJB interfaces representing the UML meta-model.

A MOF-compliant tool could thus store a UML-based object model by populating a repository with meta-objects exposing industry-standardized EJB interfaces, as illustrated by Figure 9. Of course the repository could also hold data models exposing the EJB interfaces derived by applying the mapping to the data warehousing meta-model.

Figure 9
Figure 9. An UML-based domain model stored in a MOF-compliant repository as a set of EJBs.

Deriving the EJB interfaces for the meta-objects via the MOF will enhance interoperability between IDL-based meta-objects on the one hand, and EJB-based meta-objects on the other. The mapping between the two will be very straightforward. Repositories could project meta-objects as either exposing IDL or EJB interfaces, depending on the needs of the developer. Importing and exporting via MOF-compliant XML streams rounds out a very exciting picture.

About the Author

Business Objects
The OMG Meta Object Facility