Figure 1: Architecture of the dynamic workflow management system.
Business organizations across the Internet can perform and contribute different manual or
automated tasks, which are useful for the operation of a joint business. An E-Service Adapter needs to be
installed at each organization's site to wrap the underlying services, which can be implemented in
different ways, as e-services. Thus, these services can be made accessible on the Internet using SOAP
[BoxOO] and HTTP protocol. A Broker Server works as a central repository for e-services and is typically
used by the service requesters to find required e-services [HelOla]. The Workflow Server is composed of
two sub-components: namely, the Process Definition Tool and the Workflow Engine. The Process
Definition Tool is responsible for modeling business processes, which integrate the e-services across the
Internet. The Workflow Engine schedules the enactment of business processes according to the defined
The Event Server and the Event-Trigger-Rule (ETR) Server, which give the workflow
management system its active and adaptive properties [MenO1], are also shown in Figure 1.
3. E-Services and Process Modeling
3.1 E-Service Template
In order to introduce a standard way to define e-services, it is useful to categorize e-services and
their providers by the types of business in which these providers are involved. For example, some
business organizations may function as the Distributor of a supply chain. For each business type, a set of
useful e-services can be defined. Business organizations that are of the same business type may provide
all or some of these e-services. The categorization of service providers and the specification of e-services
are consistent with the Universal Description, Discovery and Integration (UDDI) specification [AriOO].
To standardize the specification of an e-service, an e-service template can be jointly defined by
those business organizations of the same business type. An e-service template consists of one or more
operations offered by the e-service. For each operation, there are three types of attributes:
Input attributes, which specify the data needed as input to invoke an operation.
Output attributes, which specify the returned data of an operation.
Service attributes, which specify other properties of an operation, such as the length of time the
operation takes, the side-effect of the operation, etc.
An e-service template can also contain service attributes for the e-service. These attributes
specify the properties of an e-service, such as the cost for using the e-service, the quality of the e-service,
etc., which may be useful for negotiation, contracting, or service selection.
A simple example of an e-service template of an e-service OrderProcessing provided by the
business type Distributor is shown in Table 1. It contains an operation Process Order.
Table 1. E-Service Template of e-service OrderProcessing of Distributor
Service Operations Description
Process Order Name Type
Operations Input Attributes productDesc ProdDesc
Output Attributes satus Status
Service Attributes duration Time
3.2 E-Service Constraint
A service provider registers its e-services with the Broker Server by first browsing and selecting
the proper e-service templates that are managed by the Broker Server. During the registration, the service
provider first provides the Broker Server with its general information, such as its name, URL, telephone,
email, etc. It then specifies the e-services it provides. For each e-service, the service provider needs to
specify the e-service binding description, which contains the location of the service implementation and
details on the protocol and the port to be used to access the server that hosts the e-service.
The service provider can also specify the constraints on the service attributes of the e-service, and
the constraints on the input attributes and service attributes of the operations. By allowing attribute and
inter-attribute constraints associated with e-service and its operations as well as e-service requests to be
explicitly specified, we can extend the Web Service Description Language (WSDL) to increase its
expressive power. These constraints restrict the selection of proper e-service providers for e-service
For constraint specifications, we adopt the syntax and semantics of the Constraint-Based
Requirement Specification Language used in [SuOl]. We shall call these constraints e-service
constraints. For example, a distributor named Worldwide who provides the e-service named
OrderProcessing may specify the following constraint on the operation Process Order as shown in Figure
2. This constraint specification states that the operation Process Order of e-service OrderProcessing can
only process the order of computer product with the quantity less than 1000. If the quantity of the order is
larger than 500, this e-service needs to take more than 10 time units. Iacl is the name of the inter-
productName String ENUMERATION ["Computer"] priority[l]
modelName String ANY priority
quantity Integer RANGE [1-1000] priority
INTER ATTRIBUTE CONSTRAINT:
lacl quantity > 500 implies duration>10
Figure 2: Constraint specification for operation Process Order.
For each e-service, the e-service template, the e-service binding description, and the e-service
constraints defined by the service provider together form the e-service specification. After registration,
the general information of the service provider and the e-service specifications of the e-services it
provides are stored in a persistent store and managed by the Broker Server.
3.3 E-Service Request and its Constraint
In our dynamic workflow management system, e-service requests are the main task items that can
be specified in an activity definition. They are defined according to their corresponding e-service
templates. The bindings of e-service requests to specific service providers occur at run-time when the
available providers are known to the workflow management system through the Broker Server. During
process modeling, the model designer first browses the e-service template information provided by the
Broker Server. He/she then defines the e-service requests in the activities of a process model according to
the corresponding e-service templates. In an e-service request, in addition to the values of the input
attributes of the requested operation, the constraints on the service attributes of the operation and the e-
service can also be specified. We shall call the constraints in an e-service request e-service request
constraints. An example of an e-service request constraint for the operation Process Order of the e-
service OrderProcessing is shown in Figure 4. It states that the requester expects that the Process Order
operation should not take more than 10 time units, the cost of the e-service should not be more than
$1,000, and if it takes more than 4 time units, then the cost must be less than $800.
duration int RANGE [0 .. 10] priority[l]
cost float RANGE [0.. 1000] priority
INTER ATTRIBUTE CONSTRAINT
iacl: duration >4 implies cost < 800
Figure 3: A sample specification of an e-service request constraint.
In summary, at build-time, the service providers register their e-services with the Broker Server
according to these e-services' corresponding templates. The e-service specifications are maintained at the
Broker Server site. The process model designers define e-service requests according to the same
corresponding e-service templates. The build-time relationship among the Broker Server, the service
providers, and the process definition tool is shown in Figure 4.
E-Service EService Server
/ register reference'
Service / Process Model
E-Service Adapter Services
Figure 4: Build-time relationship among the Service Provider, the Broker Server, and the Process
3.4 E-Service Invocation
The E-Service Adapter at each organization's site wraps services, which have been implemented
in different ways, so that these services can be invoked using SOAP messages that are sent through the
HTTP protocol, according to the format of the corresponding e-service templates. The E-Service Adapter
thus hides the heterogeneity of service implementations and presents a uniform view of these services as
e-services. During the e-service invocation, the E-Service Adapter parses the SOAP message from the e-
service requester (in our case, the Workflow Engine) and determines the operation of the e-service to be
invoked. The E-Service Adapter then determines the corresponding method of different service
implementations, builds the parameter list as required by the method, and invokes the method. After the
invocation is complete, the E-Service Adapter encapsulates the return data into a SOAP message and
returns it to the e-service requester. The SOAP message that is used to invoke the operation
ProcessOrder of the e-service OderProcessing is shown in Figure 5.
3.5 Process Modeling using E-Services
A process model consists of activities that are connected by conditional transitions, which specify
the control flows. Additionally, we add data flows among activities. We shall describe only the activity
definition below because activity is the main modeling construct in a process model and contains e-
service requests. The syntax of the activity specification is shown below.