Web Engineering: 7th International Conference, ICWE 2007, Como, Italy, July 16-20, 2007, Proceedings

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen University of Dortmund, Germany Madhu Sudan Massachusetts Institute of Technology, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Moshe Y. Vardi Rice University, Houston, TX, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

4607

Luciano Baresi Piero Fraternali Geert-Jan Houben (Eds.)

Web Engineering 7th International Conference, ICWE 2007 Como, Italy, July 16-20, 2007 Proceedings

13

Volume Editors Luciano Baresi Piero Fraternali Politecnico di Milano Dipartimento di Elettronica e Informazione piazza Leonardo da Vinci 32, 20133 Milano, Italy E-mail: {luciano.baresi, piero.fraternali}@polimi.it Geert-Jan Houben Vrije Universiteit Brussel Department of Computer Science Pleinlaan 2, 1050 Brussels, Belgium [email protected]

Library of Congress Control Number: 2007930462 CR Subject Classification (1998): D.2, C.2, I.2.11, H.4, H.2, H.3, H.5, K.4, K.6 LNCS Sublibrary: SL 3 – Information Systems and Application, incl. Internet/Web and HCI ISSN ISBN-10 ISBN-13

0302-9743 3-540-73596-8 Springer Berlin Heidelberg New York 978-3-540-73596-0 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. Springer is a part of Springer Science+Business Media springer.com © Springer-Verlag Berlin Heidelberg 2007 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12089673 06/3180 543210

Preface

This volume contains the proceedings of the seventh International Conference on Web Engineering (ICWE2007), which was held in Como (Italy) in July 2007. The conference is the flagship event of the community, promoting research and scientific progress in the Web engineering field. The importance of the Web — and of its many related technologies— is widening the scope of the conference year after year, and is also leading to the cross-fertilization of several related disciplines (e.g., requirements engineering, testing and analysis, communication science, HCI, multimedia, and more). The conference brings together practitioners, scientists, and researchers committed to investigating and innovating the technologies, methodologies, tools, processes, and techniques used to construct, verify, and maintain Web-based applications and services. This year, the Call for Papers attracted a high number of submissions with a very good coverage of all the different facets of the Web engineering discipline. A total of 172 submissions (as for research papers) allowed us to build an attractive program of high technical and scientific quality. The 39 selected submissions comprise 26 full papers and 13 short papers (with an acceptance rate close to 23%); they cover the different aspects highlighted in the Call for Papers and represent well the many Web engineering research groups active worldwide. The program spans from service-based systems to testing and analysis, from quality and metrics to models, and from semantic issues and Web 2.0 to application development techniques. This year, we strove to attain a very homogeneous program in which the different initiatives (technical program, workshops, tutorials, demos, and doctoral symposium) are intertwined in a coherent sequence of events. The technical program remained the main forum for presenting innovative, and already consolidated, research results, while the collateral events were valuable opportunities to present interesting ideas and practical realizations and to discuss on-going research, and thus advance the state of the art in the field. The conference would not have been possible without the help of Politecnico di Milano, WebRatio, Acer, and Cefriel, which kindly accepted to support the conference, the endorsement of the International World Wide Web Conference Committee and the International Society for Web Engineering, and the enthusiastic work of the various chairs (Emilia, Nora, Maristella, Sara, Fabio, Sven, Alexander, Michalis, Antonio, and Marco), and of the local organizers. Finally, special thanks to all the contributors and participants who, at the end of the day, are what a conference like ICWE is all about. May 2007

Luciano Baresi Piero Fraternali Geert-Jan Houben

Organization

General Chair Piero Fraternali, Politecnico di Milano, Italy

Program Chairs Luciano Baresi, Politecnico di Milano, Italy Geert-Jan Houben, Vrije Universiteit Brussel, Belgium

Program Committee Grigoris Antoniou, University of Crete, Greece Uwe Assmann, TU Dresden, Germany Maria Bielikova, Slovak University of Technology in Bratislava, Slovakia Judith Bishop, University of Pretoria, South Africa Marco Brambilla, Politecnico di Milano, Italy Chris Brooks, University of San Francisco, USA Fabio Casati, Universit` a di Trento, Italy Sven Casteleyn, Vrije Universiteit Brussel, Belgium Dan Chiorean, University Babes-Bolgni, Cluj, Romania Sara Comai, Politecnico di Milano, Italy Paul Dantzig, IBM T. J. Watson Research Center, USA Yogesh Deshpande, University of Western Sydney, Australia Olga De Troyer, Vrije Universiteit Brussel, Belgium Peter Dolog, Aalborg University, Denmark Schahram Dustdar, Vienna University of Technology, Austria Martin Gaedke, University of Karlsruhe, Germany Dragan Gasevic, Simon Fraser University, Canada Michael Gertz, UC-Davis, USA Athula Ginige, University of Western Sydney, Australia Angela Goh, NTU, Singapore Jaime Gomez, Universidad de Alicante, Spain Volker Gruhn, Universit¨ at Leipzig, Germany Gerti Kappel, Vienna University of Technology, Austria Alexander Knapp, Ludwig Maximilians Universit¨at M¨ unchen, Germany Nora Koch, Ludwig Maximilians Universit¨at M¨ unchen, Germany Frank Leymann, Universit¨at Stuttgart, Germany David Lowe, University of Technology Sydney, Australia Maristella Matera, Politecnico di Milano, Italy Heinrich Mayr, University of Klagenfurt, Austria

VIII

Organization

Emilia Mendes, University of Auckland, New Zealand San Murugesan, University of Southern Cross, Australia Moira Norrie, ETH, Switzerland Oscar Pastor, Universidad Politecnica de Valencia, Spain Vicente Pelechano, Universidad Politecnica de Valencia, Spain Michalis Petropoulos, University at Buffalo, SUNY, USA Claudia Pons, University of La Plata, Argentina I.V. Ramakrishnan, Stony Brook University, USA Gustavo Rossi, Universidad Nacional de la Plata, Argentina Daniel Schwabe, PUC Rio de Janeiro, Brazil Katsumi Tanaka, Kyoto University, Japan Ernest Teniente, UPC, Spain Bernhard Thalheim, Universit¨ at Kiel, Germany Philippe Thiran, University of Namur, Belgium Riccardo Torlone, Universit` a di Roma, Italy Paolo Traverso, ITC, Italy Antonio Vallecillo, Universidad Politecnica de Valencia, Spain Jean Vanderdonckt, Universit´e Catholique de Louvain, Belgium Fabio Vitali, University of Bologna, Italy Petri Vuorimaa, Helsinki University of Technology, Finland Jeffrey Yu, Chinese University of Hong Kong, China

Industrial Track Committee Fabio Casati, Universit` a di Trento, Italy (Chair) Boualem Benatallah, University of New South Wales Sydney, Australia Aldo Bongio, WebRatio, Italy Arthur Ryman, IBM Toronto, Canada Regis Saint-Paul, University of New South Wales Sydney, Australia Erwin Schaumlechner, Tiscover, Austria Ming-Chien Shan, SAP Research, USA Bebo White, SLAC, USA Jin Yu, Martsoft, USA

Doctoral Consortium Committee Nora Koch, Ludwig Maximilians Universit¨at M¨ unchen, Germany (Chair) Piero Fraternali, Politecnico di Milano, Italy Gerti Kappel, Vienna University of Technology, Austria Alexander Knapp, Ludwig Maximilians Universit¨at M¨ unchen, Germany David Lowe, University of Technology Sydney, Australia Emilia Mendes, University of Auckland, New Zealand Luis Olsina, Universidad Nacional de la Pampa, Argentina Oscar Pastor, Universidad Politecnica de Valencia, Spain Antonio Vallecillo, Universidad Politecnica de Valencia, Spain

Organization

IX

Demo Chairs Sven Casteleyn, Vrije Universiteit Brussel, Belgium Alexander Knapp, Ludwig Maximilians Universit¨at M¨ unchen, Germany

Tutorial Chair Michalis Petropoulos, University at Buffalo, SUNY, USA

Publicity Chairs Maristella Matera, Politecnico di Milano, Italy Antonio Vallecillo, Universidad Politecnica de Valencia, Spain

Treasurer and Sponsorship Chair Sara Comai, Politecnico di Milano, Italy

Local Organization Chair Marco Brambilla, Politecnico di Milano, Italy

Additional Referees Omar Alonso Andreas Bartho Bettina Biel S¨oren Blom Matthias Book Eugene Borodin Alessandro Bozzon Daniele Braga Michael Byrd Alina Campan Alessandro Campi Sebastian Cech Alejandra Cechich Florian Daniel Sergio Espa˜ na Federico Michele Facca Paul Fodor Joan Fons Conny Franke

Irene Garrigos Robert Gombotz Sam Guinea Michael G¨oschka Falk Hartmann Christian Wende Florian Heidenreich Christian Huemer Malte H¨ ulder Angelo Di Iorio Horst Kargl Nima Kaviani Nicolas Kicillof Engin Kirda Gerhard Kramler Katja Lehmann Tammo van Lessen Jalal Mahmud Daniel Martin

Johannes Meinecke Santiago Melia Elke Michlmayr Ralph Mietzner Milan Milanovic Hisashi Miyamori Shinsuke Nakajima Satoshi Nakamura Jose I. Panach Navarrete Johann Oberleitner Hiroaki Ohshima Satoshi Oyama Filippo Pacifici Conrad Parker Ins Pederiva Pierluigi Plebani Marco Plebani Birgit Pr¨oll Alessandro Raffio

X

Organization

Sebastian Richly Thomas Richter Florian Rosenberg Andreas Schroeder Wieland Schwinger Clemens Sch¨afer Martina Seidl Anu Singh Keishi Tajima Puay Siew Tan Taro Tezuka

Dave Thau Massimo Tisi Victoria Torres Martin Treiber Christina Tziviskou Tobias Unger Pedro Valderas Francisco Valverde Martin Vasko Roberto De Virgilio Valentino Vranic

Hui Wan Junhu Wang Jianshu Weng Branimir Wetzstein Matthias Wieland Daniel Wutke Qing Zhu Daniel Zinn Chang Zhao

Table of Contents

Services On Embedding Task Memory in Services Composition Frameworks . . . . . Rosanna Bova, Hye-Young Paik, Salima Hassas, Salima Benbernou, and Boualem Benatallah

1

A QoS Test-Bed Generator for Web Services . . . . . . . . . . . . . . . . . . . . . . . . Antonia Bertolino, Guglielmo De Angelis, and Andrea Polini

17

Engineering Compensations in Web Service Environment . . . . . . . . . . . . . Michael Sch¨ afer, Peter Dolog, and Wolfgang Nejdl

32

Context-Aware Workflow Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liliana Ardissono, Roberto Furnari, Anna Goy, Giovanna Petrone, and Marino Segnan

47

Practical Methods for Adapting Services Using Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hyun Jung La, Jeong Seop Bae, Soo Ho Chang, and Soo Dong Kim

53

Metrics and Quality On the Quality of Navigation Models with Content-Modification Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jordi Cabot, Jordi Ceballos, and Cristina G´ omez

59

Metamodeling the Quality of the Web Development Process’ Intermediate Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cristina Cachero, Coral Calero, and Geert Poels

74

The Use of a Bayesian Network for Web Effort Estimation . . . . . . . . . . . . Emilia Mendes

90

Caching Sequential Pattern-Based Cache Replacement in Servlet Container . . . . . Yang Li, Lin Zuo, Jun Wei, Hua Zhong, and Tao Huang A Hybrid Cache and Prefetch Mechanism for Scientific Literature Search Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Huajing Li, Wang-Chien Lee, Anand Sivasubramaniam, and C. Lee Giles

105

121

XII

Table of Contents

Interfaces Finalizing Dialog Models at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stefan Betermieux and Birgit Bomsdorf

137

Transparent Interface Composition in Web Applications . . . . . . . . . . . . . . Jeronimo Ginzburg, Gustavo Rossi, Matias Urbieta, and Damiano Distante

152

Fine-Grained Specification and Control of Data Flows in Web-Based User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Matthias Book, Volker Gruhn, and Jan Richter

167

Authoring Multi-device Web Applications with Database Access . . . . . . . Giulio Mori, Fabio Patern` o, and Carmen Santoro

182

Enriching Hypermedia Application Interfaces . . . . . . . . . . . . . . . . . . . . . . . . Andr´e T.S. Fialho and Daniel Schwabe

188

Models Functional Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Torsten Gipp and J¨ urgen Ebert Integrating Databases, Search Engines and Web Applications: A Model-Driven Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alessandro Bozzon, Tereza Iofciu, Wolfgang Nejdl, and Sascha T¨ onnies

194

210

A Method for Model Based Design of Rich Internet Application Interactive User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . M. Linaje, Juan C. Preciado, and F. S´ anchez-Figueroa

226

Improving Communication in Requirements Engineering Activities for Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pedro Valderas and Vicente Pelechano

242

Meta-model to Support End-User Development of Web Based Business Information Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Buddhima De Silva and Athula Ginige

248

Verification and Testing Easing Web Guidelines Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Barbara Leporini, Fabio Patern` o, and Antonio Scorcia

254

Table of Contents

XIII

A Transformation-Driven Approach to the Verification of Security Policies in Web Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Esther Guerra, Daniel Sanz, Paloma D´ıaz, and Ignacio Aedo

269

Efficiently Detecting Webpage Updates Using Samples . . . . . . . . . . . . . . . . Qingzhao Tan, Ziming Zhuang, Prasenjit Mitra, and C. Lee Giles

285

Auto-Generating Test Sequences for Web Applications . . . . . . . . . . . . . . . . Hongwei Zeng and Huaikou Miao

301

A Survey of Analysis Models and Methods in Website Verification and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manar H. Alalfi, James R. Cordy, and Thomas R. Dean

306

Semantics and Web 2.0 Building Semantic Web Portals with WebML . . . . . . . . . . . . . . . . . . . . . . . . Marco Brambilla and Federico M. Facca Engineering Semantic-Based Interactive Multi-device Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pieter Bellekens, Kees van der Sluijs, Lora Aroyo, and Geert-Jan Houben Towards Improving Web Search by Utilizing Social Bookmarks . . . . . . . . Yusuke Yanbe, Adam Jatowt, Satoshi Nakamura, and Katsumi Tanaka

312

328

343

Designing Interaction Spaces for Rich Internet Applications with UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Peter Dolog and Jan Stage

358

A Behavioral Model for Rich Internet Applications . . . . . . . . . . . . . . . . . . . Sara Comai and Giovanni Toffetti Carughi

364

Search Considering Web Accessibility in Information Retrieval Systems . . . . . . . Myriam Arrue and Markel Vigo

370

Fixing Weakly Annotated Web Data Using Relational Models . . . . . . . . . Fatih Gelgi, Srinivas Vadrevu, and Hasan Davulcu

385

Creating Personal Histories from the Web Using Namesake Disambiguation and Event Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rui Kimura, Satoshi Oyama, Hiroyuki Toda, and Katsumi Tanaka

400

XIV

Table of Contents

Comparing Clustering Algorithms for the Identification of Similar Pages in Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Andrea De Lucia, Michele Risi, Giuseppe Scanniello, and Genoveffa Tortora Structural Patterns for Descriptive Documents . . . . . . . . . . . . . . . . . . . . . . . Antonina Dattolo, Angelo Di Iorio, Silvia Duca, Antonio Angelo Feliziani, and Fabio Vitali

415

421

Application Development Component-Based Content Linking Beyond the Application . . . . . . . . . . . Johannes Meinecke, Frederic Majer, and Martin Gaedke A Double-Model Approach to Achieve Effective Model-View Separation in Template Based Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Francisco J. Garc´ıa, Ra´ ul Izquierdo Castanedo, and Aquilino A. Juan Fuente Model-Driven Development of Web Applications with UWA, MVC and JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Damiano Distante, Paola Pedone, Gustavo Rossi, and Gerardo Canfora On Refining XML Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Felipe I. Anfurrutia, Oscar D´ıaz, and Salvador Trujillo

427

442

457

473

Demonstrations Mixup: A Development and Runtime Environment for Integration at the Presentation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jin Yu, Boualem Benatallah, Fabio Casati, Florian Daniel, Maristella Matera, and Regis Saint-Paul Squiggle: An Experience in Model-Driven Development of Real-World Semantic Search Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Irene Celino, Emanuele Della Valle, Dario Cerizza, and Andrea Turati

479

485

WebTE: MDA Transformation Engine for Web Applications . . . . . . . . . . . Santiago Meli´ a, Jaime G´ omez, and Jos´e Lu´ıs Serrano

491

Noodles: A Clustering Engine for the Web . . . . . . . . . . . . . . . . . . . . . . . . . . Giansalvatore Mecca, Salvatore Raunich, Alessandro Pappalardo, and Donatello Santoro

496

Table of Contents

XV

WebRatio 5: An Eclipse-Based CASE Tool for Engineering Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Roberto Acerbis, Aldo Bongio, Marco Brambilla, and Stefano Butti

501

Extending Ruby on Rails for Semantic Web Applications . . . . . . . . . . . . . C´edric Mesnage and Eyal Oren

506

Personalized Faceted Navigation in the Semantic Web . . . . . . . . . . . . . . . . Michal Tvaroˇzek and M´ aria Bielikov´ a

511

WebVAT: Web Page Visualization and Analysis Tool . . . . . . . . . . . . . . . . . Yevgen Borodin, Jalal Mahmud, Asad Ahmed, and I.V. Ramakrishnan

516

Smart Tools to Support Meta-design Paradigm for Developing Web Based Business Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Athula Ginige, Xufeng Liang, Makis Marmaridis, Anupama Ginige, and Buddihma De Silva

521

Industrial Track Next-Generation Tactical-Situation-Assessment Technology (TSAT): Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Emily W. Medina, Sunny Fugate, LorRaine Duffy, Dennis Magsombol, Omar Amezcua, Gary Rogers, and Marion G. Ceruti Tool Support for Model Checking of Web Application Designs . . . . . . . . . Marco Brambilla, Jordi Cabot, and Nathalie Moreno Developing eBusiness Solutions with a Model Driven Approach: The Case of Acer EMEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Roberto Acerbis, Aldo Bongio, Marco Brambilla, Massimo Tisi, Stefano Ceri, and Emanuele Tosetti The Challenges of Application Service Hosting . . . . . . . . . . . . . . . . . . . . . . . Ike Nassi, Joydip Das, and Ming-Chien Shan

526

533

539

545

Doctoral Consortium Securing Code in Services Oriented Architecture . . . . . . . . . . . . . . . . . . . . . Emilio Rodriguez Priego and Francisco J. Garc´ıa

550

Service Level Agreements: Web Services and Security . . . . . . . . . . . . . . . . . Ganna Frankova

556

XVI

Table of Contents

Risk Management for Service-Oriented Systems . . . . . . . . . . . . . . . . . . . . . . Natallia Kokash

563

A Framework for Situational Web Methods Engineering . . . . . . . . . . . . . . . Sebastian Lahajnar

569

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

575

On Embedding Task Memory in Services Composition Frameworks Rosanna Bova1, Hye-Young Paik2, Salima Hassas3, Salima Benbernou1, and Boualem Benatallah2 1

LIRIS, University Lyon 1, France {rosanna.bova, salima.benbernou}@liris.cnrs.fr 2 CSE, University of New South Wales, Australia {hpaik, boualem}@cse.unsw.edu.a 3 LIESP, University Lyon 1, France [email protected]

Abstract. With the increasing availability of Web services and adoption of services oriented paradigm, there is a growing need to dynamically compose services for realizing complex user tasks. While service composition is itself an important problem, a key issue is also how to support users in selecting the most appropriate compositions of services to fulfill a task. In existing dynamic services selection approaches, combinations of services are repeatedly discovered (e.g., using ontology-based matching techniques) and selected by users whenever needed. To improve their effectiveness, we propose a new technique that provides an efficient access to what is named a “task memory”. A task memory is used to provide users with a context-aware service selection by recommending combinations of services that are most appropriate in a given context. A task memory is formed using the service composition history and their metadata. We present an incremental approach for building the task memory in which we monitor how users use and rank the services. The continuous updates of the task memory over time will result in more fine-tuned recommendations for composite services. Keywords: composite web services reuse, context-aware composite web services selection, service oriented architecture.

1 Introduction Advances in service oriented computing and semantic web technologies provide foundations to enable automated services selection and aggregation [1]. Coupled with other advances in communication technologies, these foundations constitute the pillars of a new computing paradigm in which users and services establish on-demand interactions, possibly in real-time, to realize useful experiences. This paradigm offers effective automation opportunities in a variety of application domains including personal information management, office tasks, travel, healthcare, and e-government. For example, a driver might use location, travel route computation, traffic information, and road conditions services to get timely information regarding a trip in progress. L. Baresi, P. Fraternali, and G.-J. Houben (Eds.): ICWE 2007, LNCS 4607, pp. 1–16, 2007. © Springer-Verlag Berlin Heidelberg 2007

2

R. Bova et al.

Business travelers can cope with schedule changes by seamlessly combining services to find and book hotels, search and book nearby rental cars, change flight reservations, modify meeting schedules and notify attendees [2]. A key issue to facilitate seamless and efficient composition of services is providing appropriate support for services selection. This is especially important in environments where there may be large number of services offering similar functionality [3]. Services discovery and composition are very active area of research and standardization. Efforts in these areas focused mainly on designing languages for process-based services composition (e.g., BPEL), designing rich and machine understandable representations of service properties, capabilities, and behavior, as well as reasoning mechanisms to select and aggregate services (e.g., OWL-S and services matching techniques) [4]. Main stream services discovery and selection approaches typically rely on descriptions matching techniques (e.g., whether descriptions of services and requests are compatible). Descriptions refer to meta-data such as service capabilities and non-functional properties (e.g., quality of service properties) [3]. It should be noted that, in a description-based matching approach, identifying that a service has a capability to answer a user request, does not mean that the service will be selected by the user. For example, not all travel services offer airfares from Lyon to Sydney. Other approaches improve the effectiveness of description-based approaches by considering also content-based matching (e.g., using content summary [5] or using service probing [6]). Although existing techniques have produced promising results that are certainly useful, more advanced techniques that cater for context (e.g., user location, computer environment), specially in large and dynamic environments, are necessary. This will relieve users from repeating the same selection refinement process to deal with a potentially large number of relevant services returned by a matching system every time they need to perform an activity. We observe that, while performing routine tasks, there is valuable knowledge being exposed to the service matching and selection component of a service infrastructure, that is, the information about the contexts in which a certain combination services were considered most appropriate by users. This information can be helpful in terms of reuse because users would select similar services in similar contexts (e.g., repetitive, regular tasks). Unfortunately, this information is not effectively captured and utilized in existing service matching and selection approaches. In this paper, we present an approach that leverages and seamlessly extends existing service matching and selecting techniques to cater for context-aware services selection by utilizing the knowledge on past experience. More precisely, we make the following contributions: 1. We introduce a notion of task memories that effectively represent the knowledge about service selection and contexts. We use task memories during services selection to suggest most relevant candidate services. 2. We use incremental acquisition techniques to build and update task memory. By applying continuous feedback and monitoring of ongoing usage of services, the system is able to maintain and evolve the task memory. Keeping the task memory up-to-date should result in more fine-tuned services selection. 3. We propose a multi-agent architecture; called, WS-Advisor, that seamlessly extends existing service matching and service selection techniques. The interactions among

On Embedding Task Memory in Services Composition Frameworks

3

the agents are well coordinated to cater for a comprehensive service provisioning environment which supports effective capturing and utilization of user knowledge during service matching and selection.

2 WS-Advisor: Design Overview The proposed architecture builds on existing services matching, selection, and composition frameworks. This is to take advantage of the already known techniques [7], [8], but, more importantly, to strengthen the notion of reuse in the frameworks. We propose that using incrementally acquired knowledge about service capabilities and their usage history during service matching and selection will help promote effective adoption of reuse. The added value of this extension is making the system (named WS-Advisor) capable of providing context-aware and adaptive service provisioning in dynamic environments. Context Provider

Context Provider

Context Provider

Contexts

Context Agent RetrievalContext

Stores Temporary Tasks Temporary Tasks Repository

Entry New Tasks Memory

Tasks Memory Repository

Memory Builder Agent Update Task Memory

Send Events for Update TM

Interact

User Agent User Recommend Task Memory

Query for Tasks Memory

Adviser Agent

Fig. 1. Overview of WS-Advisor architecture

The main proposition of WS-Advisor is to offer effective recommendations on “best-fit” services during the process of service selection. The architecture as a whole relies on the notion of building, maintaining and querying a service usage history. By continuously monitoring which services are used in which context and how users rate the services after execution, WS-Advisor can build up extensible knowledge about a history of service usage. The knowledge is stored in the form of task memories, which are then queried during the selection of services to draw recommendations which are based on past experience (i.e., the best candidate services that performed well for the given task and context). In summary, WS-Advisor has two core functions, namely: (i) constructing task memories, and (ii) using task memories to recommend “best-fit” services based on the past experience. It is noted that WS-Advisor is based on a multi-agent architecture. Figure 1 shows the agents involved in the system, namely: user agent, adviser agent, task memory builder agent and context agent. These agents use their internal knowledge and

4

R. Bova et al.

policies to perform their functions. They interact pro actively to collect information for building the task memories and adapt continuously to provide effective service selection in dynamic environments. In the following, we introduce each agent. User Agent (UA). There are two types of users in WS-Advisor: administrators and end users. An administrator interacts with a user agent to manage tasks (i.e., create, update or delete). For an end user, a user agent acts like a proxy, performing various actions on behalf of the user. A user agent maintains a folder of tasks (e.g., travel booking, organizing a board meeting). The user can browse, select, and execute the tasks. When a task is chosen, the user agent performs the following automatic actions: (i) it contacts a context agent (see below) to retrieve context information, (ii) after obtaining the necessary contexts, it asks the adviser agent to recommend the services suitable for the chosen task. These recommendations are passed back to the user agent who makes the final decision on which services to run, (iii) when the services are finally chosen, the user agent interacts with a service orchestration engine (e.g., BPEL execution engine) to execute the task by invoking the involved services and orchestrating their interactions. Adviser Agent (AA). A recommendation request from the user agent includes task attributes (e.g., departure date and destination city for a travel booking task) and context (e.g., current time and location) attributes. The knowledge that the adviser agent uses for recommendation is encoded in task memories. Briefly stated, a task memory consists of tuples, each tuple containing a combination of services, the contexts in which the services were selected and executed, a score indicating how “successful” the execution was. More detailed description of task memories and the scores will be given in the later sections. Builder Agent (BA). This agent is responsible for incremental knowledge acquisition in the task memories. It interacts with the user agent to gather service usage history (e.g., which services were recommended in which contexts, which of the recommended services were eventually chosen to be executed in the end, etc). It also continuously monitors and collects information about how the users rank the service performance after a task is completed and carry out updates in the task memories accordingly. We will discuss this agent in details in the later sections. Context Agent (CA). The context agent collects an assortment of contexts from context providers and disseminates the information to the user agent. A context may refer to a user context (e.g., preferences, location, timezone), an environment context (e.g., hardware and software characteristics of the user’s devices). We assume that a context providing service, such as the one implemented in [9], [10], exists and it will generate the context attributes and value pairs.

3 User Agent In this section, we describe the concepts that are important, namely, service and context ontologies; tasks, to explain the activities performed by a user agent during task provisioning.

On Embedding Task Memory in Services Composition Frameworks

5

3.1 Concepts and Definitions Service Ontology. Briefly stated, the service ontology provides a description (e.g., domain, properties and capabilities) of potential services that could be used to execute specific activities. A service ontology can be described using an ontology description language such as OWL-S. In our approach, the service ontology is described by a name that represents the domain of services and a set of service categories. A service category is specified by a set of attributes and a set of operations. An attribute describes a service property and is described by its name and type. An operation describes a service behavior and is described by its name and signature (i.e, input and output parameters of the service). Categories within a service ontology can be related by specialization and generalization relationships. In this paper, we assume that service ontologies are available and accessible for instance from registries (e.g. UDDI registries). For example, in Figure 2, the domain Travel has a category Transportation, which is described using attributes origin, destination and price, etc., and this category has three sub-categories. A service provider advertises a service by specifying which ontology the service is complaint to and the service categories that are supported by the service. Let us assume that the service Alitalia offers a range of flight information. The service may register itself with the Transportation ontology and advertise that it supports all operations in the category Flight as well as all attributes inherited from the categories AirTransport and Transportation.

Fig. 2. An example of Service Ontology: “Travel Service Ontology”

Context Ontology. Various definitions exist in the literature for the notion context [11], [12]. For the purpose of our work, a context represents environmental or circumstantial factors that are relevant to effectively selecting services to perform a given task. We use a simple context ontology that consists of a set of context classes. Each class represents a specific aspect of task context (e.g., Spatio-Temporal context,

6

R. Bova et al.

Computing Environment context, ConditionalEnvironment context, User context etc). These are generic classes in the sense that they are used to describe context of any task. Each class is described by a set of attributes representing specific state of the task environment. For instance, the class Hardware that is a sub-class of ComputingEnvironment contains the attributes: memoryFree, cpuUsage, storage and network and etc. It should be noted that, although the adopted context ontology has a limited number of context classes (for the sake of illustration), it is extensible: new classes can be added without fundamentally altering the service selection techniques built on top of this ontology. Task Definition. A task in WS-Advisor represents a set of coordinated activities that realize recurrent needs (i.e. a process that orchestrates the execution a number of individual activities). For example, a user may define a business travel task or a driving planning task. The business travel task may include activities such as hotel booking, car rental, flight reservation, meeting scheduling and attendee’s notification. A driving planning task may include activities such as gathering traffic and road conditions and producing an optimum driving route. An activity can be one of three types: (i) an elementary task that refers to an operation of an actual service, (ii) an elementary task that refers to an operation defined in a service ontology, or (iii) a sub-task (i.e., a task consists of other tasks). The user agent provides support for defining new tasks and a repository for storing them. Tasks are, for example, defined by an administrator based on common patterns in recurring processes. A task is described in terms of services ontologies and is represented using state charts [7]. The choice of such notation is motivated by the fact that state charts offer main constructs that are needed to define typical user tasks such as sequence of activities, branching, and parallel activities. In addition, to their expressive power, well-defined semantics, state charts can also be translated to executable processes such BPEL. It should be noted however, that any other task modeling notation such as petri nets could be used to define tasks in our approach. In a nutshell, a state chart representing a user task consists of states and transitions. A state can be basic, or composite. Each basic state is labeled with an execution of activity that refers to: − An invocation of a concrete service operation in case the service is deemed relevant the corresponding activity whenever the task is performed. This means that, the binding of an activity to a service operation is done at task definition time. − An invocation of operation defined in a category of a service ontology. The binding of this operation to an operation of a concrete service of the corresponding ontology is done at run-time. In this case, an activity represents a request for a service instead of an invocation of a service. Since, activities describing a user task are labeled with requests for services, concrete Web services belonging to the required service ontologies are selected during the execution of the composite task. Hence, it is possible to execute tasks in different ways by allocating different Web services to execute component activities in the task. A composite state allows the nesting sub-tasks (represented as state-charts) inside a parent task. Transitions represent dependencies among the activities of a task (e.g., a

On Embedding Task Memory in Services Composition Frameworks

7

transition may represent that an activity a1 should be executed after an activity a2 or a1 and a2 should be executed in parallel). A simplified state chart diagram specifying a “Travel Planner” task is depicted in figure 3. In this task, a search is performed to find a flight reservation service. After that, if the flight reservation is successful, an AND state follows, in which a search hotel booking service is performed in parallel with an invocation of a car rental service, and finally a search for an entertainment is performed. Note that states BookFlight and BookHotel are labeled with requests for services whereas the state RentCar is labeled with an invocation to an actual service (called “Avis”). The latter invocation style is useful when the service to use for executing specific task is the preferred (e.g., Avis is the preferred car rental service in the country of destination by the user of the task).

Fig. 3. State chart of the “Travel Planner”

Annotating Tasks with Context Information. To cater for context-aware service selection, in addition to the activities and their dependencies, a task definition includes context attributes from the context ontology. The administrator associates each task with its relevant contexts (e.g., for a travel booking task, the user's timezone, local currency, type of Web browser, may be relevant). Therefore, when a user chooses a task to perform, the user agent is able to determine the contexts associated with the task and contacts the context agent to retrieve the values of each context attribute. For example, in the “Travel Planner” task, the administrator may choose the following relevant context attributes: − for the state BookFlight, the attributes preferences of the context class User and time and location of the context class Spatio-Temporal. This may be needed because the user may have some preferences in the choice of airline company and this choice depends from time and location of this user; − for the state HotelBooking, the attribute noise of the context class ConditionalEnvironment. This may be needed because the user may want, for example, a room with low noise level. 3.2 Provisioning Task At a usage phase, a user chooses a task to perform from task repository (a repository maintained by the user agent). The user configures the required information to execute the task. In other words, user needs to specify a query that will be used by the system to select services to execute activities of the task. A user query is expressed in terms of attributes of service ontologies associated with the task. To simplify the

8

R. Bova et al.

process of expressing queries, each task is associated with task service schema (service schema for short). Given a task definition, a service schema describes the attributes that can be seen as a global schema for selecting the services to execute such tasks. The attributes of such service schema are derived from the attributes, inputs and outputs of operations referenced in that task definition. In addition, since our approach caters for task context, a query is expanded by the user agent to specify the current context. The user agent interacts with the context agent to get the values of context attributes that are relevant to a given task. Example. Assume, that the schema of the task shown in Figure 3 contains: (i) the context attributes preferences, time, location, temperature, (ii) the service attributes origin, destination, departureDate, returnDate, specialService, numberOfFlight, price, location, star, hasRestaurant, period. The user agent retrieves the values of the context agent from the context agent. For instance, the result of querying of the context agent can be: (preferences = “Austrian Airlines”, time = “8:30 AM CET”, location = “Lyon”, noise = “no”, temperature = “25°C”). After that, the user fills the value of service attributes if desired and the input/output of operations. For instance the user query in this case can be: (origin = “Lyon”, destination = “Sydney”, departureDate = “02/01/2007”, returnDate = “04/03/2007”, specialService = “seat far to window”, numberOfFlight = “OS 402”, price “1000,00€€ ”, location = “Randwick”, star = “2”, hasRestaurant = “no”, period = “03/01/2007 – 03/03/2007”).

4 Adviser Agent The core idea of our services selection approach is to recommend combinations of services that are most appropriate to meet the user's needs in given contexts. The recommendations are based on the past execution history of a task (i.e., task memories). In this section, we define the notion of task memories and discuss how the adviser agent makes service selection recommendations. The issue of building a task memory will be discussed in the next section when we discuss the memory builder agent. 4.1 Task Memory A task memory is associated with a specific task and it captures the information about the contexts and combinations of services that have been successfully used in the past to execute the task. It is a kind of a dynamic folder that associates contexts to combinations of services. Dynamic, here, means that the contexts and the combinations of services may evolve over time. In this way, service selection is not only based on the description or content of services but also on how likely they will be relevant in a given context. We represent a task memory as a table that has two attributes, namely, context summary, and recommendations. Context Summary. Briefly stated, a context summary is a query representing a context that is considered by the system (or a system administrator) as relevant for selecting a combination of services to execute a task. It is specified using a conjunctive query of

On Embedding Task Memory in Services Composition Frameworks

9

atomic comparisons involving context attributes, service attributes, service operation inputs/outputs, and constants. The second column of the table 1 shows examples of context summary queries. While context summaries could be defined using sophisticated query languages such as XQuery or Xpath, without loss of generality, we choose to use a simplified representation model in terms of attribute/value comparisons for clarity of presentation. The concept of context summary allows capturing a set of possibly relevant contexts to effectively select services instead of encoding all possible service selection queries which may incur high performance cost. In other word, the notion of context summary allows the adviser agent to maintain a partial, concise and effective index of service selection queries. Table 1. An example of task memory table ID CSQ1

CSQ origin = ‘Lyon’ ^ destination = ‘Sydney’ ^ 100 < p < 250

Combination_GA {[(Quantas, Hilton), 0.6], (Quantas, Paradise), 0.4]}

CSQ2

origin = ‘Lyon’ ^ destination = ‘Hong Kong’ ^ 100 < p < 250

{[(VolareWeb, Paradise), 0.7], (Alitalia, Paradise), 0.75]}

CSQ3

origin = ‘Milan’ ^ destination = ‘Sydney’ ^ 300 < p < 500

{[(Alitalia, Hilton), 0.8], (Alitalia, Paradise), 0.65]}

We assume that an administrator can identify a set of context summary queries that are relevant to a give task. This can be done by identifying a subset of attributes of the task schema that can be used to specify context summary queries. For each of these attributes, ranges of values are formed by dividing the domain of the attribute into a set of non-overlapping ranges known as Attribute Value Groups (AVGs). For nominal attributes, an AVG contains one or more distinct nominal values; for continuous attributes, an AVG specifies values range [5]. The union of AVGs of attribute is equivalent to the domain of the attribute. The Context Summary Queries (CSQs) are generated based on a cartesian product of these values. Table 2 lists examples of AVGs, assuming origin, destination, price, star, memoryFree and temperature are selected as summary attributes for the task “Travel Planner”. The AVGs can be either manually defined by an administrator or discovered from query logs using query or context discovery techniques such as those presented in [13]. Once summary attributes are selected and AVGs are defined, the context summary queries are fixed. Table 2. Example AVGs of summary attributes Attribute Origin Destination Price Star Temperature (°C)

AVGs ‘Lyon’, ‘Milan ‘Sydney’, ‘Hong Kong’ 100 < p = 0) most preferred combinations of services to execute a given task. Each services combination is associated with a positive weight value, called Global Affinity

10

R. Bova et al.

(GA), exceeding a predefined threshold (parameter sets by a system administrator, for example). A task memory is represented by a table that as three columns: ID (identifier of context summary query), CQS (Context Summary Query), Combination_GA (combinations of services with their associate Gas). For instance, the column Combination_GA of Table 1 shows examples of service combinations and their associated GAs. The global affinity of a services combination measures the relevance of this combination to perform a task in a given context. More precisely, this value represents a weighted average of the values that measure the level of satisfaction of users, about a services combination, which respect to all the possible combinations in the that have been selected in that context. A more detailed description the notion of global affinity and its computation is given in [14]. 4.2 Making Services Selection Recommendation During services selection, in a response to a query from the UA, the AA identifies the potential combinations of services having answers to the query. The AA provides an operation called recommendCombinations(), that takes as input a selection query and returns a set of service combinations that can be potentially used to executed the corresponding task. The AA matches the user query against context summary queries of the corresponding task memory. The matching process relies on subsumption (containment) or equivalence between a user query and context summaries queries. If no combination is found to be appropriate based on the task memory, the AA forwards the query to a matching service engine to discover new possible combinations of services. For instance, the query Q: (category = “TravelToSydney”, attributes: origin, destination, price and values: origin = “not defined”, destination = Sydney, price = 150€€ ) may not pass through the context filter of CSQ3 as the price is not included in its range. Hence any service associated to CQ2 is selected to answer to query Q, but CSQ1 can be used recommended to user.

5 Task Memory Builder Agent The task of building a task memory is to associate context summary queries to combinations of services. This process is facilitated by a task memory builder agent (or simply builder agent). The Builder Agent (BA) is responsible for the incremental acquisition and to update of the elements the task memory table. Instead of asking an administrator to populate and update the task memory table, this agent incrementally captures the combinations of services that should be associated to context summary queries, by continuously monitoring how users use and rank services through interactions with the user agent. This agent has access to operational knowledge such as service usage patterns as well as means for analyzing such patterns and updating task memories. There can be two approaches to build a task memory. − A lazy approach consists to consider that the builder agent incrementally update a task memory starting from an initial table (e.g., an empty or a manually crafted table), during the service selection process. In this approach the builder agent

On Embedding Task Memory in Services Composition Frameworks

11

maintains a usage table that consists of context summary queries and their associated service combinations. The usage table contains only combinations that have been used at least once with satisfaction. Every time that a combination is used with satisfaction (respectively dissatisfaction) the associated global affinity will be upgraded (respectively, degraded). − An eager approach that consists to periodically search for services usage patterns by calculating the global affinities of previously selected service combinations. This can be achieved for instance by a logging facility associated with the builder agent. The agent logs events related to services selection. The logged information could be analyzed in real-time (during services selection phase) or periodically to identify patterns that help updating the task memory. Then, each pattern is associated to a task memory update operation (e.g., adding a new combination of services). More specifically, in the current architecture, the builder agent relies on the following building blocks to incrementally construct selection policies: − Logging service selection events. Table 3 summarizes basic events that are logged by the builder agent. Over time, these events are used as a basis to identify service usage patterns (e.g., identify that a combination of services needs to associate to a given context because the number of times this combination was selected with satisfaction is greater than a given threshold). − Task memory table update operations. Table 4 summarized main task memory update operations. The evolution of a task memory table is realized through update operations. − Task memory table update rules. Table 5 summarizes the main update operations supported in our framework. Operations to perform for updating a task memory table as a result of the occurrence certain service usage pattern are captured using Pattern Action where Pattern is a condition over service selection events, and Action is a table update operation. More precisely, a condition of a rule is a sequence over service selection events. A rule is defined for each update operation. In the lazy update strategy, whenever a combination is selected, the builder agent checks if an update rule can be triggered (i.e, checks if the associated event pattern is true, and eventually performs the rule action if true). In the eager strategy, the agent relies on a pre-defined rule triggering policy (e.g, specified by an administrator). For instance a triggering policy may say “analyze the logged events periodically (e.g, each 2 days) to detect the occurrence of event patterns” or “whenever the task Table 3. Selected events supported in WS-Advisor Events services_selected (cs, cqs) services_used (cs, cqs)

services_discarded used (cs, cqs)

Descriptions The combination of services cs is selected by the AA as a relevant candidate in a context identified by context query summary cqs The combination of services cs was selected by the AA as a relevant candidate and used with satisfaction by the user in context identified by context query summary cqs The combination of services cs is selected by the AA as a relevant candidate but discarded by the user in context identified by context query summary cqs

12

R. Bova et al. Table 4. Selected operations supported in WS-Advisor

Operations Upgrade_Score (cs, cqs) Downgrade_Score (cs, cqs) Add_combination (cs, cqs) Remove_Combination (cs, cqs)

Description The GA of combination cs is upgraded with regard to context query summary cqs The GA of the combination cs with regard to context query summary cqs A new combination cs is added and its score is initialized with regard to context query summary cqs A combination cs is removed with regard to context query summary cqs

Table 5. Selected rules supported in WS-Advisor Rules Upgrade_Score_Rule (cs, cqs) Downgrade_Score_Rule (cs, cqs) Add_Combination (cs, cqs) Remove_Combination (cs, cqs)

Pattern .

Action Upgrade_Score (cs, cqs) Downgrade_Score (cs, cqs) Add_combination (cs, cqs) Remove_Combination (cs, cqs)

memory becomes a bottleneck.” Note that a task memory might become a bottleneck when the AA forwards the user query to a service matching engine frequently as the user is never happy with the recommendations of the AA or the agent does not find any relevant services combination.

6 WS-Advisor: Implementation Architecture We adopt a layered architecture for the implementation of the whole WS-Advisor system. Figure 4 shows the elements of this architecture which are grouped into two layers: the agents layer and the infrastructure services layer. The agent layer consists of services implementing the user, adviser, builder, and context agents. The implementation of the agents is based on Java (using JADE platform), XML, and some generic services provider by the infrastructure layer of the architecture. In other words, all the agents are implemented as Java classes. The infrastructure services layer consists of generic services that we reuse from existing Web services environments to implement specific functionalities of the agents proposed in our approach. The user agent provides a GUI to assist administrators in the creation and maintenance of tasks. It provides an editor for describing a statechart of a task. The editing process consists of annotating states of a task with services descriptions based on services ontologies. In addition, a task is also associated to a number of context attributes from the Context ontology. After the editing process, the user agent generates an XML file that represents a BPEL skeleton (a parametric process where invocations refer to service definitions instead of concrete services). The implementation of the task editor and the generation of BPEL process skeleton rely on the state-charts editor and BPEL process generation components of the Self-Serv Prototype [7]. The user agent also provides a GUI to assist users in browsing tasks, selecting services, and

On Embedding Task Memory in Services Composition Frameworks

13

execute tasks. It invokes the adviser agent to select services for executing a task. Once services are selected the user agent generates a BPEL executable process from the BPEL skeleton of the task and invokes a BPEL engine (ActiveBPEL) [15] to perform the execution of a task. The user agent provides means to inform the builder agent about the selected services. The adviser agent provides methods for querying a Task Memory which represented as XML file. It also provides methods to query the service discovery engine. The service discovery engine facilitates the location Web services from external service registries. The implementation of this component relies on the services matching component of the WS-CatalogNet prototype [8]. The builder agent provides methods receiving notifications from the user agent, registering event patterns to the event monitoring service, and triggering actions for updating the task memory file. The event monitoring service is used for tracking and monitoring service usage and relies on the event management component of the WS-CatalogNet prototype. The context agent provides a method for querying context information. The implementation of this agent is a work in progress and will rely on the context service implemented in the PCAP prototype [7] which is an extension of Self-Serv to cater for context awareness in service oriented architectures. Submit Query/ Display Result User Interface

User Agent Context Agent Task Repository Uses Service & Context Onto

Event Service BPEL Engine Adviser Agent Monitor/ Update

Uses

BPEL Generator

Task Memory State Chart Editor Task Memory Builder Agent Monitor

Service Discovery Engine

Service Usage Report Context Service

Fig. 4. WS-Advisor: Implementation Architecure

7 Discussion and Conclusions A large body of research exists in the general area of web services discovery, selection, and composition. For example, early approaches based on the UDDI standard

14

R. Bova et al.

provide limited services search facilities, supporting only keyword-based search of businesses, services, category names, and service identifiers [16]. To cope with this limitation, other approaches based on semantic web technology, and in particular web ontology languages such OWL-S, to support service description and discovery emerged. Main stream approaches in this area focus on description-based matchmaking techniques based on subsumption and equivalence relationships [17]. As pointed out before, other approaches leverage content summarization techniques to improve the accuracy of description-based services selection and matching approaches. It should be also noted that the problem of description based matching has also been addressed by several other research communities, e.g., federated databases, information retrieval, software reuse systems and multi-agent communities. More details about these approaches and their applicability in the context of the semantic Web services area can be found in [18] and in [19]. Our work is also related to the general area of recommender systems, especially those based on multi-agents. (e.g., Amalthea [20], SAGE [21]). These efforts focused on analyzing documents (e.g., web pages, email folders) to recommend relevant documents as in search engines or products as e-commerce systems. Efforts in this area build upon personalization techniques in Web applications including content-based, collaborative and rule-based filtering [22]. Other agent-based approaches catered for context awareness in the orchestration of interactions among components of a composite service [23]. Our work is complementary to efforts in user context modelling [10, 24, 25]. We focus on capturing task memories to allow effective services selection. Our approach features embedding intelligence, consisting of task memories, into services composition frameworks allowing context-aware services selection. It builds upon ontology support as in web services, services discovery, selection and composition to develop a context-aware services recommender facility during execution of routine tasks. This approach is based on the observation that, in performing routine tasks, the service matching and selection component of service infrastructure may produce valuable information on the contexts in which combinations of services where considered most appropriate by users. This information can be helpful to users in selecting services to perform a task because sometimes users would select similar services in similar contexts. Unfortunately, this information, which we call task memory in our framework, is not effectively captured in existing service matching and selection approaches. We use task memory during services selection to suggest most relevant candidate services. We proposed to use incremental acquisition techniques to build and update task memory. A task is associated to an agent that monitors how users use and rank services. We believe that the proposed approach is an essential ingredient that will work in a tandem with services discovery and selection cooperative service techniques to provide more personalized and context-aware selection of services. Ongoing work consists of extending the agent-based architecture presented in this paper to cater for collaboration among different users via social networks to share task memories. Our future work will focus on experimenting with the proposed approach using some case studies to test its validity in real settings. More specifically, we will investigate the validity of the assumptions and approaches related to context summary queries acquisition and global affinity computation. We also plan to investigate the use of incremental knowledge acquisition techniques as means to learn context summary queries.

On Embedding Task Memory in Services Composition Frameworks

15

References 1. Huhns, M.N., Singh, M.P.: Service-Oriented Computing: Key Concepts and Principles. IEEE Internet Computing 9, 75–81 (2005) 2. Teevan, J., Jones, W., Bederson, B., B.: Special issue on Personal information management, vol. 49 (2006) 3. Zeng, L., Benatallah, B., Ngu, A., Dumas, M., Kalagnanam, J., Chang, H.: QoS-Aware Middleware for Web Services Composition. IEEE Trans. Software Eng., 30, 311–327 (2004) 4. Medjahed, B., Bouguettaya, A.: A Dynamic Foundational Architecture for Semantic Web Services. Distributed and Parallel Databases 17, 179–206 (2005) 5. Sun, A., Benatallah, B., Hassan, M., Hacid, M.S.: Querying E-Catalogs Using Content Summaries. In: Cooperative Information System (2006) 6. Caverlee, J., Liu, L., Rocco, D.: Discovering and ranking web services with BASIL: a personalized approach with biased focus. ICSOC, pp. 153–162 (2004) 7. Sheng, Z., Benatallah, B., Dumas, M., E., O.Y.: SELF-SERV: A Platform for Rapid Composition of Web Services in a Peer-to-Peer Environment. In: Proc. of the 28th International Conference on Very Large Databases. Hong Kong, China. September (2002) 8. Baina, K., Benatallah, B., Paik, H., Rey, C., Toumani, F.: WS-CatalogNet: An Infrastructure for Creating, Peering, and Querying e-Catalog Communities. In: Proc. of the 30th International Conference on Very Large Databases. Toronto, Canada (2004) 9. Sheng, Q.: CompositeWeb Services Provisioning in Dynamic Environments. PhD thesis, School of Computer Science, University of New South Wales, Sydney, Australia (2005) 10. Dey, A. K.: Providing Architectural Support for Building Context-Aware Applications. PhD thesis, College of Computing, Georgia Institute of Technology (2000) 11. Lei, H.: Context Awareness: a Practitioner’s Perspective. In: IEEE International Workshop on Ubiquitous Data Management (UDM 2005), in conjunction with ICDE 2005, Tokyo, Japan, April (invited paper, 2005) 12. Dey, A.K., Abowd, G.D.: Towards a Better Understanding of Context and ContextAwareness. Technical Report GIT-GVU-99-22, GVU Center, Georgia Institute of Technology, June (1999) 13. Chakrabarti, K., Chaudhuri, S., Hwang, W., S.: Automatic categorization of query results. In: Proc. of ACM SIGMOD’04, Paris, France, June, pp. 755–766 (2004) 14. Bova, R., Hassas, S., Benbernou, S.: An Immune System-Inspired Approach for Composite Web Service Reuse. In: Int. Workshop of ECAI06 Artificial Intelligence for Service Composition. Riva del Garda, Trento, Italy (2006) 15. ActiveBPEL Engine http://www.activebpel.org/ 16. Dustdar, S., Treiber, M.: A View Based Analysis on Web service Registries. In: Distributed and Parallel Databases, Springer, Heidelberg (2006) 17. Benatallah, B., Hacid, M., Leger, A., Rey, C., Toumani, F.: On automating Web services discovery. VLDB J. 14, 84–96 (2005) 18. Paolucci, M., Kawamura, T., Payne, T., R., Sycara, K., P.: Semantic Matching of Web Services Capabilities. In: International Semantic Web Conference, pp. 333–347 (2002) 19. Bernstein, A., Klein, M.: Towards High-Precision Service Retrieval. In: International Semantic Web Conference, pp. 84-101 (2002) 20. Moukas, A., Maes, P.: Amalthea: An Evolving Multi-Agent Information Filtering and Discovery System for the WWW. Journal of Autonomous Agents and Multi-Agent Systems 1(1), 59–88 (1998)

16

R. Bova et al.

21. Blake, M.B., Kahan, D., R., Nowlan, M., F.: Context-aware agents for user-oriented web services discovery and execution. In: Distributed and Parallel Databases, Springer, Heidelberg (2006) 22. Paik, H.: Community-Based Integration Adaptation of Electronic Catalogs. PhD thesis, School of Computer Science, University of New South Wales, Sydney, Australia (2004) 23. Maamar, Z., Mostefaoui, S., M., Yahyaoui, H.: Toward an Agent-Based and ContextOriented Approach for Web Services Composition. In: IEEE Transactions on Knowledge and Data Engineering (2005) 24. Jovanovic, J., Knight, C., Gasevic, D., Richards G.: Learning Object Context on the Semantic Web. In: Sixth IEEE International Conference on Advanced Learning Technologies (ICALT’06). Netherlands. July 5-7 (2006) 25. McCalla, G.: The Ecological Approach to the Design of E-Learning Environments: Purpose-based Capture and Use of Information About Learners. Journal of Interactive Media in Education (2004)

A QoS Test-Bed Generator for Web Services Antonia Bertolino, Guglielmo De Angelis, and Andrea Polini Istituto di Scienza e Tecnologie dell’Informazione - CNR Via Moruzzi 1, 56124 Pisa - Italy {antonia.bertolino, guglielmo.deangelis, andrea.polini}@isti.cnr.it

Abstract. In the last years both industry and academia have shown a great interest in ensuring consistent cooperation for business-critical services, with contractually agreed levels of Quality of Service. Service Level Agreement specifications as well as techniques for their evaluation are nowadays irremissible assets. This paper presents Puppet (Pick UP Performance Evaluation Test-bed), an approach and a tool for the automatic generation of test-beds to empirically evaluate the QoS features of a Web Service under development. Specifically, the generation exploits the information about the coordinating scenario (be it choreography or orchestration), the service description (WSDL) and the specification of the agreements (WS-Agreement).

1 Introduction The attractive promise of the Service Oriented Architecture (SOA) paradigm is to enable the dynamic integration between applications belonging to different enterprises and globally distributed across heterogeneous networks. Within the SOA paradigm, the most concrete technology is today realized by the Web Services (WSs). Although WSs constitute a quite new drift in software application development, research in this technology has already evolved through a few stages. Initially the focus was in mechanisms which could allow for the loose interconnection among services independently developed and implemented on different machines. Such vision can only be achieved through the disciplined usage of standard notations and protocols, and in fact the WS domain is characterized by a strong boost toward standardization. Thus key achievements at this stage have been the establishment of common service descriptions, the definition of open service directories for storing and retrieving such descriptions, and the enactment of dynamic discovering and binding mechanisms. The technology for basic WS interconnection is now well established, with WSDL, SOAP and UDDI being just the most representative elements. Nevertheless, the need soon arose of allowing for more complex scenarios, beyond simple point-to-point interactions [1]. The standardization of adequate mechanisms for services composition and interaction constituted thus the next stage, which is still very active. Two directions currently lead the scene within two different, but related, contexts [1]: the first aims at defining the composition of services (referred to as orchestration), the second at describing how related services should cooperate to perform a given L. Baresi, P. Fraternali, and G.-J. Houben (Eds.): ICWE 2007, LNCS 4607, pp. 17–31, 2007. c Springer-Verlag Berlin Heidelberg 2007 

18

A. Bertolino, G. De Angelis, and A. Polini

task (choreography). Both interpretations of service integration provide a means to describe interacting scenarios. On one side, orchestration approaches foresee the availability of an execution engine that, by executing the code defining the orchestration, reproduces the specified interactions; as a fact, this need limits the applicability of orchestration to those cases in which a governing organization is in charge for defining the business process. In contrast, the choreography approach foresees the availability of a specification of the interactions to which the various services must conform, but it does not introduce per se any mechanism for forcing such interactions. Currently, the most significant proposals concerning the specification of WS orchestration and choreography are represented by the Business Process Execution Language (WSBPEL) [18] and the Web Services Choreography Description Language (WS-CDL) [22], respectively. Eventually, the openness of the environment characterizing the SOA paradigm naturally led to the pursuit of mechanisms for specifying the provided levels of Quality of Service (QoS) and establishing an agreement on them, in line with the widely accepted idea that service delivery cannot just focus on functional aspects, and ignore QoS-related properties. Indeed, not only for Service Oriented systems, but for many other kinds of enterprise applications [6] [20], communication networks and embedded systems [4], solutions that do not put adequate consideration of non functional aspects [17] are no longer acceptable. Correspondingly, in recent years much research has been devoted to methodologies for QoS evaluation, including predictive and empirical techniques [13]. Predictive approaches are crucial during the design and the development of a software system, to shape the quality of the final product [20]: they perform analytical QoS evaluation, based on suitable models, such as Petri Nets or Queueing Networks. But increasingly modern applications are deployed over complex platforms (i.e., the middleware), which introduce many factors influencing the QoS and not always easy to model in advance. In such cases, empirical approaches, i.e., evaluating the QoS via run-time measurement, could help smoothing platform-dependent noise. However, such approaches require the development of expensive and time consuming prototypes [15], on which representative benchmarks of the system in operation can be run. In this last direction, however, when computer-processable specifications exist, and code-factories can be used to automatically generate a running prototype from a given specification, there is large room for the adoption of empirical approaches. In particular, and this is the position we take in this work, given the high availability of standardized computer processable information, WSs and related technologies [2,10,18,22,14] yield very promising opportunities for the application of empirical approaches to QoS evaluation. According to this intuition, in this paper we introduce an approach, called Puppet (Pick UP Performance Evaluation Test-bed), which realizes the automatic derivation of test-beds for evaluating the desired QoS characteristics for a service under development, before it is deployed. In particular, we are interested in assessing that a specific service implementation can afford the required level of QoS (e.g., latency and reliability) when playing one of the roles in a specified choreography or when used in composition with other services (orchestration). To this purpose, Puppet relies on the availability of the QoS specification of both the service under evaluation and the interacting services. Such

A QoS Test-Bed Generator for Web Services

19

assumption is in line with the increasing adoption of formal contracts to establish the mutual obligations among the involved parties and the guaranteed QoS parameters, which is referred to as the Service Level Agreement (SLA) for WSs. In the next section we provide a basic background on the emerging languages for the definition of SLAs. Then, in Sec. 3 we illustrate the general scenario in which the Puppet tool should be employed. Successively, in Sec. 4 we describe the approach and its logical architecture. An exploratory example is presented in Sec. 5 while related work is summed up in Sec. 6. In Sec. 7 we draw conclusions and hint at future work.

2 Specification of Service Level Agreements An important ingredient of the SOA paradigm is the QoS level agreement specifications among interacting services. Traditionally, agreements were expressed informally, not in machine-readable form. In software engineering quite basic notions of agreements were established by means of Interface Description Languages [17]. Concerning the WS technology, Service Level Agreements (SLAs) represent instead one of the most interesting and actively pursued issues. SLAs aim at ensuring a consistent cooperation for business-critical services. Relevant experiences in this direction are certainly represented by work around Web Service Level Agreement (WSLA) [14] or SLAng [19]. The approach introduced in this paper has been conceived to be as independent as possible of a specific SLA language. Indeed, concerning the goal of the work, any SLA languages predicating on the concepts we are considering are equivalent. However, when it comes to developing a specific implementation of our conceptual environment, we obviously need to consider a specific technology. Hence, in the remainder of the paper, we will focus on a proof-of-concept development carried on using the WS-Agreement language [10]. To make the paper self-contained, we report below the background notions behind its current proposal. WS-Agreement is a language defined by the Global Grid Forum (GGF) aiming at providing a standard layer to build agreement-driven SOAs. The main assets of the language concern the specification of domain-independent elements of a simple contracting process. Such generic definitions can be augmented with domain-specific concepts. As shown in Fig. 1, the top-level structure of a WS-Agreements offer is expressed by means of a XML document which comprises the agreement descriptive information, the context it refers to and the definition of the agreement items. The Context element is used to describe the involved parties and other aspects of an agreement not representing obligations of parties, such as its expiration date. An agreement can be defined for one or more contexts. The defined consensus or obligations of a party core in a WS-Agreement specification are expressed by means of Terms. Special elements (e.g., AND/OR/XOR operators) can be used to combine terms, via the specification of alternative branches or the nesting within the terms of agreement. The obligation terms are organized in two logical parts. The first specifies the involved services by means of the Service Description Terms. Such part primarily describes the functional aspects of a service that will be delivered under an agreement. A

20

A. Bertolino, G. De Angelis, and A. Polini xs:NCName wsag:AgreementContextType wsag:TermCompositorType

Fig. 1. WS–Agreement Structure

term for the service description is defined by means of its name, and the name of the service which it refers to. In some case, a domain-specific description of the service may be conditional to specific runtime constraints. A special kind of Service Description Terms is the Service Reference, which defines a pointer to a description of a service, rather than describing it explicitly into the agreement. The second part of the terms definition specifies measurable guarantees associated with the other terms in the agreement and that can be fulfilled or violated. A Guarantee Term definition consists of the obliged party (i.e, Service Consumer, Service Provider), the list of services this guarantee applies to (Service Scope), a boolean expression that defines under which condition the guarantee applies (Qualifying Condition), the actual assertion that have to be guaranteed over the service (Service Level Objective) and a set of business-related values (Business Value List) of the described agreement (i.e., importance, penalties, preferences). In general, the information contained into the fields of a Guarantee Term are expressed by means of domain-specific languages.

3 A WS Development and Evaluation Scenario As explained in the Introduction, initially WSs were intended for loose and basic interactions, but soon the need for mechanisms to describe more complex integration of services emerged. The basic assumption of our approach is that such a description indeed exists. This is not an unrealistic assumption, as the global definition of applications resulting from the dynamic integration of unrelated services is seen as one of the most relevant factors at the basis of the take-off of the Service Oriented paradigm. Our view1 is that the integration of services offers major guarantees, and will be fostered, by the existence of predefined choreographies and the definition of orchestration. Given a definition of the integration of different services, based on choreography or orchestration, our objective is to provide a tool to support the QoS evaluation of services to be integrated, but still under development. The scenario we envisage is depicted in Fig. 2. 1

This view is shared within the EU FP6 Strep n.26955 - PLASTIC, see at http://www.istplastic.org

A QoS Test-Bed Generator for Web Services

21

Fig. 2. The Puppet approach and supporting tool

The first step in this process, referred to as “1: WS Composition Definition” in Fig. 2, is indeed the specification of service integration, in terms of WS-CDL or WSBPEL, and of a set of WSDL descriptions defining the interfaces of the services involved in the interaction. The process continues with the annotation of the composition with QoS attributes for each service involved in the integration. In Fig. 2 this step is referred to as “2: QoS instrumentation”. For this step we distinguish between the case of a choreography and that of an orchestration. In the former case, the organization that released the specification of the composition is in charge of augmenting the specification with QoS attributes. Developers of services will take such a specification as a reference for their implementation, expecting that their required services do the same. As a consequence each developer of a service is interested in evaluating that it actually can provide the required service according to the specified QoS. If this is not true we can expect that no other service in the given choreography will agree on binding to such service. In the case of an orchestration, the derivation of QoS values for the services to be integrated is quite different. In this case the service that will be the subject of the validation is actually the orchestrated service. The developer company is interested in deriving a competitive service in terms of provided QoS. In this case the parameters for the QoS could not have been defined by someone else, i.e. a “standard” body as in the case of a choreography, but should be derived by the QoS defined by similar services possibly registered within a directory. Moreover in order to have a reliable picture of the final run-time environment the developer should also consider the QoS defined for the services that will be composed in the orchestration. Therefore retrieving from the directory

22

A. Bertolino, G. De Angelis, and A. Polini

service the QoS specification for similar services, and the QoS provided by the composed services it is possible to get a quite trustable picture of the run-time conditions for the case of orchestrating services. Summarizing, Puppet assumes the availability of a WSDL specification for each service, a definition of a composition in terms of WS-CDL or WSBPEL, and a WS-A description for the services in the composition/coordination. At this point, Puppet can automatically generate a test-bed to validate the implementation of a service before its deployment in the target environment (referred as “3: Test-bed Generator” in Fig. 2). The test-bed will consist of fake versions of the used services and of the possible clients. Such services are successively composed by the tester in order to reproduce different runt-time conditions for the service under evaluation, as discussed in the following. As illustrated in Fig. 2, step 3 consists of two different phases. The first one is the generation of the stubs simulating the non functional behavior of the services in the composition, and referred as “3.1: Stubs Generation” in Fig. 2. The second one, referred as “3.2: Service/Stubs Composition” in Fig. 2, foresees the composition of the implementation of a service, called “S1i” in Fig. 2, with the services with which it will interact. The next paragraphs provide a short introduction to both phases, that will be successively described in detail in Sec. 4. The generation of the stubs proceeds through two successive steps (not detailed in the figure). In the first one a skeleton of the stubs is generated starting from the WSDL description. At this time the generated skeletons contain no behavior. Hence, in the second step the implementation is “filled” with some behavior that by construction fulfills the required non functional properties, for the corresponding service. The necessary information is retrieved from the WS-A specification and used to apply automatic code transformation according to rules that we have defined and we describe in Sec.4. At the end of the “Stubs Generation” phase, a set of stubs providing the services specified in the composition according to the desired properties is available. In turn Puppet permits also to derive stubs simulating the behaviour of possible clients for the service under evaluation as “S2” in Fig.2. To generate such stubs Puppet considers the part of the WS-A document defining the constraints among the client and the service. Possible constraints can be for instance the number of invocations within a time frame, or a minimum time between successive invocations, and similar ones. The “Service/Stubs Composition” phase implements the final setting of the test-bed. Goal of this step is to derive a complete environment in which to test the service. To this purpose, Puppet composes the service under test, “S1i” in Fig. 2, with the required services and according to the composition specified in the choreography or in the orchestration. At the same time client stubs are composed, by the tester, to derive a meaningful workload for the service under evaluation. Currently this phase requires the assistance of a human agent, as illustrated by the presence of a stick man in Fig. 2, that has to hand-code the composition in the service stubs. Nevertheless we are working on further automatizing the process on the base of the forthcoming final WS-CDL specification and WS-BPEL specification. Concluding, the final product provided by the Puppet tool is an environment for the QoS validation of a composite service. The evaluation will require the development of a tester that integrates the client stubs generated by Puppet, in order to reproduce

A QoS Test-Bed Generator for Web Services

23

meaningful workloads. Such a tool will have to verify that the properties specified in the QoS document for the service under evaluation are fulfilled. In Fig. 2 also such a tool is shown, nevertheless how this component can be derived is not within the scope of our work and we refer to the literature on the argument [8] for possible approaches.

4 Description of the Approach The inspiring idea behind Puppet is that the technologies introduced within the WS infrastructure make it possible to automatically generate a test-bed environment for a service. The generated environment can then be used to test if the specified QoS properties (e.g. performance) will be respected by the service under development after its deployment in the final environment. Specifically, the generation exploits the information about the coordinating scenario (be it choreography or orchestration), the service description (WSDL) and the specification of the agreements that the involved roles will abide (see Sec. 3). Tools and techniques for the automatic generation of service skeletons, taking as input the WSDL descriptions, are already available and well known in the Web Services communities [2]. Nevertheless such tools only generate an empty implementation of a service and do not add any logic to the service operations. Puppet exploits and improve those solutions by processing the empty implementation of a service operation and augmenting it with fake code resulting from the appropriate transformation of the SLA specification. 4.1 Skeleton Generation Process In Puppet we automatically generate service stubs whose behaviors are derived from the terms defined in a WS-Agreement document. The UML Component Diagram in Fig. 3 outlines the architecture we propose. In the picture we directly refer to ApacheTomcat/Axis [2] as the technology used for the derivation of the various intermediate artifacts needed for the derivation and deployment of the generated services stub. Nevertheless, the approach is not bound to a particular technology and other solutions are possible: the only requirement is to identify the corresponding tools in the chosen platform with respect to Apache-Tomcat/Axis. Any Web Services platform provides in fact some WSDL compiler permitting to automatically derive the different harness needed both for the deployment of the service and for enabling service clients to invoke the published service operations [1]. More specifically, the generation of a QoS stub service simulator for the service S1 in Fig. 3 undergoes three main phases: service skeleton structure definition, QoS behavior generation, service stub deployment. The first step in the process is directly performed exploiting the Apache-Axis WSDL2Java utility [2]. Such tool, taking as input a WSDL description of a service, generates a collection of Java classes and interfaces according to the abstract part of the specification. Thus, for each binding a service skeleton structure will be automatically defined and released. At the same time the tool generates both a deployment and an undeployment descriptors. Such descriptors can be identified by the extension WSDD (Web Service Deployment Descriptor) [2]. The deployment specification represents the contact

24

A. Bertolino, G. De Angelis, and A. Polini Stubs Generation : Step 1 S1.WSDL

S1Package

Axis WSDL2Java

INPUT

Skeleton1.java

OUTPUT

Empty methods

SkeletonN.java

INPUT

INPUT

Stubs Generation: Step 2

wsaCodeBuilder

S1.WSDD

agreement.wsag

OUTPUT

Stubs Generation : Step 3 Axis Deployment Engine

S1Package Code Skeleton1.java

Methods with behavior SkeletonN.java

Fig. 3. Puppet Test-bed Generator Logical Architecture

point between the abstract definition of the service, expressed into the WSDL, and the corresponding concrete implementation of the endpoints coded into the Java skeletons. Thus far, no behaviors are coded into the skeletons, but only the operations they export are derived. According to a set of specified transformation rules from WSAgreement to Java and the relations in the deployment WSDD file, the wsCodeBuilder then generates the simulation code and inserts it into the proper operations. At the time of writing a running implementation of the wsCodeBuilder unit has been developed. The last step of the process concerns the deployment of the services simulating the selected QoS. The deployment descriptor coming from the first phase and the new version of the skeletons are then used as input for the Axis Deployment Engine. For the sake of completeness, it is important to remark that the generation of meaningful stubs would require to also handle their return values. Such values could in fact be part of a parametric QoS specification or influence the behavior of the tested service. The current implementation of Puppet does not provide a general solution, but returns values arbitrarily chosen among a set previously built for each possible data type. If no behavioral contract has been defined for the service this should be considered correct by the service under test. Nevertheless, within the WS community there is a great boost toward the definition of functional contracts for services [12] [5] [3]. To manage such situations, future releases of Puppet will integrate mechanisms that enable the instrumentation of stub services with code that returns conforming value with respect to the associated functional contract [21] (a related problem is that the determination of the return values must be low effort-intensive not to invalidate the evaluated QoS). As above mentioned, the current version of the tool needs human support for the setting of the choreography. This means that the binding among services under development and stubs is manually derived from the WS-CDL or WSBPEL. 4.2 Matching WS-Agreement Statements to Java Code Puppet can handle those QoS constraints that can be simulated by means of a parameterizable portion of code. The approach implemented in Puppet requires then that for

A QoS Test-Bed Generator for Web Services

25

Table 1. Service Level Objective Mapping for Latency ... 1000 normal ...

... try{ Random rnd = new Random(); float val = rnd.nextFloat(); int sleepingPeriod = Math.round(val*1000); Thread.sleep(sleepingPeriod); } catch (InterruptedException e) {} ...

each concept in a SLA language a precise mapping must be provided. This is clearly a quite complex task; nevertheless given a specific language and a possible interpretation of the corresponding statements, it has to be done only once and for all. Currently we have defined a simple language for SLA that can predicate over several QoS characteristics (latency, reliability, workload) and have set a precise mapping for this concepts, defined in XML format, to composable Java code segments. The mapping between the XML statements of the WS-A and the Java code has been specified in a parametric format that is instantiated each time one occurrence of the pattern appears. The examples reported in the remainder of this section show the transformations we have defined and encapsulated in Puppet. In particular, conditions on latency can be simulated introducing delay instructions into the operation bodies of the services skeletons. For each Guarantee Term in a WSAgreement document, information concerning the maximum service latency is defined as a Service Level Objective according to a prescribed syntax. The example in Tab. 1 reports the XML code for a maximum latency declaration of 1000mSec normally distributed and the correspondent Java code that Puppet will automatically generate. Table 2. Service Level Objective Mapping for Reliability ... 99.50 2000 ...

... if (this.possibleFailureInWindow()){ Random rnd = new Random(); float val = rnd.nextFloat()*100; if ( val>99.50f) { String fCode = "Server.NoService"; String fString="No target service to invoke!" org.apache.axis.AxisFault fault = new AxisFault(fCode,fString,"",null); this.incNumberOfFailure(); throw fault; } } ...

Constraints on services reliability can be declared by means of a percentage index into the Service Level Objective of a Guarantee Term. Such kind of QoS can be reproduced introducing code that simulates a service container failure. Thus, given the size of a sliding window defining the time interval within which reliability is measured, the generated stub for a service will raise remote exceptions according to the specified rate in the window. The XML code in Tab. 2 provides an example of the transformation for

26

A. Bertolino, G. De Angelis, and A. Polini

reliability constraint description, assuming that the Apache-Tomcat/Axis [2] platform is used. The case of workload can be simulated by equipping the generated skeletons with client-side code for the automatic invocation of the service under evaluation. Currently Puppet permits to describe the maximum number of requests that the clients can deliver to the service in a given period (i.e. WinSize in Tab. 3). The generation process augments the stubs with a private method for the remote invocation (i.e. invokeService in Tab. 3) and an exported public method that triggers the emulation request stream. The transformation in Tab. 3 reports the code for the trigger method. The information required for the instantiation of parameters such as the target endpoint is obtained from the part of the guarantee term concerning the scoping aspects discussed below. According to what described in Sec. 2, a guarantee in a WS-Agreement document can be enforced under an optional condition. Such additional constraints are usually defined in terms of accomplishments that a service consumer must meet: for example the latency of a service can depend on the time or on the day in which the request is delivered. In these cases, the transformation function wraps the simulating behavior code-lines obtained from the Service Level Objective part with a conditional statement (see Tab. 4.a). As mentioned, the scope for a guarantee term describes the list of services to which it applies. In particular, Tab. 4.b points out how to apply the term to a sub-set of the service operations. In this case, for each listed service, the transformation function adds the behavior previously obtained from the Service Level Objective and Qualifying Condition parts only to those operations declared in the scope.

5 Working Example This section illustrates the application of Puppet to derive a test-bed to verify the QoS characteristics of one service when interacting with other services. The case study considered refers to an on-line booking of flights. Several clients access a Travel Operator Table 3. Service Level Objective Mapping for Workload Generator

... 20 60000 ...

... public void generateTraffic () throws MalformedURLException,RemoteException{ Random rnd = new Random(); int sleepPeriod; String endpoint="http://myhost/axis/services/"; String service="client"; String method="planJourney"; int winSize=60000; for (int i=0; i98.00f){ String fCode="Server.NoService"; String fString = "No target service to invoke!" org.apache.axis.AxisFault fault=new AxisFault(fCode,fString,"",null); this.incNumberOfFailure(); throw fault; } } /**QUALIFYING COND. GENERATED CODE*/ if (interFly){ try{

Random rnd = new Random(); float val = rnd.nextFloat(); int sleepingPeriod = Math.round(val*20000); Thread.sleep(sleepingPeriod); } catch (InterruptedException e) {} } /** QUALIFYING CONDITION GENERATED CODE */ if (!interFly){ /** LANTENCY EMULATOR CODE */ try{ Random rnd = new Random(); float val = rnd.nextFloat(); int sleepingPeriod = Math.round(val*10000); Thread.sleep(sleepingPeriod); } catch (InterruptedException e) {} } ...

Starting from this description Puppet is able to generate a set of stubs for the services interacting with the service under test. In particular Table 5 shows the derived source code for the method checkFlight provided by ABS2 starting from the corresponding QoS values specified in Fig. 4 formatted according to the WS-Agreement specification as shown in Section 4. Table 3 instead shows the code generated for the client stub. The generated client defines a method, to be used by the tester, that will raise the specified number of invocations within the specified time frame. In the idea of Puppet the tester should combine all the generated services in different configurations, reproducing real run-time scenarios. Then launching the scenario it is possible to check if the specification of QoS defined for the Service under evaluation are respected and under which conditions. For instance the developer can try to understand which is the maximum number of clients that can be introduced in the scenario while still being able to abide by the specified QoS.

6 Related Work Some years ago the authors of [9] recognized that the combination of testing and QoS evaluation, performance in particular, was a seldom explored path in software engineering research. Today the situation has changed and some interesting work starts to appear on this topic. The application of testing for QoS evaluation requires to solve two main problems. The first one is the derivation and simulation of an environment faithfully reproducing the final execution conditions. The second problem is the derivation of a testing suite representative of the real usage scenario, with particular reference to the specific property to be assessed. This work is mainly related to the first point. Nevertheless the application of empirical approaches to QoS evaluation asks to solve both problems cited above. For works on how to automatically derive test cases, to be used for the successive evaluation of a system in a simulated environment, we refer to the literature, e.g., [9,16,7].

A QoS Test-Bed Generator for Web Services

29

With reference to the generation of test-beds for the validation of WS QoS, we did not find many works. With reference to the area of Component-based software the work presented in [7] shows some similarities with what we propose here. Nevertheless the two approaches are quite different in their motivations and hypotheses. In [7] starting from the hypothesis that the middleware strongly influences the performance behavior of a deployed CBS, the authors generate an environment for the evaluation of the architecture of the system under development. The generated environment then is not intended to be used for the evaluation of a single real component implementation. Instead our target here is to develop a test-bed for the evaluation of a real implementation of a service. Moreover in [7] the stubs are directly derived starting from the architectural definition, no descriptions of QoS are considered (that work was mainly aimed at early performance evaluation). In our work instead, thanks to the availability of the QoS specification (such as the WS-A document), we can generate stubs behaving in accordance to what is defined in the corresponding WS-A document. A work that has much in common with what we propose here is [11], in which a performance test-bed generator, in the domain of SOA, is presented. The approach proposed is structured in several steps. First, the service under development is described as a composition of services. Then, from this compositional model a collection of service stubs is generated. At this point for each service a description of the load that will be generated by possible clients is defined. From such descriptions, clients simulating the defined load are automatically developed. Finally, clients are executed in order to stress the service composition. The main differences with our proposal are twofold: on the one hand, the system in [11] makes no use of any kind of contract or agreement specification, differently from the approach we propose which is heavily based on the SLA. On the other hand, in [11] the service under development reacts to external stimuli generated by some clients according to the given load model. In our approach the service under development is considered plugged in a well specified choreography. Since none of the choreography members implementation is supposed to be available, our approach automatically builds an environment according to the specification of the coordination scenario. Finally a main stream of SOA literature is devoted today to runtime evaluation of QoS by means of monitoring approaches. We do not tackle such related work here for size limitations.

7 Conclusions and Future Work The paper proposed the Puppet approach for the automatic generation of test-beds to empirically pre-validate the QoS of a composite WS before it is deployed. To be applicable the approach requires the availability of the specification of the composition in which the service under evaluation will be inserted. We also assume that the composition is augmented with QoS properties, for instance expressed as a WS-A specification. QoS annotations of WS are not state-of-practice nowadays, nevertheless the relevance of this topic is raising fast in this domain. This is due to the fact that the SOA paradigm aims at removing the barrier among different organisations that can then directly cooperate. In a such scenario the reduced control over the required services certainly asks

30

A. Bertolino, G. De Angelis, and A. Polini

for the introduction of agreements concerning the quality of non functional properties in addition to the functional behaviour. Puppet requires first to define a precise mapping of the terms used for specifying QoS properties to simple parameterized Java code. This step gives a sort of semantic to each type of terms and is done once and for all. In some sense, it implicitly defines the simplest instance of a service providing the specified QoS. More complex definitions of QoS properties are obtained by composing terms of the QoS specification language. Thus, the translation function composes simple transformations according to the rules for the composition. In such a manner Puppet is able to generate service stubs according to composite QoS properties. These stubs can be used to validate possible real implementations of an under development service participating to the same coordination scenario. The approach we are working on seems promising, nevertheless some issues remain open. Particularly interesting seems the generation of stubs that permit to return meaningful values without introducing complex code that could undermine the realization of stubs behaving in accordance to a specified QoS property. The approach has been shown to be applicable and a tool is currently under finalization as an Eclipse plug-in. As described the tool will provide stubs mimicking real services, according to the corresponding QoS definition. To carry on reliable experiments the developer will have to distribute the stubs among various machines trying to reproduce as much as possible the final deployment environment. Another important factor strongly influencing the evaluation will be the definition of workload actually representing the final deployment condition. We are working on adding support for these steps that currently rely on human intervention to solve some technical issues. Nevertheless it is important to stress that the reproduction of a representative environment will never be achieved in a completely automated way.

Acknowledgements The authors wish to thank Giovanni Possemato for his important contribution to the implementation of the tools enabling the proposed approach. G. De Angelis PhD grant is sponsored by Ericsson Lab Italy in the framework of the PISATEL initiative (http://www1.isti.cnr.it/ERI/) This work is partially supported by the PLASTIC Project (EU FP6 Strep No. 26955).

References 1. Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web Services–Concepts, Architectures and Applications. Springer–Verlag, Heidelberg (2004) 2. Apache Software Foundation. Axis User’s Guide. http://ws.apache.org/axis/java/user-guide.html. 3. Baresi, L., Ghezzi, C., Guinea, S.: Smart Monitors for Composed Services. In: ICSOC 2004. Proc. 2nd Int. Conf. on Service Oriented Computing, pp. 193–202. ACM Press, New York (2004)

A QoS Test-Bed Generator for Web Services

31

4. Bertolino, A., Bonivento, A., De Angelis, G., Sangiovanni Vincentelli, A.: Modeling and Early Performance Estimation for Network Processor Applications. In: Nierstrasz, O., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, Springer, Heidelberg (2006) 5. Bertolino, A., Frantzen, L., Polini, A., Tretmans, J.: Audition of Web Services for Testing Conformance to Open Specified Protocols. In: Reussner, R., Stafford, J.A., Szyperski, C.A. (eds.) Architecting Systems with Trustworthy Components. LNCS, vol. 3938, Springer, Heidelberg (2006) 6. Bertolino, A., Mirandola, R.: Software Performance Engineering of Component–Based Systems. In: WOSP 2004, pp. 238–242. ACM Press, New York (2004) 7. Denaro, G., Polini, A., Emmerich, W.: Early Performance Testing of Distributed Software Applications. In: WOSP 2004, pp. 94–103. ACM Press, New York (2004) 8. Draheim, D., Grundy, J., Hosking, J., Lutteroth, C., Weber, G.: Realistic Load Testing of Web Applications. In: Proc. Conf. on Software Maintenance and Reengineering, pp. 57–70. IEEE Computer Society Press, Los Alamitos (2006) 9. Weyuker, E., Vokolos, F.: Experience with performance testing of software systems: Issues, and approach, and case study. IEEE Transaction on Software Engneering 26(12), 1147–1156 (2000) 10. Global Grid Forum: Web Services Agreement Specification (WS–Agreement), version 2005/09 (edn.) (September 2005) 11. Grundy, J., Hosking, J., Li, L., Liu, N.: Performance Engineering of Service Compositions. In: SOSE 2006. Proc. Int. Workshop on Service–Oriented Software Engineering, pp. 26–32. ACM Press, New York (2006) 12. Heckel, R., Lohmann, M.: Towards Contract–based Testing of Web Services. Electronic Notes in Theoretical Computer Science 116, 145–156 (2005) 13. Hrischuk, C.E., Rolia, J.A., Woodside, C.M.: Automatic Generation of a Software Performance Model Using an Object-Oriented Prototype. In: MASCOTS 1995. Proc. 3rd Int. Workshop on Modeling, Analysis, and Simulation On Computer and Telecommunication Systems, pp. 399–409. IEEE Computer Society Press, Los Alamitos (1995) 14. IBM. WSLA: Web Service Level Agreements, version: 1.0 revision: wsla-, 2003/01/28 edn. (2003) 15. Liu, Y., Gorton, I.: Accuracy of Performance Prediction for EJB Applications: A Statistical Analysis. In: Gschwind, T., Mascolo, C. (eds.) SEM 2004. LNCS, vol. 3437, pp. 185–198. Springer, Heidelberg (2005) 16. Liu, Y., Gorton, I., Liu, A., Jiang, N., Chen, S.: Designing a test suite for empirically-based middleware performance prediction. In: CRPIT ’02: Proc. 4th Int. Conf. on Tools Pacific, pp. 123–130. ACS (2002) 17. Ludwig, H.: WS-Agreement Concepts and Use – Agreement-Based Service-Oriented Architectures. Technical report, IBM (May 2006) 18. OASIS. Web Services Business Process Execution Language (WSBPEL) 2.0 (December 2005) http://www.oasis-open.org/committees/tc home.php? wg abbrev=wsbpel. 19. Skene, J., Lamanna, D.D., Emmerich, W.: Precise Service Level Agreements. In: Proc. 26th Int. Conf. on Software Engineering (ICSE 2004), pp. 179–188 (2004) 20. Smith, C.U., Williams, L.: Performance Solutions: A practical Guide To Creating Responsive, Scalable Software. Addison–Wesley, London, UK (2001) 21. Tkachuk, O., Rajan, S.P.: Application of Automated Environment Generation to Commercial Software. In: ISSTA 2006. Proc. ACM Int. Symp. on Sw Testing and Analysis, pp. 203–214. ACM Press, New York (2006) 22. W3C. Web Services Choreography Description Language (WS–CDL) 1.0 (November 2005) http://www.w3.org/TR/ws-cdl-10/

Engineering Compensations in Web Service Environment Michael Sch¨afer1 , Peter Dolog2 , and Wolfgang Nejdl1 1

L3S Research Center, University of Hannover, Appelstr. 9a, D-30167 Hannover, Germany [email protected], [email protected] 2 Aalborg University, Department of Computer Science, Fredrik Bajers Vej 7E,DK-9220 Aalborg East, Denmark [email protected]

Abstract. Business to business integration has recently been performed by employing Web service environments. Moreover, such environments are being provided by major players on the technology markets. Those environments are based on open specifications for transaction coordination. When a failure in such an environment occurs, a compensation can be initiated to recover from the failure. However, current environments have only limited capabilities for compensations, and are usually based on backward recovery. In this paper, we introduce an engineering approach and an environment to deal with advanced compensations based on forward recovery principles. We extend the existing Web service transaction coordination architecture and infrastructure in order to support flexible compensation operations. A contract-based approach is being used, which allows the specification of permitted compensations at runtime. We introduce the abstract service and adapter components which allow us to separate the compensation logic from the coordination logic. In this way, we can easily plug in or plug out different compensation strategies based on a specification language defined on top of basic compensation activities and complex compensation types. Experiments with our approach and environment show that such an approach to compensation is feasible and beneficial.

1

Introduction

The Web service environment has become the standard for Web applications supporting business to business transactions and user services. Processes such as payroll management or supply chain management are realized through Web services. In order to ensure that the results of the business transactions are consistent and valid, Web service coordination and transaction specifications [12,13,11] have been proposed. They provide the architecture and protocols that are required for transaction coordination of Web services. The transaction compensation [7] is a replacement for an operation that was invoked but failed for some reason. The operation which replaces the original one either undoes the results of the original operation, or provides similar capabilities L. Baresi, P. Fraternali, and G.-J. Houben (Eds.): ICWE 2007, LNCS 4607, pp. 32–46, 2007. c Springer-Verlag Berlin Heidelberg 2007 

Engineering Compensations in Web Service Environment

33

as the original one. The notion of compensation was introduced for environments where the isolation property of transactions is relaxed but the atomicity needs to be maintained. Several protocols have been proposed to control transactional processes with compensations [20]. Current open specifications for transaction management in Web service environment provide only limited compensation capabilities [8]. In most cases, the handling of a service failure is restricted to backward recovery in order to maintain consistency, i.e. all running services are aborted, and all already performed operations are reversed [1]. This approach is very inflexible and can result in the abortion of many services and transactions. Especially if dependencies between multiple transactions exist, the failure of one service can lead to cascading compensations. Furthermore, current approaches do not allow any changes in a running transaction. If for example erroneous data was used in a part of a transaction, then the only possible course of action is to cancel the transaction and to restart it with correct data. In this paper, we investigate an engineering approach for advanced compensation operations adopting forward recovery within Web service transactions. Forward recovery proactively changes the state and structure of a transaction after a service failure occurred, and thus enables the transaction to finish successfully. The main idea is the introduction of a new component called an abstract service, which functions as a mediator for compensations, and thus hides the logic behind the introduced compensations. Moreover, it specifies and manages potential replacements for primary Web services to be used within a transaction. The compensations are performed according to predefined rules, and are subject to contracts [14]. We introduce a framework based on the abstract services, which enables the compensations described in the compensation specifications. Such a solution has the following advantages: – Compensation strategies can be defined on both, the service provider and the client side. They utilize local knowledge (e.g. the provider of a service knows best if and how his service can be replaced in case of failure) and preferences, which increases the flexibility and efficiency. – The environment can handle both, internally and externally triggered compensations. – The client of a service is informed about complex compensation operations, which makes it possible to trigger additional compensations. Compensations can thus consist of multiple operations on different levels, and consistency is achieved through well defined communication protocols. – By extending the already adopted Web service specification, it is not necessary to discontinue current practices if compensations are not required. – The separation of the compensation logic from the coordination logic allows for a generic definition of compensation strategies, independent from the coordination specification currently in use. They are therefore more flexible and can easily be reused in a different context. The rest of the paper is structured as follows. Section 2 introduces the motivating scenario, which will be used in the paper in order to exemplify the

34

M. Sch¨ afer, P. Dolog, and W. Nejdl

concepts. Section 3 introduces the proposed design for an infrastructure that is able to handle internally and externally triggered compensations without transaction aborts, and describes the basic components and compensation specifications based on compensation activities and compensation types. A prototype implementation of the design is described in section 4, along with two experiments that use the new compensation capabilities. Section 5 reviews related work in the area of forward recovery. Section 6 concludes this paper and provides a direction for future work on this topic.

2

Motivating Scenario

The motivating scenario for this paper is a company’s monthly payroll processing. In order to introduce real-life dependencies, both, the company’s and the employee’s responsibilities are considered. Company: In the first step of the payroll processing procedure, the company has to calculate the salary for each employee, which can depend on a multitude of factors like overtime hours or bonuses. In the next step, the payment of the salary is performed, which comprises several operations. First of all, the salary is transferred from the company’s account to the employee’s account. Then the company transfers the employee’s income tax to the account of the fiscal authorities. Finally, the company prints the payslip and sends it to the employee. Employee: The employee has only one task which he has to perform each month in this scenario: He transfers the monthly instalment for his new car to the car dealer’s account. The company’s and the employee’s operations are each controlled by a business process, and are implemented using Web services from multiple providers. The two business processes use transactions in order to guarantee a consistent execution of all required operations. This is depicted in Figure 1. Only the services of transaction T1 are shown. It is obvious that there are multiple dependencies in this simple scenario, between and within these transactions. Therefore, it is vitally important that no

Fig. 1. The motivating scenario

Engineering Compensations in Web Service Environment

35

transactions have to be aborted and compensated in order to avoid cascading compensations. However, such a situation can become necessary quite easily: 1. It can always happen that a service which participates in a transaction fails. Here, it could be that the service that handles the transfer of the salary fails due to an internal error. The transaction inevitably has to be aborted, even though the error might be easily compensatable by using a different service that can perform the same operation. Such a replacement is encouraged by the fact that usually multiple services exist that have the same capabilities. 2. A mistake has been made regarding the input data of an operation. In this scenario, it could be that the calculation of the salary is inaccurate, and too much has been transferred to the employee’s account. The flaw is spotted by an administrator, but the only option is again to abort the complete transaction, although it would be very easy to correct the mistake by transferring the sum that has been paid too much back to the company’s account. Although it should be possible to handle these situations without the need to cancel and compensate the transaction(s), current technology does not allow to do so in a sensible way.

3

Web Service Environment with Transaction Coordination

We base our work on Web service coordination and transaction specifications [12,13,11]. These transaction specifications provide a conceptual model and architecture for environments where business activities performed by Web services are embedded into transactional contexts. Figure 2 depicts an excerpt of such an environment with the main components. The client runs business activities A1 to A5, which are embedded in a transactional context. The transactional context and conversation is maintained by a transaction coordinator. Client and server stubs are responsible for getting

Fig. 2. Transactional environment for Web services adopted from [1]

36

M. Sch¨ afer, P. Dolog, and W. Nejdl

Fig. 3. The abstract service and adapter

and registering the activities and calls for Web services in the right context. The sequence of conversation messages is numbered. For clarity, we only show a conversation with a Web service provider that performs business activity A1. The transaction coordinator is then responsible for running appropriate protocols, such as two phase commit or some of the distributed protocols for Web service environments such as [2]. As pointed out above, the compensation capabilities are left to the client business activities according to the specifications in [12,13,11]. We extend the architecture and the infrastructure based on those specifications, so that it can handle internally and externally triggered compensations. Figure 3 depicts the extension to the transaction Web service environment, namely the abstract service and the adapter components. This extension does not change the way how client, transaction coordinators and Web service providers operate. Clients, instead of invoking concrete Web services, invoke abstract services which wrap several services and compensations for them. The adapter functions as a mediator between transaction coordinator, abstract service and concrete service to ensure proper transactional context. 3.1

Abstract Service

The central element of the extension is the notion of an abstract service. The client stub communicates with the Web service provider stub through the abstract service. An abstract service does not directly implement any operations, but rather functions as a management unit, which allows to: – define a list of Web services which implement the required capabilities, – invoke a service from the list in order to process requests which are sent to the abstract service,

Engineering Compensations in Web Service Environment

37

– replace a failed service with another one from the list without a failure of the transaction, and – process externally triggered compensations on the running transaction. Distributed applications consisting of collaborating Web services have the advantage that normally single operations can be performed by multiple services from different providers. Which service will be chosen depends usually on the quality of service (QoS) requirements of the distributed application. The abstract service takes advantages of the existing diversity. To the outside, it provides an abstract interface and can be used like any other Web service, and uses the same mechanisms like SOAP [15] and WSDL [4]. On the inside, it manages a list of Web services (called concrete services) which provide the required capabilities. When the abstract service receives a request, it chooses one of these services and invokes it. Interface and data incompatibilities between the abstract interface and the interfaces of the concrete services are solved by predefined wrappers. This approach has multiple benefits: – Usually, a client does not care which specific service handles his requests, as long as the job will be done successfully and in accordance with the contract. The abstract service design supports this notion by providing the capabilities to separate the required abilities from the actual implementation. – The available list of concrete services enables the abstract service to provide enhanced compensation possibilities. – The definition of an abstract service can be done independently from the business process in which it will be used. It can therefore be reused in multiple applications without the need for changes. If a specific service implementation is no longer usable, then the business process does not have to be changed, as this is being managed in the abstract service. Figure 3 depicts the basic structure of an abstract service. Four interfaces are supplied to the outside: The service operations for which the abstract service has been defined can be accessed via the abstract service interface. A contract can be exchanged or negotiated by using the contract exchange interface. Execution events of a service (e.g. a failure) can be signaled via the event interface. Compensations can be triggered from the outside using the compensation interface. On the inside, the main component is the management unit, which receives and processes requests, selects and invokes concrete services, and handles compensations. In order to do so, it has several elements at its disposal: – Concrete service list : Contains the details of all available concrete services. – Concrete service wrappers: Define the mapping of the generic abstract service interface to the specific interface of each concrete service. – Request log: Holds all requests of the current session. – Compensation rules repository: Manages the rules that control the compensation handling process. – Contract repository: Contains the existing contracts with the different clients.

38

3.2

M. Sch¨ afer, P. Dolog, and W. Nejdl

Adapter

Abstract services could be used in conjunction with a wide variety of technologies. Therefore, it would be preferable if the definition of the abstract service itself could be generic. However, the participation in a transaction requires capabilities that are different for each transaction management specification. That is why the transaction specific requirements are encapsulated in a socalled adapter (see Figure 3). An abstract service registers at this adapter, which in turn registers with the transaction coordinator. To the coordinator it looks as if the abstract service itself has registered and sends the status messages. When the abstract service invokes a concrete service, it forwards the information about the adapter, which functions as a coordinator for the service. The service registers accordingly at the adapter as a participant in the transaction. As it can be seen, the adapter works as a mediator between the abstract service, the concrete service, and the transaction coordinator. The adapter receives all status messages from the concrete service and is thus able to process them before they reach the actual coordinator. Normal status messages can be forwarded directly to the coordinator, while the failure messages can initiate the internal compensation handling through the abstract service. If the adapter receives such an error message, it informs the abstract service, which can then assess the possibility of compensation. The adapter will then be informed about the decision, and can act accordingly. If for example the replacement of a failed concrete service is possible, then the adapter will deregister this service and wait for the replacement to register. In this case, the failure message will not be forwarded to the transaction coordinator. The compensation assessment could of course also show that a compensation is not possible (or desirable). In such a case, the adapter will simply forward the failure message to the coordinator, which will subsequently initiate the abort of the transaction. 3.3

Compensation Specifications

Compensation specifications enable the abstract service to handle both kinds of compensations: Internally triggered compensations (arising from internal errors) and externally triggered compensations. An example for an externally triggered compensation could be the handling of the mistake spotted by an administrator as described in the motivation scenario section. We distinguish between compensation activities and compensation types in our compensation specifications, whose interaction are shown in Figure 4. Basic Compensation Activities are the basic operations which can be used in a compensation. ServiceReplacement replaces the currently used Web service with a different one, which can offer the same capabilities and can thus act as a replacement. LastRequestRepetition resends the last request to the Web service. PartialRequestRepetition resends the last n requests from the request sequence of the current session (i.e. within the current transaction) to the Web service, while AllRequestRepetition resends all requests. CompensationForwarding forwards the

Engineering Compensations in Web Service Environment

39

Fig. 4. The compensation types and their included activities

external compensation request to a different component, which will handle it. AdditionalServiceInvocation invokes an additional (external or internal) service, which performs some operation that is important for the compensation (e.g. the invocation of a logging service, which collects data about a specific kind of compensation). AdditionalRequestGeneration creates and sends an additional request to the Web service. Such a request is not influenced by the client, and the result will not be forwarded to the client. ServiceAbortInitiation cancels the operations on the Web service, i.e. the service aborts and reverses all operations which have been performed so far. RequestSequenceChange performs changes in the sequence of requests that have already been sent to the Web service. ResultResending sends new results for old requests, which have already returned results. Compensation Types aggregate multiple compensation activities, and thus form complex compensation operations, as shown in Figure 4. These types are the compensation actions which can be used for internal and external compensations, and which form the basis of the compensation specification language. There are currently 7 different compensation types. The most simple type is NoCompensation, which does not perform any operation. If a Web service fails, then this will be signaled to the transaction coordinator, which will initiate the transaction abort. The Repetition type is important for the internal error handling, as it repeats the last request or the last n requests. The last request can for example be resend to a Web service after a response was not received within a timeout period. A

40

M. Sch¨ afer, P. Dolog, and W. Nejdl

partial resend of n requests can for instance be necessary if the request which failed was part of a sequence, which has to be completely repeated after the failure of the final request. A partial repetition of requests will result in the resending of results for old requests to the client, which has to be able to process them. The compensation type Replacement can be used if a Web service fails completely. It replaces the current service with a different one, and resends either all requests, a part of the requests, or only the last one. Resending only the last request is possible if a different instance of the service that has failed can be used as replacement, which works on the same local data and can therefore simply continue with the operations. Forwarding is special in comparison with the other types, as it only indirectly uses the available activities. It forwards the handling of the compensation to a different component, which can potentially use each one of the compensation activities (which are therefore marked as ”possibly included”) in the process. In an externally triggered compensation, it is sometimes necessary to invoke additional services and send additional requeststo the concrete service. For this purpose, the compensation types AdditionalService and AdditionalRequest exist. The final compensation type is SessionRestart. This operation is required if the external compensation request can not be handled without a restart of the complete session, i.e. the service has to be aborted and subsequently the complete request sequence has to be resend. The requested change will be realised by a change in the request sequence prior to the resending. Compensation Protocol controls the compensation process and its interaction with the different participants. An externally triggered compensation always has the purpose of changing one particular request that has already been processed at the service. More specifically, the compensation request contains the original request with its data that has to be changed (request1(data1)), and the new request-data (data2) to which the original request has to be changed to (request1(data2)). The participants in the protocol are the abstract service, the client which uses the abstract service in its business process, the initiator which triggers the external compensation (either the client itself, or any other authorized source like an administrator), and the transaction coordinator. An externally triggered compensation can only be performed if the transaction in which the abstract service participates has not yet finished, as it usually has consequences for the client due to result resending. The protocol consists of two stages. The first stage is the compensation assessment: As soon as the abstract service receives a request for a compensation, it checks whether it is feasible and what the costs would be. To that end, predefined compensation rules are being used, which consist of a compensation condition (defines when a compensation rule can be applied) and a compensation plan (defines the compensation actions that have to be performed). The second stage of the protocol is the compensation execution, which performs the actual compensation according to the plan. Whether this stage is actually reached depends on the initiator: After the assessment has been completed and has come to a

Engineering Compensations in Web Service Environment

41

positive conclusion, the initiator, based on this data, has to decide whether the compensation should be performed or not. As the client and the initiator of an external compensation can differ, the protocol contains the means to inform the client about the compensation process. It also ensures that the transaction coordinator is informed about the status of the external compensation, because the assessment and the execution stages have consequences for the abstract service’s status in the transaction. While assessing the possibilities for a compensation, and while performing it, the abstract service can not process additional requests (and either has to store the requests in a queue, or has to reject them with an according error message). Moreover, its status can change as a result of a successful compensation. 3.4

Application on the Client and Provider Side

The abstract service design can be applied on both, the client and the provider side. A client which wants to create a new distributed application using services provided by multiple providers can utilize abstract services in two different ways: 1. The client can include the abstract service from a provider in its new business process, and can use the added capabilities. 2. The client can define a new abstract service, which manages multiple concrete services that can perform the same task. The main goal of a Web service provider is a successful and stable execution of the client’s requests in accordance with the contracts. If the service of a provider fails too often, he might face contractual penalties, or the client might change the provider. He can use abstract services in order to enhance the reliability and capability of his services by creating an abstract service which encapsulates multiple instances or versions of the same service. These can be used in case of errors to compensate the failure without the need for a transaction abort.

4

Discussion and Experiments

The described design approach has been used in a prototype implementation based on the scenario in section 2, and we performed two experiments with the implemented environment. The four services participating in the payment transaction have been realized as abstract services. The abstract services manage the standard Web services performing the required operations as concrete services. The implementation has been done using Apache Tomcat as Web container, and Apache Axis as SOAP engine. The WS-Transaction specification has been chosen for the transaction coordination, more specifically the BusinessAgreementWithCoordinatorCompletion protocol with the extension for transaction concurrency control that has been introduced in [2]. It is necessary for externally triggered compensations that the transaction coordinator is able to adapt to the changes that have to be performed in the process.

42

M. Sch¨ afer, P. Dolog, and W. Nejdl

Fig. 5. Compensation on the provider side

The first experiment was devoted to the evaluation of the compensation of an internal service error. In this case, a failure of the concrete service on the provider side is simulated. Figure 5 shows the setup for the transfer salary operation: The abstract service AS1 on the client side currently uses a concrete service that is itself an abstract service (AS2 ), which is operated by a service provider. The abstract service AS2 uses Web Service 1, which performs the required operations. Figure 5 also depicts the interconnection of the services: AS1 is registered as a participant at the Transaction Coordinator via Adapter 1, AS2 is registered at Adapter 1 via Adapter 2, and Web Service 1 is registered at Adapter 2. Now Web Service 1 fails due to an internal error, and is thus not able to perform all operations required for the salary transfer. Instead of informing the transaction coordinator, abstract service AS2 is informed, which assesses its compensation rules, the contract, and the available substitution services, and decides that a compensation is possible. Web Service 1 is discarded and the request that failed is send to Web Service 2, which registers at the adapter. Web Service 2 is another instance of the same service, and can therefore simply continue with the request as it operates on the same local resources. This scenario shows that the signal of the service failure can be intercepted and the service replaced, without the need to cancel the complete transaction. The second experiment evaluates an externally triggered compensation. Figure 1 summarizes the operations on the different accounts in the scenario described in section 2. In this experiment, an administrator has found an error in the calculation of the salary: The company transferred 50 units too much to the account of the employee. The administrator directly sends a compensation request to the abstract service that handles the salary transfer (AS1 ). The abstract service assesses the request by consulting its compensation rules. In this scenario, the rules specify that this compensation is only allowed if the employee’s account would still be in credit after the additional debit operation, in order to avoid the employee’s account being in debit after the transaction. The result of the assessment is positive, which is reported to the administrator, who can decide based on this data whether the compensation should be performed. He decides that the compensation is necessary. The abstract service

Engineering Compensations in Web Service Environment

43

Table 1. The transfer operations on the accounts in the scenario Nr. 01 02 03 04 05 06

Transaction

Company (C) Employee (E) Tax (T) Car Dealer (D) 10.000 0 Y Z T1.debit(C,1.000) 9.000 T1.credit(E,1.000) 1.000 T1.debit(C,500) 8.500 T1.credit(T,500) Y+500 T2.debit(E,150) 850 T2.credit(D,150) Z+150 8.500 850 Y+500 Z+150

Table 2. The additional operations on the accounts Nr. Transaction Company (C) Employee (E) Tax (T) Car Dealer (D) ... ... ... ... ... ... 07 T1.debit(E,50) 800 08 T1.credit(C,50) 8.550 8.550 800 Y+500 Z+150

compensates operations 01 and 02 from Table 1 by creating an additional debit and credit operation, as can be seen in Table 2. The operations transfer 50 from the employee’s account back to the company’s account, which thus compensates the initial problem. As an additional service, the abstract service initiates a precautionary phone call, which informs the employee about the change. Subsequently, the compensation will be reported to the client, who has to assess whether any other services are affected according to its business process. It decides that the tax transfer does not have to be changed, while the payslip has to be updated, as the details of the salary have changed. The business process therefore initiates a compensation on the respective service, which handles this request by printing and mailing a new payslip. This shows that even the more complex initial problem could be solved without the need to abort the transaction. These two experiments have shown that the proposed design is successful in employing flexible compensation strategies in Web service transactions. It is thus possible to develop more robust distributed applications, where the abstract services are able to adapt their compensation rules to the contract they have with the client. Especially in long-running transactions, this approach helps to avoid unnecessary transaction aborts, and therefore saves money and time. While it is of course still possible that the abstract service itself encounters an error, it at least provides the capabilities to avoid transaction aborts due to concrete service failures. Moreover, it is possible to mix the new design with existing technology: The new capabilities can be used, but do not have to be, as an abstract service can be employed like any other normal Web service. However, the new functionality of the design with its advanced compensation abilities has its costs. By introducing additional components like the abstract

44

M. Sch¨ afer, P. Dolog, and W. Nejdl

services and the adapters, the overall structure of a distributed application becomes more complex. The outsourcing of compensation logic to the abstract services simplifies the business process definitions, but at the same time the distributed compensation logic can make maintenance more difficult. And finally, the added components require additional messaging, and therefore the design increases the total number of messages that have to be sent. The current implementation is a proof-of-concept of the proposed design architecture, and is still limited regarding certain aspects. The prototype of the abstract service uses only synchronous requests and does not allow parallel requests. Nevertheless, the same principles can be applied in this case, although additional request queue management will be required. Accordingly, the execution of compensation actions is currently performed only sequentially.

5

Related Work

Forward recovery can be realized by using dynamic workflow changes, as described in [17,19], which allow the semi-automatic adaptation of a workflow in case of errors. A change of the workflow process can for example consist of a deletion or jump instruction, or the insertion of a whole new process segment. The change can either be done on a running instance, or it can be performed on the scheme which controls the workflow, and which results in a change in all running instances. Refer to [18] for details. Although this approach is very powerful, it has two major disadvantages. Firstly, it is in most cases only possible to perform these adaptations semi-automatically. Changing a workflow requires a lot of knowledge about the process and the current state it is in, and the implications a change would have. Therefore, it is often necessary for a human administrator to specify and control the change. Secondly, these kinds of workflow changes require a very strict definition of the process, including for example data and control links. Ad-hoc changes of business processes with normal orchestration languages like WS-BPEL (see [6]) is very difficult [9]. [5] provides a mechanism to overcome this difficulty through a compensation handler. Our approach provides a more flexible solution for compensations orthogonal to the business processes, concrete services, and transaction coordination. Our compensation approach can be used with the Enterprise Service Bus (ESB) [3], a powerful messaging infrastructure for business to business integration with Web services. The abstract service and adapter can be integrated through the ESB flexible extension mechanism. In this way, ESB can serve as a platform to exchange extended messages between business process, abstract services and adapters involved in the compensation conversation. Our approach can be used independently of ESB, employing ESB on top of the introduced infrastructure to integrate abstract services with workflow activities. [16] introduces a notion of compensable Web services by specifying operations which can revert the execution. In our approach, we allow for a more complex specification of forward recovery compensations, which can be introduced at the client side, mediator side, as well as provider side. Two related approaches to a

Engineering Compensations in Web Service Environment

45

flexible compensation mechanism for business processes are proposed in [20,10]. In both cases, the focus is put on backward recovery. The compensation logic is treated as a part of coordination logic. In our approach, we separate the coordination from the compensation logic to provide for more flexibility.

6

Conclusions and Further Work

We have described a new design approach for complex compensation strategies in current transaction standards. Two new components have been described, the abstract service, which manages replacement services and compensation rules, and the adapter, which separates the coordination protocol specific functions from the generic definition of the abstract service. We have also presented the protocol that handles the assessment and processing of externally triggered compensations. The design and the protocol have been successfully validated in a prototype implementation. Regarding future work, we plan to run additional experiments with different compensation scenarios. Moreover, it will be necessary to further analyze the impact of the new compensation capabilities on the business process definitions. At the moment, it is only assumed that the business process is able to adapt to the signaled compensations. It will be required to analyze possible extensions of existing orchestration languages like BPEL in order to include the new capabilities. The current implementation will be extended to support the management of parallel request processing, and the definition of compensation rules will be adapted accordingly.

References 1. Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web Services - Concepts, Architectures and Applications. Springer, Heidelberg (November 2003) 2. Alrifai, M., Dolog, P., Nejdl, W.: Transactions Concurrency Control in Web Service Environment. In: ECOWS ’06. Proceedings of the European Conference on Web Services, Zurich, Switzerland, pp. 109–118. IEEE Computer Society Press, Los Alamitos, CA, USA (2006) 3. Chappell, D.A.: Enterprise Service Bus. O’Reilly Media, Inc., (2004) 4. Christensen, E., Curbera, F., Meredith, G., Weerawarana, S.: Web Services Description Language (WSDL) 1.1. W3C note, W3C, March (2001) 5. Dobson, G.: Using ws-bpel to implement software fault tolerance for web services. In: EUROMICRO ’06: Proceedings of the 32nd EUROMICRO Conference on Software Engineering and Advanced Applications, pp. 126–133. IEEE Computer Society Press, Los Alamitos (2006) 6. Alves, A., et al.: Web Services Business Process Execution Language Version 2.0 (Published online 2007) http://docs.oasis-open.org/wsbpel/2.0/CS01/ wsbpel-v2.0-CS01.pdf 7. Gray, J.: The transaction concept: Virtues and limitations. In: VLDB 1981: Intl. Conference on Very Large Data Bases (1981)

46

M. Sch¨ afer, P. Dolog, and W. Nejdl

8. Greenfield, P., Fekete, A., Jang, J., Kuo, D.: Compensation is not enough. In: EDOC 2003. 7th International Enterprise Distributed Object Computing Conference, Brisbane, Australia, pp. 232–239. IEEE Computer Society Press, Los Alamitos (2003) 9. Karastoyanova, D., Houspanossian, A., Cilia, M., Leymann, F., Buchmann, A.P.: Extending bpel for run time adaptability. In: Ninth IEEE International Enterprise Distributed Object Computing Conference EDOC, Enschede, The Netherlands (2005) 10. Lin, L., Liu, F.: Compensation with dependency in web services composition. In: NWeSP 2005. International Conference on Next Generation Web Services Practices, Seoul, Korea, pp. 183–188. IEEE Press, New York (August 2005) 11. Arjuna Technologies Ltd., BEA Systems, Hitachi Ltd., IBM Corporation, IONA Technologies, and Microsoft Corporation. Web Services Business Activity Framework, Published online (2005) ftp://www6.software.ibm.com/software/ developer/library/WS-BusinessActivity.pdf 12. Arjuna Technologies Ltd., BEA Systems, Hitachi Ltd., International Business Machines Corporation, IONA Technologies, and Microsoft Corporation. Web Services Coordination (Published online 2005) ftp://www6.software.ibm.com/software/ developer/library/WS-Coordination.pdf 13. Arjuna Technologies Ltd., BEA Systems, Hitachi Ltd., International Business Machines Corporation, IONA Technologies, and Microsoft Corporation Inc. Web Services Atomic Transaction, Published online (2005) ftp://www6.software.ibm.com/ software/developer/library/WS-AtomicTransaction.pdf 14. Meyer, B.: Applying ”Design by Contract”. IEEE Computer 25(10), 40–51 (1992) 15. Nielsen, H.F., Mendelsohn, N., Moreau, J.J., Gudgin, M., Hadley, M.: SOAP version 1.2 part 1: Messaging framework. W3C recommendation, W3C (June 2003) 16. Pires, P.F., Benevides, M.R.F., Mattoso, M.: Building reliable web services compositions. In: Aksit, M., Mezini, M., Unland, R. (eds.) NODe 2002. LNCS, vol. 2591, pp. 7–10. Springer, Heidelberg (2003) 17. Reichert, M., Dadam, P.: ADEPTflex: Supporting Dynamic Changes of Workflow without Loosing Control. Journal of Intelligent Information Systems 10(2), 93–129 (1998) 18. Reichert, M., Rinderle, S., Kreher, U., Dadam, P.: Adaptive Process Management with ADEPT2. In: ICDE, pp. 1113–1114. IEEE, New York (2005) 19. Rinderle, S., Bassil, S., Reichert, M.: A Framework for Semantic Recovery Strategies in Case of Process Activity Failures. In: Manolopoulos, Y., Filipe, J., Constantopoulos, P., Cordeiro, J. (eds.) ICEIS, pp. 136–143 (2006) 20. Yang, Z., Liu, C.: Implementing a flexible compensation mechanism for business processes in web service environment. In: ICWS ’06. Intl. Conference on Web Services (2006)

Context-Aware Workflow Management Liliana Ardissono, Roberto Furnari, Anna Goy, Giovanna Petrone, and Marino Segnan Dipartimento di Informatica - Universit`a di Torino Corso Svizzera 185, 10149 Torino - Italy {liliana,furnari,goy,giovanna,marino}@di.unito.it

Abstract. We describe the CAWE framework for the management of contextaware workflow systems, based on Web Services. The framework is based on a hierarchical workflow representation supporting a synthetic and extensible specification of context-sensitive workflows, which can be executed by standard workflow engines. We have exploited the CAWE framework to develop a prototype application handling a medical guideline specifying the activities to be performed in order to monitor patients treated with blood thinners.

1 Introduction We present the CAWE (Context-Aware Workflow Execution) framework for the development of context-aware applications based on Web Service technologies, which adapt to the user features and the execution context. In order to support a flexible adaptation of the business logic, we have adopted a workflow-based approach, which enables the declarative specification of such logic. The CAWE framework is based on a hierarchical representation of the workflow, which specifies alternative, context-dependent courses of action, and on a declarative specification of the conditions determining the runtime selection of the appropriate context-dependent part of the workflow. In order to test the functionality offered by our framework, we developed a prototype system and we have instantiated it on the execution of medical workflows involving the cooperation of human actors playing different roles. The system may be accessed from the internet, by using a PC or a Smart Phone client. The resulting medical application supports the home assistance of patients affected by heart diseases and coordinates the activities of doctors, patient and other technical and administrative personnel during the execution of the clinical guidelines to be applied.

2 Dimensions in Context-Aware Adaptation Often, context-aware applications proposing personalized products/services to their users do not consider (at least explicitly) the fact that there are two different types of roles: the beneficiary of the product/service (henceforth, the service-user) and the user who interacts with the system to get the product/service (interacting-user). For instance, in an adaptive e-commerce application, a person could buy a product on behalf 

This work is supported by the EU (project WS-Diamond, grant IST-516933) and by MIUR (project QuaDRAnTIS).

L. Baresi, P. Fraternali, and G.-J. Houben (Eds.): ICWE 2007, LNCS 4607, pp. 47–52, 2007. c Springer-Verlag Berlin Heidelberg 2007 

48

L. Ardissono et al.

of somebody else [1]. Although the same person can play different roles, it is useful to distinguish them. In fact, both the service-user and the interacting-user can be the targets of adaptation, but the features to be taken into account, and what is adapted, differ in the two cases. For instance, a different product might be proposed, depending on the service-user’s preferences; however, the User Interface (UI) should be adapted to the device utilized by the interacting-user to connect to the system. The CAWE framework supports UI adaptation, targeted to the interacting-user’s context, and workflow adaptation, based on the context of the service-user; the latter is the focus of this paper. 2.1 UI and Workflow Adaptation in the CAWE Framework In the CAWE framework, the interaction is tailored to the features of the device used to connect to the system (e.g., screen size), and to the role of the interacting-user (e.g., a relative or a doctor), by generating UI pages with different content and layout. The adaptation of the workflow, described in detail in the following, consists of actuating different courses of action (activity paths) on the basis of the features of the context of execution. These context features belong to the service-user context. For instance, the clinical guideline of our medical application prescribes blood tests which can be performed at home or at the blood test lab, depending on the fact that the patient (service-user) is movable or not. The two alternative behaviors are associated to different activity paths, as the first one requires that a nurse visits the patient at home, while the second can be managed by taking the patient to the lab. 2.2 Service-User’s Context in Our Medical Application In order to provide a more concrete idea of the service-user context, we briefly decribe its representation within our medical application. The service-user is the patient, who benefits from the home assistance service. The patient’s context includes long-term and short-term information to separate stable data from features which might change during the service execution. The long-term information includes: (a) The personal context: this corresponds to the clinical record, which includes features such as the patient id, contact information, gender, age, prescribed therapy, date of the most recent blood test, and so forth. (b) The environment: this includes features such as the available resources (i.e., the medical equipment available at home). The short-term information includes: (a) The Personal context: this includes physiological data (e.g., blood pressure, hearth pulsation, ...), the patient’s mobility state (the “movable” feature specifies whether she can be transported by car, or she needs an ambulance), and the degree of urgency in treatments due to the patient’s health state. (b) The Environment: it includes the “social context” (i.e., the people who next to the patient), which can influence the course of action to be selected.

Context-Aware Workflow Management

49

3 The CAWE Framework The architecture of the CAWE framework includes various modules, wrapped by Web Service interfaces. Specifically, the context-aware workflow execution is supported by two modules: the Context-Aware Workflow Manager and the Context Manager. The Context-Aware Workflow Manager runs a workflow engine which executes the workflow activities by following the flow specification. However, when it encounters a context-dependent portion of the workflow, the engine invokes a Personalization Module which applies adaptation strategies to select the course of action to be performed. The Context Manager provides the other modules with contextual information during the execution of the application. 3.1 Workflow Representation In order to represent the context-dependent parts of the workflow, we introduce an abstraction hierarchy whose higher-level elements describe the activities to be performed in generic way. Specifically, we introduce the concept of abstract activity to denote an activity schema which does not directly specify a piece of business logic of the application. The actions to be executed in order to complete the abstract activity are selected at runtime, depending on the context state. Moreover, we define abstract workflow a workflow schema including at least one abstract activity: the workflow abstracts from the details of execution of at least one (context-dependent) activity. If a workflow does not contain any abstract activity, it represents a concrete workflow and it can be executed by the workflow engine without invoking the Personalization Module. Finally, each abstract activity is associated with a set of context-dependent implementations, representing the alternative courses of action which the workflow engine should execute, depending on the context. Each context-dependent implementation is a (possibly abstract) workflow and represents a subprocess to be performed in order to achieve the results of the abstract activity. Figure 1 depicts the abstract workflow of our medical application, which includes the following activities (abstract/concrete activity start with an uppercase/lowercase letters): 1. A doctor starts the workflow by setting the first blood test that the patient has to undergo (setFirstBloodTest(patient, date)). 2. The application books a blood test with a lab at the specified date (BookBloodTest(patient, date)). Then, it evaluates the time interval between the current date and the date of the blood test (eval(interval)). 3. If the patient’s health state is regular, she waits until the date of the test before doing any actions (onAlarm(date)). However, if warning symptoms, e.g., bleeding or fainting, occur before that date (onMessage ...), the urgency feature within the patient’s context is set to “high” (setUrgency(patient, “high”)), and the patient skips the wait. This is represented by means of a pick scope which includes the two competing courses of action.

50

L. Ardissono et al.

start

setFirstBloodTest(patient, date)

BookBloodTest(patient, date)

eval(interval)

onMessage: bleeding or fainting

pick onAlarm (interval)

setUrgency(patient, high)

ManageBloodCollection (patient, date, bloodResults) emailPatient(date, therapy) evaluateResults (patient,date,bloodResults,eval) storeTherapy(patient,date,therapy) no

yes eval=OK?

end

SendToHospital(patient)

Fig. 1. Abstract Workflow of Medical Guideline

4. At the specified date, or immediately after the occurrence of a warning symptom, a sample of blood is taken from the patient for the lab. Then, the lab analyzes the blood sample and returns the values of the measured blood parameters (ManageBloodCollection(patient, date, bloodResults)). 5. A doctor evaluates the results that are then stored, together with the doctor evaluation, into the patient’s context (evaluateResults(patient, date, bloodResults, eval)). 6. If the test results are good (eval=OK?), the doctor selects the date for the next blood test and sets the therapy to be followed until then (storeTherapy(patient, date, therapy)). Moreover, the application sends the patient an e-mail with the needed information (emailPatient(date, therapy)) and the flow restarts from item 2. Otherwise, the patient is notified to go to the hospital for further analyses (SendToHospital(patient)). Figure 2 shows the workflow specification of a context-dependent implementation suitable for patients who may be taken to the lab by car. The applicability condition of this implementation is movable=true, where movable is a context variable included in the short-term patient’s context. The application requests the appointment with the lab (requestLabApp(patient, date)), by invoking the Blood Test Lab Service1 , which returns a notification of the appointment, specifying time and place where to show up 1

We assume that the actors involved in the workflow have Web Service interfaces.

Context-Aware Workflow Management

start

requestLabApp (patient, date)

end

51

receiveLabAppNotification (patient, appCode, date, time, address)

emailPatient (appCode,date, time, address)

workflow specification of context-dependent implementation for movable patient

Fig. 2. Worflow Specifications of one of the Context-Dependent Implementations of Abstract Activity “BookBloodTest”

(receiveLabAppNotification(patient, appCode, date, time, address)). In turn, the application notifies the patient about the appointment (emailPatient(appCode, date, time, address)).2 3.2 Context-Aware Workflow Execution The workflow engine wrapped by the Context-Aware Workflow Manager creates an instance of the abstract workflow each time the starting activity of the workflow is performed for the first time. The context-aware execution of the workflow is based on the selection of paths, depending on decision points and on the selection of the concrete implementations of the abstract activities to be performed. When the workflow engine has to execute an abstract activity, it first invokes the Personalization Module, which retrieves the context-dependent implementations of the abstract activity and returns the one to be executed, together with the bindings for its variables. Then, the workflow engine executes the selected context-dependent implementation as a subprocess of the main process instance. At subprocess completion, the control returns to the abstract workflow, which moves to the execution of the next activity. The Personalization Module, invoked on an abstract activity, works as follows: first of all, if the abstract activity is associated to more than one context-dependent implementation, the module evaluates the applicability conditions of each candidate and it selects one of the applicable implementations for execution. Then, the module binds the context-dependent variables of the implementation to their current values, provided by the Context Manager.

4 Related Work The introduction of context awareness in workflow systems is mainly focused on Quality of Service management (e.g., [2]) and on the adaptation to the user’s device (e.g., [4]). An interesting approach in the area of Web Engineering is presented in [3], where the authors propose an extension to WebML to model multi-channel, context-aware Web applications. 2

Another context-dependent implementation, not shown for space reasons, specifies that, if the patient is non-movable, a nurse is requested, to collect the patient’s blood at home.

52

L. Ardissono et al.

In this paper, we attempt to look at workflow systems from a more general perspective, and we propose a framework for the management of applications which adapt to user preferences and requirements, as well as to context-aware aspects such as the physical environment or the available resources. The introduction of hierarchical workflows is usually related to the specification of compositional workflows. For instance, several workflow languages enable the designer to define complex activities which expand in workflows forming a composition hierarchy; e.g., see WS-BPEL [5] and process languages such as Petri Nets [6]. Our proposal differs from those approaches because it introduces a specialization hierarchy supporting the actuation of the same abstract activity in different ways.

5 Conclusions We have presented the CAWE framework for the development of applications composing Web Service suppliers in complex, long-lasting workflows. CAWE supports the customization of the service offered by the application to the beneficiary of the service, taking the execution context into account; moreover, it personalizes the UI to the user(s) interacting with the application to carry out the assigned tasks. The abstract activities and contextual conditions can be executed by a standard workflow engine because they simply include the invocation of a piece of code in their body. Indeed, the hierarchical workflow could be pre-processed by translating it to a flat workflow where abstract activities are replaced with decision points which fork on alternative workflow paths. However, our approach supports the conciseness and the readability of the resulting workflows, which could be very hard to understand, if represented as a flat graph including all the alternative courses of action. Moreover, it supports a seamless extension of the business logic of an application to take new contextual conditions and new courses of action into account. Finally, the introduction of the Personalization Module for the selection of context-dependent implementations supports the extension of the framework to the adoption of possibly complex personalization rules, without imposing restrictions on the workflow engines employed.

References 1. Ardissono, L., Goy, A.: Tailoring the interaction with users in Web stores. User Modeling and User-Adapted Interaction 10(4), 251–303 (2000) 2. Benlismane, D., Maamar, Z., Ghedira, C.: A view-based approach for tracking composite Web Services. In: Proc. of European Conference on Web Services (ECOWS-05), V¨axj¨o, Sweden, pp. 170–179 (2005) 3. Ceri, S., Daniel, F., Matera, M.: Extending webml for modeling multi-channel contextaware web applications. In: WISE - MMIS’03 IEEE Computer Society Workshop (2003) 4. Keidl, M., Kemper, A.: Towards context-aware adaptable Web Services. In: Proc. of 13th Int. World Wide Web Conference (WWW’2004), New York, pp. 55–65 (2004) 5. OASIS: OASIS Web Services Business Process Execution Language (2005), http://www. oasis-open.org/committees/documents.php?wg abbrev=wsbpel 6. van der Aalst, W.: Making work flow: on the application of Petri Nets to Business Process Management. In: Proc. of 23rd Int. Conf. on Applications and Theory of Petri Nets, Adelaide, South Australia, pp. 1–22 (2002)

Practical Methods for Adapting Services Using Enterprise Service Bus* Hyun Jung La, Jeong Seop Bae, Soo Ho Chang, and Soo Dong Kim Department of Computer Science Soongsil University, Seoul, Korea 511 Sangdo-Dong, Dongjak-Ku, Seoul, Korea 156-743 {hjla, jsbae, shchang}@otlab.ssu.ac.kr, [email protected]

Abstract. In service-oriented computing (SOC), services are designed not just for a dedicated client but for a family of potential clients. For services to be generic and serviceable to different clients, service variability among the clients must be analyzed and modeled into service components. Enterprise Service Bus (ESB) is an architectural framework for service integration, but it does not provide effective adaptation mechanisms. Hence, it is desirable to devise techniques to adapt services on ESB for specific service requests. In this paper, we identify four types of service variability, and we present methods to adapt services provided on ESB. These methods can be practically applied in designing highly adaptable services on ESB.

1 Introduction In service-oriented computing (SOC), services are designed not just for a dedicated client, but for a family of potential clients. A key problem in developing such common services is to model the variability embedded in common features, and to be able to adapt common services for specific service requests [1][2]. Another case requiring service adaption is when there is a partial matching between available services and services expected by clients. That is, an available service can potentially fulfill the service expected by a client, but they do not match in full [3]. Hence, identifying types of variability which may occur on services and how service variability can be modeled into adaptable services are two essential prerequisites to designing highly reusable and applicable services. Enterprise Service Bus (ESB) is an architectural framework to integrate heterogeneous services and applications in distributed network [4]. It provides the integration functionality through transformation, communication, and routing. Beyond this, however, ESB does not provide methods for service adaptation. Hence, it is desirable to devise techniques to adapt services on ESB for specific service requests. In this paper, we first identify four types of variability which may occur on services. Then, we present adaptation methods for services on ESB; Workflow Mediator, Service Binder, Interface Transformer, and Logic Broker. Each method is presented *

This work was supported by the Korea Science and Engineering Foundation (KOSEF) grant funded by the Korea government (R01-2005-000-11215-0 (2007)).

L. Baresi, P. Fraternali, and G.-J. Houben (Eds.): ICWE 2007, LNCS 4607, pp. 53–58, 2007. © Springer-Verlag Berlin Heidelberg 2007

54

H.J. La et al.

with its overall scheme and a specific adaptation algorithm based on ESB specification. These methods can be practically applied in designing highly adaptable services on ESB.

2 Related Works Sam’s work proposes a customization framework for dynamic Web services [5]. Based on the comparison to syntactic/semantic aspects and to the constraint on input and output, it suggests a matchmaking process and conflict resolution mechanism for service adaptation. However, this work deals with only interface adaptation. Jiang’s work proposes a categorization of variation points and introduces a pattern-based approach for managing the variation points [6]. However, instructions for identifying variability and adaptation are not included. Herault’s work proposes an approach to mediating and executing operations on ESB [7]. It explains how mediation can be achieved on ESB. However, how they mediation is performed is not given in enough details. Schmidt’s work addresses a mediation model on ESB, which reconfigures the links between bus service providers and requesters to create dynamic alternations to routing and to modify their behaviors [8]. It treats interface mediations and policy mediations. However, practical adaptation mechanisms for these are not given. From our survey, we observe that current research works treat service adaptation at conceptual level rather than design level, and adaptation methods on ESB treat only interface and logic variability. In this paper, we treat four types of service variability and suggest design-level practical methods for adapting services on ESB.

3 Types of Service Variability In this section, we identify four places where service variability may occur [9]. Workflow Variability. A business process consists of a sequence of activities, i.e. unit services [10], and this sequence is called a workflow. For a given business process, the workflow may slightly vary, depending on different service clients. That is, some unit services in a workflow may be optional, and there can be more than one execution path for the given workflow. Composition Variability. Services are discovered at runtime, and there may be more than one unit service which fulfills the required functionality. In this case, variation occurs on binding the right services. That is, for each specific request, one of the candidate unit services must be composed. Interface Variability. Variability on interfaces occurs when the interfaces of unit services do not match to the interfaces of published services. Even if the functionality of a unit service is met by the functionality of a registered service, the signatures of interface and the semantics may not fully match. This should be modeled during service engineering, and the mismatch should be resolved by some interface adaptation mechanism.

Practical Methods for Adapting Services Using Enterprise Service Bus

55

Logic Variability. Service component includes operations for providing service functionality. There may be minor variation on the business logic or algorithm for the service component. This micro-level logic variability should be modeled into a service component, so that it can be tailored for each invocation.

4 Adaptation Managers for Services on EBS In SOC, service clients do not have access to the internal details of services, and hence adaptation of a service is performed by an external software agent, which we call it adaptation manager. We propose a general scheme of designing ESB-based adaptation mangers which can be used in resolving all four types of variability. To implement adaptation managers on ESB, we define two kinds of components; listener and adaptor. As shown in Figure 1, a listener with «Listener» stereotype listens and intercepts service requests made by clients. And, it determines the required adaptation for each invocation, and invokes appropriate adaptors. The adaptors actually perform the requested adaptation over service components through end-points of ESB. Figure 1, shows four types of adaptors, which are denoted with «adaptor» stereotype. Client Program

BPEL Engine

Service Component #1

Service Component #2

…

Service Component #n

(4) Invoked adapted components End End point point

(1) Request Invocation

End point

Enterprise Service Bus (2) Listen to Invocation «Listener» Invocation Listener #1

«Listener» Invocation Listener #2

…

«Listener» Invocation Listener #n

(3) Resolve variability «adaptor» Workflow Mediator

«adaptor» Service Binder

«adaptor» Interface Transformer

«adaptor» Logic Broker

Adaptation Manager

Fig. 1. Adaptation Manager deployed on ESB

4.1 Workflow Mediator for Workflow Variability Workflow Mediator is to adapt the workflow of services, and it is implemented with Mediator pattern. When modeling workflow variability, variation points of workflow type and their relevant variants are identified and stored in the workflow repository. Service Requested

Unit Service a

Path #1

Unit Service b

«Workflow Mediator» Unit Service c

Look Up Workflow Variability

1st invocation

«Service Component»

2nd invocation

«Service Component»

Path #2

Workflow Variants

3rd invocation

Workflow Repository

Fig. 2. Pattern of Workflow Mediator

«Service Component»

56

H.J. La et al.

As shown in Figure 2, the workflow mediator analyzes service requirements using user’s preference and context information, determines an appropriate workflow variant from the repository, and makes a series of invocations over the participating service components by using the rule repository. We define two adaptation methods for workflow mediators as shown in Figure 3; determineWorkflow() and conctroServicelInvocation(). The determineWorkflow() method is to select the most appropriate workflow from the repository based on the service requirements. This operation returns a path of the BPEL specification which will be executed. The conctroServicelInvocation() method is to execute the workflow by invoking appropriate service components. public String determineWorkflow(MessageExchange exchange) throws MessagingException { String BPELPath; // path of the BPEL documents Message sourceMsg = getSourceMsg(exchange); // to get source invocation message Vector workflowVariant = getWorkflowVariants(exchange); // to get candidate workflows // to get a particular workflow among candidate workflow based on the condition for ( int i = 0 ; i < workflowVariant.size() ; i++ ) { if (compare (workfowVariant[i], condition) == true) { BPELPath = workflowVariant[i].path; return BPELPath; } } } public void controlServiceInvocation(MessageExchange exchange) throws MessagingException { Message sourceMsg = getSourceMsg(exchange); // to get source invocation message Vector serviceComp = getServiceComponents (exchange); // to get the service components Rule rule = getRule (exchange ) // to get the rule for the exchange // to invoke a service component by comparing when the service component is invoked for ( int i = 0 ; i < serviceComp.size() ; i++ ) { if (compare (serviceComp[i].case, rule.case) == true) CallComponents (serviceComp[i] } }

Fig. 3. Algorithm of Workflow Mediator

4.2 Service Binder for Composition Variability Service Binder is to adapt the service compositions, and it is implemented with dynamic selection pattern. When modeling composition variability, variation points of composition type and their variants are identified and stored in composition repository.

Unit Service

Preference

«Service Binder»

Service Interface #1

Service Interface #2 Look Up Selections

Composition Repository

Fig. 4. Pattern of Service Binder

Practical Methods for Adapting Services Using Enterprise Service Bus

57

public String determineInterface (MessageExchange exchange) throw MessageException{ Message sourceMsg= getSourceMsg(exchange); // to get source invocation message Vector endPoints = getEndPoint(exchange); // to get possible end points Rule rule = getRule (exchange); //to get selection rule for the exchange String targetEndPoint; //to save a target end point // to get an appropriate end point for (int i=0;i