On Utilizing Web Service Equivalence for Supporting the Composition Life Cycle

On Utilizing Web Service Equivalence for Supporting the Composition Life Cycle

Stefanie Rinderle-Ma (University of Vienna, Austria), Manfred Reichert (University of Ulm, Germany) and Martin Jurisch (Flow GmbH, Germany)
Copyright: © 2011 |Pages: 27
DOI: 10.4018/jwsr.2011010103
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Deciding on Web service equivalence in process-aware service compositions is a crucial challenge throughout the composition life cycle. However, restricting such decisions to (activity) label equivalence is not sufficient for many practical applications: if two activities and Web services respectively have equivalent labels, does this necessarily mean they are equivalent as well? In many scenarios (e.g., evolution of a composition schema or mining of completed composition instances), other factors also play an important role. Examples include context information (e.g., input and output messages) and information on the position of Web services within compositions. In this paper, the authors introduce the whole composition life cycle and discuss specific requirements for Web service equivalence along its different phases. The authors define adequate equivalence notions for the design, execution, analysis, and evolution of service compositions. This paper focuses on attribute and position equivalence and contributes a new understanding and treatment of equivalence notions in service compositions.
Article Preview

1 Introduction

The challenge of providing adequate notions for semantic equivalence constitutes an important research subject in many areas. In federated databases or data warehouses, for example, data from heterogeneous sources need to be integrated within one schema. Amongst other problems, schema integration has to deal with synonyms and homonyms (Rahm & Bernstein, 2001); i.e., equivalent attribute labels describing different data, or attributes with different labels but describing same data. The capability of the integration process to handle such cases is crucial for its success.

1.1 Problem Statement

Similar problems emerge when designing distributed processes as can be found in inter-organizational partner settings. As an example consider a collaboration between partners from the US, India and Germany, which shall be implemented as Web service choreography. At least, we need to translate Web service labels between the service compositions of the partners. Still, such language-related aspects can be easily handled using ontologies since it can be taken for granted that service labels confirm and bestaetigen (German term for confirm) are homonyms. However, in many applications such knowledge is not at hand. One important use case is the mining of (completed) executions of service compositions and service orchestrations respectively; i.e., techniques to derive composition schemas from execution logs (van der Aalst & Verbeek, 2008). Since there is no a-priori knowledge on such logs, basically, it cannot be taken for granted that Web services with equivalent labels are equivalent themselves. Regarding our example, service confirm might have a different “meaning” depending on whether it is performed by a manager or a secretary. Obviously, we also need to consider information about the context of a service execution when defining equivalence notions for Web services.

Another use case concerns the evolution of service compositions. Here, a composition schema is structurally changed by adding, deleting or moving steps (i.e., activities representing Web service executions). The ability to adequately support such changes has become crucial since a turbulent market and a continuously changing environment force any enterprise to quickly and correctly adapt their running business processes and service compositions, respectively (Mutschler, Reichert, & Bumiller, 2008). In this context, a service orchestration engine must enable both ad-hoc changes of single instances of a composition schema at runtime (e.g., to react on exceptions) and changes of a composition schema itself. The latter may have to be propagated to already running instances of a composition schema and become necessary, for example, when new regulations come into effect or the composition schema is redesigned (e.g., due to business reengineering efforts). If changes are concurrently applied at composition schema and composition instance level, however, it becomes crucial to carefully decide on the equivalence of the affected Web services. If, for example, two Web services with equivalent label are inserted at both schema and instance level, we have to decide on their actual equivalence in order to avoid duplicate insertions at the instance level afterwards (Rinderle, Reichert & Dadam, 2004a).

Complete Article List

Search this Journal:
Reset
Open Access Articles
Volume 14: 4 Issues (2017)
Volume 13: 4 Issues (2016)
Volume 12: 4 Issues (2015)
Volume 11: 4 Issues (2014)
Volume 10: 4 Issues (2013)
Volume 9: 4 Issues (2012)
Volume 8: 4 Issues (2011)
Volume 7: 4 Issues (2010)
Volume 6: 4 Issues (2009)
Volume 5: 4 Issues (2008)
Volume 4: 4 Issues (2007)
Volume 3: 4 Issues (2006)
Volume 2: 4 Issues (2005)
Volume 1: 4 Issues (2004)
View Complete Journal Contents Listing