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).