Specifying Dt-Flow Requirements for the Automted Composition of We Services Annpol Mrconi ITC-Irst - Trento - Itly mrconi@itc.it Mrco Pistore University of Trento - Itly pistore@dit.unitn.it Polo Trverso ITC-Irst - Trento - Itly trverso@itc.it Astrct One of the fundmentl ides of We Services nd Service Oriented Architecture is the possiility to develop new pplictions y composing existing services tht re ville on the We. Severl pproches hve een proposed to tckle the prolem of We Service Composition, ut little effort hs een devoted so fr to the prolem of modeling the requirements of the composition. However, it is cler tht the possiility to express requirements specifying complex interctions ptterns mong the component services is n essentil step to cope with wide rnge of composition prolems. In this pper we present new model which ddresses one of the key spects of composition requirements, nmely the dt flow mong the component services. We develop grphicl nottions nd forml theory for the new model nd we integrte it within n existing utomted composition frmework. 1 Introduction We services re pltform-independent pplictions tht export description of their functionlities nd re ccessile using stndrd network technologies. We services re le to perform wide spectrum of ctivities, from simple receive-response protocols to complicted usiness workflows, nd provide the sis for the development nd execution of usiness processes tht re distriuted over the network. One of the fundmentl ides of We services is the possiility to develop new pplictions y composing existing services tht re ville on the We. The mnul development of the new composite service is often difficult nd error-prone tsk, ecuse humn domin experts hve to tke cre of ll the contingencies tht cn hppen during the service execution process. The ility to support the composition of We services with utomted nd This work is prtilly funded y the MIUR-FIRB project RBNE0195K5 KLASE, y the MIUR-PRIN 2004 project STRAP, nd y the EU-IST project FP6-016004 SENSORIA. semi-utomted tools is n essentil step to decrese time nd costs in the development, integrtion, nd mintennce of complex services. Severl methods hve een proposed to cope with the utomted composition prolem (see e.g. [10, 9, 11, 13, 7, 2]). In ll those methods, the existing component services re used to define domin to e controlled, composition requirements specify the desired ehviors tht should e enforced on the domin, nd the composition tsk corresponds to synthesize controller for the domin tht relized the desired ehvior. It is widely recognized tht, in generl, utomted synthesis is hrd prolem, oth in theory nd in prctice (see, e.g. [15]). In the cse of We service composition, however, utomted synthesis turns out to e fesile not only in principle, ut lso in prctice on relistic domins of significnt complexity. Indeed, in this setting the synthesized controller hs simply to ct s n orchestrtor which controls nd directs the execution of the existing services, ut delegtes to the services the other computtionl tsks. One of the key spects of We service composition is how to derive nd model composition requirements. It is cler tht, in order to cope with wide rnge of rel composition prolems, we need wy to express complex requirements on the exchnged dt nd on the executions of the component services. Moreover, to mke the utomted composition n effective nd prcticl tsk, the requirements specifiction should e esy to write nd to understnd for the nlyst. Surprisingly, very little effort hs een devoted in the literture to ddress this prolem. In this pper we present new model which ddresses one of the key spects of composition requirements, nmely the dt flow mong the component services. We propose to specify the requirements on the dt flow through set of constrints tht define the vlid routings nd mnipultions of messges tht the orchestrtor cn perform. These constrints cn e descried in grphicl wy, s dt net, i.e., s grph where the input/output ports of the existing services re modeled s nodes, the pths in the grph define the possile routes of the messges, nd the rcs de-
fine sic mnipultions of these messges performed y the orchestrtor. In the pper, we develop the forml definition nd the grphicl nottions of dt nets. Moreover, we show how to integrte dt flow requirements expressed s dt nets within n existing utomted composition frmework [13, 14, 12]. Finlly, we show tht the proposed pproch cn hndle relistic composition prolems of significnt complexity. The rest of the document is orgnized s follows. In Section 2 we descrie the prolem of We service composition nd we illustrte the necessity to define complex dt flow requirements. In Section 3 we introduce dt nets nd we formlly define their semntics y descriing the requirements tht dt net defines on the possile ehviors of We service composition. In Section 4 we discuss how dt nets cn e integrted in the utomted composition frmework proposed in [13, 14, 12]. Finlly, Section 5 concludes the pper with relted work nd finl remrks. 2 We Service Composition: A Scenrio By utomted composition of We services we men the genertion of new composite service tht intercts with set of existing component services in order to stisfy given composition requirements. More specificlly, we will ssume tht component services re descried s BPEL4WS processes. 1 Given the descriptions of the component processes nd the composition requirements, we utomticlly generte new BPEL4WS process implementing the required composition. In this section we illustrte on cse study the prolem of the utomted composition of We services. We will focus in prticulr on the prolem of specifying the requirements of such composition. Exmple 1 (Virtul Trvel Agency) Our reference exmple consists in providing virtul trvel gency service, sy the VTA service, which offers holidy pckges to potentil customers, y comining three seprte existing services: flight ooking service Flight, hotel ooking service Hotel, nd service tht provides mps AllMps. The ide is tht of comining these three services so tht the customer my directly interct with the composed service VTA to orgnize nd possily ook his holidy pckge. In the following, we descrie informlly the three ville services, whose interction protocols re depicted in 1 BPEL4WS (Business Process Execution Lnguge for We Services) [1] is n industril lnguge for the specifiction nd execution of usiness processes mde ville thorough We services. In this pper we ssume tht component nd composite services re expressed in BPEL4WS. However, the descried pproch does not depend on the specific spects of the BPEL4WS lnguge. The pper should e understndle lso for reders who re not fmilir with BPEL4WS. Figure 1 2. Hotel ccepts requests for providing informtion on ville hotels for given dte nd given loction. If there re hotels ville, it chooses prticulr hotel nd return n offer with cost nd other hotel informtion. This offer cn e ccepted or refused y the externl service tht hs invoked the Hotel. In cse of refusl, the requester cn either request n offer for different hotel, or terminte the interction with the Hotel. The Flight service receives requests for ooking flights for given dte nd loction. If there re ville flights, it sends n offer with cost nd flight schedule. The client cn either ccept or refuse the offer. If he decides to ccept, the Flight will ook the flight nd provide dditionl informtion such s n electronic ticket. The AllMps service receives requests with two loctions nd provides digitl mp depicting distnce informtion. Intuitively, the VTA service should try to stisfy given customer request y providing informtion on ville flights nd hotels (e.g., holidy cost, flight schedule, hotel description nd mp showing distnce from the irport) nd ook the holidy ccording to customer finl decision. Figure 2 descries possile protocol tht the VTA could expose to the customer. According to it, the customer sends request for n holidy, then, if there is n ville flight, it receives flight offer. If the customer grees on the flight schedule nd cost nd there is n ville hotel, he receives n hotel offer consisting of the hotel cost, the distnce of the hotel from the irport nd other informtion out the hotel. The customer cn either decide to ccept the offer, or to sk for different hotel offer, or to terminte the interction with the VTA. If he decides to ccept, he receives the ooking confirmtion with the overll holidy cost nd other informtion out the chosen hotel nd flight. Given the description of the component services nd of the customer interfce, the next step towrds the definition of the utomted composition domin is the forml specifiction of the composition requirements. As we will see from the exmples presented in the rest of this section, even for simple cse studies we need wy to express requirements tht define complex conditions, oth for wht concerns the control flow nd for the dt exchnged mong the component services. Exmple 2 (Control-flow requirements) The VTA service min gol is to sell holidy pckges. This mens we wnt the VTA to rech sitution where the customer hs ccepted the offer nd flight nd hotel hve een ooked. However, it my e the cse tht there re no ville flights (or no ville hotels) stisfying the customer 2 In the figure, lels of input trnsitions strt with?, lels of output trnsitions strt with!, other trnsitions correspond to internl opertions performed y the services.
HOTEL BOOKING SERVICE FLIGHT BOOKING SERVICE START? request(dte,loc)? request(dte,loc) check_vil(dte,loc) check_vil(dte,loc) ALL_MAPS SERVICE! not_vil!offer(cost, hotel_info)! not_vil!offer(cost, schedule)! info(mp) START? request(from_loc, to_loc) NOT_AVAIL NOT_AVAIL CANCELED? cncel? ck? other? ck? cncel CANCELED! ooked! ooked(info) BOOKED BOOKED Figure 1. The Virtul Trvel Agency Component Services CUSTOMER INTERFACE! request(dte, loc)? f_not_vil? f_offer(cost, schedule) F_NOT_AVAIL! cncel! f_ck F_REFUSED? h_not_vil? h_offer(cost, hotel, dist_mp) H_NOT_AVAIL! other! cncel! h_ck H_REFUSED? ooked(cost, info) BOOKED Figure 2. The VTA Customer Interfce Exmple 3 (Dt-flow requirements) In order to provide consistent informtion, the VTA service needs to exchnge dt with the components nd its customer in n pproprite wy. For instnce, when invoking the Flight service, the informtion out the loction nd dte of the flight must e the sme ones tht the VTA received in the customer request; similrly, the informtion sent to the customer out the distnce etween the proposed hotel nd the irport must e those otined from the lst interction with the AllMps service; nd such service must receive the informtion on the irport nd hotel loction ccording to the lst offer proposed y the Hotel service. Moreover, the cost proposed to the customer for the holidy pckge must e the sum of the hotel nd flight cost plus some dditionl fee for the trvel gency service; thus the cost offered to the customer must e computed y mens of function internl to the VTA service. And so on. request, or tht the customer doesn t like the flight or the hotel offer nd thus cncels the ooking. We cnnot void these situtions, therefore we cnnot sk the composite service to gurntee this requirement. In cse this requirement cnnot e stisfied, we do not wnt the VTA to ook flight (nor hotel) without eing sure tht our customer ccepted the offer, s well s we do not wnt displesed customers tht hve ooked holidys for which there re no ville flights or hotels. Thus, our glol termintion requirement would e something like: do whtever is possile to sell holidy pckges nd if something goes wrong gurntee tht there re no single commitments. This termintion requirement is only prtil specifiction of the constrints tht the composition should stisfy. Indeed, we need to specify lso complex requirements on the dt flow. The exmple shows tht, even for pprently simple composition prolems, we need wy to express complex dt flow requirements: from simple dt links etween incoming nd outgoing messge prts (e.g., forwrding the informtion received y the customer out the loction to the Flight service), to the specifiction of complex dt mnipultion (e.g., when computing the holidy pckge cost), to more sutle requirements concerning dt (e.g., ll the time the VTA invokes the AllMps service it must send the loction informtion of the lst hotel offer received, while the sme irport loction informtion cn e used more thn once). The reserch chllenge we ddress in this pper is the definition of modeling lnguge tht llows to cpture dt-flow composition requirements for relistic composition prolems.
3 Modeling Dt Flow Requirements The im of the dt flow modeling lnguge is to llow for the specifiction of complex requirements concerning dt mnipultion nd exchnge. In prticulr, dt flow requirements specify how output messges (messges sent to component services) re otined from input messges (messges received from component services). This includes severl importnt spects: whether n input messge cn e used severl times or just once, how severl input messges must e comined to otin n output messge, whether ll messges received must e processed nd sent, etc.. 3.1 Syntx In the following we descrie the sic elements of the lnguge, show how they cn e composed to otin complex expressions nd provide n intuitive semntics. Connection Node A connection node cn e externl or internl. An externl connection node is ssocited to n output (or n input) externl port. Intuitively, n externl input (output) node chrcterizes n externl source (trget) of dt nd it is used to exchnge dt with the outside world. Identity It is connected to one connection node in input nd one node in output. The requirement sttes tht dt received from the input node should e forwrded to the output node. The grphicl nottion for the dtflow identity element id()(), with input node nd output node, is the following:! Opertion It is relted to function definition; it is connected to s mny input nodes s the numer of function prmeters nd only to one output node corresponding to the function result. The requirement sttes tht, when dt is received from ll the input nodes, the result of the opertion should e forwrded to the output node. The grphicl nottion for the dt-flow opertion element oper[f](,)(c) chrcterizing function f, with input nodes nd nd output node c, is the following: Fork It is connected to node in input nd to s mny nodes s necessry in output. It forwrds dt received on the input node to ll the output nodes. The grphicl nottion for the dt-flow fork element fork()(,c), with input node nd output nodes nd c, is the following: Merge It is connected to one node in output nd s mny nodes s necessry in input. It forwrds dt received on some input node to the output node. It preserves the temporl order of dt rriving on input nodes (if it receives dt on two or more input nodes t the sme time, the order is nondeterministic). We represent the dt-flow merge element merge(,)(c), with input nodes nd nd output node c s: Cloner It is connected to one node in input nd one node in output. It forwrds, one or more times, dt received from the input node to the output node. The dt-flow cloner element clone()(), with input node nd output node is represented s: f + Filter It is connected to one node in input nd one node in output. When it receives dt on the input node, it either forwrds it to the output node or discrds it. We represent the dt-flow filter element filt()(), hving input node nd output node s:? Lst It is connected to one node in input nd one node in output. It requires tht t most one dt is forwrded to the output node: the lst dt received on the input c c c
C.request.dte! F.request.dte C.request.loc F.request.loc H.request.loc H.offer.cost F.offer.cost L prep_cost C.h_offer.cost C.ooked.cost C.f_offer.cost get_dte H.request.dte F.offer.schedule C.f_offer.schedule get_irport + M.request.from_loc get_loc M.request.to_loc H.offer.info C.h_offer.hotel F.ooked.info L prep_info C.ooked.info M.info.mp! C.h_offer.dist_mp Figure 3. The dt flow requirements for the Virtul Trvel Agency node. All other dt tht re received should e discrded. The grphicl nottion for the dt-flow lst element lst()(), with input node nd output node, is the following: The digrm otined y suitly composing dt-flow elements y mens of connection nodes is clled dt net (see Figure 3 for n exmple). A dt net is chrcterized y set of externl connection nodes ssocited to input ports Next, I set of externl connection nodes ssocited to output ports Next, O set of internl connection nodes N int, set of dt-flow elements D (corresponding to the sic elements descried in this section) nd set of dt vlues V. Given dt-flow element d, we denote with in nodes(d) the set of input connection nodes of d nd with out nodes(d) the set of output connection nodes of d. Definition 1 (Dt Net) A dt net D is tuple N I ext, N O ext, N int, D, V where: L for ech n N I ext there exists unique dt-flow element d D s.t. n in nodes(d); for ech n N O ext there exists unique dt-flow element d D s.t. n out nodes(d); for ech n N int there exists unique dt-flow element d 1 D s.t. n in nodes(d 1 ) nd there exists unique dt-flow element d 2 D s.t. n out nodes(d 2 ); for ech d D, in nodes(d) N I ext N int nd out nodes(d) N O ext N int. Notice tht it is possile to ssocite type to ech connection node in the network. Indeed, externl nodes inherit the types from the corresponding BPEL4WS ports, nd the types of internl nodes cn e deduced from the structure of the dt net. We do not consider this spect to mke the formliztion more understndle; completing the model to hndle typed connection nodes is strightforwrd. A possile specifiction of the dt net for the Virtul Trvel Agency exmple is presented in Figure 3, which we will (prtilly) explin in the following exmple. Exmple 4 When the VTA receives request from the Customer, it must forwrd the dte informtion to the Flight nd the loc informtion oth to the Flight nd to the Hotel. To otin the cost to e sent in the offer to the Customer, the VTA must pply its internl function prep cost on the cost received in the offer from the Flight nd on the cost informtion in the lst offer received from the Hotel. The VTA must otin the dte informtion tht it sends in the request to the Hotel y computing its internl function get dte on the schedule received in the offer of the Flight. The schedule received in the offer of the Flight is lso forwrded to the client, s prt of the f offer messge. Finlly, the VTA exploits the internl function get irport
on the flight schedule to otin the from loc informtion to e sent to the AllMps; the VTA cn use this sme informtion to send severl requests to the AllMps. And so on. 3.2 Semntics We now formlize the semntics of the dt flow modeling lnguge. Given dt net D = Next, I Next, O N int, D, V, we denote with N ext the sets of ll externl connection nodes, formlly N ext = Next I Next. O An event e of D is couple n, v, where n N ext N int, nd v V, which models the fct tht the dt vlue v psses through the connection node n. An execution ρ of D is finite sequence of events e 0,..., e n. Given n execution ρ we define its projection on set of connection nodes N N ext N int, nd denote it with Π N (ρ), the ordered sequence e 0,..e m representing the events in ρ which correspond to nodes in N. We formlly define the semntics of our lnguge in terms of ccepted executions of dt net D. In the following definition, we exploit regulr expressions to define the ccepted execution. We use nottion Σ to express lterntives tht rnge over ll the possile vlues v V tht cn flow thorough the net. Definition 2 (dt net ccepting execution) An execution ρ is ccepted y dt net D = N I ext, N O ext, N int, D, V if it stisfies ll the following properties: for ech identity element id()() in D: ( Π {,} (ρ) =, v, v ) for ech opertion element oper[f](,)(c) in D: v,w V Π {,,c} (ρ) = (, v, w +, w, v ) c, f(v, w) for ech fork element fork()(,c) in D: Π {,,c} (ρ) = (, v (, v c, v + c, v, v ) ) for ech merge element merge(,)(c) in D: ( Π {,,c} (ρ) = (, v c, v +, v c, v ) for ech cloner element clone()() in D: ( ) Π {,} (ρ) =, v, v, v for ech filter element filt()() in D: ( Π {,} (ρ) =, v (, v + ɛ) for ech lst element lst()() in D: ) ) ( ( ) Π {,} (ρ) =, v ), v, v + ɛ Notice tht this definition considers dt net elements hving t most two input/output nodes, however it cn esily e extended to hndle elements of the dt net hving more input/output nodes. 3.3 Dt Net Stisfiility A dt net cn e used to specify the desired ehvior of service or everything tht concerns the exchnge of dt with its communiction prtners. In prticulr, s shown in the dt net of Figure 3, externl connection nodes re ssocited to input (or output) ports which model BPEL4WS messges, or messge prts, which re used to store dt received (or sent) y the process while intercting with other services. Since the ehviorl spect we re interested in concerns the dt flow mong the process nd its prtners, we chrcterize n execution of BPEL4WS process W, denoted with exec(w ), s the set of ll possile ordered sequence of input/output messges (or messge prts) received nd sent y the process from its ctivtion to its termintion. Notice tht ech messge crries oth the informtion out the externl port on which it hs een sent/received nd out its content (vlue). Definition 3 (dt net stisfiility) Let W e BPEL4WS process nd D = N I ext, N O ext, N int, D, V dt net. We sy tht W stisfies D if for ech process execution ρ W exec(w ) there exists n ccepting execution ρ of D such tht Π Next (ρ) = ρ W.
4 Automted Composition of We Services In this section we show how dt nets cn e integrted in generl frmework for the utomted composition of We services. 4.1 An Automted Composition Frmework The work in [13] (see lso [14, 12]) presents forml frmework for the utomted composition of We services which is sed on plnning techniques: component services define the plnning domin, composition requirements re formlized s plnning gol, nd plnning lgorithms re used to generte the composite service. The frmework of [13] differs from other plnning frmeworks since it ssumes n synchronous, messge-sed interction etween the domin (encoding the component services) nd the pln (encoding the composite service). We now recll the most relevnt fetures of the frmework defined in [13]. The composition domin is modeled s stte trnsition system (STS from now on) which descries dynmic system tht cn e in one of its possile sttes (some of which re mrked s initil sttes nd/or s finl sttes) nd cn evolve to new sttes s result of performing some ctions. Actions re distinguished in input ctions, which represent the reception of messges, output ctions, which represent messges sent to externl services, nd internl ctions, which represent internl evolutions tht re not visile to externl services, i.e., dt computtion tht the system performs without intercting with externl services. A trnsition reltion descries how the stte cn evolve on the sis of inputs, outputs, or internl ctions. Definition 4 (stte trnsition system (STS)) A stte trnsition system Σ is tuple S, S 0, I, O, A, R, F where: S is the finite set of sttes; S 0 S is the set of initil sttes; I is the finite set of input ctions; O is the finite set of output ctions; A is the finite set of internl ctions; R S (I O A) S is the trnsition reltion; F S is the set of finl sttes. We hve defined trnsltion tht ssocites stte trnsition system to ech component service, strting from its BPEL4WS specifiction. We omit the forml definition of the trnsltion, which cn e found t http://stroproject.org. Intuitively, input ctions of the STS represent messges received from the component services, output ctions re messges sent to the component services, internl ctions model ssignments nd other opertions which do not involve communictions, nd the trnsition reltion models the evolution of the service. Exmples of the STS representtion of BPEL4WS component services cn e found in Figure 1. The utomted synthesis prolem consists in generting stte trnsition system Σ c tht, once connected to Σ, stisfies the composition requirements. We now recll the definition of the stte trnsition system descriing the ehvior of Σ when connected to Σ c. Definition 5 (Controlled system) Let Σ = S, S 0, I, O, A, R, F nd Σ c = S c, Sc 0, I c, O c, A, R c, F c e two stte trnsition systems such tht I = O c nd O = I c. The stte trnsition system Σ c Σ, descriing the ehviors of system Σ when controlled y Σ c, is defined s follows: Σ c Σ = S c S, S 0 c S 0, I, O, A, R c R, F c F, where: (s c, s),, (s c, s ) (R c R), if s c,, s c R c nd s,, s R In n utomted synthesis prolem, the composition requirements re formlized s specifiction ρ, nd the composition tsk consists in generting Σ c tht gurntees tht the controlled system Σ c Σ stisfies the requirement ρ, written Σ c Σ = ρ. In [13], ρ is formlized using EA- GLE, requirement lnguge which llows to specify conditions of different strengths (like try nd do ), nd preferences mong different (e.g., primry nd secondry) requirements. EAGLE opertors re similr to CTL opertors, ut their semntics, formlly defined in [6], tkes into ccount the notion of preference nd the hndling of filure when sugols cnnot e chieved. Exmple 5 The EAGLE formliztion of the control-flow requirements in Exmple 2 is the following. TryRech C.BOOKED F.BOOKED H.BOOKED M.SUCC Fil DoRech (C.F NOT AVAIL C.F REFUSED C.H NOT AVAIL C.H REFUSED) (H.NOT AVAIL H.CANCELED H.START) (F.NOT AVAIL F.CANCELED) (M.START) The gol is of the form TryRech c Fil DoRech d. TryRech c requires service tht tries to rech condition
c, in our cse the condition sell holidy pckges. During the execution of the service, stte my e reched from which it is not possile to rech c, e.g., since the product is not ville. When such stte is reched, the requirement TryRech c fils nd the recovery condition DoRech d, in our cse no single commitments is considered. The definition of whether ρ is stisfied is given in terms of the executions tht Σ c Σ cn perform. Given this, we cn chrcterize formlly n utomted synthesis prolem. Definition 6 (Automted Synthesis) Let Σ e stte trnsition system, nd let ρ e n EA- GLE formul defining composition requirement. The utomted synthesis prolem for Σ nd ρ is the prolem of finding stte trnsition system Σ c such tht Σ c Σ = ρ. The work in [13] shows how to dpt to this tsk the Plnning s Model Checking pproch, which is le to del with lrge nondeterministic domins nd with requirements expressed in EAGLE. It exploit powerful BDD-sed techniques developed for Symolic Model Checking to efficiently explore domin Σ during the construction of Σ c. 4.2 Dt Requirements s STSs As we hve seen in previous sections, dt net D of prticulr composition prolem specifies how messges received from the component services cn e used y the new composite process to generte outgoing messges. Therefore, it is possile to represent D s STS Σ D, which models the llowed dt flow ctions. In prticulr, input ctions in Σ D represent messges received y the component services, output ctions represent messges sent y the component services nd internl ctions represent ssignments tht the composite process performs on its internl vriles. We ssume tht, in the BPEL4WS specifiction of the composite service, vrile will exist for ech connection node in D; vriles ssocited to externl connection nodes re those used y the new composite process to store received messges nd to prepre the messges to e sent, while vriles ssocited to internl connection nodes re those used to mnipulte messges y mens of internl functions nd ssignments. Then Σ D defines constrints on the possile opertions tht the composite process cn perform on these vriles. A nice feture of our pproch is tht this cn e done compositionlly, i.e., smll utomton cn e ssocited to ech element of the dt net, nd STS Σ D is otined s the product of ll these smll utomt. More precisely, for ech output opertion of component service, which is ssocited to some externl input port in the dt net, we define STS which represents the sending of the messge (s n output ction) nd the storing of ll messge prts (s internl ctions). As n exmple, considering the VTA composition prolem, for the output opertion C.request with messge prts dte nd loc we define the following STS: 3 C.request.loc >C_request_loc!C.request C.request.dte >C_request_dte Similrly, for ech input opertion of component service, which is ssocited to some externl output port in the dt net, we define STS which represents the storing of ll messge prts (s internl ctions) nd the reception of the messge (s n input ction). As n exmple, for the input opertion C.ooked with messge prts info nd cost we define the following STS:?C.ooked x >C_ooked_cost x >C_ooked_info x >C_ooked_info x >C_ooked_cost?C.ooked Finlly, we define STS for ech dt-flow element of the dt net. These STSs hve no input/ouput ctions since they model mnipultion of vriles through ssignments. In prticulr: for ech identity element id()() in the dt net we define the following STS: for ech opertion element oper[f](,)(c) in the dt net we define the following STS: 3 In the STS tht we use to model dt net requirements, we represent input opertions y? followed y the opertion nme, output ctions y! followed y the opertion nme, while internl ctions, denoted with ->, model n internl opertion tht copies the vlue of in vrile. We use x s plce-holder for ritrry nodes/expression: so for instnce x-> denotes ll internl ctions copying ny vrile/expression to vrile, nd similrly for ->x. Finl sttes re mrked with n internl circle.
x > x > f(,) >c The STS Σ D modeling the dt net D is the synchronized product of ll the STSs corresponding to externl connection nodes nd to dt-flow elements of D. The synchronized product Σ 1 Σ 2 models the fct tht the systems Σ 1 nd Σ 2 evolve simultneously on common ctions nd independently on ctions elonging to single system. for ech fork element fork()(,c) in the dt net we define the following STS: >c >c for ech merge element merge(,)(c) in the dt net we define the following STS: >c x > >c for ech cloner element clone()() in the dt net we define the following STS: 4.3 Generting the Composite Process We re redy to show how we cn integrte the proposed composition pproch within the utomted composition frmework presented in Section 4.1. Given n component services W 1,..., W n nd dt net D modeling the dtflow composition requirements, we encode ech component service W i s STS Σ Wi nd the dt net D s STS Σ D. The composition domin Σ for the utomted composition prolem is the synchronized product of ll these STSs. Formlly, Σ = Σ D Σ W1.. Σ Wn. The plnning gol ρ is the EAGLE formliztion of the composition termintion requirements, enriched with the requirements tht ll the dt flow STS need to terminte in finl stte. Given the domin Σ nd the plnning gol ρ we cn pply the pproch presented in [13] to generte controller Σ c, which is such tht Σ c Σ = ρ. Once the stte trnsition system Σ c hs een generted, it is trnslted into BPEL4WS to otin the new process which implements the required composition. The trnsltion is conceptully simple; intuitively, input ctions in Σ c model the receiving of messge from component service, output ctions in Σ c model the sending of messge to component service, internl ctions model mnipultion of dt y mens expressions nd ssignments. for ech filter element filt()() in the dt net we define the following STS: for ech lst element lst()() in the dt net we define the following STS: 5 Conclusions nd Relted Work In the pper we hve descried new model for defining dt flow requirements for the utomted composition of We services. Its interesting fetures re the possiility to exploit esy to understnd grphicl nottions nd to model the requirements in dt net, s well s the possiility to integrte the requirements in generl frmework for the utomted composition of We services. Future work will include the implementtion of grphicl tool for drwing the requirements nd its inclusion in the AS- TRO toolset (http://www.stroproject.org) nd its experimentl evlution. Severl methodologies hve een proposed to model different spects of requirements for service oriented pplictions, from gol-oriented pproches, see, e.g., [8, 5], to UML-sed oject-oriented methodologies, see, e.g., [17]. In these works, high-level requirements re used to guide nd construct y hnd the composition. The prolem of the utomted synthesis of compositions is not ddressed.
These methodologies cn e integrted with our pproch nd used in pre-nlysis step to guide the nlyst to the definition of the dt net tht we use to generte utomticlly the composition. Most of the works tht ddress the prolem of the utomted synthesis of process-level compositions do not tke into ccount dt flow specifictions. This is the cse of the work on synthesis sed on utomt theory tht is proposed in [7, 2, 3], nd of work within the semntic we community, see, e.g., [10]. Some other pproches, see, e.g., [16], re limited to simple composition prolems, where component services re either tomic nd/or deterministic. The work closest to ours is the one descried in [4], which proposes n pproch to service ggregtion tht tkes into ccount dt flow requirements. The min difference is tht dt flow requirements in [4] re much simpler nd t lower level thn in our frmework, since they express direct identity routings of dt mong processes, nd do not llow for mnipultions of dt. The exmples reported in this pper clerly show the need for expressing mnipultions in dt-flow requirements nd higher level requirements. [12] M. Pistore, A. Mrconi, P. Trverso, nd P. Bertoli. Automted Composition of We Services y Plnning t the Knowledge Level. In Proc. IJCAI 05, 2005. [13] M. Pistore, P. Trverso, nd P. Bertoli. Automted Composition of We Services y Plnning in Asynchronous Domins. In Proc. ICAPS 05, 2005. [14] M. Pistore, P. Trverso, P. Bertoli, nd A.Mrconi. Automted Synthesis of Composite BPEL4WS We Services. In Proc. ICWS 05, 2005. [15] A. Pnueli nd R. Rosner. Distriuted rective systems re hrd to synthesize. In Proc. of IEEE Symp. of Foundtions of Computer Science, 1990. [16] S. Ponneknti nd A. Fox. SWORD: A Developer Toolkit for We Service Composition. In Proc. WWW 02, 2002. [17] D. Skogn, R. Gronmo, nd I. Solheim. We Service Composition in UML. In Proc. EDOC 04, 2004. References [1] T. Andrews, F. Curer, H. Dolki, J. Golnd, J. Klein, F. Leymnn, K. Liu, D. Roller, D. Smith, S. Thtte, I. Trickovic, nd S. Weervrn. Business Process Execution Lnguge for We Services (version 1.1), 2003. [2] D. Berrdi, D. Clvnese, G. D. Gicomo, M. Lenzerini, nd M. Mecell. Automtic composition of E-Services tht export their ehviour. In Proc. ICSOC 03, 2003. [3] D. Berrdi, D. Clvnese, G. D. Gicomo, nd M. Mecell. Composition of Services with Nondeterministic Oservle Behviour. In Proc. ICSOC 05, 2005. [4] A. Brogi nd R. Popescu. Towrds Semi-utomted Workflow-Bsed Aggregtion of We Services. In Proc. IC- SOC 05, 2005. [5] E. Colomo, J. Mylopolous, nd P. Spoletini. Modeling nd Anlyzing Context-Awre Compositions of Services. In Proc. ICSOC 05, 2005. [6] U. Dl Lgo, M. Pistore, nd P. Trverso. Plnning with Lnguge for Extended Gols. In Proc. AAAI 02, 2002. [7] R. Hull, M. Benedikt, V. Christophides, nd J. Su. E- Services: A Look Behind the Curtin. In Proc. PODS 03, 2003. [8] D. Lu nd J. Mylopoulos. Designing We Services with Tropos. In Proc. ICWS 04, 2004. [9] S. McIlrith nd R. Fdel. Plnning with Complex Actions. In Proc. NMR 02, 2002. [10] S. McIlrith nd S. Son. Adpting Golog for Composition of Semntic We Services. In Proc. KR 02, 2002. [11] S. Nrynn nd S. McIlrith. Simultion, Verifiction nd Automted Composition of We Services. In Proc. WWW 02, 2002.