In today's environment it's becoming more and more difficult to develop well-architectured software for two reasons: the size and complexity of software keeps growing and the target environments are becoming more and more complex. In other words, today's environments are distributed and highly heterogeneous.

Applications are so large that one doesn't develop stand-alone systems anymore - applications are developed from existing components and are likely to use common services available in the target implementation environment. Since networks - especially the Internet - facilitate interoperability, today's applications need to interoperate with other applications and share information with them.

Through modeling, architects attempt to manage the complexity of software systems better. The model allows the software architect to separate design from implementation: it's essentially a design abstraction of the application. It doesn't capture implementation details nor does it specify interoperability semantics, information interchange formats and so on. This is clearly the limitation of the model. To provide a complete definition of the application, the architect needs to specify operational semantics, constraints and information exchange formats in addition to the design abstraction captured by the model.

The three-legged stool for software development recommended by the Object Management Group (OMG) consists of the Unified Modeling Language (UML), the Meta Object Facility (MOF) and the XML Metadata Interchange (XMI) format. The MOF is the meta-metamodel used to describe the entire software development architecture (including itself). That is, it describes modeling languages such as UML, a set of technology metamodels such as the CORBA component model (CCM), the Enterprise JavaBeans (EJB) model and so on, as well as any other user-defined metamodels. The MOF also contains a set of rules that specify the interoperability semantics and interchange format for any of its metamodels.

To describe a software system, the software architect uses a modeling language such as UML (that's already described using MOF) to describe the "design." This design can then be enhanced using the technology models - and other models - to describe implementation/runtime semantics. The MOF rules are applied to the model to define the interoperability semantics and interchange format. Thus this architecture allows the architect to fully describe the software system.

By describing models using metamodels and describing all metamodels using a self-describing meta-metamodel, the MOF-based architecture allows applications and technologies to be described from different levels of abstraction. It also includes rules that specify interoperability semantics and interchange formats, thus facilitating interoperability and information interchange across different execution environments and technologies.

MOF-Based Software Development Architecture
The OMG's metamodel-driven architecture consists of three layers (see Figure 1). At the top of this architecture is the MOF meta-metamodel. The MOF is the subset of UML required to describe OO systems and technologies including itself. Each modeling element in the MOF is well defined in terms of its semantics such that the MOF is capable of providing precise definitions of OO systems and technologies. Note that the UML Revision Task Force (RTF) has recommended that the "core" of UML be aligned with the MOF in a future revision of UML.

In the middle tier the MOF is used to describe the different technologies within the object management architecture (OMA). The OMA is the OMG's distributed object framework. This layer consists of a set of metamodels that describe technologies, services and business models (or information models in general) such as UML (i.e., the UML metamodel), CCM, the Common Warehouse Model (CWM), the EJB model and so on. Note that the technology models are shared by tools and applications. The technology layer is used to provide a rigorous definition of the OO modeling/ implementation environment.

Models of applications and their implementation details are captured in the final tier of this architecture. The technology models of the middle tier are used to capture different aspects of the application. Let's take, for example, an accounting application whose business logic is captured in a UML model. In this architecture the model will be an instance of the UML metamodel. Note that this model captures only the business logic of the application - it doesn't capture any implementation details. The accounting application may be targeted toward one or more implementation environments. The implementation details will be captured by the respective technology metamodels - e.g., EJB and/or CCM metamodels. In addition, the application may be developed using already available components and may make use of services available in the target environment. This information can also be captured using the respective technology metamodels. Thus a rigorous description of the application that includes its business logic as well as implementation details is captured by this three-tiered, metamodel-based approach.

For today's e-business systems (i.e., integrated systems across the enterprise) the metamodel-driven architecture described above combines the business model and the metadata captured in the "meta" levels of the business model to bring about new levels of abstraction, personalization and extensibility of these business models - essential ingredients to manage business information (content) and application/business processes that use this content in the distributed OO environment.

Interoperability and Information Exchange
In addition to providing a rigorous description of OO systems, the MOF contains a set of rules that define the interoperability semantics and information (metadata) exchange formats for a given information model (see Figure 2). The MOF to IDL (Interface Definition Language) transformation rules can be applied to any metamodel to produce a well-defined API. This API can be used to manipulate instance data corresponding to the respective metamodel. This API also provides introspection (a.k.a. reflection) - the ability to discover information contained in the respective metamodel. In addition to the API, the MOF rules also define the DTD corresponding to the metamodel. Any instance data of a metamodel can be represented by an XML Metadata Interchange (XMI) stream that conforms to the corresponding DTD.

Next, a simple example is used to illustrate the interoperability and information exchange capabilities of this MOF-based architecture. In this example the MOF is used to define a relation database (RDB) technology metamodel. The MOF rules are then applied to the RDB metamodel to generate the normative IDL interfaces and XMI DTD for information exchange.

The Metamodel
This simple RDB model consists of two classes: Table and Column (see Figure 3). The Table class has one attribute named "name" of type String. Column has two attributes, "name" and "type" (which describes the data type of the column), both of type String. The model also defines an association with the following semantics:

1. Each column belongs to one and only one table.
2. Each table has one or more columns.

The DTD
The DTD for the simple RDB model generated using the MOF is given in Listing 1. Note that this DTD makes use of XML namespaces (e.g., xmlns:RDB). Any instance data rendered in XMI corresponding to this RDB metamodel will conform to this DTD.

The Interfaces
Due to space limitations, the entire set of interfaces generated isn't included - only the interface generated for the Table (see Listing 2). Note that the interface provides methods to get (name()) and set (set_name()) the name of the table, as well as methods to add modify and delete columns from the table. These generated interfaces can be used to (programmatically) manipulate instance data of the RDB metamodel.

The XMI Stream
Listing 3 shows the XMI stream that represents a simple table named "PERSON." This table consists of two columns:

1. "name" of type "String" used to store the name of a person
2. "socialSecurityNumber" of type "CHAR(9)" used to store a person's social security number as a nine-character string

Current State of the Technology
As part of the ongoing process of defining the OMA, many technology models are being defined using the MOF. The CCM and the CWM are defined using it, and the MOF APIs for interoperability and the XMI DTDs for information exchange are part of the published standard. In fact, XMI DTDs for the common warehouse process of the Metadata Coalition (MDC) have also been generated using the MOF.

At an OMG meeting in November 1998, before XMI became an OMG standard, nine products from five vendors were demonstrated working together using XMI. In fact, a demonstration on the exchange of metadata between CWM repositories of different vendors is scheduled for the September 2000 meeting of OMG to be held in Burlingame, California.

Although the MOF is an OMG standard (and generates only IDL interfaces), it's gaining acceptance outside the OMG as well. Currently, normative Java interfaces to the MOF are being defined as part of JSR-40 - the Java Community Process (JCP) Metadata API Specification. JSR-40 is scheduled to be completed in third quarter 2000.

Summary
UML is used extensively to model object systems. It can't, however, capture implementation details, interoperability semantics, information exchange formats and so on. In today's heterogeneous distributed environment, integration, interoperability and information exchange are core requirements of any software system and need to be represented in the definition of the system. The OMG MOF-based architecture blends metadata with UML and XML and allows the modeler to provide an extensive definition of a system that includes integration and interoperability APIs as well as information exchange formats.

XML References
1. Iyengar, S. (1998). "A Universal Repository Architecture using the OMG UML and MO." Proceedings of the EDOC, La Jolla, CA, October.
2. Kobryn, C. (1999). "UML 2001: A Standardization Odyssey." Communications of the ACM, Vol. 42, No. 10, October.