Towards an agent based approach for verification of OWL-S process models

(1)

Towards an agent based approach for verification of

OWL-S process models

Alessio Lomuscio and Monika Solanki Department of Computing, Imperial College London, UK

Abstract. In this paper we investigate the transformation of OWL-S process mod-els to ISPL - the system description language for MCMAS, a symbolic model checker for multi agent systems. We take the view that services can be considered as agents and service compositions as multi agent systems. We illustrate how atomic and composite processes in OWL-S can be encoded into ISPL using the proposed transformation rules for a restricted set of data types. As an illustrative example, we use an extended version of the BravoAir process model. We formalise certain interesting properties of the example in temporal-epistemic logic and present results from their verification using MCMAS.

1 Introduction

The verification of web service behaviour and interaction protocols is now an integral aspect of several frameworks providing service oriented solutions to the IT industry. The Increasing complexities that arise during service composition, make offline verification as model checking [4] crucial in successfully implementing and using services. Model checkers typically use specialised formats for the specification of behaviour, different from those commonly used for describing services. Examples of such system description languages include Promela, used with the checker SPIN [10] and NuSMV, used with the checker NuSMV [3]. However in the web service domain, WSBPEL [18], WSCDL [17] and OWL-S [20], are some popular and widely used standards for describing service behaviour, their composition and interaction protocols.

The languages above work at different levels of abstraction. In order to verify ser-vices, an important first step is to investigate how the input language to the model checker can be adapted to encode a suitable abstraction of the service behaviour, which has been described using one of the above standards. Figure 1 illustrates the general architecture of a verification framework for services. As highlighted, a crucial component is the “com-piler” that takes as input the service specification, and generates a suitably abstracted model/program, encoded in the system description language for the checker. The model and the desired properties to be verified are fed to the checker. By performing a systematic exploration of the complete set of states that can be generated during an interaction be-tween a service and its clients, the model checker is able to verify desirable properties of the composition. Generating a well abstracted model is thus crucial to the verification of services. However, developing a tool that generates such a model is non trivial. Mapping rules between the languages are required to be established before any automated trans-lation can be undertaken. The rules provide the basis and rationale for development of a compiler providing (semi)automatic compilations from one abstraction to the other.

(2)

Fig. 1. General architecture for service verification

In this paper, we explore the generation of transformation rules from the process model of OWL-S, a well-established language for the description of web services on the semantic web, to ISPL (Interpreted Systems Programming Language) in view of verifying the results using MCMAS [15]. We are interested in using MCMAS, because it enables the user to verify rich specifications. MCMAS supports not only temporal logic, but also epistemic and deontic modalities. We take the view that a web service can be modelled as an “agent” [6]. Keeping this in perspective, a composition of web services can be viewed as a multi agent system [22]. An OWL-S process model specifies the composition and interaction between agents/services and their clients. Control constructs similar to those found in programming languages can be used to compose services. Earlier work [16,1] on using MCMAS for services has focused on exploiting its verification capabilities. In this paper we provide the transformation rules and a compiler implementation of the rules, that combined with MCMAS, could aid in automated verification of services.

The paper is structured as follows: Section 2 outlines our running example for the pa-per, a flight booking and managing service, which is an extended version of the BravoAir process from the OWL-S suite of examples. In Section 3 we provide a brief overview of OWL-S, ISPL and MCMAS. Section 4 discusses the mapping rules from OWL-S to ISPL and presents our implementation of the compiler. We present a brief account of the analysis and verification for the case study in Section 5. Finally, we conclude in Section 6.

2 Case study

As a running example, we use an extended version of the BravoAirProcess model from the OWL-S suite of examples. BravoAir functions as a flight booking agent. It allows a client to perform several tasks such as searching, selecting and booking flights. Book-ings can be made as individual or as groups. The top level process, BravoAir, is a composite process. It is composed of a sequence of processes. Components of the se-quence areGetDesiredFlightDetailsandSearchAvailableFlight, and a composite process,BookFlight. We extend theBookFlightprocess as a sequence whose components are LogIn, followed by a choice betweenIndividualBookng and GroupBooking and finally ConfirmReservation. Group bookings can be

(3)

done for a group of more than 10 people and the discount offered is 10% of the total booking fee. However when a group booking is cancelled, the cancellation fee is 15% rather than 10% for individual bookings. We elaborate on the GroupBooking process in Section 4.

We further extend the top level process with a composite processManageBooking, to be executed in sequence withBookFlight.ManageBookingis composed as a

choice between the atomic processChooseSeatsand the composite processes, ChangeBookingandCancelBooking. If a booking is cancelled the amount which is charged for cancellation depends on whether the booking was made at an individual or group level.ChangeBookingis composed of a split+join whose components are the three atomic processesChargeCard- for economy bookings,AllocateNewBooking -for club and business class bookings andSendUnAvailability- when a change of booking is not possible. The outcome from a choice between the first two processes is composed in sequence withSendConfirmation.ChargeCardis also invoked when a booking is cancelled. Figure 2 illustrates the various control constructs and processes used in the composition between BravoAir and a potential client. The composition can

Fig. 2. An extended version of the BravoAir process

be viewed as a multi-agent system where individual processes are abstracted as agents. Within the above settings certain interesting properties of the composition can be veri-fied. We enumerate some of these below and formalise them in temporal-epistemic logic in Section 5.

– if there is a request confirmation of reservation, the ConfirmReservation agent knows that the booking has been successful and payment has been made.

– If the number of people is more than 10, group booking will always be successful. – Whenever a booking change is requested, it will always be confirmed.

– If a card is not charged when a booking is changed, theChangeBookingagent knows that the reference is a business class booking.

(4)

– if a confirmation is received, the Customer agent knows that his booking was changed. – If a card is charged after a booking has been made, it always implies that the booking

has been cancelled.

3 Preliminaries

3.1 OWL-S

OWL-S [20] is an OWL-based Web service ontology which supplies Web service providers with a core set of constructs for describing the properties and capabilities of their Web services. It defines an upper ontology for services with Service Profile, Service Model and Service Grounding models. The ServiceProfile provides the information needed for an agent to discover a service, while the ServiceModel and ServiceGrounding, taken to-gether, provide enough information for an agent to make use of a service, once found.

The process model informs a client on how to use the service by detailing the se-mantic content of requests, the conditions under which particular outcomes will occur, and where necessary, the step by step processes leading to those outcomes. Functional-ity description in OWL-S is represented by two aspects: the information transformation (represented by inputs and outputs) and the state change produced by the execution of the service (represented by preconditions and effects). The term Result is used to refer to a coupled output and effect. Preconditions and conditions in results are represented as logical formulas specified in a suitable logical framework such as SWRL [12]. OWL-S defines three fundamental processes: atomic, simple and composite. Atomic processes correspond to the actions a service may perform by engaging in a single interaction; com-posite processes correspond to actions that require multi-step protocols and/or multiple server actions; simple processes provide an abstraction mechanism to provide multiple views of the same process.

3.2 ISPL and MCMAS

ISPL (Interpreted System Programming Language) is based on the formal semantics of interpreted systems [7] and is the input language for the model checker MCMAS [15,14]. The syntax of ISPL includes the following

– The definition of agents describes the local behaviour of every agent in terms of states, actions, protocols and evolution function. Each agent has a set of local variables. The states of an agent, each of which contains a valuation of its local variables can be further partitioned into two disjoint sets: a non-empty set of allowed (“green”) states and a set of disallowed (“red”) states. Currently, ISPL allows three types of variables: Boolean, enumeration and bounded integer.

– The global evaluation function of the system defines atomic propositions held over global states which are a combinations of local states of agents defined in the model. – The local initial state for each agent in the system.

– Specification to be checked defined as formulae in temporal, epistemic and deontic logic and fairness formuale.

(5)

MCMAS is a specialised model checker for the verification of multi-agent systems. It builds on symbolic model checking via OBDDs as its underlying technique, and supports CTL, epistemic and deontic logic. The current version of MCMAS has the following features:

– Support for variables of the following types: Boolean, enumeration and bounded in-teger. Arithmetic operations can be performed on bounded integers.

– Counterexample/witness generation for quick and efficient display of traces falsify-ing/satisfying properties.

– Support for fairness constraints. This is useful in eliminating unrealistic behaviours. – Support for interactive execution mode. This allows users to step through the

execu-tion of their model.

– A graphical interface provided as an Eclipse plug-in which includes a graphical editor with syntax recognition, a graphical simulator, and a graphical analyser for counterex-amples.

4 Encoding OWL-S processes as ISPL models

In an OWL-S process model, inputs and outputs are process parameters that have concrete datatypes. The current version of ISPL provides support for variables of types bounded

integers, boolean and enum. Mapping between ontologies and these types can be done as

discussed in [13]. Most existing model checkers including MCMAS, are not equipped to support OWL object types as also highlighted in [2]. We therefore abstract from defining object types for the transformation presented in this paper.

Conditions explicitly occur in OWL-S models asPrecondition, and as part of the Resultandifstatement. In ISPL conditions are defined as formulae when specifying the protocol and evolution functions. In this section we first propose the following step-by-step methodology for transforming an atomic process to an ISPL program. We then show how composite processes can be transformed. These rules also facilitate the generation of a semi-automatic compiler from OWL-S to ISPL.

4.1 Encoding Atomic Processes

Agent: For every atomic process in OWL-S, we define an agent, qualified asProcessName in ISPL. Recall, that the definition of an agent in ISPL includes: local variables, red states, actions, protocol functions and evolution functions.

Variables and local states: The local states of an agent in ISPL are defined in terms of valuation of the local variables. We define the set of local variables for an agent by transforming the ontological inputs and outputs in the process model, to variables with the same identifiers and datatypes in the ISPL model. Bounds for integer variables are interactively assigned keeping the domain and context of the process model in perspective. For an atomic process, we identify two kinds of states: (1) An “Input” or initial state and (2) several “Result” states depending on the number of results defined for the process.

LetVIdenote the set of integer variables,VBthe set of Boolean variables andVEthe set of variables of type enum. We define the set of their valuations asV alI, V alB and

(6)

V alErespectively. The set of local variables for an agent is thereforeV =VI∪VB∪VE. The set of local states,Llstate, of an agent can now be defined as

Llstate: (VI →V alI)∪(VB→V alB)∪(VE→V alE) . We enumerateLlstatefor an agent as follows

-– the initial state (l0) where local variables are assigned initial values. We denote the set of variables at the initial state asV0⊆V.

– the set of statesLresult, where eachl ∈ Lresult corresponds to a non deterministic Resultstate, defined for the process. For example, a credit card validating service may produce two results: ValidationSuccess with boolean outputvalidatedastrue, andV alidationnF ailedwith boolean outputvalidatedas f alse. The set of vari-ables at each of the result state is denoted asVi ⊆ V,i = 1. . . | Lresult |. The valuations for the variables are computed as per the evolution function described be-low.

– finally,lf, a failure state which is reached when the preconditions for the process evaluates tof alse. We denote the set of variables at this state asVf ⊆V. Valuations for the variables are again computed as per the evolution function.

Red States: They are reached when an agent performs an undesirable action. This feature of ISPL is most useful while encoding faults and recovery in complex systems. The red states of an agent are represented by a Boolean formula,fred_{, over its local variables.} Actions: The internal actions taken by a service cause a transition from the input state to one of the several result states. Actions for the agent are enumerated as follows:

– the null actionǫ,

– the set of internal actions,Aint ={ai|i= 1. . . n}, the agent takes at the input state to reach one of the several result states.

– the internal actionaf taken when the precondition fails, to reach statelf.

– the set of actionsAsend ={si|i= 1. . . n}. The agent takes an actions∈Asendat eachl∈lresultrespectively to send the corresponding results to the client.

– the actionsfwhich the agent takes to send the precondition failure message atlf. – It follows that the total number of actions is:

Nactions=|Aint∪ {af} |+|Asend∪ {sf} |+| {ǫ} |

For simplicity we assume,|Aint∪ {af} |=|Asend∪ {sf} |, and simplify the above to,

Nactions = 2× |Aint∪ {af} |+1 Protocols: Protocols for the agent can be enumerated as follows:

fpre:{ai|i= 1. . .|Aint|} !fpre:af

(7)

wherefpre(precondition),fires,i = 1 . . . | Asend |(condition in results) and!fpre are Boolean formulae over the set of local variables at the input state, result states1and the failure state respectively. Note that ISPL and MCMAS allow non determinism in the specification of protocols.

At execution time an agent atl0takes an action,a∈Aintiffpre, i.e., the precondi-tion holds and acprecondi-tionaf if!fpreholds. This causes a transition to one of the result states

l ∈Lresult∪lf, where the conditionals from the results,fires, i = 1. . . | Asend |are required to hold. Atl, the agent take an action,s∈Asend∪ {sf}.

Evolutions (Transitions): The evolution function determines how local states evolve based on the agent’s current local state and a set of actions. An evolution consists of a set of assignments of local variables inV and an enabling condition which is a Boolean formula, over local variables and actions of all agents.

l0iff_iresand ProcessName.Action= sior ProcessName.Action= sf, i= 1. . .|Asend|

li iffpreand ProcessName.Action=ai, i= 1. . .|Aint|

lf if!fpreand ProcessName.Action=af

We have implemented a semi automatic compiler for the transformation, by extending

Fig. 3. Mapping between an OWL-S atomic process and ISPL

the CMU OWL-S API [5]. Given an OWL-S process model, the compiler extracts the agent name, inputs and outputs from the process model as ISPL variables and enumerates the actions for the agent. Currently the definition of the red states, protocol and evolution function are interactively given, but we hope to automate the process in future versions of the paper.

1

Note that for simplicity we do not consider the case, when due to some internal failure of the service, the result conditions do not hold, but this may well be possible and additional transitions would have to be defined to consider such scenarios

(8)

The psuedocode of an algorithm, which we implemented as part of our compiler for compiling an atomic process to ISPL is presented as algorithm 1 towards the end of the paper.

4.2 ISPL encoding of the atomic process: GroupBooking

Fig. 4. Atomic Process: Group Booking

Figure 4 illustrates an atomic process “Group Booking ” from the case study pre-sented in Section 2. The process takes noOf P eople,f lightdetails,carddetails and

loggedInStatusas inputs. In order to perform a group booking, the preconditions on the process are that the payment card details must be provided, the number of people in a group must be atleast 10 and the booking client must be a logged in. It returns as output, a

successM sgmessage, aninvalidCardM sgor aninvalidN umM sgmessage depend-ing on the conditionsisBookingSuccessf ul,isV alidCardand

isV alidN umberOf P eoplebeingtrueorf alse. For a successful booking it also returns the discounted booking cost.

We specify the “GroupBooking” agent using the presentation syntax of OWL-S along with its corresponding ISPL code in Table 1. The inputs and outputs are mapped as “Vars” in ISPL. Actions are interactively enumerated in accordance with the operation names specified in the grounding model defined for the process. Preconditions such asloggedIn,

providedCardandnoOf P eople≤10are specified as Boolean formula on the LHS of the protocol function. For the precondition,loggedIn=trueandprovidedCard=true

andnoOf P eople≥10the internal actionsintAct1orintAct3would be non determin-istically chosen by MCMAS as specified in the protocol function. The conditional part of results is specified as Boolean formula on the LHS of the “if” in the evolution function. 4.3 Encoding Composite Processes

A composite process may use one of several control constructs such as sequence,

if-then-else, found in programming languages. In what follows, we discuss the modelling of

com-posite processes, for some of the control constructs. Transformation to other constructs follows intuitively from those presented below.

(9)

OWL-S atomic process ISPL Agent

define atomic process Group (inputs:( noOfPeople - xsd:integer cardDetails - xsd: string dout - xsd:date din - xsd:date ), exists:( loggedInStatus - xsd:boolean ), preconditions :( (loggedInStatus) & (noOfPeople>=10) & providedCard(cardDetails), outputs:( invalidCardMsg - xsd:string

successMsg - xsd:string invalidNumMsg -xsd:string discountedPrice - xsd:String )

results :(

isValidCard & noOfPeople>=10)|> output(isBookingSuccessful -xsd:boolean, discountedPrice - xsd:integer),

isValidCard |-> output(invalidCardMsg-xsd:string), isValidNumberOfPeople |-> output(invalidNumMsg), ) Agent GroupBooking Vars: noOfPeople:1..20; isValidNumberOfPeople:boolean; loggedIn:boolean; providedCard:boolean; isValidCard:boolean; isBookingSuccessful:boolean; price:1000..200000; discountedPrice:100..20000; dates:{dout, din}; successMsgSent:boolean; cardFailureMsgSent:boolean; numberFailureMsgSent:boolean; end Vars RedStates: end RedStates

Actions = {intAct1, intAct2, intAct3, intAct4, invalidCardMsg, invalidNumMsg, successMsg, nothing}; Protocol:

loggedIn=true and providedCard=true and noOfPeople >=10 : {intAct1, intAct3};

loggedIn=true and noOfPeople <10 : {intAct2}; isValidCard=false:{invalidCardMsg}; isValidNumberOfPeople=false:{invalidNumMsg}; isBookingSuccessful=true:{successMsg}; end Protocol

Evolution:

isBookingSuccessful=true and isValidCard=true and discountedPrice=price -(price * 1/10) if loggedIn=true and providedCard=true and noOfPeople>=10 and

GroupBooking.Action=intAct1;

isBookingSuccessful=false and isValidCard=false if providedCard=true and

GroupBooking.Action=intAct3; isBookingSuccessful=false if noOfPeople<=10 and

GroupBooking.Action=intAct2;

successMsgSent=true if isBookingSuccessful=true and GroupBooking.Action=successMsg;

cardFailureMsgSent=true if isBookingSuccessful=false and GroupBooking.Action=invalidCardMsg;

end Evolution end Agent

Table 1. The Group Booking Atomic Process

Sequence The sequence specifies a list of processes to be executed in a certain order. The modelling of OWL-S sequence requires explicit synchronisation. In ISPL, the def-inition of evolution for an agent encodes this synchronisation. We illustrate sequential composition through an example of processes composed in sequence.

Consider the processBookFlight, from the BravoAir model, which is a sequential composition of three atomic processes,Login,GroupBookingand

ConfirmReservation. After receiving the result of a successful booking from the GroupBookingprocess, the client invokes theConfirmReservationprocess with inputs isbookingSuccessful=true and confirmFlight=true. The precondition for the exe-cution ofConfirmReservationis isbookingSuccessful=true. Note that this was also the result condition of theGroupBookingprocess. TheConfirmReservation pro-cess returns a single result as a complex message consisting of a reservationID and

seat-Number. The processes are synchronised for these inputs on the final state of

GroupBookingand the initial state ofConfirmResearvation. It may also be the case that the client provides all the inputs for both the processes in the initial state of the GroupBookingprocess. In such a scenario theGroupBookingprocess invokes the ConfirmResearvationprocess at its final state using those inputs. We encode both the atomic processes in ISPL using the approach outlined in Section 4.1. We then define synchronisation between the processes for the sequential composition as outlined above. Figure 5 illustrates the composition. A typical evolution function for the “GroupBooking”

(10)

Fig. 5. Sequential composition of GroupBooking and ConfirmReservation

agent would now be:

Evolution:

isBookingSuccessful=true and isValidCard=true and discountedPrice=price -(price * 1/10) if loggedIn=true and providedCard=true and noOfPeople>=10 and GroupBooking.Action=act1; isBookingSuccessful=false and isValidCard=false if

providedCard=true and GroupBooking.Action=act3; isBookingSuccessful=false if

noOfPeople<=10 and GroupBooking.Action=act2; sucessMsgSent=true if

isBookingSuccessful=true and GroupBooking.Action=successMsg and ConfirmResearvation.Action=recBookingSuccessMsg;

cardFailureMsgSent=true if

isBookingSuccessful=false and GroupBooking.Action=invalidCardMsg; numberFailureMsgSent=true if

isBookingSuccessful=false and GroupBooking.Action=invalidNumMsg; end Evolution

Split, Split+Join OWL-S provides two types of constructs for concurrent execution: split and split+join. The components of a split process are a set of processes to be executed concurrently. Split completes when all its component processes have been scheduled for execution whereas split+join completes when all of its component processes have been completed. In both these types of constructs there is a parent process that spawns off the component processes. Split is encoded as illustrated in Figure 6.

The parent process is agentP which spawns three child processes A,B,C at the initial state. Synchronisation between the processes is defined at the initial states of the parent and child processes. Note that in ISPL the parent and child processes are encoded as agents. The number of child agents to be defined can be extracted automatically from the OWL-S definition of composite process.

Similar to split, split+join is encoded as illustrated in Figure 7. In addition to the synchronisation on the initial states of the child processes, the parent process is also syn-chronised on their final states.

Consider, our extended model for BravoAir. The parent processChangeBookingis composed of two child atomic processes,ChargeCardandAllocateNewBooking using split+join. The processes are synchronised at the states indicated in Figure 8. ChangeBookingsends an input message toChargeCardwhich includes the client’s details and the extra payment to be charged. As outputChargeCardreturns transac-tion details. Concurrently,ChangeBookingsends the client’s details, original booking and the requested new booking toAllocateNewBooking. The process returns new booking for the client. All messages are encoded as propositions as discussed in section 4.1.

(11)

Fig. 6. Encoding split Fig. 7. Encoding split+join

Fig. 8. The ChangeBooking process

Choice The choice construct allows the invoking process to choose one process non de-terministically, from a set of processes. Once the choice is made, the composition essen-tially resolves to a sequential composition between the invoking process and the chosen process. The parent process as well as the set of processes are encoded as agents in ISPL, as illustrated in Figure 9

In our extended example for BravoAir,ManageBookingis a process, composed as a choice betweenChooseSeatsand theChangeBookingandCancelBooking. Due to space restrictions, we do not discuss this in the paper.

If-then-else The if-then-else construct allows to conditionally choose a process from a pair of processes. We define three agents, corresponding to the invoking process and the pair of processes. Since the condition to be checked is a boolean formulae, similar to checking preconditions, we define two states, one where the condition holds and the other where it does not. At these two states we define the synchronisation between the invoking process and the processes in the pair respectively as illustrated in Figure 10.

(12)

Fig. 9. Encoding choice Fig. 10. Encoding if-then-else

Iterate, Repeat-while, Repeat-Until The iterate construct allows the unconditional re-peated invocation of a process. Two agents are defined corresponding to the invoking and the iterating process. Repeat-while and Repeat-Until allow repeated and conditional invo-cation of a process Synchronisation between the processes is illustrated in Figure 11 and 12.

Fig. 11. Encoding iterate Fig. 12. Encoding repeat-while-repeat-until

5 Analysis and Verification

In this section we show the results of verification of some interesting properties of the BravoAir process. Properties are specified as CTL and epistemic formulae2_.

– if there is a request for flight booking confirmation, the ConfirmReservation agent(CR) knows that the customer (C) is an authorised customer.

EF((conf irmBookingRequest)→KCR(authorisedCustomer)) – If the number of people is more than 10, group booking will always be successful.

AF((noOf P eople >10)→EF(isBookingSuccessf ul))

2

For further details on how such properties could be specified and verified using MCMAS, the interested reader is referred to [1].

(13)

Intuitively the property does not hold because if the card details provided are not valid, the booking will not be successful.

– Whenever a booking change is requested, it will eventually be confirmed.

EF((bookingChangeRequest)→EF(sendConf irmation))

Intuitively the property does not hold because if there are no alternative bookings available, the change will not be confirmed.

– If a card is not charged when a booking is changed, theChangeBookingagentCB

knows that the reference is a business class booking.

EF(bookingChanged∧ ¬cardCharged→KCB(businessBooking)) – if a confirmation is received, the Customer agent(C) knows that his booking was

changed.

EF(receivedConf irmation→KC(bookingChanged))

We encoded the scenario and the specification above in ISPL and verified it using MC-MAS. Our system was running on Linux Ubuntu 8.10 (kernel 2.6.27) on Intel Core 2 Duo T5500 1.66GHz with 2GB memory. We encoded 20 ISPL agents by using 120 BDD variables: 43 BDD variables for local states (the same number of BDD variables are con-structed for the transition relation) and 34 for local actions. The total number of global states is approximately105

. it took about 41 seconds with 34 MB memory space for MCMAS to verify 15 properties. The verification results were in accordance with what expected.

6 Conclusions

Although extensive research [19,8] has been done on the automated verification of web service composition using BPEL4WS, work on verification of OWL-S process models is relatively scant. Approaches closely related to our work are [2] and [11]. In [2] the mapping rules are defined for Promela to be used with SPIN, an explicit model checker. In [11], the rules are defined for a C-like specification language to be used with BLAST [9]. The limitation in both cases is that only LTL (SPIN) and LTL-like (BLAST) properties can be verified. Using our approach, it is possible to verify LTL, CTL, epistemic and deontic properties with MCMAS. For example, for the case study in Section 2 the composition can be viewed as a multi-agent system where individual processes are abstracted as agents.

In this paper we have proposed mapping rules from the process model of OWL-S to ISPL. We believe the rules are sound as the semantics of ISPL are based on standard kripke semantics and it has been shown that OWL-S processes can be encoded as transi-tion systems [21]. We have shown the mapping for atomic processes and for certain con-trol constructs used for composing them. Our approach provides the first steps necessary to compile automatically OWL-S process models to ISPL. We have developed a com-piler that implements the proposed mapping rules. The comcom-piler generates ISPL agents for atomic processes and processes composed in sequence. We are now in the process of enhancing the compiler for other control constructs such as choice and if-then-else.

(14)

References

1. A. Lomuscio and H. Qu and M. Solanki. Towards verifying compliance in agent-based web service compositions. In Proceedings of The Seventh International Joint Conference on Au-tonomous Agents and Multi-agent systems (AAMAS-08). ACM Press, 2008.

2. Anupriya Ankolekar, Massimo Paolucci, and Katia P. Sycara. Towards a formal verification of owl-s process models. In International Semantic Web Conference, pages 37–51, 2005. 3. A. Cimatti, E. Clarke, F. Giunchiglia, and M. Roveri. NuSMV: A new symbolic model verifier.

In Proc. of CAV’99, pages 495–499, 1999.

4. E. M. Clarke, O. Grumberg, and D. A. Peled. Model Checking. The MIT Press, Cambridge, Massachusetts, 1999.

5. CMU: An API for OWL-S. CMU OWL-S API.

http://www.daml.ri.cmu.edu/owlsapi/index.html.

6. D Booth, H Haas, F McCabe, E Newcomer, M Champion, C Ferris and D Orchard. Web service architecture. W3c working group note 11 february 2004, 2004. http://www.w3.org/TR/ws-arch/.

7. R. Fagin, J. Y. Halpern, Y. Moses, and M. Y. Vardi. Reasoning about Knowledge. MIT Press, Cambridge, 1995.

8. X. Fu, T. Bultan, and J. Su. Analysis of interacting BPEL web services. In 13th international conference on World Wide Web, pages 621–630. ACM Press, 2004.

9. T. A. Henzinger, R. Jhala, R. Majumdar, , and G. Sutre. Software verification with Blast. In Proceedings of the Tenth International Workshop on Model Checking of Software (SPIN), pages 235–239. Lecture Notes in Computer Science 2648, Springer-Verlag, 2003.

10. G. J. Holzmann. SPIN Model Checker, The: Primer and Reference Manual. Addison Wesley Professional, 2003.

11. H. Huang, W. Tsai, R. Paul, and Y. Chen. Automated model checking and testing for composite web services. In Proc. of ISORC’05, pages 300–307. IEEE Computer Society, 2005.

12. I Horrocks, P F. Patel-Schneider, H Boley, S Tabet, B Grosof, M Dean. SWRL: A Semantic Web Rule Language Combining OWL and RuleML . Technical report, University of Manch-ester, Version 0.5 of 19 November 2003.

13. Aditya Kalyanpur and Daniel Jimnez. Automatic mapping of owl ontologies into java. In In Proceedings of Software Engeering and Knowledge Engeering (SEKE04, 2004.

14. A. Lomuscio, H. Qu, and F. Raimondi. Mcmas 0.9 alpha.

http://sourceforge.net/projects/ist-contract/, 2008.

15. A. Lomuscio and F. Raimondi. MCMAS: A model checker for multi-agent systems. In Pro-ceedings of TACAS 2006, volume 3920, pages 450–454. Springer Verlag, 2006.

16. Alessio Lomuscio, Hongyang Qu, Marek J. Sergot, and Monika Solanki. Verifying temporal and epistemic properties of web service compositions. In ICSOC, volume 4749 of LNCS, pages 456–461. Springer-Verlag, 2007.

17. N Kavantzas, D Burdett, G Ritzinger, T Fletcher, Y Lafon. Web Services Choreography De-scription Language Version 1.0: W3C Working Draft 17 December 2004, 2004.

18. OASIS Web service Business Process Execution Language (WSBPEL) TC. Web service Busi-ness Process Execution Language Version 2.0, 2007.

19. Marco Pistore, F. Barbon, Piergiorgio Bertoli, D. Shaparau, and Paolo Traverso. Planning and monitoring web service composition. In AIMSA, pages 106–115, 2004.

20. The OWL-S Coalition. OWL-S 1.1 Release., 2004. http://www.daml.org/services/owl-s/1.0/.

21. Paolo Traverso and Marco Pistore. Automated composition of semantic web services into executable processes. In ISWC, 2004.

(15)

Transformation Algorithm from OWL-S to ISPL

Algorithm 1 Psuedocode: OWL-S - ISPL mapping 1: readProcessName.owl{parse the atomic process} 2: print AgentProcessName{define the agent}

3: print Vars:{begin the extraction and definition of local variables} 4: for all hasInput in ProcessName.owl do

5: print InputID: datatype; 6: end for

7: for all hasOutput in ProcessName.owl do 8: print OutputID: datatype;

9: print end Vars{end of variable definition} 10: end for

11: NhasResult ⇐ count(<process:hasResult>){count the number of <process:hasResult>elements}

12: Nactions⇐2×NhasResult+2{determine the number of actions for the process}

13: print RedStates:{begin the definition the red states} 14: fred{define the Boolean formula for the red states} 15: print end RedStates{end definition of red states} 16: print Actions ={ǫ, af {begin enumeration of actions}

17: for allisuch that1≤i≤|Aint|do

18: printai,{enumeration of actions taken at statesl0}

19: end for

20: for allisuch that1≤i≤|Asend|do

21: printsi,{enumeration of actions taken at states{li|i= 1. . .|Asend|}}

22: end for

23: printsf} {end enumeration of actions}

24: print Protocol:{begin enumeration of the protocols} 25: printfpre_:_{_{define the Boolean formula for the precondition}_}

27: print{ai|i= 1. . .|Aint|} {enumerate the actions}

28: end for

29: print;{end of line}

30: print!fpre:af;{define the protocol for precondition failure}

32: printfires:{si}

33: print;{end of line} 34: end for

35: print end protocol{end enumeration of the protocol} 36: print Evolution:{begin enumeration of the evolutions} 37: printl0if (

39: print (liand ProcessName.Action=si)

40: end for

41: print;{end of line}

43: printliif (l0and ProcessName.Action=ai);

44: end for

45: printlfif (Lstate =l0and ProcessName.Action=af);

46: end Evolution;{end enumeration of evolutions} 47: end Agent{end agent definition}