Chapter 3. openMDX: An Advanced MDA Framework

Table of Contents
Platform-Independence
Plugins - Programming by Contract
Generative PSM-to-PSM mapping is not required
PSM modeling is not required

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, Rose, 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.