matter of fact, the choreography generalizes the concept of orchestration to distributed ...... liver(id, cost, adS, adC), deliveryInfo(id,cost)). Then, depending on ...
Universit` a degli Studi di Torino Scuola di Dottorato in Scienza e Alta Tecnologia Tesi di Dottorato di Ricerca in Scienza e Alta Teconologia Indirizzo: Informatica
AN EVENT-BASED MODEL FOR THE MANAGEMENT OF CHOREOGRAPHED SERVICES
Roberto Furnari Tutor: Prof. Liliana Ardissono XXII Ciclo, Gennaio 2010
Universit`a degli Studi di Torino
Scuola di Dottorato in Scienza e Alta Tecnologia
AN EVENT-BASED MODEL FOR THE MANAGEMENT OF CHOREOGRAPHED SERVICES
Roberto Furnari
Acknowledgments I would like to thank my supervisor Prof. Liliana Ardissono who led me in this work and the reviewers Prof. Dr. Johann Eder and Senior Researcher Khalil Drira and Dr. Eng. Riadh Ben Halima for their careful evaluation of this thesis and their useful comments. In the following some more personal thanks in Italian.
Ringraziamenti Tante sono le persone che dovrei ringraziare e che magari qui non si ritroveranno, quindi partirei con un grazie a tutti quelli che per un motivo o per l’altro non si ritroveranno in quanto segue. Per prima cosa i miei ringraziamenti vanno alla Prof. Liliana Ardissono per avermi seguito durante questo lavoro sempre in modo attento e preciso. Con lei ovviamente tutto il gruppo con cui ho condiviso per un pochino l’ufficio e poi diversi lavori e discussioni: Anna Goy, Giovanna Petrone, Marino Segnan. In particolare un ringraziamento ad Anna per il suo continuo interessamento e le sue preziose consulenze. Con piacere ringrazio il Prof. Luca Console per avermi fatto partecipare al progetto WS-Diamond, un’esperienza sicuramente importante, e per il suo rinnovato interessamento. L’universita’ l’avevo lasciata col professor Torasso, che poi ho ritrovato con piacere come coordinatore del dottorato e come tutor dei primi due anni; non posso non ringraziarlo per la sua grande rinnovata disponibilita’. I miei compagni di ufficio, quelli passati e quelli nuovi. Il Bocconiano e i bei momenti di vita vissuta trascorsi, Petru e Omar che completavano il quartetto degli anni d’oro. Scappati loro nuovi graditi inquilini li hanno degnamente rimpiazzati: Pier e la sua onniscienza (sara’ la scrivania), la consulente di inglese Fabiana caduta anche lei nella trappola del dottorato, e il buon Michele. Tutti in parti diverse per un po’ hanno sopportato i miei
lamenti .. e questo gia’ e’ degno di nota. Sono stati tre anni segnati dall’onore di appartenere al mitico ciclo XXII. E’ stato un po’ come un tuffo nel passato da studente, a partire da Bertinoro in poi .... un ringraziamento a tutti a partire dall’omonimo coscritto professore con cui ho condiviso i malanni dell’eta’, e tutti gli altri....chi condividera’ con me il giorno X, chi ha gia’ dato, e chi presto avra’ il suo giorno X, con i miei sinceri migliori in bocca al lupo per tutto. Un ringraziamento anche a Federica per aver creduto nella creatura e nel povero Magnificus e ad Elena G. perche’ tutti e due conosciamo (temo solo noi) le grandi proprieta’ del fungo teorico. Prima del dottorato i sei anni di lavoro... un ringraziamento a Sinedita s.r.l. per l’importante esperienza professionale vissuta e per la continua stima e fiducia dimostrata. A partire dal Dott. Agus a tutti i capi e ai mitici colleghi, e spesso pure qualche cliente. Un’esperienza fondamentale che mi ha fatto vivere questa esperienza in modo sicuramente piu’ maturo e consapevole. Un ringraziamento agli amici tutti, in particolare a Federico, prezioso aiuto tecnico-matematico e linguistico e soprattutto umano. La scelta fatta di provare l’avventura del dottorato non e’ stata banale e devo ringraziare la mia famiglia per non avermi mai fatto mancare il supporto e l’affetto necessario. Ho molto apprezzato (anche gli orsi sanno apprezzare). Genitori nonni fratelli (+ Laura) e Ginetto pure. Un ringraziamento particolare alla nuova arrivata Giulia (migliore pubblicazione non potevate fare) e ai nuovi parenti acquisiti ... il signor Nicola e Annalisa, nonno Antonio e nonna Mafalda, la mitica Anto e Sandruccio, che mi hanno accolto senza troppe domande e con tanto affetto. Il sicuro special thanks to Raffaella, per tutto. Roby. 2
Abstract This thesis presents a mediation framework supporting a seamless integration of web services in choreographed services, supporting the conciliation of interaction protocol mismatches. The approach is based on an event-based management of choreographed services that, together with an action based execution of web services, allows a more flexible execution of web service choreography. This is obtained by means of: • a Context Management Service which handles the context of the composite service and propagates the relevant business data and synchronization information to the web services participating to the composite service; • a set of knowledge-based adapters (the Communication Interfaces) which decouple the interaction between web services and run them as autonomous agents operating in context-dependent way. By decoupling the web service interaction, the framework addresses several interaction protocol mismatches, ranging from differences in the signatures of the messages, to the order and number of the messages to be exchanged, including cross-protocol mismatches involving more than two interacting peers. After the introduction of the problem and the presentation of the mismatch patterns considered, this thesis describes the proposed model focusing on its architecture, on the mediation model implemented and on its runtime management. In order to assess the applicability of the proposed approach to real world cases, a prototype framework implementation is presented together with the implementation of a use case example. The proposed model has proved to be flexible and easily configurable and able to effectively address several protocol mismatches. Moreover it can be used to integrate efficiently different kinds of heterogeneous services.
3
List of Figures
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8
Web service adapter. . . . . . . . . . . . . . . . . . . . . . Choreography adapter. . . . . . . . . . . . . . . . . . . . . Operational mismatch: name and order of parameters. . . Operational mismatch: parameters not used. . . . . . . . Message split mismatch - One to Many message pattern. . Message merge mismatch - Many to One message pattern. Extra message mismatch - different services involved. . . . Message Ordering mismatch - Deadlock. . . . . . . . . . .
. . . . . . . .
30 32 34 34 36 37 38 40
3.1 3.2
Framework architecture. . . . . . . . . . . . . . . . . . . . . CI interactions. . . . . . . . . . . . . . . . . . . . . . . . . .
45 47
4.1 4.2 4.3 4.4 4.5 4.6
Web service B interaction protocol. . . . . . . . . . . . . . . From interaction protocol to token based representation. . . Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ChorX choreography after token decoration. . . . . . . . . . Choreography Actions. . . . . . . . . . . . . . . . . . . . . . Protocol mismatch resolution between web service WSA (at the right) and the composite web service ChorX (at the left). (a). Action-based representation of the interaction protocol of WSA, within composite service ChorX. . . . . . . . . . .
54 59 64 66 68
4.7 5.1 5.2 5.3
Execution flow, example 1. . . . . . . . . . . . . . . . . . . Execution flow, example 2. . . . . . . . . . . . . . . . . . . Inizialization phase: Activation. . . . . . . . . . . . . . . . .
6.1 6.2 6.3 6.4 6.5 6.6 6.7
Token mapping. . . . . . . . . . . . . . One-to-One mapping rule. . . . . . . . One-to-N mapping rule. . . . . . . . . N-to-One mapping rule - Send case. . N-to-One mapping rule - Receive case. Unspecified reception. . . . . . . . . . Deadlock - First case. . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
70 74 83 83 87 100 103 104 106 107 111 112 5
LIST OF FIGURES 6.8 6.9 6.10 6.11
Deadlock - Second case. . . One-to-N mapping - parallel N-to-One mapping - parallel Request-response example. .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
114 115 117 118
7.1 7.2 7.3 7.4 7.5
Software architecture. . . . . . . . . . . . . . . . . CI Architecture. . . . . . . . . . . . . . . . . . . . ActionDescr states transition. . . . . . . . . . . . . CIProxyInWS logical architecture. . . . . . . . . . CIProxyInWS - WS interaction sequence diagram.
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
122 125 126 129 131
8.1 8.2 8.3 8.4 8.5 8.6
BookShopping choreography. . . . . . . NewSupplier (NSU) interaction protocol. Fragment of the CI KB file of NSU. . . Fragment of the CI KB file of NSU. . . GigaWriter. . . . . . . . . . . . . . . . . Giga Browser. . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
137 138 140 146 150 154
10.1 10.2 10.3 10.4 10.5
Architecture evolution. . . Prototype. . . . . . . . . . Web service orchestration. WS adapter. . . . . . . . . Data adapter. . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
166 168 169 170 174
6
. . . . .
. . . . . . branches. branches. . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
List of Tables
2.1
Protocol mismatch considered. . . . . . . . . . . . . . . . .
6.1 6.2 6.3
Data Mapping Table of WSA within choreography ChorX. . 93 Message Mapping Table of WSA within choreography ChorX. 96 Token Mapping Table of WSA within choreography ChorX. 97
8.1
Data Mapping Table of NSU within the BookShopping choreography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Message Mapping Table of NSU within the BookShopping choreography. . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Token Mapping Table of NSU within the BookShopping choreography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
8.2 8.3 9.1 9.2 9.3
41
Number of exchanged pieces of information. . . . . . . . . . 159 Weight of exchanged pieces of information. . . . . . . . . . 160 Efforts (time) required by the two approaches. . . . . . . . 164
7
Contents
1 Introduction 1.1 Introduction to the problem 1.2 Key research issues . . . . . 1.3 The proposed solution . . . 1.4 Thesis contribution . . . . . 1.5 Thesis outline . . . . . . . .
. . . . .
. . . . .
13 15 17 19 21 22
2 Problem statement 2.1 Signature mismatch . . . . . . . . . . . . . . . . . . . . . 2.2 Protocol mismatch . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Message split mismatch (One-to-N mapping) . . . 2.2.2 Message merge mismatch (N-to-One mapping) . . 2.2.3 Extra message mismatch (Zero-to-One mapping) . 2.2.4 Missing message mismatch (One-to-Zero mapping) 2.2.5 Message Ordering mismatch . . . . . . . . . . . . . 2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
25 33 35 35 36 37 38 39 40
framework architecture Communication Interface (CI) . . . . . . . . . . . . . . . . . Context Management Service . . . . . . . . . . . . . . . . . Overview of the execution model . . . . . . . . . . . . . . .
43 46 47 49
4 The mediation model 4.1 Token-based representation of an interaction protocol . . . 4.1.1 Interaction protocol representation . . . . . . . . . . 4.1.2 Action based representation of a web service . . . . 4.1.3 Translation of an interaction protocol to the token based representation . . . . . . . . . . . . . . . . . . 4.2 Token-based representation of a choreographed service . . . 4.3 Token-based representation of a web service in the context of a choreographed service . . . . . . . . . . . . . . . . . . .
51 51 52 55
3 The 3.1 3.2 3.3
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
59 64 69 9
CONTENTS 5 Management of a composite service 5.1 Start-up phase . . . . . . . . . . . . 5.2 Initialization phase . . . . . . . . . . 5.3 Runtime phase . . . . . . . . . . . . 5.3.1 Context Management Service 5.3.2 Communication Interface . . 5.4 Execution flow examples . . . . . . . 5.5 Discussion . . . . . . . . . . . . . . . 5.6 Details on the initialization phase . . 5.6.1 Activation . . . . . . . . . . . 5.6.2 Registration . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
6 Integration of a web service in a composite service 6.1 The integration process . . . . . . . . . . . . . . . . . . . 6.1.1 Phase 1 - Data Mapping . . . . . . . . . . . . . . . 6.1.2 Phase 2 - Message Mapping . . . . . . . . . . . . . 6.1.3 Phase 3 - Token Mapping. . . . . . . . . . . . . . . 6.1.4 Phase 4 - CI KB Updating. . . . . . . . . . . . . . 6.1.5 Phase 5 - Validation. . . . . . . . . . . . . . . . . . 6.2 Mapping Rules for CI KB updating . . . . . . . . . . . . . 6.2.1 One-to-one mapping . . . . . . . . . . . . . . . . . 6.2.2 One-to-N mapping (Message split mismatch) . . . 6.2.3 N-to-One mapping (Message merge mismatch) . . 6.2.4 Zero-to-One mapping (Extra message mismatch). . 6.2.5 One-to-Zero mapping (Missing message mismatch) 6.3 Special cases . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Message Ordering . . . . . . . . . . . . . . . . . . 6.3.2 Mapping involving parallel branches . . . . . . . . 6.3.3 A Request-response example . . . . . . . . . . . . 6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .
75 76 77 77 78 78 81 84 85 86 87
. . . . . . . . . . . . . . . . .
89 92 93 96 97 99 101 102 103 105 105 108 109 110 111 115 117 118
7 Prototype 121 7.1 Context Management Service (CtxMg) . . . . . . . . . . . . 123 7.2 The Communication interface (CI) . . . . . . . . . . . . . . 123 10
CONTENTS
7.3 7.4
7.2.1 The KernelCI . . . . . . . . . . . . . . . . . 7.2.2 The CIProxyOUT and the CIProxyIN . . . 7.2.3 CIProxyOUT and CIProxyIN instantiations Testing Tools . . . . . . . . . . . . . . . . . . . . . Hint at software delivery and configuration . . . .
8 Scenario 8.1 The BookShopping choreography . 8.2 The web service to integrate . . . 8.3 The integration process . . . . . . 8.3.1 Phase 1 - Data mapping . . 8.3.2 Phase 2 - Message mapping 8.3.3 Phase 3 - Token mapping . 8.3.4 Phase 4 - CI KB updating . 8.4 Run time test . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
9 Evaluation of the mediation framework 9.1 Evaluation of the software architecture . . 9.1.1 Capability to handle heterogeneous 9.1.2 Performance and scalability . . . . 9.2 Evaluation of the integration effort . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . software . . . . . . . . . .
. . . . .
. . . . . . . .
. . . .
. . . . .
. . . . . . . .
. . . .
. . . . .
. . . . . . . .
. . . .
. . . . .
. . . . . . . .
. . . .
. . . . .
125 127 128 130 133
. . . . . . . .
135 135 138 139 140 141 142 143 148
. . . .
155 155 156 157 160
10 Framework Exploitation 165 10.1 Using services “as they are” . . . . . . . . . . . . . . . . . . 165 10.2 Classical web service adapter . . . . . . . . . . . . . . . . . 169 10.3 Data mediation . . . . . . . . . . . . . . . . . . . . . . . . . 172 11 Related work 11.1 Adaptation . . . . . . . . . . . . . . . . . . . . 11.1.1 Software component adaptation . . . . . 11.1.2 Web service adaptation . . . . . . . . . 11.2 Coordination and mediation frameworks . . . . 11.3 Hints on related topics . . . . . . . . . . . . . . 11.3.1 Data mediation and automatic mapping
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
177 177 178 179 185 190 191 11
CONTENTS 11.3.2 Choreography representations . . . . . . . . . . . . . 192 12 Conclusions
12
195
1 Introduction
In software engineering the term interoperability has been coined in order to define the ability of two or more systems or components to exchange information and to use the information that has been exchanged [49]. In recent years an important contribution to the achievement of interoperability is represented by the introduction of a stack of protocols that are in general referred as web services technologies [3]. A web service is defined by W3C as “a software system designed to support interoperable machineto-machine interaction over a network. It has an interface described in a machine-processable format (specifically Web Services Description Language WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards”[106]. The point is that, thanks to the well acceptation of the proposed standards, both by the academic and industrial world, web services make possible, or at list more achievable, the interoperation between applications; issue followed without the expected success by other similar initiatives in 13
CHAPTER 1. INTRODUCTION the past years1 . As mentioned in the above definition, the base standards consist of the Web Services Description Language (WSDL) [102] used to describe the interface of the services, the Simple Object Access Protocol [103] concerning the format of the messages exchanged, together with the Universal Description Discovery and Integration (UDDI) [97] defining the registry used as discovery system. In this scenario applications published as web services can set-up collaborations more easily, using the common communication platform defined by the provided standards. The general idea is to build an open environment where applications offer their functionalities in form of web service operations and other applications use them. The opportunity to have several services deliverable in a standardized format led to the possibility to create new services by composing existing services. This is a core concept of the Service Oriented Computing (SOC) [85], that is a new computing paradigm that utilizes services as the basic constructs to support the development of rapid, low-cost and easy composition of distributed applications even in heterogeneous environments. As stated in [84], the visionary promise of Service Oriented Computing is a world of cooperating services where application components are assembled with little effort into a network of services that can be loosely coupled to create flexible dynamic business processes and agile applications that may span organisations and computing platforms. Services composition is realized in Service Oriented Computing by means of web service orchestrations and choreographies, that specify composite applications whose business logic is managed, respectively, in a centralized or 1 Consider for instance the Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA), Microsoft’s Distributed Component Object Model (DCOM) or Sun Microsystems’s Java/Remote Method Invocation (RMI); see [3] for a survey of the different proposed tools.
14
1.1. INTRODUCTION TO THE PROBLEM decentralized way; see [86]. Specifically, in an orchestrated service, a centralized application controls the business logic of the composite service and invokes web service suppliers as needed. On the contrary, a choreographed service results from the cooperation of multiple web services which coordinate the activities to be performed via message passing; in this case, the business logic of the composite service is distributed among the participating web services and none of them has a complete control over it. As a matter of fact, the choreography generalizes the concept of orchestration to distributed control.
1.1 Introduction to the problem The set up and management of a composite service is challenged by the heterogeneity of the web services to be integrated: although web service technology addresses the heterogeneity of execution platforms, it does not help to solve data and protocol mismatches, which are usually addressed by developing ad hoc adapters (see Chapter 2). In particular, the protocol mismatches which are the focus of this work, are problematic from the viewpoint of both composite services and individual web service providers: • On the one hand, the exploitation of alternative web service providers filling the same role within a composite service (i.e., the web service replacement (see Chapter 2)) is problematic because the interaction logic has to be adapted to different interaction protocols. • On the other hand, if an individual web service provider wants to participate to more than one existing composite service (e.g., some public choreographed services) it needs an adapter for each service. 15
CHAPTER 1. INTRODUCTION The idea of reusing and composing exiting services, highlights the need of interface adaptation: often services that aim at collaborating are hampered by differences in their interfaces. This happens when services deliver their functionalities by means of simple atomic operations, and the problem is more challenging when more complex services adopt complex form of interactions based on conversations. These problems become even more evident when collaborations based on conversation involve several web services that collaborate following complex multi peers conversation. This is the case of web service choreographies (see [86, 34]). A model of collaboration expressed as a choreography describes the observable exchange of messages among the involved web services from a global perspective; thus it defines how each web service has to behave in order to take part in the composite service. In such a scenario a web service aiming at participating to a given choreography has to adhere to the prescribed model implementing the required behavior. Therefore existing services, that already implement an own behavior, have to adapt to the behavior imposed by the choreography. This is a big obstacle that hampers the exploitation of web service compositions based on choreography in the real world. The difficulty to realize web service choreography is related to two main aspects: • the rigidity of the choreography definition, that does not include flexibility on its model (at least in its standard definition); • the nature of the message-oriented coordination model underlying a web services choreography. A message needs to have a sender and a receiver and makes a strong coupling between them. Moreover with the growing of the number of the services involved, the resulting 16
1.2. KEY RESEARCH ISSUES choreography becomes too much complex, mainly due to the peer to peer nature of coordination and data propagation. On the other hand, the choreography specification needs to be rigid because it defines common rules that drive the collaboration process between the involved services. Each service relies on this rigidity to correctly carry out the collaboration; i.e. if a service respects the choreography specification it knows that the interaction succeed (assuming the reliability of all the services involved). Moreover, the communication model implemented by web services is based on messages, and this is part of their success. Furthermore these two features characterize web services choreographies in their actual definition and have to be considered in the model proposed in this thesis.
1.2 Key research issues The core research issue that this thesis addresses is how is possible to provide a seamless execution of web service choreography. In the research of a solution to this problem, starting from the considerations of Section 1.1, two base hypotheses have to be taken into account: • the collaboration among several services is expressed by using a choreography; • existing web services are message-based and the approach proposed has to deal with this. Starting from these points, the need is to offer an execution environment where web services can collaborate in a seamless way, overcoming 17
CHAPTER 1. INTRODUCTION the differences between their behavior model and the one expected by the choreography. In order to achieve this general goal, some related more specific issues can be identified. • The web service choreography representation and the execution model currently in use hamper the wide diffusion of choreographed services; these limits have to be relaxed (taking in consideration the above mentioned hypotheses). • The constraints imposed by the coupling between senders and receivers in the message oriented coordination model have to be relaxed in order to permit a more flexible and malleable execution of choreographed services. • The participation of a new web service in a given choreography has to be achieved without changing the business logic of the service. • The definition of the adaptation logic has to abstract from the implementation of the service and has to be expressed in a declarative way. • The effort required to integrate a new service in a given choreography must be minimized in order to make collaborations based on choreography more appealing. This list represents a sort of checklist that drove the development of the work presented in this thesis. 18
1.3. THE PROPOSED SOLUTION
1.3 The proposed solution Interface mismatches are in general managed by using an adapter (see Chapters 2 and 11) that mediates between the expected interface and the one implemented by the service. The implementation, the testing, the deploying, and the maintenance of adapters can be a costly and error prone activity, specially if is needed to deal with the multiplicity of interfaces required from a service participating to different collaborations. This leads to the need of defining a new mediation tool based on high-level concepts, as opposed to implementing adapters using programming languages extended with basic message manipulation primitives. Moreover the general problem addressed by adapters has been mainly studied with respect to bilateral interactions and not from the perspective of a web service choreography where several services interact by means of complex conversation models. Therefore this work builds on the idea that a general run-time model for composite service management can be developed by abstracting from the flow details imposed by the message-oriented coordination. Indeed, during the execution of a composite service, it is possible to abstract from several message flow details, provided that the data dependencies and synchronization constraints imposed by the business logics of all the involved web services are respected. In the proposed framework, business data and synchronization information are propagated as context information in the composite service according to the Publish and Subscribe pattern. Moreover, web services are managed in an event-driven way [64] in order to enable them to perform their operations in context-dependent way. 19
CHAPTER 1. INTRODUCTION
The main features of the proposed solution are the following: • The message oriented coordination and the SOA notion of routing are replaced by the notion of publishing, matching an emitter to the interested handlers. Thus an event-based computational approach is proposed in order to decouple each service to the others participant services and to relax the management of the coordination aspects. The framework is based on the runtime management of a choreography context storing the business data and synchronization information needed to manage the composite service. • The initial representation of the choreography and service communication interface are enhanced in order to provide a new model where the aspects related to synchronization, expressed by means of pieces of information called tokens, are explicitly represented. By this representation an action based representation of the web services is derived. Moreover is used a declarative description of the synchronization constraints to be met, and of the mappings to be applied in order to conciliate mismatches. • The mediation model proposed is supported by a framework architecture where several Communication Interface components, wrapping the services involved in the choreography, collaborate though a central shared space. These components wrap the services by mediating the interaction with the central space and then indirectly with the other services (in a transparent way to the services, that operate regularly by using message passing). In order to assess the applicability of the framework to real world cases, 20
1.4. THESIS CONTRIBUTION a reference prototype implementation has been developed and utilized to implement a e-commerce composite application modeled as a choreography.
1.4 Thesis contribution The main contributions that this thesis aims at offering are: • the definition of a new approach to choreographed service execution. In general choreography are considered in order to study problems related to conformance, compatibility and protocol derivations (see Chapter 2). Conversely the focus in this thesis is on facilitating the collaboration among services modeled as choreography, offering a framework where a mediation model and the supporting architecture make possible the seamless implementations of choreographies, promoting more complex forms of collaborations among services; • a new form of exploitation of the benefits of the event based model to support the message based communication of web services. The integration between the two different computational models is managed by the proposed framework and is totally transparent to the services; • a new approach to service adaptation where the focus is on the adaptation of a service with respect to the definition of a choreographed service and not with respect to another service. The mediation offered by the framework overcomes the problems related to interface mismatches between the service behavior and the one prescribed in the choreography. This is possible thanks to an execution of the web services based on actions. 21
CHAPTER 1. INTRODUCTION
1.5 Thesis outline This thesis presents the event-driven execution model for choreographed services introduced in this Chapter. The presentation starts in Chapter 2 with a more detailed introduction to the web service adaptation problem and with an analysis of the interaction protocol mismatches addressed. Afterwards the first part of the thesis is devoted to describe the proposed approach under different viewpoints, the architecture, the mediation model and the execution model. Specifically: • Chapter 3 describes the framework architecture presenting the main components devoted to the management of the new execution model. • A detailed presentation of the mediation model exploited is provided in Chapter 4. This Chapter describes the representation used to model the choreography, the service protocol interface, and the adapters supporting the interaction protocol mediation. • Chapter 5 focuses on the event-driven web service execution describing the execution model supporting the new composite service execution. An important issue this thesis addresses is the integration of new services in existing web service choreographies. Thus Chapter 6 provides a detailed description of the integration process of a web service in a composite service and describes the defined mapping rules applied to conciliate the protocol mismatches.
22
1.5. THESIS OUTLINE As mentioned a reference implementation and a use case scenario have been developed in order to demonstrate the feasibility of the proposed approach. These concerns are treated in Chapter 7, that provides some details about the framework prototype implementation, and in Chapter 8, that presents a use case scenario: the integration of a service in a choreographed service by means of the mediation model proposed, using the implemented prototype. Chapter 9 discusses an evaluation of the proposed framework and Chapter 10 overviews how, exploiting its flexibility, the proposed framework can be used to address different issues as the execution of web service orchestrations, classical peer to peer web service adaptation and data mediation. Chapter 11 positions the work in the related research and finally Chapter 12 concludes the thesis.
23
2 Problem statement
As introduced in Chapter 1 a challenging kind of service composition takes place when a complex service results from the cooperation of several web services interacting in a distributed open environment. In this case, the composition can be handled as a choreography (see [86]), that describes the public messages exchange among the involved web services, expressed in terms of roles. In a web service choreography the interaction takes place in form of complex peer to peer conversations among participants, structured in a conversation. Moreover, a choreography describes the interactions among the involved participants from a global point of view and not from the perspective of a single leading participant. Note that in an open environment complex services are dynamic, in the sense that the choreography defines the cooperating participants in terms of roles, while the binding with the actual web services taking part in the provision of the complex service is performed at runtime (see [6]). Looking at the description of the complex service as a choreography, each participant can derive how to behave, in order to play its role in the composite service. In other words the choreography model can be used as a starting point from which a concrete 25
CHAPTER 2. PROBLEM STATEMENT collaboration can be set up (see [34]) and represents a sort of contract in a collaborative scenario. The term behavioral interface [10] can be used to identify the interaction behavior of a single participant within a choreography. A behavioral interface represents the local view of a single web service playing a specific role within a choreography; other terms as interaction protocol, communication protocol and protocol interface are used in literature with the same meaning. A possible design model is to follow a top down approach: a model of collaboration is designed from a global point of view as a choreography and becomes a contract that provides the collaboration rules among participants. From this model the behavioral interfaces of each role are derived, according to the global definition, and following these interfaces the services are implemented. The function that derives a local behavior from a global description is generally referred as projection and can highlight the problem that Honda and colleagues (see [47]) call synchronization bug. This is a failure that can occur in communicating programs that should jointly realize a consistent conversation described in a global model. The term conformance is generally used to indicate a local behavior in accordance with a global model (see [18] and [60] among others). Many works pointed out that only a subset of choreographies or, in general, global models can be projected in local behaviors that collaborating satisfy the order prescribed by the global model. Several names identify a choreography with this property: implementable [126], locally implementable [60], locally enforceable [120] or realizable [20]. Also when the design of the collaboration starts from implementable choreographies, recognized by means of some rules (see for instance [60] and [24]) or when some procedure is provided to transform a non implementable choreography to an implementable one ([42]), this top-down design ap26
proach is somewhat rigid in the sense that services can take part into the choreography only if they exactly implement the prescribed protocol. This is unlikely to happen especially when existing services have to be integrated in new collaboration settings. To deal with this problem the idea is then to provide a mediation component supporting the integration of a service with a different protocol in a given choreography, by solving the inconsistency between the choreography and the service to integrate. In these situations the interaction protocols of the participant web services have to be mapped to the choreography and the existing interface mismatches have to be solved. The problem of mediating the mismatches between communication protocols has been addressed in the web services literature in different ways. In general the mismatches, and thus the need of adaptation, have been studied considering the interaction between two web services: a client asking for some services and a service provider offering these services. The adaptation becomes more complicated if the interaction with the provider involves the execution of a complex protocol and the interaction takes place in form of a conversation: in this case, not only the signature of the messages has to be taken into account, but also the order in which the messages must be exchanged. The starting issue is to identify when two web services can be considered compatible and thus able to correctly collaborate [16]. A first definition of compatibility says that two services are compatible if they can interact properly. Another intuitive notion of compatibility is to consider two web services as compatible if they have opposite behavior: the behavior of service B should be the same of service A, but with receptions instead of emissions, and vice-versa [16]. More formal discussion on compatibility are offered in the literature, see for instance [16], [13]. 27
CHAPTER 2. PROBLEM STATEMENT Starting from the notion of compatibility, the concept of replaceability or substitutability can be defined: [16] asserts that a service A’ can substitute a service A if it is compatible with any service B which is compatible with A. In that sense, services associated by the relationship of replaceability are interchangeable and can be used in the same way for the same goals. The replaceability among services is a very important property that makes possible the set-up of composite services where different alternatives suppliers are considered. This is useful, for instance, when a particular service is unavailable or when a service client can choose among different service providers. For instance, if a service provider SPA can be substituted with one of SPB , SPC , SPD , and if a service consumer SC1 is client of SPA , then SC1 can correctly interact with SPB or SPC or SPD instead of SPA . This is very useful when service SPA is unavailable, or when for instance the different SPx are competitors offering the same service. The notion of replaceability makes also possible the definition of self-healing composite services able to autonomously deal with situation of failure (see for instance [5]). Many issues hamper web services compatibility and replaceability, and many works attempt these issues (see Chapter 11 for an overview of the state of the art). In this thesis some issues are considered solved by hypothesis: • the stack of protocols used in the communication and the agreement on a common syntax (the messaging level interoperability layer of [12]) is solved by the hypothesis that web service technology is used with the all related protocols; • all the aspects related to semantic compatibility of the services, regarding the meaning of messages and data, as well as the functionalities of services, are assumed correct. 28
Therefore the problem that this thesis addresses regards two kinds of mismatches: • static mismatches, concerning the differences in the signatures of the WSDL operations; e.g., different orderings of the message parts (operational mismatch in [12]); • dynamic mismatches, raised by the dynamic nature of the web service interaction, which is based on an exchange of messages which can be ordered in complex sequences. Thus these mismatches concern the behavior feature of the services involving the possible sequences of messages that services can send or receive. Notice that this thesis focuses on protocol mismatches, leaving data mismatches apart, as they represent a complex problem, deserving separate treatment; e.g., see [108, 33, 74] for some relevant works in that area and see Section 10.3 for an overview on a possible management of this issue in the proposed framework. The main solution offered to overcome these operational and protocol mismatches is represented by the use of adapters used to restore compatibility between incompatible services. In general, adapters handle an intermediate behavior which is put between the two services and corrects the flaws in their interaction. The top part of Figure 2.1 represents a service WSA interacting with a service WSB using protocol P B : the two web services are compatible and thus they can correctly interact. In the bottom part of the same figure the service WSB has been replaced with WSB’ that offers the same services as WSB but has a rather different protocol. In this case the communication between WSA and WSB’ cannot occur due to the protocol mismatches. A possible solution is to place an adapter between 29
CHAPTER 2. PROBLEM STATEMENT
Figure 2.1: Web service adapter. the two services mediating their interaction. In the figure the adapter is placed beside the protocol of WSB’ and offers a double interface: • it interacts with WSB’ following the protocol P B’ ; i.e. sending to WSB’ the expected messages and intercepting its outgoing messages to WSA; • it offers to WSA the expected communication protocol P B both in input and in output. By means of this adapter WSA can interact with the new service WSB’ without changing its protocol in a completely transparent way. Similarly WSB’ can maintain its own native protocol and can rely on the Adapter for the mediation work. Figure 2.1 depicts an architecture where the adapter has been associated to WSB’ acting as a wrapper, but a similar component can be placed associated to WSA or in the middle of WSB and WSA playing the same function: different solutions can be adopted depending on the 30
peculiarities and the needs of each particular application context. An interesting approach concerning the adapters definition is proposed by Benatallah and colleagues in [12]: in that work the design of the adapters is based on mismatch patterns. These are design patterns [43] that can be used to capture the possible differences among the communication protocols of services. These mismatch patterns become both the guideline for the designer in developing adapters, and input of a tool that automatically generates the adapter code (by means of an adapter template). With respect to the approaches mentioned so far, involving a web service client and a web service provider, in this thesis the problem is slightly different: the focus is on a web service choreography and on the integration of an existing service. Thus the patterns to investigate are the mismatches between the protocol of a service aiming at playing a given role in a choreography and the communication protocol prescribed to that role by the choreography. Moreover, starting from these mismatches, a solution to overcame these differences has to be offered. Following the approaches presented so far, an adapter can be designed for that purpose. Figure 2.2 depicts the situation: in the top part of the figure is showed a service WSB which interacts in a choreography C following the correct prescribed protocol. In the bottom part of the figure the same role of WSB is played by WSB’, that offers the same functions but has a different protocol. In this case an adapter can be used to mediate these protocol differences. Note that in this case the adapter is not necessarily placed in between two services, as it has to mediate the interaction with several web service choreography participants. Thus the adapter could be logically composed by a set of service-to-service adapters (as the one in Figure 2.1), one for each web service interacting with WSB’. 31
CHAPTER 2. PROBLEM STATEMENT
Figure 2.2: Choreography adapter.
Although a possible solution is to use a set of service-to-service adapters instantiated in a choreography setting, this work proposes a different solution, for the sake of flexibility, offering a different perspective of the problem (see the following chapters). The approach used takes inspiration from the work of Benatallah and colleagues ([12]) and is based on the identification and classification of mismatches that can occur between the web services aiming at playing a role in a choreography and the behavioral interface associated to such a role in the choreography. Differently from the work presented in [12], the terms of comparison in the mismatches considered in this thesis are: 32
2.1. SIGNATURE MISMATCH • the communication protocol of the service candidate to take part in the choreography; • the choreography model. In particular the focus on the choreography regards all the activities involving the role the service aims at play, but not only. As showed in the following, some protocol differences can be solved by taking into account the activities performed by other roles. The next Section describes the mismatches considered in this work, taking as example (where needed) the case of a service WSB’ aiming at playing the role B in the choreography C. Although the list is not exhaustive, it describes fairly frequent situations to be managed, translated to the choreography case, which have been also analyzed in previous works on service adaptation; e.g., see [12], [75].
2.1 Signature mismatch A fist kind of mismatch regards the signature of the WSDL operations respectively sent and received by the web services. These mismatches are referred as Differences at Operational Level in [12] and require an adaptation that Brogi and Popescu in [19] define as signature-based. A first case regards the mismatches concerning the message name and the order of the parameters; in Figure 2.3, an example of that is depicted. In the left part of the figure the choreography prescribes that service B sends to service A (and thus that B receives it) a message msga with parameters x1 , ..xn . In the right part of the figure, the communication protocol of the service B’ actually sends a message called msgb with parameters y1 , ..yn . Intuitively one can see that this is a simple difference to overcome, using a 33
CHAPTER 2. PROBLEM STATEMENT
Figure 2.3: Operational mismatch: name and order of parameters.
Figure 2.4: Operational mismatch: parameters not used. message and parameter name mapping function1 . Another possible mismatch regards the number of the parameters of a message. For instance this happens when the recipient of the message does not utilize all the data items produced by the sender. An example is depicted in Figure 2.4, where service B does not use the parameter xk , that in the choreography is part of the parameters of the message msga . In this case, the recipient should ignore the extra-information. In general a signature mismatch pattern occurs when the operations in the choreography and in the communication protocol of the service have the same functionality but differ in operation name, number and order of operation input/output parameter [12]. 1
This because, as mentioned, the hypotheses assure that there is no semantic difference among the messages and their parameters.
34
2.2. PROTOCOL MISMATCH
2.2 Protocol mismatch More challenging kinds of mismatches occur when the differences concern the protocol of the service with respect to the one prescribed by the choreography. These are generally referred as Protocol Mismatches [12] and require an adaptation that [19] defines as behavior-based. The following sections analyze some fairly frequent mismatches as suggested in [12] and [75].
2.2.1
Message split mismatch (One-to-N mapping)
This mismatch occurs when the choreography model requires a single message to achieve certain functionality, while in the protocol of the service the same behavior is achieved by means of several messages; this happens for instance if web service B ′ expects to receive the business data in different interaction steps, but the choreography prescribes that it has to receive all the data items in a single step. This type of difference is handled by a mismatch pattern called One to Many Message Pattern in [12]. Figure 2.5 shows an example of message split mismatch: the choreography on the left of the figure prescribes that service A sends a message to service B (that thus receive it) with the parameter x1 , .., xn . The service B ′ instead, aiming at cover the role B in the choreography, receives in its protocol all these data items in two distinct messages: the parameter x1 , .., xi in msgb and xi+1 , .., xn in msgc . In this case we consider that the operation names and the parameters of the messages in B ′ are functionally equivalent to the ones in B. To overcome this mismatch is necessary to have a mechanism able to receive all the data items in one message (as required by role B ) and then able to split and to send them in separate messages according to the protocol of B′. 35
CHAPTER 2. PROBLEM STATEMENT
Figure 2.5: Message split mismatch - One to Many message pattern.
2.2.2
Message merge mismatch (N-to-One mapping)
This mismatch is the dual of 2.2.1 and occurs when the choreography model requires several messages to achieve certain functionality, while in the protocol of the service the same functionality is achieved by means of one message; this happens for instance if web service B ′ expects to receive the business data in one interaction step from A, but the choreography prescribes that it has to receive them enveloped in several messages. This type of difference is handled by a mismatch pattern called Many to One Message Pattern in [12]. Figure 2.6 shows an example of message merge mismatch: the choreography on the left of the figure prescribes that service A first sends a message msga to service B with the parameters x1 , .., xi and then a message msgb with the parameters xi+1 , .., xn . The service B ′ instead, aiming at cover the role B in the choreography, receives in its protocol all these data items in just one messages msgc with the parameters x1 , .., xn . Also in this case we consider that the operation name and the parameters of the messages in B ′ are functionally equivalent to the ones in B. To overcome this mismatch is necessary to have a mechanism able to 36
2.2. PROTOCOL MISMATCH
Figure 2.6: Message merge mismatch - Many to One message pattern. receive and collect all the messages (as required by role B ) and then able to merge and to send all the data items in one message according to the protocol of B ′ .
2.2.3
Extra message mismatch (Zero-to-One mapping)
This mismatch occurs when the service generates an extra message that the choreography model does not issue. In this case makes sense to overcome this mismatch only if the extra message does not affect the semantics of the service. As done for the other mismatches we can call this mismatch pattern as Zero to One Message Pattern 2 . In order to analyze this case, it is useful to consider if the extra message is a send or a receive activity. If the extra message is a send and represents the sending of an acknowledgment message not prescribed in the choreography, then a possible solution is to absorb the message. The same solution can be adopted if the message 2
Note that this name is not provided in [12], but is introduced here for uniformity and because these names are used in the following when the mapping rules are defined (see Section 6.2).
37
CHAPTER 2. PROBLEM STATEMENT
Figure 2.7: Extra message mismatch - different services involved. produces data not functionally relevant for the choreography execution. If the extra message is a receive activity, although this is a typical starvation case, it can be solved in at least two situations. If the message represents an acknowledgment required by the service but not present in the choreography, it can be forced (simulated) in the service. If the message includes some business data that are produced by different services in the choreography, then the mismatch could be solved by establishing a message mapping which involves various web services. Figure 2.7 depicts an example of the last case presented where service B’ waits in its protocol for a message msgc sent by service A with parameter x1 . . . , xn , y1 , . . . , ym . The choreography does not include a similar message for role B, but the data items requested by B’ are produced respectively by services C and D for services A and E. Thus in this case, in order to correctly overcome this mismatch, other services have to be involved and the needed data must be collected.
2.2.4
Missing message mismatch (One-to-Zero mapping)
This mismatch is the dual of the 2.2.3 and occurs when the service choreography model issues a message that the service does not issue. Also in 38
2.2. PROTOCOL MISMATCH this case, the mismatch can be solved only if the extra message does not affect the semantics of the service. This mismatch pattern can be called as One to zero Message Pattern. In order to analyze this case, it is useful to consider if the extra message is a send or a receive activity. If the missing message is a send and represents an acknowledgment message prescribed by the choreography and not implemented in the service, a possible solution is to force the production of the message. The same solution can be adopted if the message required includes data that the service owns and is able to produce, otherwise the mismatch cannot be resolved. If the missing message is a receive, the situation is similar. If the choreography prescribes the receiving of an acknowledgment or of data not functionally relevant for the service, the solution could be to force in service B’ the receiving of this message and thus ignore it.
2.2.5
Message Ordering mismatch
This mismatch occurs when the service choreography expects messages in a different order with respect to the one specified in the communication protocol of the service. These are complex mismatches that deserve a specific analysis depending on the different cases (see Chapter 6.3.1). In this typology of mismatch is included the typical deadlock situation, where two web services wait for each other. Figure 2.8 shows this case since the protocol of WSB’ sends message msgb and receives msga in the opposite order as prescribed by the choreography for role B and thus as expected by A. This mismatch cannot be solved, unless the messages exchanged by the two web services can be skipped, or another participant in the composite service produces the needed business data. If this is the case, the mismatch could be solved by establishing a message mapping 39
CHAPTER 2. PROBLEM STATEMENT
Figure 2.8: Message Ordering mismatch - Deadlock. which involves more than two web services.
2.3 Discussion The operational mismatches concerning the signatures of the WSDL operations can be solved by applying simple mappings. However, in order to solve the protocol mismatches, the interaction among web services has to be deeply modified, e.g., by relaxing the bindings of web services to their peers. Therefore, a flexible mediation framework, which supports general protocol mismatch resolution and extends it from the typical one-to-one to the many-to-many, is needed. This work is aimed at answering this need. As described in the following, the approach described in this thesis enables the conciliation of cross-protocol mismatches by decoupling the interaction between web services not only at the level of the signatures and order of messages, but also concerning the identities of the interacting peers. This approach offers a seamless way to obtain flexibility in service integration 40
2.3. DISCUSSION
# operational i) operational ii) split merge extra missing deadlock
Table 2.1: Protocol mismatch considered. Choreography send (B,msa (x1 , . . . , xn ), A) receive(B,msc (x1 , . . . , xn ), A) receive(B,msa (x1 , . . . , xn ), A)
receive(B,msa (x1 , . . . , xi ), A) receive(B,msb (xi+1 , . . . , xn ), A) — send (B,msa (x1 , . . . , xn ), C) receive(B,msa (x1 , . . . , xn ), A) send (B,msb (y1 , . . . , ym ), A)
Web Service B send(msb (y1 , . . . , yn ), A) receive(msc (x1 , . . . , xk , xk+l , xn ),A) receive(msb (x1 , . . . , xi ),A) receive(msc (xi+1 , . . . , xn ), A) receive(msc (x1 , . . . , xn ), A) send(msa (x1 , . . . , xn ), C) — send(msb (y1 , . . . , ym ), A) receive(msa (x1 , . . . , xn ), A)
that cannot be easily reached using the classical peer-to-peer web service adapter. The framework proposed takes in consideration and offers a solution to overcome the mismatches presented in this chapter and resumed in Table 2.1.
41
3 The framework architecture
The previous discussion highlights that most interaction protocol mismatches are caused by the direct send/receive invocation method adopted in Service Oriented Computing, which imposes severe restrictions in the exchange of messages between the interacting peers. Most mismatches between the interaction protocols of role fillers and composite service specifications can be solved by abstracting from message flow details: signature of messages, sender of messages (another source might produce a data item), unexpected messages or required acknowledgments. In order to address such problems, is possible to decouple the web services interaction by managing web services as autonomous agents acting in a context which guides their cooperation within the composite service. In such a context services perform operations autonomously and not on an invocation base, decoupling the web service interaction and performing an Agent-based web service execution. Starting from these considerations the approach followed in this project moves from an execution model based on Remote Procedure Call (RPC ) to an agent-based execution model where web services (agents) interact 43
CHAPTER 3. THE FRAMEWORK ARCHITECTURE by exchanging business data and synchronization information avoiding the direct peer-to-peer invocation of WSDL operations. Each agent performs actions (WSDL operations) autonomously, as soon as the necessary data items are available, but respecting the order of messages in the interaction protocol, in order to prevent violations of the web service business logic. This execution model becomes possible if the WSDL operations offered by each web service are turned into actions representing the capabilities of an agent (see Chapter 4). In order to realize this execution model, different coordination models able to meet these requirements have been considered. In the research on distributed processes, several coordination models were proposed to enable the cooperation between heterogeneous systems, by abstracting from language and interaction protocol details; e.g., see [83]. In particular, data-driven coordination models are based on the Shared Dataspace metaphor, which decouples processes in both space and time by modeling their interaction as the access to a common, content-addressable data structure, used to post and retrieve information. At the conceptual level, a Shared Dataspace nicely fits the requirements of a composite service, because it supports the maintenance of a complex context and the contextdependent web service execution. Moreover, the data-driven coordination models use tuple-based coordination languages, such as Linda [2], which support the posting and retrieval of complex data items. Therefore, such languages can be employed to flexibly exchange business data and synchronization information. At the technical level, the posting and retrieval of data items from a Shared Dataspace has been implemented by means of the Publish and Subscribe pattern in order to support an efficient and robust interaction. 44
Figure 3.1: Framework architecture.
Therefore in order to achieve the agent-base execution model at the base of the web service choreography execution, a Shared Dataspace model has been selected for the management of the context of a choreographed service. Figure 3.1 shows the architecture that has been designed to support such a model in the framework proposed in this thesis. The core element of the architecture, which realizes and manages the Shared Dataspace, is the Context Management Service, while each web service participating to a composite choreographed service is wrapped by means of a Communication Interface component, which mediates the interaction between the service and the Context Management Service. In the following these components are presented in detail. 45
CHAPTER 3. THE FRAMEWORK ARCHITECTURE
3.1 Communication Interface (CI) The CI decouples the interaction of the wrapped service with the rest of the composite service: • by inhibiting the direct invocation of the WSDL operations of the wrapped service to other services; • by inhibiting the direct invocation of the operations offered by other services to the wrapped service; • by managing the wrapped service following an action-based model. In order to perform these tasks and to correctly manage at execution time the interaction with the wrapped service in the given choreography context, the CI uses the information stored in the CI Knowledge Base (CIKB ). The CIKB stores the action-based representation of the service
1
(see Chapter 4 for a detailed description of the action-based representation). During the service run time execution, the CI maintains a Local Execution Context storing the local context information about the web service execution state. Note that for each choreography instantiation a distinct Local Execution Context is managed. The CI operates as an autonomous agent managing the message-based interaction with the wrapped service and the event based interaction with the Context Management Service. Specifically (see Figure 3.2): • on the basis of the available Local Execution Context information, the CI selects the WSDL operations to be performed and invokes them on the service (invoke in Figure 3.2). 1
For each service, a different KB is defined
46
3.2. CONTEXT MANAGEMENT SERVICE
Figure 3.2: CI interactions. • it intercepts the outgoing messages of the service (send in Figure 3.2) updating its Local Execution Context; • it retrieves the context information relevant to the web service execution from the Context Management Service (read in Figure 3.2) updating its Local Execution Context; • it propagates the context information generated by the web service to the Context Management Service (publish in Figure 3.2).
3.2 Context Management Service The Context Management Service (CtxMg) manages the interaction with all the CIs associated to the web services participating to the choreography execution and manages the global status of the choreography; i.e. the Choreography Execution Context. Specifically the Context Management Service: 47
CHAPTER 3. THE FRAMEWORK ARCHITECTURE • updates the Choreography Execution Context with the data provided by the web services via their CIs; • propagates new available information items in the Choreography Context to the interested CIs according to the Publish and Subscribe pattern, supporting distributed caching. The shared dataspace is realized by means of the Choreography Context that collects all the data, in form of tuples, exchanged during the choreography execution. For each choreography instance in execution, a distinct Choreography Context is instantiated and managed. The Choreography Context includes the following kinds of information: • Basic coordination information; e.g., the identifier of the instance of the composite service to which the cooperating web services participate (Chapter 5 provides a description of the protocol used). • The data items to be shared among web services, i.e., the business data of the composite service. • The synchronization information which the cooperating web services need in order to perform their operations while respecting their own business logic and that of the composite service. In order to uniformly handle business data and synchronization information, they are both represented as tokens. A token thus represents a data item, or the fact that a certain synchronization information, enabling the execution of one or more operations, has been satisfied. In order to perform its task the Context Management Service manages the information collected in the Choreography Execution Context according to the data space model. It offers to the CIs all the needed tools to publish 48
3.3. OVERVIEW OF THE EXECUTION MODEL or read data from the global choreography context and it implements the publish subscribe mechanism: it manages the subscription of the CIs and notifies them accordingly.
3.3 Overview of the execution model The autonomous, context-dependent web service execution is achieved by adopting an event-driven execution model, which subordinates the invocation of WSDL operations to the reception of enabling events; i.e. tokens. The context-dependent selection of the operations is based on their representation as actions whose preconditions are expressed in terms of the tokens (synchronization constraints) to be satisfied. The WSDL operations of each service are invoked depending on the state of the Local Execution Context and the item information produced as output by the service2 is propagated to the global Choreography Execution Context. The updating on the Choreography Context affects the Local Context of each service involved in the choreography depending on its subscriptions; i.e. each CI (on the basis of the configuration stored in the CI KB) subscribes for the interested information to the Choreography Context. A detailed description of the execution model used is presented in Chapter 5.
2
Following the message-based interaction model of web services, a data output is produced by explicit message exchange; i.e. when: i) a message is sent to another service; ii) a return value of a received request message is sent.
49
4 The mediation model
In order to realize an event driven execution of a choreographed service, it is necessary to consider a new representation of the involved components. The purpose of this Chapter is to introduce the representation model used in this thesis. Specifically, Section 4.1 focuses on the representation of the interaction protocol of a single web service while Section 4.2 focuses on the choreography representation. Then Section 4.3 analyzes the representation of a single web service integrated in a choreographed service.
4.1 Token-based representation of an interaction protocol In order to execute a web service as an event-driven system, its WSDL operations have to be invoked on the basis of events; moreover, the results of its send activities (SOAP messages sent to others web services) have to be expressed in form of events. As mentioned in Chapter 3, the events in the proposed model are represented as tokens associated to business data items and synchronization information. In principle, the web service might 51
CHAPTER 4. THE MEDIATION MODEL receive such tokens at any point of its execution. Therefore, each WSDL operation has to be associated to a precondition which enables its execution at the appropriate phase of the business logic. Similarly, the web service sends SOAP messages to its partners at specific steps of its execution, depending on its business logic. These messages have to be translated to events and propagated (when needed) to other services in particular points during the global model execution, depending on the choreography constraints. Therefore preconditions can be associated to the send activities in order to manage the appropriate events propagation. The rest of this section first introduces the starting representation of interaction protocols considered (see Section 4.1.1); then the action-based representation of web services (Section 4.1.2) and, at last, the process used to translate a web service to the token-based representation used in the event execution model presented (Section 4.1.3).
4.1.1
Interaction protocol representation
Graph-based representations are widely used to represent web service interaction protocols; by means of a graph the nodes representing inbound and outbound messages can be ordered using different order relations (e.g., WSCL[104], WSCI [9]). Several different graph based representations as Petri-Net [98, 90], or UML Activity Diagrams [80] or more generally several workflow-based languages (Abstract BPEL [77], BPMN [79], YAWL [101]) can be used for this purpose. This work starts from a model where interaction protocols are represented at the abstract level using a graph, composed of two kinds of nodes: Communication Activity nodes and Control Flow nodes. A Communication Activity node represents a message exchange (inbound 52
4.1. TOKEN-BASED REPRESENTATION OF AN INTERACTION PROTOCOL or outbound message) and can be of two types: • receive: describes the act of receiving a message and has two arguments: the object message and its sender; • send : describes the act of sending a message and specifies the object message and the recipient. For example, considering the interaction protocol of web service B, depicted in Figure 4.1, the first node is send(msg1 (x1 , . . . , xn ), A) representing that B has to send the message msg1 with parameters x1 , . . . , xn to web service A. A Control Flow Node organizes the connected nodes providing partial order relations on them. In this work the following basic types of control flow nodes are considered: • AND, used to create parallel execution flows; • SYNCH, used to synchronize two or more parallel execution flows resulting from a previous AND; • XOR, used to create alternative execution flows with just one possible selection; • MERGE, used to join alternative execution flows resulting from a previous XOR in one flow. By means of these basic control flow nodes, and considering that the oriented arcs between the nodes of the graph represent sequence order relations between the nodes, it is possible to describe the five basic workflow patterns identified by van der Aalst in [99]: sequence (the arcs), parallel split and synchronization (our AND and SYNCH nodes), exclusive choice 53
CHAPTER 4. THE MEDIATION MODEL
Figure 4.1: Web service B interaction protocol.
and simple merge (our XOR and MERGE nodes). These patterns can be considered as elementary building blocks for more complex patterns 1 . Moreover, for each object message, the output arguments of the message are annotated by specifying whether the web service has just generated them (either as new business data items, or by modifying their previous values). This is done, similar to WS-CDL, in order to distinguish business data propagated within a composite service from new information to be handled. For simplicity, in the presentation of this work the hypothesis is that different data names are used in order to distinguish new or revised 1 Note that not all the patterns in [99] are implementable with these basic constructs. This fact poses limits to the considered approach. However the main workflow patterns are covered and also the main workflow languages used to represent service composition only support some of these patterns (see for instance [117]).
54
4.1. TOKEN-BASED REPRESENTATION OF AN INTERACTION PROTOCOL data from simple data propagation2 . Although this representation is easy to understand, it cannot be applied straightforwardly to manage a web service in event-driven way, because it supports the invocation of operations (receive nodes) on the basis of the navigation of the interaction graph, instead of subordinating it to the reception of events. Similarly, the navigation of the graph sets when a message has to be sent to other web services (send nodes), avoiding the use of events. For this reason another representation has been selected, the token-based one, which describes the dependencies among messages in terms of input and output tokens associated to the nodes of the interaction graph. An input token is necessary to activate a node, while an output token represents the fact that the message described by the node has been received or sent. This represents an observable progress step in the business logic of the web service.
4.1.2
Action based representation of a web service
The message-based specification of web services is translated to an actionbased representation, where Actions drive the interaction of the service with other services in a choreographed composite event-driven service execution. A web service interacts with its partners by means of messages exchange; that is receiving or sending SOAP messages. Therefore two different Actions are necessary: Receive Action and Send Action. 2
A simple rename procedure can be used on an annotated graph in order to provide this representation.
55
CHAPTER 4. THE MEDIATION MODEL Receive Action A Receive Action, as suggested by the name, represents the receiving of a message. When the activation conditions are satisfied and the action is enabled, the firing of the action results on the invocation of the specific WSDL operation associated and thus in the dispatching of a SOAP message to the service. The outcome of the Action execution are new data items and synchronization tokens that affect the execution context (at local and choreography level). Specifically a Receive Action is defined by means of the following fields: • pre (precondition): specifies the list of synchronization constraints that are required in order to activate the action (and thus to invoke the WSDL operation). These constraints are used to enable the invocation of the corresponding operation in accordance with the communication protocol of the service; i.e. in the appropriate phase of the business logic of the web service. This means that if, within a composite service, the input parameters of the operation are generated before time, the execution of the operation can be delayed by means of this field. • in (input data): specifies the list of data items that the corresponding operation requires; the corresponding action can be fired only when all the data items required are available. • out (output data): specifies the new and the revised output data items produced by the action. In general it includes the return values of the operation, if any. Note that the output data items propagated by the message without modifying them are not reported in this field, because it is assumed that they are already available to the other 56
4.1. TOKEN-BASED REPRESENTATION OF AN INTERACTION PROTOCOL cooperating web services. • post (postcondition): specifies the list of the synchronization tokens to be generated when the message is handled. The purpose of these tokens is twofold. First, postconditions are used to synchronize this action with the other actions of the service in order to respect its protocol. Second, they are used in order to synchronize the action with the choreography execution: a token synchronization is used as an event informing the other services that the state of the choreography has changed (a step has been done). • op (operation): is the signature of the operation to be invoked and provides the operation name and the parameters list needed to pack the correct message to the service (i.e.; the message that the service expects). When all the input data items in in are available and the precondition pre is satisfied, the action fires and the SOAP message is packed as specified in op and sent to the service. After the execution of the operation, the data listed in out and the synchronization tokens in post represent the outcome of the Action and are propagated to the Choreography Execution Context (see Section 3.3). Send Action A Send Action, as suggested by the name, represents the sending of a message. In this case among the activation conditions of the Action is included the sending of the SOAP message performed by the service. The firing of the Action consists in the publication of its outcomes: the production of new data and synchronization tokens changing the Local and Choreogra57
CHAPTER 4. THE MEDIATION MODEL phy Execution Context. For representation uniformity, the fields used to define a Send Action are the same used for the Receive Action, but they have a different meaning; specifically a Send Action is defined by means of the following fields: • pre (precondition): specifies the list of synchronization constraints that are required to activate the action. These conditions are used to constraint the propagation of the output tokens of the message to the Choreography Execution Context when required by the choreography prescriptions. This means that, if the web service anticipates the phase of the business logic of the composite service where the message is expected, the effects of the message can be delayed by means of this field. • in (input data): this field requires that the specified data are present in order to activate the action. In the case of a Send Action, this field is empty; • out (output data): the meaning of this field is the same of the Receive Action and specifies the new and the revised output data items produced by the action; this in general includes a subset of the parameters enveloped in the body of the SOAP message sent by the service; • post (postcondition): specifies the list of the synchronization tokens to be generated when the action has been fired with the same purpose explained for the receive case; • op (operation): this field specifies the send operation associated to the Action. 58
4.1. TOKEN-BASED REPRESENTATION OF AN INTERACTION PROTOCOL
Figure 4.2: From interaction protocol to token based representation. When the web service sends its SOAP message invoking the operation op on another service and the precondition of the associated action is satisfied, the Action fires and the data items listed in out and the synchronization tokens in post are propagated to the Local and to the Choreography Execution Context.
4.1.3
Translation of an interaction protocol to the token based representation
This section describes how a communication protocol (defined using the graph-based representation presented in Section 4.1.1) can be automatically translated to its token-based representation. This can be obtained by performing the following steps: 59
CHAPTER 4. THE MEDIATION MODEL 1. Token Decoration. Each arc of the graph, not originating from a Control Flow node, has to be decorated with a new synchronization token si . This token forces the ordered sequence expressed by the arc between the communicative nodes it connects; in particular: • the node from which the arc starts has to produce the token in order to inform that it performs its communicative act; i.e. when the inbound (outbound) message is received (sent), the related synchronization constraint is satisfied; • the output node to which the arc is directed has to wait for this token before starting its execution. Note that if the arc is directed to a Control Flow Node the token is propagated to the following nodes according to the Token propagation rules (see the following). In the Figure 4.2 the tokens added in this phase are represented by the filled circles s1, s2, s3, s4, s5, s6, s7. Note that the tokens produced in this step are labeled with letter s and represent Local Synchronization Tokens: they synchronize the communication activity of the service with respect to its private business logic protocol. 2. Token propagation. The arcs outgoing from Control Flow Nodes have to be decorated depending on the tokens associated to the incoming arcs and on the node types. • In case of an XOR a single token is propagated to each of the ramifications of the split. In Figure 4.2 the incoming token s2 is propagated through the XOR node to two branches outgoing from the node. 60
4.1. TOKEN-BASED REPRESENTATION OF AN INTERACTION PROTOCOL • In case of a MERGE, the outgoing arc is decorated with the disjunction of the tokens associated to the incoming arcs. In the figure the token from the left branch s3 appears in the outcome of the node in disjunction with the tokens arriving from the right branch s6 && s7. • In case of an AND the token associated to the incoming arc is propagated to each of the ramifications of the split. The AND node starts a parallel execution and in terms of tokens it spits a sequence order relation between the previous and the following nodes. See for instance the token s5 in Figure 4.2. • In case of a SYNCH, the outgoing arc is decorated with the conjunction of the tokens associated to the incoming arcs. This node synchronizes parallel execution threads, thus it prescribes to wait the completion of all the activities in its incoming branches before going on. In terms of tokens this means to wait until all the incoming tokens are available. See for instance how the SYNCH node of Figure 4.2 joins the tokens s6 and s7 from its ingoing arcs. As shown in the example depicted in Figure 4.2, these propagation rules have to be applied inductively on the structure of the graph: the tokens associated to the outgoing arc of the MERGE node in the figure is an example of that. Note that this representation underspecifies the synchronization constraints imposed by the local interaction protocol; e.g., in the XOR case, a single path should be activated. However, in order to produce only one of the alternative tokens, the token generation should be tightly coupled to the business logic of the web service. In this 61
CHAPTER 4. THE MEDIATION MODEL approach, the web service interaction is modeled by relying only on their message passing behavior. From such an external point of view, the alternative paths cannot be discriminated until the related messages are observed. In order to address the underspecification issue, two assumptions are made: (a) The web service operates coherently with its own interaction protocol. Thus, at each execution, it generates only one of the alternative messages.3 (b) At composite service set up, the participating web services are checked for interaction protocol mismatches. Therefore, it is possible to check whether they violate such constraints. 3. Action Definition. For each Communication Activity in the graph a new Action has to be created.
As mentioned before, each in-
bound/outbound message must be associated with a precondition specifying the input tokens necessary for handling the message and with a postcondition specifying that the message has been handled. The precondition and the postcondition are expressed as a boolean expression on the synchronization tokens placed on the input and output arcs of the node. Therefore in case of a node of type receive, a new Receive Action is created and filled out as follows: • pre: the tokens associated to the incoming arc (incoming tokens4 ) represent the precondition of the action; 3 The analysis of the conformance between business logic and interaction protocol is out of the scope of this work. See, e.g., [100] for details about this issue. 4 Henceforth the term incoming token of a message is used to refer to the token labeling the arc entering the Communicative Node representing the message in the token based
62
4.1. TOKEN-BASED REPRESENTATION OF AN INTERACTION PROTOCOL • in: the input parameters of the WSDL operation represented by the node are listed here; • out: the new or revised data items retuned by the operation are listed in this field; • post: the token associated to the outgoing arc (outgoing token) becomes the postcondition of the action; • op: the signature of the associated operation; Similarly, a new Send Action is created in case of a node of type send and filled out as follows: • pre: the tokens associated to the incoming arc (incoming tokens) represent the precondition of the action; • in: empty; • out: the new or revised data in the body of the send message are listed in this field; • post: the token associated to the outgoing arc (outgoing token) becomes the postcondition of the action; • op: the signature of the send operation; Figure 4.3 shows an example of two actions derived from the protocol depicted in Figure 4.2. Note that the outcome of the translation process is a list of Action Descriptors where the name of the web service involved in the communication (as interlocutor) disappears; therefore the service execution is decoupled graph representation. Similarly the term outgoing token of a message refers to the token labeling the arc outgoing from the node.
63
CHAPTER 4. THE MEDIATION MODEL
Figure 4.3: Actions. from the execution of the other services. The specification of such descriptors makes it possible to describe an interaction protocol as a set of actions selected for execution by an autonomous agent, on a contextual basis. However, the descriptors specify local synchronization constraints. Thus, they have to be modified when the web service is integrated in a composite service, in order to support its execution in that context; see Section 4.3 and Chapter 6 for details.
4.2 Token-based representation of a choreographed service A choreographed service can be represented by means of an interaction graph similar to the one adopted for the specification of the interaction protocol of a web service. The interaction graph represents a global view of the interaction expected among all the web services participating to the composite service. In other words, it represents the point of view of an external observer of the composite service. Many languages have been proposed to describe a choreography. Most of them are based on graphs, as Let’s Dance [120, 121], Web Services Choreography Description Language (WS-CDL [110]), and extensions of business process modeling languages, 64
4.2. TOKEN-BASED REPRESENTATION OF A CHOREOGRAPHED SERVICE such as Business Process Modeling Notation [79]. In this thesis, choreographed services are represented using an extension of the representation used for the interaction protocol, i.e. by means of graph composed by Communication Activity nodes and Control Flow nodes. The meaning of the nodes is the same as described in Section 4.1.1, transported in the context of a choreographed service. The graph includes a couple of Communicative Action nodes for each message exchanged by the participants. The first node, send(), represents the act of sending the message and has three arguments: the message sender, the object message and the recipient. The other node, receive(), represents the act of receiving a message and specifies the recipient, the object message and its sender. The send() and receive() nodes are explicitly represented in order to separate the two phases necessary for a successful communication: if a sending act is completed, but the message does not reach the recipient, the communication fails. Moreover, from an events perspective, the act of sending and receiving a message are in fact two distinct events. The Control Flow nodes are the same described in Section 4.1.1: AND, SYNCH, XOR, MERGE and, together with the sequence construct represented by the arcs, they define the order relations in the messages exchange from a global perspective. The same procedure done for the interaction protocol representation can be applied to the choreography, moving from a classical message-based representation to a an event-oriented representation based on actions. An example of such a representation is shown by using the choreography ChorX depicted in Figure 4.4. The translation of the interaction graph to the token-based representation is similar to the one described in Section 65
CHAPTER 4. THE MEDIATION MODEL
Figure 4.4: ChorX choreography after token decoration.
66
4.2. TOKEN-BASED REPRESENTATION OF A CHOREOGRAPHED SERVICE 4.1.3 for interaction protocols. 1. Token Decoration. Each arc of the graph representing the choreography is decorated with a synchronization token ti , with the exception of the arcs outgoing from Control Flow nodes (that do not produce any new tokens but just propagate them). This step is similar to the Token Decoration step in the token based representation of interaction protocol (see Section 4.1.3), however, in this case, is interesting to note that there are two different kinds of synchronization: • The synchronization of the sender with respect to the rest of the composite service. The sender cannot send the message until the composite service has reached the appropriate progress state. • The synchronization between sender and receiver. The recipient cannot handle the receive() action (and thus invoke the object WSDL operation) until it has received the output token of the send() action. Moreover, when the recipient manages the receive() action, it generates the associated output token, meaning that the interaction step has been completed. This token represents the synchronization of the next sender with the message exchange completed by this receive node. In Figure 4.4, with respect to the exchange of message msg3 , t2 synchronizes the sender with respect to the rest of the composite service, t5 synchronizes the sender and the receiver of the message, and t6 synchronizes this message exchange with the following msg4 . Note that in this case the tokens are labeled with letter t and represent Global Synchronization Tokens imposed by the choreography model. 67
CHAPTER 4. THE MEDIATION MODEL
Figure 4.5: Choreography Actions. 2. Token Propagation. The token propagation through the Control Flow node is the same as described for the Interaction Protocol in Section 4.1. For example in Figure 4.4 t4&&t6 is the result of the propagation through the SYNCH node. 3. Action Definition. Looking at the decorated graph, a set of actions representing the choreography can be derived; for each couple of communicative nodes representing a message exchange two actions are defined: • a SendAction, with precondition and postcondition obtained respectively by the ingoing and outgoing arcs, and the other fields filled depending on the signature of the message (as already detailed in Section 4.1). • a Receive Action, obtained in a similar way and having as precondition the postcondition of the respective SendAction. Figure 4.5 shows the two actions relative to the exchange of message msg3 in Figure 4.4. Note that, also in this case, the token-based representation of the composite service underspecifies the synchronization constraints imposed by the choreography specification; e.g., consider the XOR splits. In order to 68
4.3. TOKEN-BASED REPRESENTATION OF A WEB SERVICE IN THE CONTEXT OF A CHOREOGRAPHED SERVICE guarantee a correct service execution, at set up time, the cooperating web services have to be analyzed to verify that they operate consistently with the choreography specifications. Now two separate token-based distinct representations of interaction protocol and choreography are available, based on respectively local and global synchronization tokens and data items. In order to integrate a service in a composite service, some mapping between these two representations is needed. The next section provides an overview of the integration procedure.
4.3 Token-based representation of a web service in the context of a choreographed service The integration of a web service in a composite service requires a preliminary mapping phase, where the existing protocol mismatches are identified and analyzed in order to evaluate whether they represent solvable conflicts, which can be conciliated, or unsolvable ones. In particular, the interaction protocol of the web service has to be adapted to the target interaction protocol, by grounding its token-based representation to the constraints imposed by the choreography model. The idea is that, in the context of a composite service, the operations of the web service have to be performed by respecting local and global synchronization constraints. The integration process is described in detail in Chapter 6, where for all the mismatch patterns analyzed in Chapter 2 the mapping rules are provided; this Section sketches this process on a simple example in order to provide an overview of it. Let’s consider a web service, WSA, which has to be integrated in the ChorX service (see Figure 4.4). The left side of Figure 4.6 shows the choreography specification of ChorX and the right side the 69
CHAPTER 4. THE MEDIATION MODEL
Figure 4.6: Protocol mismatch resolution between web service WSA (at the right) and the composite web service ChorX (at the left).
70
4.3. TOKEN-BASED REPRESENTATION OF A WEB SERVICE IN THE CONTEXT OF A CHOREOGRAPHED SERVICE interaction protocol of WSA. For simplicity, the assumption is that the local business data managed by WSA has already been mapped to the target business data managed in ChorX. This is represented by utilizing similar names for the arguments of the messages; for instance the x′i arguments of mes1 (x′1 , ..., x′r ) are mapped to the xi data items of ChorX. Similar names are used for the role fillers occurring in the choreography and in the local interaction protocol of WSA. In this example, WSA plays role A in ChorX and WSB and WSC play roles B and C respectively. In order to integrate WSA in ChorX a mapping between its local interaction protocol and the choreography messages has to be provided; in Figure 4.6 the dashed arrows identify these mappings: • Messages mes1 and mes2 of WSA correspond to message msg1 of the choreography. • Message mes3 of WSA corresponds to message msg4 of the choreography. Given such correspondences, the interaction protocol of WSA can be mapped to the choreography by replacing the local synchronization tokens with the global ones of the token-based choreography representation. In fact, the choreography tokens describe synchronization information at the level of the composite service, which can be shared among all the participant web services and used to coordinate their execution. In our example (see Figure 4.6) this happens for local token s2 and s3 that must be replaced by target tokens t1 and t8. Indeed, some local tokens have to be managed during the execution of the composite service. This happens, for instance, if a choreography 71
CHAPTER 4. THE MEDIATION MODEL message is mapped to more than one message of the local interaction protocol. However, this is not a problem because such tokens only synchronize the local messages of the web service. This is the case in the example of the local token s1. Moreover, as represented by the arrow in the figure, the local protocol of WSA has to synchronize the receiving of the message mes3 , mapped to the message msg4 in the choreography, by means of the choreography token t7. Having mapped the local interaction protocol of a web service to the choreography, the Communication Interface (CI) associated to that service can be configured in order to support its execution in the context of the composite service. This is done by defining the CI Knowledge Base (CI KB). The CI KB includes the following types of information: • The mappings field maps the business data items of the choreographed service to the local business data items managed by the web service; i.e., to the input and output arguments of the WSDL operation. • The actions which the web service has to perform as the filler of a role of the choreographed service. The descriptor is the one used in the token-based representation of the local interaction protocol (see Section 4.1.2), enhanced with the information derived by the integration in the choreographed service. In particular: – the preconditions (pre) and the postconditions (post) of the existing Actions in the protocol are updated by replacing the local tokens with the global ones for which a mapping has been set. In our example replacing s2 with t1 and s3 with t8; – the preconditions of the Actions are updated in order to syn72
4.3. TOKEN-BASED REPRESENTATION OF A WEB SERVICE IN THE CONTEXT OF A CHOREOGRAPHED SERVICE chronize with the choreography specification. In the example t7 is added to the precondition of the receive action of mes3 ; – the output (out) field of the the Actions is updated according to the signature of the choreography message corresponding to the message modeled by the action; – new Actions can be defined depending on the mismatches found with the choreography (see for detail Section 6). • The CI KB also specifies the subscription list of the web service (subscriptionList). This is the list of the business data items and synchronization tokens relevant for the web service execution; i.e., those occurring in the input parameters of the receiveAction descriptors or in the preconditions of the receiveAction and sendAction descriptors. Figure 4.7 shows the CI KB of WSA before the integration in the composite service (left side) and then after the integration in the context of ChorX (right side). In the figure, the receiveAction mes3 descriptor concerns the WSDL operation named mes3 . The operation can be executed only after the synchronization constraints represented by t1 and t7 have been satisfied. Moreover, the arguments of the action p′1 , . . . p′t are bound, respectively, to the p1 , . . . pt business data items of ChorX.
73
CHAPTER 4. THE MEDIATION MODEL
Figure 4.7: (a). Action-based representation of the interaction protocol of WSA, within composite service ChorX.
74
5 Management of a composite service
After the description provided in Chapter 4 of the mediation model used to represent the components involved in a choreographed service, this Chapter describes the execution model that drives the event-based web service cooperation in the proposed approach. The life cycle of a choreographed service includes three main phases: • During the start up phase, all the needed components are set up and launched. • Then, each time the composite service is invoked by a client, the initialization phase is carried out in order to start the interaction session. • During the management phase the interaction section is managed. During the second and the third phases, the CIs manage their web services as autonomous agents acting in a shared context.
75
CHAPTER 5. MANAGEMENT OF A COMPOSITE SERVICE This thesis deals with the management of multi-peer conversation among web services, described as web service choreographies. The first problem to solve in these cases is to provide a coordination mechanism to manage the concept of interaction session and correlations among messages. In distributed multi-peer conversations, a possible solution is provided by WS-Coordination [22], that proposes a protocol to deal with the problem of message correlation within conversations involving several partners. For this purpose, WS-Coordination defines a reference data-structure called coordination context, to be added to the exchanged SOAP headers, that serves the purpose of passing a unique identifier between interacting web services. The model proposed by WS-Coordination is used in this work in order to create a shared choreography context identifier among services. During the event-based execution of the choreographed services this identifier is used to refer to the specif choreography instance considered. As showed in Chapter 3, the architecture of the proposed framework includes a central Context Management Service (CtxMg) devoted to the management of the Choreography Execution Context and to the interaction with the services involved. Therefore the role of Service Coordinator in the WS-Coordination implementation can be played by the CtxMg.
5.1 Start-up phase During the start-up phase, all the components of the framework are launched. It is not requested that the different services are started at the same time, but is required that the CtxMg is launched and is correctly working when the other web services are launched. When a web service, wrapped by its Communication Interface (CI) is launched, in order to play a role in the choreography: 76
5.2. INITIALIZATION PHASE • it pre-registers to the CtxMg, providing the required information in order to be contacted by the CtxMg (i.e., it applies as a candidate to play a role in the choreography); • it goes in wait state, waiting for requests from the CtxMg.
5.2 Initialization phase At session initialization time, the CI of each cooperating web service registers to the Choreography Context by sending a registration request to the Context Management Service (CtxMg) according to the WS-Coordination specifications. Moreover, the CI subscribes for the context information relevant to the web service execution (as stored in the subscriptionList of the CI KB). Notice that, for each new session, an instance of the CI is created, in order to handle the specific session. Moreover, when the CtxMg receives a request for a new choreography instance initialization from a CI, it generates a new, session-dependent, Choreography Execution Context instance. Details on the realization of the initialization phase and on the implementation of the WS-Coordination specifications are provided in Section 5.6 at the end of this Chapter.
5.3 Runtime phase At runtime, the CI mediates the interaction between the web service and the rest of the composite service by receiving the notification messages from the CtxMg and by intercepting the outbound messages of the web service. Moreover, the CI invokes the WSDL operations of the web service 77
CHAPTER 5. MANAGEMENT OF A COMPOSITE SERVICE on the basis of the available context information and publishes the requested tokens to the CtxMg. In order to analyze in detail the run time of the choreography execution, the following description is focused on the tasks performed by the different components in the framework: the Context Management Service and the Communication Interface.
5.3.1
Context Management Service
The CtxMg stores each token tok published by any CI in the Choreography Context and propagates it to the CIs of the subscribed web services by sending a multicast notify(ctxID, tok). In order to do this task, the CtxMg exploits the information (the subscription list received) collected during the Registration phase.
5.3.2
Communication Interface
The Communication Interface is the most active component during the choreography execution because it has to manage and coordinate different aspects: • the message based interaction with the wrapped web service, by intercepting its outgoing messages and invoking its WSDL operations; • the interaction with the CtxMg, by managing the arriving notification messages and publishing the tokens to be propagated; • the management of the Local Execution Context with the consequent firing of actions. 78
5.3. RUNTIME PHASE Interaction with the web service The interaction with the wrapped web service takes place via message passing, i.e., by managing its outgoing and ingoing SOAP messages. • When a web service, following its own interaction protocol, tries to invoke a WSDL operation on a supplier (outgoing SOAP message), the CI absorbs the outbound message, extracts from the message the values of the output parameters, and stores such values in its own Local Context. Then it checks the Local Execution Context for action activation. • A CI invokes a WSDL operation of its wrapped service when the respective Receive Action is executed. In this case, the CI packs the required SOAP message, referring to the signature of the action (field op) and retrieving the needed data values from the local context. Then it sends the message to the web service. If the message has a return value, the CI waits for the answer, unpacks the SOAP message isolating the return value and updates its Local Execution Context accordingly. Then it adds the required local synchronization token to its context, if any, and propagates to the CtxMg the required synchronization and data tokens (fields post and out of the action). Note that the global tokens produced are not added in the Local Execution Context because they will be notified by the CtxMg exactly as the other global tokens which where not generated by this service. This supports an uniform management of the global tokens (subscription list and notification) and does not cause any misalignments on the global execution status among the service, the global Choreography Execution Context and the other services. 79
CHAPTER 5. MANAGEMENT OF A COMPOSITE SERVICE Interaction with the Context Management Service When a CI receives a set of data items and/or synchronization tokens from the CtxMg, by means of notification messages, it stores them in its Local Execution Context and checks the context for action activation. Moreover, when requested, it publishes new tokens on the Choreography Execution Context sending them to the CtxMg. Local Context Update and Action Execution The CI has to check its Local Context in order to decide if some actions become enabled (and thus have to be executed) in the following cases: • when a notification message with a new token arrives from the CtxMg; • when a send message from the wrapped web service is intercepted; • when an action execution produces any new local tokens on the Local Context1 . The Local Execution Context is checked by inspecting all the action descriptors on it; specifically an action is enabled and thus executed when the conjunction of the following conditions is satisfied: • all the synchronization tokens (both global and local) listed in the precondition (pre field) are available on the Local Execution Context; • all the data requested as input (in field) are associated with a value on the Local Execution Context; 1
The case of a new global token produced is included in the first point in the list: the notification about a new token arriving from the CtxMg.
80
5.4. EXECUTION FLOW EXAMPLES • for the SendAction, when the send message associated to the action has been already sent by the web service and intercepted by the CI. The execution of an action consists of two main points, both for the Receive Action and for the Send Action. • all the global synchronization tokens ti , listed in the post field of the action, are propagated to the Choreography Execution Context; i.e. published to the CtxMg; • all the data items listed in the out field of the action are propagated to the CtxMg. The main difference between the Receive Action and Send Action execution is that the Receive Action triggers the activation of the associated WSDL operation on the wrapped service and waits for its return value, if any, before performing the common tasks described above. Whereas, when the Send Action is performed, its corresponding web service send operation has already been performed, thus there is no need to interact with the web service.
5.4 Execution flow examples In order to clarify the choreography execution model proposed in this framework, Figure 5.1 depicts a possible execution flow after a new token has been published (by some unspecified service) in the Choreography Context: 1. CtxMg checks if the token is included in some subscription list; 2. According to the CIs subscriptions, CtxMg notifies about the new token all the interested services and, among them, the CI-WSA. 81
CHAPTER 5. MANAGEMENT OF A COMPOSITE SERVICE 3. CI-WSA updates with the new token its local context and inspects it discovering that the Receive Action op1, associated to the WSDL operation op1 of the service WSA, has been enabled. 4. CI-WSA invokes the WSDL operation of WSA, sending to it the requested SOAP message and using the required data stored in the Local Execution Context. 5. WSA executes the method op1 and returns a data item; 6. CI-WSA updates the Local Execution Context with the data returned by the execution of op1 and completes the action execution considering the tokens to be propagated to the CtxMg; 7. CI-WSA publishes the tokens to the Context Management Service; 8. CtxMg updates the Choreography Execution Context and compares the new tokens arrived with the subscription lists. 9. CtxMg notifies all the interested services and, among them, the CIWSB, about the new token available. Another interesting example of the framework execution flow derives from the following scenario: web service WSA sends two messages ms1 (x1 ) and ms2 (x2 ) in sequence to WSB, but WSB expects a unique ws3 message with both the parameters x1 and x2 . A similar situation happens in case of message split and message merge (depending on the choreography description) presented in Section 2. The sequence diagram in figure 5.2 depicts this scenario (note that in the diagram only the main execution steps are represented) showing that CI-WSB invokes the message ms3 (x1, x2) after the reception of all the needed data. 82
5.4. EXECUTION FLOW EXAMPLES
Figure 5.1: Execution flow, example 1.
Figure 5.2: Execution flow, example 2.
83
CHAPTER 5. MANAGEMENT OF A COMPOSITE SERVICE
5.5 Discussion Is interesting to note that, in the presented execution model, the web services involved are decoupled by means of the CIs mediation. For instance consider a service WSA that during its execution tries to invoke an operation on WSB. The message produced by WSA is intercepted by its Communication Interface and can result in different outcomes depending on the configuration of the CI KB: • the data items in the message (the parameters of the message) and the synchronization tokens as described in the associated Send Action, can be dispatched to the CtxMg. Then the CtxMg can dispatch the message to WSB, depending on the subscription list submitted by WSB during the registration phase; • the message can be absorbed by the CI avoiding the propagation of any tokens to the CtxMg; e.g., in an Extra Message mismatch, the message is not included in the choreography description (see Section 2.2.3). Considering the point of view of WSB, when it receives some tokens from the CtxMg, for instance the one deriving from the message sent by WSA, the analysis of its Local Execution Context searching for the actions to be performed can identify zero, one, or more enabled actions, depending on the synchronization constraints and conciliated interaction protocol mismatches. For instance, as far as the Receive Actions are concerned, there are different cases: • No action can be performed in the current Local Context. This happens in three different cases: (a) the inbound tokens have not produced enough business data to enable the execution of any WSDL 84
5.6. DETAILS ON THE INITIALIZATION PHASE operation; e.g., in a Message Merge mismatch, multiple choreography messages are mapped to a local one (see Section 2.2.2); (b) the choreography message is not mapped to any local one; e.g., in a Missing Message mismatch (see Sction 2.2.4); (c) the web service has not yet reached the phase where the operation can be executed and thus the input tokens of the action are not available; e.g., a local synchronization token misses. • One or more actions can be performed, e.g., in Message Split mismatch, the choreography message is mapped to more than one local message (see Section 2.2.1).
5.6 Details on the initialization phase This section provides to the interested readers some details about the initialization phase, as realized in the proposed execution model. As mentioned, during the initialization phase an interaction session is instantiated in order to manage the execution of the choreography instance. This is the time when the WS-Coordination model has to be executed to provide a common instance identifier. The WS-Coordination specification describes a framework for a coordination service which consists of the following component services: • an Activation service with an operation that enables an application to create a coordination instance or context; • a Registration service with an operation that enables an application to register for coordination protocols. Taking inspiration from this model, the initialization phase in the proposed approach consists of two steps: the Activation and the Registration. The 85
CHAPTER 5. MANAGEMENT OF A COMPOSITE SERVICE following two sections describe how the framework handles these steps.
5.6.1
Activation
The service that starts the choreography (the sender of the first message in the choreography) has to ask the CtxMg for a new choreography session instance (the WS-Coordination coordination context). Thus it sends a startConversation() message to CtxMg that creates the new session and replies with ctxID, the unique identifier of the new session (the WS-Coordination protocol defines the CreateCoordinationContext message for the same purpose). In the Choreography Execution Context, designed as a shared dataspace, the creation of a new context is logically equivalent to the creation of a new shared sub-dataspace identified and accessible by means of the provided ctxID. Afterward, in order to activate the other services involved in the choreography, the starting service sends to the CtxMg a series of messages activate(wsi ) passing to it the names of the selected services (on the assumption that they are pre-registered). The CtxMg forwards the messages to the mentioned services asking for their activations. Note that, although conceptually the sending of these activation messages belongs to the initialization phase, it can take place in different moments during the composite service execution. For instance, a specific service might not be involved in the composite service in the first phases of its execution. For instance a shipper service can be contacted after a complex conversation between a service client and a service supplier has taken place. Figure 5.3 shows the sequence diagram of the activation phase where WSA 86
5.6. DETAILS ON THE INITIALIZATION PHASE
Figure 5.3: Inizialization phase: Activation. sends the choreography starting message to WSB; the CI-WSA intercepts the message, asks the CtxMg for the creation of a new Choreography Context (startConcversation()) and asks for the activation of service B. Note that the “selection” of the choreography participants can take place in different ways: either directly involving the starting service, or delegating the selection to the service that sends the first message to a new service, or delegating it to the CtxMg, or providing hybrid solutions. This is an interesting topic of discussion, but it is out of the scope of this work. The coordinator CtxMg component, after having created the new context, sends to the involved web services the activate(ctxID) message, passing to them the identifier of the choreography session context. The services, after the reception of this message, can go on with the registration step.
5.6.2
Registration
During the registration step, the CI of each web service registers to the Choreography Context by sending a registration request to the CtxMg specifying the ctxID identifier (a similar register message is used in WSCoordination). Specifically, at the Registration step each CI of the services involved: 87
CHAPTER 5. MANAGEMENT OF A COMPOSITE SERVICE • subscribes for the context information relevant to the web service execution, as stored in the subscriptionList of the CI KB (see section 4.3); following the publish subscribe pattern after this operation any modification about the subscribed tokens (data items and synchronization tokens) will be notified to the service by means of notification messages; • for each new session, a new Local Execution Context and a new CI subcomponent devoted to manage it are created, in order to handle the specific choreography instance execution. The CtxMg keeps trace of the registrations received, together with the tokens for which a subscription has been requested. When the CtxMg receives a registration request from a CI it starts the new session instance. Note that following WS-Coordination, the session is started at the first registration, while the subsequent registration requests refer to the created session.
88
6 Integration of a web service in a composite service
As mentioned in Chapter 2, a web service choreography can be used as a contract among web services prescribing, from a global perspective, how a set of services have to collaborate in order to provide a composite service. If the behavior of each web service conforms to the choreography prescription, the services interact correctly and can jointly provide the composite service. This approach works correctly but embeds a lot of rigidity constraining the behavior of its participants; this represents an obstacle to the use of choreographed services in real situations. The framework proposed in this thesis aims at lowering the barriers of web services interoperability by means of a event based model, based on an action representation of web services toward an agent based view of services. After having presented the framework architecture (see Chapter 3), the mediation model exploited (see Chapter 4), and the run time behavior of the framework (see Chapter 5), this Chapter presents the guidelines and the procedures that have to be followed in order to integrate a web service in a composite choreographed 89
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE service. As showed in Chapter 3 the integration of a web service in a choreography is handled by the Communication Interface (CI) that wraps the service and manages the interaction with the Context Management Service. The CI adapts the web service behavior, when possible, to the behavior prescribed by the choreography, dealing with the most common mismatches sketched in Chapter 2. Since the CI component performs its task on the basis of the configuration information stored into the CI KB, the outcome of the integration process is a CI KB file, which specifies the mediation work to be carried out by the CI. The integration is obtained by means of a mapping between a model of collaboration represented as a web service choreography and the communication protocol of the web service to be integrated. The hypothesis is to start from a token-based representation of the communication protocol of the service obtained using the procedure described in Section 4.1 as well as a token based representation of the choreography (see Section 4.2). In the rest of this Chapter two terms are used: • local, to refer to the web service object of the integration process; • target to refer to the features of the role the web service wants to play as described in the choreography definition; i.e. the target protocol refers to the interaction protocol of a role as derived by the choreography description1 . Notice that, event if the reasoning focuses mostly on the mapping between the local protocol to its target protocol, in this work the discussion is often 1
That can be obtained by means of choreography projection.
90
focused on the mapping of the local protocol directly to the choreography description, in order to obtain a more flexible mapping where also roles different from the target one can be involved. By means of this mapping, a correspondence is defined between the local web service execution and the progress in the execution of the composite service. The integration process is a complex task, requiring a large amount of domain and technical knowledge. The general assumption is that an expert performs this task, providing all the required mapping information. The idea is to provide this expert with a set of guidelines in order to facilitate this work together with automatic procedures, when possible. In the different phases of the integration, the expert is also in charge of deciding if some of the identified mismatches are unsolvable and thus if the integration fails (unless business logic changes on the service). The integration process is composed by five steps described in Section 6.1: the Data Mapping (Phase 1), the Message Mapping (Phase 2), the Token Mapping (Phase 3), the CI KB Updating (Phase 4) and the Validation (Phase 5). Among them, the data mapping and the message mapping are in charge of the users, whereas the others can be supported by automatic procedures. In particular during the CI KB Updating (Phase 4) several mapping rules are applied in order to manage the identified mismatches. The details of these mapping rules are described in Section 6.2 where for each mismatch pattern considered a rule to solve it is presented. However the number of the different possible mappings and mismatches is unlimited in real cases and the procedure presented only deals whit the ones identified and described in Chapter 2. With respect to this problem 91
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE the purpose of this Chapter is twofold. First, it presents (see Section 6.2) a set of rules that can manage the most fairly frequent cases of mismatches between interaction protocols: these rules are easily applicable by a human or by an automatic procedure in order to configure the CI KB. The cases considered are a subset of the possible cases, but are the ones examined in other significant works in the literature; i.e., [12], [19], [75]. Second, Section 6.3 presents some special cases where custom solutions are applied; the analysis of these special cases and the description of the possible solutions help to understand how the proposed mediation model can be exploited in order to manage different and more complex situations.
6.1 The integration process The integration process includes several phases and a set of working artifacts that are used to obtain the desired CI KB configuration file. This Section details these phases. The process is based on the assumption that the following description is provided: • a graph representing the choreography, decorated with the global synchronization tokens (as for instance the one depicted in Figure 4.4); • a graph representing the interaction protocol of the service, decorated with the local synchronization tokens (as for instance the one depicted in Figure 4.1); • a CI KB file containing the action based representation of the interaction protocol obtained following the procedure described in Section 4.1.1. 92
6.1. THE INTEGRATION PROCESS
Table 6.1: Data Mapping Table of WSA within choreography ChorX. Choreography business data x1 x2 ... pt
Local data x′1 x′2 ... p′t
As an example of some of the artifacts produced during the integration process, the integration of service WSA in the ChorX choreography is considered. See Section 4.3 and Figure 4.6.
6.1.1
Phase 1 - Data Mapping
The first step is to map the parameters of the messages occurring in the local interaction protocol to the business data specified in the choreography. The artifact produced by this task is the Data Mapping Table, where the data names used in the local interaction protocol are associated to the names used in the choreography description for the same data; e.g., see Table 6.1. During this phase, the user might identify several data mismatches and might also decide to stop the mapping with a failure. As mentioned in Chapter 2 this thesis does not deal with problems of data heterogeneity (see Section 10.3); however situations where some of the local business data items cannot be mapped to any target business data items, or vice versa, are considered. Specifically: • If the target interaction protocol specifies that the web service should provide a business data item, but the web service does not provide it, there may be two cases: either it represents mandatory information, or it is an acknowledgment. If it is a mandatory information, the conflict cannot be solved and 93
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE the mapping phase fails. Notice that this is true unless the data item is just propagated by the local protocol, but produced by another service in the choreography. In this case the service can ignore this data item, in fact the peer to peer data propagation is unnecessary in a shared data space where, once a data item has been provided by a service, it is available to all the services interested in. If it is an acknowledgment or a data with a predefined value, the conflict can be solved by defining a new data item associated to a default value. This is obtained adding the new data item in the Default Data Table where a new data name is associated with a default value. Afterwards, the name of the data, for uniformity, is added to the Data Mapping Table, where the new data name is associated to its name in the choreography. • If the target interaction protocol specifies that the web service should receive a business data item, but the web service does not receive it, either the data item represents mandatory information, or it is an acknowledgment. If it is a mandatory piece of information, it probably means that for the composite service, the local service should use this information in its logic. This in general makes the integration fail, but as always this decision is taken by the user. Otherwise, if it is an acknowledgment or a data item not significant for the composite service execution, the conflict can be solved by simulating the receiving of the data in the service. Notice that if the data item is received only in order to be propagated to another service, the service can ignore this item (see the previous case). • If the local interaction protocol specifies that the web service should 94
6.1. THE INTEGRATION PROCESS receive a business data item, but the target interaction protocol does not include it, there may be two cases: either it represents mandatory information, or it is an acknowledgment. In the former case, the mapping phase fails unless the data item can be provided by another role in the choreography; in this case the data item is added in the Data Mapping Table and the process goes on. In the latter case, the conflict can be solved by entering in the Default Data Table the expected data associated to a default value.
• If the local interaction protocol specifies that the web service should provide a business data item, but the target interaction protocol does not include it, this is not a problem as the rest of the composite service can ignore it. This behavior can be obtained excluding the data item from the out field of the associated action in the CI KB, or can be obtained without any modification after verifying that the name of the data is unique in the choreography (no service in the choreography subscribes for it and the data does not impact on the choreography execution).
Note that the management of a received data item can be more flexible than the case of a data item to send. In the receive case, if the data item is provided by a service different from the one expected in the local protocol, this is not a problem: the item is included in the subscription list and notified to the service, and this is independent of who published it. Conversely when a service has to provide a data item, which is not just propagated, a similar reasoning is not possible. It is not possible to relay on another service in order to produce a data item without introducing 95
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE Table 6.2: Message Mapping Table of WSA within choreography ChorX. # 1
Choreography messages send(A, msg1 (x1 , . . . , xn ), B)
2
receive(A, msg4 (p1 , . . . , pt ), B)
WSA messages send(mes1 (x′1 , . . . , x′r ), W SB) send(mes2 (x′r+1 , . . . , x′n ), W SB) receive(mes3 (p′1 , . . . , p′t ), W SB)
Kind One to N One to One
new constraints on the other role fillers of the choreography2 . Therefore in general the management of data items in input is more easy and does not require particular considerations.
6.1.2
Phase 2 - Message Mapping
In this phase the inbound and outbound messages of the local interaction protocol (send s and receives) are mapped to the messages of the choreography. In general the choreography messages mapped refer to the target role, but as already mentioned, the mapping can involve also other services. During this phase, the user might identify some local messages which have no correspondence in the target protocol, or vice versa. It is up to the user to decide whether such conflicts can be solved, or they are fatal and they make the mapping fail. This task produces the Message Mapping Table, which relates the messages of the web service to the messages of the choreography, together with an indication of the kind of mapping realized, set on the basis of the mismatch patterns considered in Chapter 2. An example of Message Mapping Table is showed in Table 6.2. Two things are worth mentioning: first, the table may have incomplete rows, corresponding to the unmapped messages (in 2
This is an interesting future research direction, but is at the moment out of the scope of this work. In this work are considered integration processes that are totally transparent to other services taking part to the choreographed service.
96
6.1. THE INTEGRATION PROCESS
Table 6.3: Token Mapping Table of WSA within choreography ChorX. # 2 3
Choreography global tokens t1 t8
WSA local tokens s2 s3
case of Missing Message or Extra Message mismatch). Second, if a message compares more than once in the protocol (e.g., in alternative paths of the composite service), the table contains duplicated rows because each path has to be separately mapped.
6.1.3
Phase 3 - Token Mapping.
Starting from the artifacts generated in the previous phases, the Data Mapping and the Message Mapping Tables, an automated procedure maps the tokens defined in the token-based representation of the local protocol to the tokens of the choreography protocol. This task produces the Token Mapping Table; e.g., see Table 6.3. The mapping depends on the kinds of mismatch patterns identified, specifically: • One-to-One mapping: the outgoing token3 of the local message is mapped to the outgoing token of the choreography message. The outgoing token in the choreography sets that the communicative action represented by the node has been performed; the same meaning has the local outgoing token of the message in the local protocol and thus the two tokens can be mapped to each other. A similar reason3 As mentioned in Section 4.1 the term outgoing token of a message is used to refer to the token labeling the arc outgoing from the Communicative Node representing the message in the token based graph representation. Similarly the term incoming token of a message refers to token labeling the arc entering the node.
97
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE ing cannot be done for the synchronization token associated to the inbound arc (incoming token). In fact this token prescribes to wait, before performing the action of the node, that the previous action has been performed. The service performing the action must produce this token and such a service can be different in the choreography and in the local. In the example depicted in Figure 6.1 s2 maps to t2. • One-to-N mapping: the rule described for the One-to-One case is applied to the last message4 of the set of local messages associated to the choreography one. Only the outgoing token of the last message in the local protocol is mapped to the outgoing choreography token of the associated message. This because the action in the choreography has been completed only when all the N mapped actions in the local protocol have been performed; i.e. when the last message has been performed. This rule considers mismatch patterns where the N messages belong to the same branch of the graph, particular cases of mapping involving parallel branches are discussed in Section 6.3. In the example depicted in Figure 6.1 s3 maps to t2. • N-to-One mapping: the rule described for the One-to-One case is applied considering the local message and the last message of the N choreography messages associated. The outgoing token in the local protocol sets that the sequence of the mapped messages in the choreography has been performed, and then corresponds to the outgoing token of the last message in the choreography. Also for this case, special cases of mappings involving parallel branches are discussed in 4
Last with respect to the order defined in the graph representing its protocol.
98
6.1. THE INTEGRATION PROCESS Section 6.3. In the example depicted in Figure 6.1 s2 maps to t4. • Zero-to-One mapping: in this case no mapping is performed since the local message does not have a related message in the choreography and it needs only to be synchronized with respect to its local business logic. The execution of this local message does not directly affect the choreography execution. • One-to-Zero mapping: in this case no mapping is performed since there are no local tokens candidate to the mapping.
6.1.4
Phase 4 - CI KB Updating.
Given the previous three mapping tables (Data, Message and Token Mapping Table), and the token-based representations of the local and target protocols, an automated procedure updates the starting CI KB of the local service and generates the new CI KB, configured to manage the integration of the service in the choreographed service. Specifically: • all the occurrences in the CI KB of the local tokens si are replaced with the associated choreography tokens tj in the Token Mapping Table (and on the graph representation); • in order to synchronize the local service with the choreography, the CI KB is updated by means of several Mapping Rules depending on the kind of the involved mismatches. A description of these rules is provided in Section 6.2; • the subscription list is created considering all the synchronization tokens presented in the precondition fields (pre) of the action descriptors 99
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE
Figure 6.1: Token mapping.
100
6.1. THE INTEGRATION PROCESS and all the data items presented in the input (in) fields. Note that, in order to fill the subscription list with the data name used in the choreography, the Data Mapping Table is used.
6.1.5
Phase 5 - Validation.
The human user (an analyst or a developer, or in general a user with some technical and domain knowledge) checks the CI KB obtained for correctness and completeness and possibly adjusts it. In order to support the user in this not trivial task, two mains tools are provided: Checklists and Testing tools. Checklists help and drive the user in its activity suggesting a list of aspects to consider and evaluate; for instance a checklist can include the following operations: • Data review ; e.g. remove all the propagated data items from the out field (i.e. out should contain only new or revised data items); • Local Actions Review ; e.g. check that all the messages sent and received by the local service have a corresponding action descriptor in the CI KB; • Target Actions Review ; e.g. check that all the messages of the target protocol (in the choreography) have been considered; • Check subscriptionList; e.g. check that all the data items and synchronization tokens in the in and pre fields of each action descriptor are in the subscription list; Testing Tools can be used to test the action-based execution of the service in a simulated environment. The user can simulate different execution 101
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE flows of the choreographed service testing the behavior of the local service. See Section 7.3 for an overview of the available testing tools and Section 8.4 for an example of use.
6.2 Mapping Rules for CI KB updating During the Phase 4 of the integration process (see Section 6.1.4) the CI KB is updated in order to correctly integrate the service in the choreographed service. This is done by means of some Mapping Rules that prescribe how to update this file, depending on the different kinds of mismatch patterns identified in the Message Mapping Table. As shown in the following, the updating can include both the modification of the fields of the existing action descriptors and the insertion of new descriptors. These new action descriptors are called ChorAction and are defined with the only goal of simulating the communicative behavior prescribed by the choreography. ChorActions are used to simulate, at local level, the execution of the operations required by the choreography that not have a corresponding action descriptor in the CI KB (as derived by the local protocol). Moreover ChorActions can be considered as dummy action descriptors that implement a special purpose behavior in order to make the local service compatible with the global collaboration model. A ChorAction looks like another action descriptor, a part for the op field that is empty. When a ChorAction is executed, following the same procedure described for the other actions in Chapter 5, its outcome is the publication of the tokens included in the out and post fields (without any side effects or particular meaning in the local service logic). The Mapping Rules are applied to each row of the Message Mapping 102
6.2. MAPPING RULES FOR CI KB UPDATING
Figure 6.2: One-to-One mapping rule. Table, in order to provide a descriptor for each message occurring in the local or in the target interaction protocol. However, the order of application of such rules depends on the local protocol; starting from its start node, and following the paths of the interaction graph, the rules are applied in order to synchronize the local messages to the choreography. Then, the messages of the target interaction protocol which are not mapped to any local messages (Zero-to-One Mapping) are considered in order to generate their descriptors in the CI KB. In the rest of this Section the mapping rules for the mismatch patterns introduced in Chapter 2 are presented.
6.2.1
One-to-one mapping
In this case there is a one-to-one correspondence between a message of the local and one of the target protocol and thus is sufficient to synchronize the activation of the local action to the choreography prescription. Then a revision of the data items according to the possible signature mismatches is necessary. The action descriptor of the involved message in the CI KB is updated as follows: • the action has to start respecting the choreography prescription, thus it has to get the precondition (the incoming token) of the mapped 103
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE
Figure 6.3: One-to-N mapping rule.
choreography message. In figure 6.2 the token t1 is added in the pre field; this means that if other tokens are present in this field the new token is joined in AND with them. If the token to be added is already present in the pre field it is not added again: in figure 6.2 this happens if t1 has been previously mapped to s1.
• the fields in and out are updated according to the mapped choreography message considering the Data Mapping Table. During this operation some of the data mismatches presented in Section 6.1.1 might be managed.
Notice that in the figure message mappings are linked by dotted lines, while token mappings by dashed lines5 . The arrows denote global tokens added in the local protocol to synchronize it with the choreography. 104
6.2. MAPPING RULES FOR CI KB UPDATING
6.2.2
One-to-N mapping (Message split mismatch)
In this case a set of messages in the local protocol maps to a message in the choreography. This means that the joint contribution of the local messages corresponds to the contribution of the target message (message split). In this case the execution of the actions related to the N messages of the local protocol has to be enabled as described in the choreography; i.e. by the incoming token of the choreography message. Figure 6.3 shows an example where the messages are ordered in a sequence on the same branch of a graph, in this case is sufficient to work on the first message of the local protocol. In the figure, t1 is added to the precondition of the action descriptor associated to msgb in the local service. Adding t1 also in the precondition of the other actions is useless in this case. On the contrary when the N messages are placed in different parallel branches this is needed. This case is treated a part in Section 6.3. No particular management different from the one already described for the case One-to-one is requested for the other fields of the action descriptors.
6.2.3
N-to-One mapping (Message merge mismatch)
In this mismatch pattern a message in the local protocol maps to a set of messages in the choreography. This means that the contribution of a single local message corresponds to the joint contribution of all the target messages (message merge). In this case the rule splits in two different rules depending on the kind of the messages: if they are send messages or receive messages. 5
In this case the local token is replaced by the mapped global token during the CI KB Updating, the phase 4 of the integration process (see Section 6.1.4)
105
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE
Figure 6.4: N-to-One mapping rule - Send case.
N-to-One mapping - Send case
The sending of the message in the local protocol can start just after the incoming token of the first message in the choreography is available, as in the previous cases examined. Thus the pre field of the Send action descriptor in the CI KB gets this choreography token. In figure 6.4 the token t1 is added to s1. Then, since the local message corresponds to the execution of the N choreography messages associated, the outcome of its action description has to produce all the synchronization tokens produced in the choreography by these messages (the outgoing tokens of each choreography message). In Figure 6.4 t2, the outgoing token of msga , has to be added to the postcondition (post) of the local action descriptor. 106
6.2. MAPPING RULES FOR CI KB UPDATING
Figure 6.5: N-to-One mapping rule - Receive case.
N-to-One mapping - Receive case In this case the mapping is a little more complex. Since the local receive corresponds to N receives in the choreography, the local receive gets, as precondition, all the incoming tokens of each mapped message in the choreography. In Figure 6.5 t1 and t3 are added to s1 as precondition in the action descriptor of msgc . The problem is that, following the choreography schema, the local service is also in charge of the production of the outgoing tokens of the N messages it maps. This is the case in Figure 6.5 of t2. If this token is not produced by the local service, the service playing the role A cannot send msgb (it waits for t2 ). The production of this token cannot be added to the postcondition of the local action descriptor: in this case a deadlock is produced. In fact, referring to Figure 6.5, the local service waits for t3 in order to start the action and produce t2, and the service playing role A waits for t2 in order to activate 107
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE msgb and produce t3. Thus the solution is to define new ChorActions. Specifically, for each choreography message involved in the mapping, a part for the last one, a new ChorAction is defined and filled as follow: • the pre field is set with the incoming token of the message; • the post field is set with the outgoing token of the message; • the in and out fields are left empty. In this way the behavior required by the choreography is simulated in the local protocol.
6.2.4
Zero-to-One mapping (Extra message mismatch).
In this case the local message cannot be mapped to any message of the target interaction protocol (extra message mismatch). Also in this case the rule splits depending on the kind of the message.
Zero-to-One mapping - Send case If the message is a send, it can be ignored in the composite service. The solution is to absorb the message, and that can be done by clearing its out field in the associated action descriptor. Notice that this message belongs to the local protocol, then the associated action descriptor is present in its CI KB file. Moreover its postcondition field contains only local synchronization tokens; thus, it does not produce any tokens to be published to the CtxMg. 108
6.2. MAPPING RULES FOR CI KB UPDATING Zero-to-One mapping - Receive case If the message is a receive the problem is the one described for the Data Mapping table in Section 6.1.1. If the data received does not represent an unsolvable conflict, the problem can be handled, for instance, by using the Default Data Table. The data items in the in field are got from this table and, when the precondition is satisfied (when the required local tokens are available) the operation can be invoked. If the receive has not parameters, the problem is solved without any updating. In fact, as soon as the local synchronization token is available, the action is executed (without any direct dependency on the choreography execution).
6.2.5
One-to-Zero mapping (Missing message mismatch)
In this case the choreography message cannot be mapped to any message of the local interaction protocol (missing message mismatch). The mapping can be solved by defining a new ChorAction descriptor in order to manage the missing message in the local protocol. In particular: • the precondition pre is set with the tokens associated to the incoming token of the message in the choreography and the postcondition post with the outgoing token. The rationale is that the message does not exist in the local protocol; therefore, it has only to be synchronized with respect to the target protocol and to produce the required synchronization global token (in order to avoid blocking the choreography execution). • The output field out is filled with the output data of the message in the choreography (the argument of the message in case of a send). In 109
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE this case data from the Default Data Table can be useful6 (see Section 6.1.1). The input field can be left empty also in case of a receive action: the ChorAction represents an action with no associated operation in the local protocol and thus the data items required are not used in the business logic of the local service, at list in this point.
6.3 Special cases In principle a lot of different mismatch patterns can be isolated, categorized and provided with a special purpose rule, as done for the mismatch patterns presented in Section 6.2. Or more realistically, a good understanding of the model presented can be used by an expert in order to manage different particular cases of service integrations. The approach suggested in this thesis is to use the standard rules described in Section 6.2 to manage the most common mismatches and exploit the flexibility of the framework in order to configure custom solutions to the other cases. The idea is that the complexity of isolating the different kinds of mismatch patterns and developing the associated rules, and then the effort required to the user to identify the different typologies of mismatches in its scenario, is comparable to the effort required to manage the different cases providing custom solutions. The purpose of this Section is to present how particular cases involving more complex mappings than the ones presented in Section 6.2 can be managed by using the proposed model. Ordering mismatches (see Section 2.2.5) for their particularity and mappings involving different graph branches are included here. 6
As always, as hypothesis, the mismatch is solvable.
110
6.3. SPECIAL CASES
Figure 6.6: Unspecified reception.
6.3.1
Message Ordering
As mentioned in Section 2.2.5, ordering mismatch patterns occur when the service choreography expects messages in a different order with respect to the one specified in the communication protocol of the local service. These complex mismatches deserve a specific analysis and require customized solutions. This Section presents some examples. Unspecified Reception The example in Figure 6.6 depicts a case that Motahari Nezhad and colleagues in [75] use to represent a typical situation of what they call an unspecified reception, in which one party sends a message in a step of interaction where the other is not expecting it. The service B ′ in its protocol receives the two messages in the opposite 111
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE
Figure 6.7: Deadlock - First case. order prescribed in the choreography. As shown in the figure the problem is solved by using a ChorAction that simulates the receiving of msga when expected by the global model. This ChorAction has t2 in the precondition and t3 in the postcondition and allows the choreography execution to continue by simulating the correct reception of the message. When the last receive action in the local protocol has been executed, t5 is produced in order to continue the choreography execution. Deadlock This set of mismatch patterns includes cases of deadlock as the one presented in Chapter 2 in Figure 2.8. The same example is depicted in Figure 6.7 where, starting from the message mapping, the Mapping Rule for the One-to-One case has been applied. The figure highlights the deadlock: s2 112
6.3. SPECIAL CASES is mapped to t4 and synchronizes the receive action of B’. s3 is mapped to t3 and is generated by B’ after its receive activity. But t3 also synchronizes the sending activity of B’. In this case a possible solution is to remove the synchronization of the first send activity of service B’ ; that means removing t3 from the precondition of the action description for the activity send(msgb (. . .)). This configuration makes possible, for instance, this sequence of events: • A executes the action associated to msga and produces t2 ; • when B ′ sends msgb , the associated action is executed and the token t4 (s2 ) is generated (the action can be executed because token t3 has been removed); • t2 is available then B’ can execute the receiving of msga ; • A executes its receive action msgb ; Notice that, with this configuration the order prescribed by the choreography is not exactly respected 7 . Assessing the correctness of this solution is a task in charge of some human expert and is out of the scope of this work. Figure 6.8 shows a deadlock situation dealing with the same choreography but involving service A′ aiming at playing role A. In this case, to activate its receive action msgb , A′ needs the data items y1 , . . . , ym and the token t4 provided by B soon after the sending of msgb . The problem 7 Relaxing the sequence order imposed by t3 means to give a new interpretation of the choreography where some parallelism in the execution of the two messages exchanges of msga and msgb is acceptable. Moreover in this case the protocol of B ′ suggests that there is not dependency between the data x1 , . . . , xn and y1 , . . . , ym , contrary to what the choreography seems to suggest (y1 , . . . , ym are sent before the receiving of x1 , . . . , xn ).
113
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE
Figure 6.8: Deadlock - Second case. is that, as defined in the choreography, B can provide them only after it receives msga from A. In this case without changing the business logic of service A′ , it is not possible to implement a solution as the one presented for service B in Figure 6.7. In fact, is not sufficient to remove the token t4 in the precondition of its receive action msgb in order to execute the action, in this case the data items y1 , . . . , ym in its input field are required8 . Also forcing A’ to send its msga before the receiving of msgb is not possible without changing its logic since in its business logic the two actions are ordered in a sequence. In this case the mapping will fail unless some other service in the choreography can provide the needed data y1 , . . . , ym . Of course this possibility cannot be assumed by the designer of service A′ independently, but some 8
Of course the problem changes if msgb has not parameters.
114
6.3. SPECIAL CASES
Figure 6.9: One-to-N mapping - parallel branches. other service in the choreography has to be involved.
6.3.2
Mapping involving parallel branches
The rules described so far consider mismatch patterns where the nodes involved belong to the same branch of a graph. The problem can be different when the nodes belong to different branches. As already mentioned, this work focuses on cases that are solvable. There are some cases that obviously fail: for instance in a One-to-N mapping if the N nodes of the service belong to alternative branches (starting from a common XOR; i.e. exclusive choice) the match is not possible and the integration fails. Conversely the mapping can be possible when the nodes belong to parallel branches (starting from a common AND; i.e. parallel split). One-to-N mapping Figure 6.9 shows an example of this case, where two local messages placed on parallel branches map to one message in a choreography. The example 115
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE highlights the problem of the token mapping: the choreography token t2, stating that service B has received all the data items x1 , . . . , xn , corresponds to the two local tokens s3 and s4. That means that t2 has to be mapped to the conjunction of s3 and s4. Instead of changing the representation of the Token Mapping Table, that allows a 1 to 1 mapping between tokens, the problem can be managed by using a ChorAction. A new ChorAction with s3 and s4 in the precondition and t2 in the postcondition can be used to generate the global synchronization token as required by the choreography, without affecting the logic of the local service. The execution of the ChorAction, and then the generation of the correct token, is delegated to the runtime action management (that manages this action exactly as the others, see Section 5.3.2). The integration is then completed by synchronizing the service execution to the choreography. This corresponds to adding the incoming token of the choreography message to the precondition of the actions corresponding to the first local message encountered on each parallel branch. In the example t1 is added both to msgb and msgc . N-to-One mapping A similar case consists in a mapping where multiple messages in a choreography, placed on different parallel branches, map to a message in a local service. Figure 6.10 depicts an example of this. In this case the local outgoing token s2, stating that the service has sent the message msgc with the data items x1 , . . . , xn , corresponds to the two choreography tokens t2 and t4. This can be obtained defining a new ChorAction with s2 in the precondition and t2,t4 in the postcondition9 . Then, in order to complete the integration, the local action has to be synchronized to the choreogra9
Another possible solution is filling two rows of the Token Mapping Table ([s2,t2],[s2,t4] ), but require the management of this double mappings at runtime.
116
6.3. SPECIAL CASES
Figure 6.10: N-to-One mapping - parallel branches. phy execution by adding all the incoming tokens of the choreography nodes involved (actually is sufficient to consider the first node of each branch). In the example this means adding in the precondition the tokens t1 and t3.
6.3.3
A Request-response example
The example studied so far uses choreographies and interaction protocols built combining one-way (i.e., asynchronous) messages. The idea is to use this representation for simplicity, taking in consideration that synchronous messages, consisting of request-response couples, can be written as a sequence of two one-way, asynchronous messages. When the problem of integrating an existing service in a given choreography model is managed, it is highly probable to run into operations designed as request-response operations. The proposed model supports these oper117
CHAPTER 6. INTEGRATION OF A WEB SERVICE IN A COMPOSITE SERVICE
Figure 6.11: Request-response example. ations and the Receive Action descriptor includes an output field for the purpose. Therefore the mapping of a request-response message to a couple of one-way messages with the same functionality is trivial. As example of integration, Figure 6.11 shows a more interesting situation where a service B ′ defines an operation msgb , without parameters and returning y1 as output. This data item maps to the choreography data item x1 , that, as prescribed by the choreography, a service playing role B should send to role A. The problem is that service A expects to receive data from service B, but although service B ′ is able to provide the requested data, it waits for an explicit request of it. In this case the mapping can be solved using the Mapping Rule presented for the One-to-One rule (see Figure 6.11).
6.4 Discussion Section 6.3 showed particular cases of mapping that have to be managed by using special rules, a little different from the one presented in Section 6.2. As mentioned two approaches are possible: to collect and classify all the possible mismatch patterns and compile a specific rule for each pattern (as done for the cases presented in Section 6.2), or to adopt the approach 118
6.4. DISCUSSION suggested in this thesis; i.e. to rely on the user capability in order to configure the framework to deal with particular cases of mismatch. In both cases the point is that the mediation model presented is very powerful and flexible. Therefore, it can be instantiated and configured in order to manage a lot of complex situations without changing the business logic of the involved services. That means that with a little configuration effort it improves the interoperability between services.
119
7 Prototype
Part of the work of this Phd thesis has been devoted to the implementation of a prototype realizing the proposed event-based execution framework. The complete development of the mediation model described in this work should cover two main parts: the implementation of the tools helping the representation and the configuration of the different components involved in the composite service and the implementation of the infrastructure supporting the event-base runtime execution of the composite service. Elements included in the first aspect should be software components supporting the token based representation of interaction protocols and choreographies, possibly with translation tools to import descriptions in different languages; user interfaces helping the user during the definition of the mapping tables and the configuration of the CI KB and tools automatizing parts of the mapping procedure. These elements are not in the focus of this thesis. Conversely the implementation work has been focused on the realization of the runtime part of the framework, with the goal of providing a software environment for the execution model described in Chapter 5. Moreover a 121
CHAPTER 7. PROTOTYPE
Figure 7.1: Software architecture. set of testing tools has been realized, helping the user to verify the correct final integration of the service in the choreography. The prototype developed as a reference implementation of the mediation framework has two main components: • A tool implementing the functionalities of the Context Management Service (CtxMg). • The Communication Interface (CI), which wraps a web service by taking its interaction protocol into account, and which correctly communicates with the CtxMg following the behavior prescribed by the composite service. The resulting software architecture is depicted in Figure 7.1. The rest of this Chapter presents a more detailed description of these components. 122
7.1. CONTEXT MANAGEMENT SERVICE (CTXMG)
7.1 Context Management Service (CtxMg) The CtxMg has been developed by exploiting the GigaSpaces middleware [44], which offers a robust implementation of the JavaSpaces [54] paradigm supporting the propagation of data items according to the Linda [2] tuple space model. GigaSpaces provides a scalable environment where several clients can collaborate by publishing and reading information (publish/read in Figure 7.1). Moreover, it offers a Publish and Subscribe mechanism that enables clients to subscribe for notification on events (e.g., creation, update, deletion) concerning particular data items (subscribeFor/notify in Figure 7.1). The GigaSpaces software includes a server part implementing the shared tuple spaces and a client part consisting of a set of utilities and facilities enabling a Java-based application to easily and transparently connect to the tuple spaces. Furthermore, it supports scalability, space replication, and a data persistence mechanism based on Hibernate or on other widely used persistence tools.
7.2 The Communication interface (CI) As described in Chapter 3, the CI mediates the interaction between the CtxMg and the web service it wraps. The design of the architecture of the CI has been inspired by the goal to obtain a software artifact quite flexible, able to easily integrate different kinds of service components in different environments. The main consideration is that the services candidate to be integrated can be heterogeneous under different aspects. First, when standard web services, based on WSDL and SOAP, are considered, different versions or implementations of these standards can hamper 123
CHAPTER 7. PROTOTYPE the effective interoperation among them. Similar technical problems also arise when services are implemented in different languages and hosted in different environments. Second, the same idea of composing and integrating services involves the possibility to integrate and compose different software entities, providing services which use different standards and technologies; i.e. RESTFUL web services, RMI services, CORBA components and so on. Third, the proposed computational model seems suitable to integrate, using ad hoc interfaces, existing legacy systems that do not support any WSDL interface. Taking into account these considerations the Communication Interface in the prototype has been designed with the goal to decouple its business logic from the peculiarities of specific environments; i.e., the specific CtxMg implementation adopted (GigaSpace) and the typology of the services considered (standard web services). As shown in the Figure 7.1, the CI consists of three main components: • The KernelCI, that offers the core CI functionalities (the CI business logic) and implements the execution model presented in Chapter 5. • The CIProxyOUT interface, that mediates the interaction with the CtxMg and the KernelCI. • The CIProxyIN interface, that mediates the interaction with the wrapped service and the KernelCI. The CIProxyOUT and the CIProxyIN have been designed as interfaces in order to decouple the KernelCI from the technologies and the communication protocols used by the Context Management Service and by the 124
7.2. THE COMMUNICATION INTERFACE (CI)
Figure 7.2: CI Architecture. wrapped services. While the former abstraction enables the replacement of the Context Management Service, the independence of the wrapped service enables the integration of web services, as well as of Java-based applications and other kinds of software components. Specifically, different implementations of the interfaces can be developed depending on the particular environment and technology used, without changing the business logic of the KernelCI. Figure 7.2 details the architecture of the CI component.
7.2.1
The KernelCI
The kernelCI implements the core business logic of the Communication Interface; specifically: • When the composite service is launched (start-up phase, see Section 125
CHAPTER 7. PROTOTYPE
Figure 7.3: ActionDescr states transition. 5.1), the KernelCI reads the configuration settings from the CI KB. Notice that the CI KB is an XML document, created at set up time, as described in Chapter 6. • During the initialization phase (when the composite service is invoked, see Section 5.2), based on the configuration information, the KernelCI creates an object representing the Local Execution Context. Moreover, it asks the CIProxyOUT to subscribe to the Context Management Service for the relevant context information (subscribeFor in Figure 7.2). • At runtime, the KernekCI manages the Local Execution Context as described in Section 5.3. In particular, when it needs to interact with the CtxMg it calls the methods offered by the CIProxyOUT (publish and read in Figure 7.2). Moreover when it needs to call some operations on the wrapped service it uses the method offered by the CIProxyIN (callOp in Figure 7.2). A different Local Execution Context is instantiated for each active instance of execution, and different identifiers Ctx-IDs are used to distinguish 126
7.2. THE COMMUNICATION INTERFACE (CI) them. A Local Execution Context is represented as a set of objects ActionDescr representing the Action descriptor (see Section 4.1.2) stored in the CI KB file. Each time a new item arrives to the Local Context (synchronization token or data item) each ActionDescr object is checked to verify if it includes this token in its input or precondition fields1 . The automaton in Figure 7.3 describes the state evolution for an ActionDescr object during its life. As soon as the instance of the ActionDescr is created, its state is waiting: in this state it waits for new tokens. For each new token arrived the ActionDescr is checked and updated accordingly. If its input field is completely filled and its precondition is satisfied, it goes in state enabled : in this state the ActionDescr is ready to be executed. When the KernekCI finds an enabled action it executes the Action2 and turns it in state fired : this state means that the action has been executed and not other transitions can takes place.
7.2.2
The CIProxyOUT and the CIProxyIN
The CIProxyOUT offers to the KernekCI an interface to the CtxMg, and for that purpose it offers to it the methods used for publish and red information from the tuple space (publish and read ). The CIProxyOUT is also in charge of the management of the publish/subscribe implementation offered by the CtxMg using the requested protocol (depending on the specific implementation of the CtxMg). However it offers to the KernelCI standard methods (subscribeFor and notify in Figure 7.2). The interaction with the service, using the correct protocol, is delegated 1 The attributes defined for the ActionDescr objects are the same defined for the ActionDescriptor components described in Section 4.1.2 2 The action execution is the one described in Section 5.3.2 and is realized by using the CIProxyIN and CIProxyOUT components.
127
CHAPTER 7. PROTOTYPE to the CIProxyIN component. The CIProxyIN offers the callOp method to the KernelCI and invokes on it the send method (when manages the messages sent by the service). In the software prototype realized the KernekCI has been implemented in Java and the CIProxyIN and CIProxyOUT components have been realized as Java interfaces. Java has been selected as it is particularly suitable for this kind of applications and since almost all the most widely used tools to realize web services and process-based web services supports it.
7.2.3
CIProxyOUT and CIProxyIN instantiations
An implementation of the CIProxyIN and CIProxyOUT components has been realized, following the architecture described and according to the CtxMg implementation used and to the kind of services considered. CIProxyOUTGiga As mentioned in Section 7.1 the CtxMg has been realized using the Gigaspace middleware, therefore a specific CIProxyOUT implementation, the CIProxyOUTGiga, has been developed. Exploiting the java client libraries offered by Gigaspaces, the CIProxyOUTGiga implementation connects to the server GigaSpace (the CtxMg), publishes data on it and implements the Publish and Subscribe pattern provided by such a tool. CIProxyINWS This thesis focuses on web services choreographies, then the goal of the prototype is to integrate web services. Therefore a CIProxyIN implementation for the integration of standard web services (based on WSDL and SOAP) 128
7.2. THE COMMUNICATION INTERFACE (CI)
Figure 7.4: CIProxyInWS logical architecture. has been developed: the CIProxyINWS. The CIProxyINWS manages the interaction with the KernelCI and with a web service; specifically: • it invokes the WSDL operations offered by the web service when the related callOps are invoked by the KernelCI; • it intercepts the SOAP messages that the service tries to send and it translates them to the invocations of the send method of the KernelCI. Figure 7.4 depicts the logical architecture underlying the CIProxyINWS applied to a generic web service (Web Service A in the figure). As showed in the figure the CIProxyINWS is composed by two elements: the HandlerClient and the CIProxyINWS . The HandlerClient is a web service handler that is used to intercept the 129
CHAPTER 7. PROTOTYPE messages that the web service sends to other web services. In Figure 7.4, when Web Service A sends a SOAP message (for instance to a Web Service B), the handler parses the SOAP message intercepted, retrieves the invoked operation and the parameters passed, and notifies the CIProxyINWS (msgIntercepted ). The CIProxyINWS forwards this information in the format required to the KernelCI (using a send ). The CIProxyINWS is also in charge of invoking the WSDL operations on the service. Looking at the figure, when the KernelCI needs to invoke a WSDL operation on Web Service A, it delegates the CIProxyINWS (callOp) passing the operation name and the parameters list. Then, the CIProxyINWS, by means of its CIProxyINWS component, dynamically creates the correct SOAP message and sends it to the service (invoke SOAP ). If the operation has a return type, the CIProxyINWS waits for the answer (return SOAP ) and returns the value to the KernelCI. The interactions with the wrapped web service just described are reported in the sequence diagram in Figure 7.5.
7.3 Testing Tools Together with the Context Management Service and the Communication Interface implementations, a set of testing components are provided with the prototype. By means of a simulation of the execution of a choreographed service, these testing tools permit to verify: • the correct action based execution of the web service, verifying the interaction and the messages exchanged between the CI and the integrated service; 130
7.3. TESTING TOOLS
Figure 7.5: CIProxyInWS - WS interaction sequence diagram. • the correct integration of the service in the composite choreographed service, verifying its interaction (mediated by the CI) with the central CtxMg in different scenarios characterized by different execution flows. The components forming the testing tools are the following: • GigaSpace Browser. This is a desktop application included in the GigaSpaces package that, by means of a graphical user interface, it allows to browse and inspect the tuple spaces managed by GigaSpace. This makes the user able to monitoring the global execution state of the choreographed service and the correct interaction of the service with it (in terms of publish and notify operations). • GigaWriter. This is a desktop application that can be used to publish tuples representing synchronization tokens or data items on a GigaS131
CHAPTER 7. PROTOTYPE pace tuples space instance. This can be done manually, by means of a simple user interface or, in batch mode, by using a command file filled with the list of the tokens to be added in the space. In the last case the GigaWriter publishes the tokens stored in the command file, in sequence, with random time intervals. Thanks to this application is possible to simulate the interactions of the other services involved in the choreography with the CtxMg, simulating different scenarios. • CILogFile. The CI creates, during its execution, a detailed log file that reports the activities of the CI and the occurred interactions with the CtxMg and with the service. The different aspects to log can be configured in order to permit the user to focus on different aspects of interest. • SOAPMonitor. The SOAP messages received and sent by the web service are intercepted and traced in a log file by using a SOAP monitor. The integrated use of these tools offers to the user an organized monitoring of the system and makes it possible to verify the correct integration of the service in a test environment. Moreover, the fact that the GigaWriter allows a batch mode use, reading tokens to publish from a command file, makes possible its use with several pre-defined test cases. These test cases can be generated automatically by browsing the choreography graph, and their execution can be automatically simulated with the GigaWriter and checked with the monitoring tools. Examples of use of these tools are presented in Section 8.4 where they are used to test the scenario implemented. 132
7.4. HINT AT SOFTWARE DELIVERY AND CONFIGURATION
7.4 Hint at software delivery and configuration The described software components are delivered as a set of jar libraries that can be loaded on any Java-enabled environments. Specifically: • the Gigapspace server application is distributed in a Community Edition available for free for educational purpose (refers to [44] for details); • the core CI library is packed in a CommunicationInterfaceLib.jar where the classes implementing the kernelCI and the CIProxyIN and CIProxyOUT interfaces are provided; • the implementation of the CIProxyOUTGiga and CIProxyINWS are packed in a GigaWS.jar library; • the testing tools are packaged in a TestingTool.jar library. When these libraries are used to integrate a web service in a choreographed service (managed using the proposed event-based model) some configurations are also needed, as for instance: • the CIProxyOUTGiga needs to know the Gigaspace server address; • the CIProxyINWS needs to knows the address of the service endpoint in order to invoke its messages; • the CIProxyINWS, and in particular the HandlerClient, has to be configured in the service environment and that in general means to fill a simple XML file describing the handler (e.g., class name and package of the class implementing the handler). The features of the XML might depend on the particular application server used. Moreover in 133
CHAPTER 7. PROTOTYPE general for each web service recipient of an outbound SOAP message, a proper handler has to be defined.
134
8 Scenario
In order to test the event-based model presented in this thesis, as well as the prototype presented in Chapter 7, this Chapter analyzes how a given web service can be integrated in an existing choreographed service, solving the protocol mismatches by means of the proposed mediation model. Specifically, given as example a global collaboration model expressed as a choreography, and a service aiming at playing a specific role in the choreography, the integration process presented in Chapter 6 is applied to the example to obtain the CI KB file. Then the choreographed service is ran and tested, using the run time environment and the testing tools provided by the prototype.
8.1 The BookShopping choreography As example of choreographed service the BookShopping choreography represented by the UML Activity Diagram [80] depicted in Figure 8.1 is considered. This choreography specification describes the messages to be exchanged by three web services, playing the roles of a BookStore (BK ), a 135
CHAPTER 8. SCENARIO Supplier (SU ) and a Shipper (SH ), in order to provide a complex service in a BookShopping e-commerce scenario. Looking at the diagram in Figure 8.1 the choreography can be described as follows. The BookStore orders a bookList by interacting with the Supplier (order(id, bookList), orderAnsw(id,avail,total)) and asks the Shipper about the delivery cost, given the addresses of the supplier and of the customer (bkDeliver(id, cost, adS, adC), deliveryInfo(id,cost)). Then, depending on some internal evaluation (e.g., the reception of the payment by the customer), the BookStore confirms, or deletes the order by interacting with its business partners (XOR). • In case of deletion, the BookStore starts a parallel messages exchange (AND) where it asks its partners for the deletion of the order (cancelOrder(id), cancelDelivery(id)) and waits for an acknowledgment message from each of them ackCancel(id), ackCancelDel(id)); then the process terminates. • In case of confirmation, a parallel messages exchange is started (AND) to confirm the order (confirmOrder(id), confirmDelivery(id)); in this case, the Bookstore does not expect any acknowledgments from its partners. Then, when both the Supplier and the Shipper have received the confirmation (after the SYNCH ), the Supplier asks the Shipper for the delivery of the goods, suggesting a date for the appointment on its site (askDelivery(id, data, bookList)). The Shipper responds with a plan for the delivery (sendDeliveryPlan(id, plan)). When the items have been delivered to the customer, the Shipper acknowledges the BookStore (notifyDelivered(id)) and the collaboration ends. 136
8.1. THE BOOKSHOPPING CHOREOGRAPHY
Figure 8.1: BookShopping choreography.
137
CHAPTER 8. SCENARIO
Figure 8.2: NewSupplier (NSU) interaction protocol.
8.2 The web service to integrate We suppose that the NewSupplier web service (henceforth, NSU ) is interested to take part in this choreography, by playing the Supplier role. Figure 8.2 shows the interaction protocol of NSU. It can be noticed that the protocol is a bit different from what is expected within the BookShopping choreography. In particular, the following mismatches hamper the integration of NewSupplier in the composite service: • The signatures of the operations differ in operation name, order and 138
8.3. THE INTEGRATION PROCESS name of arguments (signature mismatch). • In case of order deletion (unreserve(orderId)), NSU does not provide the acknowledgment message occurring in the choreography (missing message mismatch, One-to-Zero). • In case of order confirmation, NSU generates an acknowledgment message (ackConfirm(ordList, price,ordId)) which is not expected in the choreography (extra message mismatch, Zero-to-One). • Instead of the askDelivery(id, data, bookList) message prescribed by the choreography, NSU specifies the delivery request in two different messages: first, it generates message requestDelivery(ordList, ordId); then, it sends the date (when) suggested for the appointment (reqTimeDelivery(when, ordId)) (message split mismatch, One-to-N ). • Finally, NSU waits for a notifyDelivered(ordId) message in order to know whether the items have been delivered to the customer. Notice that, in the choreography, a similar message (notifyDelivered(id)) is exchanged between the BookStore and the Shipper, but it does not involve the Supplier. As described in the following, all the above listed mismatches can be solved using our mediation framework without changing the interaction protocol of NSU.
8.3 The integration process In order to integrate the web service NSU in the BookShopping service, the integration process described in Section 6.1 is applied. The integration 139
CHAPTER 8. SCENARIO
Figure 8.3: Fragment of the CI KB file of NSU. starts from the token based representation of both the choreography and the interaction protocol. The token based representation is obtained by applying the Token Decoration, Token Propagation and Action Definition steps described in Sections 4.1 and 4.2. These steps are quite trivial and are not detailed here; however Figure 8.2 and Figure 8.1 show the tokenbased graphs of the NSU protocol and of the BookShopping choreography. Moreover Figure 8.3 shows a fragment of the starting CI KB file obtained with the application of the Action Definition step. Notice that in the CI KB all the parameters of the send actions are listed in the out fields, without distinction from new or propagated data items. The data items ordList and ordID are propagated and then have to be removed. The five phases of the mapping process are detailed in the following.
8.3.1
Phase 1 - Data mapping
The first step consists in filling out the Data Mapping Table, where the data names used in the local service (NSU in this case) are associated to 140
8.3. THE INTEGRATION PROCESS
Table 8.1: Data Mapping Table of NSU within the BookShopping choreography. BookShopping business data id bookList avail total data plan
NSU business data ordId ordList answer price when deliveryPlan
the names used in the choreographed service (BookShopping in this case). See Table 8.1.
8.3.2
Phase 2 - Message mapping
The Message Mapping Table is generated by mapping the messages in NSU to the ones in the BookShopping choreography; see Table 8.2. Notice that in the table the names of the roles sender and receiver are missing from the message signature and the kind of the mapping is concisely indicated with n-m 1 . The last row of the table is a particular case. In fact it can be considered as a case of extra mismatch (Zero-to-One) since the choreography does not include for the Supplier (the role that NSU aims at playing) a notifyDelivered message. In this case the semantics of the message does not depend on the data items exchanged (id) but on the semantics of the message name. That means that the receiving of the message cannot be simulated (as it was a missing data with a default value in the local protocol) without loosing its meaning in the local business logic. 1
Remember that the names n-m, used to identify the mapping, consider the choreography viewpoint; i.e. n refers to the choreography and m to the local protocol.
141
CHAPTER 8. SCENARIO
Table 8.2: Message Mapping Table of NSU within the BookShopping choreography. BookShopping messages rec(order(id, bookList)) send(orderAnsw(id, avail, total)) rec(cancelOrder(id)) send(ackCancel(id)) rec(confirmOrder(id)) send(askDelivery(id, data, bookList)) rec(sendDeliveryPlan(id, plan)) rec(notifyDelivered(id))
NSU messages rec(book(ordList, ordId)) send(bookResp(answer, price, ordId)) rec(unreserve(ordId)) rec(confirmOrder(ordId)) send(ackConfirm(ordId)) send(requestDelivery(ordList, ordId)) send(reqTimeDelivery(when, ordId)) rec(notifyPlan(deliveryPlan, ordId)) rec(notifyDelivered(ordId))
n-m 1-1 1-1 1-1 1-0 1-1 0-1 1-N 1-1 [-]
However it can also be considered as a One-to-One mapping since the choreography includes a message notifyDelivered that is sent by the Shipper to the BookStore. Therefore this case can be considered as a receive case where a data item is provided by a service different from the one expected in the local protocol, where the data considered is the name of the message. Thus the mapping can be evaluated as easily solvable, as shown in the following (see the last case of the list in Section 8.3.4). Notice that this is an example where the match cannot be solved automatically by a software application, unless some semantic description is added to the messages. In this case the messages involved have the same name (notifyDelivered ), but of course this is not sufficient to automatically determine the correctness of the mapping.
8.3.3
Phase 3 - Token mapping
Then, by applying the rules presented in Section 6.2, the Token Mapping Table is generated. Specifically: 142
8.3. THE INTEGRATION PROCESS
Table 8.3: Token Mapping Table of NSU within the BookShopping choreography. BookShopping global token t2 t3 t10 t18 t21 t24
NSU local token s1 s2 s3 s4 s7 s8
• the 1-1 mapping of rec(order(id, bookList)) generates the map [s1,t2] • the 1-1 mapping of send(orderAnsw(id, avail, total)) generates the map [s2,t3] • the 1-1 mapping of rec(cancelOrder(id)) generates the map [s3,t10] • the 1-1 mapping of rec(confirmOrder(id)) generates the map [s4,t18] • the 1-1 mapping of rec(sendDeliveryPlan(id, plan)) generates the map [s8,t24] • the 1-N mapping of send(askDelivery(id, data, bookList)) generates the map [s7,t21]. The resulting Token Mapping Table is showed in table 8.3 .
8.3.4
Phase 4 - CI KB updating
As described in Section 6.1.4 this phase consists of three steps: the substitution of the local tokens with the associated global ones, the application of the updating rules to synchronize the local protocol to the choreography and the filling of the subscription list. The first step is trivial and is 143
CHAPTER 8. SCENARIO not detailed here, whereas in the following the application of some rules is detailed, considering different mapping cases. • One-to-One mapping. As example is considered the case of the message confirmOrder, mapped to the message with the same name in the choreography. In this case the message has to be synchronized to the choreography and, following the relative rule described in Section 6.2, that means to add in its precondition the choreography token t17 (token generated by the service playing the role BK soon after the sending of the confirmOrder message). • One-to-N mapping. In this case the two local messages requestDelivery and reqTimeDelivery mapping the choreography message askDelivery are in sequence, thus only the first action descriptor requestDelivery has to be updated adding the incoming token in the mapped choreography message (see the rule in Section 6.2). The choreography message is send(askDelivery(id, data, bookList)) and the tokens to be added in the precondition of the local descriptor requestDelivery are t18 and t20. Then the item orderId can be removed from the field out of the action descriptors. This is just a propagated data that is received by the service at its first invocation (order(id, bookList)). • One-to-Zero mapping. In this case the choreography message ackCancel(id) does not have a corresponding message in the local protocol. This is an acknowldgement and can be easily managed defining a new ChorAction descriptor correctly synchronized with the message in the choreography. In particular, it is important that t11, the outgoing token of the choreography message, is generated in order to avoid stopping the choreography execution. The new descriptor is shown 144
8.3. THE INTEGRATION PROCESS in Figure 8.4 (ChorAction Send ackCancel ). Notice that other solutions are possible. For instance in this case the mismatch can be solved without the definition of the new ChorAction descriptor, merely by adding t11 in the postcondition field of the action descriptor of the unreserve(ordId) message. • Special case. The case of the message notifyDelivered can be solved by synchronizing its descriptor to the same message in the choreography, sent to the service playing the SH role. This means adding in its precondition t25. Notice that the difference from a normal One-toOne mapping is that its token in the postcondition is not associated to any global token. This because the message is not present in the choreography and its execution has to be transparent to the global choreography execution context. After the CI KB has been updated, the subscription list is created extracting the data items and the global tokens from the in and pre fields2 . At this point the CI KB is ready for the integration. The outcome of the integration process is the CIKB NSU.xml file, where all the configurations derived from the integration process are expressed in an XML format. In the following is reported a fragment of the CIKB NSU.xml file.
requestDelivery 2 Note that in the resulting CI KB (see Figure 8.4) some optimizations is possible. For instance t3 in the pre field of the receive action confirmOrder is redundant (the presence of t17 assures the availability of t3). That can be an example of an activity on the final CI KB performed by the user. However the overhead generated is negligible and the action descriptor is not modified in this case.
145
CHAPTER 8. SCENARIO
Figure 8.4: Fragment of the CI KB file of NSU.
146
8.3. THE INTEGRATION PROCESS t18falsefalse t20falsefalse s5falsetrue s6falsetrue reqTimeDelivery s6falsetrue when t21falsefalse
This fragment shows how the messages send(requestDelivery(ordList, ordId), SH) and send(reqTimeDelivery(when, ordId), SH) of NSU are mapped to the send(SU, askDelivery(id, data, bookList), SH) choreography message. Notice that, for technical reasons, some different notations are used in the XML representation, with respect to the KB model presented in Section 147
CHAPTER 8. SCENARIO 4.33 . For instance in the XML document the tokens are represented using a field where is declared if it is a local or a global token (tag local ).
8.4 Run time test After the configuration of the CI KB file, the NSU service has to be wrapped with a CI and connected to the Context Management Service (CtxMg). The NSU web service used has been coded in java in the environment provided by the Netbeans IDE and hosted in the Sun Application Server 9 (SAAS)4 . In order to activate the mediation framework, the libraries of the framework (see Section 7.4) have been installed in SAAS, the required configurations have been provided and the SOAP Handlers have been configured to intercept the messages sent by NSU. To this purpose a simple XML file (the handler descriptor, indicating the Java class implementing the handler) has been placed in the correct domain server folder. At execution time, the framework mediates the interaction between Gigaspaces (CtxMg) and NSU in a way transparent to the service, which operates regularly by using SOAP message passing. After the CI of NSU has been correctly configured and connected to the server instance of GigaSpace, the simulation of the choreography execution can start. In order to test the service execution and to inspect the execution state of the service, the testing tools described in Section 7.3 have been used. Following the choreography definition, the execution of the complex 3
These little differences are only due to implementation reasons and do not affect the logic of the model. 4 This is the application server offered by the NetBeans IDE.
148
8.4. RUN TIME TEST service has been tested by simulating with the GigaWriter the actions of the services playing the role BK and SH on the CtxMg (publishing the required data items and synchronization tokens). Moreover the activities of NSU and its CI have been monitored: • with the GigaSpace Browser, checking the occurred notifications and the tokens added in the spaces; • with the CILogFile, analyzing the activities performed by the CI; • with the NSU SOAPMonitor, checking the SOAP messages received and sent by NSU. For instance in the following is analyzed the moment in a choreography instance execution where the order has been confirmed by the BK to the SH and SU (NSU). Specifically NSU has already executed its receive action confirmOrder, and has published t18 on the Choreography Execution Context; also the ackConfirm action has been executed producing the token s5 in its Local Execution Context. The choreography misses the synchronization token t20 to pass the SYNCH node and to enable the execution of the askDelivery message. That means that, in the described situation, as soon as the token t20 is available, the NSU action requestDelivery can be executed (see Figure 8.4). In such a situation t20 is added using the desktop application GigaWriter ; Figure 8.5 shows the window used to the purpose. Notice that in the figure the field CHOR contains the number 133499, the CtxID of the particular choreography instance considered. GigaSpace receives the token and notifies NSU. After some seconds the log file can be checked to see what happened. 149
CHAPTER 8. SCENARIO
Figure 8.5: GigaWriter. In the following some fragments of this file are listed and commented. Notice that the reported log file has been cleaned and cut for space and readability purposes. First, the log file reports the moment when NSU, following its business logic, sends its messages requestDelivery and reqTimeDelivery. It shows that these messages have been intercepted by the HandlerClientWs and that the respective send Actions have not been activated. BusinessLogic.requestDelivery - SEND requestDelivery HandlerClientWs.handleMessage - name:requestDelivery CIProxyINWS_B.interceptedOUTMsg from Handler: requestDelivery LocalContext.checkActivation SendAction (requestDelivery) LocalContext.checkActivation - Actions activated: BusinessLogic.reqTimeDelivery - SEND reqTimeDelivery HandlerClientWs.handleMessage - name:reqTimeDelivery HandlerClientWs.handleMessage - param: when, 16-09-2009
150
8.4. RUN TIME TEST
CIProxyINWS_B.interceptedOUTMsg from Handler: reqTimeDelivery LocalContext.checkActivation SendAction (reqTimeDelivery) LocalContext.checkActivation - Actions activated: -
The action requestDelivery cannot be activated because it misses the token t20 and reqTimeDelivery because it misses the local token s6. This is reported by the Local Execution Context state, printed as an XML string in the log file. This XML contains all the action descriptors of the original KB CI partially filled with the available tokens in that moment. In the following the part of the XML showing the requestDelivery descriptor is reported. The token.flag field set to false in the precondition means that t20 is missing. KernelCommInter.printKB: requestDelivery t18truetrue t20falsefalse s5truetrue s6falsetrue
The next log fragment shows when t20 arrives from GigaSpace. The CIProxyOUTGiga, notified about t20, forwards this information to the Ker151
CHAPTER 8. SCENARIO nel CI component of the Communication Interface (KernelCommInter ) and the Local Execution Context is checked (LocalContext.checkActivation) by inspecting all the action descriptors (see Section 5.3.2). As result the requestDelivery action is enabled and can be executed by the KernelCommInter, producing the local token s6 (KernelCommInter.publishToken). CIProxyOUTGiga.NotifiedTokenReader - >TOKEN [133499,t20] KernelCommInter.getInstance chorID:133499 KernelCommInter.notifyToken - token :t20 KernelCommInter.checkActivation ReceiveAction [t20] LocalContext.checkActivation - Actions activated: LocalContext.checkActivation SendAction [t20] LocalContext.checkActivation - Actions activated: requestDelivery KernelCommInter - SendActionExecution - requestDelivery KernelCommInter.publishToken - local token added:s6
The new local token s6 fires the activation of the reqTimeDelivery action that results in the publishing of two tokens: the data item when (parameter of the SOAP message reqTimeDelivery sent by NSU and previously intercepted by the HandlerClientWS ) mapped on the global data item named date, and the synchronization token t21.
LocalContext.checkActivation SendAction [s6] LocalContext.checkActivation - Actions activated: reqTimeDelivery KernelCommInter - SendActionExecution - reqTimeDelivery KernelCommInter - Mapping data [when, date]
152
8.4. RUN TIME TEST KernelCommInter.publishData: date ProxyOUTGiga.publishData: date16-09-2009 KernelCommInter.publishToken: t21 ProxyOUTGiga.publishToken: t21truefalse
Moreover at any execution moment the application GigaBrowser can be used to inspect the shared tuple space and to have some statistical information on it. Figure 8.6 shows the Statistics panel of GigaBrowser, where the number of notifications sent is represented using an histogram.
153
CHAPTER 8. SCENARIO
Figure 8.6: Giga Browser.
154
9 Evaluation of the mediation framework
The main evaluation of the proposed model is represented by the reference prototype implementation described in Chapter 7 and by the implemented scenario discussed in Chapter 8. This Chapter discusses the evaluation of the proposed model under different perspectives. A first evaluation of the software architecture is given in terms of quality attributes (capability to handle heterogeneous software, scalability and performance). Afterwards, a comparison of the proposed approach and another adaptation approach is provided, with respect to the goal of reducing the integration effort.
9.1 Evaluation of the software architecture This section presents an evaluation of the framework aimed at assessing the high-level features offered in order to support a flexible management of business processes and web service composition. The presented work aims at supporting the integration of heterogeneous software and the management 155
CHAPTER 9. EVALUATION OF THE MEDIATION FRAMEWORK of long-lived, asynchronous services, with minor performance requirements, due to the fact that they automatize lengthy activities, often involving the human user. Therefore, different from other work, such as the research on middleware for Service Oriented Computing (e.g., see [53]), the focus is in not to present numerical performance measures. Several methodologies have been proposed in literature in order to evaluate software architectures. Most of the evaluation techniques [29, 50] proposed to evaluate different quality attributes (such as modifiability, portability, extensibility or quality aspects as performance and scalability) according to specific contextual scenarios. To this purpose, Chapter 8 presents a scenario of use, and shows how the framework deals with it. Taking inspiration of such theories, the remainder of this Section focuses on an assessment of some features offered by the framework, and in particular on its capability to handle heterogeneous software and on its performance and scalability.
9.1.1
Capability to handle heterogeneous software
With respect to the capability to handle heterogeneous software, as described in Chapters 3 and 7, the framework architecture and its prototype reference implementation provide a certain level of flexibility from different perspectives: • the Communication Interface (CI) architecture provides an high level of decoupling between the components of the framework. The ProxyINInterface, devoted to manage the interaction with the web service, allows an easy integration of heterogeneous services based on different languages and technologies. Moreover the ProxyOutInter156
9.1. EVALUATION OF THE SOFTWARE ARCHITECTURE face, devoted to the interaction with the Context Management Service (CtxMg), allows an easy integration with different middleware offering the shared central space and the publish/subscribe service. • The event-based model implemented by the CtxMg offers the possibility to add new components and services (or modify existing one) in a seamless way. Even if the presented framework made some assumptions about the compatibility of data types among the services, they can be easily relaxed. Nothing prevents the insertion, for example, of additional services to the composite service, with the purpose of performing data conversion among different formats (see Section 10.3). These converter services would work only on the Choreography Context and they would be completely transparent to the other services.
9.1.2
Performance and scalability
As far as performance and scalability is concerned, in the following is briefly compared the network traffic generated by the proposed framework to that of a standard composite service. First of all, let’s consider the propagation of business data items and synchronization tokens: • On the one hand, different from standard web service composition, a CI has to retrieve one synchronization token, and to produce one, for each inbound/outbound message of the wrapped web service. However, the token transmission is negligible if compared to the management of complex SOAP messages invoking WSDL operations. • On the other hand, in our framework, the business data is directly propagated to the interested participants as events, and the manage157
CHAPTER 9. EVALUATION OF THE MEDIATION FRAMEWORK ment of SOAP messages is limited to the interaction between the CI and its wrapped web service. This means that, if the CI is installed on the same server hosting the web service, the impact on the network traffic is negligible, while it increases if the CI is a remote web service. However the number of data items propagated as events, compared to the point-to-point propagation of the business data via SOAP messages, is limited: due to the properties of the Publish and Subscribe pattern, each web service avoids sending a single message more than once, regardless of the number of receiver web services. Notice also that, for each inbound/outbound message, the framework propagates only the new and the revised business data, while in standard web service composition all the arguments of a WSDL operation are transmitted. This feature sensibly reduces the amount of information sent by a web service to the other ones. In fact, both the interaction protocols and the choreography specifications often include redundancies in the data propagation aimed at aligning the interaction among the cooperating web services.
As an example of these considerations, the network traffic generated by the BookShopping choreography example described in Chapter 8 is considered. Table 9.1 compares the numbers of data exchanged among the web services BookShopping (BK ), Supplier (SU ) and Shipper (SH ) when they interact in the classical message based way or adopting the event-based model. Notice that in the table, the row labeled with message refers to the message based model, whereas the row labeled with event refers to the event-based execution. Moreover the incoming pieces of information are represented by the suffix in and the outgoing with out. 158
9.1. EVALUATION OF THE SOFTWARE ARCHITECTURE
Table 9.1: Number of exchanged pieces of information. # message event
BKin 5 11
BKout 6 15
SUin 4 11
SUout 3 10
SHin 4 13
SHout 4 10
The values presented in the two rows have a different meaning. In row message they represent SOAP messages sent (out) and received (in), whereas in row 2, event publications (out) and notifications (in), where an event can be a data item or a synchronization token. The impact of these different elements on the global traffic network generated is different. Therefore the same problem is reformulated by Table 9.2, where the values of the table represent a sort of network traffic weight approximated as follow: a synchronization token is an atomic information item with weight 1, a data item is a more complex item with weight 4 and a SOAP message is a more complex data structure with weight 101 . For instance the traffic weight generated by the input of the Supplier (column SUin ) is computed as follows: SU receives 4 messages and then its weight is 40; in the event case SU receives 8 synchronization tokens (weight = 8) and 3 data item (weight= 3*4=12) with total weight 20. In Table 9.2 the last column Global Weight summarizes the total amount of traffic generated by the two approaches2 . 1
This value is obtained using the following coarse grained approximation: a message contains an operation name (weight =1) and a mean of two data (weight=8) and the SOAP infrastructure (weight =1), for a total weight of 10. 2 Note that in row message the Global Weight is not the sum of all the row values, since each message has a sender and a receiver and then its contribute is computed two times in the row (one from the sender perspective and one from the receiver), whereas in row event, each event published or notified involves a piece of information that transits from the service (its CI) and the Context Management Service (thus no weight duplication occurs in the row).
159
CHAPTER 9. EVALUATION OF THE MEDIATION FRAMEWORK
Table 9.2: Weight of exchanged pieces of information. # message event
BKin 50 20
BKout 60 27
SUin 40 20
SUout 30 19
SHin 40 28
SHout 40 16
Global Weight 130 130
In this particular case of the BookShopping example the global weight representing the network traffic generated is the same, indicating that, at least for the choreography with features similar to the one taken as example, the network traffic is not a problem for the proposed execution approach. As far as scalability is concerned, the framework is based on GigaSpaces, which offers immediate advantages because it supports messaging at the level of each participant of the composite service, instead of providing messaging services externally. Specifically, the JavaSpaces [54] paradigm, on which GigaSpaces is based, defines the API and semantics for writing and reading objects from a shared memory service. As the space implementation can be virtualized, it can be comprised out of a set of physical instances that are located in different places on the network but are still viewed and accessed as one logical instance by the application. Since this middleware is virtualized, it can handle scaling events implicitly, i.e., route requests to a different server if one is busy, without any intervention from the application.
9.2 Evaluation of the integration effort One of the goals this thesis tries to achieve is to offer a seamless integration of new services in existing choreographies, overcoming the most common possible mismatches. 160
9.2. EVALUATION OF THE INTEGRATION EFFORT An example of integration is presented in Chapter 8, where the case of a Supplier web service in the BookShopping choreography is discussed. Some general comments can be done, after this experimentation, with respect to the complexity of the proposed approach: • mapping business data and messages is a complex task and requires a certain domain and technical skill. However requiring these mappings as input is the approach followed in many other works in literature (see Chapter 11). Moreover existing or new reliable automatic approaches to this problem can be used to integrate the presented model; • the automatic procedures and the guidelines offered for the configuration of the CI KBs (see Chapter 6) leverage the effort required to the user by providing a significant help; • the verification of the generated CI KB is challenging for the human user, who is required to be familiar with action-based formalisms and rule-based systems. However, the support offered by the provided testing tools (see Section 7.3) represents an important help for this task. However, the final impression is that the generality of the proposed approach balances the presented inconveniences. Furthermore also other approaches to similar problems in literature present the same inconveniences. The approach proposed by Benatallah and colleagues in [12], for instance, requires the message mapping as input and assumes (since it is not specified in the paper) the ability of the user to compose the different BPEL pieces of code generated by the BPEL templates in a final BPEL adapter. Moreover the management of new mismatch cases is not described and thus 161
CHAPTER 9. EVALUATION OF THE MEDIATION FRAMEWORK left to the user responsibility. In order to experiment the advantages offered by the approach presented in this thesis, a discussion derived by the comparison with another adaptation approach is proposed in the remainder of this Section. The reference example used is the BookShopping choreography presented in Chapter 8. The test consisted in considering 10 different communication protocols definition for different services implementing the role of Supplier. For each service two adapters have been created: one by using the presented approach and one by directly coding it using the java language. The protocol mismatches considered in the different cases examined included both basic mismatch patterns (see Section 6.2)(8 cases) and more complex cases (2 cases). The two adaptation approaches used are quite different and the number of case examined limited, therefore instead of using traditional software metrics (see for instance [27]), some considerations are provided in the following, focusing on the effort requested to integrate the different services overcoming the protocol mismatches. In particular the effort required in the different development phases of the adapter implementation is discussed.
• Analysis. Both approaches rely on a preliminary analysis work. If the Mapping Message Table and the Data Mapping Table are mandatory in the approach proposed by this thesis (hereafter defined, for shortly, as new approach), in the case of the java coded adapter (hereafter called classical ) this is not mandatory. However a similar analysis work is required, thus not significant differences have been experienced during this phase. 162
9.2. EVALUATION OF THE INTEGRATION EFFORT • Adaptation Logic Definition. In the classical approach the adaptation logic has to be implemented in source custom code and then the adapter has to be deployed on the hosting server. This is a costly, time consuming and error-prone activity. In the new approach the adaptation logic is expressed in a declarative way by means of the action descriptors; moreover the integration process described in Chapter 6 facilitates its definition. When the mismatch managed is one of the base cases considered in Section 6.2, the definition of the adaptation logic coincides with the definition of the required input mapping tables, elsewhere a more configuration effort is required. • Testing. The testing and debugging phase in the new approach is, at first impact, more complex since different technologies have to be monitored and organized. Some training and a correct use of the testing tool help in this work and make possible a correct monitoring of the situation. In the classical approach the testing is possible using the available tools as SOAP monitors and logging systems.
The Table 9.3 summarizes a quantification of the effort required in the mentioned phases. These values have been elaborated by considering the time spent during the adapter implementation for each different phase activity. Afterward, the values have been scaled by settings the value in the classical case to 10 and changing the value in the new approach column accordingly. Therefore looking at the table is possible to say that, in the tested cases: • the analysis phase for the new approach is about the 30% longer than the same phase in the classical approach; 163
CHAPTER 9. EVALUATION OF THE MEDIATION FRAMEWORK
Table 9.3: Efforts (time) required by the two approaches. # Analysis Adaptation Logic Definition Testing
new approach 13 2 5
classical 10 10 10
• the adaptation logic definition for the new approach takes about the 20% of the time required for the classical approach; • the testing phase for the new approach case takes about the 50% of the time used in the new classical case. In general is possible to say that the new approach is very fast and reliable compared to the classical approach. No new code has to be provided and a more easy and flexible configuration of the adaptation logic is offered. This is particularly true when the protocol differences are the base cases of mismatch patterns considered and solved with associated mapping rules in Section 6.2. In these cases the integration of a service becomes a very easy and fast task. With respect to the human skill required for the integration, both cases consider an expert user with some technical skill. However in the new approach a general technical understanding of the underlying technology model is necessary, but in the classical case a user with specific knowledge on computer programming languages is required.
164
10 Framework Exploitation
The purpose of this Chapter it to outline some exploitations of the framework in contexts different from the one considered in this thesis. This is possible thanks to the flexibility of the framework, due to the event based execution model and to the modularity of the architecture and the reference prototype implementation. Section 10.1 shows how a different configuration of the framework can be used in order to use services as they are, and in particular to realize web service orchestrations. Section 10.2 shows how some parts of the model can be used, with some little changes, in order to set up classical web service adapters without the use of the central coordination space. Then Section 10.3 describes how different approaches of data mediation have been experimented in the framework.
10.1 Using services “as they are” The execution model proposed in this thesis is based on the assumption that each service participating in the choreographed service is wrapped by 165
CHAPTER 10. FRAMEWORK EXPLOITATION
Figure 10.1: Architecture evolution. a Communication Interface (CI) component mediating its interaction with the Context Management Service (CtgMgr) server (see Chapter 3). This is not always possible. There are many situations where web services have to be used as as they are. This happens for instance in those business environments where the interaction, even at the interface and business protocol level, has been standardized either de jure or de facto (e.g. due to the presence of a dominant player in the market). Figure 10.1 shows how the framework can be used to manage this situation. The top part of the figure represents the services W SA and W SB 1 interacting using the framework in the classical way. Hence suppose that W SB is a widely used service (e.g., the Google Map service) that has to 1
The assumption is that W SA and W SB have protocol mismatches that can be solved with the framework.
166
10.1. USING SERVICES “AS THEY ARE” be used as is (the owners of W SB do not allow to wrap it with the CI). The bottom part of Figure 10.1 depicts how this situation can be handled with a different configuration of the framework architecture. In this configuration the CIB is hosted in the logical environment of W SA and interacts with W SB as a web service compatible with its protocol. Notice that the logical architecture of the framework is always the same, only the physical distribution of the components is changed. This architecture configuration can be easily achieved by using the prototype presented in Chapter 7. In fact this is carried out by providing the Communication Interface of W SB (CIB ) with an implementation of the CIProxyIN interface that exposes the WSDL interface expected by W SB and invokes its SOAP messages as requested by its protocol. Figure 10.2 depicts the resulting architecture of the prototype. In this case the CI KB for W SB has to be configured by the people owning W SA .
A further different configuration of the architecture configuration can be used to realize Web Service Orchestrations. Figure 10.3 depicts this scenario considering a web service orchestrator W Sorch that provides a service by orchestrating the services provided by a set of web service suppliers: W Sx and W Sy . The mismatches between the orchestrator and the suppliers can be solved by defining a CI configured for each web service supplier used. With this architecture the service suppliers are exploited in the orchestration without changes in their business logic and without requiring any installation or configuration in their servers. 167
CHAPTER 10. FRAMEWORK EXPLOITATION
Figure 10.2: Prototype.
168
10.2. CLASSICAL WEB SERVICE ADAPTER
Figure 10.3: Web service orchestration.
10.2 Classical web service adapter This Section focuses on the first case considered in Section 10.1: the interaction between two services where a service client adapts to the interaction protocol of a service provider. The idea is to exploit an architecture similar to the one presented in this thesis, adapted to this particular situation, where the central Context Management Service is removed. In fact, since the client carries out all the adaptation work (in a way transparent to the service provider), it is possible to remove the concept of a central shared space and manages all the adaptation process at the Local Execution Context. The resulting architecture is depicted in figure 10.4, obtained by modifying the architecture of the CI component in the prototype design (see Figure 7.1 in Chapter 7). The main new features of the architecture are listed in the following: 169
CHAPTER 10. FRAMEWORK EXPLOITATION
Figure 10.4: WS adapter. • the CIP roxyOU TP rovider carries out the exchange of SOAP messages with the service provider; for the service provider, it plays the role of a service client compatible with its interface2 ; • the KernelCI has to manage two KB files, one storing the action based representation of the service client (CIKBC ) and one of the service provider (CIKBP ); • each instance of the Local Execution Context at runtime stores all the action descriptors describing both the service client and the provider 2
The CIP roxyOU TP rovider becomes an implementation of the CIProxyIN interface that offers the callOp and send methods to the KernelCI and manages the SOAP based interaction with the service provider. Notice that the main difference with the CIP roxyINClient , that manages the interaction with the client, is that the CIP roxyOUP rovider is implemented as a web service, offering the WSDL operations needed to interact with the service provider.
170
10.2. CLASSICAL WEB SERVICE ADAPTER (an instance for each descriptor listed in the KBC and KBP ); • The management of the Local Execution Context (and the action execution) is similar to the one of the original model, with some differences: – the action descriptors have an owner, setting if they refer to the service client or to the service provider; – the execution of a Receive Action delegates the invocation of the associated WSDL operation to the CIP roxiINClient or to the CIP roxyOU TP rovider depending on the owner of the action (client or provider); – the execution of each action descriptor publishes the tokens present in the out and post fields only into the Local Execution Context; Notice that the CI KB files can be obtained with a process similar to the one presented in Chapter 6, where: • The KBP stores the token-based representation of the web service provider, where all its synchronization tokens are defined as global (it plays the role of the choreography since it defines the protocol to follow); • the KBC stores the token-based representation of the web service client synchronized to the provider protocol3 . 3
The updates of the KBC should follow mapping rules similar to ones defined for the choreographed case.
171
CHAPTER 10. FRAMEWORK EXPLOITATION
10.3 Data mediation As mentioned several times in this thesis, the mismatch patterns considered in this work involve signature and protocol mismatches where problems deriving from data heterogeneity are not considered. However is quite obvious to run into conflicts due to data misalignments when integration problems, like the ones examined in this thesis, are managed. The data mediation problem is quite complex and includes aspects related to the meaning of the data (semantic) and aspects related to the structure (format) of the data. The problem of semantic data mediation (called by Becker and colleagues in [11] concept mismatches) is a very complex problem and a lot of works addresses this topic, in the recents years especially in the semantic web community; see for instace [33, 116]. However this topic is out of the scope of this thesis. With respect to the data mediation structural aspects, the problem can be managed by means of data adapter used to restore compatibility between incompatible data items. Data adapters are in general included in web service adapter and manage the mediation problem with different approaches. For instance, Benatallah and colleagues in [12] use XQuery ([112]) transformation functions added to the template adapters they define, in order to manage different data representations, and Dumas and colleagues in [37] use data manipulation functions coded in XSLT [113]. In general the problem of data adaptation from the structural point of view has received considerable attention, leading to a number of transformation definition (e.g. XSLT) and schema mapping tools such as Microsoft BizTalk Mapper [71], Stylus Studio XMLMapping Tools [31], and SAP XI 172
10.3. DATA MEDIATION Mapping Editor [91]. Similar data adapter components can be added to the Communication Interface component and handle the data transformation both in input and output. There are two other possible solutions that can be used exploiting the peculiarities of the framework. First, special purpose rules can be used to handle data mediation. Exploiting the structure of the Action Descriptor used for the action, new DataConverter descriptors can be defined with the following fields: • in, containing the data items in the input format; • op, containing the data transformation function expressed in some language (e.g. XQuery transformation functions or java classes); • out containing the data in the output format. For instance, considering a choreography exchanging the two data items firstname and surname used to represent a person, and a web service using the complex data type name, composed by the fields fname and sname, the following descriptor can be used: in: fname, sname op: packName out: name
where packName represents the function performing the data translation. Swapping the in and out fields the inverse translation function 173
CHAPTER 10. FRAMEWORK EXPLOITATION
Figure 10.5: Data adapter. can be realized. An experimentation of this approach on the trivial example described has been implemented in the prototype, in order to verify its feasibility, by using translation functions defined by means of Java classes4 , with a small change on the kernelCI business logic. Second, is possible to exploit the event-based model offered by the CtxMg and adding specialized data mediator components directly connected to the central space. Figure 10.5 depicts this case. Two data adapter DataAdapterA and DataDapterB are directly connected to the CtxMg and read and publish data on it. For instance, DataAdapterA can read the data items 4
The classes have to implement the java interface DataTranslator defined for this purpose.
174
10.3. DATA MEDIATION f name and sname and publish the data item name. These adapters are specialized to manage one or more data translations and make available to all the interested systems different representation of the same data. However in such a situation is necessary to manage some data naming convention in order to distinguish among the different data representations of the same data item. An experimentation of this approach has been implemented in the prototype, in order to verify its feasibility, by coding custom data adapter components as java application exploiting the Gigaspaces client libraries.
175
11 Related work
The model presented in this thesis extends conversational models, initially defined to support bi-lateral collaboration between web services (e.g., [119, 104]), to the management of many-to-many interactions, i.e., choreographies [86]. In order to carry out such an extension, this thesis focuses on two issues: the solution of interaction protocol mismatches and the coordination of the activities of the cooperating web services. This Chapter shows some of the different proposed approaches in literature managing these issues. Moreover some hints on data mediation approaches and choreography representation languages are provided in Section 11.3.
11.1 Adaptation The issue of synthesizing adapters for incompatible protocols has been studied in the area of SOA, as well as earlier in the area of software component; the adaptation of components is a crucial task in Component-Based Software Engineering (CBSE) ([119, 17, 46, 52]). Many works discuss this topic in literature adopting different approaches and using different formal177
CHAPTER 11. RELATED WORK izations.
11.1.1
Software component adaptation
In [124], Zaremski and Wing analyze the differences between components by adding preconditions and postconditions to the component interface definitions, written as predicates in first-order logic. Thus they rely on theorem proving to determine matches and mismatches. In [23] by Canal and colleagues, CORBA components are extended with behavioral models (described using a formal notation based on π-calculus) to allow for checking compatibility and replaceability of them. A significant work in this research area is the one of Yellin and Strom described in [119], where the authors propose an approach for automatic adapter generation between protocol models of software components. They identify two main types of protocol mismatches: unspecified reception, in which one party sends a message while the other is not expecting it; and deadlock, the case where both parties are mutually waiting to receive some message from the other. In this thesis these cases are treated as mismatch patterns that can be assimilated to missing/extra mismatch and message ordering mismatch (see Section 2.2). In [119] an adapter is modeled as an Finite State Automata consisting of a set of states, a set of memory cells to store the messages received by the adapter, and a set of state transition rules. Each rule describes a state transition in the adapter based on sending or receiving messages, along with a set of memory actions that store or retrieve messages in/from the cells. Rules are also used to construct messages that need to be sent to partners. As in the thesis, to synthesize the adapter specification1 , their interface mappings (which messages should be 1
In the case of [119] for a pair of components.
178
11.1. ADAPTATION mapped to which other messages) is required as input. In general those approaches assume that there are no mismatches at interface level. However, interface and protocol specifications in web services are much richer than component specifications. In addition, web services are typically developed by separate teams possibly in different companies. Thus they are open to heterogeneities and two services are likely to present mismatches at both interface and protocol levels. Moreover, conversely from the mentioned approaches, this thesis is build on a characterization of mismatch patterns and on a set of mapping rules used to overcome them. A similar approach based on a mismatches characterization is presented by Becker and colleagues [11] that introduce a taxonomy of mismatches that enumerates different types of component mismatches, including signature mismatches, protocol mismatches, concept mismatches and technical mismatches. Therefore adaptation patterns are used to solve these mismatches, since they provide generic and systematic solutions to eliminate component mismatches. However in that work, the component mismatches and patterns are presented at an abstract level. The thesis focuses on web service interfaces and protocols, and presents a concrete specification of mismatch patterns and a concrete procedure to solve them.
11.1.2
Web service adaptation
In recent years with the diffusion of web services technologies, that promote the B2B interoperability between applications, the issues related to service adaptation and mediation have deeply interested the SOA research field. A fairly large amount of work [36] in industrial and academic researches has 179
CHAPTER 11. RELATED WORK been carried out to automatize the identification and the resolution of signature and interaction protocol mismatches, in order to develop adapters in a fully or partially automatic way; e.g., [87, 12, 75]. In [87], Ponnekanti and colleagues address structural and value incompatibility; i.e. mismatches that occur in the structure or the values of a XML message sent by the sender and expected by the receiver. They offer tools to analyze the incompatibility between two services written using static host types, where the WSDL specification and XML schema types are mapped to Java classes, and applications are written using these classes. In their proposal the interaction is mediated at runtime by semi-automatically generated middleware components called cross-stubs. Notice that these stubs are generated once the application owner has resolved the relevant incompatibilities2 . That work considers atomic service operations and does not cope with protocol mismatches; moreover it assumes derived services, services with interfaces derived from a common base using a limited number of modification operations. Conversely, this thesis deals with both interface (signature) and protocol mismatches. Moreover, the approach of the thesis is more flexible and does not rely on static host types represented by mapped Java classes, but is based on a declarative description of the adaptation logic expressed by means of actions. As in [87], also in the thesis is considered the human intervention, in order to customize the logic of adapters and manage particular cases. In [75] (Motahari-Nezhad and colleagues), a semi-automated support is proposed to identify and resolve mismatches between service interfaces and protocols, and for generating adapter specifications. However the mediation model of this thesis is more general than that, as it addresses the 2
They also provide the possibility to use custom handler components where customized arbitrary code is used to handle particularly complex incompatibility.
180
11.1. ADAPTATION mediation among several services taking part in a multi-party interaction. As BPEL [77] is the de facto standard for the definition of web service orchestrations, many works consider BPEL as reference language used to define the input and the output of the adaptation task. For instance in [12] BPEL template adapters are used as basic artifacts. Other works consider BPEL as input and output technology of their approaches, but translate it to an intermediate representation; e.g. the work presented in [37] exploits a Finite State Machine representation and [62, 63] a Coloured Petri Net ([51]). A similar approach is followed by Brogi and Popescu in [19], which present an approach for automated generation of BPEL adapters, obtained after an intermediate translation of a BPEL process to a YAWL process (and by the analysis of the Service Execution Trees (SET) of the service). However that work only addresses protocol level mismatches assuming compatible interfaces. The framework presented in this thesis, as described in Chapter 2, is based on a classification of the mismatch patterns and proposes specialized rules to solve them. In particular, the framework deals explicitly with the protocol mismatches described by Benatallah and colleagues in [12]3 . In [12], the design of the adapters is based on mismatch patterns that are used to capture the differences between the communication protocols of a pair of services. These mismatch patterns are both the guideline for the designer in developing adapters, and the input of a tool that automati3
However, unlike [12], this thesis assumes that the data types are compatible, and does not deal with the problem of converting data types by splitting and merging, nor tries to enforce constraints on their value.
181
CHAPTER 11. RELATED WORK cally generates the adapter code. That tool works on BPEL processes and exploits a specific BPEL adapter template for each identified mismatch. However that paper does not detail how these adapters can be composed, in order to deal with more complex mismatches offering a systematic solution to the problem. An evolution of that work is presented in [58] by Kongdenfha and colleagues (among them some of the author of [12]), where an approach based on Aspect-Oriented Programming (AOP) is presented to solve the mismatches identified in [12]. The authors of [58] justify their choice with the consideration that adaptation logic is a cross-cutting concern, which means that from the developer point of view it is transversal to the other functional concerns of the service. The approach is based on the definition of aspect templates that, when instantiated, generate a collection of adaptation aspects that will be woven into the service at runtime. In that sense that solution makes the adaptation model more dynamic and flexible and thus more similar to the approach used in this thesis. Others papers has been inspired by [12] and base their works on the analysis of the proposed mismatch patterns. Marlon Dumas and colleagues in [37] define an algebra over behavioral interface where a set of operators are used to express how to transform an interface to another. Each operator is defined in order to face a particular mismatch pattern4 . The approach of [37] is based on a declarative specification of the adaptation logic (based on algebraic operators) and on a mediation engine able to implement at execution time the adaptation logic. The focus on the declarative description of the adaptation logic and the definition of an engine tool is a point in common with the model proposed in this thesis; i.e., the outcome of the adaptation task is not a final static 4
In [37] an interface mapping between a provided and required interface is represented with a collection of interface transformation expressions.
182
11.1. ADAPTATION artifact embedding the adaptation logic and managing autonomously the interaction with the adapted service, but is a more dynamic artifact with a declarative description of the adaptation logic, executed by a mediation engine. Another work starts from the patterns described in [12] and tries to focus on a more systematic approach in order to deal with more complex mismatch patterns. The work is the one presented in [62] that enhances the model of [12] with five extra mismatch patterns at the interface and protocol level in the context of heterogeneous services composition. In [63] (by Li and colleagues) several basic mediation patterns are defined to reconciling basic mismatches. These basic patterns can be used by developers to modularly construct more powerful mediators and reconcile more complex mismatches. Li and colleagues in [63] assume, as in the thesis, that the low level structures of the data exchanged are consistent and propose a semi-automated procedure in order to generate BPEL pseudo code (by means of BPEL templates associated to mediator patterns). Their procedure is based on a Coloured Petri Net [51] representation of service interaction protocols and on the usage of heuristic selection rules to select the mediator patterns to use. However their approach is semi-automatic in the sense that service developers should specify the message mappings and adjust the selected patterns. Their assumptions are similar to the ones adopted in this thesis. With respect to the number of mismatches considered, this thesis offers an automatic approach to the basic mismatches considered in [12]; moreover Section 6.3 shows how the proposed execution model, based on action descriptors, is able to address many different situations. The work of this thesis extends previous researches on the management 183
CHAPTER 11. RELATED WORK of bi-lateral web service interaction (e.g., see [7, 12, 37, 19]) by supporting the mediation of cross-protocol mismatches among sets of web services. For instance, different from previous approaches, this model abstracts from the identities of the services which generate the business data of a composite application. Thus, it can handle protocol mismatches concerning not only the messages, but also the data flow between the cooperating web services. In recent years the topics discussed so far have drawn the attention of the Semantic Web community [15]. Semantic-based approaches to web services ([14, 21, 61, 69, 70]) propose enriching the web services interface and protocol specifications to describe their semantics, supported by ontologies. This technology should simplify the interoperation between web services and several, often competing, proposals such as OWL-S [107], WSMO [108], and WSDL-S [109] as been proposed. Nevertheless semantic web services do not have currently a wide adoption in the industry (as asserted by Benatallah and Nezhad in [14]). However the use of Semantic Web technologies do not remove the need for adaptation ([21],[70]). An interesting approach is the one of Williams and colleagues [116], that describe a framework for providing a rich service description of web services that enables a more malleable approach to the integration of web services, than the current rigid approach offered by WSDL. The behavioral description is obtained by abstracting the included communicative actions [92] of a protocol and is provided in a format machine readable and interpretable by a mediation component. The main assumption in that work, as well as in other approaches based on semantic web, is that the ontology of the interface description is what needs to be shared between partners rather than prior agreement on a specific interaction protocol5 . 5
When different ontologies are used to describe web service operations and their pa-
184
11.2. COORDINATION AND MEDIATION FRAMEWORKS
The main general difference of this work from the ones presented so far is that this thesis focuses on complex services based on choreography, where several services collaborate. Thus the adaptation problem is not studied with respect to a single service, but with respect to several services; specifically the adaptation problem studied is the one of a web service with respect to a choreography. This allows a more flexible adaptation approach where more that two services are considered.
11.2 Coordination and mediation frameworks In the Semantic Web research, various mediation frameworks have been proposed to manage composite services and to solve data and interaction protocol mismatches among web services. For instance, see [74], the Web Service Modeling Ontology (WSMO [108]) and its reference implementation, the Web Service Execution Environment (WSMX [122, 33, 45]), or the SWWS project [116]. The combination of semantic web with tuple space based middleware has been proposed by the Triple Space Computing [1, 41] initiative aiming at extending tuple spaces by means of tuples in form of RDF [105] triples ([94]). An interesting architecture combining Triple Space and WSMX is the one proposed in [93], where several distributed WSMXs interact through Triple Space technology. While this thesis, differently from these approaches, does not deal with data mismatches, it addresses protocol mismatches in a more flexible way. For instance, there are similarities with SWWS in the attempt to abstract from the flow details of the interaction protocols. However, this thesis rameters, adaptation can need tools for ontology mapping [38].
185
CHAPTER 11. RELATED WORK proposes a lightweight abstraction approach, based on the propagation of business data and synchronization information. Moreover, the approach of this thesis provides a lightweight coordination mechanism supporting the decentralized reconciliation of interaction protocol mismatches, carried out by the CIs (the Communication Interface component used to wrap the service). In contrast, WSMX proposes a centralized solution (e.g., see [28]), where an external choreography management service orchestrates the composite service, representing a possible bottleneck in the coordination of the participant services. A core feature of the collaboration model presented in this thesis is that the activities of the involved web services are synchronized through a shared space where the computational model adopted is based on events. As far as the web service coordination is concerned, the proposed model builds on the previous research on Event Condition Action (ECA) execution models [56, 72, 66] in order to support a context-dependent execution of web service operations. However, thanks to the introduction of the Choreography Execution Context, which is shared by all the participants of the composite service, the work supports the coordination of both orchestrated services (see Section 10.1), corresponding to the workflows handled in ECA models, and choreographed ones (the core focus of the thesis). This generality provides a natural support to the decentralization of services, which has been studied in several projects in order to address the overhead of a centralized coordination based on a complex orchestration logic; e.g., see [25, 125]. Other works in literature propose an unified architecture where Event Drive Architecture (EDA) and Service oriented architecture (SOA) combine in a coherent whole ([68, 114]). For instance the SOEDA architec186
11.2. COORDINATION AND MEDIATION FRAMEWORKS ture presented by Wieland and colleagues in [115] where the advantages of EDA-based systems (i.e. the ability to flexibly react to ad-hoc changes, recognize situations, and the power to handle huge amounts of events and data streams) are integrated to the one of SOA-based systems (i.e. provide standards compliance, interoperability and legacy system integration). In [115] a development method for design workflow based applications based on the SOEDA architecture is presented. Kong and colleagues present in [57] an event-driven approach to business process integration in ubiquitous enterprise environments. The ubiquitous collaborative process described in [57] is based on several distributed workspaces coordinated in a decentralized collaboration network based on event-driven rule processing. The architecture presented adopts the publish/subscribe mechanism based on event notification and relies on eventdriven web service technology as the WS-Eventing proposal [111] and the framework EW-ECA [55] (as well as fundamental standards such as WSDL, SOAP, UDDI). In particular that work presents how an event-driven approach and a reactive rule processing can be applied in order to meet the specific requirements of ubiquitous real time enterprises, based on automatic identification and data capture (ADIC) technologies using radiofrequency identification. Despite the difference with the context analyzed in this thesis, similar properties as the decoupling between applications through event notification is used in this thesis to overcome the communication mismatches among collaborating systems. With respect to the use of technologies as WS-Eventing [111], WS-Events [30] or WS-Notification [48], in this thesis another event-based implementation based on GigaSpaces technology has been selected. However this was a development choice and, thanks to the prototype architecture based on ProxyInterface (see Section 7.2), the above mentioned technologies can be 187
CHAPTER 11. RELATED WORK easily supported in the framework. In particular the brokered version of WS-Eventing, the WS-BrokeredNotification [78], where a central broker is used to dispatch event notifications, considers a model very similar to the one implemented in this thesis and is quite appropriated to be integrated. The central Context Management Service (and its Choreography Execution Context) in this thesis has been implemented by a shared data space where the Communication Interfaces (CI, see 3.1) communicate by exchanging tuples (data items and synchronization tokens). We can say that the Communication Interface (wrapping the service) translates (using the Action Descriptors) the tuples received to web service SOAP messages, both in input and in output (see Section 5.3). An interesting association between SOAP and tuple space is presented by Wutke and colleagues in [118], were tuplespace technology is proposed as an alternative web service transport to have directly on the transport level several benefits as asynchrony, strong decoupling of sender and receiver and support for message exchange patterns, such as one-to-many interactions. Obviously the perspective is different from the use of tuple spaces made in the thesis, however the work presented in [118] highlights some limitations of the message based model in web service technology. In recent years an increasing interest has been shown on the use of classical coordination models on distributed environments (such as Linda [2]) to manage the new scenarios offered by service cmposition. For instance an integration of petri net formalisms and complex peers collaborations based on a Linda (enhanced) coordination framework is proposed and studied in [40] and [4]. That is an interesting view of the coordination problem that is solved in this thesis in a more decoupled perspective, where the tuple space coordination and the web service process (workflow) execution are 188
11.2. COORDINATION AND MEDIATION FRAMEWORKS mediated by the CI. The approach adopted in this thesis is similar to the one proposed by Monsieur and colleagues in [73] and to the business event-based coordination system (BECO) described in [95] and [59], which uses an eventbased coordination paradigm. The interaction in BECO is based on atomic units of interaction called business events, where each business event mirrors some event in the real world that requires the coordination of actions within a number of components. The coordination between components is achieved by having components specify preconditions for business events. In that model events become a sort of contract between participant; i.e. each component can insert its own clauses into the contract by specifying preconditions. With respect to the approach presented in this thesis, BECO proposes a more abstract design model where the concept of business event plays the central role and defines the collaboration between the involved participants. In the thesis view, events are used to relax the conditions that enable the interaction of the web services through the use of the CI. As long as the basic synchronization constraints are observed, in fact, the CI overcomes the problem of sending and receiving data as exactly specified in the WSDL interface. Before concluding this overview is necessary to consider that coordination model based on shared data spaces has been proposed and used in the Multi Agent System (MAS) research field as coordination tools among agents. Many evolutions and enhancement of the original tuple spaces model have been proposed also in recent years, see for instance [82, 81, 67]). Conversely in this thesis only the main basic functionalities offered by the blackboard based coordination model [76] are exploited; i.e. the basic pub189
CHAPTER 11. RELATED WORK lish and subscribe mechanism. However the architecture proposed is quite flexible to support more complex tuple base architectures. Moreover, is necessary to point out that, being event-driven, the proposed model bears some relation to a Complex Event Processing (CEP) architecture; e.g., see [65, 39]. However, this work focuses on the execution of a specific choreography where applications with complex protocols interact with each other, not on the activation of applications in response to the detection of complex events. An approach similar to the one proposed in this thesis is presented by Taher and colleagues in [96], that propose to integrate CEP technology with Service Oriented Architecture in a mediation framework used to adapt message interactions between web services with incompatible interfaces. In that approach exchanged messages are modelled as events and the message adaptation logic is encoded in terms of continuous computation queries (CCQ6 ), that allow the CEP engine to observe message events and detect the predefined adaptation situations. However the approach is presented at abstract level and the definition of the adaptation logic is not specified in the work.
11.3 Hints on related topics In this Section a concise overview on two other related topics is provided. First, some considerations about the data mediation and the proposed automatic mapping approaches is provided, then, an overview about the available choreography languages representation is given. 6 Most of existing CEP platforms provide a continuous computation language for specifying queries each of which defining the schema of an event stream to be monitored, defining event patterns to be detected, specifying processing functions and sequencing, and finally declaring output to be generated [96].
190
11.3. HINTS ON RELATED TOPICS
11.3.1
Data mediation and automatic mapping
As mentioned several times in this thesis, the mismatch patterns considered in this work involve signature and protocol mismatches where problems deriving from data heterogeneity are not considered. That means that the interfaces of the single operations can be different, but the data type involved and their structure are considered shared among services. This simplification is discussed in Section 10.3 where is showed how the generality of the framework supports a seamless introduction of data mediation services aimed at performing data translation within composite services. Another aspect not discussed in this thesis is the automatic mapping of data and interfaces. The presented model relies on data and message mapping tables provided by an analyst. The problem of identifying the actual differences between two service interfaces, as asserted by Benatallah and colleagues in [12] “constitutes a separate research thread in itself, is extremely complex, and unlikely to have practical, applicable solution for years”. In the area of software engineering, there are approaches for automatic identification of mismatches between software components based on their interface and protocol specifications [123, 124, 26]. In general these approaches provide a measure of similarity (or differences) of software components, but do not aim at their adaptation. Similar approaches are used also in web service adaptation. With respect to the data integration aspects of automatic mapping, the problem is the one of schema mapping and semantic-related researches (see [88, 89]); i.e. web service interfaces are expressed in WSDL and thus the problem can be considered as a schema matching problem. The messages mapping in services with complex behavior is more chal191
CHAPTER 11. RELATED WORK lenging and can be considered an open issue. However some interesting approaches are proposed in the literature. For instance Nezhad and colleagues in [75] proposes a semi-automated approach for identifying service mismatches at the interface7 and protocol-level. The approach allows to identify mismatches between service interfaces and protocols, and provides suggestions on how to resolve them whenever possible. Nevertheless, automated approaches for identification of mismatches are error-prone, and the approach proposed in this thesis, based on characterization of mismatch patterns, complements them and helps the adapter developer to identify most of possible differences that are not detected by automated approaches by providing a taxonomy of mismatch patterns and solutions to resolve them.
11.3.2
Choreography representations
With respect to the available languages and representations used, several choreography specification languages have been defined; e.g., Let’s Dance [120, 121], Web Service Choreography Interface (WSCI [9]), Web Services Choreography Description Language (WS-CDL [110]), Chor [126], and business process modeling languages, such as Business Process Modeling Notation [79]. The work carried out in relation to such languages focuses on the design of composite services and on the derivation of the local interaction protocols of the participants. This thesis has a different goal: starting from the interaction protocols and the identification of the protocol mismatches, the proposed mediation framework supports the set up and the execution of the composite service. 7
Built on top of XML schema matching [88, 35] approaches.
192
11.3. HINTS ON RELATED TOPICS The BPEL4Chor proposal [32] introduces a separate specification of control flow dependencies, interaction links and concrete configurations of data formats and port types, in order to support the adaptation of interaction protocols within a choreographed service. However, the control flow within a choreography is defined from the viewpoint of the individual web services participating to the composite service, in the tradition of the WS-BPEL initiative [77]. This means that, although participants can decouple the interaction with their peers, they have to explicitly adapt to each other, and have to update their adaptation logic whenever they have to interact with a new web service (e.g., because a web service is replaced in the composite service). In comparison, the approach proposed in this thesis is more flexible and synthetic, as it enables the web services to adapt to a single, unified view of the composite service, which does not depend on the particular set of web services filling the roles of the choreography.
193
12 Conclusions
This thesis has presented a mediation framework supporting the integration of web services in choreographed services and the conciliation of interaction protocol mismatches among them. The main novelties of the approach can be summarized in the two following points: • The analysis and the solution of the adaptation problem from a choreographed service perspective; i.e., the focus is not on the mediation between two services, but among several web services collaborating in a web service choreography. Therefore the adaptation is studied with respect to the choreography. • A new event-based management of service composition that, together with a new action based execution of web services, allows a more flexible execution of web service choreographies. This is obtained by means of two components: – a Context Management Service which handles the context of the composite service and propagates the relevant business data and 195
CHAPTER 12. CONCLUSIONS synchronization information to the web services participating to the composite service; – a set of knowledge-based adapters (the Communication Interfaces, CIs) which decouple the interaction between web services and run them as autonomous agents operating in contextdependent way. Using these two components is realized a new form of integration between the service oriented computational model and the shared dataspaces event-based model. The collaboration among services is managed by using events, representing data items and synchronization information, that are published and notified to the services, whereas the end-point services continue to work with message passing.
In the proposed model two different approaches coexist. The coordination and communication aspect of the choreography, consisting in the exchange of data items and synchronization tokens, is managed in a centralized way by the publish and subscribe model. This facilitates the management of the problems related to data consistency and synchronization among the services. In contrast, the business logic of the choreography, consisting in the business activities composing the global service, is performed in a distributed way; i.e. each web service manages its activities depending on its business logic exactly as in classical web service choreography executions. This allows to preserve the important features of service choreographies taking advantages of the benefit deriving from the centralized management of the coordination. For instance the global execution state of the choreography, that otherwise is scattered among several peers, can be now observed 196
at central level. Thanks to this new approach on the management of the adaptation problem and to the decoupling of the web service interactions, the framework provides several advantages in the management of choreographed services: • The solution of several interaction protocol mismatches, ranging from differences in the signatures of the messages, to the order and number of the messages to be exchanged, including cross-protocol mismatches involving more than two interacting peers. • The possibilitiy of declaratively solving mismatches at the abstract level, thus overcoming the need to implement a custom adaptation logic. • The use, as starting artifacts, of the most common used representation model of web service protocols and web service choreographies. This fact facilitates the application of the proposed approach at existing cases, offering a shared understanding about the starting problem avoiding the need to introduce totally new representation models. • The reduction of the effort needed to integrate a new web service in a choreographed service. With respect to the solution of the protocol mismatches, a peculiarity of the framework is the management of mismatches concerning the expected senders of messages. For instance, a web service might expect to be invoked by a certain client, but in the choreographed service another web service might actually invoke its operations. In the described approach, the propagation of business data within the Choreography Context hides the identity 197
CHAPTER 12. CONCLUSIONS of the web service which has produced it; therefore, the mismatches involving the source or destination of messages can be ignored. This thesis has also presented: • a set of software components implementing the run time execution environment for choreographed service execution covering both the management of the central shared choreography space (the Context Management Service) and the management of the service side adapters (the Communication Interface); • a set of software tools, procedures and guidelines helping the user in the service integration configuration and testing phases. These tools have been used to implement a use case scenario to verify the general validity of the proposed framework. Although this thesis has focused on choreographed services, the generality of the framework proposed overcomes these boundaries and supports different forms of collaborations not limited to web services. Chapter 10 shows how the model can support the implementation of web service orchestrations and how it can support the integration of different special purpose software components as Data Adapters. Furthermore the proposed architecture and the reference prototype implementation open the framework to the participation of different components based on different technologies and languages. This represents an interesting opportunity for other applications integration scenarios where the collaboration environment offered in this framework (or part of it) can be reused. 198
Moreover this model is suitable also in cases where a web service wants to participate to more than one existing choreographed service (e.g., some public choreographed services [6]). An interesting property of the proposed approach is the management of not implementable choreographies (see Chapter 2). The problem causing the non implementability of a choreography is due to synchronization points defined at global level and not realizable by the local peers collaboration. The explicit representation of these synchronization points (global tokens) in the proposed model forces the satisfaction of these constraints locally (a similar approach is used in [42]). That means that also this kind of choreographies can be implemented with this approach, simplifying and relaxing the definition of the initial choreography. As mentioned several times, the approach presented relies on the support of an expert user in order to provide the data and message mapping table and to overview and check the configuration of the CI KB. This is acceptable, since it can be considered an hazard to rely only on automatic mapping techniques. However an interesting future work can be the integration of one of these techniques in order to propose a initial mapping to the user. Another aspect not managed in this work is the definition of a theoretical environment supporting the proposed model. This should entail the definition of a theory and a set of reasoning tools to demonstrate properties as the correctness of the generated CI KB. The focus in this thesis is on the architecture, the configuration and the execution of the presented model in real environments. A work on the theoretical aspects is a very different work that should be provided in order to justify this approach from a theo199
CHAPTER 12. CONCLUSIONS retical point of view. This is an important future direction for this research. Before concluding is interesting to remark that the presented approach supports flexible management of web service choreography, thanks to the properties of the underlying event based computational model. However a lot of constraints (synchronization tokens) are defined in order to respect the prescriptions of the choreography model, in some way limiting the capability of the new execution model. This because this thesis assumes that the initial choreography defines the exact sequence of operations that has to be respected. However this new computational model opens to different definitions of service collaborations more suitable for the execution model exploited. All these aspects can represent interesting topics of research for the future of this research.
200
Bibliography
[1] Triple space computing. http://tsc.deri.at/, 2005. [2] S. Ahuja, N. Carriero, and D. Gelernter. Linda and friends. IEEE Computer, 19(8):26–34, 1986. [3] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services Concepts, architectures and applications. Springer-Verlag, 2004. ´ [4] Pedro Alvarez, Jos´e A. Ba˜ nares, and Joaquin Ezpeleta. Approaching web service coordination and composition by means of petri nets. the case of the nets-within-nets paradigm. In Boualem Benatallah, Fabio Casati, and Paolo Traverso, editors, ICSOC, volume 3826 of Lecture Notes in Computer Science, pages 185–197. Springer, 2005. [5] Danilo Ardagna, Liliana Ardissono, Stefano Bocconi, Cinzia Cappiello, Marie-Odile Cordier, Philippe Dague, Khalil Drira, Gerhard Friedrich Johann Eder and, Mariagrazia Fugini, Roberto Furnari, Anna Goy, Karim Guennoun, Andreas Hess, Volodymyr Ivanchenko, Xavier Le Guillou, Marek Lehmann, Jrgen Mangler, Yingmin Li, Tarek Melliti, Stefano Modafferi, Enrico Mussi, Yannick Pencol, Giovanna Petrone, Barbara Pernici, Claudia Picardi, Xavier Pucel, Sophie Robin, Laurence Roz, Marino Segnan, Amirreza Tahamtan, Annette Ten Tejie, Daniele Theseider Dupr, Louise TravMassuys, Frank van Harmelen, Thierry Vidal, and Audine Subias. Ws-diamond: Web services-diagnosability, monitoring and diagnosis. At your service. Service-Oriented Computing From an EU Perspective, pages 213–239, 2009. 201
BIBLIOGRAPHY [6] L. Ardissono, R. Furnari, A. Goy, G. Petrone, and M. Segnan. PERCHE: A Public Registry for Choreographies. System and Information Sciences Notes, 1(4):353–358, 2007. [7] L. Ardissono, G. Petrone, and M. Segnan. A conversational approach to the interaction with Web Services. Computational Intelligence, 20(4):693–709, 2004. [8] Liliana Ardissono, Roberto Furnari, Anna Goy, Giovanna Petrone, and Marino Segnan. Monitoring choreographed services. In Innovations and advanced techniques in computer and information sciences and engineering., pages 283–288. Springer, Dordrecht, NL, 2007. [9] A. Arkin, S. Askary, S. Fordin, W. Jekeli, K. Kawaguchi, D. Orchard, S. Pogliani, K. Riemer, S. Struble, P. Takacsi-Nagy, I. Trickovic, and S. Zimek.
Web Service Choreography Interface 1.0.
http://ifr.sap.com/wsci/specification/wsci-specp10.html, 2002. [10] A. Barros, M. Dumas, and P. Oaks. A Critical Overview of the Web Services Choreography Description Language (WS-CDL). BPTrends Newsletter, 3(3):1–24, March 2005. [11] Steffen Becker, Antonio Brogi, Sven Overhage, Er Romanovsky, and Massimo Tivoli. Towards an engineering approach to component adaptation. In Architecting Systems with Trustworthy Components, volume 3938 of LNCS, page 193215. Springer Berlin / Heidelberg, 2006. [12] Boualem Benatallah, Fabio Casati, Daniela Grigori, Hamid R. Motahari Nezhad, and Farouk Toumani. Developing adapters for web services integration. In Oscar Pastor and Joo Falco e Cunha, editors, 202
BIBLIOGRAPHY CAiSE, volume 3520 of Lecture Notes in Computer Science, pages 415–429. Springer, 2005. [13] Boualem Benatallah, Fabio Casati, and Farouk Toumani. Representing, analysing and managing web service protocols. Data Knowl. Eng., 58(3):327–357, 2006. [14] Boualem Benatallah and Hamid R. Motahari Nezhad. Interoperability in semantic web services. In Jorge Cardoso and Amit P. Sheth, editors, SWSWPC, volume 3387 of Lecture Notes in Computer Science, pages 22–25. Springer, 2004. [15] T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web. Scientific American, pages 28–37, 2001. [16] Lucas Bordeaux, Gwen Salan, Daniela Berardi, and Massimo Mecella. When are two web services compatible? In Ming-Chien Shan, Umeshwar Dayal, and Meichun Hsu, editors, TES, volume 3324 of Lecture Notes in Computer Science, pages 15–28. Springer, 2004. [17] Andrea Bracciali, Antonio Brogi, and Carlos Canal. A formal approach to component adaptation. Journal of Systems and Software, 74(1):45–54, 2005. [18] M. Bravetti and G. Zavattaro. Towards a Unifying Theory for Choreography Conformance and Contract Compliance. In Proc. 6th Int. Symposium on Software Composition (SC 2007). Springer, 2007. [19] Antonio Brogi and Razvan Popescu. Automated generation of bpel adapters. In ICSOC, pages 27–39, 2006. 203
BIBLIOGRAPHY [20] Tevfik Bultan, Xiang Fu, and Jianwen Su. Analyzing conversations: Realizability, synchronizability, and verification. In Test and Analysis of Web Services, pages 57–85. 2007. [21] Christoph Bussler, Dieter Fensel, and Alexander Maedche. A conceptual architecture for semantic web enabled web services. SIGMOD Record, 31(4):24–29, 2002. [22] F. Cabrera, worthy, Services
G. Copeland,
D. Orchard, Coordination
T. Freund,
J. Shewchuk,
J. Klein,
D. Lang-
and T. Storey.
(WS-Coordination).
Web
http://www-
106.ibm.com/developerworks/library/ws-coor/, 2002. [23] Carlos Canal, Lidia Fuentes, Ernesto Pimentel, Jos´e M. Troya, and Antonio Vallecillo. Adding roles to corba objects. IEEE Trans. Software Eng., 29(3):242–260, 2003. [24] Marco Carbone, Kohei Honda, and Nobuko Yoshida. Structured communication-centred programming for web services. In ESOP, pages 2–17, 2007. [25] G. Chafle, S. Chandra, V. Mann, and M.G. Nanda. Decentralized orchestration of composite Web Services. In Proc. of 13th Int. World Wide Web Conference (WWW’2004), pages 134–143, New York, 2004. [26] Ping Chen, Matt Critchlow, Akash Garg, Christopher van der Westhuizen, and Andr´e van der Hoek. Differencing and merging within an evolving product line architecture. In Frank van der Linden, editor, PFE, volume 3014 of Lecture Notes in Computer Science, pages 269–281. Springer, 2003. 204
BIBLIOGRAPHY [27] S. R. Chidamber and C. F. Kemerer. A metrics suite for object oriented design. IEEE Trans. Softw. Eng., 20(6):476–493, 1994. [28] Emilia Cimpian and Adrian Mocan. Wsmx process mediation based on choreographies. In Christoph Bussler and Armin Haller, editors, Business Process Management Workshops, volume 3812, pages 130– 143, 2005. [29] Paul Clements, Rick Kazman, and Mark Klein. Evaluating Software Architectures: Methods and Case Studies. Addison-Wesley Professional, January 2002. [30] Hewlett-Packard Company. Web services events (ws-events) version 2.0. http://xml.coverpages.org/WS-Events20030721.pdf, 2003. [31] Stylus ful
xml
Studio
Corporate.
integrated
Stylus
development
studio:
environment
Power(xml
ide).
http://www.sap.com/platform/netweaver/components/xi, 2009. [32] G. Decker, O. Kopp, F. Leymann, and M. Weske. BPEL4Chor: extending BPEL for modeling choreographies. In IEEE Int. Conf. on Web Services (ICWS’07), pages 296–303, Salt Lake City, Utah, 2007. IEEE Computer Society. [33] DERI International. Web Service Modelling eXecution environment. http://www.wsmx.org/, 2008. [34] Remco Dijkman and Marlon Dumas.
Service-oriented design: A
multi-viewpoint approach. International Journal of Cooperative Information Systems, 13(4):337–378, 2004. 205
BIBLIOGRAPHY [35] Hong Hai Do and Erhard Rahm. Coma - a system for flexible combination of schema matching approaches. In VLDB, pages 610–621. Morgan Kaufmann, 2002. [36] Marlon Dumas, Boualem Benatallah, and Hamid R. Motahari Nezhad. Web service protocols: Compatibility and adaptation. IEEE Data Eng. Bull., 31(3):40–44, 2008. [37] Marlon Dumas, Murray Spork, and Kenneth Wang. Adapt or perish: Algebra and visual notation for service interface adaptation. In Business Process Management, pages 65–80, 2006. [38] M. Ehrig and Y. Sure. Ontology mapping - an integrated approach. In In Proceedings of the European Semantic Web symposium (ESWS), pages 76–91, 2005. [39] O. Etzion. Complex event processing. In IEEE Int. Conf. on Web Services (ICWS’04), page 30, San Diego, CA, 2004. IEEE Computer Society. ´ [40] Javier Fabra, Pedro Alvarez, Jos´e A. Ba˜ nares, and Joaquin Ezpeleta. Rlinda: A petri net based implementation of the linda coordination paradigm for web services interactions. In Kurt Bauknecht, Birgit Pr¨oll, and Hannes Werthner, editors, EC-Web, volume 4082 of Lecture Notes in Computer Science, pages 183–192. Springer, 2006. [41] Dieter Fensel. Triple-space computing: Semantic web services based on persistent publication of information.
In Finn Arve Aagesen,
Chutiporn Anutariya, and Vilas Wuwongse, editors, INTELLCOMM, volume 3283 of Lecture Notes in Computer Science, pages 43–53. Springer, 2004. 206
BIBLIOGRAPHY [42] Roberto Furnari. Fungo: An algorithm to implement ws choreogrphy. Communication of SIWN, 4:6–10, 2008. [43] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [44] GIGASPACES. Gigaspacesxap. http://www.gigaspaces.com, 2008. [45] Armin Haller, Emilia Cimpian, Adrian Mocan, Eyal Oren, and Christoph Bussler. Wsmx - a semantic service-oriented architecture. In ICWS, pages 321–328. IEEE Computer Society, 2005. [46] David Hemer. A formal approach to component adaptation and composition. In ACSC ’05: Proceedings of the Twenty-eighth Australasian conference on Computer Science, pages 259–266, Darlinghurst, Australia, Australia, 2005. Australian Computer Society, Inc. [47] Kohei Honda, Nobuko Yoshida, and Marco Carbone. Multiparty asynchronous session types. In POPL, pages 273–284, 2008. [48] IBM,
Akamai
ternational, Globus,
Technologies,
SAP
AG,
Hewlett-Packard,
Software.
Web
Computer
Fujitsu Sonic
services
Associates
Laboratories Software,
notification
In-
of
Europe,
and
TIBCO
(ws-notification).
http://www.ibm.com/developerworks/library/specification/wsnotification/, 2004. [49] IEEE. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. Institute of Electrical and Electronics Engineers, 1990. 207
BIBLIOGRAPHY [50] M.T. Ionita, D.K. Hammer, and H. Obbink. Scenario-based software architecture evaluation methods: An overview. In Proc. of Workshop in Methods and Techniques for Software Architecture Review and Assessment at the International Conference on Software Engineering, Orlando, Florida, USA, 2002. [51] Kurt Jensen. Coloured Petri Nets : Basic Concepts, Analysis Methods and Practical Use. Volume 1 (Monographs in Theoretical Computer Science. An EATCS Series). Springer, April 2003. [52] Wenpin Jiao and Hong Mei. Automating integration of heterogeneous cots components. In Maurizio Morisio, editor, ICSR, volume 4039 of Lecture Notes in Computer Science, pages 29–42. Springer, 2006. [53] J. Jin and K. Nahrstedt.
QoS-aware service management for
component-based distributed applications. ACM Transactions on Internet Technology (TOIT), Special Issue on Service-oriented Computing, 8(3):art. 14, 2008. [54] JINI. Gigaspacesxap. http://www.jini.org/wiki/JavaSpaces Specification, 2006. [55] Jae-Yoon Jung, Jonghun Park, Seung-Kyun Han, and Kangchan Lee. An eca-based framework for decentralized coordination of ubiquitous web services. Information and Software Technology, 49(11-12):1141– 1161, 2007. [56] G. Kappel, S. Rausch-Schott, and W. Retschitzegger. Coordination technology for collaborative applications - organizations, processes, and agents. In W. Conen and G. Neumann, editors, LNCS n. 1364: 1996 ASIAN 1996 Workshop, pages 359–362, London, 1998. 208
BIBLIOGRAPHY [57] Jaehyun Kong, Jae-Yoon Jung, and Jinwoo Park. Event-driven service coordination for business process integration in ubiquitous enterprises. Computers & Industrial Engineering, 57(1):14–26, 2009. [58] Woralak Kongdenfha, Hamid Reza Motahari-Nezhad, Boualem Benatallah, Fabio Casati, and Rgis Saint-Paul. Mismatch patterns and adaptation aspects: A foundation for rapid development of web service adapters. IEEE Transactions on Services Computing, 2(2):94– 107, 2009. [59] Wilfried Lemahieu, Monique Snoeck, Frank Goethals, Manu De Backer, Raf Haesen, Jacques Vandenbulcke, and Guido Dedene. Coordinating cots applications via a business event layer. IEEE Software, 22(4):28–35, 2005. [60] J. Li, H. Zhu, and G. Pu. Conformance Validation between Choreography and Orchestration. In First Join IEE/IFIP Symposium on Theoretical Aspects of Software Engineering (TASE’07). IEE Computer Society, 2007. [61] Ke Li, Kunal Verma, Ranjit Mulye, Reiman Rabbani, John A. Miller, and Amit P. Sheth. Designing semantic web processes: The wsdl-s approach. In Jorge Cardoso and Amit P. Sheth, editors, Semantic Web Services, Processes and Applications, volume 3 of Semantic Web And Beyond Computing for Human Experience, pages 161–193. Springer, 2006. [62] Xitong Li, Yushun Fan, and Feng Jiang. A classification of service composition mismatches to support service mediation. In GCC, pages 315–321, 2007. 209
BIBLIOGRAPHY [63] Xitong Li, Yushun Fan, Jian Wang, Li Wang, and Feng Jiang. A pattern-based approach to development of service mediators for protocol mediation. In WICSA, pages 137–146, 2008. [64] R. Lu and S. Sadiq. A survey of comparative business process modeling approaches. In Proc. of 10th Int. Conf. on Business Information Systems (BIS), LNCS 4439, pages 82–94, Poznan, Poland, 2007. [65] David C. Luckham. The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 2001. [66] D.C. Ma, J.Y.C. Lin, and M. Orlowska. Automatic merging of work items in business process management systems. In Proc. of 10th Int. Conf. on Business Information Systems (BIS’07), pages 14–28, Poznan, Poland, 2007. [67] Marco Mamei and Franco Zambonelli. Programming pervasive and mobile computing applications: The tota approach. ACM Transactions on Software Engineering and Methodology (TOSEM), 18(4):1– 56, 2009. [68] Jean-Louis Mar´echaux. Combining service-oriented architecture and event-driven architecture using an enterprise service bus, 2006. [69] David L. Martin, Mark H. Burstein, Drew V. McDermott, Sheila A. McIlraith, Massimo Paolucci, Katia P. Sycara, Deborah L. McGuinness, Evren Sirin, and Naveen Srinivasan. Bringing semantics to web services with owl-s. In World Wide Web, pages 243–277, 2007. [70] Sheila A. McIlraith and David L. Martin. Bringing semantics to web services. IEEE Intelligent Systems, 18(1):90–93, 2003. 210
BIBLIOGRAPHY [71] Microsoft.
Microsoft
biztalk
mapper.
http://www.microsoft.com/biztalk/en/us/adapter-pack.aspx, 2000. [72] Z. Milosevic, M. Orlowska, and S. Sadiq. Linking contracts, processes and services: an event-driven approach. In Proc. of the IEEE International Conference on Services Computing, pages 390–397, Washington, DC, 2006. [73] G. Monsieur, M. Snoeck, and W. Lemahieu. Coordinated Web Services orchestration. In IEEE Int. Conf. on Web Services (ICWS’07), pages 775–783, Salt Lake City, Utah, 2007. IEEE Computer Society. [74] M. Mrissa, C. Ghedira, D. Benslimane, Z. Maamar, F. Rosenberg, and S. Dustdar. A context-based mediation approach to compose semantic web services. ACM Transaction on Internet Tecnology (TOIT), Special Issue on Semantic Web Services, 8(1):art. 4, 2007. [75] Hamid R. Motahari Nezhad, Boualem Benatallah, Axel Martens, Francisco Curbera, and Fabio Casati. Semi-automated adaptation of service interactions. In Carey L. Williamson, Mary Ellen Zurko, Peter F. Patel-Schneider, and Prashant J. Shenoy, editors, WWW, pages 993–1002. ACM, 2007. [76] H. P. Nii. Blackboard systems. In A. Barr, P. R. Cohen, and E. A. Feigenbaum, editors, The Handbook of Artificial Intelligence (Volume IV), pages 1–82. Addison-Wesley, Reading, MA, 1989. [77] OASIS. cess
OASIS Execution
Web
Language.
Services
Business
Pro-
http://www.oasis-
open.org/committees/documents.php?wg abbrev=wsbpel, 2005. 211
BIBLIOGRAPHY [78] Oasis.
Web
services
brokerednotification).
brokered
notification
1.3
(ws-
http://docs.oasis-open.org/wsn/wsn-
ws brokered notification-1.3-spec-os.pdf, 2006. [79] OMG Object Management Group. Business process modeling notation (BPMN) information. http://www.bpmn.org, 2008. [80] OMG Object Management Group.
Unified Modeling Language
(UML. http://www.uml.org, 2008. [81] Andrea Omicini and Enrico Denti. From tuple spaces to tuple centres. Science of Computer Programming, 41(3):277–294, 2001. [82] Andrea Omicini and Franco Zambonelli. Coordination for internet application development. Autonomous Agents and Multi-Agent Systems, 2(3):251–269, 1999. [83] G.A Papadopoulos and F. Arbab. Coordination models and languages. In Advances in Computers, pages 329–400. Academic Press, 1998. [84] Mike P. Papazoglou, Paolo Traverso, Schahram Dustdar, and Frank Leymann. Service-oriented computing: a research roadmap. International Journal of Cooperative Information Systems (IJCIS), 17(2):223–255, 2008. [85] M.P. Papazoglou and D. Georgakopoulos, editors. Service-Oriented Computing, volume 46. Communications of the ACM, 2003. [86] C. Peltz. Web Services orchestration and choreography. Innovative Technology for Computing Professionals, 36(10):46–52, 2003. 212
BIBLIOGRAPHY [87] Shankar R. Ponnekanti and Armando Fox. Interoperability among independently evolving web services.
In Proceedings of the 5th
ACM/IFIP/USENIX international conference on Middleware, pages 331–351, New York, NY, USA, 2004. Springer-Verlag New York, Inc. [88] Erhard Rahm and Philip A. Bernstein. A survey of approaches to automatic schema matching. VLDB J., 10(4):334–350, 2001. [89] Erhard Rahm, Hong Hai Do, and Sabine Massmann. Matching large xml schemas. SIGMOD Record, 33(4):26–31, 2004. [90] W. Reisig. Petri Nets: an introduction. Springer, 1985. [91] SAP.
Sap
xi
mapping
editor.
http://www.sap.com/platform/netweaver/components/xi, 2009. [92] J. Searle. What is a speech act. Language and Social Context, 1972. [93] M. Omair Shafiq. Triple space computing for semantic web services - a phd roadmap. In Isabel F. Cruz, Stefan Decker, Dean Allemang, Chris Preist, Daniel Schwabe, Peter Mika, Michael Uschold, and Lora Aroyo, editors, International Semantic Web Conference, volume 4273 of Lecture Notes in Computer Science, pages 989–991. Springer, 2006. [94] Omair Shafiq, Ioan Toma, Reto Krummenacher, Thomas Strang, and Dieter Fensel. Using triple space computing for communication and coordination in semantic grid. In Proceedings of the 3rd Semantic Grid Workshop in conjunction with the 16th Global Grid Forum, Athens, Greece, 2006. 213
BIBLIOGRAPHY [95] M. Snoeck, W. Lemahieu, F. Goethals, G. Dedene, and J. Vandenbulcke. Events as atomic contracts for component integration. Data knowledge & knowledge engineering, 51:81–107, 2004. [96] Yehia Taher, Marie-Christine Fauvet, Marlon Dumas, and Djamal Benslimane. Using cep technology to adapt messages exchanged by web services. In WWW, pages 1231–1232, 2008. [97] UDDI Org. Universal Description, Discovery and Integration of Business for the Web. http://www.uddi.org/. [98] W. van der Aalst. 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, pages 1–22, Adelaide, South Australia, 2002. [99] W. van der Aalst, A.H.M. Ter Hofstede, B. Kiepuszewski, and A. Barros. Workflow patterns. Distributed and Parallel Databases, 14(1):5– 51, 2003. [100] W. van der Aalst, A.H.M. Ter Hofstede, B. Kiepuszewski, and A. Barros. Conformance checking of service behavior. ACM Transactions on Internet Technology (TOIT), Special Issue on Service-oriented Computing, 8(3):art. 13, 2008. [101] Wil M. P. van der Aalst and Arthur H. M. ter Hofstede. Yawl: yet another workflow language. Information Systems, 30(4):245–275, 2005. [102] W3C.
Web
Services
http://www.w3.org/TR/wsdl, 2001. 214
Definition
Language.
BIBLIOGRAPHY [103] W3C.
Simple
Object
Access
Protocol
(SOAP)
1.1.
http://www.w3.org/TR/SOAP/, 2002. [104] W3C.
Web
Services
Conversation
Language
(WSCL).
http://www.w3.org/TR/wscl10, 2002. [105] W3C.
Resource
Description
Framework
(RDF)
Primer.
http://www.w3.org/TR/rdf-primer/, 2004. [106] W3C.
Web services glossary.
http://www.w3.org/TR/ws-gloss/,
2004. [107] W3C.
OWL-S:
Semantic
Markup
for
Web
Services.
http://www.w3.org/Submission/OWL-S/, 2005. [108] W3C.
Web
Service
Modeling
Ontology.
http://www.w3.org/Submission/WSMO/, 2005. [109] W3C.
Web
Service
Semantics
-
WSDL-S.
http://www.w3.org/Submission/WSDL-S/, 2005. [110] W3C. Web Services Choreography Description Language version 1.0. http://www.w3.org/TR/ws-cdl-10/, 2005. [111] W3C.
Web
services
eventing
(ws-eventing).
http://www.w3.org/Submission/WS-Eventing/, 2006. [112] W3C.
Xquery
1.0:
An
xml
query
language.
http://www.w3.org/TR/xquery/, 2007. [113] W3C.
Xsl
transformations
(xslt)
version
2.0.
http://www.w3.org/TR/xslt20/, 2007. 215
BIBLIOGRAPHY [114] Mingzhu Wei, Ismail Ari, Jun Li, and Mohamed Dekhil. Receptor: Sensing complex events in data streams for service-oriented architectures, 2007. [115] Matthias Wieland, Daniel Martin, Oliver Kopp, and Frank Leymann. Soeda: A method for specification and implementation of applications on a service-oriented event-driven architecture. In Witold Abramowicz, editor, BIS, volume 21 of Lecture Notes in Business Information Processing, pages 193–204. Springer, 2009. [116] S.K. Williams, S.A. Battle, and J.E. Cuadrado. Protocol mediation for adaptation in semantic Web Services. In LNCS n. 4011: The Semantic Web: Research and Applications, pages 635–6495. Berlin Heidelberg, 2006. [117] Petia Wohed, Wil M. P. van der Aalst, Marlon Dumas, and Arthur H. M. ter Hofstede. Analysis of web services composition languages: The case of bpel4ws. In ER, volume 2813 of LNCS, pages 200–215. Springer, 2003. [118] Daniel Wutke, Daniel Martin, and Frank Leymann. Facilitating complex web service interactions through a tuplespace binding. In Ren´e Meier and Sotirios Terzis, editors, DAIS, volume 5053 of Lecture Notes in Computer Science, pages 275–280, 2008. [119] Daniel M. Yellin and Robert E. Strom. Protocol specifications and component adaptors. ACM Transactions on Programming Languages and Systems (TOPLAS), 19(2):292–333, 1997. [120] J. M. Zaha, M. Dumas, A. ter Hofstede, A. Barros, and G. Decker. Service Interaction Modeling: Bridging Global and Local Views. In 216
BIBLIOGRAPHY Proc. 10th IEEE Int. Conf. on Enterprise Distributed Object Computing (EDOC 2006), pages 45–55. IEEE Computer Society, 2006. [121] J.M. Zaha, M. Dumas, A.H.M. ter Hofstede, A.P. Barros, and G. Decker. Service interaction modeling: Bridging global and local views. In Proc. of 10th IEEE International EDOC Conference (EDOC 2006) “The Enterprise Computing Conference”, pages 45– 55, Hong Kong, China, 2006. [122] M. and
Zaremba, S-K
M.
Moran,
Han.
T.
D13.4v0.3
Haselwanter, WSMX
H-K
Lee,
architecture.
http://www.wsmo.org/TR/d13/d13.4/v0.3/, 2005. [123] Amy Moormann Zaremski and Jeannette M. Wing. Signature matching: A tool for using software libraries. ACM Trans. Softw. Eng. Methodol., 4(2):146–170, 1995. [124] Amy Moormann Zaremski and Jeannette M. Wing. Specification matching of software components. ACM Transactions on Software Engineering and Methodology, 6(4):333–369, 1997. [125] C. Zirpins, W. Lamersdorf, and T. Baier. Flexible coordination of service interaction patterns. In Proc. of 13th Int. World Wide Web Conference (WWW’2004), pages 49 – 56, New York, 2004. [126] Q. Zongyan, Z. Xiangpeng, C. Chao, and Y. Hongli. Towards a Theoretical Foundation of Choreography. In WWW ’07: Proc. 16th Int. Conf. on World Wide Web, pages 973–982. ACM Press, 2007.
217
