AUTOMATIC COMPOSITION OF SEMANTIC WEB SERVICES
USING PROCESS MEDIATION
Zixin Wu
1
, Karthik Gomadam
2
, Ajith Ranabahu
1
, Amit P. Sheth
2
and John A. Miller
1
1
LSDIS Lab, Department of Computer Science, University of Georgia, Athens, GA
2
kno.e.sis center, Department of Computer Science and Engineering, Wright State University, Dayton, OH
Keywords:
Semantic Templates, Process Mediation, Semantic Web Services, SAWSDL, SWS Challenge.
Abstract:
Web service composition has quickly become a key area of research in the services oriented architecture com-
munity. One of the challenges in composition is the existence of heterogeneities across independently created
and autonomously managed Web service requesters and Web service providers. Previous work in this area
either involved significant human effort or in cases of the efforts seeking to provide largely automated ap-
proaches, overlooked the problem of data heterogeneities, resulting in partial solutions that would not support
executable workflow for real-world problems. In this paper, we present a planning-based approach to solve
both the process heterogeneity and data heterogeneity problems. Our system successfully outputs a BPEL file
which correctly solves a non-trivial real-world problem in the 2006 SWS Challenge.
1 INTRODUCTION
Web services are software systems designed to sup-
port interoperable machine-to-machine interactions
over a network. They are the preferred standards-
based way to realize Service Oriented Architecture
(SOA) computing. A problem that has seen much in-
terest from the research community is that of auto-
mated composition (i.e., without human involvement)
of Web services. The ultimate goal is to realize Web
service compositions or Web processes by leveraging
the functionality of autonomously created services.
While SOAs loosely coupling approach is appealing,
it inevitably brings the challenge of heterogeneities
across these independently developed services. Two
key types of heterogeneities are those related to data
and process. It is necessary and critical to overcome
both types of these heterogeneities in order to orga-
nize autonomously created Web services into a pro-
cess to aggregate their power.
Previous efforts related to Web service compo-
sition considered various approaches, and have in-
cluded use of HTN (Sirin et al., 2004), Golog
(Narayanan and Mcilraith, 2002), classic AI planning
(Rao et al., 2006), rule-based planning (Ponnekanti
and Fox, 2001) model checking (Traverso and Pis-
tore, 2004), theorem proving (Rao et al., 2004) etc.
Some solutions involve too much human effort; some
overlook the problem of data heterogeneities. Over-
coming both process and data heterogeneities is the
key to automatic generation of executable process.‘
The way to measure the flexibility of a solution is
to see how much human effort is needed if the sce-
nario is changed. Our solution involves minimal hu-
man effort. Only the specification of the task, i.e., ini-
tial state and goal state of the task, has to be changed.
We are assuming that all Web services are already se-
mantically annotated.
In our solution, we extend GraphPlan(Russell and
Norvig, 2003), an AI planning algorithm, to automat-
ically generate the control flow of a Web process. Our
extension is that besides the preconditions and effects
of operations, we also take into consideration in the
planning algorithm the structure and semantics of the
input and output messages. This extension reduces
the search space and eliminates plans containing op-
erations with incompatible messages. Our approach
for the problem of data heterogeneities is a data me-
diator which may be embedded in the middleware or
an externalized Web service. Let us say that message
M1 need to be converted into message M2 since they
have different structure and/or semantics. The data
453
Wu Z., Gomadam K., Ranabahu A., P. Sheth A. and A. Miller J. (2007).
AUTOMATIC COMPOSITION OF SEMANTIC WEB SERVICES USING PROCESS MEDIATION.
In Proceedings of the Ninth International Conference on Enterprise Information Systems, pages 453-461
Copyright
c
SciTePress
mediator takes as input the message M1 along with
the semantically annotated schemas of M1 and M2,
and then automatically gives as output the message
M2. Our system continues to support loose coupling
paradigm of SOA by separating the data mediation
from the process mediation. This approach lets the
process mediation system concentrate on generating
the control flow, and it also makes it easier to analyze
the control flow.
The key benefit of our solution is its ability to
automatically generate executable workflow that ad-
dresses both control flow and data flow considera-
tions (in our current implementation it is a BPEL
process specification). In the process, we propose
and implement (a) an extended GraphPlan algorithm,
(b) a loosely coupled data mediation approach, (c) a
context-based ranking algorithm for data mediation,
and, (d) a pattern-based approach for loop generation
in planning.
We demonstrate the above capabilities using a
case/scenario in the 2006 SWS Challenge that has
many real-world complexities. Our system generates
a BPEL process automatically according to the spec-
ification of initial state, goal state, and semantically
annotated Web service descriptions. The generated
BPEL process can be executed successfully and ac-
complishes the desired task.
The remainder of this paper is organized as fol-
lows. We first give some background information of
the problem of Web service composition in section 2,
and then introduce a motivating scenario in section
3. The next two sections form the technical core of
this paper section 4 presents a formal definition of
semantic Web services and Semantic Templates, and
section 5 discusses the automatic Web service compo-
sition capability. The system architecture and imple-
mentation is briefly introduced in section 6, and the
evaluation results are given in section 7. Finally, we
give conclusions and future work in section 8.
2 BACKGROUND AND RELATED
WORK
2.1 Background
There are two categories of partners that are described
within the Web services domain, namely the service
provider and service requester. A service provider
presents its Web service functionality by providing
a set of operation specifications (or operations for
short). These operations allow service requesters to
use the services by simply invoking them. These op-
erations might be inter-dependent. The dependences
can be captured using precondition, effect, input, and
output specifications of the operation. Using these
available operations, a service requester performs one
or more inter-related steps to achieve the desired goal.
These steps can be best viewed as activities in a pro-
cess and can be divided into smaller and more con-
crete sub-steps, and eventually invocations of con-
crete operations. Specifications by service requesters
and providers are often times autonomously created.
This causes heterogeneities to exist between the re-
quester and provider when Web services need to in-
teroperate as part of a composition of Web services.
Two key types of heterogeneities may exist the data
related and the communication/process related. We
say that process heterogeneity exists when the goal
of the service requester cannot be achieved by atom-
ically invoking exactly one operation once. On the
other hand, data heterogeneity exists when the out-
put message of an operation has different structure or
semantics from the input message of the consecutive
operation.
SAWSDL: We describe Web services and Se-
mantic Templates (discussed next) in SAWSDL.
SAWSDL (39, 2007) is a W3C standard to add se-
mantics to Web services descriptions. SAWSDL does
not specify a language for representing the semantic
models, e.g., ontologies. Instead, it provides mecha-
nisms by which concepts from the semantic models
that are defined either within or outside the WSDL
document can be referenced from within WSDL com-
ponents as annotations. Semantic annotations facili-
tate process composition by eliminating ambiguities.
We annotate a Web service by specifying Model Ref-
erences for its operations as well as Model References
and Schema Mappings for the input and output mes-
sage of its operations. We also extend SAWSDL by
adding preconditions and effects as in our W3C sub-
mission on WSDL-S (Akkiraju et al., 2004) for an
operation, which will be discussed in later sections.
Semantic Templates(Verma, 2006) is the way a
service requester defines its task specifications. We
again represent a Semantic Template in SAWSDL, in
a manner very similar to Web service description, ex-
cept that it is the specifications of a task, not of a spe-
cific Web service. We will discuss the formal model
for Semantic Templates in a session 4.2.
2.2 Related Work
Rao et al. (Rao et al., 2006) discuss the use of the
GraphPlan algorithm to successfully generate a pro-
cess. While it is good to consider the interaction with
the users, their approach suffers from the extent of
ICEIS 2007 - International Conference on Enterprise Information Systems
454
ated order ID from the output message of operation
createNewOrder. In order to solve this problem suc-
cessfully and automatically, the composition system
at least should be able to do the following: generate
the control flow of the mediator that involves at least
two workflow patterns (Sequence and Loop) based on
the specification of the task and the candidate Web
service(s), and convert (and combine if needed) an in-
put message to an acceptable format annotated with
appropriate semantics.
4 METEOR-S APPROACH TO
SEMANTIC WEB SERVICES
4.1 Abstract Semantic Web Service
Description
WSDL is a widely accepted industry standard (a
W3C recommendation) for describing Web services.
SAWSDL is expressive for functional and data se-
mantics, and sufficient to solve the problem of se-
mantic discovery and data mediation. We extend
SAWSDL by adding preconditions and effects in the
operations for process mediation. Preconditions and
effects are necessary because not all the states of a
Web service are represented by the input/output mes-
sage. For example, both a book buying service and
book renting service may take as the input the user
ID and the ISBN, and give as the output the status
succeed or fail. Importance of pre-condition and ef-
fects have been recognized by major semantic Web
services initiatives including OWL-S, WSMO and
WSDL-S, here we do that by extending the emerging
standard of SAWSDL.
Formal model of abstract Web services: For the
purpose of service composition, our model only fo-
cuses on the abstract representation of Web services,
i.e., operations and messages, but does not consider
the binding detail. Before giving our formal model,
we need to introduce some definitions of the basic
building blocks. Most classic AI planning problems
are defined by the STRIPS representational language
(or its variants like ADL), which divides its repre-
sentational scheme into three components, namely,
states, goals, and actions. For the domain of Web ser-
vice composition, we extend the STRIPS language as
the representational language of our method.
Extended state: We extend a state by adding a set
of semantic data types in order to ensure that the
data for the input message of an operation is avail-
able before the operation is invoked. An extended
state s has two components: s = <SSF, SDT >,
where:
SSF is a set of status flags, each of which is
an atomic statement with a URI in a controlled
vocabulary. SSF defines the properties of the
world in the specific state. We use ternary logic
for status flags, thus the possible truth values
are True, False, and Unknown. We use the
open-world assumption, i.e., any status flag not
mentioned in the state has the value unknown.
SDT is a set of semantic data types represent-
ing the availability of data. A semantic data
type is a membership statement in Descrip-
tion Logic of a class (or a union of classes) in
an ontology. An example state could be: <{
orderComplete=True, orderClosed=False }, {
ontology1#OrderID(Msg
1
)} >
The reason why we use predicate logic for status
flags is because it is simple for the user to specify
the values of status flags in predicate logic, and
computationally efficient. On the other hand, we
use description logic for semantic data types be-
cause we need more expressive power to compare
related messages, such as those with sub-class re-
lationships.
Abstract semantic Web service (Verma, 2006):
Our definition of an abstract semantic Web service
is built upon SAWSDL (39, 2007) An abstract se-
mantic Web service SWS can be represented as a
vector: SW S = (sop
1
, sop
2
, , sop
n
) Each sop is a
semantic operation, which is defined as a 6-tuple:
sop = <op, in, out, pre, eff, fault>where,
op is the semantic description of the operation.
It is a membership statement of a class or prop-
erty in an ontology.
in is the semantic description of the input mes-
sage. It is a set of semantic data types, stating
what data are required in order to execute the
operation.
out is the semantic description of the output
message. It is a set of semantic data types, stat-
ing what data are produced after the operation
is executed.
pre is the semantic description of the precondi-
tion. It is a formula in predicate logic of status
flags representing the required values of the sta-
tus flags in the current state before an operation
can be executed.
eff is the semantic description of the effect. It
can be divided into two groups: positive effects
and negative effects, each of which is a set of
status flags describing how the status flags in a
state change when the action is executed.
ICEIS 2007 - International Conference on Enterprise Information Systems
456
fault is the semantic description of the excep-
tions of the operation represented using classes
in an ontology.
Table 1 illustrates an example of the representation of
part of the Order Management System Web service
described in our running scenario.
4.2 Semantic Template
While an abstract semantic Web service definition
represents the operations and messages of a service
provider, a Semantic Template models the require-
ment of the service requester. It is the way a ser-
vice requester models the data, functional and non-
functional specifications of a task. Formally semantic
templates (ST ) are defined by a collection of template
terms.
ST = {sopt is a template term}.
A template term sopt = {op, in, out, pre, e f f , f ault}
is a 6-tuple with:
op: The operation
in: The inputs to the operation
out: The output of the operation
pre:The pre conditions of the operations
e f f : The effects of the operation
f ault: The fault generated by this operation.
5 AUTOMATIC WEB SERVICE
COMPOSITION
5.1 Formal Definition of Web Service
Composition
A semantic Web service composition problem in-
volves composing a set of semantic Web services
(SWSs) to fulfill the given requirements, or in our
case a Semantic Template. Figure 2 illustrates our ap-
proach.
A semantic operation (Operation
k
in figure 2) has
to be checked by the satisfy operator (X in figure
2)against the current extended state before it can be
added in the process specification. After it is added,
a successor extended state is created by applying the
apply (+ in figure 2) operator. We will give the for-
mal definition of satisfy and apply operators below.
For convenience, we use the following notations.
Satisfy operator is a function mapping an ex-
tended state s
i
and a semantic operation sop
k
to T or
F. Formally textitsatis f y is defined as:
Figure 2: Business Process Levels.
Definition 1 satisfy: (s
i
, sop
k
) {T, F}
This function maps to T (in such case, s
i
satisfies sop
k
and is written as: s
i
× sop
k
) if and only if:
ε(Pre(sop
k
), SSF(s
i
)) = True, where ε( f , v) is an
evaluation of formula f based on the truth values
in v.
(Onto SDT (s
i
)) in(sop
k
) , where Onto is the
ontology schema for semantic data types.
That is, the precondition of sop
k
holds based on the
truth values of the status flags in state s
i
, and the
semantic data types of s
i
together with the ontology
schema entails the input of sop
k
. For example, the
following state satisfy the operation sop
3
in table 1:
<{orderComplete = True,orderClosed =
False}, {ontology1#OrderID(Msg
x
}>
Here the semantic data type OrderID comes from an
output message of any previous operation, or the ini-
tial message of the Semantic Template, so we put
Msg
x
in the above example.
Apply operator is a function mapping an ex-
tended state si and a semantic operation sop
k
to a new
extended state s
j
. Formally this is defined as
Definition 2 apply: (s
i
, sop
k
) s
j
Alternatively, we write s
i
+ sop
k
s
j
This operator
does the transition both on status flags and semantic
data types.
For status flags:
s f positive(e f f (sop
k
)), value(s f , s
j
) = True
s f negative(e f f (sop
k
)), value(s f , s
j
) = False
s f (e f f (sop
k
)), s f (s
j
) = s f (s
i
)
That is, a status flag in the positive effects is true
in s
j
, a status flag in the negative effects is false in
s
j
, while any status flag in s
i
but not in the effect
is assumed to be unchanged in s
j
.
AUTOMATIC COMPOSITION OF SEMANTIC WEB SERVICES USING PROCESS MEDIATION
457
Table 1: Representation of Order Management System Web service.
sop sop
1
sop
2
sop
3
op CreateNewOrder AddLineItem CloseOrder
in CustomerID LineItemEntry,Order OrderID)
out OrderID AddItemResult ConfirmedOrder
pre orderComplete orderClosed orderComplete orderClosed
eff negative:{orderComplete, orderClosed} positive:{orderComplete} positive: { orderClosed }
fault sop
1
fault sop
2
fault sop
3
fault
Table 2: Representation of Order Management System Web service.
Notation Explanation
SSF(s) The set of status flags of extended state s
Value(s) The truth value of a status flag sf in extended state s
SDT(s) The set of semantic data types of extended state s
in(sop) The input messages of semantic operation sop
pre(sop The output messages of semantic operation sop
eff(sop) The effect of semantic operation sop
positive(eff) The positive effects of eff
negative(eff) The negative effects of eff
For semantic data types: SDT (s
j
) = SDT (s
i
)
out(sop
k
) That is, the semantic data types (mem-
bership statements) in s
j
are the union of the se-
mantic data types in s
i
and the output of sop
k
.
As an example, if we apply the operation sop
3
in
1 to the state
<{orderComplete = True,orderClosed =
False}, {ontology1#OrderID(Msgx)}>
we will get a new state:
<{orderComplete = True,orderClosed = True}, {
ontology1#OrderID(Msgx),
ontology1#Con f irmedOrder(sop
3
OutMsg)}>
5.2 Composition of Semantic Web
Services
We consider a SWS composition problem as an AI
planning problem such that the semantic operation
template defines the initial state and the goal state
of the problem specification: Initial state is the
extended state at the beginning of the process. It is
defined by the precondition and initial message of the
semantic operation template ψ.
s
0
= <ss f
0
(sopt), in(sopt)>
Goal state is a requirement of the extended state at
the end of the process. It is defined by the goal and
output of sopt.
goalstate = <gl(sopt), out(sopt)>
Composition of semantic Web services is a func-
tion
swsc : (sopt, SWS
s
) plan
Where,
sopt is a semantic operation template.
SWSs is the set of the semantic operations in the
semantic Web services.
plan is a DAG (Directed Acyclic Graph) of opera-
tions. Every topological sort of the DAG (say one
of them is sop
1
, sop
2
, , sop
n
) must conform to the
following restrictions:
s
0
× <pre(sop
1
), in(sop
1
)>
s
0
+ sop
1
s
1
s
i1
× <pre(sop
i
), in(s
i
)>
s
i1
+ sop
1
s
i
s
n
× goalstate
That is, every topological sort of the plan must trans-
form the initial state into the goal state by conforming
to the satisfy and apply operators. Loops are gener-
ated in a post-process step that is explained at the of
subsection 5.3.
5.3 Planning for Process Mediation
AI planning is a way to generate a process automat-
ically based on the specification of a problem. Plan-
ners typically use techniques such as progression (or
forward state-space search), regression (or backward
state-space search), and partial-ordering. These tech-
niques attempt to use exploration methods such as
ICEIS 2007 - International Conference on Enterprise Information Systems
458
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
Levesque, H. J. (2005). Planning with loops. In IJCAI,
pages 509–515.
Narayanan, S. and Mcilraith, S. A. (2002). Simulation, ver-
ification and automated composition of web services.
In WWW ’02: Proceedings of the 11th international
conference on World Wide Web, pages 77–88, New
York, NY, USA. ACM Press.
Pistore, M., Traverso, P., Bertoli, P., and Marconi, A.
(2005). Automated synthesis of composite bpel4ws
web services. In ICWS, pages 293–301.
Ponnekanti, S. R. and Fox, A. (2001). Sword: A developer
toolkit for web service composition.
Rao, J., Dimitrov, D., Hofmann, P., and Sadeh, N. (2006).
A mixed initiative approach to semantic web service
discovery and composition: Sap’s guided procedures
framework. In ICWS, pages 401–410.
Rao, J., K
¨
ungas, P., and Matskin, M. (2004). Logic-based
web services composition: From service description
to process model. In ICWS, pages 446–453.
Russell, S. J. and Norvig, P. (2003). Artificial Intelligence:
A Modern Approach. Pearson Education.
Sirin, E., Parsia, B., Wu, D., Hendler, J., and Nau, D.
(2004). Htn planning for web service composition us-
ing shop2. Journal of Web Semantics, 1(4):377–396.
Stephan, W. and Biundo, S. (1995). Deduction-based
refinement planning. Technical Report RR-95-13,
Deutsches Forschungszentrum f
¨
ur K
¨
unstliche Intelli-
genz GmbH
Erwin-Schr
¨
odinger Strasse
Postfach 2080
67608 Kaiserslautern
Germany.
Traverso, P. and Pistore, M. (2004). Automated compo-
sition of semantic web services into executable pro-
cesses.
van der Aalst, W. and Hofstede, A. (2002). Yawl: Yet an-
other workflow language.
Verma, K. (2006). Configuration And Adaptation of Seman-
tic Web Processes. PhD thesis, University of Georgia.
AUTOMATIC COMPOSITION OF SEMANTIC WEB SERVICES USING PROCESS MEDIATION
461