Processes as Input: Generating Web Portals

At the Hasso Plattner Institute for Software Systems Engineering (HPI) in Potsdam (Germany) the "Bachelorpodium 2006" event took place on 12th April. One highlight from the project results that were presented is the "Magrathea" software generator. This generator produces the executable implementation of an Internet portal directly from process model data. This project is part of the research project PESOA (Process Family Engineering in Service-Oriented Applications). Delta Software Technology (Delta) provides the core technology for the Magrathea project: HyperSenses. The Magrathea generator realizes a system family concept as defined by Generative Programming. Please read on for a more detailed look at this project.

Seven students from the HPI participated in the Magrathea project, supported by staff members from the PESOA project partner ehotel AG, from the HPI and also from Delta. Three of the students attended a HyperSenses training course at Delta’s headquarters in Schmallenberg (Germany). Substantial parts of the generator were implemented there.

The application domain of the Magrathea generator is Web portals that implement business processes. ehotel provides the real-world use case for the project. ehotel offers on its Web site business services as Web services, e.g. a hotel search. It is usual that Web services correspond with business processes and vice versa. Both are frequently adapted, which can quickly lead to their maintenance becoming expensive. This scenario is therefore an area ideally suited to the use of generators.

"Computer programs for complex business applications often have to be expensively adapted for individual customer needs. Many similar products are therefore developed, only differing from each other in minor details. Such a product suite is by definition hard to maintain, for example making enhancements."
(HPI student Olaf Märker)

Using software generators to hold down maintenance costs is nothing new. Things become more exciting If there are different levels of abstraction to be performed. This is definitely true concerning business processes that are implemented as portals: the processes are modeled using the BPMN (Business Process Modeling Notation). The BPMN notation exactly targets the description of the contents of the business processes themselves. In contrast, BPMN is not applicable for the description of implementations. In fact, it is impossible to perform any kind of "code-related" modeling with BPMN, contrary to certain UML diagrams, for example.

A Web portal is an implementation with a large technical complexity, a “playground” for different architecture layers, different programming languages and technologies. How did the Magrathea team succeed in developing a generator that is dedicated not only to a distinct use case (e.g. the hotel search), but can produce any Web portal from the corresponding BPMN models?

First the project team decided to use Ruby on Rails as the technical platform. Ruby on Rails provides a framework that significantly simplifies the development of Web services. This framework allowed the abstraction level of the generator's target platform to be raised significantly: the Ruby code for the complete controller layer, as well as for parts of the model and view components (Ruby on Rails propagates an architecture according to the Model-View-Controller pattern), were completely generated.

This was, however, not sufficient as the BPMN process elements did not represent Ruby constructs. The solution: decompose the implementation into building blocks each of which, taken on its own, are only subject to small technical changes. The Magrathea generator team implemented the building blocks containing dependencies concerning a (varying) process model as HyperSenses patterns. Building blocks without such dependencies were manually programmed and made available as generic components.

On the one hand the BPMN process models have been defined, while on the other hand the building blocks of the implementation containing dependencies on the process models have been created. A mapping had to be defined between them to relate the process model elements to these building blocks. It was therefore necessary to consider the business processes to be handled as being a family of processes; this means to define their potential commonalities and variation points. Based on this, conventions have been defined to allow for the next step: coupling individual BPMN elements with appropriate implementation building blocks for the domain "Generation of Web Portals". The linchpin for these couplings was the metamodel of the HyperSenses technology.

The result: A very powerful generator that accepts the process model data in the OMG XMI format and produces the appropriate Ruby code. Thanks to the interpreter-based nature of Ruby this can happen even during execution of the Web service.

The use of HyperSenses for this project gave Delta with important insights on the further development of this technology. Magrathea is not a generator only dedicated to one concrete application area (domain = hotel search), but one applicable to an enlarged application field, i.e. an enhanced domain (= Web portals for business processes). Because the generator should be able to process any BPMN data, an accordingly comprehensive metamodel needed to be defined in HyperSenses. However, this effort only needs to be invested once. Because the process models already served as configuration data for code generation, the creation of configuration patterns (as it is otherwise usual with HyperSenses), could be omitted. The main implementation work consisted of the definition of production patterns. For their creation a prototype was indispensable – which was manually created. This also was a large, but again, a one-off effort. The application of the generator, on the other hand, only required very small efforts: the project environment consisted of the process modeling tool (a proprietary development of HPI), HyperSenses, as well as Ruby on Rails, all of which were implemented as a production line on which the application of the generator could be automated.

In PESOA the development work for the process family as a whole is separate from the work required to create an instance, i.e. an application: we use the terms "domain engineering" and "application engineering" for these separate activities. Taking into account the respective efforts, the Magrathea project complies with PESOA's assessment criteria: the domain-related efforts may be large by all means – but they have to be economic taking into account all of the applications that are produced. The development of a single application, by contrast, has to be profitable on its own, i.e. these efforts have to be very small. The latter is definitely true for Magrathea. Even if in this case the domain engineering was relatively expensive – it was worthwhile!

The development of a powerful tool with several project members distributed across various locations underlines HPI's and Delta's claim to interconnect as closely as possible the research world and the real world.

Several reports about the Magrathea generator and the "Bachelorpodium" event at the HPI are available. You are invited to read on at:

Magrathea page at the HPI
Innovations-report (report in German only)
Science Year 2006 (report in German only)
Germany, Land of Ideas (report in German only)