Reducing adapter synthesis to controller synthesis - CiteSeerX

1

Reducing adapter synthesis to controller synthesis Christian Gierds, Arjan J. Mooij, and Karsten Wolf Abstract—Service-oriented computing aims to create complex systems by composing less-complex systems, called services. Since services can be developed independently, the integration of services requires an adaptation mechanism for bridging any incompatibilities. Behavioral adapters aim to adjust the communication between some services to be composed in order to establish proper interaction between them. We present a novel approach for specifying such adapters, based on domain-specific transformation rules that reflect the elementary operations that adapters can perform. We also present a novel way to synthesize complex adapters that adhere to these rules, viz., by consistently separating data and control, and by using existing controller-synthesis algorithms. Our approach has been implemented, and we discuss some example applications, including real business processes in WS-BPEL. Index Terms—Services Composition, Web Services Interoperability, Service Integration

F

1

I NTRODUCTION

Service-oriented computing [1] advocates the creation of complex systems by composing less-complex systems, called services. Services have an external interface that can be described by a signature (names of the communication channels) and a behavioral model (describing the orders in which messages are expected and provided). From the beginning it has been clear that the integration of independently-developed services requires a way to bridge incompatibilities (e.g., format, semantics, behavior, non-functional) between the services to be composed. Behavioral adaptation aims to adjust the communication between some given services such that a certain behavioral property (e.g., deadlock-freedom, or weak termination) holds in the composed system. To this end, an additional service is introduced that acts on the messages communicated by the given services. Such a service is typically called mediator, glue logic, or adapter; we shall use the latter term. We present a novel approach for specifying such adapters based on domain-specific transformation rules. We also present a novel way to synthesize adapters that adhere to these rules, viz., by consistently separating data and control, and by using existing controller• C. Gierds is with the Institut fur ¨ Informatik, Humboldt-Universit¨at zu Berlin, Germany. His work is supported by the German Research Foundation (DFG) under grants RE 834/18-1 and WO 1466/11-1. E-mail: [email protected] • A.J. Mooij is with the Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Netherlands. His work is part of the Poseidon project at Thales under the responsibilities of the Embedded Systems Institute (ESI). This project is partially supported by the Dutch Ministry of Economic Affairs under the BSIK program. E-mail: [email protected] • K. Wolf is with the Institut fur ¨ Informatik, Universit¨at Rostock, Germany. His work is supported by the German Research Foundation (DFG) under grants RE 834/18-1 and WO 1466/11-1. E-mail: [email protected]

synthesis algorithms. Moreover, we show that this approach can be implemented efficiently. Running Example Before further explaining our approach, we introduce and discuss a running example. At a conceptual level our approach is independent of a specific formalism, but for the examples and implementations we use the open Petri nets formalism. The running example is related to beverage vending machines. The vending machine modeled in Figure 1(a) expects a Euro coin (MEuro), expects the choice for coffee or tea (MCoffeeButton or MTeaButton, respectively) and finally serves coffee or tea (MServedCoffee or MServedTea) accordingly. On the other side, the coffee drinker modeled in Figure 1(c) provides a Euro (DEuro) and just waits for his coffee (DServedCoffee). This example is compact and, as we will see, also interesting. Services can be composed using an operator ⊕ that fuses the pairs of interface channels with equal names. To enable adapters to intercept all messages, the interfaces of the given services are assumed to be disjoint; see pairs of related channels like MEuro and DEuro. When directly composing the two given services, it is a problem that the names of the channels differ. Moreover, if we ignore this problem, the composed system would contain a deadlock as no button is used. Figure 1(b) contains an example adapter that solves these issues: one DEuro is converted in a MEuro, one MCoffeeButton is generated, and one MServedCoffee is converted in a DServedCoffee. Exploration This analysis indicates a requirement on the adapter, viz., it must establish a certain behavioral property B (e.g., deadlock-freedom) in the composed system. This requirement suggests a reduction to controller synthesis, for which many implementations are available.

2

MEuro

MEuro

MTeaButton

MTeaButton MCoffeeButton

MServedTea MServedCoffee

DEuro

DEuro

MCoffeeButton

MServedTea

DServedCoffee

DServedCoffee

MServedCoffee ω

ω

(a) Vending machine

(b) Adapter

(c) Coffee drinker

Fig. 1. Running example: beverage vending machine

For any behavioral property B, a B-controller for a service S is a service C such that the composition S ⊕ C has property B. Similarly, a B-adapter for two given services S1 and S2 is at least a B-controller for the service S1 ⊕ S2 obtained by (disjoint) composition of S1 and S2 . Despite the simplicity of this criterion, it admits the adapter from Figure 2, which transforms DEuro into DServedCoffee independently of the interaction with the vending machine. For many services and properties B, there exists such a strange adapter that is the (disjoint) composition of two services A1 and A2 such that S1 ⊕A1 and S2 ⊕ A2 establish property B independently. So, apart from the requirement on the composed system, a requirement on the internals of the adapter is needed such that the adapter can actually be implemented. Proposed Approach To indicate what is implementable in an adapter, we propose a specification of the elementary activities (SEA). Such an SEA describes (from a semantical perspective) the elementary building blocks for the adapter. An SEA consists of transformation rules in terms of the message types, and describes which message types can be created, deleted and transformed. Thus our adapter specifications consist of three parts: • behavioral models of the given services; • behavioral property on the composed system; • specification of the elementary activities. To synthesize an adapter that obeys an SEA, we propose a two-piece adapter structure that consistently MEuro

MTeaButton

separates data and control. The first piece is an engine service E that models the elementary activities from the SEA; the second piece is a controller service C that controls the execution of activities in the engine. The interface of the engine includes (the complement of) the interfaces of the given services S1 , . . . , Sn . In addition there is an interface between the engine and the controller. This structure is sketched in Figure 3. To synthesize for some given services S1 , . . . , Sn a B-adapter that obeys a given SEA, we first transform the SEA into an engine E. Afterwards we compute a controller C as any B-controller for (S1 ⊕ · · · ⊕ Sn ) ⊕ E. The final adapter service A is obtained by composing services E and C, i.e., A = E ⊕ C. Thus we reduce adapter synthesis (even with SEA restrictions) to controller synthesis, and hence enable the re-use of existing technology. Conceptually our approach is independent from the property B, and the modeling formalism. So, once controller synthesis for a property and a formalism is solved, and the SEA can be translated to an engine, adapter synthesis can be reduced to controller synthesis. We have implemented this approach such that an adapter can be synthesized automatically given an adapter specification. Even on real business processes, our approach turns out to perform good. Overview In Section 2, we introduce the open Petri nets formalism. In Section 3, we present our language for specifying the elementary adapter activities. In Section 4, we describe the synthesis of the adapter, and in particular, the engine that is responsible for executing the specified elementary

DEuro

C

MCoffeeButton

MServedTea

E

DServedCoffee

MServedCoffee

Fig. 2. Running example: another adapter?

S1

…

Si

…

Sn

Fig. 3. General structure of our adaptation approach

3

activities. This approach is implemented and applied to some examples as described in Section 5. Finally, in Section 6 we discuss related work, and in Section 7 we draw some conclusions and discuss future work.

2

P RELIMINARIES

At a conceptual level our approach is independent of a specific formalism, but for the examples and implementations we use the open Petri nets formalism. 2.1 Open Petri Nets Petri net models are appropriate for services given the strong links with real service description languages. There exist feature-complete translations [2], [3], [4], [5] from languages like WS-BPEL to Petri nets, as well as translations [6] from Petri nets to WS-BPEL. Another motivation is an existing tool that we shall use. More specifically, we use an extension of Petri nets that is called open nets [7], [8]. To model asynchronous communication with an environment, open nets have an interface that consists of input places and output places. To model successful completion of a service instance, open nets have a set of final markings. Definition 1 (Open net): An open net N consists of two finite and disjoint sets P (of places) and T (of transitions); • two disjoint subsets Pi (of input places) and Po (of output places) of P ; • a flow relation F such that F ⊆ ((P \ Po ) × T ) ∪ (T × (P \ Pi )); • an initial marking m0 such that m0 .p = 0 for all p ∈ Pi ∪ Po ; • a set Ω of final markings such that no final marking enables any transition in T , and such that m.p = 0 for all m ∈ Ω and for all p ∈ Pi ∪ Po . •

Note that we use ‘.’ to denote function application. Given an open net N , an arc is an element of F , and a marking is a mapping from P to the naturals. For any marking m, it is said that there are m.p tokens in each place p. We use 0 to denote the marking that is zero in every place. The graphical representation (see Figure 1) uses circles for places, squares for transitions, and arrows for arcs. The interface places are depicted on the dashed border, and the places with a token in the initial marking are marked by a black dot. The final markings are typically omitted, or marked suggestively with an ω. Open nets can be used for adapter synthesis, but for some of our results we also need synchronous communication. To this end, we extend open Petri nets with an interface that consists of synchronous ports (represented by small black boxes; see Figure 4(a)). As in [9], we introduce a total labeling function L, which assigns to every transition a label that denotes the synchronous port (if any) it is connected to. If a transition is not connected to any synchronous port (like in traditional open nets), it is assigned the auxiliary label τ .

2.2

Composition

Services are made to be composed with other services. A complete service choreography corresponds to a closed net, which is a net without asynchronous interface places (i.e., Pi ∪Po = ∅) and without synchronous interface ports (i.e., (∀t : t ∈ T : L.t = τ )). Traditional open nets (without synchronous ports) can be composed by fusing pairs of corresponding interface places that are an input place of one net and an output place of the other, resulting in internal places (as is sketched in Figure 6). Two nets are composable if and only if their shared interface places are of this kind; regarding our running example, each pair of nets in Figure 1 is composable. Open nets with synchronous ports can be composed by also fusing each pair of transitions from the two nets with identical non-τ labels, resulting in internal τ -transitions. Place fusion replaces two places by a single place with all the incoming and outgoing arcs of the two original places. Similarly, transition fusion replaces two transitions by a single transition with all the incoming and outgoing arcs of the two original transitions. Without loss of generality, we assume that all constituents except the interfaces of the nets to be composed are disjoint, which can be achieved by renaming the internal (i.e., non-interface) places and transitions. Definition 2 (Composition): Let N1 and N2 be open nets. N1 and N2 are composable iff Pi1 ∩ Pi2 = ∅ and Po1 ∩ Po2 = ∅. If N1 and N2 are composable, their composition N = N1 ⊕ N2 is defined by P = P1 ∪ P2 ; Pi = (Pi1 ∪ Pi2 ) \ (Po1 ∪ Po2 ); Po = (Po1 ∪ Po2 ) \ (Pi1 ∪ Pi2 ); m0 = m01 ⊕ m02 ; Ω = {m1 ⊕ m2 | m1 , m2 : m1 ∈ Ω1 ∧ m2 ∈ Ω2 }; T = Tf ∪ Ts ; Tf = {t | t : t ∈ T1 ∧ (L1 .t = τ ∨ (∀t0 : t0 ∈ T2 : L1 .t 6= L2 .t0 ))} ∪ {t | t : t ∈ T2 ∧ (L2 .t = τ ∨ (∀t0 : t0 ∈ T1 : L2 .t 6= L1 .t0 ))}; Ts = {{t1 , t2 } | t1 , t2 : t1 ∈ T1 ∧ t2 ∈ T2 ∧ L1 .t1 = L2 .t2 ∧ L1 .t1 6= τ }; L = {[t, (L1 ∪ L2 ).t] | t : t ∈ Tf } ∪ {[{t1 , t2 }, τ ] | t1 , t2 : {t1 , t2 } ∈ Ts }; F = ((F1 ∪ F2 ) ∩ ((P ∪ Tf ) × (P ∪ Tf ))) ∪ {[p, {t1 , t2 }] | p, t1 , t2 : {t1 , t2 } ∈ Ts ∧ ([p, t1 ] ∈ F1 ∨ [p, t2 ] ∈ F2 )} ∪ {[{t1 , t2 }, p] | p, t1 , t2 : {t1 , t2 } ∈ Ts ∧ ([t1 , p] ∈ F1 ∨ [t2 , p] ∈ F2 )}. The transitions are partitioned into the set Ts of transitions that synchronized on a port, and the set Tf of transitions that did not synchronize. For markings m1 of N1 and m2 of N2 , the marking m1 ⊕ m2 is defined as (m1 ⊕m2 ).p = m1 .p for p ∈ P1 and (m1 ⊕m2 ).p = m2 .p for p ∈ P2 . Places p ∈ P1 ∩P2 give no conflict in the definition as these are interface places, and hence m1 .p = m2 .p in

4

the initial and final markings. If no three services share an interface (place or port), composition is associative. 2.3 Semantics The semantics of a closed net is defined as follows. A transition t is enabled in marking m iff m.p > 0 for all places p such that (p, t) ∈ F . A marking m0 is reachable from marking m iff there exists a sequence of firings from m to m0 . Firing an enabled transition t in marking m leads to the marking m0 such that m0 .p = m.p − W.[p, t] + W.[t, p] for all places p, where W.[x, y] = 1 if [x, y] ∈ F and W.[x, y] = 0 otherwise. The data in the tokens (if any) do not influence the control flow (i.e., firing of transitions). That is, we consider nets with black tokens, which is enough to discuss behavioral adaptation. Non-deterministic choice can be used to model a data dependency in a real service. As real services manipulate the data in the tokens, at several places we discuss how this can be included. A closed net is k-bounded if, in every reachable marking, each place contains at most k tokens. The number of reachable markings of a closed net is finite if the net is k-bounded for any k. Notice that bounded nets can contain iteration. Definition 3 (Behavioral properties): Any marking m of a closed net is a deadlock if m ∈ / Ω and no transition is enabled in m. Any closed net is deadlock-free iff no deadlock markings are reachable from m0 . Any closed net is weakly terminating iff for every marking m that is reachable from m0 , a marking in Ω is reachable from m. To define similar properties for open nets, we use the notion of controllability. A net is B-controllable if it can be composed with another net (a controller) such that the result is a closed net with behavioral property B. Definition 4 (Controllability): For any behavioral property B, open net N is B-controllable iff there exists a composable open net N 0 such that N ⊕ N 0 is a closed net with property B. Such a N 0 is a B-controller of N . As the composition of the three nets in Figure 1 is deadlock-free, the composition of each subset of these services is deadlock-free controllable. Two open nets are B-accordance equivalent if they have equal sets of B-controllers; informally, this means that their useable interface behavior is indistinguishable. There exist algorithms for deciding controllability with respect to deadlock freedom or weak termination [10], [11], [12], [13]. These algorithms rely on the synthesis of a witness controller net N 0 ; tools like F IONA [5], W ENDY [14] or W OMBAT 4WS [15] provide efficient implementations. More precisely, the algorithms construct transition systems that represent the behavior of N 0 . This is, however, not a significant difference as there is a mature theory for the transformation of transition systems to Petri nets [16] which is supported by tools like P ETRIFY [17] and G ENET [18].

3

E LEMENTARY ACTIVITIES

In this section we focus on the capabilities of an adapter, and we propose to specify them using SEA rules. 3.1

Adapter Capabilities

As the given services have an asynchronous communication interface, the basic capabilities of an adapter are receiving a message from a channel, and sending a message to a channel. As these are separate tasks, it is also possible to delay the forwarding of messages. We assume these capabilities for each channel. For the few cases in which this is too general, Section 4.6.2 describes a way to restrict these for some of the channels. Internally, the capabilities of an adapter include ways to transform messages; thus reflecting semantic dependencies between certain message types. Most of the approaches, including [19], [20], [21], [22], [23], [24], agree that the capabilities of an adapter should include the following activities: • Create “Can an adapter arbitrarily generate a message?” This is possible for basic control messages, such as simple acknowledgments, and for messages with a clear default value. However, it is typically impossible for messages containing important data such as passwords, personal data of a user, etc. • Copy “Can an adapter deliver a message multiple times?” This is possible for many electronic messages, but it can be inappropriate for single-use data such as transaction numbers or single-access passwords. In our running example it is also inappropriate for messages that represent real goods, e.g., money, or a beverage. • Delete “Can an adapter delete a message?” This is possible for many electronic messages (except legal messages like invoices, cancelation notices etc.), while it is inappropriate for real goods in our running example. • Transform “Can an adapter transform the content of some messages into the content of some other messages?” They can do so if the underlying transformation routine is provided, e.g., calculating a metric measure from an imperial one, or deriving a city name from a zip code. The transformation routine may be a call to another, stateless, service. • Split “Can an adapter distribute the content of a received message to several outbound messages?” This depends on the semantics of the message types. • Merge “Can an adapter integrate the contents of various received messages to form the content of an outbound message?” Again, this depends on the semantics of message types. • Reroute “Can an adapter send a message to another recipient than specified?” This can be done if the new recipient accepts the same semantical entity as the original recipient. For each activity we have sketched examples in which they may or may not be applicable. So, the applicability

5

TABLE 1 Examples of elementary activities in terms of transformation rules Elementary activity

Possible transformation rule

Create a Copy a Delete a Transform a, b, c into d, e Split a into b, c, d Merge a, b, c into d Reroute a to recipient j instead of recipient i

7→ a a 7→ a, a a 7→ a, b, c 7→ d, e or a, b, c 7→ a, b, c, d, e a 7→ b, c, d or a 7→ a, b, c, d a, b, c 7→ d or a, b, c 7→ a, b, c, d ai 7→ aj

TABLE 2 Running example: SEA

of an activity to a particular message type depends on semantic considerations, and hence the capabilities of the adapter must be specified per message type.

DEuro

3.2

Transformation Rules MServedCoffee

We specify the capabilities of an adapter using a Specification of the Elementary Activities (SEA). Definition 5 (SEA): Given a set of message types M , an SEA is a set of transformation rules on these message types. Each transformation rule has the shape Z

X 7→ Y where X and Y are finite, possibly-empty, bags (multi sets) over the set M , and where Z is a total function. The set M contains at least the names of the interface channels of the given services, but it may also contain auxiliary message types. Each rule denotes that, using the transformation Z (e.g., in terms of XSL or WS-BPEL code), a message of each type in X is consumed, and a message of each type in Y is produced. The SEA does not admit that the contents of the input messages determine the applicability of a rule or the types of the output messages of the rule. After receiving some messages, the adapter can apply several transformations to the available messages before sending any messages. Synthesizing an adapter boils down to applying the SEA rules in a right order, and sending messages to the interface at a right moment. Table 1 contains examples of how activities can be expressed in terms of transformation rules (apart from any transformation Z). For some rules, we give two versions, depending on whether the inputs remain available after application of the rule. To model the reroute rule, we use ai and aj to denote the message type a addressed to recipient i and j respectively. Some more-complicated patterns require multiple rules: a typical “collapse” pattern, where an arbitrary series of a messages has to be merged into one message b, could be modeled using the two rules 7→ b (create an empty ‘b’) and a, b 7→ b (add a single ‘a’ to an existing ‘b’). There is no need to encode a termination

7→ 7 → 7 → 7 →

MEuro MCoffeeButton MTeaButton DServedCoffee

condition (i.e., how to conclude that all a messages have been received) in the transformation rules. Additional examples are discussed in Section 5.3. By focusing on elementary activities, the SEA typically remains simple. As the SEA is independent from the details of the given services, it can be seen as domain knowledge that can be reused for several adapters. In this article we focus on using a given SEA. There are several ways to get one. First, if a particular set of services is composed, the rules may be simple enough to be specified manually. Second, if the interfaces of the services are specified using technologies of semantic web or ontologies, this information could be analyzed to create an SEA automatically. Third, in an intra-organizational environment, there could be strict rules for message names and types from which an SEA can be deduced. These, and related techniques such as semantic mapping [25], are research areas on their own. In particular [23] presents an interactive approach to find and refine SEAlike specifications for adapters using mismatch trees, and [26] aims for an automated approach based on heuristics and expert systems. Further exploring these techniques is beyond the scope of this article, but there are enough opportunities to justify the use of an SEA. Running Example The messages for euro and coffee can simply be transformed. However, the creation or deletion of euro, coffee, or tea should not be permitted, as these messages represent real goods. Pressing a button is feasible for the adapter, and hence the corresponding messages can be created. A possible SEA is given in Table 2.

4

A DAPTER S YNTHESIS

Our adapter specifications consist of (behavioral models of) the given services, a behavioral property, and an

6

SEA. We assume that the interfaces of the given services are disjoint, which can be achieved by renaming. For simplicity of presentation, we assume that for each SEA rule, the bags before and after the 7→ are sets; the general case follows analogously using Petri nets with arc multiplicities. An adapter is a service such that the net that results after composition with the given services is closed and satisfies the behavioral property. Furthermore, to ensure implementability, an adapter may only be constructed from the elementary activities described by the SEA. In this section we first give a semantics for the SEA rules in terms of the services that obey these rules. Afterwards we introduce some more structure in these services, which, in turn, is exploited to synthesize adapters that establish the behavioral property. Finally we discuss some extensions of the approach. 4.1

Building Blocks for SEA-based Services

In this section we describe the services that obey a given SEA by showing how they can be constructed. The SEA only imposes restrictions on the inner of the service, so the service can have any (asynchronous) interface. In the case of adapters, the required interface follows from the given services. To describe the restrictions on the inner of the service, we distinguish between two kinds of places: message places and control places. Each message place (like each interface place) is related to exactly one message type, but several message places may exist for a single type. In the initial and final markings, the message places (like the interface places) are empty. In contrast to the message and interface places, the control places can be freely connected to transitions. We distinguish between four kinds of transitions, with the following restrictions on their connections with the message and interface places: • SEA transition: arcs to and from message places as specified by one SEA rule; • input transition: one arc from an input interface place and one arc to a corresponding message place; • output transition: one arc to an output interface place and one arc from a corresponding message place; • control transition: no arcs to or from any interface or message places. Strictly speaking, the example adapters from Figure 1(b) and Figure 6 are no SEA-based services. However, they are the result of simplifying (fusion of series places [27]) an SEA-based service that is accordance equivalent to them. As the contents of the messages cannot influence the control flow in our models, any message of a certain type is as good as any other message of the same type. As each place can contain any number of messages, we assume that there is exactly one message place for each message type. If, for some reason, two messages of a

single type need to be distinguished, then the message type itself should be refined by two new message types, and also a more fine-grained model of the services and the SEA should be provided. 4.2 Data and Control in SEA-based Services The described SEA-based services have a monolithic structure, which turns out to be unnecessarily complex for adapter synthesis. To this end we separate the message places and the control places in two services that share a dedicated interface. Conceptually the easiest way to do so is using a synchronous interface, but in Section 4.4 we translate it to an asynchronous interface. Synchronous communication is essentially transition fusion. So, given any SEA-based service, we can split every transition into two transitions: the first transition only deals with message and interface places, while the second transition only deals with control places. The idea is to put these two transitions in separate services, and connect each such pair of transitions through a dedicated synchronous interface port. For simplicity reasons, the control transitions are not split, but directly moved to the second service. In this way, the first service only contains SEA, input and output transitions, which, in addition, are connected to a dedicated synchronous port. The control flow of the SEA-based service is largely dictated by the second service. Notice that the first service is almost a generic service, given the SEA rules and the required asynchronous interface. However, it may contain several transitions that only differ in their synchronous port, while some other transitions may not occur at all. This issue can easily be solved: any duplicate transition (and its corresponding interface port) can be removed after changing some transition labels in the second service. Moreover, any missing transition can be added by introducing a fresh interface port that is not used in the second service. Thus we obtain a generic service (like Figure 4(a)) that is solely based on the interfaces of the given services and the SEA. We call this service an engine E. The remaining control-flow of the original SEA-based service is isolated in a separate service, which we call a controller C. The engine is a skeleton service implementation, that guarantees that the full service obeys the SEA. In turn, the controller schedules the execution of the transitions in the engine. In Section 4.4 we give formal definitions of some engines. By construction, each SEA-based service can be split into the engine and a controller. Moreover, the composition of the engine with any controller gives an SEAbased service. Thus we have reduced the construction of an SEA-based service, to the construction of a controller service that only communicates with the engine. 4.3 Controllers for SEA-based Adapters We have seen how to synthesize an SEA-based service. What remains in order to synthesize an SEA-based B-

7

4.4

Formal Definition of Two Equivalent Engines

In this section we formalize two engines, including the one from Section 4.2. The interface between the engine and the controller as described in Section 4.2 is synchronous, and hence we would need an algorithm for synchronous controller synthesis. However, in the context of open Petri nets asynchronous communication (just interface places) is more natural and better developed. It turns out [9] that the interface between the engine and the controller can be replaced by an asynchronous one, without changing the services that can be synthesized (up to accordance equivalence). 4.4.1

Common

We first describe the commonalities of these two engines. Let I and O denote the (disjoint) union of the input and output places, respectively, of the given services. Let K be a set such that the SEA consists of rules Xk 7→ Yk , where Xk and Yk are bags, for any k ∈ K. Let M be a set of message types, containing (the types of) the sets of places I and O, and the set of message types used in K. The SEA may contain auxiliary message types (that do not occur in the given services), and hence I ∪ O ⊆ M . For defining the service E, we use names from the space (M ∪K)×{e, n, c, r, s}, where e, n, c, r, and s denote fresh names that do not occur in the given services. Moreover, we assume that the sets M and K are disjoint. The interface of E consists of output places I, input places O (i.e., the interfaces of the given services in opposite orientation), and an interface (defined later on) for interaction with the controller. For each message type m ∈ M , we introduce in service E an internal place

x1,r

k,c

xn

yn,s

x1,c

y1,c

...

x1

xn,r

xn,r

y1,s

y1,s

y1

...

x1,r

k,c

xn,c

yn,c

yn,s

yn

(a) Synchronous engine

x1

xn,n

x1,r

k,e

xn

k,n

x1,c

xn,r

xn,c

yn,e

y1,c k,c

y1,e

y1,s

y1

...

x1,n

...

adapter, is to ensure that after composition with the given services S1 , . . . , Sn , also the behavioral property B is established. Formally, we want to construct an SEAbased B-adapter A such that (S1 ⊕ · · · ⊕ Sn ) ⊕ A has property B, or rather, we want to construct a service C such that (S1 ⊕ · · · ⊕ Sn ) ⊕ (E ⊕ C) has property B. Using the associativity of composition operator ⊕, we construct C as a B-controller of the open net (S1 ⊕ · · · ⊕ Sn ) ⊕ E. As every C yields an SEA-based service E ⊕C, every B-controller C for the open net (S1 ⊕· · ·⊕Sn ) ⊕ E, yields an SEA-based B-adapter E ⊕ C. So, at a conceptual level, our adapter-synthesis approach consists of the following steps, given the services S1 , . . . , Sn and an SEA: 1) generate an engine E from the SEA and the interface of S1 ⊕ · · · ⊕ Sn ; 2) synthesize a B-controller C for (S1 ⊕ · · · ⊕ Sn ) ⊕ E; 3) compose E and C to obtain the final adapter E ⊕C. Figure 3 sketches this structure. Notice that property B is guaranteed independently of any specifics of the used engine. The results from Section 4.2 indicate that our approach is sound and that it is complete in the sense that every SEA-based B-adapter can be synthesized.

yn,c

yn,s

yn

(b) Asynchronous engine Fig. 4. Engine for a single rule x1 , . . . , xn 7→ y1 , . . . , yn (m, c), where c refers to “conceptual”. In the initial and final markings, the internal places are empty. Service E has three kinds of transitions. For every input place o ∈ O, there is a transition (o, r), where r refers to “receive”, to move arriving messages from interface place o to internal place (o, c). For every transformation rule Xk 7→ Yk , where k ∈ K, there is a transition (k, c) to perform the transformation in terms of the internal places. Finally, for every output place i ∈ I, there is a transition (i, s), where s refers to “send”, to move messages from internal place (i, c) to interface place i. What remains is to describe the interface with the controller, for which we consider two flavors. 4.4.2 Synchronous Interface For every transition (o, r), where o ∈ O, there is a synchronous interface port (o, r) that controls the receipt of a message o. For every transition (k, c), where k ∈ K, there is a synchronous interface port (k, c) that controls the application of transformation rule k. Finally, for every transition (i, s), where i ∈ I, there is a synchronous interface port (i, s) that controls the delivery of a message i. The synchronous engine is formally defined as: Definition 6 (Synchronous engine [9]): Let I, O, M, K be as introduced before. The synchronous engine is defined as an open net with the following constituents: P = (M × {c}) ∪ Pi ∪ Po ; m0 = 0; Ω = {0}; Pi = O; Po = I; T = (O × {r}) ∪ (K × {c}) ∪ (I × {s}); S L = St∈T { [t, t] }; F = Fr ∪ Fc ∪ Fs ; Fr = S o∈O { [o, (o, r)], [(o, r), (o, c)] }; Fc = k∈K ( { [(m, c), (k, c)] | m : m ∈ Xk } ∪ { [(k, c), (m, c)] | m : m ∈ Yk } ); S Fs = i∈I { [(i, c), (i, s)], [(i, s), i] }. Figure 4(a) illustrates this on a singleton SEA.

8

4.4.3 Asynchronous Interface For every transition (o, r), where o ∈ O, there is an output place (o, n) that notifies an arrived message o. For every transition (k, c), where k ∈ K, there is an input place (k, e) that enables transformation rule k, and an output place (k, n) that notifies an execution of transformation rule k. Finally, for every transition (i, s), where i ∈ I, there is an input place (i, e) that enables the delivery of a message i. The asynchronous engine is formally defined as: Definition 7 (Asynchronous engine [28]): Let I, O, M, K be as introduced before. The asynchronous engine is defined as an open net with the following constituents: P = (M × {c}) ∪ Pi ∪ Po ; m0 = 0; Ω = {0}; Pi = O ∪ (K × {e}) ∪ (I × {e}); Po = I ∪ (K × {n}) ∪ (O × {n}); T = (O × {r}) ∪ (K × {c}) ∪ (I × {s}); S L = St∈T { [t, τ ] }; F = Fr ∪ Fc ∪ Fs ; Fr = S o∈O { [o, (o, r)], [(o, r), (o, n)], [(o, r), (o, c)] }; Fc = k∈K ( {[(m, c), (k, c)] | m : m ∈ Xk } ∪ {[(k, e), (k, c)], [(k, c), (k, n)]} ∪ {[(k, c), (m, c)] | m : m ∈ Yk } ); S Fs = i∈I { [(i, c), (i, s)], [(i, e), (i, s)], [(i, s), i] }. Figure 4(b) illustrates this on a singleton SEA. The SEA of our running example translates to the asynchronous engine in Figure 5(b). 4.5

Refining the Adapter

The two described engines contain a transition (k, c) for Z each transformation rule Xk 7→k Yk , where k ∈ K. Moreover, each transition in the synthesized adapter refers to at most one transformation rule. If the annotations Zk are of the right shape, these transitions can easily be refined into an implementation of the transformation rule, e.g., in terms of Colored Petri net. For example, a transformation rule that converts distances in meters to distances in feet, can be implemented as multiplication by 3.2808. More complex transformations can even involve invocations of other services. Alternatively, with the results of [6], the synthesized adapter could be transformed into an abstract WS-BPEL process, containing opaque activities for the transformation rules. If Zk is an XSL transformation, we can inject Zk into the opaque activity, and thus obtain an executable adapter in a practically relevant language. 4.6

Engine Variations

In this section, we discuss some straightforward variations on our engines. 4.6.1 Initial and final markings Inspired by the requirements on interface places, the initial and final markings of the engine are supposed to be empty markings. In some cases this is too restrictive,

but it is straightforward to extend our approach to engines with arbitrary initial and final markings. An example is the case in which a shared variable s needs to be modeled. It is natural to model updates using a message w with the rule w, s 7→ s, and similarly, inspections using a message r with the rule s 7→ s, r. However, in this case the initial and final markings of the engine should contain one message s. (Shared variables are also part of [20], but not of the corresponding formal semantics [29].) 4.6.2 Partial adaptation An adapter may not be able to intercept all messages that are exchanged by the services. One example is the service of a book store where an adapter may intercept and adapt electronic messages but not the delivery of the sold book (and perhaps not the money transfer). A second example would be a composition of services in different ownership where an adapter may interact only with services in the same ownership. As a last example, some connections may have security requirements which restrict the influence of an adapter. To model partial adaptation, we slightly modify the engine. For the messages that cannot be intercepted, we omit the usual receiving and a sending transition. Instead, we just insert a transition from the input place to the corresponding output place. If the controller can be informed of passing messages, and the interface between the engine and the controller is asynchronous, then the inserted transition is also connected to a notifying output place for the controller. (In case of a synchronous interface an additional buffer needs to be introduced.) Thus the controller cannot delay such a message. 4.6.3 Optimization In some cases, the interface between the engine and the controller is larger than necessary. For example, using the empty final markings of E, we do not need an enabling input nor a notifying output for a transformation rule like X 7→ Y , provided that X is non-empty, the messages in X are no outgoing messages, and no other transformation rules have messages from X at their lefthand side. Such a rule can be executed as soon as the required messages of types X are present. Thus the interface between the engine and the controller becomes smaller, and, in turn, this makes controllers simpler.

5 I MPLEMENTATION In this section, we validate our approach using a few examples. We use deadlock freedom as the behavioral property to be established. The tools and examples can be downloaded from: http://service-technology. . org/publications/gierdsmw 2010 tsc 5.1 Tool Chain We have implemented our adapter synthesis approach in a new tool called M ARLENE1 . By combining several 1. http://service-technology.org/tools/marlene

9

R1

rE

MEuro E1 MTeaButton Communication with P

Rules 1-4

E2

Communication with R

(a) Asynchronous controller C Communication with P

Rules 1-4

MEuro

MCoffeeButton MServedTea

Communication with R

MCoffeeButton

DEuro

E3

DServedCoffee R4 rC

ω R3

NE

rT

R1

MTeaButton

NC

R2

MServedCoffee

E4

ω

DEuro

R2

Fig. 6. Running example: generated adapter (dark part) MServedTea MServedCoffee

DServedCoffee R4

(b) Asynchronous engine E Fig. 5. Services synthesized for the running example existing tools, we have implemented it with only small efforts. The chain of procedures consists of the following steps, which we explain using our running example. Get open net models of the services and the SEA These artifacts are the inputs to our approach. The services can be modeled manually as open nets, or the tool BPEL2OWFN2 [5] can be used to translate WS-BPEL specifications into open nets. Currently, the SEA can only be specified manually. In our example, we use the services in Figure 1(a) and Figure 1(c) as well as the SEA in Table 2. Create an engine model from the SEA This procedure has been described in Section 4. The SEA of our running example translates to the asynchronous engine in Figure 5(b). By construction, all outputs to the given services have been obtained from the inputs of these services using the transformation rules only. The actual scheduling of the rule applications and message deliveries is left for the controller to be synthesized next. Compose the service models and the engine model The composition of service models is supported by the Petri net API3 . Afterwards we apply structural Petri net reduction, which is also supported by the Petri net API. This reduction consists of local graph-transformations in an open net, inspired by classical Petri net reduction (like [27]). It preserves the interface behavior of the transformed net, but it may significantly reduce the number of reachable internal states. We apply it in this stage for the purpose of reducing complexity in subsequent steps. Synthesize a controller as a transition system Controller synthesis is the core functionality of the tool W ENDY4 . For details concerning the algorithms and the 2. http://service-technology.org/tools/bpel2owfn 3. http://service-technology.org/tools/petri net api 4. http://service-technology.org/tools/wendy

underlying theory, we refer to [30]. The general construction principle is to identify each state of the controller with a set of situations. A situation consists of a state of the service to be controlled and a state (number of pending messages) of the channels. E.g., the initial state of the controller corresponds to all situations that can be reached from the initial state of the service to be controlled and initially empty communication channels. The successor state of a state s for a label x corresponds to all situations that can be reached from a situation of s if the controller receives or sends one message of type x. During the construction, the states or transitions that violate the chosen behavioral property (e.g., deadlock freedom) are removed. The resulting controller is a transition system rather than an open net. Transform this transition system into an open net G ENET is a tool that translates a transition system into an equivalent Petri net. The underlying theory aims for Petri nets that exhibit a large (under some additional requirements: maximum) degree of concurrency. The resulting Petri net representation tends to be significantly more compact than the original transition system. The concurrency is also beneficial for a later translation into WS-BPEL. The result of G ENET for our running example is depicted in Figure 5(a). Compose the engine and the controller into an adapter Finally the engine and controller are composed, and we apply structural Petri net reduction afterwards. This time the reduction aims at simplifying the resulting structures, thus leading to a more compact Petri net. In particular, the reduction may iron-out dead parts in the adapter (like SEA transitions which are not used) or collapse a sequence of transitions into a single transition. As such a sequence may consist of a transition from the controller and a transition from the engine, the interface between them may become invisible in the resulting adapter. The final generated adapter, together with the initially given services, for our running example is shown in Figure 6 (where bold circles denote places with final marking 1).

10

When receiving a Euro (transition rE ) from the right net, an internal notification is generated that is removed by transition NE . After firing transition E1 , rule R1 (DEuro 7→ MEuro) can be applied. Rule R2 (7→ MCoffeeButton) can be applied after firing transitions E2 and E3 . Finally, when receiving coffee (transition rC ), an internal notification is generated that is removed by transition NC . After firing transition E4 , rule R4 (MServedCoffee 7→ DServedCoffee) can be applied; thus leading the adapter to a final state. Looking more closely at Figure 6, you may find that the (unused) transformation rule for MTeaButton has been removed and the sequences for transmitting euro and coffee have been shortened by Petri net reduction rules. Although the overall adapter is a connected net, the controller independently enables application of the rules (e.g., E1 and E4 may fire concurrently), thus providing a most permissive behavior. The adapters in Figure 1(b) and Figure 6 are accordance equivalent. 5.2

Details on Controller Synthesis

The controllability of unbounded open nets turns out [31] to be undecidable, while the engines described in Section 4 contain places that can be unbounded (especially for a message type that can be arbitrarily created). To be able to synthesize a controller for unbounded nets, an artificial bound k may be imposed on each message type (viz. only a bounded number of message is allowed inside the engine). Thus, also a controller can be computed for an unbounded net, if there is a controller that respects the bound. This is no principal restriction, as every finite-state adapter can be synthesized if k is chosen sufficiently large. For any given net, there usually exist several controllers. Although every controller yields a valid adapter, the tool implementation needs to select one. W ENDY can construct (a representation of) a set containing all controllers, and it can construct two special controllers: a most-permissive one, and an arbitrary one. A most-permissive controller represents the largest behavior that can enforce the behavioral property to be established. In this way, it causes the smallest constraints on its interface. The price for computing a mostpermissive controller is its size, which may be huge (but typically can be handled by W ENDY), and, consequently, a certain run time penalty both for W ENDY and G ENET. In turn, it exhibits a tremendous amount of non-determinism which, in many cases, results in nice concurrency in the Petri net version of the controller. Figure 5(a) shows the open net of a most-permissive controller for our running example. When computing an arbitrary controller, W ENDY produces only a part of the possible behavior. For example, W ENDY does not generate send events in states where one of the following conditions holds: 1) just receiving messages is sufficient for the behavioral property; receiving messages gives hints

about the current state of the controlled service, which can lead to more informed decisions. 2) the controlled service does not explicitly wait for that message; in the most-permissive controller, messages can be send long before they are needed since messages are buffered. 3) another send event occurs in the same state; thus non-determinism inside the controller is resolved. Due to the absence of several transitions (and the transitively resulting successor states), the produced controller is often much smaller (in terms of number of states in the transition system) than the most-permissive one. Accordingly, it takes much less time to produce it. On the other hand, this kind of controller may impose some kind of restriction on the given services. E.g., an absent send event according to the second item in the above list may cause a service to block until the controller has actually received some message while the most-permissive controller would be able to send a message instantaneously thus letting the service continue its execution. Another disadvantage is that they tend to reduce concurrency in the resulting open net. W ENDY can also synthesize an implicit representation of all controllers for a given service. This representation is called an operating guideline, and it basically consists of the most-permissive controller with some annotations. The annotations control how the behavior of the mostpermissive controller may be restricted without jeopardizing the behavioral property. This representation could be quite useful in future work where we would like to compute an adapter which is optimal with respect to some criterion. Such a criterion could model the costs, run time, or throughput of the applications of SEA rules. To sum up, both most-permissive and arbitrary controllers have specific advantages and disadvantages which more or less complement each other. This gives the user an opportunity to choose how the trade-off between complexity of synthesis and quality of the resulting adapter (in terms of size and runtime behavior) should be resolved. With the representation of all controllers, we may include further criteria for selecting an appropriate adapter. 5.3 Additional Examples To obtain an adapter with more complicated behavior, we first extend our running example with a repetition. After serving coffee or tea, the machine returns to its initial marking, which is then a final marking as well. The customer can order and receive coffee arbitrarily often, until he non-deterministically chooses to terminate. As the SEA represents domain-specific knowledge, it does not need to be modified. In this case (see [9] or the website mentioned before), the adapter can no longer treat the euro’s and buttons independently. 5.3.1 Collapse Pattern Consider the example in Figure 7, where, for the sake of simplicity, we have omitted the engine’s interface

11 engine only - interface to controller omitted

engine only - interface to controller omitted

req

R3

s0

R1

order s1

c1

IP

R2

item

c0

co

c2

invoice

cω

resp

R2 R3

inquiry

req’

R4

bill

R1

ack

IP’

part1 R4

R5

part2

reply

sω

Fig. 7. Collapse: shop, partial engine, customer

Fig. 8. Reroute: two providers, partial engine, requester

towards the controller. On the left-hand side an online shop waits for an order and then sends a bill. On the right-hand side a customer sends an arbitrary number of item codes, each of which must be confirmed by an acknowledgement (ack). Eventually the customer may check out (co) and receive an invoice. This is a typical collapse example, where the customer sends any number of items, whereas the shop expects one order. To model the collapse pattern, we need two SEA rules, which are highlighted in the gray area of the engine in Figure 7. Using rule R1 (7→ order ) we can create an empty order message. Using rule R2 (order , item 7→ order ) we can add an item to an order. Note that in the SEA rules we do not need to encode a termination condition for the collapse pattern. The other three SEA rules create an acknowledgement (R3 : 7→ ack ), delete a checkout message (R4 : co 7→), and transform the bill (R5 : bill 7→ invoice). Every controller applies rule R1 exactly once, as the shop expects one order message. To avoid that items are left over in the engine, every controller can only send the order to the shop once all items have been received and added to the order. It is up to controller synthesis to determine the termination condition, in this case using the receipt of message co.

state, it is up to controller synthesis to determine which information providers are used.

5.3.2 Reroute pattern Consider the example in Figure 8, where we have again omitted the engine’s interface towards the controller. This example illustrates the rerouting capabilities of an adapter between more than two services. On the right-hand side a requester sends an inquiry and then expects a reply. On the top left-hand side an information provider (IP) receives a request (req) and provides an immediate response (resp). These two services can collaborate via an adapter based on two SEA rules R1 (inquiry 7→ req) and R2 (resp 7→ reply). In addition, there is a second information provider (IP0 ). It can handle the same kind of requests as IP, but its response is delivered in two parts. To enable the use of this service for, e.g., load balancing, we can specify that requests can be rerouted. Rule R3 (req 7→ req 0 ) specifies the rerouting (see the highlighted gray area). In addition, rule R4 (part1 , part2 7→ resp) specifies how partial responses can be combined. Assuming that for each information provider also the initial state is a final

5.3.3 Consultancy Examples We have also applied our approach to two examples that we got as challenges from a consulting company. One models an airline ticket counter, the other one a car rental service. These were offered as WS-BPEL processes, and we have used the tool BPEL2 O WFN to obtain Petri nets. The airline example is interesting because it closes a control cycle: as long as no route is found, the adapter needs to ask for a new route (on another date), until it can deliver a bookable route to the customer. The car rental example is interesting because its services contain a large degree of concurrency. 5.4

Results

Table 3 contains for every example the number of SEA rules, and the number of places (p) and transitions (t) of the given services together. Furthermore the three composite columns describe the size of the adapter and the computation time (in seconds for M ARLENE, W ENDY and G ENET together) for the following approaches: • asynchronous engine, most-permissive controller; • asynchronous engine, arbitrary controller; • synchronous engine, most-permissive controller. In all three cases, the given services and the final adapter are modeled using open Petri nets without synchronous communication. We have used a computer with 6 GB RAM and four Intel Xeon 3.06 GHz CPUs. As related work on automated adapter synthesis reports only little about experimental results, we do not compare our experimental results. The time and memory needed for adapter synthesis depend on the number of events that needs to be evaluated during controller synthesis. In turn, this is influenced by the number of interface places, the number of rules in the SEA, and the level of concurrency in the given services. The collapse example results in a state space of 81,612 states when using an asynchronous engine (depending on the bound k). In the case of the car rental service, the most-permissive controller for the asynchronous engine consists of 5,184 states, such that 4 seconds are due to G ENET. Let us compare the results for the asynchronous engine with a most-permissive and an arbitrary controller.

12

TABLE 3 Comparison of the examples’ key data

Beverage Beverage (Repeated) Airline ticket counter Car rental service Collapse pattern Reroute pattern

SEA rules

services size (p/t)

4 4 6 7 5 4

15/ 7 14/ 8 26/11 31/19 13/ 6 15/ 5

most-permissive size (p/t) time

The synthesis of a most-permissive controller requires the computation of a larger transition system as intermediate step, which explains the larger computation time. The size of this intermediate result is mostly invisible in the synthesized Petri net adapters, since G ENET transforms arbitrarily-interleaved transitions into concurrently-enabled Petri net transitions. Although synchronous communication is less common in terms of Petri nets, for these examples the use of a synchronous engine gives even better results; see also [9]. The use of existing technology for controller synthesis makes it harder to implement optimizations specific for adapter synthesis, but so far the observed performance is very acceptable (and in line with the W ENDY benchmarks discussed in [14]). The small run-times suggest that our approach could in fact be feasible in some online scenario, where services are composed interactively, e.g., by dragging and dropping icons. The few larger run-times seem to be closer to an off-line scenario, where a layout of a service composition is carefully designed, and then wired by calculating the appropriate adapters. We shall explore the available options in future research.

6

R ELATED

WORK

The body of literature on adapter synthesis is growing fast (see [32] for a recent survey), though there are quite some similarities between the various approaches. In this section we compare our approach with some typical directions of related work. 6.1

Adaptation Context

Our adapter specification contains models of the given services to be composed. The given services themselves cannot be changed, so the goal is to synthesize an adapter service that establishes proper interaction when composed with the given services. This is the mostcommonly studied context. In contrast, [22] studies how to ensure that a given provided service behaves as a certain required service. We expect that similar techniques should be applicable as in our setting. Nevertheless, the kind of adapters that we are looking for differs from those of [22], as they basically transform actions instead of transmitted

27/12 29/14 52/23 69/30 36/17 38/18

0 0 0 9 6 0

s s s s s s

arbitrary size (p/t) time 17/ 7 18/ 8 36/18 47/24 31/17 21/ 9

0 0 0 0 6 0

s s s s s s

synchronous size (p/t) time 12/ 3 12/ 3 18/ 6 31/10 15/ 6 18/ 8

0 0 0 0 1 0

s s s s s s

messages. In this way they can address different kinds of mismatches (e.g., some instances of collapse), but at the expense that the adapters need to modify the given services including their control flow. Such an approach is not valid if the given services are not running under our command. 6.2

Service Models

Our services are expressed in terms of Petri nets, for which translations to and from industrial languages (e.g., WS-BPEL) are already available. Apart from approaches based on Petri nets, there exist approaches based on various automata and process algebras. Some authors severely restrict the services that can be modeled. For example, in [33] a custom algorithm is described for checking compatibility of services that communicate asynchronously; for compatible services also a custom algorithm is described for synthesizing an adapter in case they happen to communicate synchronously. However, this approach is restricted to services that have been designed using certain wellstructured patterns; furthermore, there is nothing like an SEA, so the adapter can only perform buffering. In [20] the interaction patterns (i.e., abstract models of the given services) are restricted by excluding recursion, while we support arbitrary bounded services, including those that contain loops. In concurrency theory, it is important to be able to reason about deadlocks and moments of choice. Related work like [22], [24] is based on traces, which makes it hard to reason about these important issues. Furthermore, in [24] there is nothing like an SEA, and their approach relies on a data structure called modified reachability tree [34]. However, in [35] it is reported that some of the claimed results in [34] are incorrect, including a fundamental theorem about deadlocks. 6.3

Adapter Specification

Our transformation rules (SEA) are expressed using a custom language, which, in turn, is translated into a service. Many other languages have been proposed that look similar but that are different. Languages like in [22], [23] do not support multiple alternative rules, like A 7→ B and A 7→ C, which in

13

our case means that at any time the adapter can choose which rule to apply. Moreover, the interface transformations from [22] are local, although, e.g., gather looks similar to our merge pattern. However, in their case the merged actions have to be subsequent actions, while our approach also handles non-local instances. Specification languages like [20], [21] look similar to our SEA, but there are essential semantic differences. Our transformation rules are asymmetric, while their rules have no direction [29]. The asymmetry is often important, e.g., when the transformation involves publickey encryption like “text 7→ encrypted text”, which is irreversible in an asymmetric cryptographic system. Essentially, the mapping rules from [36] exclude duplicates and multiple outputs, although there is an adhoc extension to address the collapse pattern. Furthermore, the rules from [19] relate messages of one service to messages of the other service, i.e., they do not seem to support transformations where a message is synthesized from messages of both services. For example, suppose one service executes the sequence “send(initiate); send(order)”, while the other service executes the sequence “receive(initiate); send(case-id); receive(order-and-case-id)”. Specifying that order-andcase-id can be generated from order and case-id although these messages arrived from different services, can be done using one SEA rule: “order, case id 7→ order-andcase-id”. 6.4

Adapter Synthesis

In our approach everything is a service, so we can directly reuse existing technology, and do not need to implement new (complex) algorithms nor modify them. Many authors, like [19], [20], [21], [37], develop custom algorithms for adapter synthesis. Such algorithms often include tricky optimizations like on-the-fly reductions. In [38], [39] a constraint-oriented approach is described. Besides the deadlock-freedom requirement, the constraint is an adapter contract, which is an LTS labeled with synchronization vectors. These adapter contracts turn out to be error-prone and it is proposed to verify the synthesized adapter; however, our insightful SEA can mimic their vector LTS using auxiliary messages. Their approach, like ours, is both generative (e.g., reordering messages) and restrictive (e.g., avoiding incorrect behavior). Their services are modeled as LOTOS processes, which are supported by the CADP toolbox (which evolved into the ITACA system [40]). Their “Store” service includes part of the functionality of our “Engine” service, but it is only used for imposing constraints, and not as part of the final adapter. In [41] an approach is described to discover a set of services and an orchestrator that together implement a user task; the opportunities for adaptation clearly influence the possibilities. These authors aim to reuse an existing planning technique to generate all solutions, but in the end a lot of modifications are needed. In contrast to our

general models of services, these authors impose serious restrictions on the behavior of the services. In that sense, their work addresses no behavioral adaptation but just service selection and data transformation. In terms of our SEA, all their data types can be copied and deleted. To the best of our knowledge, our approach is unique in its consistent separation of data and control in terms of an engine and a controller. The engine, which encodes the data transformations, is used both during controller synthesis and as part of the synthesized adapter.

7

C ONCLUSIONS

AND

F UTURE W ORK

We have proposed a novel way to synthesize behavioral adapters based on three main ingredients. The first ingredient is a powerful specification of the elementary activities (SEA) to model domain knowledge. The second ingredient is the use of an engine that encodes the SEA, thereby separating data from control. This engine is used both for synthesizing a controller, and as part of the final adapter. We expect that this structure is not only beneficial for adapter synthesis, but also for the synthesis of other services. The third ingredient is a reduction from adapter synthesis to controller synthesis. Thus, complex adapters can be synthesized using existing tools. Our approach is systematic and independent from behavioral properties or modeling formalisms. Once controller synthesis for a property and a formalism is solved, and the SEA can be translated to an engine, adapter synthesis can be reduced to controller synthesis. We have implemented our approach in a tool called M ARLENE, which uses W ENDY’s controller synthesis for the open Petri nets formalism. There exist tools that link this formalism to industrially-relevant languages like WS-BPEL. To experiment with other formalisms, we have also implemented our approach in terms of an extension of open Petri nets that includes synchronous communication. This extension only affects the interface between the engine and the controller; the given services and the final adapter are open Petri nets as usual. Using a few examples, we have shown that an implementation of our approach yields acceptable runtimes, with opportunities for further improvements. It is further work to conduct larger case studies. In future work, we intend to look for optimal adapters, according to some definitions of optimality. To this end, we want to compare different controllers based on finite representations of the set of finite-state controllers.

ACKNOWLEDGMENTS The authors like to thank Marc Voorhoeve for the useful discussions in various stages of this work. They also thank the referees for their comments that led to improvements with respect to earlier versions of this article.

14

R EFERENCES [1] [2]

[3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]

M. Papazoglou, Web Services: Principles and Technology. Essex: Pearson – Prentice Hall, Jul. 2007. C. Ouyang, H. Verbeek, W. van der Aalst, S. Breutel, M. Dumas, and A. ter Hofstede, “Formal semantics and analysis of control flow in WS-BPEL,” Science of Computer Programming, vol. 67, no. 2–3, pp. 162–198, 2007. ¨ S. Moser, A. Martens, M. H¨abich, and J. Muller, “A Hybrid Approach for Generating Compatible WS-BPEL Partner Processes.” in Proc. BPM, ser. LNCS, vol. 4102, 2006, pp. 458–464. N. Lohmann, “A feature-complete Petri net semantics for WSBPEL 2.0.” in Proc. WS-FM, ser. LNCS, vol. 4937, 2007, pp. 77–91. N. Lohmann, P. Massuthe, C. Stahl, and D. Weinberg, “Analyzing interacting WS-BPEL processes using flexible model generation,” Data & Knowledge Engineering, vol. 64, no. 1, pp. 38–54, 2008. N. Lohmann and J. Kleine, “Fully-automatic Translation of Open Workflow Net Models into Human-readable Abstract BPEL Processes,” in Proc. Modellierung, ser. LNI, vol. P-127, 2008, pp. 57–72. E. Kindler, “A compositional partial order semantics for Petri net components,” in ATPN, ser. LNCS, vol. 1248, 1997, pp. 235–252. P. Massuthe, W. Reisig, and K. Schmidt, “An Operating Guideline Approach to the SOA,” Annals of Mathematics, Computing & Teleinformatics, vol. 1, no. 3, pp. 35–43, 2005. A. Mooij and M. Voorhoeve, “Trading off concurrency to generate behavioral adapters,” in Proc. ACSD. IEEE, 2009, pp. 109–118. A. Martens, “Analyzing Web Service based Business Processes,” in Proc. FASE, ser. LNCS, vol. 3442, Apr. 2005. K. Schmidt, “Controllability of Open Workflow Nets,” in Enterprise Modelling and Information Systems Architectures, ser. LNI, vol. P-75, 2005, pp. 236–249. N. Lohmann, P. Massuthe, and K. Wolf, “Operating guidelines for finite-state services,” in Proc. ATPN, ser. LNCS, vol. 4546, 2007, pp. 321–341. P. Massuthe and K. Wolf, “An Algorithm for Matching Nondeterministic Services with Operating Guidelines,” IJBPIM, vol. 2, no. 2, pp. 81–90, 2007. N. Lohmann and D. Weinberg, “Wendy: A tool to synthesize partners for services,” in Proc. ATPN, ser. LNCS, Jun. 2010. A. Martens and S. Moser, “Diagnosing SCA components using wombat,” in Proc. BPM, ser. LNCS, vol. 4102, 2006, pp. 378–388. E. Badouel and P. Darondeau, “Theory of Regions,” in Lectures on Petri Nets I: Basic Models, ser. LNCS, vol. 1491, 1996, pp. 529–586. J. Cortadella, M. Kishinevsky, L. Lavagno, and A. Yakovlev, “Deriving Petri nets from finite transition systems,” IEEE Transactions on Computers, vol. 47, pp. 859–882, 1998. J. Carmona, J. Cortadella, and M. Kishinevsky, “Genet: a tool for the synthesis and mining of Petri nets,” in Proc. ACSD. IEEE, 2009, pp. 181–185. B. Benatallah, F. Casati, D. Grigori, H. R. Motahari Nezhad, and F. Toumani, “Developing Adapters for Web Services Integration.” in Proc. CAiSE, ser. LNCS, vol. 3520, 2005, pp. 415–429. A. Bracciali, A. Brogi, and C. Canal, “A formal approach to component adaptation.” Journal of Systems and Software, vol. 74, no. 1, pp. 45–54, 2005. A. Brogi, C. Canal, E. Pimentel, and A. Vallecillo, “Formalizing Web Service Choreographies.” Electr. Notes Theor. Comput. Sci., vol. 105, pp. 73–94, 2004. M. Dumas, M. Spork, and K. Wang, “Adapt or Perish: Algebra and Visual Notation for Service Interface Adaptation.” in Proc. BPM, ser. LNCS, vol. 4102, 2006, pp. 65–80. H. Motahari Nezhad, B. Benatallah, A. Martens, F. Curbera, and F. Casati, “Semi-automated adaptation of service interactions,” in Proc. WWW, 2007, pp. 993–1002. A. Brogi and R. Popescu, “Automated Generation of BPEL Adapters.” in Proc. ICSOC, ser. LNCS, vol. 4294, 2006, pp. 27–39. E. Rahm and P. Bernstein, “A survey of approaches to automatic schema matching,” VLDB Journal, vol. 10, no. 4, pp. 334–350, 2001. J. Mart´ın and E. Pimentel, “Automatic generation of adaptation contracts,” ENTCS, vol. 229, no. 2, pp. 115–131, Jul. 2009. T. Murata, “Petri nets: Properties, analysis and applications,” Proceedings of the IEEE, vol. 77, no. 4, pp. 541–580, 1989. C. Gierds, A. Mooij, and K. Wolf, “Specifying and generating behavioral service adapters based on transformation rules,” Institut fur Informatik, Universitat Rostock, Preprints CS-02-08, 2008. A. Brogi, C. Canal, and E. Pimentel, “On the semantics of software adaptation,” Science of Comp. Progr., vol. 61, pp. 136–151, 2006.

[30] K. Wolf, “Does my service have partners?” Transactions on Petri Nets and other Models of Concurrency, vol. 2, pp. 153–171, 2009. [31] P. Massuthe, A. Serebrenik, N. Sidorova, and K. Wolf, “Can I find a partner? Undecidability of partner existence for open nets,” Information Processing Letters, vol. 108, no. 6, pp. 374–378, 2008. [32] R. Seguel, R. Eshuis, and P. Grefen, “An overview on protocol addapters for service component integration,” Technische Universiteit Eindhoven, Beta working papers (Int. rep. 265), Dec. 2008. [33] A. Kumar and Z. Shan, “Algorithms based on pattern analysis for verification and adapter creation for business process composition,” in OTM Conferences (1), 2008, pp. 120–138. [34] F. Wang, Y. Gao, and M. Zhou, “A modified reachability tree approach to analysis of unbounded Petri nets.” IEEE Transactions on Systems, Man, and Cybernetics, vol. 34, no. 1, pp. 303–308, 2004. [35] R. Yu, W. Wu, and C. Hadjicostis, “Comments on “A modified reachability tree approach to analysis of unbounded Petri nets”.” IEEE Transactions on Systems, Man, and Cybernetics, Part B, vol. 36, no. 5, pp. 1210–1210, 2006. [36] K. Wang, M. Dumas, and C. Ouyang, “The service adaptation machine,” in Proc. ECoWS. IEEE, 2008, pp. 145–154. [37] D. Yellin and R. Strom, “Protocol specifications and component adaptors,” ACM ToPLaS, vol. 19, no. 2, pp. 292–333, 1997. ¨ “Adaptation of service pro[38] R. Mateescu, P. Poizat, and G. Salaun, tocols using process algebra and on-the-fly reduction techniques,” in Proc. ICSOC, 2008, pp. 84–99. ¨ [39] C. Canal, P. Poizat, and G. Salaun, “Model-based adaptation of behavioral mismatching components,” IEEE Transactions on Software Engineering, vol. 34, no. 4, pp. 546–563, 2008. ¨ J. Cubo, M. Ouederni, C. Canal, [40] J. C´amara, J. Mart´ın, G. Salaun, and E. Pimentel, “Itaca,” in Proc. ICSE. IEEE, 2009, pp. 627–630. [41] S. Beauche and P. Poizat, “Automated service composition with adaptive planning,” in Proc. ICSOC, 2008, pp. 530–537.

Christian Gierds received his Diploma degree in 2008. He is now research assistant and PhD ¨ zu Berlin. student at Humboldt-Universitat His PhD thesis will focus on behavioral adaptation of web services. Further research interests include system verification and nonfunctional properties of services.

Arjan J. Mooij received his PhD in 2006 from the Technische Universiteit Eindhoven. After working at The University of Nottingham as a research fellow, he has returned to Eindhoven as a postdoctoral researcher. His research interests are formal techniques for constructing and reasoning about concurrent systems. In particular, this includes topics like concurrency, formal methods, methodology, and program and proof construction.

Karsten Wolf was born in 1967. He received ¨ zu his PhD in 1996 from Humboldt-Universitat Berlin. He worked as a researcher in this place until 2005. Within this period, he also worked at Helsinki University of Technology, Dresden University of Technology, and Carnegie Mellon University. Since 2006, Karsten Wolf has been a full professor at the University of Rostock. His research topics include explicit state space verification of distributed systems and the study of web service behavior.