1

Web Service Interaction Modeling and Verification Using RecursiveComposition Algebra

Gopal N. Rai1,2, G. R. Gangadharan1, Vineet Padmanabhan2, Rajkumar Buyya3

1IDRBT, Hyderabad, India2University of Hyderabad, Hyderabad, India

3University of Melbourne, Melbourne, Australia

The design principle of composability among Web services is one of the most crucial reasons for the success and popularity of Webservices. However, achieving error-free automatic Web service composition is still a challenge. In this paper, we propose a recursivecomposition based modeling and verification technique for Web service interaction. The application of recursive composition overa Web service with respect to a given set of Web services yields a recursive composition interaction graph (RCIG). In order tocapture the requirement specifications of a Web service interaction scenario, we propose recursive composition specification language(RCSL) as a requirement specification language. Further, we employ the proposed RCIG as an interpretation model to interpret thesemantics of a RCSL formula. Our verification technique is based on the generation and analysis of all possible interaction patterns.Performance evaluation results, provided in this paper, show that our proposition is implementable for the real world applications.The key advantages of the proposed approach are: (i) it does not require explicit system modeling as in model checking basedapproaches, (ii) it captures primitive characteristics of Web service interaction patterns, such as recursive composition, sequentialand parallel flow, etc, and (iii) it supports automatic composition of services.

Index Terms—Web service composition, Web service interaction, recursive composition, interaction modeling, interactionverification

I. INTRODUCTION

Web services are distributed and independent software mod-ules which communicate with each other through the exchangeof messages based on the XML standards [1]. Web services arecategorized into basic and composite [2]. A basic Web serviceis self-contained and independent whereas a composite Webservice is dependent on other Web services and based on therequirements, forms composition out of available services. Inthe context of Web services, two types of composition arepossible: linear composition and recursive composition [3],[1]. In linear composition, the constituent Web services areonly basic Web services, whereas in recursive composition, theconstituent Web services could be basic as well as composite.The notion of recursive composition requires special attention[4] in the verification process as it is not easily tractable withclassical modeling and verification schemes such as modelchecking and Petri net.

Modeling and verification of Web service interaction isa well-explored research area. Various solutions that areproposed for modeling and verification of Web service in-teractions can be classified as: aspect-based: modeling [5],[6], [7], verification [8], [9], modeling and verification [10],[11]; target-based: BPEL [12], [13], WSDL [11], [14]; andapproach-based: model-based [15], [16], Petri net based [7],[17], process algebra based [18], artificial intelligence (AI)planning based [19], [6], logic based [20]. Although theexisting solutions are promising, core techniques adopted inthe solutions do not capture all the required characteristicsof Web service interaction verification as they were proposednatively for different scenarios and applications. Key issuesassociated with Web service interaction modeling and veri-

Corresponding author: G.R.Gangadharan (email:geeyaar@gmail.com)

fication, focused in this paper, are described as follows: Ifwe model a Web service interaction scenario using a genericinteraction model [21], [22], it may not be suitable becausea Web service cannot interact with all other available Webservices as invoking a service is conditional (based on inputand output messages compatibility of caller and callee Webservices). Further, unlike a generic interaction model, in aWeb service interaction model, a participant may be dependenton other participants for its replies. A message sequencechart (MSC) is one of the popular and classical genericinteraction modeling techniques. MSCs have also been usedfor the verification purpose [23], [16], [24]. However, MSCsdo not capture the primitive characteristics of Web serviceinteraction patterns such as parallel and sequential interactionflows initiated at a time by a service.

WS-BPEL defines a model for describing the behavior of abusiness process based on interactions between the process andits partners [25]. In order to realize an automatic and dynamicWeb service composition, a feasible way is to generate acomposite service or a BPEL file automatically and on the flyas per requirement. However, automatic generation of BPELis not feasible unless we have a technique for automaticknowledge extraction about Web services. For a service, itsWSDL document [26] is a source to extract the knowledgeabout the service, but a WSDL file does not provide underlyingimplementation details and logic. Due to the lack of thisknowledge, the complete and comprehensive verification ofWeb service interaction is not possible [27]. WSDL and BPELdocuments consist of several built-in features. If these built-infeatures are richer, the accompanying coding or logic effort forthe verification process becomes less. If a verifier could knowinteraction patterns in advance, it would be easy to find outthe possible undesired interaction patterns. In a composition

2

hierarchy, composite services may exist at several levels. Inorder to support the full automation, no composite serviceshould be bound with the constituent services before run-time[2].

The Kripke model has been a prominent model to interpretformulas written in temporal logics, thus comprises fundamen-tal part of model checking [28]. In a model checking basedverification technique, a set of labelled transition rules governsthe transitions from one world (Kripke node) to another. How-ever, in the context of Web services, the underlying philosophyof a transition from one service to another is different than themodel checking. For instance, in the context of Web serviceinteraction, the communication messages are considered aspropositions [10]. The truth value of a message infers whetherthe message is communicated or not. Once truth value fora message is set ‘true’, it cannot be altered to ‘false’ at asubsequent time instance. Moreover, model checking does notsupport modeling subtleties regarding Web service interactionsuch as automatic discovery of Web services [29].

In order to overcome the mentioned problems, in thispaper, we employ our previously proposed algebraic modelfor Web services namely, the Recursive Composition Algebra(RCA) [14] (with several modifications). This paper proposes acomplete framework for modeling and verification of the Webservice interaction and makes the following key contributions:• A recursive composition based modeling technique for

the Web service interaction: This technique generatesa recursive composition interaction graph (RCIG) thatworks as an interpretation model. We studied the feasi-bility for implementability of the RCIG and found that itis completely implementable in the real-time scenarios.

• A requirement specification language: We propose a spec-ification language namely, recursive composition speci-fication language (RCSL) that is expressive enough tocapture requirements of Web service interaction scenariosand completely interpretable on the RCIG model.

• A verification technique - We propose a verificationtechnique based on the possible trace phenomenon andoutline the fundamental differences with possible worldphenomenon. This verification technique employs RCIGas its interpretation model and RCSL as its specificationlanguage.

We implemented our proposed framework of Web serviceinteraction modeling and verification using Java programminglanguage. Given a set of WSDL documents of candidateservices, the framework accepts the following inputs:• An input message (Ip) or a service name (wi) or an input-

service tuple (〈wi, Ip〉)• A specification formula (φ) written in RCSL

Provision of an input (Ip or wi or 〈wi, Ip〉) generates a RCIG(say M ) for interactive trace visualization and performanceanalysis, whereas provision of a RCSL formula (say φ) triggers

verification process (M?

|= φ) along with trace visualization.If model M does not satisfy φ (M 2 φ), counter trace (T ) isalso generated. In the implementation, a RCIG is generatedautomatically using GraphViz tool by invoking the systemlevel commands internally.

The rest of the paper is organized as follows. Section IIpresents our proposed algebraic modeling of Web serviceinteraction. Formation of recursive composition interactiongraph and its implementation are discussed in Section III.Verification approach based on possible trace phenomenon isdescribed in Section IV. Section V provides implementationdetails and feasibility analysis of the RCIG. Section VIIinvestigates the relevant works followed by the advantagesand limitations of our proposed approach with possible futureworks in Section VIII.

II. ALGEBRAIC MODELING OF WEB SERVICECOMPOSITION

In this section, we present complete description of modifiedRCA with its algebraic properties and computability analysis.In comparison to the previous version of RCA [14], currentversion consists of two key modifications: (1) A single compo-sition operation instead of previously defined two compositionoperations and (2) Introduction of a term service-input tupleand based on it, we redefine the operators: conditional succes-sor, restrictive successor, and recursive composition.

Let W = {w1, w2, w3, · · · , wm, ε} be a finite set of avail-able Web services, where ε represents an empty Web service.An empty Web service does not invoke any service or performany activity. On the basis of our proposition, we define a Webservice wi ∈ W as follows:

Definition II.1 (Basic Web service). A Web service wi ∈ Wis a 3-tuple 〈I,R,Rl〉, where I = {I1, · · · Ip}, p ∈ Nis a finite set of input messages, that wi accepts. R ={R1, · · · , Rq}, q ∈ N is a finite set of response messages, thatwi produces. Rl is a service logic that maps an input messagefrom I to the output messages in R (Rl ⊆ I×R). wi.I , wi.R,and wi.Rl are referred as the set of input messages, the set ofresponse messages, and the relation from wi.I to wi.R in wi.

For a Web service, the set of input messages, the set ofoutput messages, and relation from input message set to outputmessage set are static and available in the respective WSDLdocument. We define a composite service as follows:

Definition II.2 (Composite Web service). A composite Webservice wi ∈ W is a 3-tuple 〈I, F,Rl〉, where I ={I1, · · · Ip}, p ∈ N is a finite set of input messages, that wiaccepts. F = {F1, · · · , Fq}, q ∈ N is a finite set of forwardmessages, that wi produces. Rl is a service logic that mapsan input message from I to a set of forward messages in F(Rl ⊆ I × 2F ). wi.I , wi.F , and wi.Rl are referred as theset of input messages, the set of forward messages, and therelation (called as service logic) from wi.I to wi.F in wi.

A. Operators (successor, composition, and recursive compo-sition)

Definition II.3 (Absolute successor). Let ‘�’ be a symbol torepresent the successor operator. � maps an element of theWto an element of the power set of the set W (�: W → 2W ).Given a composite Web service wi ∈ W , S ⊂ W is a set ofsuccessor services for wi if and only if ∀wj ∈ S, ∃Ff ∈ wi :wi.Ff ∩ wj .I 6= ∅.

3

The absolute successor (in short, successor) operator (�)is an unary operator that provides services directly invokableby a composite service (we call them as successor services).The successor operator works only for a composite service asa basic service does not call other services for composition.If a service wi ∈ W invokes a service wj ∈ W , thenwj ∈ (� wi). If wj is not known in advance, we write� wi = {wi+1} unless stated otherwise. If the service widirectly invokes a set of services (say {w1, · · · , wl} ⊂ W)then � wi = {w1, · · · , wl}. If the service wi does not invokeany service from the set W , then � wi = ∅.

The composition of services (say, n no. of services) is theaggregation of facilities provided by the n services as a singleservice. Composability of a service with another service isdecided by successor relation. Given a composite service wiand its successor service wj , wj is always composable with wi.Let ‘⊕’ be a symbol that represents the service composition.We define composition of services as follows:

Definition II.4 (Service composition). Given two Web ser-vices wi, wj ∈ W : wj ∈ (� wi), composition of wi andwj (represented as wi ⊕ wj) yields a composite Web servicewk ∈ W such that∃m ∈ wi.I

((wi.Rl(m) = n) ∧ (n ∈ wj .I)

)→((m ∈

wk.I) ∧ ((wk.Rl(m) ⊆ wj .Rl(n)))

A WSDL document of a composite service just providesthe information on how it gets composed when required.The structural definition of a composite service, providedin its intermediate representation form (see Section III.B),decides whether a composition would be treated as parallelor sequential.

Definition II.5 (Service-input tuple). A tuple 〈wi, Ip〉 is calledas a service-input tuple if and only if wi ∈ W and Ip ∈ wi.I .

Definition II.6 (Service-response tuple). A tuple 〈wi, Rq〉 iscalled as a service-response tuple if and only if wi ∈ W andRq ∈ wi.R.

A service-input tuple is possible for basic and compositeservices whereas service-response tuple is possible only forbasic services. A service-message tuple is a common namefor both service-input and service-response tuples. 〈wi,m〉 isa representation for service-message tuple.

Definition II.7 (Conditional successor). A conditional suc-cessor (�C) accepts the input in the form of service-inputtuple format and produces the output either in the form ofservice-input tuple 〈wi, Ip〉 or in the form of service-responsetuple 〈wi, Rq〉. Given a tuple 〈wi, Ip〉, 〈wj ,m〉 is a conditionalsuccessor of 〈wi, Ip〉 (written as: 〈wj ,m〉 ∈

(�C 〈wi, Ip〉

))

if and only if wj ∈(� wi

)and m ∈ wi.Rl(Ip).

Let 〈wi,mp〉 and 〈wj ,mq〉 be two service-message tuplessuch that their composition (〈wi,mp〉⊕ 〈wi,mq〉) is possible.Then, ‘〈wi,mp〉 ⊕ 〈wj ,mq〉’ represents a composition chainthat could participate in further composition processes as asingle service. However, only the end elements of a com-position chain participates in further composition process. Ifa service-message tuple 〈wi,mp〉 composes with 〈wj ,mq〉

and 〈wr,mr〉 in parallel, it is represented by the means oftwo separate composition chains: 〈wi,mp〉 ⊕ 〈wj ,mq〉 and〈wi,mp〉⊕〈wk,mr〉. A composition chain grows further withthe attachment of other composable service-message tuples.However, a composition with an empty service results as atuple itself without any change (〈wi,mp〉 ⊕ ε = 〈wi,mp〉).The conditional successor for a tuple with an empty secondfield (input message is not specified) behaves as an absolutesuccessor, indicating that the service-message tuple can bereplaced with the service name only. A conditional successoroperator is a special case of restrictive successor operator(�R) representing that Domain(�R) = Domain(�) andRange(�R) ⊆ Range(�C). We define a restrictive successoroperator as follows.

Definition II.8 (Restrictive successor). Let 〈wi, Ip〉 ⊕〈wj , Iq〉⊕· · ·⊕〈wn, Is〉 be a composition chain and 〈wx, Ir〉 bea service-input tuple, then 〈wx, Ir〉 is a restrictive successor of〈wi, Ip〉⊕〈wj , Iq〉⊕· · ·⊕〈wn, Is〉 if and only if the followingtwo conditions hold.

1) 〈wx, Ir〉 is a conditional successor of the compositionchain 〈wi, Ip〉 ⊕ 〈wj , Iq〉 ⊕ · · · ⊕ 〈wn, Is〉 (written as〈wx, Ir〉 ∈

(�C 〈wi, Ip〉 ⊕ 〈wj , Iq〉 ⊕ · · · ⊕ 〈wn, Is〉

)).

2) 〈wx, Ir〉 is not a constituent member of the compositionchain 〈wi, Ip〉 ⊕ 〈wj , Iq〉 ⊕ · · · ⊕ 〈wn, Is〉 (written as〈wx, Ir〉 /∈ {〈wi, Ip〉, 〈wj , Iq〉, · · · , 〈wn, Is〉}).

The empty first field or second field in the input argumentof a restrictive successor is a special case and is treated asfollows:

�R 〈wi,−〉 ≡ �R {〈wi, I1〉, 〈wi, I2〉, · · · , 〈wi, Ip〉} (1)

where {I1, I2, · · · , Ip} = wi.I

�R 〈−, Ip〉 ≡ �R {〈wi, Ip〉, 〈wj , Ip〉, · · · , 〈wl, Ip〉} (2)

where {wi, wj , · · · , wl} ∈ W such that Ip ∈wi.I, wj .I, · · · , wl.I

Let ‘~’ be a symbol to represent recursive composition.To define recursive composition, we use restrictive successoroperator (�R) and composition operator (⊕) as supplementaryoperators (defined earlier in this section).

Definition II.9 (Recursive composition). Recursive composi-tion for a given service-input tuple 〈wi, Ip〉, where Ip ∈ wi isdefined as follows:

~〈wi, Ip〉 ,

{〈wi, Ip〉 ; if �R 〈wi, Ip〉 = ∅~{〈wi, Ip〉 ⊕ (�R 〈wi, Ip〉)

}; otherwise

(3)

Successor operator and recursive composition operator arehaving equal precedence. They possess higher precedence overthe composition operator.

Various flavors of Web service algebras [18], [17], [30],[31], [32] are available in the literature. The RCA differs fromthese algebras in consideration of recursive composition andits applicability to the well-known problem of Web serviceinteraction verification.

4

III. RECURSIVE COMPOSITION INTERACTION GRAPH(RCIG)

A. RCIG formation

Given a set of Web services W and an input argument suchas a message 〈Ip〉 or a service 〈wi〉 or a service-messagetuple 〈wi, Ip〉, the application of recursive composition forms agraph. We call it as a recursive composition interaction graph(RCIG) (see definition III.1). Algorithms for generating RCIGare given in Appendix A.

Definition III.1 (Recursive composition interaction graph(RCIG)). A RCIG is a tuple 〈V,E〉 where V is a set of nodes(either in service-input format or in service-response format)and E is a set of directed edges. An edge connects a node witha set of nodes (E : V → 2V ) such that following conditionholdsE(vi) = U,where vi ∈ V and U ⊆ V iff ∀vj ∈ U : vj ∈ �R(vi)

In the literature, interactions among services are defined andhandled in many ways [33], [12], [10] based on their modelingapproaches. In our context, we use the term Trace to name aninteraction pattern from the RCIG, and we represent it usingthe letter T . We formally define a trace as follows:

Definition III.2 (Trace). A trace T is a RCIG such that anode in the graph can have only one child utmost.

Let W be a set of Web services, wi ∈ W , and Twi ={T0, T1, · · · , Tn} represents a set which contains all the tracesgenerated by applying the recursive composition on wi. Simi-larly, TIp represents a set that contains all the traces generatedby applying the recursive composition on Ip. For the sake ofconvenience, we always extract traces from left to right in aRCIG. We follow the concept of trace, mainly, while studyingbehavioral equivalence of services.Subtrace. Let Ti and Tj be two traces. Let Ni and Nj bethe set of nodes in Ti and Tj , respectively. Let Ri and Rj bethe relations that map a node to another in Ti and Tj . Then,Tj is a subtrace of Ti (represented as Tj ⊂ Ti) if and only ifNj ⊂ Ni and Rj ⊂ Ri.

There are two types of traces based on the terminationcondition as follows:

Definition III.3 (Open Trace). An open trace is a trace thatends with a service-input tuple.

Definition III.4 (Closed Trace). A closed trace is a trace thatends with a service-response tuple.

For a given set of Web servicesW and an input message Ip,if TIp consists an open trace, it implies that adequate candidateservices are not available inW to compute all the possibilities.Since an open trace is a faulty trace, it is not desirable inservice composition scenarios.

There are three types of RCIG based on its formation style:service-driven, message-driven, and service-message driven. Ina service-driven RCIG, a service name is the generator ofthe graph. The root node consists of the service name and ispreceded by service-message tuples. For instance, let wi bea service name that forms a root node. Then, all immediate

nodes are of the form 〈wi, Ip〉, where Ip ∈ wi.I . In a message-driven RCIG, a message name (say, Ip) is the generator of thegraph. The root node consists of the message name and ispreceded by service-message tuples such that all immediatenodes (after root node) are restrictive successor of the Ip.In a service-message driven RCIG, a service-message tuple(say, 〈wi, Ip〉) is the generator of the graph. The root nodeconsists of the service-message tuple and is preceded byservice-message tuples such that all immediate nodes (afterroot node) are restrictive successor of the previous node.

B. Implementation of the RCIG

A WSDL document is the description of a Web ser-vice, written in XML format. A WSDL document consistsof the following elements: 〈definition〉, 〈types〉, 〈message〉,〈operation〉, 〈portType〉, 〈binding〉, 〈port〉, and 〈service〉. List-ing 1 depicts an abstract structural view of a WSDL document.The 〈portType〉 element combines multiple message elementsto form a complete one-way or round-trip operation. WSDLsupports four basic patterns of operations as: one-way, request-response, solicit-response, and notification. In order to supportverification of completely automated and dynamic Web servicecomposition, we use an intermediate representation (see List-ing 2) that is derived from an existing WSDL structure withthe following minor modifications in the 〈operation〉 elementof the WSDL document. Except the 〈operation〉 element, theremaining structure of WSDL is not altered.

Basic and composite services differ in their actions thatthey take upon reception of an input message to fulfillthe request. A basic service computes the output itself foran input message whereas a composite service relies on others.

Listing 1. WSDL Document Structure1 <p o r t T y p e name . . .>∗2 <o p e r a t i o n name . . .>3 <i n p u t message . . . />4 <o u t p u t message . . . />5 < / o p e r a t i o n>6 < / p o r t T y p e>

Listing 2. Intermediate Representation1 <p o r t T y p e name . . .>∗2 <o p e r a t i o n name . . .>3 <i n p u t message . . . />4 <f o r w a r d . . .>∗5 <s e q u e n t i a l . . . />∗6 < / f o r w a r d>7 <r e s p o n s e message . . . />8 < / o p e r a t i o n>9 < / p o r t T y p e>

In the case of a basic service, we adopt the similar structureof a classical WSDL document. However, instead of input-output set of messages, we propose the input-response setof messages in the 〈operation〉 element. In the case of acomposite service, within the 〈operation〉 element, an 〈 input〉element is preceded by a number of 〈forward〉 elementsand each 〈forward〉 element consists 〈sequential〉 elements.A 〈sequential〉 element is a text element that consists amessage that has to be forwarded to other services. All〈forward〉 elements corresponding to an input message, gettriggered in parallel and all sequential messages within a

5

〈forward〉 element get triggered successively in the orderin which they appear. 〈forward〉 element is not a textelement whereas 〈input〉 and 〈sequential〉 elements are textelements. The purpose of a forward message is to discriminatestreams of parallel flows from each other. Throughout thepaper, in our examples, wherever it is required to providea WSDL document for a service, we provide a fraction(only 〈portType〉 element) of that WSDL document toavoid unnecessary complex details and to support betterunderstandability.

Now, rest of this subsection presents an implementation(using Java) for formation of recursive composition interactiongraph (RCIG) by means of a classical travel agency scenario.Let W = TA, HB, FB, CB, EQ, and Null be a finite setof Web services. TA, HB, FB, CB, EQ, and Null are theabbreviations for services: travel agency, hotel booking, flightbooking, car booking, Enquiry and Null, respectively. TA is acomposite service, FB, HB, CB, and EQ are basic services,and Null is an empty service. Simplified and fractional WSDLdocuments (in the proposed format) for these Web services aregiven in Appendix B.

Let W and 〈Travel Booking〉 be the input argumentsto construct a RCIG. The RCIG (the partial depiction ofthe RCIG is provided as Fig. 1 and the complete depictionof the RCIG is provided in Appendix C) is generated byusing RCIGFORMATION algorithm (given in AppendixA) and shows all the possible interaction patterns in Wtriggered by the input message Travel Booking. Thealgorithm creates a root node (s0) labeled with the inputargument Travel Booking. Further, it searches existenceof the input argument Travel Booking in the input set ofavailable services and Travel Booking is found only inTA. On reception of this input, TA initiates three paralleltraces considering s1 as the parent node. These three tracesbegin with forwarding three messages: Flight Avail?,City Name, and Car Avail?. These traces proceed furtherand stop when they map to a service-response tuple. Once aservice-response tuple appears in a trace control goes back toTA and next sequential message get triggered. For instance,s4 is a service-response tuple that comes in the path of traceT0. Once s4 is encountered, control goes back to TA andtriggers next sequential message (Flight Book). In this way,it proceeds until all sequential messages from all the forwardelements in TA get exhausted.

IV. WEB SERVICE INTERACTION SPECIFICATION ANDVERIFICATION

The requirements of Web service interaction are classi-fied into functional and non-functional [9]. A functional re-quirement describes the behavior of the system as it relatesto the system’s functionality. A non-functional requirementelaborates a performance characteristic of the system suchas efficiency, privacy, maintainability, etc. In this paper, weexclusively focus on functional requirements. Our proposedverification technique verifies both aspects of functional re-quirements: safety properties (describe what must not happen)and liveness properties (describe what must happen) [34], [35].

TA, Travel_Booking

TA, Flight_Avail?

TA, Hotel_Avail?

TA, Car_Avail?

HB, Hotel_Avail?

FB, Flight_Avail?

HB, Hotel_Yes HB, Hotel_No

HB, Hotel_Book

FB, Flight_Yes FB, Flight_No

FB, Flight_Book

CB, Car_Yes CB, Car_No

CB, Car_Book

CB, Car_Avail?

FB, BusinessClass FB, EconomyClassFB, Flight_Not_Booked

HB, 5Star HB, 4Star HB, Hotel_Not_Booked

CB, Car_Booked CB, Car_Not_Booked

TA, Hotel_Avail?

HB, Hotel_Avail?

HB, Hotel_Yes HB, Hotel_No

HB, Hotel_Book

HB, 5Star HB, 4Star HB, Hotel_Not_Booked

S0

S2

S3

S4

S5

S6

S7

S8

S9

S10

S11

S12

S13 S14S15

S16

S17 S18

S19

S20

S21

S22

S23

S24 S25 S26

S30

S27

S28

S29

TA, City_Name

EQ, Weather_Condition

Travel_Booking

S1

S31

S32

S33

S34

TA, Car_Book

EQ, City_Name

S35

S36

TA, Flight_Book

TA, Hotel_Book TA, Hotel_Book

S37 S38

S39

Fig. 1. A partial RCIG generated by the input Travel Booking

Throughout the paper, M represents an interpretation modeland si, where i ∈ N, represents ith node or ith state(depending on the context) in M . The logical statementM, s0 |= φ infers that a state s0 in the model M satisfiesthe requirement specification φ. Messages with similar namecan exist in several Web services. While referring a messagein particular, a service name is used as prefix and to refer amessage in general, a message name itself appears withoutany prefix. Specifications are written using both the schemesas per requirement. For instance, let φ = wi.mp → mq bea specification formula. In φ, wi.mp refers a message mp inwi and mq is a message name in general. The specificationformula φ infers that if mp is triggered from the service withen mq will be triggered eventually.

A. Model for interpretation of semantics of specificationformula

The proposed recursive composition interaction graph(RCIG) is employed as a model for interpreting requirementspecifications formula. The interaction between two Web ser-vices can be anticipated very easily with the help of RCIG asit explores all possible interactions. A RCIG is a graph andeach branch from the root to a terminal node is consideredas a trace. An interaction pattern evolves with time. However,time ordering cannot be established between two nodes thatbelong to two different traces in a RCIG.

In the context of Web service interaction, the communica-tion messages are considered as propositions [10]. The truthvalue of a message infers whether the message is communi-cated or not. For instance, if wi.Ip = >, then the Web servicewi has communicated the message Ip, otherwise not. In atrace, once truth value for a message is set to “true”, it cannotbe altered to “false” at a subsequent time step.

6

B. Specification language

In order to specify the requirements regarding Web servicesinteractions, we propose a specification language recursivecomposition specification language (RCSL).

Definition IV.1 (Syntax of RCSL). RCSL has the followingsyntax given in Backus-Naur form:φ ::= > | ⊥ | p | (¬φ) | (φ ∧ φ) | (φ ∨ φ) | (φ → φ) | (φ ∪φ) | Aφ | Eφ

where p is any propositional atom from some set of atomsand each occurrence of φ to the right of ::= stands for anyalready constructed formula. > and ⊥ are well formed formu-las “the tautology” and “the falsum” respectively. ¬, ∧, ∨,and → are sentential connectives and be used in their usualmeaning. ∪ is a temporal modality called until. A and E arepath quantifiers. A stands for all paths and E stands for atleast one path.

Negation symbol ‘¬’ binds most tightly. Next in the ordercomes ∪ that binds more tightly than ∨ and ∧, and the lattertwo bind more tightly than →. Though RCSL consists of theconstructs from both LTL and CTL, neither RCSL ⊆ LTLnor RCSL ⊆ CTL. Let M = (S,→, L) be a RCSL model,T = s0, · · · , sn be a trace in M , and n(T ) is a collection ofall nodes in a trace T . si |= p means that a node si consistsof the proposition p. The satisfaction relation |= (explainingwhether T satisfies a RCSL formula) is defined as follows:

1) T |= > (> is always true).2) T 2 ⊥ (⊥ is always false).3) T |= p iff ∃si ∈ n(T ) : si |= p4) T |= ¬φ iff T 2 φ5) T |= φ1 ∧ φ2 iff T |= φ1 and T |= φ26) T |= φ1 ∨ φ2 iff T |= φ1 or T |= φ27) T |= φ1 → φ2 iff si, sj ∈ n(T ) : (si |= φ1 ∧ sj |=

φ2) ∧ (i < j)8) T |= φ1 ∪ φ2 iff φ1 is a negative literal of the form ¬p

and((si, sj ∈ n(T ) : si |= p) ∧ (sj |= φ2)

)=⇒ i > j

9) T |= Aφ1 iff Ti |= φ1 for all i ≥ 110) T |= Eφ1 iff Ti |= φ1 there exists i ≥ 1

Difference between temporal logic and RCSL. Temporal logicis a formal system for reasoning about time whereas RCSLreasons about possible Web service interaction patterns andverifies whether an interaction pattern is possible to be formedor not with the available services. There is a fundamentaldifference in motivation for utilizing any of them. The speci-fication requirements are the key factors to opt a language. Inlinear temporal logic, there is an implicit universal quantifica-tion over the computations - the paths in state space. RCSLuses both universal and existential quantifiers explicitly, butdoes not use temporal operators X (next), F (finally), and G(globally). RCSL does not require X , F , and G because itsinterpretation model RCIG is a finite and acyclic graph whereno proposition can be false at later stage once it becomes true.In branching-time temporal logic, universal and existentialquantifiers are used as explicit prefixes to the temporaloperators and use combination of temporal operators withquantifiers such as AF , AG, etc., whereas RCSL does notrequire the combination of temporal operators with quantifiers.

C. Verification technique

Algorithm 1 initiates the verification process. It accepts atuple as an input argument that consists of a set of Webservices (say,W) and a requirement specification formula (say,φ) written in RCSL. W is an online Web service repositoryavailable on a specific url address and φ is provided by averifier. Once φ is available, Algorithm 1 calls Algorithm2 by passing φ as an argument. Algorithm 2 parses φ, andcorrespondingly it generates an abstract syntax tree (writtenas Pφ) if given formula is free from syntax errors. Word tokenin Algorithm 2 represents a sequence of characters that canbe treated as a single logical entity. Typical tokens are: 1)identifiers 2) keywords 3) operators 4) special symbols, and5) constants.

Algorithm 1 INTERACTIONVERIFICATION(W, φ)Input: W (a set of Web services), φ (a specification formula)Output: W � φ or W 2 φ

1: Pφ ← REQSPECPARSING(φ) . calling Algorithm 22: FLAG← TRUE3: Integer i, j, p, t4: wj .I : set of all input messages in wj5: Aφ : set of atoms in φ6: for all αi ∈ Aφ do7: for all wj ∈ W do8: if αi ∈ wj .I then9: Ip ← αi

10: M ←RCIGFORMATION (W, Ip) . M is a model formed byRCIGFORMATION algorithm

11: for all trace Tt ∈M do12: FLAG← INTERPRETATION(Pφ, Tt) . calling Algorithm 313: end for14: end if15: end for16: end for17: if FLAG = TRUE then18: W � φ . available services satisfy the specification formula19: else20: W 2 φ . available services do not satisfy the specification formula21: end if

Further, Algorithm 1 collects all the atoms from φ in theset Aφ and observes whether an atom (say, αi) belongs to aninput set of a service from the set W . If αi is found in theinput set of a service, Algorithm 1 invokes RCIGFORMATIONalgorithm by supplying argumentsW and Ip. After completingthe processing of the input arguments, RCIGFORMATIONalgorithm provides a RCIG model M rooted at Ip. Then,Algorithm 1 extract the traces Tt (t ∈ N) from the modelM one by one and calls Algorithm 3 for further processingby passing the arguments Pφ and Tt. Then, Algorithm 3interprets Pφ on the provided trace Tt and results as TRUEor FALSE, based on its computation. In case, if the resultis TRUE, trace Tt is a witness example, otherwise traceTt is a counter example. Algorithm 3 decomposes the ASTPφ in subtrees recursively and divide also the trace Tt re-cursively corresponding to subtrees until unit-level-subtrees(smallest non-trivial subtrees) are achieved. Now, the functionPInterpretation(subtree, trace) in Algorithm 3 interpretsthe unit-level-subtrees over corresponding dividend of thetrace. Once these subtrees are satisfied in the trace, satisfactionof the higher level subtrees will be investigated in bottom totop fashion.

Example IV.1. Let the RCIG depicted in Fig. 1 be an inter-

7

Algorithm 2 REQSPECPARSING(φ)

Input: φ: a requirement specificationformula written in RCSLOutput: Pφ: an abstract syntax treefor φ

1: int i = 02: String Idi ← NULL3: String Token← NULL4: String nextToken← NULL5: String prevToken← NULL6: for all Token ∈ φ do7: TokenSet← Token8: end for9: Token← TokenSet(i)

10: while |TokenSet| 6= 1 ANDToken 6= Id do

11: if Token =‘¬’ then12: if nextToken =‘(’ then13: PARENTHESIS(nextToken)14: else15: Idi ← nextToken16: Replace nextToken

with Idi in φ17: end if18: Replace ‘¬Idi’ with

‘Idi+1’ in φ19: i← i+ 120: else if Token =‘(’ then21: while nextToken =‘(’ do22: Token← nextToken23: end while24: PARENTHESIS(Token)25: else if Token =‘∪’ then26: FUNC(Token)

27: else if Token =‘∨’ then28: FUNC(Token)29: else if Token =‘∧’ then30: FUNC(Token)31: else if Token =‘→’ then32: FUNC(Token)33: else if Token =‘p’ then . p is

a proposition34: Idi ← ‘p’35: Replace ‘p’ with ‘Idi’ in φ36: i← i+ 137: else if Token = Id then38: Skip . move to next token39: end if40: end while41: function PARENTHESIS(V alue)42: String Token← V alue43: repeat44: φTemp ← Token45: Token← nextToken46: until Token 6=‘)’47: φTemp ← Token48: Replace φTemp with Idi in φ49: i← i+ 150: end function51: function FUNC(Token)52: Idi ← prevToken Token

nextToken53: Replace prevToken Token

nextToken with ‘Idi’ in φ54: i← i+ 155: end function56: AST (Idi−1) . print the abstract

syntax tree for φ

pretation model M and φ1 (see Equation 4) be a requirementspecification formula which, formally, states that in all thetraces, if flight is available and booking is requested, theneither flight must be booked or hotel must not be booked untilflight is booked.

φ1 = A((Flight Y es∧Flight Book)→ (Flight Booked

∨ (¬Hotel Booked ∪ (Flight Booked)))) (4)

-->

Flight_Yes

V

U

!

Flight_Booked

Flight_Booked

Flight_Book

/\

Hotel_Booked

Fig. 2. AST for the specification formula φ1 (Eqn. 4)

Now, a verifier has to verify the model M against theformula φ1. According to the verification technique, traces inmodel M are considered one by one for verification. Let usconsider that a trace Tt (shown in Fig. 3) from the model M(Tt = s0, · · · , s21) has to be verified against φ1. The AST(Pφ1

) for φ1 is given in Fig. 2.

TA, Flight_Avail? FB, Flight_Avail? FB, Flight_Yes TA, Flight_Book FB, EconomyClass TA, Hotel_Avail? HB, 5StarTravel_Booking

S0 S2 S3 S4 S5 S18 S19 S24

Fig. 3. A trace from the RCIG in Fig. 1

According to Algorithm 1, Pφ1gets recursively decomposed

in its respective subtrees recursively until unit-level-subtreesare achieved (see Fig. 4) (further no decomposition is possi-ble). Initially, Pφ1 is decomposed into subtrees: ST1 and ST2.ST1 is decomposed into ST11 and ST12 that are unit-level-subtrees. Therefore, they cannot be decomposed further. ST2 isfurther decomposed into: ST21 and ST22 and so on. Once thegiven formula φ is completely decomposed in its constituentunit-level-subtrees, decomposition process stops.

-->

Flight_Yes

V

U

!

Flight_Booked

Flight_Booked

Flight_Book

/\

Hotel_Booked

ST2

ST21

ST22

ST1

ST11 ST12

ST221

ST222ST2211

Fig. 4. Subtree decomposition of the AST given in Fig. 2

Now, ST1 → ST2 will be interpreted on the trace Tt.The subtree ST1 represents a subformula Flight Y es ∧Flight Book that is satisfied in the subtrace s0, · · · , s5.Then, we divide the trace Tt into subtraces: s0, · · · , s6 ands7, · · · , s24. After this, the subtree ST2 ::= ST21 ∨ ST22(Flight Booked∨(¬Hotel Booked∪Flight Booked)) getsinterpreted over subtrace s7, · · · , s24. Since the subtrace satis-fies ST21, ST2 ::= ST21∨ ST22 becomes satisfied. Conse-quently, the requirement specification φ1 = (Flight Y es ∧Flight Book) → (Flight Booked ∨ (¬Hotel Booked ∪Flight Booked)) is satisfied in the trace Tt. In the similarway, we check satisfiability of φ1 over every trace in the modelM and find satisfied. Hence, M |= φ1

V. IMPLEMENTATION AND ANALYSIS

A. Implementation

In this subsection, we describe a prototype implementationof our proposed approach for verifying the specificationswritten in the RCSL against the set of available Web services.The implementation and experiments conducted have shownthat the ideas proposed in this paper are realizable usingexisting technologies. Fig. 5 shows the high-level architectureof our prototype system, which has been implemented inJava and is based on technologies such as XML, SOAP, andWSDL. Fig. 5 consists of four modules namely, specificationformula parsing, RCIG and trace generation, intermediate formconversion, and semantical interpretation. All modules aredetailed as follows:

8

RCIG Generator(Algorithm 1 & 2)

Discovery of Relevant ServicesBased on Specification

Formulas (Alg. 1)

Abstract Syntax Tree Generator (Alg. 4)

specification

formulas

(written in

RCSL)

AST

set of

traces

RCIGs

witness examples

Specification formula parsing

Trace Extractor(using depth-first

traversal)

discovered related services

Verifier

Yes No

counter examples

SubtreeDecomposition(Algorithm 4)

Semantic Interpretion of a Unit-level-subtree on a Trace(Algorithm 5)

unit-level

parse trees

Graphical User Interface for Web Service Interaction Verification

RequirementsSpecifications

intermediaterepresentationof services in XML

Online Web Service Repository (collection of WSDL documents for all available services)

XML Parser and Intermediate

Form Converter

Optimizer (removes redundant

traces)

WSDL documents

Semantical interpretation RCIG and trace generator

Intermediate form conversion

Lexical Analyzer

formula

Optimized

RCIGsVerification (Algorithm 3)

Fig. 5. High-level architecture of implementation

1) Specification formula parsing: This module receives arequirement specification formula from the verifier andprocesses it using Algorithm 2. Syntax checking isperformed at first. Thereafter, it makes an abstract syntaxtree (AST) out of the given formula. Generated ASTis decomposed into its constituent subtrees until unit-level-subtrees are achieved. Finally, unit-level-subtreesare provided to the module semantical interpretation.

2) Intermediate form conversion: This module also re-ceives the specification formula and discovers the setof relevant services from the available ones. Then, itretrieves their WSDL documents and makes duplicate(local) copy of WSDL documents and modifies themby adding two tags: sequential and parallel. ModifiedWSDL documents work as intermediate representationand are provided to the module RCIG and trace gener-ator for further processing.

3) RCIG and trace generation: This module receives the

set of modified WSDL documents along with an input(a service-input tuple or a message name or a servicename). The input is provided by Algorithm 1. Once aninput and the set of modified WSDL documents areavailable, it forms a RCIG using the algorithm men-tioned in Appendix A. Further, it optimizes the generatedRCIG by removing redundant subtraces and supplies thetraces to the module semantical interpretation.

4) Semantical interpretation: This module verifies whethera given trace interprets the semantics of a given subtree(subformula). If the trace interprets the semantics, themodule produces the witness example, otherwise, themodule produces the counter example.

In addition to automation, our implementation also supportsdynamic availability of services. A Web service verificationframework where the verifier has to decide the participantservices in advance (with or before specifying the requirement)does not support dynamic availability of services. However, in

9

Algorithm 3 INTERPRETATION(Pφ, T )

Input: Pφ (parse tree) and T (trace)Output: TRUE or FALSE

1: Root← Root(Pφ)2: LST ← LeftSubTree(Pφ)3: RST ← RightSubTree(Pφ)4: if Root /∈ {¬,∧,∨,→,∪} then5: if PINTERPRETATION(Root, T ) =TRUE then

6: Return TRUE7: else8: Return FALSE9: end if

10: else if Root = ‘¬’ then11: if PINTERPRETATION(LST, T )

= TRUE then12: Return FALSE13: else14: Return TRUE15: end if16: else if Root = ‘∧’ then17: if INTERPRETATION (LST, T )

= TRUE AND INTERPRETATION(RST, T ) = TRUE then

18: Return TRUE19: else20: Return FALSE21: end if22: else if Root = ‘∨’ then23: if INTERPRETATION (LST, T )

= TRUE OR INTERPRETATION(RST, T ) = TRUE then

24: Return TRUE25: else26: Return FALSE27: end if28: else if Root = ‘→’ then29: FLAG← FALSE30: Temp← ∅31: TTemp ← ∅32: for all node n ∈ T do33: Temp · n .

Concatenating n to the existingsequence of nodes in Temp

34: if INTERPRETATION(LST, n) = TRUE then

35: FLAG← TRUE36: BREAK

37: end if38: end for39: TTemp ← {T − Temp}40: if INTERPRETATION

(RST, TTemp) = TRUE then41: Return TRUE42: else if FLAG =

FALSE AND INTERPRETATION(RST, TTemp) = FALSE then

43: Return TRUE44: else45: Return FALSE46: end if47: else if Root = ‘∪’ then48: FLAG← FALSE49: Temp← ∅50: for all node n ∈ T do51: Temp · n52: if INTERPRETATION (LST ′,

Temp) = FALSE then53: FLAG← FALSE54: BREAK55: end if56: end for57: if FLAG 6= FALSE then58: Return FALSE59: else if INTERPRETATION (RST ,

Temp) = TRUE then60: Return FALSE61: else62: Return TRUE63: end if64: end if65: function PINTERPRETATION(p,T)66: FLAG← FALSE67: for all node n ∈ T do68: if p ∈ L(n) then . L(n)

means label of node n69: FLAG← TRUE70: BREAK71: end if72: end for73: if FLAG = TRUE then74: Return TRUE75: else76: Return FALSE77: end if78: end function

our approach, a specification formula can be written with orwithout explicitly mentioning the participant service names. Inthe case, if service names are not explicit, relevant services arediscovered based on the propositions in the formula. Initially,if required, the verifier has to specify only the addresses oflocal or global service repositories. Later, while verification,our implementation discovers relevant services and checkscurrent availability of services each time verification queryis submitted. In other words, our implementation periodicallychecks the availability of the services in the given online Webservice repositories. If any change occurs in availability at alater stage (for instance, during realization of a compositionplan), the plan will be updated with the change and updatedplan will be shown to the user.

Also, our implementation features a user interface thatsupports a wide range of features such as editing and trackingof the modeled system, writing requirements specificationsin RCSL, adding new services in repository by specifyingtheir addresses, checking syntax, and starting verification.Furthermore, our proposed verification framework is fullycapable to verify other systems that behave similarly to the

Web service system (such as multi-agent system), providedthat their system description is in desired XML format andrequirement specifications are written in the RCSL.

B. Performance Analysis of RCIG

The order of a graph (the total number of nodes in a graph(|G(V )|)) generated by a technique is an important criteriato determine the feasibility for real world implementability ofa technique. The computational resources such as time andspace are directly proportional to the number of nodes. In thissection, we analyze how the cardinality of forward, sequential,and response messages in services affect the order of a RCIG.

1) Experimental SetupLet us consider a set of three services (W := wf , ws, wr),

where wf and ws are composite services and wr is a basicservice. All three services accept only one input message:Hotel Avail. The composite services (wf and ws) forwardthe input message to other services, whereas, the basic ser-vice (wr), upon reception of this message, replies with theavailable hotel booking options. Initially, each service consistsof only one output message (“output message” representsto 〈forward〉, 〈sequential〉, and 〈response〉 elements). Asper the requirement of experiment, we gradually increase thenumber of forward, sequential, and response messages in theservices. At any stage of experiment, all output messages inwf are parallel to each other, all output messages in ws aresequential to each other, and all output messages in wr areonly response messages. We assume that wf can invoke onlyws and ws can invoke only wr. Since wr is a basic service,it cannot invoke any service. This assumption facilitates uswith a hierarchical invocation system of services that preventsredundancy while performing recursive composition out of wf ,ws, and wr. All observations are taken by providing the input〈wf , Hotel Avail〉 to the RCIG construction process. Thenumber of nodes are counted for the unfolded form of theRCIG without applying any heuristic to reduce the number ofnodes.

2) Experimental EvaluationThere are three types of elements in the candidate ser-

vices: 〈forward〉, 〈sequential〉, and 〈response〉. Observationsare taken for the total number of nodes by increasing anelement type. In order to support symmetrical growth, weassume that a 〈forward〉 element can be increased only inwf , a 〈sequential〉 element can be increased only in ws,and a 〈response〉 element can be increased only in wr. Theminimum threshold for the count of all element types is oneand maximum threshold is six. The maximum threshold isset to six, that is sufficiently large to capture and observe thepatterns of the growth of order of the RCIG. For taking theobservations, we increase the count for an element type whilekeeping the count for other element types as constant at apre-specified value.

Following are the three sets of observations correspondingto the increment of response elements, sequential elements,and forward elements respectively. Three keywords are usedin the observation tables: Res, Seq, and Fwd. These keywordsstand for 〈response〉, 〈sequential〉, and 〈forward〉 elements

10

Messages # Nodes Messages # Nodes1Res 1Seq 1Fwd 5 1Res 4Seq 4Fwd 502Res 1Seq 1Fwd 6 2Res 4Seq 4Fwd 2423Res 1Seq 1Fwd 7 3Res 4Seq 4Fwd 8024Res 1Seq 1Fwd 8 4Res 4Seq 4Fwd 20425Res 1Seq 1Fwd 9 5Res 4Seq 4Fwd 43706Res 1Seq 1Fwd 10 6Res 4Seq 4Fwd 8290

1Res 2Seq 2Fwd 14 1Res 5Seq 5Fwd 772Res 2Seq 2Fwd 26 2Res 5Seq 5Fwd 6223Res 2Seq 2Fwd 42 3Res 5Seq 5Fwd 30274Res 2Seq 2Fwd 62 4Res 5Seq 5Fwd 102315Res 2Seq 2Fwd 86 5Res 5Seq 5Fwd 245246Res 2Seq 2Fwd 114 6Res 5Seq 5Fwd 62202

1Res 3Seq 3Fwd 29 1Res 6Seq 6Fwd 1102Res 3Seq 3Fwd 86 2Res 6Seq 6Fwd 15143Res 3Seq 3Fwd 197 3Res 6Seq 6Fwd 109224Res 3Seq 3Fwd 380 4Res 6Seq 6Fwd 491425Res 3Seq 3Fwd 653 5Res 6Seq 6Fwd 1640546Res 3Seq 3Fwd 1034 6Res 6Seq 6Fwd 447890

TABLE IEFFECT OF INCREASING RESPONSE MESSAGES ON THE ORDER OF THE

RCIG

respectively. A number that precedes an element keywordis the count for that element in the respective service. Forinstance, ‘4Res 5Seq 6Fwd’ indicates that there are fourresponse elements in wr, five sequential elements in ws,and six forward elements in wf . Table I depicts the variousobservations taken for total number of nodes with respectto the increment in 〈forward〉, 〈sequential〉, and 〈response〉elements.

Effect of increasing response messages on the order ofthe RCIG: From Table I, we extract the various observationstaken for total number of nodes with respect to the incrementin 〈response〉 elements while the count of 〈forward〉 and〈sequential〉 elements are kept constant at the values 1, 2, 3, 4,5, and 6. Based on the extracted values, Fig. 6 (split into twoparts for better visibility) depicts six curves namely Seq1Fwd1,Seq2fwd2, Seq3Fwd3, Seq4Fwd4, Seq5Fwd5, and Seq6Fwd6.Nature of the curves in Fig. 6 are linear and polynomial.Seq1Fwd1 is a line (y = x+4). Seq2Fwd2 is a polynomial ofdegree 2; Seq3Fwd3 and Seq4Fwd4 are polynomials of degree3; Seq5Fwd5 and Seq6Fwd6 are polynomials of degree 4.

Effect of increasing sequential messages on the order ofthe RCIG: From Table I, we extract the various observationstaken for total number of nodes with respect to the incrementin 〈sequential〉 elements while forward and response elementsare kept constant at the values 1, 2, 3, 4, 5, and 6. Basedon the extracted values, Fig. 7 depicts six curves namelyRes1Fwd1, Res2Fwd2, Res3Fwd3, Res4Fwd4, Res5Fwd5,and Res6Fwd6. Nature of the curves in Fig. 7 are linear andpolynomial. Res1Fwd1 is a line (y = 3x+2). Res2Fwd2 andRes3Fwd3 are three degree polynomials. Curves Res4Fwd4and Res5Fwd5 are four degree polynomials. Res6Fwd6 is afive degree polynomial.

Effect of increasing forward messages on the order ofthe RCIG: From Table I, we extract the various observationstaken for total number of nodes with respect to the incrementin 〈forward〉 elements while sequential and response elementsare kept constant at the values 1, 2, 3, 4, 5, and 6. Based on theextracted values, Fig. 8 depicts six curves namely Res1Seq1,Res2Seq2, Res3Seq3, Res4Seq4, Res5Seq5, and Res6Seq6.Nature of the curves in Fig. 8 is linear.

● ● ● ● ● ●

1 2 3 4 5 6

020

040

060

080

010

00

Effect of Response Messages on the Order of the RCIG

No. of Response Messages

Ord

er o

f the

RC

IG

● Seq1Fwd1Seq2Fwd2Seq3Fwd3

1 2 3 4 5 6

0e+0

01e

+05

2e+0

53e

+05

4e+0

5

Effect of Response Messages on the Order of the RCIG

No. of Response Messages

Ord

er o

f the

RC

IG

Seq4Fwd4Seq5Fwd5Seq6Fwd6

Fig. 6. Effect of Increasing Response Messages on the Order of the RCIG

In the best case (when count of forward elements aregrowing), the growth of the order of RCIG is linear. In theaverage case (when count of response elements are growing),the growth of the order of RCIG is lower degree polynomial,and in the worst case (when count of sequential elements aregrowing), the order of RCIG is a higher degree polynomial.However, in many practical cases, it is a lower degree poly-nomial.

VI. DISCUSSION

In this section, we present discussion on similarity of RCIGwith a call graph of input/output WSDL, inclusion of sameservice more than once in a composition chain, and distancefrom the presented approach to a system useful in practice.

Similar to RCIG, in literature, several graphical modelsbased on input/output WSDL messages have been proposedfor capturing recursive composition of Web services. There aremainly two categories of those graphical models: call graphs[36] and graph-based planners [37]. However, we do not usethe said (existing recursive composition based) models becauseour requirements are different. We find many graphical models

11

● ● ● ● ● ●

1 2 3 4 5 6

010

0020

0030

0040

0050

00

Effect of Sequential Messages on the Order of the RCIG

No. of Sequential Messages

Ord

er o

f the

RC

IG● Res1Fwd1

Res2Fwd2Res3Fwd3

1 2 3 4 5 6

0e+0

01e

+05

2e+0

53e

+05

4e+0

5

Effect of Sequential Messages on the Order of the RCIG

No. of Sequential Messages

Ord

er o

f the

RC

IG

Res4Fwd4Res5Fwd5Res6Fwd6

Fig. 7. Effect of Increasing Sequential Messages on the Order of the RCIG

that are suitable for discovery and composition planning [38],[19], however, our main interest is in the verification process.Our focus is on interaction verification and we are generatinga RCIG based on the requirement specification given by averifier/user. One more difficulty with the available models isthat, by seeing WSDL file of a composite service, we are notable to find the sufficient details (i) how (sequentially or inparallel) a composite service is composed of its component/-constituent services, and (ii) the messages a composite serviceis sending to its component/constituent services. Unavailabilityof the said details hinders the real-time implementation ofautomatic composition and verification process. Moreover, anabstract graphical representation is not suitable to verify theconcrete requirement specification given by a user.

With our proposed modeling technique, it is possible toinclude a service in a composition chain more than once.However, it is not possible to include a service-input tuplemore than once in a composition chain. While forming acomposition chain, the proposed approach avoids composinga service-input tuple that has been already composed as a con-stituent service of the composition chain. If the same service-

● ● ● ● ● ●

1 2 3 4 5 6

010

020

030

040

0

Effect of Forward Elements on the Order of the RCIG

No. of Forward Elements

Ord

er o

f the

RC

IG

● Res1Seq1Res2Seq2Res3Seq3

1 2 3 4 5 6

0e+0

01e

+05

2e+0

53e

+05

4e+0

5

Effect of Forward Elements on the Order of the RCIG

No. of Forward Elements

Ord

er o

f the

RC

IG

Res4Seq4Res5Seq5Res6Seq6

Fig. 8. Effect of Increasing Forward Elements on the Order of the RCIG

input tuple be included in a composition chain more than once,then it can lead into an indirect deadlock. For instance, let usconsider a scenario where A invokes B for hotel booking,which invokes C for hotel booking, and C invokes A for hotelbooking. This scenario may lead into an indirect deadlock.Explanation is given as follows: A invokes B for hotel bookingcan be written as ‘〈A,Hotel Book〉 ⊕ 〈B,Hotel Book〉’.Further, B in ‘〈A,Hotel Book〉⊕〈B,Hotel Book〉’ invokesC for hotel booking that can be written as ‘〈A,Hotel Book〉⊕〈B,Hotel Book〉 ⊕ 〈C,Hotel Book〉’. Now, if C in-vokes A for hotel booking, it lead into an indirect dead-lock written as ‘〈A,Hotel Book〉 ⊕ 〈B,Hotel Book〉 ⊕〈C,Hotel Book〉, 〉 ⊕ 〈A,Hotel Book〉’. That is why theproposed approach does not allow including a service-inputtuple more than once in a composition chain.

Our proposed Web service interaction modeling and veri-fication technique consists of three steps: (i) given a set ofWeb services, modeling of the Web service interaction, (ii)writing a requirement specification for verification, and (iii)verification of the requirement specification against the model.Though we have implemented and demonstrated that all the

12

steps are working correctly, there is space for sophisticationof the technique from the practical perspective as follows.We perform I/O messages (mentioned in WSDL files) basedmatching to discover a composable service while creating acomposite service. However, matching I/O messages of WSDLfiles is very syntactic in nature and does not capture the servicelogic. Due to this fact, small variation in message syntax willmake look compatible services as incompatible. The similarkind of situation arise when one verifies whether a given traceinterprets the semantics of a given requirement specification.In order to address the said problem, as our future work,we plan to incorporate a vocabulary in service discovery andspecification formula interpretation process.

VII. RELATED WORK

Our proposition is completely focused on Web serviceinteraction modeling and verification. We compare our workwith most related works from the literature on modeling andverification of service interaction.

The problem of automatic Web service composition gen-eration is closely related to the problem of Goal-OrientedAction Planning (GOAP) in artificial intelligence (AI) [37],[39]. In literature, several AI planning based techniques for au-tomatic composition are available: STRIPS-based [39], PDDL-based [40], HTN-based [41], [42], etc. Though theoreticallypossible, they present a number of complexities in practicalimplementation, such as, generating and maintaining heavyamount of additional information (for instance, task libraryin [39]) hinders the automation process. We also use WSDL-based intermediate representation, however, in our approach,generation of the intermediate representation takes place au-tomatically at the back-end and a verifier need not to beconcerned about it. Recent AI planning based works, like [19]and [6], are better than previous proposals as they handledynamic availability of services and domain-dependency ofplanning in more efficient way. Zou et al. [6] focused onsearch time reduction when finding a composite service fromthe Web service repository. In order to achieve their goalthey converted the Web service repository into a planningdomain. This transformation reduces the response time andimproves the scalability of solving Web service compositionproblems. Kaldeli et al. [19] differed from other AI planningbased techniques in that they used state variables rather thanpredicates as the basic elements for describing the worlds (inmodeling phase). From the modeling perspective, we differfrom [19] as, in our approach, the worlds need not to bedefined or generated by the designer explicitly. Once thespecification formula is available, worlds in the interpretationmodel get generated automatically. Moreover, unlike to ourwork, verification aspect of Web service interaction is notdiscussed in [6], [19].

Another line of work [4], [43] investigated into recursivecomposition of Web services. To form a cost-effective com-posite service, Jaiswal et al. [4] used a recursive compositionbased model. The model proposed in [4] is suitable foroptimization, whereas our focus is interaction verification.Abrougui et al. [43] used recursive multi-agent systems to

support dynamism in Web service composition. Like previousone [4], this work also supports in finding a better compo-sition solution; their motive was not to verify an interactionspecification.

Application of model checking based techniques for verifi-cation of Web service interaction is not entirely new, but stillis in use because of its efficacy. Foster et al. [33] proposeda model-based technique to verify Web service compositionsrepresented in the form of BPEL. They modeled specificationsin the form of Message Sequence Charts (MSCs). Further,BPEL and MSCs were mechanically compiled into the finitestate process notation (FSP). Then, verification process takesplace between FSPs generated from BPEL and MSCs usingtrace equivalence phenomenon. Contrary to [33], Fu et al.[12] presented a Web service interaction verification schemebased on the centralized theme of conversation modeling. Theyspecified desired conversations of a Web service as a guardedautomaton. Their focus was on the asynchronous messagingand they made effort to relax the restrictions in the way ofdirect application of model checking. Walton [44] verifiedthe interaction among agents participating in multi-agent Webservice systems by proposing a Web service architectureand a lightweight protocol language. Further, he verified thespecification properties written in the proposed language usingmodel checking. Techniques presented in [33], [12], [44]were efficient, however, they did not deal with automationof verification process. Schlingloff et al. [45] presented anintegrated technique for modeling and automated verificationof Web service composition. Their modeling was based onPetri net and for correctness they employed model checkingtechnique with alternating temporal logics. Zheng et al. [46]presented a test case generation framework for BPEL usingmodel checkers SPIN and NuSMV. They modeled BPEL asWeb service automata (WSA) and on the basis of WSA theypresented their test case generation framework. Test cases wereused to verify whether the implementation of Web servicesmeet pre-specified BPEL behavior. Rossi [47] proposed amodel checking algorithm for adaptive service compositions.She employed a logic-based technique for verification ofsecurity and correctness properties using modal µ-calculus.Collectively, we differ from all the said model checking basedtechniques [33], [12], [44], [45], [46], [47] in that our verifi-cation technique employ possible trace-based phenomenon forverification instead of classical possible-world phenomenonand explicit system modeling (specifications of the systemprovided by the designer) is not required.

Further, as an improvement over the previous ones, recentmodel-checking based verification techniques [10], [48], [49]support automation to a great extent. Bentahar et al. [49]proposed a modeling and verification technique for compositeWeb services. Their modeling aspect is based on separation ofconcerns between operational and control behaviors (interac-tions among Web services) of Web services. Their verificationtechnique was model checking-based where they automaticallygenerated Kripke model out of the given operational behavior.Similarly, Sheng et al. [48] also proposed an automated serviceverification approach based on the operational and control be-haviors. The coordination of operational and control behaviors

13

at runtime was facilitated by conversational messages and theirproposed automated verification technique was based on sym-bolic model checking. Like [49] and [48], our proposition alsosupports the operational and control behaviors. Operationalbehaviors can be captured using the RCIG model and controlbehavior can be specified using RCSL. In addition to that, inour approach, once control behaviors are provided by a verifier,related operational models are discovered automatically. Raiet al. [11] proposed a set partition and trace based techniquefor Web service composition and its verification. However,unlike to our proposition, their focus was on the controlflow logic, not on the interaction between the services. ElKholy et al. [10] presented a framework to capture and verifythe interactions among multi-agent based Web services. Inorder to capture the interactions, they proposed and use aspecification language that use commitment modalities in theform of contractual obligations. Further, multi-agent com-mitment protocols regulated the interactions among servicesand engineered service compositions. Though their approachis efficient and incorporate commitment modalities, it cancapture the conversation between two agents only if participantagents are known in advance (does not support automation).Moreover, it does not capture recursive composition scenariosthat is done in our approach. Recently, a Petri net based formalmodel for verification of Web service composition [50] wasproposed. However, their goal was to verify the compliancenot the interaction.

VIII. CONCLUSIONS AND FUTURE WORK

In this paper, we present a recursive composition basedtechnique for modeling and verification of interactions amongWeb services. Given a set of Web services and an interactionspecification, our goal is to verify whether the specificationis being satisfied or not. We propose recursive compositioninteraction graph (RCIG) to model the interactions among Webservices, and recursive composition specification language(RCSL) to capture the specifications about service interactions.Further, we propose a verification technique based on theinterpretation of a requirement specification formula (writtenin RCSL) over a given interpretation model (represented as aRCIG). Recursive composition and the quest for automatedcomposition are two important challenges that make Webservice interaction verification process difficult and differentfrom other classical verification problems. In this paper, wesuccessfully addressed these two challenges.

Although our proposed approach is able to achieve itsintended objectives, it still has two limitations: partially solvedstate explosion problem and non-consideration of Qualityof Services (QoSs). As we have seen in Section V-B2, aRCIG grows polynomially if response messages and sequentialmessages grow higher. Trace merging [11] (merging of similartraces in a RCIG) is a technique that is applicable andworking fine to reduce the order of the RCIG. However, moresophisticated solutions are required. Non-consideration of QoSparameters is a major limitation of our proposed approach. Ina RCIG, a QoS parameter could be represented in two ways:either by labeling the edges or by providing the values in

nodes. After forming a RCIG with QoS parameters, multi-objective optimization techniques could be used to computethe best possibility at runtime based on availability of services.

In our future work, apart from addressing the said limita-tions, we plan to make the proposed technique more designerinteractive, so that a designer will have fine grained controlover the modeling and verification aspects. We also plan toenhance the technique in such a way that it would be able tocapture and verify more generic interaction scenarios. Further,we want to investigate the applicability of our proposition formulti-agent interaction verification, formalization of negotia-tion and bargaining, and modeling of enterprise mash-up.

REFERENCES

[1] G. Alonso, F. Casati, H. A. Kuno, and V. Machiraju, Web Services -Concepts, Architectures and Applications. Springer, 2004.

[2] Q. Z. Sheng, X. Qiao, A. V. Vasilakos, C. Szabo, S. Bourne, and X. Xu,“Web services composition: A decade’s overview,” Inform. Sci., vol. 280,pp. 218–238, 2014.

[3] C. Granell, M. Gould, R. Grønmo, and D. Skogan, “Improving reuseof web service compositions,” in E-Commerce and Web Technologies.Springer, 2005, pp. 358–367.

[4] V. Jaiswal, A. Sharma, and A. Verma, “Recomp: Qos-aware recursiveservice composition at minimum cost,” in Proc. of the 12th IFIP/IEEEInt. Symp. on Integrated Network Management. IEEE, 2011, pp. 225–232.

[5] C.-A. Sun, X. Zhang, Y. Shang, and M. Aiello, “Integrating transactionsinto bpel service compositions: An aspect-based approach,” ACM Trans.on the Web, vol. 9, no. 2, p. 9, 2015.

[6] G. Zou, Y. Gan, Y. Chen, and B. Zhang, “Dynamic composition ofweb services using efficient planners in large-scale service repository,”Knowledge-Based Systems, vol. 62, pp. 98–112, 2014.

[7] Q. Hu, Y. Du, and S. Yu, “Service net algebra based on logic petri nets,”Information Sci., vol. 268, pp. 271–289, 2014.

[8] F. Belli, A. T. Endo, M. Linschulte, and A. Simao, “A holistic approachto model-based testing of web service compositions,” Software: Practiceand Experience, vol. 44, no. 2, pp. 201–234, 2014.

[9] M. Chen, T. H. Tan, J. Sun, Y. Liu, J. Pang, and X. Li, “Verification offunctional and non-functional requirements of web service composition,”in Proc. of the Int. Conf. on Formal Engineering Methods. Springer,2013, pp. 313–328.

[10] W. El Kholy, J. Bentahar, M. El Menshawy, H. Qu, and R. Dssouli,“Modeling and verifying choreographed multi-agent-based web servicecompositions regulated by commitment protocols,” Expert Systems withApplications, vol. 41, no. 16, pp. 7478–7494, 2014.

[11] G. N. Rai and G. R. Gangadharan, “Set partition and trace basedverification of web service composition,” in Proc. of the 6th Int. Conf.on Ambient Systems, Networks and Technologies (ANT), 2015, pp. 278–285.

[12] X. Fu, T. Bultan, and J. Su, “Analysis of interacting BPEL web services,”in Proc. of the 13th Int. Conf. on World Wide Web. ACM, 2004, pp.621–630.

[13] R. Kazhamiakin, M. Pistore, and M. Roveri, “Formal verification ofrequirements using SPIN: A case study on web services,” in Proc. ofthe 2nd Int. Conf. on Software Eng. and Formal Methods. IEEE, 2004,pp. 406–415.

[14] G. N. Rai, G. R. Gangadharan, and V. Padmanabhan, “Algebraicmodeling and verification of web service composition,” in Proc. of the6th Int. Conf. on Ambient Systems, Networks and Technologies (ANT),2015, pp. 675–679.

[15] G. M. Kapitsaki, D. A. Kateros, C. A. Pappas, N. D. Tselikas, and I. S.Venieris, “Model-driven development of composite web applications,”in Proc. of the 10th Int. Conf. on Inform. Integration and Web-basedApplications & Services. ACM, 2008, pp. 399–402.

[16] H. Foster, S. Uchitel, J. Magee, and J. Kramer, “Compatibility verifica-tion for web service choreography,” in Proc. of the Int. Conf. on WebServices (ICWS). IEEE, 2004, pp. 738–741.

[17] R. Hamadi and B. Benatallah, “A petri net-based model for web servicecomposition,” in Proc. of the 14th Australian Database Conf. AustralianComputer Society, Inc., 2003, pp. 191–200.

14

[18] A. Ferrara, “Web services: a process algebra approach,” in Proc. of the2nd Int. Conf. on Service Oriented Computing. ACM, 2004, pp. 242–251.

[19] E. Kaldeli, A. Lazovik, and M. Aiello, “Domain-independent planningfor services in uncertain and dynamic environments,” Artificial Intelli-gence, vol. 236, pp. 30–64, 2016.

[20] P. Papapanagiotou and J. D. Fleuriot, “A theorem proving frameworkfor the formal verification of web services composition,” in Proc. of the7th Int. Workshop on Automated Specification and Verification of WebSystems, WWV, 2011, pp. 1–16.

[21] D. Skogan, R. Grønmo, and I. Solheim, “Web service composition inuml,” in Proc. of the 8th IEEE Int. Conf. on Enterprise DistributedObject Computing. IEEE, 2004, pp. 47–57.

[22] B. Benatallah, F. Casati, and F. Toumani, “Web service conversationmodeling: A cornerstone for e-business automation,” Internet Comput-ing, IEEE, vol. 8, no. 1, pp. 46–54, 2004.

[23] B. Finkbeiner and I. Kruger, “Using message sequence charts forcomponent-based formal verification,” in In: Proc. of the Int. Conf. onSpecification and Verification of Component-Based Systems, 2001, pp.32–45.

[24] A. Letichevsky, J. Kapitonova, V. Volkov, S. Baranov, and T. Weigert,“Basic protocols, message sequence charts, and the verification ofrequirements specifications,” Computer Networks, vol. 49, no. 5, pp.661–675, 2005.

[25] D. Jordan, J. Evdemon, A. Alves, A. Arkin, S. Askary, C. Barreto,B. Bloch, F. Curbera, M. Ford, Y. Goland et al., “Web services businessprocess execution language version 2.0,” OASIS standard, vol. 11, p. 11,2007.

[26] R. Chinnici, J.-J. Moreau, A. Ryman, and S. Weerawarana, Web ServicesDescription Language (WSDL) Version 2.0 Part 1: Core Language,World Wide Web Consortium Std., 2007.

[27] N. Mehandjiev, F. Lecue, M. Carpenter, and F. A. Rabhi, “Cooperativeservice composition,” in Proc. of the Int. Conf. on Advanced Inform.Systems Engineering. Springer, 2012, pp. 111–126.

[28] C. Baier and J.-P. Katoen, Principles of model checking. MIT pressCambridge, 2008.

[29] H. Giese and B. Becker, Modeling and verifying dynamic evolvingservice-oriented architectures. Universitatsverlag Potsdam, 2013.

[30] S. Hashemian and F. Mavaddat, “Composition algebra,” in Proc. of theFormal Aspects of Component Software (FACS06), 2006, pp. 247–264.

[31] P. Hofner and F. Lautenbacher, “Algebraic structure of web services,”Electronic Notes in Theoretical Computer Science, vol. 200, no. 3, pp.171–187, 2008.

[32] Q. Yu and A. Bouguettaya, “Framework for web service query algebraand optimization,” ACM Trans. on the Web, vol. 2, no. 1, p. 6, 2008.

[33] H. Foster, S. Uchitel, J. Magee, and J. Kramer, “Model-based verificationof web service compositions,” in Proc. of the 18th IEEE Int. Conf. onAutomated Software Engineering. IEEE, 2003, pp. 152–161.

[34] L. E. Moser and P. M. Melliar-Smith, “Formal verification of safety-critical systems,” Software: Practice and Experience, vol. 20, no. 8, pp.799–821, 1990.

[35] A. P. Sistla, “Safety, liveness and fairness in temporal logic,” FormalAspects of Computing, vol. 6, no. 5, pp. 495–511, 1994.

[36] S. Kona, A. Bansal, G. Gupta, and D. Hite, “Automatic compositionof semantic web services.” in Proc. of the Int. Conf. on Web Services,vol. 7, no. 1, 2007, pp. 150–158.

[37] J. Peer, “Description and automated processing of web services,” Ph.D.dissertation, University of St. Gallen, 2006.

[38] P. Bertoli, M. Pistore, and P. Traverso, “Automated composition of webservices via planning in asynchronous domains,” Artificial Intelligence,vol. 174, no. 3, pp. 316–361, 2010.

[39] S. Lu, A. Bernstein, and P. Lewis, “Automatic workflow verification andgeneration,” Theoretical Computer Science, vol. 353, no. 1, pp. 71–92,2006.

[40] O. Hatzi, D. Vrakas, M. Nikolaidou, N. Bassiliades, D. Anagnostopou-los, and I. Vlahavas, “An integrated approach to automated semanticweb service composition through planning,” IEEE Trans. on ServicesComputing, vol. 5, no. 3, pp. 319–332, 2012.

[41] I. Georgievski and M. Aiello, “HTN planning: Overview, comparison,and beyond,” Artificial Intelligence, vol. 222, pp. 124–156, 2015.

[42] D. Wu, B. Parsia, E. Sirin, J. Hendler, and D. Nau, “Automating daml-sweb services composition using shop2,” in Proc. of the Int. SemanticWeb Conf. Springer, 2003, pp. 195–210.

[43] A. Abrougui, A. Mercier, M. Occello, and M.-P. Huget, “Recursivemulti-agent system for dynamic and adaptative web services compo-sition,” in Proc. of the Int. Conf. on Management of Emergent DigitalEcoSystems. ACM, 2009, pp. 44:295–44:299.

[44] C. Walton, “Model checking multi-agent web services,” in Proc. of theAAAI Symp. on Semantic Web Services, 2004.

[45] H. Schlingloff, A. Martens, and K. Schmidt, “Modeling and modelchecking web services,” Electronic Notes in Theoretical Computer Sci.,vol. 126, pp. 3–26, 2005.

[46] Y. Zheng, J. Zhou, and P. Krause, “A model checking based test casegeneration framework for web services,” in Proc. of the 4th Int. Conf.on Inform. Technology (ITNG ’07). IEEE, 2007, pp. 715–722.

[47] S. Rossi, “Model checking adaptive multilevel service compositions,”in Proc. of the 7th Int. Workshop on Formal Aspects of ComponentSoftware, FACS, 2010, pp. 106–124.

[48] Q. Z. Sheng, Z. Maamar, L. Yao, C. Szabo, and S. Bourne, “Behaviormodeling and automated verification of web services,” Inform. Sci., vol.258, pp. 416–433, 2014.

[49] J. Bentahar, H. Yahyaoui, M. Kova, and Z. Maamar, “Symbolic modelchecking composite web services using operational and control behav-iors,” Expert Systems with Applications, vol. 40, no. 2, pp. 508–522,2013.

[50] H. Groefsema, N. van Beest, and M. Aiello, “A formal model for com-pliance verification of service compositions,” IEEE Trans. on ServicesComputing, vol. 10.1109/TSC.2016.2579621, 2016.

Gopal N. Rai received his B.Sc. and M.C.A. degreefrom University of Allahabad, Allahabad, India, in2007 and 2011, respectively. He is currently workingtowards the Ph.D. degree at the University of Hyder-abad and the Institute for Development and Researchin Banking Technology (IDRBT), Hyderabad. Hisresearch interests include Software Verification, Webservices, and formal methods.

G R Gangadharan is an associate professor at theInstitute for Development and Research in BankingTechnology, Hyderabad, India. His research inter-ests focus on the interface between technologicaland business perspectives. Gangadharan received hisPhD in information and communication technologyfrom the University of Trento, Italy, and the Euro-pean University Association. He is a senior memberof IEEE and ACM.

Vineet Padmanabhan is a professor in the Schoolof Computer and Information Sciences in the Uni-versity of Hyderabad, India. His areas of interestinclude Knowledge Representation and Reasoning,Multi-Agent Systems, and Logics in Artificial In-telligence. Vineet received his Ph.D. from GriffithUniversity, Australia.

Rajkumar Buyya is a professor of computer sci-ence and software engineering, future fellow ofthe Australian Research Council, and the directorof the Cloud Computing and Distributed Systems(CLOUDS) Laboratory at the University of Mel-bourne, Australia. His areas of interest include gridcomputing, cloud computing, and high-performancecomputing. Buyya received his Ph.D. from Univer-sity of Melbourne, Australia. He is a Fellow of IEEEand Life Member of ACM.