Chapter 2. MDA - Industrialization of Software Manufacturing

Table of Contents
Introduction
OMG Model-Driven Architecture

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.