Introduction

In the past decade various modeling approaches have emerged in the research field of web engineering including WebML [7], UWE [13], W2000 [1], OOHDM [26], OO-H [10], WSDM [8], and OOWS [25]. Each of those model-based approaches follows the similar goal of counteracting a technology-driven and ad hoc development of web applications. Beyond this, we notice similar and simultaneous extensions to the individual web modeling approaches, e.g., for supporting context-aware web applications [2,6,9], business process modeling [4,14], and for exploiting all benefits of model-driven web engineering (MDWE) [15,18]. The current situation somewhat resembles the object-oriented modeling "method war" of the 90ies. A situation from which after a unification process the UML [24] eventually has become the lingua franca in software engineering. In the light of the current "method war" in the research field of web engineering (cf. Figure 1) the question arises if a unification of the existing web modeling approaches can be successfully applied as it was achieved for the UML. In the MDWEnet initiative [16], which has recently started by a small group of researchers working on MDWE, this and further questions are tackled. More specifically, the initiative's goal is to improve interoperability between current web modeling approaches as well as their tools for the model-driven development of web applications.

As a prerequisite for unification a common agreement on the most important web modeling concepts is essential. This agreement can only be gained when investigating the concepts used in existing web modeling languages and fully understanding the languages' commonalities and differences. In the MDWEnet initiative, we therefore defer the task of designing a "Unified Web Modeling Language". Instead, we first aim at integrating three prominent representatives of the web modeling field, namely WebML, UWE, and OO-H, since they are well elaborated and documented as well as supported by modeling tools. This integration is based on specifying and implementing transformation rules allowing the transformation of WebML, UWE, and OO-H models into any other of the three languages, respectively. This way a detailed understanding of the common concepts used in web modeling can be obtained as well as their different realizations in the three selected languages. On the basis of this integration task the definition of a common metamodel for web modeling can be achieved in the future.

Consequently, the major contribution of this work is a step towards identifying the common concepts in web modeling by first defining transformations between different modeling languages. We present the general integration approach as well as first results on the integration of WebML and OO-H.

Besides representing an important step towards unification, the transformation rules also enable model exchange between the three different languages. For defining the transformation rules, the languages' definitions had to be made explicit in terms of metamodels, which in turn represent a prerequisite for enabling model-driven web engineering for each individual approach. On the basis of tool adapters the models' representation within the approaches' tools could be translated into instances of these metamodels and vice versa thus also insuring interoperability. Furthermore, it will be possible to exploit the different strengths of each web modeling approach, e.g., code generation facilities for different platforms such as J2EE in WebML's WebRatio1 tool and PHP in OO-H's tool VisualWade 2 .

In the remainder of the paper, we discuss our methodology for integrating existing web modeling languages in Section 2. We elaborate on preliminary results of the integration task with respect to WebML and OO-H in Section 3 and provide our lessons learned in Section 4. Finally the paper is concluded with a discussion on future challenges in integrating as well as unifying web modeling languages.

Integration Methodology used in MDWEnet

In this section we discuss the general methodology used for the integration of WebML, OO-H, and UWE. We first explain why integration on the basis of already existing language artifacts is not possible. Second, we outline a model-based integration framework, and third, we discuss how to obtain the most important prerequisite for integration -the metamodels for the three web modeling languages.

Why is the integration on the basis of existing language artifacts not possible?

In Table 1 we present an overview of the formalisms used for defining WebML, OO-H, and UWE as well as the approaches' model storage formats. When looking at the languages' definitions, one can easily identify that each language is specified in a different formalism, even in different technological spaces [17], which a-priori prevents the comparability of the languages as well as model exchange.

For the integration of modeling languages in general and for web modeling languages in particular, the first requirement is that the languages are defined with the same meta-language. This enables to overcome syntactical heterogeneities and to compare the language concepts in the same formalism. Furthermore, defining languages with the same formalism also allows expressing their model instances in the same formalism which further fosters comparability of the languages' concepts and beyond allows the uniform processing of the models, e.g., their visualization or transformation. Consequently, it seems necessary to split up the integration process in order to tackle two distinct integration concerns, namely syntactical integration and semantical integration: In the first step, i.e. the syntactic integration, the different formats used by WebML, UWE and OO-H are aligned towards one common integration format. For example, a WebML model represented in terms of an XML document has to be translated into this common integration format. The second step, i.e. the semantical integration step, covers the transformation of a model from one language into another one, e.g. from WebML to OO-H, while preserving the semantics of the input model within the output model. This transformation is based on transformation rules which require the input models to be available in the common integration format.

How to use model-based techniques for integration purposes?

We decided to apply a model-based approach and use techniques and technologies which have emerged with the rise of Model Driven Engineering (MDE) [3]. MDE mainly propagates two techniques which are relevant for integration purposes: (1) metamodels for defining the concepts of modeling languages, and (2) model transformations. Model transformations in the context of MDE can be divided into vertical model transformations and horizontal model transformations [19]. While the first kind concerns transformations between different abstraction levels, e.g., continuously introducing more details that finally are necessary for code generation purposes, e.g., for model refactoring. Consequently, in this work we rely on horizontal model transformations.

In Figure 2, we present our model-based integration framework, which is based on the tool integration pattern of Karsai et al. [12]. The framework is built upon opensource technologies for MDE, which have been developed under the hood of the Eclipse project. In particular, we are using the Eclipse Modeling Framework (EMF) [5], as a model repository for a common syntactic integration format and EMF's Ecore, i.e. an implementation of the Meta Object Facility (MOF) standard [21], as the meta-language for defining the metamodels for WebML, OO-H, and UWE. Furthermore, we employ ATL [11] as model transformation language to implement the transformation rules and finally, the ATL engine for actually executing the transformation. In Figure 2, we also sketch the model-based integration process of WebML (WebRatio), OO-H (VisualWade), and UWE (ArgoUWE), which is described more detailed in the following:

1) Syntactic Integration. On the basis of tool adapters for bridging the native model storage formats of the approaches' tools towards the EMF models can be integrated syntactically. Thus, realizing import functionality the tool adapters have to parse the models in their native format and generate an XMI [22] version for the EMF. In addition, the tool adapters also must be capable of exporting the models by transforming them into the tools' native format. 2) Semantic Integration. After the syntactic integration, the user can focus on the correspondences between modeling concepts of different languages. This is done by relating the metamodel elements and implementing the integration knowledge in terms of ATL model transformation rules. illustrates the goal of MDWEnet, i.e., a unification of existing web modeling languages in terms of a common metamodel for web modeling. By defining the metamodels for WebML, OO-H, and UWE, as well as working out the integration knowledge in a first step, we hope that the creation of such a common metamodel is easier to achieve afterwards. For the future, the common metamodel for web modeling can serve as a pivot model and thus lowering the integration effort drastically. Subsequently, the generated models can be exported via the specific tool adapter to the proprietary tool.

What's missing for a model-based integration and how to close the gap?

As a key-prerequisite for a model-based integration, the metamodels for WebML, OO-H, and UWE must be available, which currently, however, is not the case. Within the MDWEnet initiative, we have decided to use a top-down approach for building the individual metamodels by starting with a focused set of requirements which are specific to the web modeling domain [30]. This approach has the advantage that we can concentrate on the core modeling constructs of the web modeling domain supported by the addressed approaches instead of focusing on a huge amount of concepts available in the individual approaches and implemented in their tools. Following this top-down approach, a set of modeling requirements for the core of web modeling were defined each focusing on a specific modeling problem. In the following, these requirements are briefly explained and categorized into requirements for content modeling, hypertext modeling, and content management modeling.

Layer 0 -Content Modeling. This layer is required to express domain objects and their properties on which the web application is built upon. Example: Class Student with attribute name, age, and a relationship to the class Professor.

Layer 1 -Hypertext Modeling. This layer covers the requirements for web applications that allow navigation among the hypertext nodes and publish within a node the content extracted from domain objects (cf. Layer 0), possibly based on input provided by the user. The following four cases are subsumed by Layer 1:

• Global Navigation: This case requires a starting point in the web application, i.e. a home page, and subsequently, a navigation mechanism for moving to another page of the hypertext. The definition of metamodels is of course an art on its on and can be approached in different ways. For the purpose of this work it was decided to employ an example-based approach by a process of obtaining a metamodel from the aforementioned requirements as follows [16]: One or more concrete modeling examples were derived from the requirements specification and modeled in the respective modeling language within each approach's accompanying tool. The code generation facilities of each tool were then used to find out if the examples modeled were semantically identical, i.e., the generated applications should work in the same way. From these models the language concepts which have been used were identified, as well as how these concepts were related to each other. Consequently, this information is then defined in a corresponding metamodel. These metamodels should allow expressing the same models as within the approaches' tools, meaning the same information must be expressible in the models.

Preliminary Results

In this section we present our preliminary results. First, we briefly discuss the modeling examples realizing the MDWEnet's modeling requirements for web modeling and provide the resulting metamodels in Section 3.1. In order to illustrate how, on basis of those metamodels, the integration is realized with ATL in Section 3.2 we then present excerpts of the set of ATL transformation rules that have been defined for the metamodels.

Derived Metamodels

Our first task after the MDWEnet's modeling requirements for web modeling have been agreed on has been the derivation of concrete modeling examples realizing these requirements specifications. Inspired by previous examples in the web modeling domain, we are using excerpts of the often referred to album store running example [6], which covers all the aforementioned requirements. After defining the modeling examples, each of them was modeled within the approaches' tools, i.e., WebRatio, VisualWade, and ArgoUWE, respectively. Furthermore, we used the code generation facilities to compare the behavior of the models by executing the generated web applications.

On the basis of the modeling examples, each expressed in WebML, OO-H, and UWE, we identified the language concepts used in the individual examples and obtained first versions of the metamodels for WebML as well as for OO-H. The metamodel for UWE is currently under preparation. Beyond, we have grouped the metamodels' elements into packages which directly correspond to the layers of the modeling requirements presented in Section 2. In the following, the class structures of the metamodels for WebML and OO-H are presented and briefly explained. For more detailed versions of the metamodels the reader is referred to [30].

WebML Metamodel. In Figure 3, we present the resulting WebML metamodel, i.e., its packages, classes and their interrelationships. While the Structure package and ContentManagement package correspond to the Layer 0 and Layer 2 of the modeling requirements, respectively, for Layer 1 two packages have been defined, namely Hypertext and HypertextOrganization.

The Content package contains modeling concepts that allow modeling the content layer of a web application. Since WebML's content model is based on the ER-model, it supports ER modeling concepts: An Entity represents a description of common features, i.e., Attributes, of a set of objects. Entities that are associated with each other are connected by Relationships. Unlike UML class diagrams, ER diagrams model structural features, only.

The ContentManagement package contains modeling concepts that allow the modification of data from the content layer. The specific ContentManagementUnits are able to create, modify, and delete Entities (cf. EntityManagementUnit) as well as establish or delete Relationships between Entities from the content layer (cf. RelationshipManagementUnit). In contrast, the hypertext layer represents a view on the content layer of a web application, only. The Hypertext package summarizes ContentUnits, used, for example, to display information from the content layer which may be connected by Links in a certain way.

The HypertextOrganization package defines the Page modeling concept which is used to organize and structure information from the content layer, e.g., ContentUnits from the Hypertext package, SiteViews group Pages as well as operations on data from the content layer, e.g., OperationUnits from the ContentManagement package. More specifically, SiteViews represent groups of pages devoted to fulfilling the requirements of one or more user groups.

OO-H Metamodel. The class structure of the resulting OO-H metamodel is presented in Figure 4. Similar to the WebML metamodel, the Layer 0 and Layer 2 modeling requirements are realized by corresponding packages in the OO-H metamodel, i.e., the Content package and Service package, respectively. Concerning Layer 1, two packages have been defined, however, namely the Navigation and Presentation packages.

In the Content package, OO-H's content model is based on the UML class diagram: A Class represents a description of common structural and behavioral features, e.g., Attributes and Operations, respectively. Classes can be connected with each other via Associations.

The Service package contains the modeling concept ServiceNode that allows the execution of arbitrary operations defined at the content layer. The modeling concept ServiceLink is needed to connect NavigationalNodes with ServiceNodes, and in addition, to transport information in terms of arguments from NavigationalNodes to Operations.

Figure 4: The OO-H Metamodel

The Navigation package represents a view on the content layer of a web application. In the Navigation package two types of NavigationalNodes can be distinguished, namely ClassNodes displaying information from the content layer, and Collections providing additional information such as navigation menus. Both types have in common that they may be connected by Links. OCLExpressions attached to Links either filter certain objects which should be displayed at the target NavigationalNode or are used as preconditions that must be assured to access the target NavigationalNode.

The Presentation package defines the Page modeling concept which is used to organize and structure the NavigationalNodes of the navigation layer.

Model Transformations Using ATL

Following we discuss one representative example for the commonalities between WebML and OO-H, in order to exemplify how integration is achieved on the basis of metamodels and model transformation.

As already mentioned, ATL was used as model transformation language, which is a uni-directional, rule-based transformation language. For a full integration, consequently, transformation rules have to be specified for both directions, e.g. from WebML to OO-H and vice versa. An ATL rule consists of a query part (from keyword), which collects the relevant source model elements, and a generation part (to keyword) creating the target model elements.

In Figure 5 (a) we illustrate the semantic correspondences between WebML and OO-H metamodel elements and present two ATL rules implementing the transformation from WebML to OO-H in Figure 5 (b).

1. Rule Entity_2_Class is responsible for transforming each Entity of the WebML model into a Class in OO-H. 2. Rule DisplayUnit_2_ClassNode is responsible for transforming each instance of the concrete subclasses of DisplayUnit into ClassNodes. 3. This minimal example already shows some advantages of using ATL in contrast to using a general-purpose programming language. When executing ATL rules, a "trace model" is created transparently, which saves how instances are transformed. In our example the ATL engine traces which Class instance is generated for an Entity instance. Therefore, it is possible to retrieve the Class instance for the referenced Entity, which allows for the simple statement cN.displayedClass <-dU.displayedEntity.

Lessons Learned

Following, we summarize our lessons learned concerning the integration of WebML and OO-H. In general, the integration of WebML and OO-H has turned out to be straight-forward for the most part. At least for the core concepts of web modeling, which have been the focus of the MDWEnet initiative, there exist many commonalities between the two languages. Since the chosen modeling examples could be realized in each language the languages can be considered to have "equal" expressivity with respect to the defined core requirements. Nevertheless, we also faced differences between the languages, which aggravated the integration. When integrating languages based on their metamodels, further information, which often are not covered by the metamodels, must be incorporated into the transformation rules. This kind of information is on the one hand incorporated into the code generator and on the other hand defined by the frameworks for which code is generated. Some of these differences and the complexity they introduced during integration are explained following the structure of the modeling requirements layers. Nevertheless, from our current experiences we are able to conclude that the differences can be eliminated within the transformations rules. Due to space restrictions and readability reasons we explain the transformation rules textually and refer the reader to [30] for detailed information on the ATL code.

Content Modeling (Layer 0)

As can be seen in Figure 1, WebML and OO-H have different origins. WebML is based on the ER-model, which is typically used in the context of modeling database schemas. In contrast, OO-H has emerged from an object-oriented background. Consequently, in WebML each Entity has a set of operations which are "implicitly" available and need not be defined by the modeler, i.e., WebML's ContentManagementUnits actually represent a data manipulation language (DML). These operations include typical create, update, and delete operations as well as operations for linking Entities (cf. Table 2). In contrast, in OO-H there are some predefined operation types available, which have to be explicitly defined for each Class by the modeler (cf. Table 2). Thus, when transforming WebML Entities in OO-H Classes, the default operations must be created for each corresponding Class, in order to ensure that OO-H's ServiceNodes can execute them. Generally speaking, one could say that WebML is the more explicit language compared to OO-H, i.e., in the way that there are much more language concepts used. In particular, this is the case for hypertext modeling where OO-H uses a minimal set of concepts, which are refined with OCLExpressions, i.e., preconditions and filters, for Links. In contrast to WebML, where various types of ContentUnits are available, OO-H uses the concepts ClassNode and Collection, only. The actual content and behavior of ClassNodes is defined by their incoming Links. Furthermore, for parameter passing WebML offers LinkParameters with explicit source and target parameter bindings, while in OO-H this is again expressed by OCLExpressions.

Besides the difference in the number of explicit concepts, WebML and OO-H both use their own selector language for computing the content to be displayed. While in OO-H the Object Constraint Language (OCL) [23] has been reused and extended, WebML's selector language is defined within the metamodel as well as based on the concepts of Selector and SelectorCondition [30]. However, in the current version of the OO-H metamodel, the modified grammar for the OCL is not yet covered as it is done for the WebML selector language in the WebML metamodel. Thus, currently the OCL statements are hard-coded in the transformations rules as ordinary Strings. Incorporating the OCL grammar into the OO-H metamodel and the refinement of the model transformations in order to define the OCL statements as model elements is subject to future work. In the following, an example illustrating these differences between WebML and OO-H is given.

Example: A search scenario is given, where in the first page the user provides input, i.e., a certain year, for searching the set of albums. Figure 7 (a) shows the example modeled with WebML4 , where the EntryUnit AlbumSearch with a Field named 'from' represents the input form. The Link to the IndexUnit AlbumResults carries the user input in terms of a parameter. Therefore, a LinkParameter is assigned to the Link, which has as LinkParameterSource the input Field and as LinkParameterTarget the SelectorCondition of the AlbumResults IndexUnit. This SelectorCondition computes the subset of all albums where the input value of the user equals the value of the year attribute. In Figure 7 (b), the same information is modeled with OO-H, where a separate concept for the information that is transported via Links is not available. More specifically, the search scenario can be modeled with a Collection AlbumSearch and a Link to the ClassNode AlbumResults. The Link contains a filter OCLExpression dst.year = ?, with the question mark standing for the user's input value and dst.year meaning the 'year' Attribute of the Album Class.

OO-H Filter Conditions

This example illustrates the need to integrate the various WebML ContentUnits with OO-H Collections and ClassNodes as well as WebML LinkParameter and SelectorConditions with OO-H filter OCLExpressions.

Content Management Modeling (Layer 2)

Due to the differences at the content modeling layer, the modeling concepts for content management modeling are also differently defined in WebML and OO-H. For each operation on Entities of the content modeling layer WebML offers an explicit modeling concept, e.g., CreateUnit, DeleteUnit, and ConnectUnit. In contrast, OO-H's Service package encompasses two concepts only, namely ServiceNode and ServiceLink. This means that OO-H does not differentiate between the typical create, update, and delete operations by defining sub-concepts of ServiceNode. Instead a ServiceNode has a reference to the Operation which should be executed when the ServiceNodes is entered.

Example: The given scenario describes the deletion of a specific album by an authorized user. In Figure 6 (a) a DeleteUnit DeleteAlbum is shown which might be accessed, e.g., through an IndexUnit AlbumSearch (cf. Figure 7 (a)). Likewise, concerning OO-H a ServiceNode DeleteAlbum might be accessed, e.g., through a ClassNode (cf. Figure 7 (b)). For the given scenario we assume that the Selectors and SelectorConditions are translated according to the transformation rules defined for the hypertext modeling layer. Beyond, each OperationUnit from the WebML model needs to be translated into a ServiceNode in the OO-H model. Thereby, the reference identifying the corresponding operation type (cf. Table 2) must be set for the ServiceNode.

Conclusions and Future Challenges

In this paper we have presented our methodology of integrating three of the most prominent web modeling approaches, namely WebML, OO-H, and UWE, on the basis of a set of core web modeling requirements. As a proof of concept, we have defined the core languages in Ecore-based metamodels and subsequently, have implemented the integration in ATL model transformations rules. From our preliminary results and lessons learned from the integration of WebML and OO-H sofar, we conclude that the core of the three languages can be integrated without loosing information. Nevertheless, the presented results are only a first step in the direction of a full integration of the languages and to the definition of a common metamodel for web modeling.

Future challenges concerning the integration of WebML and OO-H include the finalization of the integration for their core modeling concepts which requires the OCL version used in OO-H to be incorporated in the metamodel. Therefore, we plan to employ the EBNF_2_Ecore transformer [29], which is capable of generating the corresponding metamodel elements from a textual EBNF grammar. On the basis of this we intend to finalize the transformation rules from OO-H to WebML.

The UWE metamodel is currently under preparation. As soon as a first stable version is available, we plan to integrate UWE with the two other modeling languages as well. We expect that a third language would bring further insights for building the common metamodel for web modeling and on these results a first unification of the modeling concepts can be proposed for the core requirements.

Beyond the core requirements, the modeling requirements and modeling examples need to be extended to other web modeling concerns such as presentation, contextawareness, and business processes in the future to broaden the view on the unification of the modeling concepts. Furthermore, a refinement of possible variants of modeling requirements, in order to find further sub-concepts and alternative modeling styles would be of interest.