Implementation Issues for Automatic Composition of Web Services

2010 Workshops on Database and Expert Systems Applications

Implementation Issues for Automatic Composition of Web Services Juan Carlos Zu˜niga

Jos´e J. P´erez-Alc´azar

Luciano Digiampietri

Department of Electrical Engineering University of Sao Paulo Email: [email protected]

School of Arts, Sciences and Humanities University of Sao Paulo Email: [email protected]

School of Arts, Sciences and Humanities University of Sao Paulo Email: [email protected]

Abstract—Service Oriented Computing (SOC) is a computing paradigm for the agile development of software based on the orchestration of loosely-coupled services. Services perform functions from the solution of simple atomic requests to execution of complex business processes. Nowadays, new services are created from the manual composition of basic Web Services. It is an arduous and susceptible to errors task. To avoid this problem, it is necessary the existence of discovery and automatic composition mechanisms.This paper presents the specification of a architecture and implementation of a prototype for the automatic composition of Web Services using Artificial Intelligence planning techniques and the WSMO ontological model. Moreover, the paper contains a discussion about design and implementation choices and further improvements.

I. I NTRODUCTION Semantic Web arises from the ideas of Web’s creator, Tim Berners-Lee, of enriching the data in the Web with annotations in order to make this data intelligible by machines. Thus, the Web resources (data and applications) could be automatically discovered and processed [1]. The notion of Ontologies turns these ideas feasible [2]. Ontological languages, such as OWL and RDF, besides allow the semantic annotation of data and applications also provide inference mechanisms and data integration using automatic reasoning on the ontological structures. However, the Web is composed of static and dynamic resources, such as data, remote applications and services [3]. Both, static and dynamic resources, must be annotated. The semantic Web services are Web services enriched with a semantic annotation of their interfaces and functionalities. In the same way that ontologies make easier the automatic integration of data, they also provide the base for automatic discovery, composition monitoring and execution of services. The automatic composition of services can be seen as the evolution of the traditional service oriented systems, providing several benefits in areas such as: e-business and knowledge management. This paper proposes the architecture for the automatic composition of Web services using Artificial Intelligence (AI) planning and the ontological model WSMO (Web Services Modeling Ontology) [4] for the semantic description of services. Moreover, this paper describes the implemented prototype and a discussion about design and implementation choices and further improvements.

1529-4188/10 $26.00 © 2010 IEEE DOI 10.1109/DEXA.2010.54

II. BASIC CONCEPTS In order to use a Web Service, a software agent needs to know the description of the service and the way to access it. Moreover, these shared descriptions must be understood by any software agent that wants to use it. A solution for sharing conceptualization of resources is the use of ontologies. Ontology is a formal and shared representation of concepts and of the relations among concepts. In order to capture semantic properties of concepts and relations, ontologies provide a set of axioms, expressed in some logical language [4]. Ontological models, such as, OWL-S (Web Ontology Language for Services) [5], WSMO (Web Services Modeling Ontology) [4] and WSDL-S (Web Service Description Language for Services) [6] provide the infrastructures for the development, discovery and execution of Semantic Web Services. OWL-S is an ontology based on OWL (Ontology Web Language) for the definition of Web Services. The reaches and limitations of the Semantic Web Services based technologies were evaluated in [7]. III. AUTOMATIC COMPOSITION OF W EB S ERVICES The combination of several Web Services to achieve a given functionality is called: “Web Services Composition” and can be made manually or (semi-)automatically using computational algorithms. The manual composition is a complex task and susceptible to errors, due the dynamism and flexibility of the Web. Thus, there are several research efforts in the industry and academy to develop mechanisms for the “Automatic Composition of Web Services” [8]. In order to compose Web Services automatically, it is necessary: (i) an ontological model to allow the semantic description the Web Services; and (ii) inference mechanisms or techniques to reasoning over the semantic descriptions of the services. Among the inference mechanisms, we highlight the ones based on AI Planning [9]. Approaches based on Artificial Intelligence Planning study the deliberation process to choose and organize actions in order to reach some predefined goals in the best way possible [10]. However, to apply the planning algorithms in the automatic composition of Web Services, it is necessary to extend them with characteristics typically disregarded in the

201

classical planning. This extension is necessary because the Web is a dynamic and non-deterministic environment. There are several works discussing planning techniques for the automatic composition of Web Services [8], [11]–[14]. Some of the most interesting approaches uses hierarchical planning [15] combined with the ontological model OWLS [5] to allow Web Services automatic composition [16], [17]. However, the classical hierarchical planning does not provide support to non-determinism. To deal with this problem it was necessary to use non-deterministic planning techniques or to extend some planning techniques [10], [18]–[20]. Moreover, the automatic composition of Web services using planning can be classified in two classes of proposals: (i) the first ones use services parameters to establish connections or matches among services [21]; and (ii) the proposals that consider pre and post conditions (i.e. the functional description of the services [22]) to establish the connections or matches among services [15]. It is important to note that the use of each class determines several characteristics of the resulting composition and can limit the capabilities and range of the composition system. The first class presents the advantage of easy modeling because the order of the services is defined for the parameters (input and output) of the services. Even with the use of ontologies, this kind of approach only consider parameters matching without takes in account the state of the world. In the other hand, the approaches that use pre and post conditions of each service takes in account, besides the parameters, the state of the world. This kind of approach has the disadvantage of being harder to model, but allows the creation of better composed services avoiding several kinds of errors not considered in the first class of approaches. In this work we implemented a prototype considering these two classes of approaches. IV. T HE P ROPOSED A PPROACH The goal of this work is to specify an ideal architecture and discuss the implementation issues of our prototype for the automatic composition of Web Services using Artificial Intelligence planning techniques. A. Architecture Figure 1 presents the proposed architecture. Each box of the figure represents a module of the system and the arrows correspond to interactions among the modules. - The Interface module is responsible for the interaction between the user and the rest of the system. It allows the user to request for a goal, i.e., to specify the application domain, the desired goal and some restrictions. Each domain allows some specific goals and these goals are specified according with the ontological language used; - The Discovery Module receives the user’s request and searches in the Service Repository for services that satisfy the request. If one or more services in the knowledge base fit the user request fulfilling all the restrictions, these services are identified by the discovery module and sent to the Executor. If

Fig. 1.

Semantic Web Service Composition Architecture

no service can satisfy the request, the Composition Process is started to produce a composed service that satisfy the request. - The Translator module receives the user requests and translates them to the language understood for the planner. - The Planner is the reasoning module of the system. It receives a request written in the planning language and uses planning techniques to produce one or more solutions plans (solutions are composed Web Services that satisfy the user’s request). The plans are sent to the Evaluator module that will choose which one best suits the user’s request. - Whenever more than one plan is produced, the Evaluator module chooses the one that best fit the user’s request. In order to do this, the Evaluator take in account the non-functional properties of the services that compose the plan; - The Executor module receives a plan and maps each activity in the plan to the corresponding Web services in the invoking level. After the execution of the plan, the results are presented to the user. If a fail occur during the execution of a plan, a replanning process can be requested by the Executor to the Planner. In our prototype, the Executor, Evaluator and Planner modules change messages using the PDDL language. B. Prototype: Implementation Issues As follows we describe how each module of the proposed architecture was implemented in our prototype: 1) Interface: The Interface Module allows the user to specify a request. To start the specification, the user chooses the application domain. Each application domain contains a set of services which represents the goals that the user can achieve and they are described using WSML [23]. Besides the domain and the goals, the user can also specify some restrictions. These restrictions can define the initial state of the problem. For example, a user can choose the domain “travel agency” and the goal is “to obtain a itinerary”, the restrictions must specify, at least, the origin and the destiny of the travel, and can have additional information such as preferential kind of transportation (train, airplane, etc). Since the restrictions range from one domain to another, it is desired to construct specific input interfaces for each domain in order to help the user to fill the specific restrictions. Moreover, 202

Fig. 2.

Fig. 3.

PDDL Domain - Pre and Post Conditions Matches Services Model

Fig. 4.

PDDL Problem - Pre and Post Conditions Matches Services Model

Mapping between WSML and PDDL

it is important to notice that the fulfilling of the restrictions is a complex task and the amount and level of detail of the restrictions varying according to the domain that is being used. 2) Discovery: In our prototype, the Discovery Module was not implemented, all the services (composed or not) are identified by the Planner Module in the Composition Process. 3) Translator: In our prototype, the translator is responsible for translating the goal specification in WSML to a problem and a domain specification in PDDL (Planning Domain Definition Language) [24]. A PDDL problem is specified as an initial state, a goal state and a domain composed of operations, objects and axioms. The initial and final states are defined according to the specification of the capabilities of the WSML goal, in particular, the initial state is produced using the restrictions described in Interface Module (pre-conditions and assumptions); and the final state is produced using the postconditions and effects. In PDDL there is no explicit behavior description of a Web service, hence, our prototype will not deal with this part of the service specification. Our Translator does a mapping between the languages WSML and PDDL. This mapping considers the structures of both languages (actions, predicates, parameters, etc). Figure 2 presents parts of this mapping that was developed based on a technical report [25] from the creators of WSML. This report presents the equivalence between WSML and OWL terms. The translation process depends of the composition approach that is being used (see Section III). In the “pre and post condition matching” the planning domain is modeled including the business logic, the pre and the post conditions. The business logic represents the functionalities of the Web Services, for example, a Web Service that searches for a flight between two cities must verify, in the business logic, if the origin and destiny cities are not the same. The business logic is described in the planning domain using pre conditions, post conditions, predicates and parameters as showed in Figure 3. The planning problem is composed for an initial state and a goal. The initial state is created using the restrictions defined by the user and the instantiation of the domain ontology, i.e. the possible values that the ontology concepts can assume. For example, for a Web Service that searches for flights between cities, the airport concept must be defined in the domain

ontology. When this concept is instantiated, it can assume a set of values (such as, Guarulhos, Jorge Chaves, etc). Thus, the planning problem modeled based on “pre and post condition matching” will have its initial state as presented in Figure 4. In the other hand, in the planning considering the approach “parameters matching”, the planning domain describes only the parameters (input and output) of the services. For example, the Web Service that searches for a flight between two cities need to verify only if the parameters origin and destiny of the flight belong to the type airport, without verify, for example, if the origin and destiny airport are the same. This planning approach uses a model easier to specify, but it has smaller capability of representing complex domains. 4) Planner: In our prototype, the Planner receives the PDDL problem and domain specification and tries to produce a composed service that solves this problem. The automatic composition of Web services is characterized, among other thing, for the non-deterministic behavior of the Web, i.e., during the planning it is impossible to precisely foresee the state of the world produced by the execution of a service [26]. The execution of a service can lead to a set of alternative states, thus, the artificial intelligence classic planning [27] must be extended to deal with this kind of problems. The planner used in our prototype was extended to deal with these characteristics, as it will be describe as follows. ND-SHOP2 [10] is a planner for non-deterministic domains that uses the decomposition in Hierarchical Task Network (HTN), defined in the SHOP2 algorithm [28] to solve prob203

lems. The HTNs in ND-SHOP2 provide specific domain information to restrict the search space of the planner. During the planning, among the actions applicable for some state, ND-SHOP2 will only consider the ones that can be obtained for the HTN decompositions, i.e., it will avoid the verification of great part of the search space [29]. Kutter and Nau [10] presented a methodology to extend any classic planner based on progressive search to work in non-deterministic domains. The SHOP2 planer was one of the planners considered for this extension, and the result is ND-SHOP2. Herrmann [30] prototyped an extension in Haskel [31] called ND-HSHOP2. Non-deterministic planners, such as ND-HSHOP2, produce plans in the form of policies. A policy describes a solution from a state machine [27]. This planner was used in our prototype, for that, we developed an interface to connect the planner with the rest of the system. Since there is no Java API for ND-HSHOP2, in our prototype we developed a small system to run, in background, the Haskell compiler and pass the parameters (domain and problem) to the ND-HSHOP2 planner. The planer produces all policies that solve a given request. These policies are represented as a sequential set of action and the parameters associated with each action. 5) Evaluator: The Evaluator uses non-functional properties to select among the policies which one is the best fit the user goals. A well elaborated process of evaluation and selection can be obtained with the use of techniques from Quality of Services (QoS) researches [32]. The current version of our prototype select as best policy the one that contains the best individual services, i.e., instead of considering the plan as a whole, it consider the quality and cost of the services individually. But it will be improved in the next versions. 6) Executor: The policy selected by the Evaluator is translated from PDDL to service calls in WSDL (invocation level). The grounding mechanism (“lowering”) [33] is defined in a way that the policy can be executed. The execution process follows the sequence of tasks presented in the policy. If one service of the policy been executed presents an execution error, then the next policy is executed. If an error occurs and there is no other policy to be executed, an error message is sent to the user. V. P ROTOTYPE : T HE B RAVO A IR C ASE S TUDY In order to implement a case study, we modeled a semantic application domain and implemented a graphical user interface to allow the user to fill her/his requests. A. The Bravo Air Domain The Bravo Air application domain represents a fictitious airline company. This example is frequently used in the Semantic Web case studies [34]. The services provided by Bravo Air allow the reservation of flights. In order to do a reservation, some information is need: origin airport, destiny airport, departure date and, if it is round trip, the return date. If the intended flight is available, a list of valid itineraries for the chosen route is presented to the user. The user chooses the preferred itinerary and does the reservation of the flight.

Fig. 5.

Bravo Air User Interface

B. The Modeling of Bravo Air Domain One of characteristics of Semantic Web based applications is that all concepts and relationships among concepts must be clearly defined in a domain ontology. Therefore, we specified the Bravo Air domain ontology which defines concepts such as: Airport, Itinerary and ItineraryList; and the instances of the concepts. Besides, the domain ontology, it is necessary to specify the dynamic involved in Bravo Air domain. This modeling is made using a service ontology to describe the semantic Web services associated with the domain. The semantic Web services contain semantic information about pre and post conditions, effects and non-functional information about the services. In our case study, the semantic Web services are specified using WSMO. All the semantic Web services associated with the Bravo Air domain are translated by the Translator to the planner language (PDDL) and to the language for service invocation (WSDL). In order to execute a resulting policy, we developed a mapping between the semantic Web services from the policy (described in WSML) to the services described in WSDL. This mapping mechanism (called Grounding) can be specified using links in the WSML or adding semantic annotation to the WSDL [7]. In this case study, we used SAWSDL semantic annotations. Thus, we first developed the Web services (and their WSDL description) and then added semantic annotations to these services using the WSMO Studio tool [35]. C. Automatic Composition for the Bravo Air Domain Figure 5 presents the graphical interface developed to allow the user to do requests using the Bravo Air. This interface allows the user to specify the goal and the restriction: origin airport, destiny airport, departure and return dates. The way the system will produce a solution for the user’s request depends on the approach used in the construction of the planning problem. In the “parameters matching” approach, the restrictions specified in the Bravo Air User Interface are used only by the Executor in the execution time. In the “pre and post conditions matching”, these restrictions are used in the policies construction (in planning time). The produced policies must be read, interpreted and executed by the Executor Module. When the Executor Module 204

read a policy and finds an action it associates this action with the corresponding Web service and uses the parameters of the action as the input parameters of the service. VI. C ONCLUSIONS AND F UTURE W ORK The definition of a Semantic Web Service Composition Architecture is a composed task that includes the use of several languages, tools and technologies that are in developing process. The prototyping of this architecture showed that the integration of these technologies with the existing planners is a non-trivial task. Besides, the semantic modeling of a domain (including concepts, relationships and services) requires a great understanding of the domain and of the planning approach that is being used. The developing of graphical interfaces to help the user to specify her/his requests is a challenging task because it depends on the domain that is being used, the level of details desired and the planning approach used. We implemented a first approach to the automatic composition of semantic Web services. It was able to receive user’s request, processed than, produce policies and execute these policies. In the other hand, several modules must be improved in order to fulfill all the user needs for this kind of framework. As future work, we intent to improve the prototype, validate it with more complex case studies and include partial observation of the state of the world in the executor. ACKNOWLEDGMENTS This work was partially financed by FAPESP, processes: 2006/04334-7, 2008/06509-4, 2009/10413-5. R EFERENCES [1] T. Berners-Lee, J. Hendler, and O. Lassila, “The semantic web,” Scientific American Magazine, 2001. [2] N. F. Noy and D. L. McGuinness, “Ontology development 101: A guide to creating your first ontology,” Knowledge Systems Laboratory Stanford University, Tech. Rep., 2001. [3] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web services: concepts, architectures and applications. Springer Verlag Berlin, 2004. [4] D. Fensel, H. Lausen, A. Polleres, J. de Bruijn, M. Stollberg, D. Roman, and J. Domingue, Enabling Semantic Web Services: The Web Service Modeling Ontology. Springer-Verlag New York, Inc., 2007. [5] D. Martin, M. Burstein, J. Hobbs, O. Lassila, D. McDermott, S. McIlraith, S. Narayanan, M. Paolucci, B. Parsia, T. Payne, E. Sirin, N. Srinivasan, and K. Sycara, “Owl-s: Semantic markup for web services,” W3C, Tech. Rep., 2004. [6] R. Akkiraju, J. Farell, J. Miller, M. Nagarajan, A. Sheth, and K. Verma, “Wsdl-s: Web service semantics,” W3C, Tech. Rep. URL: http://www.w3.org/Submission/WSDL-S/, 2005. [7] K. S. de Souza, J. P´erez-Alc´azar, L. A. Digiampietri, and J. C. Zuniga, “Um estudo comparativo de frameworks para desenvolvimento de aplicac¸o˜ es baseadas em servic¸os web semˆanticos,” Revista Eletrˆonica de Iniciac¸a˜ o Cient´ıfica (REIC), vol. 9, no. 2, junho 2009. [8] J. Rao and X. Su, “A survey of automated web service composition methods,” in Proc. Of the 1st International Workshop on Semantic Web Services and Web Process Composition (SWSWPC), 2004. [9] S. Russel and P. Norvig, Artificial Intelligence: A Modern Approach, 2nd ed. Prentice-Hall, 2003. [10] U. Kuter and D. Nau, “Forward-chaining planning in nondeterministic domains,” in AAAI 2004, 2004. [11] J. Peer, “A pddl based tool for automatic web service composition,” in Proceedings of Second International Workshop on Principles and Practice of Semantic Web Reasoning, St. Malo, France (6th–10th September 2004), ser. LNCS, vol. 3208. REWERSE, 2004.

[12] A. Alamri, M. Eid, and A. E. Saddik, “Classification of the state-of-theart dynamic web services composition techniques,” International Journal of Web and Grid Services, vol. 2, no. 2, pp. 148–166, 2006. [13] L. A. Digiampietri, J. P´erez-Alc´azar, and C. B. Medeiros, “Ai planning in web services composition: A review of current approaches and a new solution,” in VI Encontro Nacional de Inteligncia Artificial, Anais do XXVII congresso da SBC, 2007. [14] E. Sirin and B. Parsia, “Planning for semantic web services,” in In Semantic Web Services Workshop at 3rd International Semantic Web Conference, 2004. [15] E. Sirin, B. Parsia, D. Wu, J. Hendler, and D. Nau, “Htn planning for web service composition using shop2,” in Web Semantics: Science, Services and Agents on the World Wide Web In International Semantic Web Conference, vol. 1, no. 4, 2004, pp. 377–396. [16] A. N. da Silva, “Composic¸a˜ o autom´atica de web services: Avaliando os planejadores jshop2 e jess,” Departamento de Ciˆencia da Computac¸a˜ o da Universidade Federal da Bahia, Tech. Rep., 2007. [17] M. Klusch, A. Gerber, and M. Schmidt, “Semantic web service composition planning with owls-xplan,” in Proceedings of the 1st Intl. AAAI Fall Symposium on Agents and the Semantic Web, 2005. [18] P. Bertoli, A. Cimatti, M. Pistore, M. Roveri, and P. Travesso, “Mbp: A model based planner,” in Workshop on Planning under Uncertainty IJCAI, 2001. [19] H. Q. Yu and S. Reiff-Marganiec, “Semantic web services composition via planning as model checking,” Department of Computer Science, University of Leicester, UK, Tech. Rep., 2004. [20] P. Doshi, R. Goodwin, R. Akkiraju, and K. Verma, “Dynamic workflow composition: Using markov decision processes,” International Journal of Web Services Research, vol. 2, no. 1, pp. 1–17, Jan-March 2005. [21] S.-C. Oh, D. Lee, and S. R. T. Kumara, “Web service planner (wspr): An effective and scalable web service composition algorithm,” International Journal of Web Services Research, vol. 4, no. 1, pp. 1–22, 2007. [22] D. Shin, K. Lee, and T. Suda, “Automated generation of composite web services based on functional semantics,” Web Semantics: Science, Services and Agents on the World Wide Web, vol. 7, no. 4, pp. 332–343, Dec 2009. [23] J. Brujin, D. Fensel, M. Kerrigan, U. Keller, H. Lausen, and J. Scicluna, Modeling Semantic Web Services. Springer-Verlag Berlin, 2008. [24] M. Ghallab, A. Howe, C. Knoblock, D. Mcdermott, M. Ram, M. Veloso, D. Weld, and D. Wilkins, “Pddl - the planning domain definition language,” in AIPS-98 Planning Committee, 1998. [25] N. Steinmetz, J. de Bruijn, A. Frankl, and T. version:, “Wsml/owl mapping,” WSML Working Draft, Tech. Rep., 2008. [26] B. Srivastava and J. Koehler, “Web service composition - current solutions and open problems,” in Workshop Planning for Web Services (ICAPS), 2003. [27] M. Ghallab, D. Nau, and P. Traverso, Automated Planning, Theory and Practice. Morgan Kaufmann Publishers, Elsevier, 2004. [28] D. Nau, T. Au, O. Ilghami, U. Kuter, W. Murdock, D. Wu, and F. Yaman, “Shop2: An htn planning system,” Journal of Artificial Intelligence Research (JAIR), 2003. [29] U. Kuter, D. Nau, M. Pistore, and P. Traverso, “Task decomposition on abstract states, for planning under nondeterminism,” Artificial Intelligence, vol. 173, no. 5, pp. 501–788, 2008. [30] R. G. Herrmann, “Planejamento hier´arquico sob incerteza knightiana,” Master’s thesis, Instituto de Matem´atica e Estat´ıstica da Universidade de S˜ao Paulo, 2008. [31] S. P. Jones and J. Huges, “Haskell 98 language and libraries,” Haskell, Tech. Rep. URL: http://haskell.org, 2008. [32] V. Agarwal, G. Chafle, K. Dasgupta, N. Karnik, A. Kumar, S. Mittal, and B. Srivastava, “Synthy: A system for end to end composition of web services,” Journal of Web Semantics, vol. 3, no. 4, 2005. [33] J. Kopecky, M. Moran, T. Vitar, D. Roman, and A. Mocan, “Wsmo grounding,” W3C, Tech. Rep. URL: http://www.wsmo.org/TR/d24/d24.2/v0.1/, 2007. [34] R. Lara, D. Roman, A. Polleres, and D. Fensel, “Owls 1.0 release - examples bravo air fictitious airline site,” W3C, Tech. Rep. URL: http://www.daml.org/services/owl-s/1.0/examples.html, 2003. [35] M. Dimitrov, A. Simov, M. Konstantinov, L. Cekov, and B. Norton, “Wsmo studio,” WSMO, Tech. Rep. URL: http://www.wsmostudio.org/, 2009.

205