Download Survey and Comparison of Planning Techniques for Web Services

Survey and Comparison of Planning Techniques for
Web Services Composition
K. S. May Chan1, Judith Bishop1 and Luciano Baresi2
1
University of Pretoria, Department of Computer Science
0002 Pretoria, South Africa
[email protected], [email protected]
2
Politecnico di Milano, Dipartimento di Elettronica e Informazione
Piazza L. da Vinci 32, I-20133 Milano, Italy
[email protected]
Abstract:
Web services are created and updated on-the-fly. Manual composition cannot foreseen the change
and adapt to the dynamic environment. Different AI planning techniques have been proposed to
facilitate automatic composition of Web services. Planners have been developed to help with the
composition based on these techniques. The adequacy of these planners is vital for correctness of
Web service composition. In this paper we investigate the recent research efforts of automatic Web
services composition from the AI planning research community. Two sets of criteria – properties
and control structure are compared. The result of this comparison shows HTN planning at this
stage has various advantages over the other AI planning techniques.
.
1
INTRODUCTION
“A Web service is a software system designed to support interoperable machine-to-machine
interaction over a network. It has an interface described in a machine-processable format
(specifically WSDL). Other systems interact with the Web service in a manner prescribed by its
description using SOAP messages, typically conveyed using HTTP with an XML serialisation in
conjunction with other Web-related standards” – [4]
The basic Web services architecture, described in the above definition, suffices to implement
simple interactions between a client and a Web services. However, a single Web service is not
1
proficient at performing complex tasks. Therefore, it is necessary to combine the functionality of
several Web services. The process of combining and linking existing Web services to create new
Web processes is known as Web service composition. The end product of the composition is called
a composite service [1], [16]. The participating services involved in the composition can
themselves be either simple or composite services.
For example, a loan application involves various functions and there is no one single service for
performing this task. A loan service is comprised of four other services, namely ReceiveInput,
invokeCR, invokeStarLoan and invokeUnitedLoan. ReceiveInput initiates the composition process
by receiving input from the client while sending information to the GetCredit activity. GetCredit is
comprised of one Web service called invokeCR that checks the credit rating of the applicant and
GetLoadOffer selects an offer from one of these two banks and approves the loan offer. It has two
Web services, invokeStarLoan and invokeUnitedLoan. The workflow for the composed service is
shown in Figure 1.
Several low-level process modelling and execution standards have been proposed for the
composition of Web services. One of the most prominent standards for composition is the Business
Process Execution Language for Web Services (BPEL4WS) [2]. These standards allow developers
to implement composite services using simple monolithic blocks. Such composition processes
require manual implementation by the developers. Therefore, the process is hard, time consuming
and often error prone. For Web services to reach their full potential, the composition process needs
to be automated. To do this, semantics should be added to the service description. Therefore, the
Semantic Web is used where services are described in a top-down and unambiguous way, with
languages such as OWL-S1 [18] Such description aids the automation of various kinds of tasks,
such as discovery and composition.
To make best use of Web services they should have the ability to perform automatic composition.
Recently, AI planning techniques have been proposed as a way to automate Web services
composition [5, 21, 24, 30, 36]. To effectively identify the most suitable planning techniques for
Web service composition a comparison is required.
1
Formally known as DAML-S.
2
Figure 1: Workflow for a composed loan Service
The purpose of this paper is to survey and compare AI planning techniques in Web service
composition according to a set of criteria defined in Section 3.1. Criteria with regards to discovery
of Web services are not addressed in the paper. Although the discovery of services is important,
and it has influence on the correctness of the composite services, such selection can be done using
semantics. Evidently comparisons of planners have been performed before, for example [3, 27, 39].
However, the issues of Web service composition have not been addressed adequately with respect
to AI planning techniques. The result of our comparison will help developers to choose a better
planner for composition purposes.
3
1.1
AI Planning
Planning focuses on selecting suitable actions and ordering them in an appropriate sequence so as
to achieve some goal. In general, a classical AI planning problem can be described as a quintuple
‹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 the planning system attempts to reach;
•
A is the set of actions the planner can perform in attempt to reach a desire goal, and
•
the translation relation Ґ ⊆ S x A x S defines the precondition and effects for the execution
of each action.
In terms of Web services, S0 and G represent the initial state and the goal state respectively,
specified by the service requestors. A is a set of available services and Ґ denotes the current states
of each service.
According to Ghallab [10], AI planning techniques can be categorised into the following classes
and sub-classes:
Table 1: Categorisation of AI planning techniques
Class
1. Classical Planning
Sub-class
• State-Space Planning
• Plan-Space Planning
2. Neoclassical Planning
•
•
•
Planning-Graph Techniques
Propositional Satisfiability Techniques
Constraint Satisfaction Techniques
3. Heuristics and Control Strategies
•
•
•
•
•
Domain-Independent Heuristics
Control Rules in Planning
Hierarchical Task Network Planning
Situation Calculus
Dynamic Logic
4. Planning with Time and Resources
(Extensions to (neo-)classical planning)
•
•
Temporal Planning
Planning with Resources
5. Planning under Uncertainty
•
•
•
Planning Based on Markov Decision
Processes
Planning Based on Model Checking
Uncertainty with Neoclassical Techniques
•
Case-based Planning
Other Approaches to Planning
4
•
•
•
•
Multi-agent planning
Plan merging and rewriting
Abstraction Hierarchies
Domain Analysis
So far, some of the sub-classes in classes 3 and 5 have already been adapted for Web service
composition. In the subsequent sections we will describe five of these, as underlined in Table 1.
Planning-graph techniques have also been adapted for Web service composition. However, they
are restricted in terms of control. Because Web services live in a dynamic environment, control,
monitoring and planning under uncertainty is important. Therefore, we have not included classes 2
and 4, neoclassical and extension to (neo-)classical planning respectively, in this paper.
2
2.1
SOME AI PLANNING TECHNIQUES
Domain-Independent Heuristics
The classical approach to planning is based on searching. A plan can be obtained by either
searching the space of action sequences for one that works, or by searching the space of world
states for a path from the initial state to the goal state. The regression planning technique does a
backward search from the goal description. Given an initial and a goal situation, it does a situationspace search for a sequence of steps that achieves the goal. The search is guided by a heuristic: for
each search state, build a regression-match graph from the goal back to the current situation of that
search state. The regression-match graph is essentially an AND/OR tree made up of nodes and
arcs, where nodes are propositions and arcs correspond to actions. AND nodes represent the
preconditions of an action and OR nodes represent to a set of actions. The preconditions of each
action are matched to the current situation to obtain a set of deference literals that must be achieved
by further actions, and so forth. Figure 2 depicts an example of the serialisations of AND/OR tree
with (a) illustrating the basic pattern and (b) showing the repetition form of the AND/OR tree Gb,k.
The number of repetitions is calculated as follows:
cb,k = 1 + (b + 1) + (b + 1)2 + … + (b + 1)k-1
5
(a)
(b)
Figure 2: AND/OR tree (adapted from [10])
McDermott [21] extended PDDL (Planning Domain Definition Language) [20] to deal with Web
service composition. The motivation for using PDDL is that OWL-S is strongly influenced by
PDDL. Therefore, mapping from OWL-S to PDDL is straightforward as long as declarative
information is considered. It was shown that the Optop (Opt-based total-order) planner (an
extension to Unpop) could handle simple Web service composition. Even though McDermott
proved that the estimated-regression planner is suitable for Web service composition, issues of
dealing with non-determinism, partial observability and generation of conditional and iterative
behaviours were not addressed.
2.2
Hierarchical Task Network Planning
HTN planning is a type of AI planning that incorporates and exploits domain-independent control
knowledge. As a result, it achieves good performance in realistic domains [35]. HTN planning
techniques use a hierarchical decomposition to plan. A task network consists of abstract tasks that
are defined in terms of primitive actions and other tasks. According to [8] there are three types of
tasks in HTN planning:
1. Goal tasks that denote the desired properties of the final state;
2. Primitive tasks, that are tasks that can be executed directly by invoking atomic operators;
3. Compound tasks that denote desired changes that involve several goal tasks and primitive
tasks.
6
Figure 3: Solution to simple a travelling problem (adapted from [26])
Figure 3 depicts the solution to a simple travelling problem. The planning problem is stated as
follows:
•
Goal: go to a park that is 2 miles away
•
Initial state: at home and have $20
•
There are two ways of travelling: by foot or by taxi
•
If we want to travel by taxi we should have enough money.
Figure 1 shows how the task travel(me, home, park) can be implemented by two other
tasks: either travel-by-foot or travel-by-taxi. The abstract task of travel-bytaxi is expanded into a series of subtasks call-taxi(me,home), ride(me,home,park)
and pay-driver(me,home,park). All these tasks are primitive tasks and can be execute
directly by invoking atomic actions.
HTN planning uses action and state descriptions, where actions are usually called primitive tasks.
Non-primitive tasks are decomposed to primitive tasks using a method. According to the definition
in [8] a planning domain is specified by a tuple ‹V, C, P, F, T, N›, where:
•
V = {v1, v2, … } is an infinite set of variable symbols,
•
C is a finite set of constant symbols,
•
P is a finite set of predicate symbols,
•
F is a finite set of primitive task symbols,
7
•
T is a finite set of compound task symbols, and
•
N = {n1, n2, … } is an infinite set of symbols for labelling tasks.
A state is a set of ground atoms, listing all the propositions that are true. Propositions not occurring
in a state description are assumed to be false.
There are two kinds of tasks: primitive tasks and non-primitive tasks (i.e. compound tasks2). If x1,
…, xk are terms, then a primitive task the form do(f(x1, …, xk)), where f
F; a goal task has the
form achieve(l), where l is a literal; and a compound task has the form perform[t(x1, …, xk)], where
t
T.
A task network describes a number of actions and their interrelationship. Formally, a task network
has the form ((n1 :
1),
…, (nm :
m),
), where each
i
is a task labelled with ni, and
is a Boolean
formula constructed from variable binding constraints, temporal ordering constraints and truth
constraints.
An operator is specified as (f(v1, …, vk), pre(l1, …, lm) post(l’1, …, l’m)), where f is a primitive task
symbol, v1, …, vk are variable symbols, and l1, … lm are literals denoting when f is executable and
l’1, …, l’m are literals denoting the effects of f.
A method specifies a way to achieve non-primitive tasks. A method is a pair ( , d) where
is a
non-primitive task, and d is a task network. To achieve , all subtasks in the network d must be
accomplished without any violation of constraint formula of the network.
A planning problem is represented as a triple ‹d, I, Op, Me› where:
•
d is the task network to plan for
•
I is the initial state
•
Op is a set of operators
•
Me is a set of methods.
•
Op and Me represents a planning domain.
Recently, HTN planners have been proposed for the automatic composition of Web services, for
example the Simple Hierarchical Task Network (SHOP2) [36]. SHOP2 is a domain-independent
planning system based on ordered task composition. Ordered task decomposition is a modified
2
Goal task is also a compound task.
8
version of HTN planning, which has the property that it plans for tasks in the same order in which
they will be executed. Ordered task decomposition can greatly reduce the complexity of the
planning process by avoiding some task-interaction issues. Since SHOP2 always has complete
knowledge of the world-state at each step of the planning process, it eliminates a great deal of
uncertainty about the world. Therefore it can use more expressivity in its domain representation to
encode highly efficient planning procedures. The procedure of plan generation consists of the
following steps (more detail description can be find in [36]):
•
Encode an OWL-S process model as a SHOP2 domain
•
Encode an OWL-S Web service composition problem as a SHOP2 planning problem
•
SHOP2 generates the plan
•
The plan converter converts the plan to an OWL-S process
•
The OWL-S API executes the process
SHOP2 uses first-order-logic definitions of variable and constant symbols, function and predicate
symbols, terms, atoms, conjuncts, most-general unifiers and Horn clauses. Therefore, the
representation of plan generated is a list of operator instances. One of the shortcomings of SHOP2
is the inability to deal with non-deterministic actions. To resolve this problem, ND-SHOP2 planner
[14], a non-deterministic version of SHOP2, was developed.
Paolucci [28] make use of RETSINA, a planner that is based on the HTN planning paradigm.
RETSINA is similar to SHOP2 in the way that it interleaves planning and execution. They claim
that by executing the information-gathering services during planning, unexpected situations can be
handled by re-planning. The RETSINA planner has been modified to use OWL-S descriptions, but
the exact modification process is unclear.
2.3
Situation Calculus
Situation calculus [19, 34] is a logic formalism designed for representing and reasoning about
dynamic systems. It differs from the other planning techniques in a way the state of the world is
described. The world state is described by functions f with relational fluents3 that contain terms and
formulas containing a situation s (e.g. f( , s) where
represent the term and formula). There are
three basic elements: action a, situation s and fluent χ.
An action is a first order term consisting of an action function and argument. For example, calltaxi(me, home) from Figure 3 is an action term.
3
A fluent is a state variable whose value is subject to change over time.
9
A situation is a history of the primitive actions performed from the initial situation s0. A situation
term is denoted by a first order term. A distinguished binary function symbol do; do( , s) denotes
the successor situation to s resulting from performing the action
. Referring to the simple
travelling domain in Figure 3, the situation term will be (for simplicity let A be the actions):
do(pay-driver(A), do(ride(A, s)), do(call-taxi(A, s0)))
denoting the sequence of actions:
[call-taxi(A), ride(A), pay-driver(A)]
The sequence of actions is obtained from a situation term reading off the actions from right to left.
A fluent is a state variable whose value is subject to change over time. Rational fluent refers to a
relation whose truth values vary from situation to situation. Similarly, functional fluent refers to a
function whose truth values vary from situation to situation. An example of functional fluent would
be in a world in which it is possible to paint objects. colour(x, s) denotes the colour of object
x in that state of the world resulting from performing the action sequence s. Once again consider
the simple travelling example, an example of possible rational fluent is call-taxi(me,
home, s) denoting the state of the world reached by performing the action sequence s, we (me)
will be able to call a taxi to from home [34].
A domain theory D in situation calculus is described as
ss
ap
una
•
is the foundational axioms for situation.
•
ss is
a set of successor state axioms for functional and relational fluent.
•
ap is
a set of action precondition axioms.
•
una is
•
s0 is a set of axioms describing the initial situation.
0
where:
a set of unique names axioms for actions.
Golog (alGO1 in LOGic) [15] is a logic programming language based on situation calculus that
specifies and execute complex actions in dynamic domains. The semantics of Golog is defined by
marco-expansion using a ternary action Do. Do( , s, s´) as the abbreviation for a situation calculus
formula that indicates the possibility of reaching s´ from s by executing a sequence of actions
specified by .
McIlraith [22, 24] extend and adapt Golog for automatic Web service composition. They use
formal methods to define, characterise and compute the preconditions and conditional effects for
complex action. Service composition is done via the use of general templates that are modified
based on user preferences. Later, they applied a modified version of ConGolog (Concurrent Golog)
10
to the Web service composition problem [23]. Extensions were added to the ConGolog interpreter
so that it has the ability to implement sensing actions (for information gathering) as external
function calls.
A formal translation from OWL-S to situation calculus is given by Narayanan and McIlraith [25].
OWL-S processes describe the atomic and complex actions of the Web service as well as the
composite service (i.e. the desired process). All these descriptions are first translated to PDDL
(Planning Domain Description Language) then to situation calculus. Golog is responsible for
finding the suitable composition plan and executing it as a Golog program that satisfies the
properties in the goal.
2.4
Planning Based on Markov Decision Processes
A Markov Decision Process (MDP) models the decision problem as inherently stochastic,
sequential and fully observable.
A MDP process M is a tuple ‹S, A, , R› where:
•
S is a finite set of states;
•
A is a finite set of actions;
•
is the state transition function, mapping each action and a state is a
probability distribution over S for the possible resulting state. The probability of reaching
state s´ by performing action a in state s is written as
, and
•
R : S
A
ℝ is the reward function. R(s,a,s΄) is the reward that is issued for the
transitional from s to s΄ under action a.
A solution to a MDP is achieved by finding an optimal policy which maps each state to an action.
Given a policy, the expected value of applying the policy
for n steps starting in state s can be
calculated. Therefore, a solution to an MDP is a policy that maximises its expected value. Two
methods for calculating the optimal policy are value iteration and policy [32]. Value iteration and
policy iteration run in a time polynomial to the size of the state space and the state space is usually
exponentially large in the input. Therefore, MDP does not scale well to large-problem space.
Traditional MDPs assume the world is fully observable. Kaelbling
[12] relaxed the fully
observable assumption and introduced Partially-Observable Markov Decision Processes
(POMDPs).
A POMDP process is a tuple ‹S, A, O, P, R›, where:
•
S is a set of states;
•
A is a set of actions;
11
•
O is a set of observation label;
•
P(o|a, s), o O, a A, s S, is a set of conditional probabilities; and
•
R(s,a,s΄) is the reward that is issued for the transitional from s to s΄ under action a.
Finding an optimal policy for a POMDP is much harder than finding an optimal policy for a
regular MDP, because it is PSPACE-complete.
Recent work done by Doshi [7] and Gao [9] investigate the application of MDPs in Web service
composition. Doshi presented a policy-based approach for dynamic Web service composition
resulting in workflows. They developed a tool to convert a policy into a workflow in BPEL4WS
specification using the BPWS4J API. This can then be executed under a BPEL engine. The paper
focuses on automating the establishment of workflow logic and not on the implementation details.
In contrast, the work done by Gao, proposes a framework for representing Web service
composition using MDP. The Web service composition as MDP based on Quality of Service (QoS)
criteria.
2.5
Planning Based on Model Checking
Planning Based on Model Checking [6, 11] is an approach to planning under uncertainty. The main
idea is to deal with non-determinism, partial observability and extended goals, where the problems
should be solved model-theoretically.
Model Checking is a formal verification technique used to determine whether or not a property
holds in a finite state model. Model checkers and planners are normally used to perform
verification. The model checker searches for a counter-example to falsify a given specification, and
the planner searches for a sequence of actions to satisfy a goal. The Labelled Transition System
Analyzer (LTSA) [17] is an example system that uses model checking to verify the final state of a
transition.
Planning based on Model Checking is a technique to synthesize a plan from a formal model of a
domain and a logical specification of a goal. A planning domain is formalised as a tuple ‹S, S0, T,
P, L›, where:
•
S is a finite set of states
•
S0 is the initial state
•
P is a finite set of atomic propositions
•
T ⊆ S × S is the transition relation
12
•
L : P a 2s assigns to each proposition p ∈ S the set of states where p holds.
Planning is done by verifying whether the temporal formulae are true in a semantic model. At each
step, the truth values of some suitable formulas in the model are checked to ensure the correctness
of the plan at that time. In principle Planning as Model Checking is good for all applications where
uncertainty is critical. In Figure 4 we shown the equivalent state-transition diagram of the travel
example mentioned in Section 2.2
at(me, ride)
at(me, home)
S1
ride(me,
park)
at(me, park)
home,
S2
S3
pay-driver(me,
home, park)
Figure 4: State-transition diagram of the travel example
Pistore [30, 31, 37] exploit Planning as Model Checking to automatically compose Web services
and synthesize the monitoring of components. They show that the technique is able to deal with
unpredictable external services as well as their internal structure in the presence of complex
behavioural requirements. The main drawback of this approach is its performance, which makes it
unusable for complex protocols: in complex protocols, the state space becomes unwieldy.
ASTRO toolset4 [37, 38] is a set of tools that extend existing platforms for Web service design and
execution with automated composition and execution monitoring functionalities. ASTRO is
comprised of several components: WS-gen, WS-mon, WS-verify, WS-console and WS-animator.
WS-gen is responsible for generating the automated composition. It takes a BPEL4WS
specification and translates it into an intermediate file that represents a Planning as Model
Checking problem. WSYNTH takes the intermediate file and generates a plan, translating it back
to BPEL4WS executable code. WS-mon is responsible for implementing monitor code for the
composition process which will get deployed to the monitor framework. During run-time the
monitor framework executes the monitors associated with a given instance of the process that is
being executed. WS-verify is responsible for verification to ensure the properties of service holds.
WS-console and WS-animator are extensions to the Active BPEL console and plug-in for Eclipse
4
Toolset can be obtain from http://www.astroproject .org
13
respectively. The main usage of these extension and plug-in is to provide easy interaction between
the users and the process.
3
3.1
COMPARISON OF PLANNING TECHNIQUES
Evaluation Criteria
We start by presenting a set of criteria that will be used to evaluate the planning techniques and
planners surveyed in Section 2. We selected criteria with the aim of evaluating the capability of
planning techniques for automatic Web service composition.
Table 2 and 3 present a list of the properties and control structure criteria respectively, and the
reason for their choice.
Table 2: Properties
Properties Criteria
Reason
Domain-independence
Allows the solution of a broad range of
problems.
Search Mechanism
Mechanism used to prune the search space.
Partial Observability
The real-world situation is not fully observable.
The ability to reason based on incomplete
information is important.
Domain Complexity
Measures the level of difficulty in solving
composition problems in terms of time and
computation steps.
Scalability
Provides the ability to solve large real world
problems.
Extendibility
The assumption that planning goals are sets of
final desired state is unrealistic especially in
Web service compositions. Because it is a
reactive system, infinite plans might exist that
react to changes.
Applicability
Standards to which it can apply to (i.e.
BPEL4WS or OWL-S).
14
Table 3: Control structure
Control Structure Criteria
Reason
Composition constructs
Sequential, iteration, parallel and conditional
Non-determinism
An action executed in a state may lead to many
different states. The ability to deal with nondeterminism will ensure the output state is the
desired one.
Concurrency
Allows more than one services to execute at the
same time
Plan monitoring
The plan monitor is important to ensure the plan
is executed as expected.
Plan failure
If the plan as generated fails, it should be able to
detect and recover such failures to retain
correctness of composition.
3.2
Comparison Summary
The previous section (Section 2) presented overviews of planning techniques and planners that
adopt these planning techniques. We examined both the planning techniques and planners
according to a set of criteria described in Tables 2 and 3, and our results of the comparison are
presented in Table 4 and 5. For the details and references for each planner, refer to Section 2.
3.3
Discussion
Based on the analysis conducted, we see that HTN planning is well suited for Web service
composition. We also noted the following:
•
OWL-S is most used when comes in applying AI planning to Web service composition.
•
The domain complexity of estimated-regression planning, planning as Model Checking
and MDPs hampers the scalability to large-scale problems. In Web service composition,
the problem domain tends to very large. Therefore, these techniques are not feasible for
large Web service composition.
15
•
There is no existent planner based on estimated-regression and situation calculus that
supports an extended goal in Web service composition. The ability to support an extended
goal is important in automatic Web service composition, because requirements (the desire
goal) set by users differ from time to time.
•
Plan monitoring and plan failure detection and recovery are not supported by most
planners. Automatic Web service composition should not only generate the plan
automatically, but it should be able to monitor the plan during execution and perform
recovery when failures occur.
•
Estimated-regression planning (as was point out by the McDermott [21]) is suitable for
Web service composition. However, there are too many unresolved issues, such as dealing
with non-deterministic actions.
•
Using pure HTN planning hampers the ability to tackle recursive and conjunctive tasks.
Zhang [40] proposed an enhanced HTN planning algorithm to tackles these problems. The
algorithm combines HTN methods with partial-order planning (POP) for Web service
composition. HTN methods are used for automatic plan generation and POP is responsible
for plan refinements.
•
Recently, Kuter
[13] found that the way ND-SHOP2 solves non-determinism is not
efficient if search strategies cannot cut down the search space. Therefore, a novel
algorithm, YoYo, is proposed to solve non-determinism under fully observability. The
algorithm combines the power of search-control strategies in HTNs with Planning via
Symbolic Model-Checking.
4
CONCLUSION AND FUTURE WORK
For Web services to reach their full potential, the composition of Web services should be
automated. To this end a planning technique can be used to automated Web service composition.
In [29, 33] a list of current planning techniques used in Web services is presented. In this paper we
surveyed and performed a feasibility analysis on five planning techniques according to a set of
criteria at the beginning of Section 3. The result of the analysis shows that HTN planning has
various advantages over other planning techniques that are currently used to automate the
composition of Web services. However, the analysis conducted only considers the composition
process itself, the discovery of services has not been taken into account.
Future work includes a more in-depth analysis of AI planning techniques in relation to the fault
behaviours of Web service composition. Having all the information, we then need to examine
suitable control and recovery mechanisms to ensure proper execution of composition.
16
Properties Criteria
Domain-independent
heuristic (Optop)
HTN Planning
(SHOP2)
Situation Calculus
(Golog)
Planning as Model
Checking (ASTRO)
Planning based
on Markov
Decision
Processes
Domain-independence
Domain-independent
Domain-specific or
domain-configurable
Domain-independent
Domain-specific
Domain-specific
Search Mechanism
Search guided by
heuristic
Forward search
Based on current
situation
Breadth-first search
proceeding backward
from the goal state
toward the initial state.
Policy guided the
search
Partial Observability
know-val predicate
WSC-SHOP2 is a
sound and complete
HTN-planning
algorithm for solving
planning problems with
incomplete information
about the initial world
state.
Uses sensing actions
during execution or
knowledge
Yes
Original MDP
does not support
partial
observability.
POMDP is the
partial
observability
version of MDP.
Domain Complexity
Building the
regression-match graph
is too expensive (no
proper measurement
exists)
O((n/k)!·k)
Plan generation takes
linear time.
Combination of
complex actions is
polynomial in the
number of primitive
action occurrences in
its definition
O(n!)
O(|S|2)
Scalability
Not feasible
Scales well to large
domain problems.
Reasonable
Can deal with large
scale problems.
Lack of
scalability.
17
However, verification
steps are time
consuming.
Extendibility
N/A
Define as HTN
methods
N/A
Yes, but have to take
into account the context
of execution (i.e. state
of service)
Yes
Applicability
Mapping between
OWL-S and PDDL
Translation between
OWL-S and planning
operators
Translation: OWL-S to
PDDL to situation
calculus
Translation between
BPEL4WS and
planning operators
Converting a
policy into a
workflow in
BPEL4WS
specification
using BPWS4J
API
Table 4: Properties comparison of AI planning techniques and planners
Control Structure Criteria
Domain-independent
heuristic (Optop)
HTN Planning
(SHOP2)
Situation Calculus
(Golog)
Planning as Model
Checking (ASTRO)
Planning based
on Markov
Decision
Processes
Composition constructs
Sequential and parallel
Sequential, parallel and
conditional
Sequential, iteration
and conditional
Sequential, iteration
and conditional
Sequential,
iteration and
conditional
Non-determinism
Not addressed
Can be included during
development of
methods. ND-SHOP2
is specifically design to
deal with nondeterminism
Represent with
disjunctive formulae
Though weak and
strong (acyclic) graphs.
Yes
18
Concurrency
Via interleaving
Fully supported
Concurrency via
interleaving (ConGolog
– concurrency Golog)
Supported
Concurrent
MDPs (extension
to traditional
MDPs)
Plan monitoring
Not addressed
Debugging
Not addressed
Supported (WS-mon)
Not addressed
Plan failure detection and
recovery
Not addressed
Backtracking
mechanism,
precondition reasoning,
post-condition check
Not addressed
Recovery mechanism is
not addressed
Not addressed
Table 5: Control structure comparison of AI planning techniques and planner
19
ACKNOWLEDGEMENTS
This work was funded by South Africa National Research Foundation Grant number 2053401 and
an SA-Italy inter-governmental cooperation agreement. Many thanks to Tim Grant and Stefan
Gruner for their valuable feedback.
REFERENCES
[1]
Gustavo Alonso, Fabio Casati, Harumi Kuno and Vijay Machiraju, Web Services:
Concepts, Architecture and Applications, Springer Verlag, 2004.
[2]
Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klien, Frank
Leyman, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Ivana Trickovic and Snajiva
Weerawarana, "Business Process Execution Language for Web Services," Available:
ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf. [Accessed: 01
February 2007].
[3]
Fahiem Bacchus and Froduald Kabanza, "Using Temporal Logics to Express Search
Control Knowledge for Planning," Artificial Intelligence, vol. 116, no. pp. 123-191, 2000.
[4]
David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, Michael Champion, Chris
Ferris
and
David
Orchard,
"Web
Services
Architecture,"
Available:
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. [Accessed: 23 Feburary 2007].
[5]
Mark Carman, Luciano Serafini, and Paolo Traverso, "Web Service Composition as
Planning," presented at Proceedings of ICAPS 2003 Workshop on Planning for Web
Services, Trento, Italy, 2004.
[6]
Edmund M. Clarke and Bernd-Holger Schlingloff, Handbook of Automated Reasoning,
Clsevier Science Publisher, 2001.
[7]
Prashant Doshi, Richard Goodwin, Rama Akkiraju and Kunal Verma, "Dynamic
Workflow Composition: Using Markov Decision Processes," International Journal of Web
Service Research, vol. 2, no. 1, pp. 1-17, 2005.
[8]
Kutluhan Erol, James Hendler, and Dana S. Nau, "HTN Planning: Complexity and
Expressivity," presented at Proceedings of the Twelfth National Conference on Artificial
Intelligence (AAAI-94), 1994.
[9]
Aiqiang Gao, Dongqing Yang, Shiwei Tang and Ming Zhang, "Web Service Composition
Using Markov Decision Processes", in Proceedings of the WAIM 2005, 2005, pp. 308-319.
[10]
Malik Ghallab, Dana Nau, and Paolo Traverso, Automated Planning: Theory and Practice,
Amsterdam Morgan Kaufmann Publisher, 2004.
[11]
Fausto Giunchiglia and Paolo Traverso, "Planning as Model Checking," presented at
Proceedings of the 5th European Conference on Planning: Recent Advances in AI
Planning, London, UK, 1999.
[12]
Leslie Pack Kaelbling, Michael L. Littman, and Anthony R. Cassandra, "Planning and
Acting in Partially Observable Stochastic Domains," Artificial Intelligence, vol. 10, no. 12, pp. 99-134, 1998.
20
[13]
Ugur Kuter, Dana Nau, Marco Pistore and Paolo Traverso, "A Hierarchical Task-Network
Planner based on Symbolic Model Checking", in Proceedings of the Fifteenth
International Conference on Automated Planning and Scheduling, 2005, pp. 300-309.
[14]
Ugur Kuter and Dana S. Nau, "Forward-Chaining Planning in Nondeterministic Domains",
in Proceedings of the AAAI, 2004, pp. 513-518.
[15]
Hector J. Levesque, Raymond Reiter, Yves Lesperance, Frangzhen Lin and Richard B.
Scherl, "GOLOG: A Logic Programming Language for Dynamic Domains," Journal of
Logic Programming, vol. 31, no. 1-3, pp. 59-83, 1997.
[16]
Yimin Liu. "Web Services Composition," in Department of Application-Software, vol.
MSc. Stuttgart: University of Stuttgart, 2004.
[17]
J. Magee and J. Kramer, Concurrency - State Models and Java Programs, John Wiley,
1999.
[18]
David Martin, Anupriya Ankolekar, Mark Burstein, Grit Denker, Daniel Elenius, Jerry
Hobbs, Lalana Kagal, Ora Lassila, Drew McDermott, Deborah McGuinness, Sheila
McIlraith, Massimo Paolucci, Bijan Parsia, Terry Payne, Marta Sabou, Craig Schlenoff,
Evren Sirin, Monika Solanki, Naveen Srinivasan, Randy Washington. "OWL-S 1.1
Release," 2004.
[19]
John McCarthy and Patrick J. Hayes, "Some Philosophical Problems from the Standpoint
of Artificial Intelligence," Machine Intelligence, vol. 4, no. pp. 463-502, 1969.
[20]
Drew McDermott, "The Planning Domain Definition Language Manual," Yale Computer
Science, Tech. Rep. 1165, 1998.
[21]
Drew V. McDermott, "Estimated-Regression Planning for Interactions with Web
Services", in Proceedings of the Sixth International Conference on Artificial Intelligence
Planning Systems, 2002, pp. 204-211.
[22]
Sheila McIlraith and Ronald Fadel, "Planning with Complex Actions", in Proceedings of
the 9th International Workshop on Non-Monotonic Reasoning, 2002, pp. 356-364.
[23]
Sheila McIlraith and Tran Cao Son, "Adapting Golog for Programming the Semantic
Web", in Proceedings of the 5th International Symposium on Logical Formalizations of
Commonsense Reasoning, 2001, pp. 195-202.
[24]
Sheila McIlraith and Tran Cao Son, "Adapting Golog for Composition of Semantic Web
Services", in Proceedings of the 8th International Conference on Principles and
Knowledge Representation and Reasoning, 2002, pp. 482-496.
[25]
Srini Narayanan and Sheila A. McIlraith, "Simulation, Verification and Automated
Composition of Web Services", in Proceedings of the 11th International World Wide Web
Conference, 2002, pp. 77-88.
[26]
Dana Nau. "Dana Nau's Lecture Slides: Chapter 11." College Park, Md, USA: University
of Maryland, 2007.
[27]
Dana Nau, Yue Cao, Ammon Lotem and Hector Munoz-Avila, "SHOP and M-SHOP:
Planning
with
Ordered
Task
Decomposition,"
Available:
https://drum.umd.edu/dspace/handle/1903/517?mode=simple. [Accessed: 6 April 2006].
[28]
Massimo Paolucci, Katia Sycara, and Takahiro Kawamura, "Delivering Semantic Web
Services", in Proceedings of the 12th International World Wide Web Conference, 2003, pp.
111-118.
[29]
Joachim Peer, "Web Service Composition as AI Planning - a Survey," Available:
http://elektra.mcm.unisg.ch/pbwsc/docs/pfwsc.pdf. [Accessed: 21 January 2007].
21
[30]
Marco Pistore, Paolo Traverso and Piergiorgio Bertoli, "Planning and Monitoring Web
Service Composition," presented at AIMSA 2004, Varna, Bulgaria, 2004.
[31]
Marco Pistore, Paolo Traverso, and Piergiorgio Bertoli, "Automated Composition of Web
Services by Planning in Asynchronous Domains", in Proceedings of the 15th International
Conference on Automated Planning and Scheduling, 2005, pp. 2-11.
[32]
Martin L. Puterman, Markov Decision Processes: Discrete Stochastic Dynamic
Programming, New York: John Wiley & Sons, Inc., 1994.
[33]
Jinghai Rao and Xiaomeng Su, "A Survey of Automated Web Service Composition
Methods," Semantic Web Services and Web Process Composition: First International
Workshop, SWSWPC 2004, vol. 3387 / 2005 no. pp. 43, 2004.
[34]
Raymond Reiter, Knowledge in Action: Logical Foundations for Specifying and
Implementing Dynamical Systems, Cambridge, Massachusetts: MIT Press, 2001.
[35]
Stuart J. Russell and Peter Norvig, Artificial Intelligence: A Modern Approach, 2nd. Upper
Saddle River, N.J.: Prentice Hall, 2003.
[36]
Evren Sirin, Bijan Parsia, Dan Wu, James Hendler and Dana Nau, "HTN Planning for Web
Service Composition Using SHOP2," Journal of Web Semantics, vol. 1, no. (4), pp. 377396, 2004.
[37]
Michele Trainotti, Marco Pistore, Fabio Barbon, Piergiorgio Bertoli, Annapaola Marconi,
Paolo Traverso and Gabriele Zacco, "ASTRO: Supporting Web Service Development by
Automated Composition, Monitoring and Verfication", in Proceedings of the 16th
International Conference on Automated Planning and Scheduling (Software
Demonstration), 2006, pp. 28-31.
[38]
Michele Trainotti, Marco Pistorem, Gaetano Calabrese, Gabriele Zacco, Gigi Lucchese,
Fabio Barbon, Piergiorgio Bertoli and Paolo Traverso, "ASTRO: Supporting Composition
and Execution of Web Services", in Proceedings of the ICSOC 2005, 2005, pp. 495-501.
[39]
Maja Vukovic and Peter Robinson, "SHOP2 and TLPlan for Proactive Service
Composition", in Proceedings of the UK-Russia Workshop on Proactive Computing, 2005.
[40]
Jianhong Zhang, Shensheng Zhang, Jian Cao and Yujie Mou., "Improved HTN Planning
Approach for Service Composition", in Proceedings of the 2004 IEEE International
Conference on Service Computing, 2004, pp. 609-612.
22