OMG Model-Driven Architecture

To solve the problems of non-automated and non-standardized software manufacturing, the OMG (Object Management Group) introduced the Model-Driven Architecture (MDA) initiative as an approach to system-specification and interoperability based on the use of formal models [20], [21], [08]. In MDA, platform-independent models (PIMs) are initially expressed in a platform-independent modeling language, such as UML. The platform-independent model is subsequently translated to a platform-specific model (PSM) by mapping the PIM to some implementation language or platform (e.g., Java) using formal rules. This process is shown in Figure 2-10. This process is very similar to the production process shown in Software Industry. The MDA process, on the other hand, places formal system models at the core of the interoperability problem. What is most significant about this approach is the independence of the system specification from the implementation technology or platform. The system definition exists independently of any implementation model and has formal mappings to many possible platform infrastructures (e.g., Java, XML, SOAP).

Figure 2-10. OMG Model-Driven Architecture (MDA) approach.

At the core of the MDA concept are a number of important OMG standards: The Unified Modeling Language (UML), Meta Object Facility (MOF), XML Metadata Interchange (XMI), and the Common Warehouse Metamodel (CWM). These standards define the core infrastructure of the MDA, and have greatly contributed to the current state-of-the-art of systems modeling [21]. These standards form the basis for building coherent schemes for authoring, publishing, and managing models within a model-driven architecture.

One basic concept of MDA is to use models directly used in software production chains. Although this possibility had often been considered and partially applied, we may now envision its large-scale industrial deployment. Until now object analysis and design models have mainly been used to document software system. Analysts and designers were building models that were provided to programmers only as inspiration material to facilitate the production of concrete software. The move from this 'contemplative' period to a new situation where production tools will be model-driven has been facilitated by the introduction of the XMI recommendation. This XMI recommendation builds upon many other standards like UML, MOF, OCL and XML. We may recognize its importance from the fact that many new proposals at OMG are no more provided as a simple paper description, but as a XMI DTD as well, corresponding to the MOF-compatible meta-model of the proposal. This helps to reduce the gap between human readable and computer interpretable standards.

The W3C XML standard provides the transfer syntax but also a complete technological space with widely available and well-engineered tools on which to map the MOF-compatible models. This will allow for example to apply transformation systems like XSLT to any kind of high level models. As Figure 2-11 suggests, there is a similarity between the relation of a XMI document to a XMI DTD or schema on one side and the relation of a MOF-based model to a MOF-based meta-model on the other side. The XML, MOF, UML and OCL standards are well integrated in XMI and play together to provide a powerful model serialization tool. The move from DTDs to XML schemas is being integrated into this process and will strengthen the resulting possibilities.

Figure 2-11. XMI representation of MOF-compatible models.

The MDA is preparing for a new situation where models will be first class entities. They are stand-alone and on-line accessible. This means that the execution model will contain execution objects and if necessary these execution objects will have the capacity to access other attributes explicitly represented in other models. Ultimately, all entities present in the various models may show autonomous behavior. This organization is based on the fact that there may exist a common execution bus (i.e. CORBA, DotNet, the Web, Java) and an "orthogonal" common representation bus (i.e. the MOF). The architecture goes much beyond proposals of separation of aspects with AOP (Aspect-Oriented Programming, [30]). It shows how the meta-modeling framework may provide possibilities only currently offered by computational introspection and reflection. Of course the separation of aspects with meta -models will make its way in a progressive evolution. However more limited applications of this general scheme to deal with the reification of contracts, exceptions or performance QoS specification may be envisioned on a medium-term basis.

A Survey of Standards

At the core of the MDA concept are a number of important OMG standards: The Unified Modeling Language ([45]), Meta Object Facility ([22]), XML Metadata Interchange ([44]), and the Common Warehouse Metamodel ([07]). These standards define the core infrastructure of the MDA, and have greatly contributed to the current state-of-the-art of systems modeling. The following sections give a brief overview of the MDA standards and other standards which are important for the development of openMDX-based applications.

MOF - Meta Object Facility

The Meta Object Facility ([22]) is an OMG standard defining a common, abstract language for the specification of metamodels. MOF is an example of a meta-metamodel, or model of the metamodel (sometimes called an ontology). MOF is distinctly object-oriented in nature. It defines the essential elements, syntax, and structure of metamodels that are used to construct object-oriented models of discrete systems. MOF serves as the common model of both the CWM and UML metamodels. Specifically, the MOF specification provides:

An abstract model of the generic MOF objects and their associations.
A set of rules for mapping any MOF-based metamodel to language-independent interfaces (defined in CORBA IDL). An implementation of these interfaces for a given metamodel would be used to access and modify any model based on that metamodel.
Rules defining the life cycle, composition, and closure semantics of elements of MOF-based metamodels.
A hierarchy of reflective interfaces. These define generic operations for discovering and manipulating models based on MOF-compliant metamodels, but whose mapped interfaces are unknown.

The power of MOF is that it enables otherwise dissimilar metamodels (representing different domains) to be used in an interoperable manner. MOF-aware applications may not have any knowledge of the domain-specific interfaces of some model instance, but can still read and update that model using the generic operations of the reflective interfaces.

MOF semantics generally define metadata repository services that support model construction, discovery, traversal, and update, where models are understood to be instances of some particular metamodel. In particular, the MOF's support for model life cycle semantics means that a MOF implementation provides an effective metadata authoring and publishing tool, when combined with support for visual modeling. For example, newly developed metamodels can be persisted in the MOF repository and combined with existing metamodels according to MOF life cycle and composition semantics (inheritance, clustering, nesting, etc.). Model interfaces and default implementations can then be generated and made available to the environment. Default implementations are further enhanced with the inclusion of additional programmed logic, either written by hand or generated from tools (e.g., implementation of OCL constraints (see [46])). A fully MOF-compliant repository provides a significant number of metadata services that go well beyond the construction and serving of metadata (e.g., persistence, versioning, directory services).

Figure 2-12. The OMG four layers standard modeling stack.

Relationship between Standards

As shown in Figure 2-13, MOF builds the 'middleware' of the model standards. The MOF standard defines mappings such as MOF-to-XML (XMI), MOF-to-IDL, MOF-to-Java (JMI). UML is an instance of the MOF model. The "UML Profile for MOF" describes a two-way mapping between UML and MOF. The mapping supports both designing metamodels with UML (UML to MOF) and viewing metamodels with UML (MOF to UML) (also see [09]).

Figure 2-13. Relationship between standards.

openMDX supports the mappings indicated in the figure. An application designer or developer applies these mappings typically as follows (for more information also see ).

Step 1: The application model is defined as instance of the MOF model. Instead of using UML model elements when defining the application models, the application model is restricted to use MOF model elements. In that way MOF is used on the metamodel level [m2] for defining application models.
Step 2: The MOF-to-XML and MOF-to-Java mappings allow to map the application model to an XMI-compliant XML file and to JMI-compliant Java classes.

UML - Unified Modeling Language

The OMG Modeling documents ([45]) describe the OMG standards for modeling distributed software architectures and systems along with their CORBA Interfaces. There are two complementary specifications:

Unified Modeling Language Specification
Meta-Object Facility Specification

The Unified Modeling Language (UML) Specification defines a graphical language for visualizing, specifying, constructing, and documenting the artifacts of distributed object systems. The specification includes the formal definition of a common Object Analysis and Design (OA&D) metamodel, a graphic notation, and a CORBA IDL facility that supports model interchange between OA&D tools and metadata repositories. The UML provides the foundation for specifying and sharing distributed object models.

First and foremost, the Unified Modeling Language fuses the concepts of Booch, OMT, and OOSE. The result is a single, common, and widely usable modeling language for users of these and other methods.

Second, the Unified Modeling Language pushes the envelope of what can be done with existing methods. As an example, the UML authors targeted the modeling of concurrent, distributed systems to assure the UML adequately addresses these domains.

Third, the Unified Modeling Language focuses on a standard modeling language, not a standard process. Although the UML must be applied in the context of a process, it is our experience that different organizations and problem domains require different processes. (For example, the development process for shrink-wrapped software is an interesting one, but building shrink-wrapped software is vastly different from building hard-real-time avionics systems upon which lives depend.) Therefore, the efforts concentrated first on a common metamodel (which unifies semantics) and second on a common notation (which provides a human rendering of these semantics). The UML authors promote a development process that is use-case driven, architecture centric, and iterative and incremental.

XMI - XML Metadata Interchange

XML Metadata Interchange ([44]) is an OMG standard that maps the MOF to the W3C's eXtensible Markup Language (XML). XMI defines how XML tags are used to represent serialized MOF-compliant models in XML. MOF-based metamodels are translated to XML Document Type Definitions (DTDs) and models are translated into XML Documents that are consistent with their corresponding DTDs.

XMI solves many of the difficult problems encountered when trying to use a tag-based language to represent objects and their associations. Furthermore, the fact that XMI is based on XML means that both metadata (tags) and the instances they describe (element content) can be packaged together in the same document, enabling applications to readily understand instances via their metadata. Communication of content is both self-describing and inherently asynchronous. This is why XMI-based interchange is so important in distributed, heterogeneous environments.

JMI - Java Metadata Interface

Java Metadata Interface ([17]) provides a formal mapping of the MOF to the Java language. A JMI implementation allows for the generation of pure Java interfaces for programmatic and XMI-based access to repository-based MOF metamodels and their instances. This means that a Java implementation of any MOF-based metadata service can expose both the generic and metamodel-specific interfaces derived from the MOF's interface mapping rules. Java clients have completely portable access to metadata services via JMI.

JDO - Java Data Objects

JDO ([48] ) is optimized to manage objects in a platform-independent way (for more information see).

Figure 2-14. Overview Java Data Objects (JDO).

The main benefits of JDO are:

The JDO architecture provides a transparent interface for application component and helper class developers to store data without learning a new data access language for each type of persistent data storage.
The JDO architecture simplifies the development of scalable, secure and transactional JDO implementations for a wide range of EISes - ERP systems, database systems, mainframe-based transaction processing systems.
The JDO architecture is implementable for a wide range of heterogeneous local file systems and EISes. The intent is that there will be various implementation choices for different EIS-each choice based on possibly application-specific characteristics and mechanisms of a mapping to an underlying EIS.
The JDO architecture is suitable for a wide range of uses from embedded small footprint systems to large scale enterprise application servers. This architecture provides for exploitation of critical performance features from the underlying EIS, such as query evaluation and relationship management.
The JDO architecture makes it easy for application component developers to use the Java programming model to model the application domain and transparently retrieve and store data from various EIS systems.

MDA: Long Term Vision

The long term vision for MDA-oriented system architectures includes software capable of automatic discovery of properties of its environment and adaptation to that environment by various means, including dynamic modification of its own behavior. This is an ambitious vision that builds significantly on experiences and insights gained from implementing the near term vision. It represents a migration of the near term vision (i.e., metadata-based interoperability) to that of systems whose behavior is largely determined at run-time by AOMs. The following points summarize the main characteristics of the long term vision.

Experiences gained in the development and deployment of metadata-driven systems based on extensible object models will ultimately result in the development of systems that can directly interpret models and modify their own behavior accordingly, rather than explicitly mapping external views of shared metadata to implementation models. In the future, this mapping process will be discarded and models will be interpreted directly by software. This is the promise of the areas of dynamic objects and AOMs [10], [19], [05], [03]. In this paradigm, changing the model directly changes software behavior, resulting in complete run-time extensibility. For example, publishing a new version of a model in a repository causes all software systems in the environment to automatically adjust their own behaviors to reflect the changes. Note that a highly evolved concept of metadata is critical to this sort of architecture. Metadata (i.e., the Adaptive Object Model) is updated while the system is executing, and the resulting changes to system behavior and structure takes effect as soon as the running system is ready to expose those changes.

System functionality will gradually become more knowledge-based and capable of automatically discovering common properties of dissimilar domains, making intelligent decisions based on those discoveries, and drawing and storing resulting inferences. In general, "knowledge" is supported by an advanced and highly evolved concept of ubiquitous metadata, in which the ability to act upon, as well as revise, knowledge at run time is provided through AOMs.

Our ability to engineer such systems will come about largely as the result of our extensive experiences with the use of metamodels and ontologies in influencing system behavior and decision making. We will eventually learn how to build systems in which a considerable amount of domain knowledge is pushed up into higher abstraction levels. Systems will understand how to efficiently extract and act on that information.

Another factor contributing to the development of knowledge-based systems will be the future availability of far more effective reflective capabilities, as provided by programming language implementations, as well as repository and middeware services, and most importantly, generalized metadata management, authoring and publishing services. The current state-of-the-art of reflection generally allows for static program introspection. Future reflective capabilities will efficiently support not only introspection, but also dynamic modification of both structure and behavior [06], [10], [22].

The architectures and capabilities described above will produce a general class of highly dynamic and self-organizing systems that can act directly on domain knowledge and behave intelligently without having to be told how. Such systems can readily accommodate unforeseen changes in the environment and react appropriately without the need for programmer intervention (e.g., when dynamic and largely unstructured data resources are brought into the environment). When systems do need to be modified, this is accomplished by altering the system model. This may be performed by domain experts who are not necessarily software specialists, or perhaps by the system itself, in many cases.