This chapter presents a comprehensive logic programming framework designed to support intelligent composition of Web services. The underlying model relies on the modeling of Web services as actions, each described by a logic programming theory. This view allows the use of logic-based planning to address the Web service composition problem, taking advantage of the fact that logic-based planning enables the elegant introduction of a number of extensions and generalizations (e.g., dealing with incomplete knowledge and preferences). The theory describing each Web service is encoded as a logic programming module, and different semantics are allowed within different modules, thus better reflecting the practical use of different service description formalisms and ontologies.
TopIntroduction
One of the main goals of the Semantic Web initiative (Berners-Lee, Hendler, & Lassila, 2001) is to extend the existing Web technology to support the development of intelligent agents, which can automatically and unambiguously process the information available in millions of Web pages. This led to numerous works on Web services and Web service composition. The primary goal of Web service composition is to determine an appropriate sequence of Web services to accomplish a user goal. The majority of the existing proposals dealing with Web service composition build on the principle of viewing Web services as actions, thus, representing the Web service composition problem as a planning problem that can be addressed using existing planning techniques. A second popular approach to Web service composition relies on techniques developed in the area of workflow development. The survey by Rao and Su (2004) provides a good overview of various proposals for Web service compositions.
McIlraith and Son (2002) propose to use GOLOG (Levesque, Reiter, Lesperance, Lin, & Scherl, 1997), a logic programming based language, for Web service composition. In such a proposal, each Web service is translated to a primitive action. GOLOG provides control-flow constructs, such as if-then-else, while-do, sequence (denoted by ‘;’), procedure, and test (denoted by ‘?’), which can be used to combine the primitive actions into programs. The resulting programs can be provided to a GOLOG interpreter for finding the sequence of Web services that need to be executed to achieve the goal of the user. Alternatively, the program can be given to an execution monitoring module, for direct execution. Sufficient conditions for a successful execution of a program are also provided. This direction of work has been adopted by Au, Kuter, and Nau (2005), Kuter, Sirin, Nau, Parsia, and Hendler (2005), and Wu, Parsia, Sirin, Hendler, and Nau (2003), where SHOP2, a hierarchical planning system, is used as the underlying system for automatic Web service composition. The latter work also addressed an important aspect of Web service composition, namely, the problem of incompleteness of information in Web service composition, by adding to the planning algorithm a module for gathering information during the planning process.
Viewing Web service composition as high-level planning is not only natural, but also advantageous for different reasons:
- •
AI planning has made remarkable progress in the last 10 years, and several robust and scalable planning systems have been developed and are available for use, such as FF (Hoffmann & Nebel, 2001), SHOP (Nau, Cao, Lotem, & Muñoz-Avila, 1999), SAT-based planners (Kautz & Selman, 1996), and logic programming based planners (Lifschitz, 1999). All these planners can be used as the backbone in the development of systems for Web service composition with an architecture similar to the one described by McIlraith and Son (2002).
- •
AI planning allows the Semantic Web research community to focus on the development of Web service representation and reasoning languages and tools for translating Web service representation into a planning language.
Indeed, this view of Web service composition has been embraced by many researchers, and a number of tools have been proposed, for example, translators to map Web services encoded using DAML-S or OWL-S to PDDL (PDDL Technical Committee, 1998), a well-known planning language used by many planning systems.