DYNAMIC SERVICE COMPOSITION:
A PETRI-NET BASED APPROACH
Michael K
¨
ohler, Daniel Moldt, Jan Ortmann
University of Hamburg, Computer Science Department
Vogt-K
¨
olln-Str. 30, D-22527 Hamburg
Keywords:
Web Services, High-level Petri Nets, Semantic Service Composition, Ontologies.
Abstract:
Dynamic service composition requires a formal description of the services such that an agent can process
these descriptions and reason about them. The amount of detail needed for an agent to grasp the meaning of a
service may lead to clumsy specification.
Petri nets offer a visual modeling technique for processes, that offers a refinement mechanism. Through this,
a specification can be inspected on the level of detail needed for a given objective.
In this paper we introduce a Petri net based approach to capture the semantics of services by combining Petri
nets ideas from the description logic area focusing on ontologies. The resulting framework can than be used
by agents to plan about activities involving services.
1 INTRODUCTION
The dynamic composition of services requires a de-
tailed understanding of the effects the invocation of a
particular service has. This makes it necessary to have
a formal semantics that can be interpreted by machi-
nes.
There is always a tradeoff between formal and pre-
cise semantics of a model and ease of modeling. As-
suming that a semantic description always has to be
formal, we chose Petri nets as a conceptual back-
ground, which is rather intuitive because of its visual
notation and the possibility to refine models. We con-
sider three aspects of semantic service modeling of
major importance:
• A common vocabulary shared by the participants
provided by a common ontology,
• a description of the functional behavior of single
Web services or parts thereof, and
• a description of the coordination of multiple ser-
vices.
An agent has some knowledge about the state of the
world it is located in. To change this state the (soft-
ware) agent can communicate to the world via mes-
sage passing (i.e. through the invocation of other ser-
vices). These messages have to be understood by
both sides which is guaranteed by a common onto-
logy. (For further information see (Staab and Studer,
2004).) The functional behavior will be described by
the change of the interpretation of an algebraic speci-
fication. This is related to ideas of abstract state ma-
chines (B
¨
orger and St
¨
ark, 2003). Finally the coordi-
nation and sequence in which the services are execu-
ted are modeled by a Petri net.
The combination of services has different aspects.
The services need to be invoked in the right order
and the right services showing the right behavior need
to be invoked. In this paper we will focus on the
operational aspects of behavior and will refer to e.g.
(van der Aalst, 2003) or (Kindler et al., 2000) for
an discussion of when services and workflows fit to-
gether.
A Web service interprets the messages according to
a given ontology. Here, we make use of Description
Logics (Baader et al., 2002) as the formal basis for
the ontology. To specify the functionality of a service,
we use algebraic constructs (Ehrig and Mahr, 1985).
By the execution of the different possible processes
of a net, an agent can then pick a sequence of services
best suited for a given objective. Planning can thus
be considered as reaching a particular marking from a
given one and is hence closely related to the planning
as model checking approach as e.g. in (Giunchiglia
and Traverso, 1999).
The paper starts with an example we will use to il-
lustrate the main idea in Section 2. Hereafter follows
a brief introduction to Description Logics in Section 3
before we introduce Service Description Nets in Sec-
tion 4. We will then illustrate the idea with the exam-
159
Köhler M., Moldt D. and Ortmann J. (2006).
DYNAMIC SERVICE COMPOSITION: A PETRI-NET BASED APPROACH.
In Proceedings of the Eighth International Conference on Enterprise Information Systems - SAIC, pages 159-165
DOI: 10.5220/0002494901590165
Copyright
c
 SciTePress

ple and give a short overview of our implementation
in Section 5 and will finally draw a conclusion and
give an outlook in Section 6.
2 MOTIVATIONAL EXAMPLE
Dynamic Web service orchestration is useful in a va-
riety of different application areas. Here, we will fo-
cus on the management of ship-supplies as an illustra-
ting example. Imagine a ship entering different ports
all over the world. The only time when it can purchase
supplies is while mooring in a port, which is normally
only a short period of time. Hence the delivery of all
supplies needs to be coordinated in advance such that
there is no delay. There might be different providers
offering different prices for the same goods. Additio-
nally we might have unexpected needs. For example,
due to heavy weather nobody attended the restaurant,
so that there is less need of food, but the weather cau-
sed a fuel shortage.
If we access the different providers of goods by
Web services, we would certainly like to know, what
happens if we chose a particular provider. This is
commonly given by a textual description which can-
not be understood by a machine. Thus we need a more
formal description of what happens. In the case of
ship supplies we have hard constraints such as the de-
livery time and we have things we would like to be
maximized or minimized such as quality and price.
What we need to know of a service is therefore what
effects it has on the particular part of the world that
we are interested in. Having a representation of the
world, we would like to know, how this representa-
tion changes. To allow a communication in general,
all parties involved need to comply with a common
vocabulary given by an ontology.
Different services can be classified based on there
behavior. If two providers offer the same item at dif-
ferent prices we will normally put them in the same
category of services. This can be reflected by a clas-
sification of services in a process ontology. The cal-
ling agent accesses a discovery service with a pro-
cess ontology to retrieve a list of services matching a
certain class. Through their semantic description the
agent can now determine, which of the services suits
its needs best.
3 ONTOLOGIES AND
DESCRIPTION LOGICS
Ontologies specify the concepts that are used in a gi-
ven domain. A concept is determined by its attributes
and by the roles existing between itself and the other
concepts. Concept descriptions are built inductively
from a set of primitive concepts, roles and attribu-
tes by using concept and role constructors. The most
widespread approach is to model the concepts of an
ontology by a Description Logic (DL). Different De-
scription Logics vary in their expressiveness, i.e. in
the number and kind of constructors they provide. We
distinguish between attributes as functional roles and
roles (non-functional). An example of a concept des-
cription would be the definition of a concept
LibraryBook
.
= Book ∀signature.Signature 
∀subject.String
Description logics knowledge bases are divided
into TBoxes and ABoxes. (For an in-depth discussion
on DL see (Baader et al., 2002).)
TBoxes (terminology boxes) hold intensional
knowledge in form of a terminology. They are built
through declarations of general properties of concepts
and thus restrict the set of possible worlds. More for-
mally, given a DL L,aL-TBox T is a finite set of
concept definition axioms of the form A
.
= C , with
A being a concept symbol and C being a L-concept
description (the defining concept).
ABoxes (assertion boxes) on the other hand allow
to describe a specific state of the world. They hold
extensional knowledge that is specific to the individu-
als of the domain of discourse. A concept assertion is
denoted C(i) where C is a concept description and i
is an individual. A role assertion is denoted R(i
1
,i
2
)
where R is a role symbol and i
1
,i
2
are individuals.
An ABox A is a finite set of concept and role asserti-
ons. ABoxes are defined with respect to some TBox.
The LibraryBook example above would be part of the
TBox T whereas the instance LibraryBook(book43)
would be part of an ABox wrt. T .
An interpretation I is a pair (∆
I
, ·
I
) consisting of
a domain ∆
I
= ∅ and an interpretation function ·
I
,
that assigns a set A
I
⊆ ∆
I
to every concept symbol
A, a partial function a
I
:∆
I
→ ∆
I
to every attri-
bute symbol a, and a binary relation R
I
⊆ ∆
I
× ∆
I
to every role symbol R.
Let C and D be concept descriptions. D subsumes
C, denoted as C  D,iffC
I
⊆ D
I
for all interpre-
tations I. C ≡ D ⇔ C  D ∧ C  D denotes the
equivalence of two concept descriptions.
4 MODELING OF SERVICE
BEHAVIOR USING NETS
To model scenarios like the one given in Section 2
we introduce Service Description nets. They have
been discussed more formally in (K
¨
ohler and Ort-
mann, 2005). Service Description nets (SD nets) can
be mapped to algebraic Petri nets. This allows us
to adopt the analysis techniques introduced for them
ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING
160

order1
[]
Start
_order
End
_order
_err
_deliv
_deliv
_acc
_order
_price
_acc
DeliveryReceipt
_err
_order
_order
_err
_dr
Failure
guard _deliv
_order
FuelOrder
AccountInformation
acc1
_dr
_dr
order: FuelOrder
fail: Failure
price: Price
login: Login
cancel:
return: DeliveryReceipt
Communication Channel
(place fusion)
Calling Agent
assign _acc = _customer.account;
assign (_customer) =
getCustomer(_login.name, _login.pw);
account: AccountInformation
FuelBuyService
FuelOrder
FuelOrder
_deliv
_acc
assign _dr = new DeliveryReceipt;
assign _date = deliveryDate(_order.isbn);
set _dr.deliveryDate = _date;
set _dr.order = _order;
set _dr.price = _price;
FuelOrder
_order
_dr
_acc
_acc
_dr
assign (_deliv) = isDeliverable(_order.quantity);
_customer
_customer
Price
_login
assign _price = new Price;
update (_price.currency, _price.amount)
= priceLookup(_order.quantity);
_price
_price
assign (_diff) = convertCurrency(
_price.amount,_price.currency,
_acc.currency);
update _acc.balance =
_bal => _bal-_diff;
_cc
_price
_cc
Price
_price
guard !_deliv;
assign _err =
new NotDeliverableFailure;
set _err.order = _order;
noop
Figure 4.1: An Example for a Service Description Net.
(Reisig, 1991).
A Petri net is a bipartite graph consisting of places
and transitions. More formally a Petri net N is a triple
N =(P, T, F), where P is a finite set of places, T is
a finite set of transitions with P ∩ T = ∅, and F ⊆
(P × T ) ∪ (T × P ) is a flow relation (a set of arcs).
The basic idea behind Service Description nets is
that each service affects the current state of the agents
world by changing the value of data items. A service
can either create new data items or it can modify the
attributes of existing data items. The data items are re-
presented by an ontology, which is based on Descrip-
tion Logics. Description Logics allows us to define
concepts on a formal basis and is on the other hand
well supported by tools. As described in Section 5 we
integrated (P
ROT
´
EG
´
E, 2005, ) in our Petri net simu-
lation engine (R
ENEW, 2005, ) to have an executable
model.
SD nets allow us to model the workflow of a Web
service together with the data exchanged and manipu-
lated. Hence we make use of workflow nets (van der
Aalst, 2003) or more specifically of open workflow
nets (Reisig et al., 2005). Workflow nets reflect the
specific structure of workflows with a single starting
point and a single end point. Open Workflow nets
additionally introduce border places to model the in-
coming and outgoing messages of workflows. We
further extend the expressiveness by allowing typed
messages and by allowing the functional description
of activities. The types are taken from an ontology.
The concepts modeled in the ontology can be used in
the net. The roles and attributes modeled in the onto-
logy are hidden in the inscriptions. E.g. C.x refers to
the attribute x of a concept C.
To represent the concepts and the operations de-
fined on them, we use order-sorted algebra (Go-
guen and Meseguer, 1992). Order-sorted algebra ex-
tends many-sorted algebras by a partial order relation,
which the sorts need to obey. Here, it is used to define
an order-sorted logical specification as follows:
Definition 1 (Logical Specification, Structure). A
logical specification is a tuple LS =(S, ≤, Ω,E,Π)
where S is a set of sorts, ≤ is a partial order on the
set of sorts, Ω is a set of operation symbols and E is
a set of equations such that (S, ≤, Ω,E) is an order-
sorted specification and Π=(Π
w
)
w∈S
∗
is a family
of predicate symbols, which is disjoint from S and Ω.
A structure (or interpretation) of a logical speci-
fication LS is a triple A
LS
=(S
A
, Ω
A
, Π
A
) con-
sisting of a family of sets S
A
=(A
s
)
s∈S
respec-
ting ≤ and of operations Ω
A
=(ω
A
)
ω∈Ω
with ω
A
:
A
s
1
× ... × A
s
n
→ A
s
for all ω ∈ Ω
s
1
...s
n
,s
as
well as a family of relations Π
A
=(π
A
)
π∈Π
with
π
A
⊆ A
s
1
× ...× A
s
n
for π ∈ Π
s
1
...s
n
. ♦
DYNAMIC SERVICE COMPOSITION: A PETRI-NET BASED APPROACH
161

Using a logical specification we can now define the
current state of an agent’s world as formula in first
order logic. This represents the ABox of our ontology.
To state, that ship vessel01 has 2000 gallons of fuel
we might have the following fact in our knowledge
base:
stored(vessel01,item04)∧ItemQuantity(item04)∧
quantity(item04,2000)∧unit(item04,Gallon)∧
type(item04,Diesel)
Naturally the knowledge base entry depends on the
ontology. Here, the predicates represent the roles (and
attributes) defined by an ontology. The operations
defined on the data are specified by an algebra. Fi-
gure 4.1 shows a potential description of a ship sup-
plies workflow as SD-net. Its underlying structure
consists of two open workflows that yield a workflow
net when composed by place fusion. The net on the
left side represents the calling client whereas the net
on the right side represents the Web service invoked.
Some information is optional to invoke FuelBuySer-
vice. The invoking service can either cancel the ope-
ration, provide a Login or some new AccountInforma-
tion. In Figure 4.1 the latter alternative is chosen.
We say a logical specification is compatible with
an ontology if each named concept has a correspon-
ding sort, that respects the hierarchy defined by the
ontology and each role has a least sort that is its do-
main among the set of sorts. Furthermore we require
the predicate symbols to have the sorts of the corre-
sponding roles. Through this, we can now define a
net class changing the current concepts and attributes
of an ontology by changing the interpretation of its
logical specification, which we will call Service De-
scription Nets. These nets have special inscriptions
to change the interpretation of the predicates. Addi-
tionally we have variable assignments that assign the
result of a term evaluation to a variable, so that we can
create new items or use local variables.
We can now specify the syntax of the transition ins-
criptions. In the following we will let T
Σ,s
(X) denote
the set of terms of sort s over the set of variables X
wrt. the signature Σ.
Definition 2 (Assignment and Update, Consistency).
Let LS =(S, ≤, Ω,E,Π) be a logical specification
and X a set of variables. Given v ∈ X
s
and s, s

∈ S
a variable assignment is of the form
1. assign v =news,
2. assign v = t

with t

∈ T
Σ,s
(X),or
3. assign v = t

.π with t

∈ T
Σ,s

(X), π ∈ Π
s

,s
.
A predicate update for some π ∈ Π
s

,s
, t ∈ T
Σ,s

(X)
is of the form
4. update t.π = t

with t

∈ T
Σ,s
(X).
A set of variable assignments Ass (Assignment set)is
consistent if no left hand side occurs more than once
in Ass, i.e. (assign v = rexp) ∈ Ass and (assign v =
rexp

) ∈ Ass implies rexp = rexp

. A set of pre-
dicate updates is consistent similarly if no left hand
side occurs more than once in it. A set of assignments
together with a set of updates is called a set of ac-
tion statements Act or Act(X) respectively if it ran-
ges over a specific set of variables X. ♦
If a variable occurs on the left hand side of a varia-
ble assignment it is called bound, otherwise it is called
free. The set of all bound variables of an assignment
set Ass is denoted by Bound(Ass).
The assignment statements define a natural exten-
sion α
ext
of a variable assignment α as long as there
are no circular dependencies in the assignment state-
ments. Each free variable gets assigned the value of
the term on the right hand side of the equation eva-
luated under ¯α or under the extended evaluation ¯α
ext
.
The firing of a set of action statements is done by first
evaluating the extended assignment, i.e. by evaluating
all assign statements, and then executing the update
statements.
Definition 3 (Firing of Action Statements). Given
an interpretation A
LS
=(S
A
, Ω
A
, Π
A
) of LS and an
assignment α : X → A, where X is the set of all free
variables. The firing of a set of action statements Act
first evaluates all assignments yielding an extended
assignment α
ext
. Then the updates of the form u =
(update t
.π = t

) are evaluated in A
LS
. This yields a
successor interpretation A

LS
=(S
A
, Ω
A
, Π

A
) such
that we have Π

A
=(Π
A
\{π
A
}) ∪{π

A
} where
π

A
=(π
A
\{(¯α
ext
(t),x)}) ∪{(¯α
ext
(t), ¯α
ext
(t

))}
for some value x. ♦
In a consistent update set, each predicate update af-
fects either a different predicate or a different value of
the same predicate. Therefore we have the following
lemma.
Lemma 4: For a consistent set of predicate updates
the firing can be done in arbitrary order.
This allows us to speak of the firing of a consistent
update set in an interpretation A
LS
which will lead to
a successor interpretation. Now that we have modeled
the change of attributes and roles by logical specifica-
tion and the creation of objects by assignments, we
can use this in a net, where we can define the order in
which these changes occur.
Service Description Nets (SD Net) consist of typed
places, arcs inscribed by variables and transitions with
guards. Additionally transitions specify the change
of the predicates. The control flow is modeled by a
dedicated sort called s
token
which has the constant •
as its only operation symbol. If an arc or place has
no inscription it is implied that it is of sort s
token
.
Figure 4.1 shows an SD Net.
Definition 5 (Service Description Net, Service Des-
cription Net system). Let LS =(S, ≤, Ω,E,Π) be
ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING
162

a logical specification compatible to an ontology O
such that LS contains the concrete domain B of boo-
leans as well as a sort ⊥
undef
, with ⊥⊥
undef
 C
for all C =⊥.
A Service Description Net is a tuple SDN =
def
(LS,X,N ,d,W,G,act) where
• LS =(S, ≤, Ω,E,Π) is a logical specification
as defined in Def. 4,
• X is a set of LS-variables,
•N=(P, T, F ) is a Petri net,
• d : P → S is a place typing,
• W : F → X is an arc inscription such that for
p ∈ P and f ∈ F we have W (f) ∈ (X
s
\
Bound(act(t))) with d(p) ≤ s if f =(p, t) and
W (f ) ∈ X
s
with s ≤ d(p) if f =(t, p),
• G : T → T
Σ,Bool
(X) assigns an enabling con-
dition to each transition, and
• act : T → Act(X) assigns a regular and consis-
tent set of assignments and updates to each tran-
sition as defined in Def. 4.
A Service Description Net together with an initial
state Q
0
=(m
0
, I
0
LS
) consisting of an initial mar-
king m
0
: P → T
Σ
such that for m
0
(p) ∈ T
Σ,s
we
have s ≤ d(p) for all p ∈ P and an initial interpreta-
tion I
0
LS
=(S
I
0
, Ω
I
0
, Π
I
0
) of LS =(S, ≤, Ω,E,Π)
is called a Service Description Net system. ♦
To guarantee the executability of Service Descrip-
tion Nets, we require that a variable used on an output
arc of a transition is either also used on an input arc
or defined through an assignment, thus reducing the
search space for possible bindings.
Definition 6 (State, Marking, Enabling and Firing).
A marking m of a Service Description Net SDN is
a mapping m : P → T
Σ
such that m(p) ∈ T
Σ,s
with s ≤ d(p) for p ∈ P .Astate Q =(m, I
LS
)
is a marking together with an interpretation I
LS
=
(S
I
, Ω
I
, Π
I
) of LS.
A transition t is enabled under a variable assi-
gnment α : X → A iff the evaluation of the activation
condition ¯α(G(t)) = true and for all places p ∈ P
we have m(p) ≥ ¯α(W (p, t)) and α assigns a value to
each free variable in act(t).
The firing of a transition under a variable binding
α is denoted as state transition Q
t,α
−−→ Q

which
is again split into m
t,α
−−→ m

and I
LS
t,α
−−→I

LS
.
m

is defined for each place p ∈ P as m

(p)=
m(p) − α(W (p, t)) + α(W (t, p)). The interpreta-
tion I

LS
=(S
I
, Ω
I
, Π

I
) is defined as in Defini-
tion 4 by successively applying the predicate upda-
tes (update t
.π = t

) ∈ act(t) resulting in a sequence
Π
I
=Π
0
I
,...,Π
n
I
=Π

I
with Π
i+1
I
=(Π
i
I
\{π
i
I
}) ∪
{(π
i
I
\{(¯α(t),x)}) ∪{(¯α(t), ¯α(t

))}} for some value
x. ♦
For convenience reasons we introduce two abbre-
viating notions for Service Description Net inscripti-
ons:
5. update t
.π = v

⇒ t

, which is equivalent to the
assignment assign v

= t

.π together with the predi-
cate update update t
.π = t

, and
6. t
.π within a term expression, which is equivalent
to assign v

= t

.π and the usage of v

instead.
The second abbreviation allows us to write e.g.
assign v =
book.author.name instead of
assign v1 =
book.author and assign v = v1.name
Additionally we require a repository containing a sub-
set of A where assignments of the form (assign v =
new s) can retrieve an a ∈ A
s
that has not been pre-
viously used in the net. Practically this is done by a
pool, from which an element is taken. For most prac-
tical scenarios we have a finite set of items, so that we
can determine an upper bound as the size of the pool.
Furthermore it is often convenient in practice to
have not only binary relations but relations of arbi-
trary arity. Here, we will only consider functional re-
lations and call them predicates as well. For an n-ary
predicate π we additionally introduce
assign (v
1
,...,v
j
) = π(t
1
,...,t
i
), (i + j = n)
which replaces the value of v
1
,...,v
i
by appropriate
values such that (t
1
,...,t
i
,v
1
,v
j
) ∈ π
LS
.
Through this, we can express database queries or
external queries that assign values to more than one
variable. In Figure 4.1 such an assignment operation
would be priceLookup. For these assignments the
definition of the logical specification has to be modi-
fied, to allow n-ary predicates.
There are some specialties about the net definition
above. We allow only one concept instance on each
place. Having more than one concept instance on a
single place results in picking one instance nonde-
terministicly, if more than one instance satisfies the
guards of a transition. Nondeterminism, however, is
rarely intended and only complicates planning. Addi-
tionally by restricting the number of tokens on a place
to one, the underlying net becomes safe and will be
easier to analyze. This restricts the expressiveness of
the net on the one hand, but makes planning and ana-
lyzing easier on the other hand. Although the change
of roles (i.e. binary relations) could also be modeled
by Transform nets as defined above, we omitted them,
since we did not introduce flexible assignments. The-
refore, in Figure 4.1 only attributes have been mode-
led.
5 EXAMPLE REVISITED
Let us return to the SD Net in Figure 4.1 again. We
will now explain the first steps the net might take. We
have the following ontology and the following initial
DYNAMIC SERVICE COMPOSITION: A PETRI-NET BASED APPROACH
163

facts in our knowledge base:
Ontology (TBox)
FuelOrder
.
= Order 
quantity.ItemQuantity 
type.FuelType
AccountInformation
.
= currency.Currency 
balance.Decimal 
owner.Person 
acc number.integer 
bank code.integer
NotDeliverableFailure
.
= Failure  order.Order
Price
.
= amount.Decimal 
currency.Currency
DeliveryReceipt
.
= deliveryDate.Date 
order.Order 
price.Price
...
Facts (Abox) (initial)
FuelOrder(order1)
order1.quantity = quant1
order1.type = Diesel
ItemQuantity(quant1)
quant1.quantity = 200
quant1.unit = Gallon
AccountInformation(acc1)
acc1.currency = Euro
acc1.balance = 40000
...
After the message with the order arrives at the ser-
vice, the service looks up, whether the order quantity
can be delivered. If it cannot be delivered, the calling
agent receives a NotDeliverableFailure. If it can be
delivered, the agent receives a DeliveryReceipt and
the account corresponding to the AccountInformation
the agent has sent will have a reduced balance. After
the execution of the net, the knowlegde base might
contain the following statements:
Facts (Abox) (final)
FuelOrder(order1)
order1.quantity = quant1
order1.type = Diesel
ItemQuantity(quant1)
quant1.quantity = 200
quant1.unit = Gallon
AccountInformation(acc1)
acc1.currency = Euro
acc1.balance = 39200
DeliveryReceipt(dr1)
dr1.deliveryDate = date1
dr1.order = order1
dr1.price = price1
date1.day=05
date1.month=12
price1.amount=800
price1.currency=Euro
...
The agent can now calculate the difference and rea-
son about what happens when it executes the service.
In this simple scenario we only have one service. It
is of course possible to have a much more complex
scenario with many different services. Another ma-
jor advantage of Petri nets as underlying formalism is
their support for refinement. This allows us to build
classes of net fragments that correspond to classes of
services. Saying that a BuyService always involves
some kind of payment and some kind of delivery, we
can now refine this basic structure in different ways
resulting in an ontology of services – an approach
very similiar to the one in (OWL Services Coalition,
2005).
The approach described in this paper has been pro-
totypically implemented using (R
ENEW, 2005, ) and
(P
ROT
´
EG
´
E, 2005, ). The SAND (Service Agent Net
Description) Plug-in is a plug-in of the R
ENEW Pe-
tri net simulation engine which allows to model and
execute Service Description Nets. It makes use of the
P
ROT
´
EG
´
E API to import ontologies which can then
be used within an SD net. These ontologies can be
either P
ROT
´
EG
´
E files or OWL ontologies. Since the
latter is a standardized exchange format, this format
is strongly encouraged. The current attribute values
of the net can be inspected by clicking on the corre-
sponding tokens in the simulation. This allows a user
to visually follow the steps and their impact on the
data. S
AND can automatically evaluate different nets
and can return the one best suited for a given task to
the user. Through this, an agent can select or preselect
workflows with the desired qualities. As for now this
planning is simply carried out by a depth-first search,
which, however, may not terminate if the underlying
workflow net has an infinite reachability graph.
6 CONCLUSION AND OUTLOOK
In this paper we have presented a formal framework
to model processes with data based on description lo-
gics, algebra and Petri nets. We see this as a step to-
ward a semantic description of processes as it is nee-
ded in the Semantic Web services and agent context.
Predicate/Transition nets (Genrich, 1986) have as
well used petri nets to model the modification of lo-
gical terms. Service Description Nets, however, focus
more on the manipulation of information represented
by the terms defined in an ontology.
Since Service Description Nets are closely related
to algebraic nets, analyzing techniques for algebraic
nets as e.g. discussed in (Reisig, 1991) can be app-
lied to Service Description Nets as well. Additionally,
this relationship guarantees the executability of these
nets. Further investigation has to show if the special
structure of Service Description Nets results in other
interesting properties and analysis techniques. Fur-
ICEIS 2006 - SOFTWARE AGENTS AND INTERNET COMPUTING
164

thermore it should be discussed to what extend it is
sensible to forget about the algebraic structure and re-
duce Service Description Nets to S/T-Nets or work-
flow nets to study their behavioral properties.
As further research we will classify services ac-
cording to their behavior and their interface. This
will give us a semantic classification of Web services
which will make planning much faster by selecting
only services from particular classes. Another topic
is the improvement of the planning and the conver-
sion of the representation to some XML dialect such
that we can import the process description of other
formats (e.g. OWL-S).
REFERENCES
Baader, F., Calvanese, D., McGuinness, D., Nardi, D., and
Patel-Schneider, P. F., editors (2002). Description
Logic Handbook: Theory, Implementation and Ap-
plications. Cambridge University Press, Cambridge
(Mass.).
B
¨
orger, E. and St
¨
ark, R. (2003). Abstract State Machines –
A Method for High-Level System Design and Analysis.
Springer, Berlin et.al.
Ehrig, H. and Mahr, B. (1985). Equations and initial seman-
tics; Fundamentals of algebraic specification. EATCS
Monographs on Theoretical Computer Science. Ber-
lin.
Genrich, H. J. (1986). Predicate/transition nets. In Brauer,
W., Reisig, W., and Rozenberg, G., editors, Advances
in Petri Nets, volume 254 of Lecture Notes in Compu-
ter Science, pages 207–247.
Giunchiglia, F. and Traverso, P. (1999). Planning as model
checking. In Biundo, S. and Fox, M., editors, ECP,
volume 1809 of Lecture Notes in Computer Science,
pages 1–20.
Goguen, J. A. and Meseguer, J. (1992). Order-sorted al-
gebra I: equational deduction for multiple inheritance,
overloading, exceptions and partial operations. Theor.
Comput. Sci., 105(2):217–273.
Kindler, E., Martens, A., and Reisig, W. (2000). Inter-
operability of workflow applications: Local criteria
for global soundness. In van der Aalst, W. M. P., De-
sel, J., and Oberweis, A., editors, Business Process
Management, volume 1806 of Lecture Notes in Com-
puter Science, pages 235–253.
K
¨
ohler, M. and Ortmann, J. (2005). Formal aspects for
semantic service modeling based on high-level petri
nets. In Proceedings of the International Conference
on Intelligent Agents, Web Technologies and Internet
Commerce (IAWTIC) 2005.
OWL Services Coalition (2005). OWL-S1.1 Release. Tech-
nical report, ˙www.daml.org/services/owl-s/1.1/.
P
ROT
´
EG
´
E (2005). The prot
´
eg
´
e ontology editor and know-
ledge acquisition system. http://protege.stanford.edu/.
Provides references to programs, source code and do-
cumentation of the Prot
´
eg
´
e tool set.
Reisig, W. (1991). Petri nets and algebraic specifications.
In Jensen, K. and Rozenberg, G., editors, High-level
Petri Nets – Theory and Application, pages 137–170,
Berlin, Heidelberg. Springer.
Reisig, W., Schmidt, K., and Stahl, C. (2005). Kommunizie-
rende workflow-services modellieren und analysieren.
Informatik - Forschung und Entwicklung.
R
ENEW (2005). RENEW – the reference net workshop.
http://www.renew.de/. Provides references to pro-
grams, source code and documentation of the Renew
tool set.
Staab, S. and Studer, R., editors (2004). Handbook on Onto-
logies. International Handbooks on Information Sys-
tems.
van der Aalst, W. M. P. (2003). Inheritance of interorga-
nizational workflows: How to agree to disagree wi-
thout loosing control? Inf. Tech. and Management,
4(4):345–389.
DYNAMIC SERVICE COMPOSITION: A PETRI-NET BASED APPROACH
165