openMDX is an advanced implementation of the OMG Model Driven Architecture (MDA) initiative (also see [20]). openMDX is an industrial-strength, open, model-driven runtime engine and framework for platform independent models (PIMs). Unlike most commercial tools, openMDX does not implement the generative PIM-to-PSM-mapping approach. Instead, openMDX provides a generic, distributed object engine which serves as a PIM platform. Business logic (derived and behavioral model elements) are added as plug-ins.

openMDX implements the OMG MDA standards MOF, UML, XMI, JMI and inherits many concepts and patterns from other standards, e.g. from Java Data Objects (JDO). An early version of the framework was used for the implementation of a MOF-compliant CORBA Interface Repository which was presented at the OMG meeting 1999 in Philadelphia (see [38], [39]). Since then, the framework has been extended and refined in all aspects. Today, the framework is powerful enough to run real business applications. openMDX allows the development of platform-independent, distributed component-based, model-driven applications. The basic design-principles are:

100% commitment to standards defined by OMG, Sun/J2EE and W3C.
Adoption of public, well-documented, proven and accepted design patterns.
No use of features which are not absolutely necessary. Make it as lightweight and powerful as possible.
Make the framework open and pluggable wherever possible.
Support for flexible deployment-scenarios: in-process to fully distributed applications.
Provide a platform and transport abstraction to support for any type of service-oriented platforms such as EJB, CORBA, WebServices, etc.
Follow the model-driven architecture (MDA) approach: "The model is the implementation".
Support for extremely fast development and deployment roundtrips.

This document gives an overview and introduction to openMDX. It explains the main functions, concepts, building blocks and standards which openMDX is built on. For more detailed information about openMDX please refer to the following documents:

openMDX Modeling Guide [54]. openMDX is a framework which is based on the OMG MDA (Model Driven Architecture) standards, namely MOF, UML, XMI and JMI. Hence, platform-independent models are an important and basic concept when building openMDX applications. This guide gives an introduction in modeling openMDX applications.
openMDX Developer's Guide [52]. The target audience of this guide is the application developer. It explains the openMDX concepts in more detail, explains APIs and how to implement clients and application plugins.
openMDX Administrator's Guide [53]. This guide explains how to install openMDX and how to deploy and manage applications built on the openMDX application framework.

Who this book is for

This document gives an overview and introduction to openMDX. It explains the main functions, concepts, building blocks and standards which openMDX is built on.

What do you need to understand this book

openMDX is an application development and integration framework based on the OMG's MDA (Model Driven Architecture) standards. This book gives an introduction to openMDX and overview of the relevant standards. This book should be read by all who design, develop and deploy applications built with openMDX. To understand this book, you should be familiar with the most important MDA concepts. You do not need to have written openMDX applications before.

Chapter 2. MDA - Industrialization of Software Manufacturing

Introduction

openMDX is an application framework which builds an abstraction layer between the application logic and underlying platforms such as J2EE, CORBA or .NET. The abstraction layer is an implementation of the OMG's Model Driven Architecture (MDA) standards JMI, MOF and XMI. Application models are modeled as MOF-compliant models. The models are mapped to Java interfaces (applying the JMI mappings), stored in a MOF repository which allows access from application logic and the openMDX framework, and to XMI to externalize models. Beside the MDA standards, openMDX implements other standards such as an enhanced (behavioral) version of the Java Data Objects (JDO) for distributed object management. Figure 2-1 gives on overview of the openMDX architecture.

Figure 2-1. openMDX architecture overview.

The effect of openMDX in software development can be compared to the effect of computer-driven weaving looms to the textile industry. Instead of letting programmers implement designs and produce software - take a computer-driven weaving loom (openMDX) and let it do the work. Instead of writing thousands and millions of lines of software, openMDX allows to directly 'interpret' and 'execute' models.

One could argue that openMDX itself defines another platform atop of already existing platforms and therefore tries is only a new way of solving the same problem J2EE, CORBA or .NET tried to solved. This point can be answered as follows:

openMDX is layered atop of platforms such as J2EE, CORBA or .NET and offers a PIM abstraction layer to the application. This way the application logic is implemented against PIM-APIs instead of platform-specific APIs such as J2EE, CORBA or .NET. This greatly improves the portability of the application logic.
The application logic can be implemented as standard Java classes (called plug-ins) and do not contain any platform-specific interfaces such as EJBHome, EJBRemote, etc. This results in portable application-logic. Because openMDX is framework based, the plug-ins can be deployed without code generation on all supported platforms.
openMDX supports a wide range from deployment scenarios. An application composed of multiple plug-ins can be deployed as a single-process or as a fully distributed, clustered system without changing or generating a single line of code.
Out-of-the-box plug-ins such as the persistence, audit, role or state plug-ins solved everyday problems when developing applications. Reusing existing models and plug-ins allows very fast application development.
Unlike most other MDA tools, openMDX does not required to extend application models beyond the MOF standard. Models do not have to be tagged or enriched by component-specific or platform-specific attributes. This makes the modeling process much simpler compared to other MDA tools and most important makes the models truly portable and reusable.

To illustrate this, Figure 2-2 shows the openMDX application testapp deployed as a set of EJBs.

Figure 2-2. EJB deployment of openMDX-based application.

However, the same application can be deployed as a single-process application deployed in one Java VM as shown in Figure 2-3. A client and the plugins are executed in the same Java-VM (in this case under Eclipse) and the execution is stopped within the class Person of a plugin of the application testapp.

Figure 2-3. In-process deployment of openMDX-based application.

A third sample shows the same application (in this case the client) deployed run as a single-process application under .NET. The execution of the client is stopped after creating a number of persons. This is shown in Figure 2-4.

Figure 2-4. .NET deployment of openMDX-based application.

These three very different deployment scenarios would not be possible when writing the application-logic as EJB, CORBA, local or .NET application. With openMDX, as long as the client or a plugin does not use platform-specific APIs (which is of course allowed and supported by openMDX) and uses only APIs derived from the JMI mapping it is portable and freely deployable.

The next sections explain in more detail the background, architecture and features of openMDX. But before going too much into details let us look at the development of the weaving industry and compare it then to the openMDX framework.

Weaving Industry

Figure 2-5 shows the early phases of the development of the weaving industry.

Figure 2-5. Early stages of the weaving industry.

1. Stone-age spinning and weaving of textiles for personal use, around 4000 BCv.Chr.
2. Highly sophisticated textile craftsmanship performed by slaves in ancient Egypt, around 2000 BCv.Chr.
3. Monotonous manual labour in a textile works, around 1728; start of specialization among the manual laborers to increase production.
4. Homeworking and farming-out system in the 18th/19th century
5. Mechanical cotton spinning and weaving mill in Augsburg, 1840, at the start of the machine age in Bavaria.

[from http://www.deutsches-museum.de/ausstell/dauer/textil/e_text1.htm]

John Kay, the twelfth child of a Yeoman farmer, was born near Bury in Lancashire in about 1704. Little is known about his early life but he was living in Bury in 1730 when he patented a machine for twisting and cording mohair and worsted. For centuries handloom weaving had been carried out on the basis of the shuttle bearing the yarn being passed slowly and awkwardly from one hand to the other. In 1733 Kay patented his flying shuttle that dramatically increased the speed of this process. Kay placed shuttle boxes at each side of the loom connected by a long board, known as a shuttle race. By means of cords attached to a picking peg, a single weaver, using one hand, could cause the shuttle to be knocked back and forth across the loom from one shuttle box to the other. A weaver using Kay's flying shuttle could produce much wider cloth at faster speeds than before. Some woolen manufacturers used Kay's flying shuttle but were reluctant to pay him royalties. The costs of using the courts to obtain the money owed to him nearly ruined Kay. In 1753 Kay's house in Bury was ransacked by a mob of textile workers who feared that his machines would destroy their livelihood. Deeply depressed about these events, John Kay left England for France where he is believed to have died a pauper in about 1780.

Figure 2-6. The Jacquard loom was smashed to pieces and burned.

Lyon in 1806. A public execution is taking place by command of the master of the weavers' guild. The jacquard loom is smashed to pieces and burned. A new technique is threatening jobs in the cloth trade, just like the flying shuttle by John Kay (1733) had done, and the Spinning Jenny - the spinning machine by James Hargreave (1764) - or the mechanical loom by Edmond Cartwright (1785). But six years later there were already 18,000 jacquard looms in France. The jacquard loom has removed the last hurdle on the way to a complete mechanization of the cloth trade, i.e. manual pattern weaving.

[from http://www.deutsches-museum.de/ausstell/meister/e_web.htm]

[from http://www.deutsches-museum.de/ausstell/dauer/textil/e_text2.htm]

The Textile Factory

The 'Textile Revolution' - the shift from manual to industrial production in the 18th/19th century - is explained in depth in what we call the 'Textile Factory' which forms the centre-piece of the room. Historic illustrations show the first textile factory in the world (Cromford Mill, England, 1771), the first textile factory in Continental Europe (Cromford-Ratingen, 1784) and, with the help of exact replicas of the first ever textile machines, Richard Arkwright's 'Factory System'.

Figure 2-7. The Textile Factory.

1. Two significant 'basic inventions' which paved the way for the 'Textile Revolution': A weaving loom with flying shuttle, invented in 1733, and a 'Spinning Jenny', invented in 1767.
2. Small spinning frame for carded yarn, and a laboratory spinning tester.
3. Computer-controlled gripper weaving machine with electronic jacquard loom and air-jet weaving machine.
4. Computer-controlled flat knitting machine with electronic needle selector for knitting jacquard patterns.
5. View of part of the 'Textile Factory' with high-performance warp knitting machine, stocking loom, sample dyeing apparatus and fabric printing machine.

State-of-the-Art Weaving

The first major change is that we will be able to cope with the expanding design needs by using artists. The second major change is that the artist working within the framework of the quality file needs not be at the weaving site. This means that the artist could be anywhere and, in fact, could be at the customer. This would mean that the weaver could get back to doing the job they are good at, namely weaving, and let the designer/stylist do more direct work with the customers. The closer the designer is to the customer, the closer the art will be to the people. The third change that could occur is that the consumer could themselves make the design. Maybe in the future (people) will design and color their own cloths. Of course, as many people are comfortable wearing the same as other peer group people there still will be the necessity for guides within the to enable people to select and modify so that the final result is acceptable. The production will, of course, be made automatically by machines.

Software Industry

Figure 2-8 compares the software with the weaving industry. The software development process is shown in a very simplified way (compared to sophisticated processes such as the waterfall or rational unified process model). However, it shows the basic principles. In the software industry typically very few designers and modelers produce an architecture and design of the software solution to create. The design is then translated (programmed) by typically many software developers and a few tools and generators (play the role of ad-hoc weaving looms) to the software solution which is then used by the user. Errors or new requirements identified by the users are typically not fed back into the model, they are directly implemented by the software developer. The product of the software development is the so called source code (programs, scripts, resource files, etc.).

Figure 2-8. Software industry with partially automated 'weaving loom'.

Figure 2-9 compares the weaving and the software industry when using a model-driven application framework such as openMDX. With this approach the modeler and designer plays a much more important role. She or he is responsible for the creation of a detailed specification of the software solution, i.e. identification of components and their layering, workflows, etc. Instead of translating this model by 'human programmers' the model is interpreted by a model-aware 'execution' engine. This engine is able to interpret and execute the models. Together, the engine and the models are the 'software solution'.

Figure 2-9. Software industry with fully automated 'weaving loom'.

Compared to the weaving industry openMDX plays the same role as the weaving loom in the weaving industry. In fact, it has the same revolutionary impact to the software development process as the industrialized weaving looms had to the weaving industry. Software development in the sense of 'writing lines of code' is reduced step by step and is replaced by 'modeling structure and behavior' of the software solution. This

1) drastically reduces the resources in a software project,
2) makes the development of software solutions much more predictable in terms of time, risk and money and
3) improves the software quality because openMDX implements state-of-the-art design patterns and standards which are typically not applied by all software developers in an efficient and proper way.

It is obvious that with model-driven development the role and importance of models plays a very important role. Models are not just 'pictures' anymore which are used as specifications for the software development. The models are the implementation and must have therefore precision and quality as programs had before.

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.

Chapter 3. openMDX: An Advanced MDA Framework

openMDX is an industrial-strength implementation of the OMG Model Driven Architecture (MDA) standards. In contrast to most existing MDA implementations, openMDX is framework-based and does NOT implement the generative PIM-to-PSM mapping approach. openMDX brings 'pure' language objects, platform-independent models (PIMs) and platform together in an orthogonal way.

Language Objects. The application programmer designs and implements the application-logic the same way as when implementing a standard, non-distributed application. The deployment of the application is a separate task and strictly separated from the implementation. The interfaces (contracts) of the language objects are described as MOF-compliant models. Language objects are grouped to plugins which can be viewed as lightweight components.
PIMs. The interfaces of language objects (and plugins) are described as MOF-compliant, platform-independent models. The modeling process does not require any component model or platform-specific tagging or refinement. The PIM-to-PSM mapping as described in OMG Model-Driven Architecture is implemented in a generic way by the openMDX framework and deployment configuration. It is not described in the models which describe business objects only.
Platform. openMDX is a generic, distributed object platform which abstracts from platforms such as J2EE, CORBA or WebServices. This abstraction layer serves as platform for PIMs and plugins. It is very important to notice that openMDX does not replace existing platforms. It simply puts an abstraction layer on top of these platforms. One could think that the interfaces and implementation of a platform-independent, distributed object platform is complex. However, combining the best-of-breed concepts of the JMI and JDO standards allowed to specify the platform with a handful of interfaces: Object_1_0, ObjectFactory_1_0, Container (a slightly extended Collection), UnitOfWork_1_0 and FilterProperty.

These principles are also shown in Figure 3-1.

Figure 3-1. Separating development from runtime environment.

The advantages of this approach are:

The application-logic is independent of the component or service model, the distribution technology and configuration. An application composed of dozens of plugins can be deployed as 'local' application running in one VM or in a distributed environment managed by a clustered application server without having to change a single line of code.
The application programmer does not have to learn complex platform technologies such as J2EE or CORBA.
All models are 100% MOF-compliant and platform-independent, i.e. models do not have to be tagged or refined for a specific component model are platform.
The framework approach allows to change component model and platform without having to re-generate the application. This is very different from the generative PSM-to-PSM mapping approach where a change of platform or component model requires a development step involving re-generation, testing and packaging the application.
openMDX implements all design patterns recommended by [34].

For information also see [52].

Through its open and transport-independent component architecture openMDX allows to integrate and extend existing and new applications in a very efficient and straight-forward way. The key benefits of openMDX are:

Open, extremely flexible framework for the integration existing and new applications.
Supports component-oriented, multi-tier application architectures.
Open for multi-party software development process.
Support of the MDA standards ([20]).
Offers a wide-range of patterns, prefabricated add-on's and plugins.
Offers a wide range of deployment scenarios.

What openMDX is:

. an open application development and integration framework providing a highly-customizable plugin-architecture.
. a generic, model-driven runtime platform for distributed, component- and service-oriented applications. The kernel contains a MOF-compliant model repository which allows to store platform-independent application models.
. a library of pre-fabricated plugins which accelerate and simplify application-development. Standard plugins are provided for runtime type-checking, persistency management, state management, role management, etc.

What openMDX is not:

... an IDE (= Integrated Development Environment). openMDX is a framework which allows the development of new applications and integration of existing applications. Any kind of development tool (e.g. Eclipse, JBuilder, Rational Rose, MagicDraw, Poseidon, Together) can be used for development of openMDX applications.
... an Application-Server. openMDX is layered on top of an application server. It uses all features offered by an application server: transport, transaction handling, security, load-balancing, failover, etc.

openMDX offers in addition to an Application-Server:

openMDX abstracts from the underlying middleware and transport such as CORBA, EJB or WebServices and offers the developer a simple, open and standards based framework for the development of platform-independent application-logic.
openMDX allows to specify and integrate components according to the MDA standards such as UML, MOF, XMI, JMI. This allows to model and implement components on a standardized, high abstraction level.
openMDX offers stable and proven infastructure services (e.g. logging, tracing, security, deployment).
openMDX offers a wide-range of patterns and prefabricated application-level components (e.g. persistency management, support for role and state patterns, etc.)

openMDX compared to other MDA tools:

openMDX uses generators only for PIM-to-PIM mappings which reduces the number of code-generators drastically compared to the generative PIM-to-PSM approach.
The limited use of code-generators speeds-up the development process roundtrip and makes debugging of applications fast and transparent. Systematic regression-testing is possible because no code is generated during the build-process. Applications are robust can be delivered in high quality.
openMDX does not require a specific development process . However, because openMDX is a model-driven development and runtime-platform, openMDX requires the precise specification of all components prior to their implementation or execution. This puts certain, minimal requirements on the software development process.

Platform-Independence

The most programming languages require that client and supplier run on the same platform within the same process. Distribution of applications is not an inherent feature of most programming environments. They are provided by additional distribution technologies such as DCE-RPC, CORBA, EJB or WebServices. They allow to run clients and suppliers in different processes and network nodes. This allows to offer the features of suppliers in a much more flexible way and to many more clients than is possible in a non-distributed environment. Moreover it is not important on which operating system a supplier is running and in which programming language it is implemented. Existing systems can be integrated with new systems.

Distributed applications require additional infrastructure, called middleware or application servers. Figure 3-2 shows how a CORBA or EJB application is typically developed. In case of CORBA, the programmer defines the interface of the CORBA service by means of an IDL, then generates the stubs and skeletons using an IDL compiler and then implements the client and supplier logic. The approach for the development of EJB-based application is very similar. The component interface is specified with Java interfaces following the EJB-standard (e.g. implements SessionBean interface). An RMI/EJB compiler generates the required stubs and the programmer implements the client and supplier logic. The 'distribution units' are CORBA services, CORBA components, EJBs, .NET components, WebServices in case of CORBA, EJB, .NET or WebServices platforms, respectively.

Figure 3-2. Binding- and platform-specific application-logic.

However, the application-logic must in case of CORBA follow the CORBA language-binding standard and in case of EJB the EJB language binding standard. If no additional abstraction layer is implemented this results in non-portable application-logic, e.g. it is not possible to port CORBA-based applications to EJB platforms without having to rewrite the application-code.

The benefit of using CORBA or EJB is to have an infrastructure which allow to build distributed applications. However, the disadvantage of using these 'distribution' technologies results in non-portable application-logic. Applications are platform-dependent in at least the following areas:

Interface language. CORBA requires to specify IDLs, EJB Java interfaces and WebServices WSDLs.
Language binding. A CORBA application must follow the CORBA language-binding, an EJB application the EJB language-binding conventions, etc. This results in non-portable application-logic from one language-binding convention to another.
Component model. The semantics of a supplier is platform-specific and requires different designs depending on whether the CORBA, EJB, .NET or WebService technology is used. Even if a binding-abstraction was implemented by the programmer a component might not easily portable from one component model to another.

This is shown in Figure 3-3.

Figure 3-3. CORBA- and EJB-specific parts of an application.

openMDX allows to implement interface language, language binding and component model independent application logic. Figure 3-4 shows how this is achieved.

Figure 3-4. Levels of platform-independence.

Language and Standard Library Platform. This platform defines the programming language and a standard class library. As with Java/JDK or .NET these platforms allow to implement algorithms and application-logic in an operating-system and distribution-technology independent way. openMDX does not make any attempt to abstract from the Language and Standard Library platform, i.e. plugins can use any feature offered by these platforms. Abstracting from these platforms would result in defining a new platform. Platforms such as Java/JDK or .NET are itself very high-level platforms and represent the state-of-the art in platform abstraction. Approaches such as xUML and other 'higher-level' environments do not solve in a better way the 'platform-independence-problems' than Java/JDK and .NET already do.
Component and Service Platform. These platforms are typically defined as extensions to the Language and Standard Library platform. They extend these platforms by distribution and component model features, e.g. J2EE and CORBA allow to build component-based, distributed applications. Platforms such as J2EE or CORBA are typically implemented on top of the Language and Standard Library platform.
PIM platform. The PIM platform abstracts from the Component and Service platform and therefore from the component and distribution model. The standards MOF, JMI, XMI and JDO allow this kind of abstraction and are implemented and provided by openMDX. The PIM platform combines the Language and Library Platform and the Component and Service Platform in an orthogonal way.
Plugins. Plugins implement the application-logic and are based on the Language and Standard Library platform. Platform-independent plugins (PIPs) are plugins which are based on the PIM platform and the Language platform only. Because PIPs do not use any technology-platform-specific APIs they can be deployed into any PIM-platform supported technology platform. Platform-specific (PSPs) or wrapper plugins use Component and Service platform specific APIs.

Plugins - Programming by Contract

Plugins are standard language objects, classes and modules implementing MOF-compliant interfaces. That is, the contract is specified by MOF-compliant models which is implemented by plugins. Platform-independent plugins (PIPs) are based on the programming language and library and PIM platform only. They do not contain any component and service platform specific code. This has the following advantage:

The programmer does not have to learn J2EE, CORBA, etc.
The application-logic is implemented as native language classes and modules. The same code can be reused independent of the underlying component and service platform.
The deployment is a pure configuration task. No code generation require. This allows fast and reproducible roundtrips and testing.

Figure 3-5 shows how the simple client-supplier model can be used to construct complex software systems. A supplier (plugin) can in turn call zero or more other plugins. Plugins calling other suppliers are also called delegating plugins. The optimal decomposition of a complex software system into plugins and their definition is one of the most important tasks of designing openMDX applications and software engineering in general.

Figure 3-5. Programming by contract. A client calls a supplier.

Figure 3-6 shows a sample application composed of platform-independent and platform-specific plugins responsible for product, contract, cost, etc. management. Wrapper plugins wrap the functionality of existing systems and access resources such as databases. The plugins are deployed on the openMDX PIM platform which in turn is deployed on a component and service platform such as an J2EE application server or CORBA environment.

Figure 3-6. From simple plugins to complex applications.

Generative PSM-to-PSM mapping is not required

As explained in the previous section, plugins are specified with platform-independent models (PIMs). The PIM-to-PSM mappings specified by the OMG (also see OMG Model-Driven Architecture) are implemented in a generic way by the openMDX framework and the deployment configuration and do not have to be modeled explicitly. Figure 3-7 shows the generative MDA development process:

In the modeling phase the PIM is created.
Still in the modeling phase the PSM is created. This is mostly done by tagging and enhancing the PIM with platform-specific information. E.g. in order to define EJB components, PIM entities are mapped to EJBs, home interfaces, object interfaces, methods, etc.
In the development phase, the PSM serves as input for generator tools which take the PSM as input and generate platform-specific source code. This generated source code is enhanced by manually written business logic. The generated and manually written code are combined and packaged to a platform-specific component, e.g. an EJB.
The component is deployed to the target platform. The orginal PIM is not part of the runtime.

Figure 3-7. Generative MDA development process.

As elegant as the generative approach might be, there are several serious drawbacks:

If the code-generation is not restricted to forward engineering, the way is paved for the so-called round-trip problem: regenerating the code overwrites modifications to the previous generation. This is primarily a maintenance issue. It won't hit you right away, and when it does, it causes difficulty only when generated and handcrafted code aren't well decoupled. Trouble is, that's more the rule than the exception. Rountrips should be fast until a model-change becomes executable. A single round-trip between modeling environment and the runtime environment can take several minutes if not hours. For non-trivial systems, the delay between model change and model execution make rapid exploration of new models impossible, because the time delay between model change and execution is too long. Users, who may have to wait for hours until a model change becomes executable, tend not to explore a wide range of model options but go the easiest possible path, not exploring possibly better alternatives.
When the application code has to be regenerated because of a change request, different roles have to become active: the application modeler, the application developer and the application deployer. If the PIM and PSM information are not 100% separated or it is not clear what has to be changed in the model to get the desired output from the generator tool, typically the application modeler first has to change the model. The application developer takes the new model, regenerates the application and migrates the manually written code. After building the application the deployer redeploys it. This scenario shows that the application modeler, developer and deployer have to work together very closely within one change request roundtrip. It is obvious that this process does not scale to large projects where different design and development teams are involved.

Figure 3-8 shows the development process when using openMDX:

Figure 3-8. openMDX MDA development process.

The PIM is created in the modeling phase.
In the development phase the MOF mappings - namely JMI and XMI - are applied to the PIM. This mapping does not require a PIM or any other platform-specific information. The JMI interfaces and implementations are plain Java objects without references to any platform-specific classes or interfaces. Therefore with openMDX, creating a PSM is NOT required. Application-logic, i.e. clients and services, are using and implementing the JMI interfaces, respectively. It is important to note that this way the application-logic is still platform-independent.
The deployment phase combines the generated MOF mappings, application logic, openMDX runtime and deployment configuration to a platform-specific component, e.g. EJB. This step defines which platform-component provides and implements which 'PIM' instances, i.e. application objects. E.g. having a model for partners, addresses and contracts and corresponding implementations, the deployer can either decide to package all models into one EJB or each model into a separate EJB. IMPORTANT: openMDX does not claim that deployment information is not required to run a PIM. In contrast, together with the platform-specific transports of openMDX, the deployment information is a very essential part of a deployed component. However, openMDX requires to add deployment information only at the deployment phase and not already in the modeling or development phase.

This very late platform binding has many benefits:

The platform-independent models do not have to be extended, profiled and tagged with platform-specific elements. Although the OMG defines model profiles for different platforms there are many vendor-specific extensions which make the models non-portable.
Platform-specific modeling makes modeling unnecessary complex and error-prone. PIM-only modeling is straight-forward and the modeler does not have to think of any platform or component technology.
Application-logic is platform-independent, i.e. it uses and implements plain Java interfaces (JMI) which do not extend or reference any platform-specific classes and interfaces. This way the code remains portable and in most cases very simple, because no platform-specific programming is required.
Pre-fabricated PIMs and plugins speed-up application development and increase software quality by orders of magnitude.
No code-generator and therefore no maintenance.
Easy, well-known development roundtrip (implementation of plugin classes).
Easy source-code management (PIMs and plugins).

PSM modeling is not required

Tagging and marking the models can be compared to C++ source code which is 'marked' with platform-specific #defines which allows to implement portable code. In the last decade Java and .NET technologies have proven that target-platform specific tagging of source code is not required. However, today's MDA tools do the same on the modeling level: they extend the platform-independent UML/MOF model by platform-specific profiles which allow to generate for a desired target platform.

Figure 3-9. Implementing MDA with the generative approach.

enlarge

Does MDA moves us from the problem of non-interoperable programming languages and middleware to the problem of non-reusable, non-portable models and application logic? The answer is NO. MDA defines everything to define and implement platform-independent, portable models and specifications. In fact, experience shows that platform-specific modeling is not required at all and that code-generation can be reduced to the platform-independent MOF mappings.

Chapter 4. Conclusion

This paper has introduced the most important concepts of the open model driven architecture and development platform openMDX.

Bibliography

[01] R. Dirckze and S. Iyengar, A Metamodel based approach to Model Engineering using the MOF.

[02] J. Bezivin, From Object Composition to Model Transformation with the MDA, TOOLS USA, Volume IEEE TOOLS-39, Santa Barbara, August 2001.

[03] D. Poole, Model-Driven Architecture: Vision, Standards And Emerging Technologies, ECOOP, 2001.

[04] J. Vlissides and A. Alexandrescu, To Code or Not to Code, Part I, C++ Report, March 2000.

[05] ECOOP '2000 Workshop on Metadata and Active Object-Models, Cannes, France, Lecture Notes in Computer Science 1852, Springer-Verlag, Heidelberg, June 2000.

@ http://www.adaptiveobjectmodel.com/ECOOP2000

[06] S. Chiba, Load-Time Structural Reflection in Java, Proceedings of ECOOP 2000, pp.311-336, Lecture Notes in Computer Science 1850, Springer-Verlag, 2000.

[07] The Common Warehouse Metamodel, Object Management Group.

@ http://www.omg.org/cgi-bin/doc?formal/01-10-01

[08] D. D'Souza, Model-Driven Architecture and Integration: Opportunities and Challenges", Version 1.1.

@ http://www.catalysis.org/publications/papers/2001-mda-reqs-desmond-6.pdf

[09] UML Profile for EDOC RFP Home Page, Object Management Group.

@ http://cgi.omg.org/techprocess/meetings/schedule/UML_Profile_for_EDOC_RFP.html

[10] The Meta-Object Protocol and Knowledge-Based Systems, Franz, Inc., December, 1997.

@ http://www.franz.com/support/tutorials/mopnkbs.php3

[11] J2EE Connector Architecture, JSR-16 Home Page, Sun.

@ http://java.sun.com/aboutJava/communityprocess/jsr/jsr_016_connect.html

[12] Java 2 Platform, Enterprise Edition Home Page, Sun.

@ http://java.sun.com/j2ee/

[13] Java Technology Home Page, Sun.

@ http://java.sun.com/

[14] JDBC Data Access API Home Page, Sun.

@ http://java.sun.com/products/jdbc/index.html

[15] The Java Comunity Process, Java Community Process.

@ http://java.sun.com/aboutJava/communityprocess/

[16] Java Data Mining API, JSR-73 Home Page, Java Community Process.

@ http://java.sun.com/aboutJava/communityprocess/jsr/jsr_073_jolap.html

[17] Java Metadata Interface, JSR-40 Home Page, Java Community Process.

@ http://www.jcp.org/aboutJava/communityprocess/review/jsr040/

[18] Java OLAP Interface, JSR-69 Home Page, Java Community Process.

@ http://java.sun.com/aboutJava/communityprocess/jsr/jsr_069_jolap.html

[19] G. Kiczales, J. des Rivieres, and D.G. Bobrow, The Art of the Meta-object Protocol, MIT Press.

[20] Model-Driven Architecture Home Page, Object Management Group.

@ http://www.omg.org/mda/index.htm

[21] Model-Driven Architecture: A Technical Perspective, OMG Architecture Board MDA Drafting Team, 2001.

@ ftp://ftp.omg.org/pub/docs/ab/01-02-01.pdf

[22] Meta-Object Facility (MOF), version 1.4, Object Management Group, September, 1999.

@ http://www.omg.org/technology/documents/formal/mof.htm

[23] J. Poole, The Common Warehouse Metamodel as a Foundation for Active Object Models in the Data Warehousing Environment, ECOOP '2000 Workshop on Metadata and Active Object-Models, Cannes, France. Lecture Notes in Computer Science 1852, Springer-Verlag, Heidelberg, June, 2000.

@ http://www.cwmforum.org/CwmAOM.pdf

@ http://www.adaptiveobjectmodel.com/ECOOP2000/

[24] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1995.

[25] D. Tolbert, CWM: A Model-Based Architecture for Data Warehouse Interchange, Workshop on Evaluating Software Architectural Solutions 2000, University of California at Irvine, May 2000.

@ http://www.cwmforum.org/uciwesas2000.htm

[26] Java UML/EJB Mapping Specification, JSR-26 Home Page, Sun.

@ http://java.sun.com/aboutJava/communityprocess/jsr/jsr_026_uml.html

[27] XML Metadata Interchange Specification, Version 1.1, SObject Management Group.

@ http://www.omg.org/

[28] N. Guarino and C. Welty, Towards a Methodology for Ontology-based Model Engineering.

[29] J. Bezivin and J. Ernst, First International Workshop on Model engineering, Nice, France, June 13, 2000.

@ http://www.metamodel.com

[30] G. Kiczales, Aspect-Oriented Programming in Aksit, M. and Matsuoka, S. (eds.), 11th European Conference on Object-Oriented Programming, LNCS #1241, pages 220-242, Springer Verlag, 1997.

[31] C. Kobryn, The Road to UML 2.0: Fast track or Detour, SD Magazine, April 2001.

[32] R. Lemesle, Transformation Rules Based on Meta-Modeling EDOC,'98, La Jolla, California, 3-5, pp. 113-122, November 1998.

[33] R. Soley, Model-Driven Architecture. OMG draft document, OMG staff Model-Driven Architecture, November 2000.

@ http://www.omg.org

[34] J2EE Patterns, Sun Java Center, January 14, 2002.

@ http://developer.java.sun.com/developer/restricted/patterns/TieredApproach.html

[35] Designing Entity Beans for Improved Performance, Java Developer Connection, January 14, 2002.

@ http://developer.java.sun.com/developer/technicalArticles/ebeans/ejbperformance/

[36] M. Rasch, Questions to Ask your Component Suppliers, SIGS Component Strategies, August 1999.

[37] C. Braun, A Lifecycle Process for the Effective Reuse of Commercial Off-the-Shelf (COTS) Software, SSR, Los Angeles, CA, 1999.

[38] H. Hoidn, UBS Philadelphia Plenary Presentation, OMG, March 1999.

@ ftp://ftp.omg.org/pub/docs/omg/99-03-02.pdf

[39] D. Frankel, Components - MOF Sunday presentation, OMG, March 1999.

@ ftp://ftp.omg.org/pub/docs/orbos/99-03-26.pdf

[40] Designing Entity Beans for Improved Performance, Java Developer Connection.

@ http://developer.java.sun.com/developer/technicalArticles/ebeans/ejbperformance/

[42] Dirk Riehle, Steven Fraleigh, Dirk Bucka-Lassen, and Nosa Omorogbe, The Architecture of a UML Virtual Machine, OOPSLA '01, Tampa, Florida, October, 2001.

[43] Bumer, Riehle, Siberski, and Wulf, The Role Object Pattern, OOPSLA '01, Tampa, Florida, October, 2001.

@ http://st-www.cs.uiuc.edu/users/hanmer/PLoP-97/Proceedings/riehle.pdf

[44] XML Metadata Interchange (XMI), version 1.2, Object Management Group.

@ http://www.omg.org/technology/documents/formal/xmi.htm

[45] Unified Modeling Language (UML), version 1.4, Object Management Group.

@ http://www.omg.org/technology/documents/formal/uml.htm

[46] Object Constraint Language, joint initial submission, version 2.0, Object Management Group.

@ http://cgi.omg.org/cgi-bin/doc?ad/01-08-09.pdf

[47] Java Message Service API, Sun.

@ http://java.sun.com/products/jms/

[48] Java Data Objects, version 1.0, Sun.

@ http://access1.sun.com/jdo/