searching, backtracking, and/or branching techniques
in order to extract such a solution. There are two ba-
sic operations in every state-space-based planning ap-
proach. First, the precondition of an action needs to
be checked to make sure it is satisfied by the current
state before the operation can be a part of the plan.
Second, once the operation is put into the plan, its
effect should be applied to the current state and thus
produce a consecutive state. We address the signifi-
cant differences between classic AI planning and se-
mantic Web service composition as follows:
1. Actions in AI planning can be described com-
pletely by its name, precondition, and effect,
while Web services also include input and/or out-
put message schema.
2. For AI planning, it is assumed that there is an
agreement within an application on the terms in
the precondition and effect. Terms with same
name (string) mean the same thing, while terms
with different name (string) mean different things.
For example, in the famous block world sce-
nario, if both block and box exist in the precon-
dition/effect, they are treated as different things.
This obviously does not carry over to the re-
sources on the Web, thus it is necessary to intro-
duce semantics in Web service composition.
3. More workflow patterns such as loops are de-
sired in Web service composition. We address this
problem by a pattern-based approach.
As discussed in the previous sections, both Web ser-
vices and the specification of the task, i.e., Semantic
Template are described in extended SAWSDL stan-
dard, so the terms in the precondition, effect, and in-
put/output messages reach an agreement which is cap-
tured by the ontologies. For the first two types of dif-
ferences we mentioned above, to apply AI planning
techniques to semantic Web service composition, any
state-space-based planning algorithm needs to be re-
vised according to the following criteria.
1. State space should include status flags, as in the
existing AI planning approaches, and semantic
data types to represent the availability of data.
2. For each candidate action, besides checking its
precondition against the status flags in the cur-
rent state, it is also necessary to check its input
message schema against the semantic data types
in the current state. This reduces the search space
and eliminates plans containing operations whose
input message is unavailable in the state.
3. Since the states and the actions/operations are se-
mantically annotated by referring to ontologies,
the checking in the previous step involves reason-
ing based on the ontologies, not just comparing
the name of the terms.
4. Once an action/operation is added into the plan,
not only the status flags are updated by applying
the effect, the semantic data types should also be
updated by put a new semantic data type based on
the output message schema.
5.4 Extended GraphPlan Algorithm
Although most AI planning algorithms are suitable
for the task here, we use GraphPlan algorithm (Rus-
sell and Norvig, 2003). It is sound and complete thus
we can always construct correct plans if there ex-
ist any, and its compact representation of the states
makes it space efficient while doing a breadth-first
style search. It also uses mutex links to avoid explor-
ing some irrelevant search space. Like other classi-
cal AI planning algorithms, GraphPlan only consid-
ers the precondition and effect of actions, thus does
not take into account the input/output message of ac-
tions. Our approach requires an extension of the algo-
rithm to accommodate the semantic data types defined
above. An operation may only be added in the next
action level when its preconditions hold based on the
current state level of the planning graph and the data
types of the input message of the operation can be en-
tailed by the union of ontology and the current state
level. When an operation is placed in the next action
level, its effects as well as output data types are ap-
plied to the current state level, and thus produce the
next state level. Afterwards, mutex links between ac-
tions must be evaluated and placed so that they may
be used when backtracking through the graph for the
solution. Note that the creation of the mutex links
should also consider the semantic data types accord-
ingly.
5.5 Pattern-Based Approach for Loop
Generation
GraphPlan algorithm may generate plans only with
sequence and AND-split workflow patterns (van der
Aalst and Hofstede, 2002). However, loops are also
a frequently used pattern. Loop generation (or iter-
ative planning) itself is a difficult and open problem
in AI. Much work on iterative planning is based on
theorem-proving (Biundo, 1994). It is believed by
Stephan and Biundo (Stephan and Biundo, 1995) and
other researchers that iterative planning cannot be car-
ried out in a fully automatic way. (Levesque, 2005)
proposes a new way that is not tied to proving a the-
orem, but it is only correct for a given bound or a
certain class of simple planning problems. Here we
AUTOMATIC COMPOSITION OF SEMANTIC WEB SERVICES USING PROCESS MEDIATION
459