Towards Re-engineering Web Applications into Semantic Web Services

Djelloul Bouchiha, Mimoun Malki EEDIS Laboratory, Djillali Liabes University of Sidi Bel Abbes, Algeria.

{bouchiha_dj, malki}@univ-sba.dz

Abstract— Semantic Web Services (SWS) are enriching Web services with machine processable semantics. To be implemented with less effort, SWS can reuse syntactic and semantic descriptions hidden under the source code of Web applications already developed. For this end, we propose a framework for reengineering Web applications, possibly already including some semantic technology, into WSMO-based SWS. The proposed framework consists in reverse engineering Web applications towards conceptual models specified with a proposed UML profile, from what syntactic and semantic descriptions of new SWS are generated. A set of tools have been developed and some experiments have been carried out to evaluate and validate the proposed framework.

Keywords- Reengineerig; Reverse engineering; Web applications; Semantic Web Services; Ontology; WSMO; UML profile;

I. INTRODUCTION

In recent years, software systems, which provide their functionalities through the Web, evolved from Web applications into Semantic Web Services (SWS) which are enriching Web services with semantic descriptions. For implementing SWS, the Web Service Modeling Ontology (WSMO) [14] provides a conceptual underpinning and a formal language for semantically describing all relevant aspects of Web services in order to facilitate the automatization of discovering, combining and invoking electronic services over the Web.

Since several efforts have been provided to develop Web applications, then it will be more rational and economic to reuse and adapt these works to generate semantic Web services, rather than build them from the scratch.

In this paper, we propose a framework for semi automatically reengineering Web applications into WSMO based semantic Web services. The proposed framework consists of two phases: (1) Web application reverse engineering phase which consists in extracting abstractions from the Web application code. These abstractions are represented as proposed UML profile models, and (2) Semantic Web services forward engineering phase which consists in generating semantic and syntactic descriptions of the semantic Web services.

The remainder of the paper is organized as follows: The next Section presents a framework for reengineering Web applications into SWS. The implemented tools are presented in

Section 3. Validation methods and tools are provided in Section 4. Related works are introduced in Section 5. Finally, conclusion and some perspectives are provided in Section 6.

II. THE PROPOSED FRAMEWORK

The proposed framework allows semi automatic reengineering of Web applications toward SWS. It receives as input the source code of the traditional Web application (HTML + PHP, JSP, or others), a relational database schema, and possibly existing OWL ontologies inherited from the Semantic Web structure of the application. It generates the four WSMO components of SWS, namely ontologies, mediators, Web services, and goals. It also generates the WSDL description of the aimed SWS.

WSMO .components

OWLOntology

Web application (HTML + PHP,…)

(Semantic) Web application

Reverse engineering Process

WSML domain Ontology

WSML Application Ontology

UML profile Models

Web services Goals Mediators

Web

-app

licat

ion

Rev

erse

-en

gine

erin

g ph

ase

(1)

Sem

antic

Web

serv

ices

en

gine

erin

g ph

ase

(2)

Engineering Web service syntactic description

WSDL file code

Engineering WSMO components

Translating Into WSML

Figure 1. The proposed framework.

The proposed framework consists of two major phases: Web application reverse engineering and SWS forward engineering (Fig. 1). Next, we detail all steps, heuristic rules and algorithms implied in the two phases.

350978-1-4244-8611-3/10/$26.00 ©2010 IEEE

A. Web application reverse engineering phase Web application reverse engineering phase extracts a model

based abstract view of the considered Web application, starting from the available implementation.

The generated models are expressed according to the proposed UML profile, and consider both Static pages (pure HTML with no server-side scripting) and Dynamic Pages (including executable code at the server side). Tab. 1 illustrates the main stereotypes introduced in the proposed UML profile.

Table 1. Stereotypes defined in the proposed UML profile.

Stereotype Applies to Definition

<<Solicit>> ActivityActivity that receives message from external

Swimlane

<<Response>> Activity Activity that sends back message to an external

Swimlane <<Request-Response>> Activity Activity that call service and

receive a response <<POperation>> Activity A generic Activity

<<ControlLink>> Transition Specializes the Stereotype

<<Link>>. Transition between two activities

Reverse engineering aims at recovering design models (class and activity diagrams) from Web applications code. The resulting models cover static and dynamic aspects of the application.

1) Recovering class diagram This process is mainly based on database and HTML pages

analysis, and requires the use of OWL domain ontology. It consists in three steps: extraction of candidate elements, analysis and conceptualization.

a) Extraction of candidate elements Candidate elements are extracted from HTML pages and

database schema: � In the HTML pages, candidate elements are hidden in

tables, lists, forms etc. � Database tables’ names and attributes’ names of each

table are considered as candidate elements [8]. b) Analysis

The analysis step consists in identifying the ontology concepts that correspond to candidate elements by using some semantic distance techniques. Semantic distance aims to quantify how much two entities are alike. For more details about recovering class diagram, refer to [3].

c) Conceptualization From a set of concepts and relations, we can now construct

a UML class diagram. The rules below briefly summarise the transformation rules used in the conceptualisation step:

� Rule 1: An identified ontology concept becomes UML class. The ontology concept name becomes the UML class name.

� Rule 2: For taxonomic relation that expresses hierarchical relationship, their translation is as follow :

� IS-A relation becomes UML Generalization/Specialisation relationship.

� Part-of relation becomes UML Aggregation/ Composition relationship.

� Rule 3: For no taxonomic: they are translated as follow:

� Relation having concept as domain and range becomes a UML association relationship.

� Relation having concept as domain and a data type as range becomes a UML attribute.

� Rule 4: Ontological axioms, which include the identified concepts, are translated into OCL constraints.

For more details about recovering class diagram, refer to [3].

2) Recovering activity diagram It consists in extracting activity diagrams from static and

dynamic pages. The static pages reflect the user behavior and the dynamic pages reflect the system behavior.

Most of the implicit structures and constraints are buried into the source code of the Web application. Analyzing the source code requires sophisticated program understanding techniques [10], notably pattern matching technique and program dependency graph. The pattern matching technique consists in searching patterns (strings) in the source code. Program dependency graph is a graph that represents the relation between the program components [11]. In our case a dependency graph is represented by an activity diagram.

We note that Web application reverse engineering is a semi automatic phase that must be validated by the designer.

B. SWS Forward engineering phase The SWS forward engineering phase is a semi automatic

process assisted by the software engineer. It exploits visual declarative models (class and activity diagrams) obtained from the Web application reverse engineering phase for semi automatically generating WSDL syntactic and WSMO semantic descriptions of the corresponding SWS. In the following, we summarize how to extract these descriptions from class and activity diagrams.

1) Building WSMO ontology The WSMO ontology provides the terminology for the

other WSMO elements. The rules below briefly summarise the transformation rules from the UML class diagram to the WSMO ontology:

� Rule 1: UML class becomes an ontology concept.

� Rule 2: UML association becomes an ontology relation.

� Rule 3: IS-A relation (generalization/specialisationrelationship) becomes a subsumption relation.

� Rule 4: Aggregation/composition relationship becomes a relation named Part-of.

� Rule 5: OCL constraints are translated into ontological axioms.

In the case of availability of OWL ontologies, inherited from semantic Web application, a translation process will be applied on these ontologies to be translated into WSML [5]. For more detail refer to [12].

351

We note that building WSMO ontology is a semi automatic task that must be assisted by the software engineer and the domain expert.

2) Generating WSMO descriptions of the Web services The activity diagram of our UML profile, describing the

dynamic aspect of the application, provides enough fordescribing the Web services behaviors. For WSMO description of web services, we consider only Swimlanes corresponding to the Dynamic Pages. Assuming that a web service is represented by one Swimlane, so the semantic description of this Web service will be as follows:

a) Extracting Web service capability Capability elements of a service Web are extracted

according to the following rules:

� Rule 1: Pre-conditions are obtained from the first Solicit activity of the Swimlane corresponding to the Web service.

� Rule 2: Post-conditions are obtained from the last Response activity of the Swimlane.

� Rule 3: Effects are extracted from the POperation activities that modify or create instances of classes of theclass diagram.

� Rule 4: Shared variables are obtained by determining the shared variables between pre-conditions, post-conditions and effects.

Notice that assumptions have to be added manually.

b) Extracting Web service choreography and orchestration

The extraction of this kind of information is rather simple: provided that a Swimlane describes a single Web service, we can assume that all the ControlLinks traversing its borders contribute to specifying a possible invocation order of the operations, i.e. a choreography interface of the Web service.

For specifying the WSMO orchestration between Web services, we follow vertically the Swimlanes of the activity diagram.

3) Generating WSMO descriptions of the goals Goals are the objectives that a client may have when

consulting a Web service. For WSMO description of goals, we consider only Swimlane corresponding to the Static Pages in the UML profile diagram describing the dynamic aspect (activity diagram). In particular, the following rules are used:

� Rule 1: shared variables are extracted from the data instances sent by the request-response activities.

� Rule 2: effects are obtained considering the request-response activities modifying data associated to the extracted shared variables.

4) Generating WSMO descriptions of the mediators Mediators are elements used to link heterogeneous

components or services. The problem of generating mediation service is cast as a problem of generating mapping rules between two sets of entities which are identified according to the mediator’s role. For example, the role of OO-mediator

consists in resolving mismatches between WSML ontologies. Each WSML ontology concepts present a set of entities.

To express the mapping rules, the modeling language OCML [9] is used. Thus, the equivalence between the two concepts C and K is expressed by the mapping rule: (def-concept-mapping C K).

The process of generating mediation components is considered semi automatic, since the system user has the possibility of withdrawing some mapping rules, or validating the result as it is generated.

5) Generating WSDL description of the Web services WSDL (Web Service Description language) is the adopted

language for describing syntactically the Web service functionalities [4].

In the following, we define the mechanisms used to produce syntactic WSDL descriptions from UML model elements supported by the proposed profile.

� Rule 1: Each WSDL document aims at describing one service Web. Thus, each Swimlane of the activity diagram, tagged by DynamicLane = true, will be used to generate a WSDL document of a service Web.

� Rule 2: Each class of the class diagram can be described as a new type used in the WSDL description.

� Rule 3: Each activity of a Swimlane will be considered as a WSDL operation that exchanges XML messages.

� Rule 4: WSDL operations are defined based on XMLmessages.

We note that generating WSDL description of the web services is a semi automatic task that must be checked by theprogrammer.

III. IMPLEMENTED TOOLS1

Many parts of the proposed framework are supported by toolsets. For checking the reverse engineering phase, we developed a tool called OntoWeR [2]. The tool allows generating class diagrams starting from Web application code and domain ontology. It has been extended to support additionally activity diagrams.

We also developed several prototypical transformers that generate WSMO compliant descriptions of Web services starting from the proposed UML profile models representing the Web applications. The WSDL description generation tool has not been implemented yet.

IV. VALIDATION

Both reverse engineering and forward engineering need to be validated either manually by software engineers or automatically by dedicated tools.

All the recovered diagrams of a running example were validated by submitting them to the judgment of the software engineers that had developed the Web application. These diagrams were compared against the original diagrams

1 http://www-inf.univ-sba.dz/WSMO/

352

designed by the software engineers: no substantial differences were found between the recovered diagrams and the original ones. these results showed us the effectiveness of the reverse engineering phase of the framework.

The resulting WSMO components were validated by WSML Validator plugin integrated in WSMO-Studio2. In the early test sessions some errors have been detected, so we corrected these descriptions and reperformed the test. No more failures were obtained after the correction.

V. RELATED WORKS

Several approaches have been proposed for reengineering Web application to Web services. However, in these works no semantics have been generated. Tab. 2 summarizes the approaches’ characteristics.

Table 2. Summary of approaches of reengineering Web applications to Web services.

Approach Analysedsource

Usedtechniques Starategy

Jiang and al., 2004 [7]

Presentationlayer

pattern based techniques Wrappers

Huy and al., 2004 [6]

CGI based Web Sites

Web

Dataextraction Wrappers

Baumgartner and al., 2004

[1]

HTML Documents

Dataextraction Wrappers

Tatsubori and al., 2006 [13]

Web Application

Model driven approach Wrappers

� The "Approach" column indicates the approach’s authors. � The "Analysed source" column indicates which part of the

Web application will be analysed. � The "Used techniques" column indicates the used

techniques in the analysis process. � The "Adopted strategy" column indicates if the

reengineering process will generate a new code or keep the original code and encapsulate it as a Web service by Wrapper technique.

The mentioned approaches above cover partially the reengineering process. Moreover, they start from analysing the implementation code of the considered application. However, the syntactic code is not reach enough to specify the semantic descriptions of the target SWS. By using ontologies in our framework, in both the reverse engineering phase to generate class diagram, and the forward engineering phase to generate WSDL ontology, we can discover and correct some errors at early stage of the SWS reengineering process. Therefore, the quality of the resulting models and semantic descriptions can be ensured and the cost of the migration can be reduced as well.

VI. CONCLUSION AND PERSPECTIVES

In this paper, we defined a mapping from Web application source code to the WSMO semantic and WSDL syntactic descriptions of the corresponding SWS, using a proposed UML profile as a bridge for this mapping. This starts by a reverse engineering process from the Web application towards the UML profile models. Then, it presets a mapping of those models to SWS (forward engineering process).

2 http://www.wsmostudio.org/

The proposed framework for reengineering Web applications into WSMO-based Semantic Web Services aims at improving development productivity and adoption of SWS. The proposed framework was implemented through a set of tools that reduced the manual intervention of the designer in the reengineering process.

Some experiments have been carried out to evaluate and validate the proposed framework. In a future work we intend tovalidate the framework on a set of industrial complex cases and to better integrate and refine the developed prototype tools.

REFERENCES

[1] R. Baumgartner, G. Gottlob, M. Herzog, and W. Slany, "Interactively Adding Web Service Interfaces to Existing Web Applications". Proceedings of the International Symposium on Applications and the Internet (SAINT’04). 2004.

[2] S-M. Benslimane, M. Malki, D. Bouchiha, and D. Benslimane, "Ontower : An ontology based web application reverse-engineering approach". International Review on Computers and Software (IRECOS), 1(1) :52–58. 2006.

[3] D. Bouchiha, M. Malki, and S. M. Benslimane, "Ontology Based Web Application Reverse-Engineering Approach". Journal of Computer Science, Vol. 6(1). p: 37-46. 2007.

[4] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, "Web Services Description Language (WSDL) 1.1." Available at http://www.w3.org/TR/wsdl. 2001.

[5] J. de Bruijn, H. Lausen, A. Polleres, and D. Fensel, "The web service modeling language: An overview". In Proceedings of the 3rd European Semantic Web Conference (ESWC2006), number 4011 in LNCS, pages 590-604, Budva, Montenegro, Springer. 2006.

[6] H-P. Huy, T. Kawamura, and T. Hasegawa, "Web Service Gateway – a step forward to e-business". Proceedings of the IEEE International Conference on Web Services (ICWS'04), California, USA. 2004.

[7] Y. Jiang, and E. Stroulia, "Towards reengineering Web sites to Web-services providers". In Proceedings of the Eighth European Conference on Software Maintenance and Reengineering (CSMR’04), pp. 296-305. 2004.

[8] M. Malki, A. Flory, M.K. Rahmouni, "Extraction of Object-Oriented Schemas from Existing Relational Databases: A Form-DrivenApproach". INFORMATICA International Journal (Lithuanian Academy of Sciences), pp 47-72, Vol. 13(1). 2002.

[9] Motta, E., (2004). Reusable Components for Knowledge Modeling: Case Studies in Parametric Design Problem Solving. IOSPress.

[10] H. Müller, "Understanding Software Systems Using Reverse Engineering Technologies Research and Practice". In Proc. of 18th International Conference on Software Engineering, Germany. 1996.

[11] K-J. Ottenstein, and L-M. Ottenstein, "The program dependence graphin a software development environment". In Proc. of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments. 1994.

[12] N. Steinmetz, J. de Bruijn, and A. Frankl, "WSML/OWL Mapping". WSML Working Draft. available at http://www.wsmo.org/TR/d37/v0.2/20080513/d37v0.2_20080513.pdf. 2008.

[13] M. Tatsubori, and K. Takahashi, "Decomposition and Abstraction of Web Applications for Web Service Extraction and Composition". IEEE International Conference on Web Services (ICWS 2006), Chicago, Illinois, USA. Pages: 859-868. 2006.

[14] H-H. Wang, N. Gibbins, T. Payne, A. Saleh and J. Sun, "A Formal Semantic Model of the Semantic Web Service Ontology (WSMO)". In: Twelfth IEEE International Conference on Engineering of Complex Computer Systems, Auckland, New Zealand. 2007.

353