Web services have emerged as a major technology for deploying automated interactions between distributed and heterogeneous applications. The main advantage of web services composition is the possibility of creating valueadded services by combining existing ones to achieve customized tasks. How to combine these services efficiently into an arrangement that is both functionally sound and architecturally realizable is a very challenging topic that has founded a significant research area within computer science. A great deal of recent webrelated research has concentrated on dynamic web service composition. Most of proposed models for dynamic composition use semantic descriptions of web services through the construction of domain ontology. In this paper, we present our approach to dynamically produce composite services. It is based on the use of two AI techniques: Case-Based Reasoning and AI planning. Our motivating scenario concerns a national system for the monitoring of childhood immunization.
A Web service is a software component identified by a URL, whose public interfaces and bindings are defined and described using XML. Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks [1]. This has led to the emergence of Web services as a standard mechanism for accessing information and software components programmatically [2].
Service composition refers to the technique of composing arbitrarily complex services from relatively simpler services available over the Internet. Composition of Web services enables businesses to interact with each other and facilitates seamless business-to-business or enterprise application integration. Applications are to be assembled from a set of appropriate Web services and no longer written manually [3]. For example, a composite Web service for an online order from a retailer Web site could bring together a number of internal and external services such as credit checking, inventory status checking, inventory update, shipping, etc.
Web Service Composition is currently one the most hyped and addressed issue in the Service Oriented Computing. Several models, techniques and languages have been proposed to achieve service composition.
The construction of a composite Web service can be made up in three main steps (not necessarily in this order): (a) Creation of the process model specifying control and data flow among the activities. (b) Discovery, selection and binding of concrete Web services to every activity in the process model. (c) Execution of the composite service by a coordinating entity (e.g. a process execution engine) [4].
In static composition the process model is created manually and the bindings of concrete Web services to the process activities are done at design time. Semi-dynamic composition strategies actively support the user with the creation of the process model and/or in the services selection and bindings. Finally, in Dynamic composition the creation of the process model and the services selection and bindings are made at runtime. In this paper, the focus will be done on dynamic composition of services.
The remainder of this paper is organized as follows: Section 2 presents the main ideas in dynamic composition of Web services and particularly the use of Case-Based Reasoning (CBR) and AI planning. Our proposal of using both CBR and AI planning is described in section 3, while section 4 presents a scenario as a direct application of our proposal. The paper is concluded by a discussion of the solution, some limitations, and future works.
In dynamic composition, automated tools are used to analyze a user query, and select and assemble Web service interfaces so that their composition will solve the user demand. From a user perspective, the composite service will continue to be considered as a simple service, even though it is composed of several Web services.
In order to support greater automation of service selection and invocation, recognition is growing of the need for richer semantic specifications of Web services, so as to enable fuller, more flexible automation of service provision and use, support the construction of more powerful tools and methodologies, and promote the use of semantically well-founded reasoning about services [5]. As a result, Web services have semantic descriptions in addition to their traditional standard syntactic description (WSDL). This is referred to as semantic Web services.
Semantic Web services solve Web service problems semantically and address Web services descriptions as a whole [6]. Semantic markup languages such as OWLS [5, 7], WSDL-S [8] and SAWSDL [9] describe Web service capabilities and contents in a computer-interpretable language and improve service discovery, invocation, composition, monitoring, and recovery quality.
Several methods and tools have been proposed for dynamic Web service
composition [
It is not in the scope of this paper to present an exhaustive list of all methods and techniques proposed for dynamic composition. In this work, we are particularly interested in the use of CBR and AI planning in order to achieve a dynamic composition.
IA Planning is certainly the area that offers the most operational solutions in
dynamic composition of services [
On the other hand, recent research used CBR efficiently in dynamic (or semidynamic) Web service composition. We aim to apply CBR over an AI Planner. The idea is that the used plans are generated by an AI planner and whenever a new query is given the system first attempts to get a solution from the stored cases. If no similar case is found, or in case of unsatisfactory solution: a planner is used to generate a new solution from scratch.
The following subsections present the main ideas in using AI planning and CBR for dynamic Web service composition.
Let’s recall that a planning problem can be defined as a five tuple <S, S0, G, A, Γ>
where, S is the set of all possible states of the world, S0⊂S denotes the initial state of
the world, G⊂S denotes the goal state of the world that the planning system attempts
to reach, A is the set of actions the planner can perform in attempting to change one
state to another state in the world and the transition relation Γ⊂SxAxS defines the
precondition and effects for the execution of each action [
e t iso e p ic oCm rsve
OWL & OWL‐S descriptions OWLS2PDDL Translation PDDL2OWLS Translation Plan
PDDL planning description
A simple analogy can be made between a Web service composition problem and a planning problem as follows: consider the user query as the initial state (S0) of the world; the set of available Web services represents the set (A) of actions; Web service inputs (resp. ouputs) represent the precondition (resp. effects) of the corresponding action. This correspondence makes it possible to transform a Web service composition problem into a planning problem. Then, an AI planner can be used to derive a plan to offer an acceptable solution to the user query.
This transformation can be done by translating the original description of the
problem into a description which corresponds to a planning problem. A Web service
composition problem is often described using the OWL-S language [7]. This
description is referred to as the external specification. On the other hand, the PDDL
language [
Many research works [
Case-based reasoning is a problem solving paradigm that in many respects is
fundamentally different from other major AI approaches [
RETRIEVE
Problem Confirmed
Solution
RETAIN
Case‐Base
REVISE
During the last few years, many research works used CBR in Web service composition. We present in the following the main ideas published in this area.
Lajmi et al. [
Osman et al. [
Recently, Lee et al. [6] build a prototype that combines planning and CBR for
dynamic service composition. The work accepts a service request from a user through
intent analysis producing a goal model by extending the service request with
keywords representing the user intent. CBR is used to provide composite services
quickly. The tool JSHOP2 [
Our approach to dynamically produce composite services is based on the use of case-based reasoning and AI planning. We apply CBR to store planning and related information in a case base to create planning much faster when users have similar needs. The overall architecture of the system is depicted in figure 3.
A case is a triplet consisting of the goal model extracted from the query, the corresponding OWL-S solution and an outcome. The goal model is used as features for case searching and matchmaking.
User
Interface (a)
Initial state ontology Goal state ontology
OWL domain ontology OWL‐S WS descriptions (b)
Execution
Engine WS Storage (h) (d) ? (c)
Plan adaptation (g)
PDDL planning
domain PDDL planning
problem
(f)
(e)
a) A new query is introduced via the user interface. This query is considered as a
new case and is semantically annotated using OWL-S.
b) The case retrieval module tries to find a match for the new case in the case base.
c) Unless the retrieved case is an exact match, an adaptation of the corresponding
solution is necessary.
d) When no matches exist, or in case or unsatisfactory solution, the new problem is
translated into a planning problem.
e) An AI planner is used to derive a new plan for the translated problem. Our
system uses OWLS-Xplan2.0 [
The execution engine binds the composite service activities to concrete Web services (by querying service registries) and returns the resulting composite service to the user. An evaluation of the proposed solution is then made. Depending on the evaluation the new case can be stored in the case base.
Our prototype for dynamic Web service composition is currently applied in a national research project (PNR 12/u310/65) [24] that concerns the Monitoring of Childhood Immunization (MCI) in Algeria. The system presently underway aims to have total immunization coverage and an access to the immunization status of every child from any department all over the country. In order to insure that every child is immunized according to a fixed calendar a vaccination notebook (VN) is established and maintained by the immunization monitoring service (IMS). This notebook is generated by the IMS of the municipality where the child was born (city of birth CB). Every municipality is attached to an IMS which in turn monitors several immunization services (IS). Children are dispatched into different ISs according to their parents’ address (PA at birth date).
The information manipulated by the MCI system comes from many sources: a) The birth registry located at the municipality: Information about the child’s name, date of birth, parents’ names, hospital of birth, name of the doctor, etc. b) The address registry located at the municipality: Information about the IS a child is assigned to according to his PA and to the urban cutting. c) The vaccination notebooks registry located at an IMS: The history of previous vaccinations for a given child and the schedule of incoming immunizations.
Parents
MCI‐UDDI Birth WS
MCI System Address
WS
IS staff VN WS
IMS office manager
Web services are used to access each registry. Every municipality and every IMS has its own registries. And even though the structure of information stored in different municipalities or IMSs is roughly the same (e.g. the birth registry), different Web services should be implemented because of particular considerations (e.g. use of different DBMS). It means that the activities are exactly the same for all municipalities and IMSs, but each of which may rely on a different technological platform. All Web services are advertised in a private UDDI called MCI-UDDI. Figure 4 depicts the overall functional structure of the MCI. Domain ontology is developed which allows giving OWL-S annotations for published Web services.
Queries to the MCI system come from different types of users and each query triggers a composition of services depending on the information given by the user (CB, PA, ..), the type of user, and the desired result. 5.
We presented a solution that combines CBR and AI planning for dynamic
composition of services. Instead of testing the solution on simulated Web services we
have chosen to apply our proposal on a real example. The use of CBR gives a way to
memorize past experiences in order to reuse previous successful solutions. As a result,
a solution is provided quickly. On the other hand, the use of AI planning allows
proposing a solution when no previous similar cases exist or when the proposed
solution does not satisfy the user. AI planning also allows populating the case base
when applying our solution in a new domain. The advantage of using PDDL is to
pave the way toward the use of a wide range of planners. Moreover, in addition of
using an existing planner, we are implementing a new AI planner that utilizes the
principle of the cellular machine [
A few issues in the use of CBR are still under examination. In particular we are
experiencing the use of decision trees to improve the similarity calculus as in [
Semantic Annotations for WSDL and XML Schema – Usage Guide. Available at: http://www.w3.org/TR/sawsdl-guide/. projects. 24. Accepted PNR
pnr/PNR_a.htm.