Modeling of Web Services Flow

Mathews Thomas
IBM Global e-business
Solutions
USA
Johnson P Thomas
Department of Computer Science
Oklahoma State University
USA
email:jpt@okstate.edu
George Ghinea
Department of Computing
Brunel University
UK
Abstract
Services such as automatic purchasing, automatic
updating of prices, or getting latest information etc, can
be provided on the Internet using Web services
technology. A client can access these services using the
Internet. Web Services infrastructure includes some
standards, such as Simple Object Access Protocol
(SOAP), Web Services Description Language (WSDL)
and Universal Description, Discovery and Integration
(UDDI). In this paper we represent distributed web
services by modeling the flow of messages and methods
in a web service transaction. Such a model assists the
web services designer to ensure the correctness of web
flows in terms of deadlock and correct termination of the
web services transaction. WSDL and methods are
modeled using Petri Nets. A software tool is implemented
for extracting the model from the WSDL description of
the web services flow.
1. Introduction
In todays e-commerce environment, various commercial
and other organizations provide their services through the
web. A single business transaction therefore invokes a
number of web services. Web services provide a
conceptual foundation and a technology infrastructure for
service-oriented computing [4]. It allows program written
in different languages on different platforms to
communicate with each other in standard-based way.
Web services are considered as reusable software
components [12] over the Internet. They are not limited
to one environment, but can be integrated into every
software-system that is web service-aware [11].
Web services are rapidly evolving and are expected
to change the paradigms of both software development
and use [1]. Web services involve interaction between
different distributed sites on the Internet. New web
services are continuously being added and linked to
existing web services. In such a dynamic distributed
environment, there is enormous potential for deadlock
and other problems. It is therefore essential to model web
services and reason about them to verify the correctness
of the services. Although tools exist for developing web
services, tools for the abstract modeling of these web
services to verify desirable properties such as absence of
deadlock are limited. In this paper we model Web
services using Petri Nets.
Petri Nets are a graphical and mathematical tool [10]
[6] used for modeling and analyzing systems with
concurrency. The mathematical framework behind Petri
Nets facilitates reasoning about the model generated. We
developed software for Petri net modeling of WSDL and
Methods description of Web Services by Visual studio.
This paper proposes a Petri Net merging method to model
the integration of distributed web services.
1.1 Objectives
The main objective of this paper is to model and verify
the correctness of message flows in web services. This is
achieved by generating a model of the web services. This
model is correct by construction, such that the web
services is free from deadlocks, will terminate correctly
and will function as desired. To realize this main
objective we first generate a Petri Net model of
individual web services. This is achieved by parsing the
WSDL and collecting all required information about
input/output data, network protocol, operation name and
destination. We next propose a mechanism for merging
different distributed web services to create a model of the
entire web service business transaction. As stated earlier,
a single business transaction invokes a number of web
services. The proposed Petri Net model ensures that the
merged system possesses desirable properties, i.e., is
deadlock-free and safe.
Proceedings of the IEEE International Conference on E-Commerce (CEC03)
0-7695-1969-5/03 $17.00 2003 IEEE
2. Web Services
Web services are self-contained, self-describing,
modular applications that can be published, located, and
invoked across the Web. Web services perform functions,
which can be anything from simple requests to
complicated business processes. Once a Web service is
deployed; other applications (and other Web services)
can discover and invoke the deployed service. [3]. Web
services have different layers. XML Schema (XSD)
defines the message format which describes the type and
structure of XML documents, Simple Object Access
Protocol (SOAP) [21] which is a lightweight XML based
protocol for exchange of information in a decentralized,
distributed environment. Web Services Description
Language (WSDL) [22] explains how operations can be
invoked using particular transport protocol bindings and
Universal Description, Discovery and Integration (UDDI)
[23] provides a mechanism for clients to dynamically find
other web services. Web services enable the exchange of
data and the remote invocation of application logic using
XML messaging to move data through firewalls and
between heterogeneous systems. The programs written in
any language, using any component model, and running
on any operating system can access XML Web services.
Web Services are in essence a collection of standards and
protocols that allow us to make processing requests to
remote systems by speaking a common, non-proprietary
language and using common transport protocols (HTTP,
SMTP). The goal is to provide a platform for building
distributed applications using software running on
different operating systems and devices, written using
different programming languages and tools from multiple
vendors, all potentially developed and deployed
independently.
Microsoft, SUN Microsystems, IBM, HP and some
others have recently developed tools for building Web
Services. Microsoft Visual Studio.Net [15] has a friendly
interface and is a powerful tool for developing Web
Services. IBM has built Web Services support in WSDK.
WebSphere [16] offers wide interoperability with other
software and systems. Sun Microsystems is supporting
Web Services in iPlanet and developed Java WSDP
[17], which in conjunction with the Java platform allows
to build, test and deploy Web Services [18]. HP Web
Services Platform 2.0 [20] provides a standard based
architecture and toolset for creating and deploying Web
Services. Oracle is moving to support Web Services
standards in its 9i database management software,
application service and development tools [19].
A number of modeling approaches have been
reported in the literature. Directed graphs to model flows
in web services have been done by IBM [5]. Languages
for capturing flows in web services are reported in [13]
and [14]. Modeling of web services using UML and RDF
are ported in [2] and [8]. In [9] the authors describe a
Petri Net tool for building workflows. They do not
attempt to reason about the generated Petri Net
descriptions. In [7], the capabilities of Web services are
described using an ontology. Next the service
descriptions are encoded in a Petri Net formalism. Petri
Nets are employed in this paper as they are well suited
for capturing flows in web services, for modeling the
distributed nature of web services, for representing
methods in a web service and for reasoning about the
correctness of the flows.
In the Car Sale example we use in this paper, three
different web sites as shown in figure 1 are
communicating automatically with each other. If a
customer at a Car Dealer needs bank financing, then
customers data is needed by the bank to decide about a
loan approval or rejection. To send a customers data
from Car Dealer to Bank, the banks method is invoked
over the Internet. To invoke the banks method, required
parameters and its data types are encoded which are
checked from the WSDL file published by the bank.
When the Bank receives a customers data, it checks if
that is its active customer. If so then it approves
otherwise the Bank sends data to the Credit Rating Co to
check the customers credit history. Here the bank is
invoking another websites method through the Internet,
after meeting the requirements given in the WSDL file
published by the Credit Rating Co. Through the Internet
the bank invokes the method of Credit Rating Co. This
method calculates credit score, and results are returned to
the bank. When the bank receives the credit rating of the
customer, it calculates the interest rate and sends its
decision back to the car dealer. This whole flow is
automatic.
2.1 Anatomy Of WSDL
WSDL is an XML document. WSDL is used to describe
what a web service can do, where it resides, and how to
invoke it. It provides critical information about the Web
Service that both the developers and programming tools
need. In a compact, concrete way, this document
describes everything, including messages that the Web
Service understands and the format of its responses to
those messages, protocols that the service supports,
where to send messages. A WSDL document always has
a <definitions> element as its root. The WSDL-specific
elements are:
1. types: Defines the data types used by messages
2. message: Defines the data passed from one point to
another in a call
3. portType: Defines a collection of operations. The
name of operation is name of the method that is
being called.
operation: Defines a combination of input, output,
and fault messages
Proceedings of the IEEE International Conference on E-Commerce (CEC03)
0-7695-1969-5/03 $17.00 2003 IEEE
input: A message that is sent to the server;
output: A message that is sent to the client
fault: An error value returned as a result of a
problem processing a message
4. binding: Describes the protocol being used to carry
the Web Service communication; bindings currently
exist for SOAP, HTTP GET, HTTP POST, and
MIME.
5. Service: Defines a collection of ports (end points);
port specifies an address for a binding, thus defining
a single communication endpoint. Each service
should map to one portType and represent different
ways of accessing the operations in that portType.
UDDI contains information about the Web services
providers. Using UDDI the Web services provider(s) who
meets the required criteria is selected. Based on its
WSDL the method is developed accordingly. More than
one Web services requiring different transfer protocols
can be selected. Different clients can use the same Web
service. One Web service also can use another web
service to fulfill its requirements.
Figure 1: WSDL flow model of Car Dealer
3. Petri Net Modeling of Web Services
Petri nets are graphical and mathematical modeling tool
applicable to many systems [6] [10]. They are a very
useful tool for describing and studying information
processing systems, which are characterized as being
concurrent, asynchronous, distributed, parallel,
nondeterministic, and/or stochastic [6]. Petri nets
representation can also be used to analyze performance
and throughput.
3.1 Introduction
Petri nets are directed graphs. They include Places,
Transition, Token, and Arcs. Places may represent states.
Places before a transition represent the pre-firing state
and places after the transition represent the post-firing
state. Places contain tokens. Token could be data or truth
of condition. Transitions are active components,
transitions are allowed to fire only when they are enabled.
Enabled means that pre-firing conditions are met
successfully. Arcs represent the flow of system and carry
weight where k-weight is represented by k parallel arcs.
The formal definition of a Petri net [6] is:
A Petri net is a 5-tuple, PN = (P, T, F, W, M) where:
P = {p
1
, p
2
, p
m
} is a finite set of places,
T = {t
1
, t
2
, t
n
} is a finite set of transitions,
F _ (P x T) U (T x P) is a finite set of arcs,
W: F {1,2,3,} is a weight function,
M: P {0,1,2,3,} is the initial marking,
P T = C and P T = C.
The Petri net is live if there is no deadlock in the net. A
transition t in a Petri net N with initial marking M is said
to be live if and only if for any M
\
in R(N, M), there exists
a marking reachable from M
\
in which t is enabled. A
Petri net is live if all its transitions are live. A Petri net is
safe if and only if all its places are one-bounded (that is,
M(p) s 1). A path in a Petri net is a finite alternating
sequence of transitions and places. A circuit in a Petri net
is a path that begins and ends at the same transition such
that no transition or place appears more than once in the
circuit. A live and save path is a path in a Petri net such
that all the transitions in the path are live and the places
in the path are safe, given an appropriate initial marking
of the net [6]. A fundamental basis for studying the
dynamic properties of any system is reachability. In a net
the token distribution (marking) is changed on firing the
enabled transition. A sequence of firings will result in a
sequence of markings. A marking M
\
is said to be
reachable from a marking M if there exists a sequence of
firings that transforms M to M
\
. A firing or occurrence
sequence of is denoted by o = M t M
1
t
2
M
2
..M
n
or
simply o = t
1
t
2
t
n
. Here M
n
is reachable from M by o
and we write M[o>M
n
. The set of all possible markings
reachable from M in a net (N, M) is denoted by R(N, M)
or simply R(M). The reachability problem for Petri nets is
the problem of finding if M
n
c R(N, M) for a given
marking M
n
in a net (N, M).
Binding
Client-1
Bank Credit Co.
Port
Method Method
SOAP
PortType
Client-2
3.2 Petri Net model of Web Services
In our model the Petri Net WSDL mapping is as below:
Place PortType (Operations input, output
messages)
Transition Service-Port (Name, Binding name,
Location)
Token Message (Data)
Arc Binding (PortType, Protocol)
The mapping for methods is defined as:
Place data storage
Transition computational primitives
Token Message (Data)
Proceedings of the IEEE International Conference on E-Commerce (CEC03)
0-7695-1969-5/03 $17.00 2003 IEEE
The Web Services Petri Net (WSPN) representation of
web service flows or WSDL is an ordinary Timed Petri
net N:
N = ( P, T, F, W, M, t
m
, d)
Where the following applies.
- P = { p
1
, p
2
, , p
m
} is a finite set of places representing
the set of PortTypes in a web service description or a
data storage in a method
- T = { t
1
, t
2
,, t
n
} { t
reset
} is a finite set of transitions;
{ t
1
, t
2
,, t
n
}
Transitions represent Service-Port in the WSDL and
operations or computation in the methods of the web
service. The transition t
reset
models the resetting of the
web service for the next transaction.
- F and W are same as mentioned above.
- There exists a set of places P
ip
_ P where P
ip
represents
the initial state of the Web service transaction
- There exists a set of places P
op
_ P where P
op
represents the final state of the Web service transaction
- P
ip
P
op
= C.
- If p e P
ip
, M(p) = 1 else 0. This is the initial marking.
- tm: P time is the time stamp associated with a token
at a place.
- d: T time is the time duration associated with a
transition.
In the initial marking of the net, there will be a token in
each of the places P
ip
representing the initial state of the
web service transaction Attached to each place with a
token is a time value specifying the time of data
initialization for the transaction This is given by the
function t
m
. It can be seen that the WSPN modeling Web
Services are live and safe. A Petri Net model of our
example is shown in figure 2.
Properties of WSPN
The formal basis of Petri nets allows the derivation and
deduction of properties of the WSPN. Properties of the
WSPN are listed below:
Property 1: Given the WSPN N representing web
services, a subnet N
\
representing one method in N is
conflict-free and persistent.
It is not sufficient to show that the WSPN is live and safe.
The unique initial and terminating conditions of the
transaction must be satisfied. This leads to the next two
properties.
Property 2: The property of clean termination. This
property states that the web services transaction
terminates only when the transaction has been completed.
A web services transaction should not terminate after a
partial transaction.
Theorem 1- Property of Clean Termination: Given an
WSPN N = ( P, T, F, W, M, t
m
, d) with initial marking
M, there exists a final marking M
fin
such that
M
fin
e R(N, M) and M
fin
= M
op
(that is, M(P
op
) = 1).
Property 3: The property of complete initialization. This
property states that a web services transaction cannot
terminate cleanly (Theorem 1) if all the data or
information required for the transaction are not received
from the external environment.
Theorem 2 Property of Complete Initialization. Given
an WSPN N = (P, T, F, W, M, t
m
, d) with initial marking
M, where only a subset of the input places are marked,
that is, if -M
\
c M, then the marking M where M(P
op
) =1
cannot be reached.
Proofs for these properties are simple and therefore
omitted. The liveness property of the net guarantees that
the business transaction will not deadlock and the
safeness property ensure that each stage in the transaction
is unique. The WSPN representation therefore provides
for a precise and accurate framework for the description
of web services, and furthermore, captures desirable
properties of web services. The Petri net model of the
WSDL flow model of figure 2 is shown below
Bank needs credit Client-1
Port
Bank Credit
OR
Bank decides
based on report
Figure 2: Petri Net model of Car Dealer
Petri Net Merging
Models of each individual web service are merged to
obtain a system-wide view of a web business transaction.
Although the individual models may display the desired
properties of liveness, safeness and complete termination,
the merged net may not display such properties. In the
example below both nets may be safe before merging, but
after merging place C is not safe.
Merging Procedure
The WSPNs of each web service are merged to form a
single control model of the entire transaction N
c
. The
WSPNs of each web service are merged such that the
following applies.
For each WSPN of a web service N
\
C
, with set of output
places P
\
oc
= m(O(t
\
)) P
\
OR
= P
\
out
P
\
OR
, there exits a
net N
\\
C
with set of input places P
\\
IC
= m(I(t
\\
)) P
\\
IR
=
P
\\
inp
P
\\
IR
, such that there is a mapping from P
\
out
to a
Client-2
OR
Credit Co sends
report to Bank
Bank sends
decision
Proceedings of the IEEE International Conference on E-Commerce (CEC03)
0-7695-1969-5/03 $17.00 2003 IEEE
place p e P
\\
inp
of net N
\\
c
, unless P
\
out
_ m(P
OA
) or P
\\
inp
_ m(P
IA
) of the plan net N
p
. That is, there is a function
z: P
/
out
P
//
inp
for each WSPN subnet N
\
c
, with a set of output places
P
\
OR
representing the final state of the transaction, there
may be corresponding input production places P
\\
IR
in net
N
\\
c
to which they are mapped.
Given a net N
\
with initial marking M(p) = 1, for all p e
P
\
IC
where P
\
IC
= P
\
inp
P
\
IR
and a net N
\\
c
with initial
marking M(p) = 1, for all p e P
\\
IC
where P
\\
IC
= P
\\
inp

P
\\
IR
, the initial marking M
ini
of the merged net such that
P
\
out
is merged with a place p e P
\\
inp
is defined as:
M
ini
(P) = {P
\
inp
P
\\
inp
z(P
\
out
) P
\
IR
P
\\
IR
P
\
OR
}.
The initial marking of the N
\
c
component of the merged
net is as if N
\
c
were isolated. The initial marking of N
\\
c
component of the merged net is partly derived from the
output marking of net N
\
c
.
Lemma 1: The merging of two live and safe refined
WSPNs does not always result in a net, which is also
safe and live.
Proof: If a loop is introduced in the merged net, this net
may not be safe and live. In the simple example in figure
3, place C is not safe.
The types of nets that can be merged are therefore
restricted so that the merged net is safe and live.
Figure 3: Unsafe Merging
Merging Structure Constraint: Any circuit introduced
into a net as a result of merging, must be a live and sage
circuit, given and initial marking M
ini
for the merged net.
To determine if a circuit is live and safe, it is necessary to
extract the subnet associated with all transitions and
places in the circuit. The subnet N
sub
= (P
sub
, T
sub
, F
sub
,
W
sub
, M
sub
) associated with the circuit can be determined.
Theorem 3: An WSPN N
c
representing individual web
services formed by merging two live and safe WSPNs
N
\
c
and N
\\
c
such that the merging structure constraint is
satisfied in the merged net, will be a safe and live WSPN
given that the initial marking of the merged net is M
ini
.
Proof Outline: Each net N
\
c
and N
\\
c
is live by definition.
Moreover, given the initial marking of the merged net
and by the appropriate introduction of transition t
reset
, it
can be deduced that the merged net is live. The N
\\
c
component of the merged net N
c
can be made unsafe only
if the N
\
c
component provides net N
\
c
more that one token
at the merged places. Show that this is not possible and
therefore the merged net is safe.
Theorem 3 is now extended to cover a complete web
service transaction that includes all the individual web
services. A complete transaction is a sequence with
commences in the initial state of the transaction and
terminates in the final state of the transaction with the
Initiator of the transaction getting the requested web
services. By a recursive application of Theorem 3 we get
Lemma 2.
Lemma 2: A merged complete web services transaction
is a live and safe net.
Proof Outline: Follows from Theorem 3.
This leads to the following conclusion.
Theorem 4: given an WSPN N
c
composed of merged
nets that represent a complete transaction such that
Theorem 3 is satisfied, then given an initial marking M
init
where M
init
(p) = 1 for all p e P
IC
where P
IC
= P
inp
P
IR
,
there exists a final marking M
final
such that M
final
(p) = 1
for all p e P
oc
where P
oc
= P
out
P
IR
. The merged net
obeys the properties of complete initialization and clean
termination with respect to assembly parts and the
production system.
Proof Outline: First we prove the property of clean
termination. From Lemma 2, transition t
reset
is live in the
merged net N
c
. Therefore, we deduce that M(p) = 1 for all
p e P
out
. Next we show that in the final marking there
does not exist a place p
y
such that p
y
is some place
excluding places { P
inp
P
out
P
IR
}. From this result
that p
y
cannot also be one of places P
inp
. We can therefore
conclude that there exists M e R(N
c
, M
init
) such that M(p)
= 1 for all p e {P
out
P
IR
} and M(p) = 0 for all p e { P
out
P
IR
}. However, a situation may arise whereby
transition t
reset
could fire before the net has reached
marking M(P
IR
). In other words, there could exist a
marking M(p
x
) where p
x
= { P
out
P
x
} and P
x
= P
ir
. We
next show that there exists a marking P
out
P
IR
that is
reachable from P
out
P
x
. A similar approach is used to
prove the property of complete initialization.
A
t
x
A t
y A
t
y
E
t
x
C
B
E
C
B
B
D Merged net
D
Petri Net Modeling of Methods
In our Car Dealer example, either cash is paid or the bank
is contacted for financing. This Car Dealer transaction is
modeled with the OR model to represent two choices as
shown in figure 4.
The Bank can send two kinds of replies i.e. approved
or declined. These replies are modeled with the OR
model. To model the complete set of transactions at the
car Dealer, the outgoing and incoming messages are
merged. After merging we get the model shown in figure
5:
Proceedings of the IEEE International Conference on E-Commerce (CEC03)
0-7695-1969-5/03 $17.00 2003 IEEE
Figure. 4: Model of Car Dealer and Bank Method
The results from the remote web site are returned to
the Car Dealer method and finally to the user. The Car
Dealer invokes the web services of two Banks to get
finance for its customers and on the basis of the cheapest
interest rate returned it selects one of them. Of these two
banks, one calls one Credit Cos Web Services and the
other bank calls three Credit Cos Web Services to check
the credit history of the customers. After getting a credit
score from the credit companies, the bank decides
whether to approve the loan and the interest rate to be
charged. The results from the banks are returned to the
Car Dealer. Each Web Service is accessed through its
particular WSDL file. The modeling software reads all
the Web Services methods and their WSDL files, and
derives the Petri net model of the entire business
transaction.
Figure.5: Merged net of both Car Dealer and Bank
methods
Similarly the methods in Bank and in Credit Co. can also
be modeled. However, these only represent the individual
web services. To get a view of the entire transactions
requires a model of the web transactions at all three sites.
This is achieved by merging the Petri Net models of the
individual web services based on Theorems 3 and 4. A
major problem with formal modeling is scalability. As
the number of sites increases, the modeling does not scale
well. The usual approach to this problem is to
hierarchical modeling of systems. In our case as shown
above, we refine transitions for scalability. Safely
modifying workflow logic in real-time requires validation
of system changes before actual system deployment [5].
Petri net modeling of the WSDL gives a descriptive
information of the web service. Moreover, the WSPN
models both WSDL and the methods in a web service.
The detailed picture of the entire system can therefore be
analyzed.
4.0 Example
The proposed Petri net modeling captures Web sites,
which use Web Services, (e.g. the Car Dealer website)
such that the system is deadlock-free and safe. The Web
Services provide services to the Car Dealer and WSDL is
the description of the Web Services. One web sites
method may use many Web Services. The called Web
Service, if needed can also invoke another Web Service
to get required information. Methods are written to
implement the companys business process computation.
They include conditional statements, and calls for other
Web Services methods.
Message is sent
from Car Dealer to
bank Web service
to apply for loan
sold
if financing
needed
approve
The complete Petri net represents all the possible
execution paths of the whole system, in which a web
sites method is followed by the WSDL and then the Web
Services method. In a correct web transaction, the path
will come back to the calling method in the same
sequence. A high level global view of all participating
Web sites, Web services and WSDL files is sketched in
figure 6. As each web site is aware only of its local
computation, the Petri Net model of the web service at an
individual site is first constructed as in figure 7. The
generated Petri Nets of individual web services are
merged to create the Petri Net model of the entire web
transaction (figure 8). Our approach allows for the
hierarchical modeling of web services.
decline
sold
If cash paid
Car dealer method Bank method
if financing
needed
If cash paid
approve
sold
decline
Not sold
In the example, the individual higher level Petri net
diagram of Car Dealer, Banks and Credit Rating
Companies are shown figure 7. In the Car Dealer
transaction, place P
1
represents the user who is applying
for a loan. The transition represents the methods at the
Car Dealer website. This method calls two web services,
MyBank and abcBank whose ports are represented by
places P
2
and P
3
. The abcBank invokes three credit
companies while the MyBank Web Service
communicates with only one Credit Company. The Credit
companies do not invoke any further Web Services.
Proceedings of the IEEE International Conference on E-Commerce (CEC03)
0-7695-1969-5/03 $17.00 2003 IEEE
Figure. 6: Abstract diagram of example
Car_Dealer MyBank abcBank
Figure 7: Petri net modeling of Web Services
An abstract global view of the entire system is obtained
by merging the Petri Nets as shown in figure 8.
Figure. 8: Merged global view of the entire system
The detailed method of each site is now constructed. This
is modeled as a Petri Net refinement. In Theorem 3 we
showed that Petri Nets can be merged to form a
composite Petri Net that is safe and deadlock free. Based
on this theorem these nets are then merged to create the
model of the entire web transaction. The car Dealers
method represented by a transition t
1
in figure 7 is refined
to the Petri Net show below in figure 9. The Car Dealers
first if-else statement decides whether to invoke web
services on the basis of payment mode. This is shown by
transition t
1
below. Depending on the returned results,
(declined or approved) as shown by t
2
, the car Dealer
accepts the lowest interest rate offered as modeled by t
3
.
Similarly, the Petri net of the methods of Web Services
can be derived. Models of the other web services
involved can be similarly represented.
Figure.9: Car Dealer Web site method
Car_Dealer
abcBank MyBank
MyCredit
Rating
WSCredit
Rating
abcCredit
Rating
MyCre it d
Rating
WSDL WSDL
WSDL
WSDL WSDL
WSDL
t
1
P
1
P
2
P
3
P
4
P
5
t
2
P
6
t
3
P
7
P
8
P
9
WSCreditR MyCreditR
P
10
P
11
P
12
P
13
P
14
P
15
t
4
t
5
t
6
abcCreditR
t
7
P
2
merge P
4
P
1
Car_Dealer
MyBank
P
2
P5 merge P10
t
1
P
3
merge P
6
P
3
t
2
t
3
abcBank
P
10
P
8
P
4
P
6
P9 merge
P14
P8 merge P12 P7 merge
P10
t
4
t
6
t
5
MyCreditR
WCreditR abcCreditR
MyCreditR
P
5
P
7
P
9
P
11
cash
Interest rate
(lowest)
P
1
t
1
if
P
2 P
3
finance
t
2
if P
5
decline
approve
P
4
t
3
P
6
Proceedings of the IEEE International Conference on E-Commerce (CEC03)
0-7695-1969-5/03 $17.00 2003 IEEE
The Petri Net representations of the individual web
services are merged to create the entire web service. This
is not shown here due to the complexity of the ensuing
Petri Net. The proposed Petri Net model ensures that the
web services flow is deadlock-free and safe. Reachability
analysis of the Petri Net confirms that that the Car Dealer
web services transaction is deadlock free and safe.
5.0 Conclusion
In this paper we present a model for representing Web
services. Petri Net formalism has been used to model web
services and a tool has been developed to generate a Petri
Net representation of distributed web services and their
WSDL. The hierarchical modeling approach presented is
designed to deal with the complexity caused by the large
number of distributed web services. The developed tool
generates for the user the sequence of all execution steps
performed to complete a business process. A modeling
tool such as the one proposed here will enable a web
services designer to construct reliable web services.
The tool can be enhanced to provide a graphical
representation of the Petri Net representation of Web
services. Due to the complexity of the web, a more
compact representation such as colored Petri Nets is
desirable. Other issues such as modeling security has not
been touched in this work and is an area for future
research. Typically service providers publish only their
WSDL descriptions and this description does not express
if that service is dependent on another service or not.
Hence to use the modeling presented in this paper, we
need a mechanism to discover the dependency of one
service with the other one. This therefore requires the
design and development of new web services protocols.
The modeling of UDDI access and selection of Web
Services, can also be added to this work. Future research
will concentrate on modeling the timing constraints of
web services using timed Petri Nets. We are also
investigating using Petri nets to model Web service flow
represented in languages like WSFL or BPEL4WS.
Acknowledgments
We would like to acknowledge Asif Javed for his
development of the web services Petri Net based tool.
References
[1] Aoyama, M.; Weerawarana, S.; Maruyama, H.; Szyperski,
C.; Sullivan, K.; Lea, D. Web services engineering: promises
and challenges, Proceedings 24th International Conference on
Software Engineering ICSE , 2002
[2] Armstrong C, Modeling Web Services with UML OMG
Web Services Workshop, 2002
[3] Kreger, H., 2001, "Web Services Conceptual Architecture
(WSCA 1.0)", IBM Software Group, www-
4.ibm.com/software/solutions/webservices/resources.htm
[4] IBM Web Services Architecture Tam. Web services
architecture overview. The next stage of evolution for e-
business, IBM Technical Document, Web Architecture Library,
2000
[5] Leymann F, Roller D and Schmidt M-T, Web services and
business process management, IBM Systems Journal, Vol. 41,
No. 2, 2002
[6] Murata T, Petri Nets: Properties, Analysis and
Applications, Proceedings of the IEEE, Vol. 77, No. 4, April
1989. pp. 541-580
[7] Narayanan S and McIlraith S A, Simulation, Verification
and Automated Composition of Web Services, Proceedings
ACM WWW 2002, pp. 77-88 23
[8] Ogbuji U, Using RDF for description and modeling in Web
services, World Wide Web Consortium Workshop on Web
services, 2001
[9] Faul B.M, Using Petri net web services to build dynamic
and adaptive service oriented workflows, International
Conference on Software Engineering Research and Practice,
2002.
[10] Petri, C A Kommunikation mit Automaten. Bonn:
Institute fur Instumentelle Mathematik, Schriften des IIM Nr. 3,
1962.
[11] Rettberg, A.; Thronicke, W., Embedded system design
based on web services, Proceedings of Design, Automation
and Test in Europe Conference and Exhibition, 2002.
[12] Szyperski, C., Component Software, Addison Wesley,
1988.
[13] Thatte S, XLANGWeb Services for Business Process
Design, Microsoft Corporation (2001); see
http://www.gotdotnet.com/team/xml_wsspecs/xlang-c
[14] http://www.bpmi.org
[15] http://www.microsoft.com/net/
[16] www.ibm.com/websphere
[17] www.iplanet.com
[18] java.sun.com/webservices/webservicespack.html
[19] http://otn.oracle.com/tech/webservices/content.html
[20] http://www.hpmiddleware.com/SaISAPI.dll/SaServletEngi
ne.class/products/hp_web_services/default.jsp
[21] Technical Report: SOAP Version 1.2 Working Draft.
http://www.w3.org/TR/soap12
[22] Technical Report: Web Services Description Language
(WSDL) 1.1. http://www.w3.org/TR/wsdl
[23] Universal Description, Discovery and Integration.
http://www.uddi.org
Proceedings of the IEEE International Conference on E-Commerce (CEC03)
0-7695-1969-5/03 $17.00 2003 IEEE