SWSCE - An Automatic Semantic Web Service Composition Engine S. Bonomi, V. Colaianni, F. Patrizi, D. Pozzi, R. Russo, M. Mecella SAPIENZA – Università di Roma, Dipartimento di Informatica e Sistemistica Via Ariosto 25, 00185 Roma, ITALY {bonomi,colaianni,patrizi,pozzi,russo,mecella}@dis.uniroma1.it ABSTRACT In order to represent the behavioral schema it is possible In several scenarios, Semantic Web technologies are gaining to use a transition system (TS). It is identified by (i) the set momentum as the most promising ones to address the issue of actions that the Web service is able to perform, (ii) the set of integrating services among different entities, possibly be- of states that the interaction with the service passes through, longing to different location. In particular, Semantic Web (iii) the initial state and final states of the interaction and Service composition can be used when no individual avail- (iv) the transition relation, which describes state changes as able service can satisfy a specific client request, but (parts result of action executions. Note that a final state is a state of) available services can be composed and orchestrated in where the client can either ask for another action (moving to order to do it. In this paper we describe SWSCE, a Seman- another state) or safely stop the interaction with the service. tic Web Service Composition Engine, able to automatically We assume the initial state is always final, so to allow the performs the composition of Semantic Web Services. client to not even start the interaction. 1. INTRODUCTION The promise of Web services is to enable the composition of new distributed applications/solutions: when no available service can satisfy a client request, (parts of) available ser- vices can be composed and orchestrated in order to do it. Service composition involves two different issues: the syn- Figure 1: Conversational Model: example of inter- thesis, in order to synthesize, either manually or automat- action ically, a specification of how coordinating the component services to fulfill client requests, and the orchestration, i.e., Figure 1 depicts an example of the conversation model we how executing the previous obtained specification by suit- adopt [2]. A typical interaction is as follows. The Pay Taxes ably supervising and monitoring both the control flow and Service is composed by two states S0 , that is an initial and the data flow among the involved services. final state, and S1 that is a final state. The actions that the Typically, a client continuously interacts with the Web client can ask for are three: (i) provideAnagraphicDetail service by asking for something (i.e., the execution of some with which the client provides to the service its data and action returning information to the client), waiting for the moves from state S0 to state S1 , (ii) provideBankAccount reply from the Web service and then asking again until the with which the client provides to the service its bank account client reaches its satisfaction. After each step, the client can information and moves from state S0 to state S1 and (iii) choose the next operation to invoke among the ones that payTaxes with which the client pays the amount of the tax the service allows at that point of the interaction. All these and he goes back to S0 from S1 . operations and the constraints on their invocation represent In some cases a client would like to interact with a non the behavior of the service and are described in the exported existing Web Service. Nonetheless, a suitable combination service as semantic description. In particular, the behavioral of available services (component services) may satisfy the schema describes all the possible sequences of actions that client’s needs. We refer to the service obtained as combina- characterize the service execution, and a conversation is a tion of other ones as target Web service, and the process of sequence of invocations of operations in a particular order building the target Web service as composition. The inter- satisfying the constraints imposed by the schema. esting challenge is how to make all of this in an automatic way. Semantic Web technologies, such as OWL/OWL-S 1 and WSMF 2 allow the description of the semantics of enti- Permission to make digital or hard copies of all or part of this work for ties, including Web services, in a machine-processable for- personal or classroom use is granted without fee provided that copies are mat based on XML, and therefore give the right solution not made or distributed for profit or commercial advantage and that copies 1 bear this notice and the full citation on the first page. To copy otherwise, to http://www.w3.org/Submission/OWL-S/ 2 republish, to post on servers or to redistribute to lists, requires prior specific D. Fensel, C. Bussler: The Web Service Modeling Frame- permission and/or a fee. work – WSMF. http://www.swsi.org/resources/wsmf- Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00. paper.pdf for expressing the behavioral schema of a Web service, by enabling its use in possible compositions. In particular, in SWSCE WSMF, the behavior of a service is natively represented as a Composition Composition Algorithm Algorithm TS and therefore Semantic Web services (SWSs) expressed User Interface Knowledge according to WSMF are well suited to be composed accord- Knowledge Base Base Manager Manager ing to the techniques presented in [2, 5]. Core Engine The contribution of this paper is to present a tool, namely Parser Parser SWSCE – Semantic Web Service Composition Engine, able to perform automatic composition of SWSs. In particular Repository Repository Manager Manager the description of the implementation of the tool is the main focus of the paper. The paper is organized as follows: in Section 2 the semantic composition engine is described; in particular Section 2.1 describes its architecture, Section 2.2 underlines issues related to automatic composition and Sec- Repository tion 2.3 shows the tool functionalities through a practical case. Section 3 presents a discussion on the state of the art, and finally Section 4 concludes the paper. At the end Ap- pendix A provides some background information on WSMF, Figure 2: SWSCE Architecture whereas Appendix B shows some code snippets about the running example presented throughout the paper. actually perform the calculation of the composition is TLV. 2. SEMANTIC WEB SERVICE COMPOSI- TLV (Temporal Logic Verifier) [21] is a computer aided ver- TION ENGINE (SWSCE) ification/synthesis system for temporal logic specifications The Semantic Web Service Composition Engine (SWSCE) [19, 20]. For a formal description of the simulation-based is a tool to perform automatic composition of SWSs and it composition algorithm, we refer to [4, 22], where theoretical can be used during the design phase of new services. In our bases to address the composition problem, along with some model, in order to compose existing (available) services, we extensions, are built. need to perform the following steps: The first step is to calculate an object called Commu- nity TS. The Community TS is the TS that represents the - selecting some services from the available ones; behavior of the whole community (i.e., set of available ser- vices which are candidate for the composition). It can be - defining a target service which represents the new ser- seen as a global view of the community. Each state of the vice satisfying the user needs; Community TS is a tuple in which are encoded the states of each available service of the community. Of course the - executing the composition algorithm and, if successful, initial state of this TS is represented by all the initial states create a new SWS. of the available services. The community TS can execute a In its current implementation, the tool works using ser- transition iff there exists one service of the community that vices described with WSML – Web Service Modeling Lan- can do that, and so it moves to the next state according to guage [11]. Some background information on WSML and the transition performed by such a service. other elements in WSMF can be found in Appendix A. In This object is exponential in the size of the TSs of the this section we will show the architecture of our tool and we available services, in fact we have to combine all states of will explain its working through a case study. the available services. TLV indeed efficiently realizes such cartesian product of the available services. 2.1 SWSCE: Architecture Then TLV checks the existence of a simulation relation In Figure 2 the SWSCE architecture is shown. SWSCE between the Community TS and the target. The simulation consists of three main blocks: (i) the User Interface, (ii) the relation is a relation on the states of two TSs. By definition Core Engine and (iii) the Repository Manager. two states a,b of two TSs are in simulation relation when (i) The User Interface makes available the composition en- if a is final, then b is final; (ii) if a can make a transition gine to the end user by mean of a user friendly interface. to a0 , then also b can make such a transition to b0 , with the In the current implementation, SWSCE is developed as a same action; (iii) a0 and b0 are still in a simulation relation. WSMO Studio 3 plug-in using the JFace/SWT library. Ac- Particular relevant is the concept of maximum simulation: tually it appears as a button inside the WSMO Studio and it the initial state of the target TS is simulated by the initial guides the developer in the composition process as a wizard. state of the Community TS. A composition of the services The Core Engine realizes all the logic needed to perform in the community realizes the target service iff the target is the computation. This component can be further divided simulated by the TS of the community. into sub-blocks, namely the Composition Algorithm, the Last step of TLV is the extraction of an Orchestrator Gen- Knowledge Base Manager and the Parser. erator (OG) from the maximal simulation. Let’s have the target service simulated by the Community TS, the orches- trator generator is a TS where: (i) the states are tuples including Community TS’s as well as target service’s state, The Composition Algorithm. This component is the one re- of course the initial state of the OG is the situation where sponsible to perform the composition. The reasoner that both target and available services are in their initial state; 3 http://www.wsmostudio.org/ (ii) for each transition of the OG we have the service selec- tion function that gives the information on which services Test # states Pellet TLV ESC can execute that transition. Therefore the OG is a TS that, 1 9 ok ok ok at each point, given an action that the client may request, 2 15 incomplete ok ok according to the target service behavior, gives back the set 3 20 out of memory ok out of memory of index of services of the community that can execute the required action. Table 1: Confronting the tools As an alternative to TLV, a Description Logic Reasoner can be used [1]. In order to generate an orchestration, we need to have a representation of the composition output. TSs representing service behaviors, written in an XML ad The PDL approach [2] consists in writing a big Propositional hoc, namely WSTSL (Web Service Transition System Lan- Dynamic Logic (PDL) formula that represents the required guage). target behavior. In this formula, we encode the behavior of TLV needs that the formulation of the problem is encoded the services, both available ones and target, and the con- into the SMV language. We encode the TSs of the services straints that have to be satisfied in order to guarantee that (target and available one) into SMV modules mutually inter- the service we are going to synthesize will be correct. More- connected through some shared variables. All modules rep- over the satisfiability of this formula is checked, and in the resent TSs. Synchronization among modules,i.e., the TSs positive case a TS is built. they represent, is realized by using some shared variables Thanks to the correspondence [23] between PDL and De- that allow to exchange relevant information. In order that scription Logic (DL) we can use a DL Reasoner to obtain everything evolves in a correct way we add some constrains the model of the PDL formula, i.e., the composition TS. At in temporal logic; in particular we define a failure assertion the state of the art there are some very efficient tools such in each available module if (i) it is requested to one avail- as Racer Pro 4 , Fact++ 5 , and Pellet 6 . Unfortunately, the able service to perform a transition that does not exist in former two are not useful for our aims, as they can check that TS, and (ii) whenever the target service reaches a fi- formulas for satisfiability but return no formula’s model, if nal state, available ones are not in their final states. In the any, which is the basic structure to extract an actual solu- main module we define an invariant property good, which tion. Pellet provides such a model but it is incomplete: it corresponds exactly to the negation of failure. TLV, then, misses some basic information for extracting a composition. tries to synthesize a strategy (or orchestrator, or controller) This is due to many optimization techniques that the tool for the problem that forces the execution to evolve in a way implements. In our experimentation of Pellet, we tried to such that disable this option in order to make a trade off by having less performance but more information. The result was a 1. no available system generates a failure; big downgrade of performances while information were still 2. the target service being in a final state implies each missing . available service being in a final state too. For a proof of concept, we implemented our own DL Rea- soner, namely ESC (E-Service Composer) [1]. ESC provides Once the OG is obtained, we easily extract from it one a good model, usable for the composition, indeed it gives the composition, choosing one service index from the set pro- composition of the target as a Mealy TS. Issues with ESC posed by the OG. The composition is saved into a WSTSL are that: (i) it is still a prototype, it lacks all optimization document, that represents the TS of the composition, ready techniques the other tools have, and it isn’t very stable; (ii) to be parsed for the orchestrator, and to be stored in the it deals only with deterministic services, that are, services orchestration engine (WSMX in our case). with a deterministic behavior, modeled with a deterministic Having an XML language to represent TSs is very useful. TS. Indeed ESC checks the satisfiability of DPDL (Deter- If there will be the need of changing the reasoner for our tool ministic PDL) that is a subset of PDL. in the future all we have to do is just to rewrite the parser TLV instead supports the composition of non determinis- for preparing the knowledge base for the new reasoner. Also tic available services, and provides good performance with we decided to use WSTSL to represent the TS of the com- stability. In Table 1 we show the results of some tests per- position because if there will be the need of changing the formed on various reasoners. The second column ”# states” execution environment for the orchestration, the tool will shows the sum of all the states of the target and the available be ready by just changing one parser: from WSTSL to the services’ TSs. This is a critical parameter for the composi- input of the new execution environment. This provides a tion algorithm; in fact when the number of states grows, we great extendibility to our tool, making it simple to change get problems. As shown in Test 2, the model returned by an orchestrator, and suitable for possible reasoners available the Pellet lacks some of important features. Increasing the in the future. number of states, as shown in Test 3, Pellet crashes satu- rating all the Java memory heap without finding a solution. The Parser Component. It performs the translation between ESC instead works good with test 2, but crashes with test the WSML representation of the services and the WSTLS 3 saturating the Java memory heap. representation of the services, and back from the WSTLS TS of the composition to the WSML representation of the The Knowledge Base Manager. This is the component re- orchestration. sponsible for preparing TLV input and extracts a composi- The Repository Manager (RM) is the block responsible for tion from the Orchestrator Generator. The input is a set of retrieving and storing the services. Actually the repository 4 http://www.racer-systems.com/ used is the one embedded in WSMX and then the RM has 5 http://owl.man.ac.uk/factplusplus/ to deal with it in order to (i) retrieve available services and 6 http://pellet.owldl.org/ using part of them, or whole, as input for the composition and (ii) store the orchestration of the composite service if it More precisely, in the in statement the concepts which repre- is found. sent the request message for the service are declared. While in the out statement the concepts which represent the re- 2.2 Related Issues sponse message returned by the service are declared. This Services composition is not a stand alone process but im- signature is the same for all states. The elements that can plies also to search services, to solve semantic incompatibil- change and that are used to express different states of a ities, to store results, etc. In this section we discuss two of choreography are the instances (and their attribute values) the main issues related to Semantic Web service composi- of concepts. Thus, a specific state is described by a set of ex- tion: discovery and mediation. plicitly defined instances and values of their attributes [24]. When we want to compose SWSs, we have to select a From a WSMO perspective, the behavior is described in- group of them that will identify the community of the can- side the choreography. The conceptual model for WSMO didates services. To build the community it is necessary to choreography is based on Abstract State Machines (ASMs). discover all the possible relevant services for the composi- A choreography in WSMO inherits the principles of ASMs tion, may be simple for a domain expert or for a service ex- by defining (i) a set of states, where each state is described pert, but it could be not so easy when we want to automate by an algebra and (ii) guarded transitions to express the this process. In the general case, an automatic discovery en- state change by means of updates. In this first version of gine eases the task of reasoning about the service signature SWSCE in order to handle all the requests coming from a (semantics of the I/O parameters, etc.) in order to select client and to perform the update operations, the transition the most suitable community. The tool presented in this condition using the forall statement have to be declared: paper does not use any discovery engine but leaves to the forall Variable with Condition do Rules(Variable) end- service engineer the task of selecting the services that will Forall. The meaning of such a rule is to execute simul- act as the input for the composition. Currently we suppose taneously the enclosed Rules for each variable in Variables that SWSCE is used by expert users. satisfying the Condition of the rule where typically a vari- Composition of services considers only the conversations able will have some free occurrences in the rules which are of the services and does not take into account the input bound by the quantifier [24]. data format. When services are defined in different ontolo- For a better explication of the sequence of actions per- gies, then there could be the need of a mediation process. formed by the service during an invocation, consider the The mediation process allows different services to represent choreography of the payTaxByBankAccount service shown the same concepts in spite of possible differences in the on- in Appendix B. tology representation. Data mediation concerns the trans- Now the service engineer can start using SWSCE by click- formation of the syntactic format of the messages exchanged ing the SWSCE button of the user interface (Figure 4). by services while the ontology mediation concerns the trans- formation of terminology used inside the message exchange. Our tool does not solve directly the mediation problem but it inserts inside the synthesized orchestration placeholders where to insert possible mediators. In Section 2.3 we show a concrete example. 2.3 SWSCE: a Practical Case In this section we presents a case study in order to un- derstand how SWSCE works. A service engineer decides to realize a SWS in which it is possible to pay government taxes Figure 4: Starting SWSCE online by providing either bank account number or personal data. First of all, he will define which is the behavior of the new SWS, by designing the TS (cfr. Figure 3). SWSCE starts by retrieving the SWSs through the RM from the repository and then shows their identifiers in the ProvideAnagraphicDetail Community table (Figure 6). It can also possible to show the WSML of the SWSs by clicking on the button Show ser- vice. The Community table contains the list of the com- PayTaxes ponent SWSs participating in the composition, i.e., in our S0 S1 example the payTaxesProvideBankAccountWS and payTax- esProvideAnagraphicalDetailsWS whose behavior is repre- sented in Figure 5. ProvideBankAccount The SWS previously designed is now selected (Figure 7) as the target service that the user wants to obtain as result Figure 3: Target Service TS of the composition. When the Start button is clicked (Figure 9), SWSCE The engineer writes the choreography of the desired ser- starts to elaborate the choreographies of the component vice. In WSMO (cfr. Appendix A) all the messages related SWSs by parsing them. If such a composition can be ob- to an operation of a SWS are considered as concepts. Those tained a new SWS is created. The new composed service concepts are used inside the choreography description in or- obtained has the choreography of the target service and it der to declare the state signature by means of the request is followed by a skeleton of a possible orchestration. The and response messages. In the state signature all the mes- Figure 8 shows the structure of the obtained orchestration. sages exchanged during the service invocation are described. In every transition rule an intermediate state has been defined by default from the algorithm. In this state possible mediators have to be declared, which allow the transition from a source state to the target state. In the obtained WSML file, the intermediate state contains a “placeholder” in which it is possible to declare the mediation: abstractStateMachine transitionRules forall {?cs} with (?cs[oasm#value hasValue oasm#S0] memberOf oasm#controlState) do //implement "perform" to invoke service PayTaxesByBankAccount delete (?cs[oasm#value hasValue oasm#S0]) add (?cs[oasm#value hasValue S0_mediation_S2]) endForall forall {?cs} with (?cs[oasm#value hasValue oasm#S0_mediation_S2] memberOf oasm#controlState) do Figure 5: Operations of component services // implement (if needed) "mediation" for // provideBankAccountRequest/provideBankAccountResponse delete (?cs[oasm#value hasValue oasm#S2_mediation_S0]) add (?cs[oasm#value hasValue S2]) endForall The WSML file of the composed service has the choreog- raphy of the target service and the orchestration obtained by the composition. Furthermore it is possible to store the com- Figure 6: Select candidate Services posed SWS obtained by means of the composition through the RM inside the repository clicking on the button Store Service (Figure 10). Figure 7: Select Target Service Figure 9: Starting the Composition t a ils D e a p h a gr S1 A n v id e p ro 3. DISCUSSION The use of Semantic Web service technologies is gaining a special role in building complex applications, e.g. as in the es Tax context of eGovernment services. In order to make it possi- pay S0 ble, many efforts in the scientific community are going in the direction of automatic services composition in order to build pa yT more complex services using the simpler building blocks as ax es component services. As we have shown in our work, in order to add semantic description to the services (in particular for pr ov id their behaviors), we need to leverage an ontology descrip- eB an kA tion. In the eGovernment domain, this approach is growing cc ou in importance and [25] provides an ontology (GEA ontol- nt S2 ogy) that models the Public Administration domain using WSMO. Figure 8: Orchestration with intermediate states In order to discuss automatic services composition, and to compare different approaches, [3] introduces a conceptual framework for “semantic service integration”, consisting of: Bouguettaya et al. * + * l. )l a * llu l. m a t e .l a H tes ci a .l ss u o l t t e + la e l. ys a t e (c g o z h t h ti a t a a eh k c s a p a e h lr e i t o l n P S cI d r b io l. a ni o its g M a r quest n o ni + t e sc K B ce re p n l. e it mn o a rvi a l. a i d taS C Pl se t r ent e t a in cli e r o e sr llu B mics Dyna e v H ra - - T - Dynamics in co mponent serv ices * do not tackle + automatic composition Figure 11: Comparison of the various approaches to Figure 10: Storing the Orchestration of the Com- automatic service composition posite Service • the community ontology, which represents the com- [26],[6]), the works of Papazoglou’s et al. [27], Bouguettaya mon understanding on an agreed upon reference se- at al. [16], Sheth et al. [9, 8], the work of McIlraith at al. [15] mantics between the services concerning the meaning and the work by Hull et al. [7, 14]. of the offered operations, the semantics of the data flow A very little research has been done following a client- through the service operations, etc; tailored approach, but some remarkable exceptions should be mentioned: the work of Knoblock at al. [17] the work of • the set of available services, which are the actual Web Traverso et al. [18], the work of Hull et al [12] and finally [2, services available to the community; 5]. Figure 11 summarizes the considered works (more details • the mapping for the available services to the com- in [3]). The three axis represent the levels of detail accord- munity ontology, which expresses how services expose ing to which the community ontology and the mappings and their behavior in terms of the community ontology; the client request can be modeled. Namely, (i) statics in the • and the client service request, to be expressed using system represents how fine grained is the modeling of the the community ontology. static semantics (i.e., ontologies of data and/or services, in- puts and outputs, alphabet of actions, etc.); (ii) dynamics in Generally, the community ontology involves several as- component services represents how fine grained is the mod- pects: on one side, it describes the semantics of the infor- eling of the processes and behavioral features of the services mation managed by services, through appropriate semantic (only atomic actions, transition systems, etc.); and (iii) dy- standards and languages (e.g., WSMO); and on the other namics in client service request represents how fine grained side, it also consider some specification of the service be- is the modeling of the process required by the client, varying haviors, on possible constraints and dependencies between from a single step (as in the case of services consisting essen- different service operations, not limited solely to pre- and tially in a single data query over a data integration system) post-conditions, but also considering the process of the ser- to a (set of) sequential steps, to a (set of) conditional steps, vice. to including loops, and up to running under the full control In building such a “semantic service integration” system, of the client. Black/white lollipops represent service-based two general approaches can be followed. (white) vs. client-based (black) approaches. • In the Service-tailored approach, the community on- The approach proposed in this paper is the first result, tology is built mainly taking into account the avail- with respect to the client-tailored approach, which uses able services, by suitably reconciling them. Indeed WSMO to describe Semantic Web services and that pro- the available services are directly mapped as elements poses a tool for automatic service composition, by providing of the community ontology, and the service request is it as a WSMO/WSMX plug-in. composed by directly applying the mappings for ac- cessing concrete computations. 4. CONCLUSION AND FUTURE WORK • Conversely in the Client-tailored one, the community In this paper we have presented SWSCE, a tool for au- ontology is built mainly taking into account the client, tomatic composition of Semantic Web services and we have independently from the services available.They are de- shown how our tool works like a wizard. Our tool actually scribed (i.e., mapped) by using the community ontol- works by retrieving SWSs through the RM in the repository ogy, and the service request is composed by reversing embedded inside WSMX. Currently we are also developing these mappings for accessing concrete computations. a new version working with a different distributed discovery engine. Actually, our tool provides support for the medi- Much of the research on automatic service composition ation by returning an orchestration where it is possible to has adopted, up to now, a service-tailored approach, exam- add manually the mediation, but in the next version we are ples are the works based on Classical Planning in AI (e.g., trying to add directly in the wizard the possibility to start the mediation tool and to define directly the mapping at the [16] B. Medjahed, A. Bouguettaya, and A. Elmagarmid. end of the composition process. Composing Web Services on the Semantic Web. Very Large Data Base Journal, 12(4):333–351, 2003. Acknowledgements. The work presented in this paper [17] M. Michalowski, J. Ambite, S. Thakkar, R. Tuchinda, is partly supported by the IST FP6 project SemanticGOV. C. Knoblock, and S. Minton. Retrieving and The authors would like to thank the project partners for Semantically Integrating Heterogeneous Data from the their useful comments and discussions on SWSCE. Web. IEEE Intelligent Systems, 19(3):72–79, 2004. [18] M. Pistore, A. Marconi, P. Bertoli, and P. Traverso. Automated Composition of Web Services by Planning 5. REFERENCES at the Knowledge Level. In Proc. IJCAI 2005. [1] D. Berardi, D. Calvanese, G. De Giacomo, [19] N. Piterman, A. Pnueli, and Y. Sa’ar. Synthesis of M. Lenzerini, and M. Mecella. ESC: A Tool for Reactive Designs. In Proc. VMCAI 2006. Automatic Composition of Services Based on Logics of [20] A. Pnueli and R. Rosner. On the Synthesis of a Programs. In Proc. VLDB-TES 2004, pages 80–94. Reactive Module. In Proc. POPL 1989. [2] D. Berardi, D. Calvanese, G. De Giacomo, [21] A. Pnueli and E. Shahar. The TLV System and its M. Lenzerini, and M. Mecella. Automatic Service Applications, 1996. Composition Based on Behavioral Descriptions. [22] S. Sardiña, G. De Giacomo, and F. Patrizi. Behavior International Journal on Cooperative Information Composition in the Presence of Failure. In Proc. KR Systems, 14:333–376, 2005. 2008. [3] D. Berardi, D. Calvanese, G. De Giacomo, and [23] K. Schild. A Correspondence Theory for M. Mecella. Automatic Web Service Composition: Terminological Logics: Preliminary Report. In Proc. Service-tailored vs. Client-tailored Approaches. In IJCAI 1991. Proc. AISC 2006 (jointly with ECAI 2006). [24] J. Scicluna, A. Polleres, D. Roman, and D. Fensel. [4] D. Berardi, F. Cheikh, G. De Giacomo, and F. Patrizi. Ontology-based Choreography and Orchestration of Automatic Service Composition via Simulation. WSMO Services. Technical report, Digital Enterprise International Journal of Foundations of Computer Research Institute (DERI), 2006. Science (IJFCS), 19:429–451, 2008. [25] X. Wang, T. Vitvar, V. Peristeras, A. Mocan, S. K. [5] D. Berardi, G. D. Giacomo, M. Mecella, and Goudos, and K. A. Tarabanis. WSMO-PA: Formal D. Calvanese. Composing Web Services with Specification of Public Administration Service Model Nondeterministic Behavior. In Proc. ICWS 2006. on Semantic Web Service Ontology. In Proc. [6] J. Blythe and J. Ambite, editors. Proc. ICAPS 2004 HICSS-40, 2007. Workshop on Planning and Scheduling for Web and [26] D. Wu, B. Parsia, E. Sirin, J. Hendler, and D. Nau. Grid Services, 2004. Automating DAML-S Web Services Composition [7] T. Bultan, X. Fu, R. Hull, and J. Su. Conversation using SHOP2. In Proc. ISWC 2003. Specification: a New Approach to Design and Analysis [27] J. Yang and M. Papazoglou. Service Components for of e-Service Composition. In Proc. WWW 2003. Managing the Life-cycle of Service Compositions. [8] J. Cardoso and A. Sheth. Introduction to Semantic Information Systems, 29(2):97–125, 2004. Web Services and Web Process Composition. In Proc. 1st International Workshop on Semantic Web Services and Web Process Composition (SWSWPC 2004). Appendix A - Introduction to WSMO [9] F. Curbera, A. Sheth, and K. Verma. Services In our approach, the implementation of the Semantic Web Oriented Architectures and Semantic Web Processes. Service composition is realized by means of the Web Service In Proc. ICWS 2004. Modelling Framework (WSMF) that provides an ontology [10] J. de Bruijn, D. Fensel, U. Keller, and R. Lara. Using (WSMO) [10] for the definition of the domain of the ser- the Web Service Modelling Ontology to Enable vices provided and of the elements characterizing each SWS, Semantic eBusiness. Communications of the ACM, that is (i) ontologies, (ii) goals, (iii) services and (iv) me- 2005. diators; a language (WSML) [11] for the formal description [11] J. de Bruijn, H. Lausen, A. Polleres, and D. Fensel. of the syntax and the semantics of all the elements defined The Web Service Modeling Language WSML: An in WSMO; and an execution environment (WSMX) [13] for Overview. In Proc. ESWC 2006. the deploy, execution, composition and orchestration of the [12] C. Gerede, R. Hull, O. H. Ibarra, and J. Su. Semantic Web services. Automated Composition of E-Services: Lookaheads. Even if in the present paper we will focus mainly on the In Proc. ICSOC 2004. description of the behavior of the SWSs, it is important to [13] A. Haller, E. Cimpian, A. Mocan, E. Oren, and briefly introduce the definition of the basic elements of a C. Bussler. WSMX - A Semantic Service-Oriented SWS in the WSMO ontology. Architecture. In Proc. ICWS 2005. A SWS description in WSMO is defined in terms of: [14] R. Hull, M. Benedikt, V. Christophides, and J. Su. • the concept representing the basic elements of the E-services: a Look Behind the Curtain. In Proc. agreed terminology concerning the domain the SWS PODS 2003. belongs to. A concept represents classes of objects of a [15] S. McIlraith and T. Son. Adapting Golog for real or abstract world that have a specific shared prop- Composition of Semantic Web Services. In Proc. KR erty (e.g., being a tax to be paid) and well defined 2002. attributes. An example of the semantic of the pay- TaxesByAnagraphicDetails service is described in the ctrfsm _"http://dis.uniroma1.it/WSMO/ControlFsm#", WSML code shown below. wsmostudio _"http://www.wsmostudio.org#" } //.. importsOntology interface byBankInterface _"http://www.semantic-gov.org/Italy#ItalianCitizen" choreography _# stateSignature byBankStSign concept AnagraphicDetails in name impliesType (1 1) _string concept pba#provideBankAccountRE dateOfBirth impliesType (1 1) { _string, _dateTime} concept pba#payTaxREQ SSN impliesType (1 1) _string out surname impliesType (1 1) _string concept pba#provideBankAccountRES concept pba#payTaxRES concept Tax transitionRules _# payToOrganization ofType _string forall {?controlstate, ?provideBankAcc} with ( amount ofType _string ?controlstate[ctrfsm#currentState hasValue 0] payBy ofType _string memberOf ctrfsm#controlledState and ?provideBankAcc memberOf pba#provideBankAccountREQ ) do • the interface describing the behavior of the SWS; add(?controlstate[ hasValue 1]) in particular the interface consists of two kinds of add(_# memberOf pba#provideBankAccountRES) information: the choereography describing how a client endForall (be it a human or a software) can interact with the forall {?controlstate, ?payTax} with ( service in order to use its functionalities, and the ?controlstate[ctrfsm#currentState hasValue 1] orchestration describing the interactions among the memberOf ctrfsm#controlledState and given service and other SWSs in order to achieve the ?payTax memberOf pba#payTaxREQ ) do target functionalities. add(?controlstate[ hasValue 0]) add(_# memberOf pba#payTaxRES) endForall In Figure 12 the different WSMO Choreography and Orchestration perspectives are illustrated. Figure 12: WSMO choreography and orchestration perspectives. The choreography describes the behavior of the service, that is, how client communicates with the service in order to consume the provided functionalities. WSMO choreography is based on the Abstract State Machines (ASM) formalisms (providing the basis for the description of both the choreog- raphy and orchestration); an ASM consists of two compo- nents: the state and the guarded transitions. The states are represented by an ontology whose content is dynamic while guarded transitions based on the model if Cond then Up- date specify transitions between states (that is changes of states). The orchestration consists in the description of how the overall functionality of the SWS is achieved through the cooperation of different service providers. In WSMO, or- chestration is based on the same ASM formalism but the guarded transitions are extended to support the use of me- diators, that is software components providing data links among different services. Appendix B In the following there is the choreography of the payTaxBy- BankAccount service: wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-flight" namespace { _"http://dis.uniroma1.it/WSMO/WS/provideBankWS#", pba _"http://dis.uniroma1.it/WSMO/payTaxesByBankAccount#",