Web Engineering methods have evolved during the last years to deal with new requirements that have arisen as a natural evolution of Web Applications. However, a new challenge that has been little handled by some of these methods is the data and functionality integration with third-party systems. Relying on the basic principles of the OMG Model Driven Architecture, we present a solution to achieve this integration at the conceptual modelling level. Therefore, solving the integration problem at this level of abstraction let us (1) give a general solution that is not tied to any particular implementation technology and (2) to handle external components at the conceptual modelling phase. To achieve this goal we present a new model that characterizes external functionality at a high level of abstraction.
In the last years it has been done a very hard work in the Web Engineering field. As a
result, a set of proposals have been developed to tackle with features such as
navigation. The most outstanding proposals developed are WebML [
Web Engineering Methods, such as WebML, have addressed directly the
integration of Web Services [
The amount of data and functionality available in the Web make us to think in the benefits that we can bring to Web Applications. Now we can provide Web users not only with the data and functionality maintained by our own system. Therefore, we are in conditions to create value added Web Applications. However, the functionality available in the Web is given in terms of an underlying technology, and this fact makes difficult the integration at the modelling level.
The main contribution of this work is to present a MDA [
The rest of the paper is structured as follows. Section 2 presents the Services Model. In section 3 we introduce the mechanisms used to integrate the Services Model previously introduced with the existing Web Engineering models. Section 4 illustrates through the use of an example how to achieve data and functional integration with third-party systems. Finally, Section 5 draws some conclusions and outlines some further work. 2
For the design of the Services Model we have followed the MDA principles aimed to provide portability, interoperability and reusability through architectural separation of concerns. This practice allows us to define integration independently from technology. The Services Model is made up of a set of operations with their input and output parameters. As a result, we have defined the Services Model at two different levels, at the PIM level and at the PSM level. The Services Model defined at the PIM level let us to characterize in a general way the functionality imported from thirdparty systems. However, the Services Model at the PSM level is intended to characterize the peculiarities of each specific technology. As a final goal what we want to achieve is the automatic code generation. So, we have to keep specific information from each technology. For this reason, we have to define as many Services Model at the PSM level as technologies we want to integrate with our system. This separation of concerns let us to integrate coherently external functionality (defined in general terms in the Services Model at the PIM level) with the native elements from the rest of the PIM models (structural, behavioural and navigational models). Due to space constraints we provide here just a general idea of the proposal, avoiding the inclusion of specific details. Fig. 1 shows that the integration with external functionality is done through the Service Model defined at the PIM level, instead of dealing directly with the PSM models. Moreover, it shows that we need a new Service Model for each technology that we want to support integration.
Structural
Model Behavioural
Model Navigational
Model
PIM Level
PSM Level Services Model
Services Model for
Web Services
Once we have external functionality defined in our system we have to integrate it with our native modelling elements. In next section we identify the mechanisms to achieve integration between models. 3
Depending on the use that we want to do of the imported functionality, we distinguish three different ways to achieve the Services Model integration through: the structural model, the behavioural model and the navigational model.
The first mechanism is to associate external functionality to our structural model. This association let us to enrich the definition of a class (defined in our structural model) adding new attributes or operations not modelled initially in our system. When we detect that the results provided by some external functionality can complement the data contained in our structural model we create a new “derived” attribute in the class to be enriched. With the word “derived” we mean an attribute which value is not kept in the persistent layer. Moreover, we have to provide the “formula” that feeds this new attribute. This formula will be based on the definition of the external functionality. However, we also can find external services which provide extra functional value to our classes. In these cases, we should wrap the external functionality into a new operation created in the enriched class.
The second mechanism to associate external functionality is by means of the behavioural model. This association is made when we want to include some external functionality in the definition of a complex operation (an operation defined as a sequence of steps/sub-operations). We can now compose operations based on internal as well as external operations.
Finally, the third mechanism is to associate external functionality directly to the Navigational Model. This kind of association is made when we want to include new data or functionality that it is not "directly" related to any of the elements modelled originally in our system.
Following this approach now the use of external functionality is almost transparent for the web designer. Note however, that we have to keep the information that allows us to know how to invoke imported functionality (via SOAP or REST in the case of Web Services). At modelling level we do not need to know these details, but when generating the final code of the Web Application this information will be necessary.
In next section, by means of a Library Web Application, we illustrate each one of the integration mechanisms introduced in the previous paragraphs.
The Library Web Application provides users with information (title, author, publication year, etc.) and functionality (to make a booking or ask for a buying) related mainly to books. To complement the data and functionality modelled and handled by our library system we are going to integrate functionality published by external providers such as an e-shop and another on-line library system.
Based on the initial requirements of the Web Application, we have defined the class Book with the following attributes: title, publication year, edition, language and issn. Through the use of external services we could add to this information the price or the list of e-shops which sell a specific book. In case a book is not available in the library at this moment, we also could provide the facility to reserve this specific book in another on-line library system.
In the following subsections we provide details of the examples that illustrate how to accomplish this integration.
We are going to create the "derived" attribute price in the class Book. This attribute will be fed by the result provided by the imported service itemSearch. We must define the formula that will provide the value to the price attribute. Sometimes this result provides more information than we need. To navigate through the returned data structure we use the dot syntax.
price = (itemSearch(title)).price The definition of this new attribute in the class diagram allow us to include it in the navigational model in an equivalent way as any other attribute of the class.
To include external functionality to the class Book we are going to create a new operation. Once the external operation is wrapped we can use it equally as the rest of internal operations. Note that the interface of the wrapping operation must be coherent with the wrapped functionality. We are going to include the operation bookReservation in the class book to wrap the bookReservation operation imported in the Services Model. Fig. 2 shows graphically this integration.
book
In the definition of an operation such as searchBook we want to search not only in our catalog, moreover, we want to search in other external libraries. For this purpose, we specify the sequence of services to execute when this operation is called. This specification can be done through an activity diagram as depicted in fig. 3. If the specified book has not been found in our catalog we complement the search with an external service provided by another library (the UPV library).
The Navigational model defines the navigational structure of a Web application. This structure is defined usually by means of a graph based representation technique, where graph nodes represent web pages and arcs among nodes represent links. Graph nodes are made up of a set of views over the structural model; these views define the information that is shown in each web page. However, following the presented approach, we allow the construction of these views also from third-party systems. For example, if we want to include in a web page information such as the most purchased books from Amazon we would include it by adding a view in the node from the corresponding Amazon service. Fig. 4 shows a web page that illustrates this case.
In this work we have presented a high level integration approach for Web Applications. This integration is achieved through a set of mechanisms that associate at the PIM level the Services Model with the rest of models.
As further work we have planned to take these ideas to practice by providing a prototype. Moreover, once this proposal had been completely defined we want to study how to achieve data integration through the use of Ontologies and Semantic Web representations.