A Simulation Based Approach

Computers & Industrial Engineering 49 (2005) 287–317
www.elsevier.com/locate/dsw
A simulation-based approach for dynamic process

management at web service platforms*
T. Madhusudana,*, Young-Jun Sonb
a
Management Information Systems Department, University of Arizona, 430V McClelland Hall, Tucson, AZ 85721, USA
b
Systems and Industrial Engineering Department, University of Arizona, Tucson, AZ 85721, USA
Received 5 January 2004; accepted 7 February 2005
Available online 1 August 2005
Abstract
Web services technology is being adopted as a viable deployment approach for future distributed software systems
that enable business-to-business and business-to-consumer interactions across the open and dynamic internet
environment. Recent research is focused on developing support technologies for web service discovery, on-demand
service composition, and robust execution to facilitate web services based deployment of business processes.
Developing techniques to cope with the volatile and open nature of the web during execution of composite services at
the service platform is essential for delivering reliable and acceptable performance in this new process delivery
framework. In this paper, we propose a simulation-based framework to guide scheduling of composite service
execution. Online simulation of the dynamics of the open environment is used for scheduling service requests at the
service platform. Comparison of the look-ahead simulation for different scheduling policies with the current execution
state provides guidelines for service execution in order to cope with system volatility. We have implemented a
prototype of the proposed framework and illustrate the feasibility of our approach with experimental studies.
q 2005 Elsevier Ltd. All rights reserved.
Keywords: Online simulation; Web services; Business process management
1. Introduction
A web service is a programmable application, which is accessible as a component via standard web
protocols (Vinoski & Lea, 2003). Deployment of web services for enabling execution of a variety of
*
This manuscript was processed by Area Editor Shimon Y. Nof
* Corresponding author.
E-mail addresses: madhu@email.arizona.edu (T. Madhusudan), son@sie.arizona.edu (Y.-J. Son).
0360-8352/$ - see front matter q 2005 Elsevier Ltd. All rights reserved.
doi:10.1016/j.cie.2005.02.003
288 T. Madhusudan, Y.-J. Son / Computers & Industrial Engineering 49 (2005) 287–317
intra- and inter-organizational processes has attracted significant research interest (Leymann, Roller, &
Schmidt, 2002). Web services technology provides a flexible and robust deployment approach to provide
various information processing services to facilitate B2B and B2C interactions (Bussler, Maedche, &
Fensel, 2002). Recent research has focused on (a) enabling dynamic discovery of web services to fulfill
service requests, (b) facilitating the composition of elementary services into complex processes, and (c)
developing service platforms for coordination and execution of such services. Several standards for
different tasks in enabling web services technology such as, (a) languages for process description
(Curbera, Goland, & Klein, 2002), (b) protocols for transactions (Cabrera, Copeland, Cox et al., 2002),
and (c) languages for coordination have been proposed (Cabrera, Copeland, Freund et al., 2002; Fensel
& Bussler, 2002). Developing adaptive techniques for service composition and service execution at the
service platform is essential for reliable service fulfillment to cope with the dynamics of an open
distributed execution environment.
Our current research (Madhusudan, 2004; Madhusudan & Uttamsingh, 2004) is focused on
understanding the inter-relationships between the service composition phase and composite service
execution at a service platform under different domain and execution conditions. Web service
interactions may be long-running depending on the nature of the service request. It is the responsibility
of the service platform fulfilling a service request to manage interruptions due to network dynamics or
component web service volatility. A service plan for fulfillment of a given service request may consist of
sequential or concurrent method calls to multiple concurrently running web services. Failures at any
constituent web service may have ramifications which have to be handled gracefully by the service
platform. Additionally, a web service platform fulfills multiple service requests concurrently. It is
imperative for such service platforms to provide acceptable performance for each new request in terms
of reliability and response times, apart from other functional characteristics such as service quality,
service coverage and effectiveness. A service platform needs to manage and control its resources to
fulfill its service requests in an effective manner. Similarly, each participant web service that advertises a
variety of services, needs to allocate computing and other resources effectively to fulfill incoming
service requests during both peak and normal hours of operation. Resource provisioning is a major task
in managing service performance (Maamar, Sheng, & Benatallah, 2003). Strategies for effective process
management need to interleave the task of service composition and execution (Benatallah, Sheng, &
Dumas, 2003; Papazoglou & Georgakopoulos, 2003).
Our recent research on developing an integrated web services framework has focused on the design
and implementation of the Integrated Service Planning and Execution (ISP&E) (Madhusudan &
Uttamsingh, 2004) approach for coping with the dynamic nature of web services. In the ISP&E
approach, service planning and execution is interleaved as illustrated in Fig. 1. The ISP&E approach
utilizes recent advances in AI planning, namely, Hierarchical Task Network (HTN) planning (Nau, Cao,
Lotem, & Munoz-Avilla, 1999) to enable service plan generation based on user requests. A service plan
is equivalent to a dynamically generated composite service. Alternatively, such a service plan may be
statically defined apriori. The planning process generates multiple service alternatives for a service
request. An optimal plan (considering multiple criteria) is chosen from the generated service plan
alternatives and is executed. As illustrated in Fig. 1, dynamic world conditions are considered during
planning (for fulfilling an individual service request) and the same conditions also possibly affect each
individual service plan execution. If plan executions are interrupted, it is possible either to re-execute the
original plan or re-plan in order to incorporate new world information. In the ISP&E approach to re-
planning, complete service plans are generated from the current state to meet all the final goals,
T. Madhusudan, Y.-J. Son / Computers & Industrial Engineering 49 (2005) 287–317 289
User issues request
PLAN GENERATION
Parse request MODULE
Replan
Generate feasible service plans
Select optimal plan
Rexecute World conditions

Execute plan
Check for execution failure

PLAN EXECUTION
MODULE
Return Answer or Timeout
Fig. 1. Integrated service planning and execution cycle.
incorporating world information obtained during execution. Further, concurrent service plans for
multiple requests are generated and then executed in parallel, without any considerations of resource
allocation either at the web service platform or at the component service providers. In this framework,
the cost of re-planning may be high depending on the world dynamics, the information assimilated (on
reacting to these dynamics such as failure of an individual web service) and the consequent changes in
the planning search space. Re-planning (and re-execution) times may be considerably improved if
guidance is provided by an embedded, concurrently running, simulation framework in which various
world alternatives are explored over a predefined short planning horizon. Guidance may include
information for the service planning phase such as preferable component services and also for the
execution phase, such as dispatch schedules for individual service plans. Re-execution may then involve
choosing a course of action, wherein the current real-world state matches one of the many branches that
have been explored by the simulation framework. Each such branch indicates a possible world that may
evolve during execution of a given plan. Possible advantages of such a framework include (a) reduced
planning times, (b) possible choice of better service plans from those previously generated, (c) increased
robustness, (d) improvements in total response time and (e) improved throughput at the service platform.
This paper reports on our approach to use simulation-based look-ahead knowledge to guide the
service planning and execution tasks at a service platform. We extend the capabilities of the
aforementioned ISP&E framework, by interleaving real-time simulation. Development of an embedded
simulation-based controller using online simulation technology for enabling real-time jobshop
scheduling has been well-studied in the shopfloor operations control literature (Harmonosky & Robohn,
1991; Jones, Rabelo, & Yuchwera, 1995; Son et al., 2003). In this study, we adapt the basic ideas of
online simulation technology to a web services environment. We present the development of a
simulation-based scheduler at the web services platform to enable scheduling of service requests.
Contributions of the paper are: (a) to illustrate the use of simulation technologies in web services process
management for scheduling service execution, and (b) to demonstrate a test-bed for developing
operating policies for service scheduling, and interleaving service composition in a web services
environment. In the long term, online simulation technologies may be used in the context of the ISP&E
framework to: (a) reduce costs of replanning under dynamic conditions, (b) enable dynamic service
selection at the service platform for concurrent service requests, (c) coordinate resource provisioning at
web services, and (d) guide reactive execution control in a web services environment.
The rest of the paper is organized as follows: Section 2 provides a background to web services and
online simulation technologies, Section 3 describes the computational models underpinning the ISP&E
framework. Section 4 describes the simulation-based control mechanism for scheduling at the web
services platform. Section 5 describes our implementation and prototypical experiments. Implications of
the approach and related work is discussed in Section 6 and concluding remarks are given in Section 7.
2. Background and literature survey
The approach described in this paper builds on two streams of research, namely, developing enabling
technologies for process management at web services platforms and recent advances in real-time
simulation technology. In this section, we provide a background to the state-of-art in web services
technology and a brief survey of the literature on web services process management and uses of real-time
simulation.
2.1. Issues in web services process management
The heterogeneity, autonomy and dynamic characteristics of web services make the development of
an integrated framework for web services composition and execution a formidable task. The basic
architectural model of web services is illustrated in Fig. 2. In the framework, three key roles are
SERVICE REQUESTORS
(Customer)
SERVICE
Request BROKERS
Step 1
Compose
(Registry)
SERVICE PLATFORM Step 4 Step 2

Step 3 Monitor & Manage Access
Stores
SERVICE SERVICE EXECUTION Service
COMPOSITION & MONITORING Descriptions
Request Step 4.2 Step 0

SERVICE Step 4.1 Publish
PROVIDERS
WSDL
(Services)
S1 S2 S3
S31 S32
Fig. 2. Web services architecture.

identified (a) service requestors, namely, customers (b) service providers, namely, specific online
businesses (who provide services such as S1, S2, S3, S31, and S32, and (c) service brokers, who maintain
registries (catalogs) of services and their capabilities. Service providers publish the capabilities of their
services, and rules to access them via Web Services Description Language (WSDL) descriptions, to
these service registries following the Universal Description, Discovery and Integration (UDDI)
standards (Consortium, 2002, 2001). Interactions amongst these three roles are supported by the service
platform which provides facilities for service composition and service execution. Customers request
services from service platforms. The service platforms execute the task of locating appropriate services
and acquiring the necessary WSDL descriptions. Services are located based on possibly registry-specific
UDDI taxonomy and the actual description (WSDL) is obtained via a predefined network access point.
For example, services S1, S2, S31, and S32 publish to the UDDI registry. Services may be composed in
advance, registered by a service provider and used to service multiple requests. For example, service S3
composed of services S31 and S32 may be predefined manually by an intermediary provider. However,
under volatile conditions, such advanced composition may be unreliable during execution if component
service capabilities change, or predefined assumptions on the composite behavior are invalid. Reacting
to such volatility during fulfillment of a service request is essential for successful adoption of web
services technology.
The basic process of interactive web service composition as supported by current technologies in the
domain of travel planning is illustrated in Fig. 3. We assume that various web services such as car
rentals, flight and hotel reservation services have published in advance their web services (in WSDL) to a
UDDI based service registry from which these services can be located. Consider a common example
scenario, where a customer assembles a package consisting of a flight, hotel reservations and a car rental.
The typical steps (without the technical details) for invoking a single service are: (1) find the services
Register tModel
Register Business
Find tModel Registry Publish Details
Find Business
Find Service
Get Access Point
Get WSDL Location
CAR RENTAL
Find
COMPOSE
HOTEL
CUSTOMER
Get WSDL
Bind
FLIGHT
Access Each service
Transfer data
Handle exceptions
Fig. 3. Example of a composite service.

based on a category code in a business registry and identify their online locations, (2) retrieve WSDL
documents from the locations, and (3) invoke service method calls by referring to the WSDL documents.
The above steps are executed for each service (flight reservation, hotel reservation and car rental) in an
order of service requests defined by the customer. Alternatively, such a sequence may be predefined by
an intermediary provider and then may be accessed by a customer. Multiple customers may concurrently
access such a predefined service. However, dynamic changes to either customer requirements or service
capabilities and a variety of customer-specific constraints may render such a priori service compositions
ineffective. The service plan definition for such composite services are hard-coded as a sequence of
Simple Object Access Protocol (SOAP) calls, by the intermediary, possibly with limited flexibility for
service definition and execution. Service composition may be highly combinatorial if a number of
alternative services are available with similar functionality. During composite service execution, data
and constraints between the services, such as airport constraints and arrival/departure information need
to be input manually and checked by the customer. Even while invoking a single service, reasoning
among constraints and making choices can be complex. The task of flight reservations involves decision-
making regarding seat selection, choices amongst alternative flights, pricing and discounts. An
intermediary may provide a composite service with all the tasks pre-sequenced and support services (for
service specific information) pre-included.
The execution module of a service platform facilitates execution of a composite service. It invokes
each task request at an individual web service and manages the intermediary states and data flows
appropriately. This service coordination has to be managed for all concurrently running service requests.
In extant approaches to service execution, fulfillment of a single service request may fail based on the
volatility of the network or dynamics at the component web services. It is the responsibility of the users
to react to the situation. Further, the reasons of failure may be either at the platform, the network or the
component web services, and may not be transparent to the user. This situation is further exacerbated
when multiple service requests compete for resources both at the service platform and common
component web services accessed during service fulfillment. Without an explicit scheduling and
resource allocation strategy either at the service platform or at each individual elementary web service,
desirable response times and service quality cannot be maintained nor guaranteed.
Current approaches to service discovery, service composition and execution coordination at the
service platform have to additionally cope with the following limitations of UDDI and WSDL
technologies, namely, (a) elementary service descriptions at UDDI may provide limited static
information about service capabilities and their dynamic behavior, (b) the WSDL descriptions of a
service are opaque with respect to the dynamic behaviors possible at an elementary web service thus
limiting the types of look-ahead reasoning one can perform at the service platform, (c) for each
individual composite service (or a plan) in execution, explicit state management has to be performed at
the service platform since WSDL is a stateless protocol, (d) the SOAP-based WSDL protocol is slow and
may be exposed to different kinds of network dynamics (such as lost messages, network outages etc)
leading to faulty behavior and variable response times, (e) the framework is a loosely coupled
autonomous distributed systems environment, without a well-defined fault tolerance model and event-
based communication standards, requiring open-loop execution of composite services without feedback,
and (f) the framework has no distributed resource management model leading to ad-hoc service
scheduling and execution policies (based on implementation) leading to large performance variations.
Research efforts towards facilitating the service definition, composition, and execution have adopted
techniques from workflow management systems. eFlow is a service platform based on facilitating
service process composition and enactment (Casati & Shan, 2001). The composition approach in (Casati
& Shan, 2001) is based on adapting templates of predefined composite processes. In (Casati & Shan,
2002), an event-based approach for control and coordination amongst web services is outlined. A similar
approach is advocated in the development of Business Process Execution Language (BPEL) (Curbera
et al., 2002; Leymann et al., 2002). BPEL is an XML-based language and provides conventional control
flow and data flow programming constructs to manually program the interaction between components of
composite services. BPEL provides constructs to explicitly refer to web services methods and manage
the data-flow between services. The program defining a composite web service is interpreted by an
execution engine in a manner similar to workflow systems. Managing programs defining composite
services in BPEL exhibit the same problems as managing workflow models such as inflexible definitions
and lack of robustness to changes in the execution environment. Service execution in the BPEL
framework allows for programmer-defined compensating transactions thus enabling service recovery.
Composition in the SelfServ system is based on manually defining state transition diagrams, wherein
sub-states identify component services (Benatallah et al., 2003). Recent work has extended this
framework for service execution considerations described in (Maamar et al., 2003). Semantic
composition of web services based on ontologies is addressed in (Cardoso, 2002). Composition is
enabled by matching service capability descriptions to requirements based on similarity measures.
Composite services are evaluated for performance metrics, primarily for enabling service redesign,
using discrete event simulation described in (Chandrasekaran, Miller, Silver, Arpinar, & Sheth, 2003). A
variety of agent-based approaches to service execution and coordination have also been proposed
(Blake, 2002, 2001; Blake & Gini, 2002). The primary focus towards composition is from a software
perspective including component-based design of large scale systems (Amyot, Buhr, Gray, & Logrippo,
1999; Mennie & Pagurek, 2001; Wiederhold et al., 2000). Resource allocation and service provisioning
in mobile and distributed environments have also been recently addressed in (Chakraborty, Perich, Joshi,
Finin, & Yesha, 2002; Ginis & Chandy, 2003). In all the approaches, the service platform functions like
a workflow execution engine performing tasks of dispatching service calls, receiving responses,
mediating and transforming intermediary data; thus executing all the steps in a service plan. Strategies to
cope with failures may be domain or programmer dependent but are encoded in the service definition
before execution. Such approaches cannot address all possible exigencies that may be encountered
during execution. Further, for reliable and large-scale business process management, more robust
techniques are required as outlined in (Burner, 2003). Further discussion on the ISP&E approach with
real-time simulation is deferred to Section 6.
2.2. Business process management and simulation-based control
Simulation for business process management has attracted significant interest in the workflow
management systems community. Simulation for workflow management has been utilized for estimating
workflow model performance (Leymann & Roller, 2000). Simulation for temporal management and
coordination of workflows has been proposed in (Zhao & Stohr, 1999). Petri Net based simulation and
formal models have formed the basis of well-developed tools for workflow analysis (Aalst, 1998, 1999;
Aalst & Hee, 1996). Petri Net based techniques have been used for workflow redesign and workflow
control (Reijers, 2003). The role of discrete event simulation for workflow performance analysis and
change management has also been discussed in the context of the METEOR system (Miller, Sheth,
Kochut, Wang, & Murugan, 1995). Recent research on the role of simulation in the context of web
services management is outlined in (Chandrasekaran et al., 2003). Agent-based technologies for

business process modeling and execution have been studied in the ADEPT system (Jennings, Norman,
Faratin, O’Brien, & Odgers, 2000). In summary, simulation has been primarily used for off-line analysis
to enable systems design, redesign and change of operating policies. Considering that the cost of
developing simulation models has been reduced, performance of simulation tools has improved, and
reliable statistical analysis tools are available, simulation technology may be profitably used for real-
time embedded control of large-scale systems. In this case, performance metrics, which are calculated
based on data acquired in both transient and steady-state periods (via simulation), may be used for the
development of real-time control policies to manage a large-scale system effectively.
An approach, called short-term simulation is advocated in (Reijers, 2003; Reijers & Aalst, 1999)
for guiding business process management. Short-term simulation is a manual off-line approach to
enable what-if analysis for scheduling and resource allocation purposes. Short-term simulation is
concerned with effects of a decision on operational aspects in a short planning horizon into the
future. The evaluation of the simulation is also based on short-term metrics. Finally, the short-term
simulation starts in the current estimated system state, unlike long-term steady-state simulations. A
key aspect of these short-term simulations (as discussed in (Reijers, 2003)), is that they are run off-
line for obtaining (a) design-related insight into long-term steady state behavior of the system for
configurational changes of a particular system, or (b) operational insight about system behavior in the
near myopic future.
In contrast to the above approach, in this paper, we propose the use of real-time simulation to guide
the scheduling policies (for service plan execution) in the ISP&E framework (discussed earlier). A
simulation-based controller is used as an integral part of the decision-making process to guide process
execution. The use of real-time simulation for scheduling has been recently demonstrated in the context
of manufacturing shopfloor control. (Jones et al., 1995; Son, Rodriguez-Rivera, & Wysk, 1999; Son,
Wysk, & Jones, 2003) demonstrate that (a) by using the most current system information in simulations
to make predictions about the future, and (b) by selecting the most viable scheduling strategy based on
the simulation results, superior shop-floor performance may be obtained. Further, recent work has also
utilized simulations to control and guide activity execution on the shop floor. In summary, the utility of
simulation-embedded decision-controllers in effectively managing shop floors has been well
demonstrated.
Development of simulation-based controllers in the shop floor control domain is primarily based on
on-line look-ahead simulation technology (Wu & Wysk, 1988). Online look-ahead simulation
scheduling algorithms for job-shop management search for the best set of dispatching rules in the
search space of alternative sets of rules. Shown in Fig. 4 is the generic architecture of an on-line
simulation framework. Major operating modules in the framework are: (a) a task execution mechanism,
(b) a control module that generates actions, (c) a state manager that tracks the latest operating status on
the shop floor based on input from sensors and auxiliary systems, (d) the look-ahead manager that
executes the on-line look-ahead simulation, and (e) the analyzer that interprets the simulation results and
guides the controller. The performance benefit is realized on the basis of alternative scenarios which are
evaluated concurrently in fast mode (of the simulation) by the look-ahead manager. For each scenario
determined by the Q operating parameters of the system (e.g. arrival rate, service rate, failure rate), the
search space is njZ1 nj , where m is the number of decision points, and nj is the number of alternative
rules at each decision point j. Therefore, for multiple scenarios, the search space increases significantly.
Current
LOOKAHEAD State REAL WORLD
STATE
MANAGER MANAGER TASK
EXECUTION
Action MECHANISM
CONTROLLER
Lookahead Search Space

Multiple Simulations/Scenarios
Current Execute
State Action
Statistical
Analyzer
Control
Rule RealWorld
Rule Selection
Fig. 4. Online simulation framework for real-time control.
Selection of the best alternative is performed based on system performance and process management
goals. The basic execution cycle of on-line look-ahead simulation for scheduling is:
† Initiate world simulation for different sets of dispatching rules over a predefined planning horizon in the
look-ahead manager. Select the most promising path based on the performance metric and initiate real-
world execution. A plan composed of a control policy (most promising set of dispatch rules) and a
trajectory of predicted performance that corresponds to that control policy is provided to the executor.
† The executor uses the control policy to make real-time decisions in the real-world. The monitor
compares predicted performance with actual performance resulting from real-time decisions and calls
the look-ahead manager when the actual performance deviates substantially from the predicted
performance, and when significant, unforeseen events, such as equipment failures or reduced
throughput levels occur. Based on disturbances or at predefined periods, update currently selected
simulation with real-world status and re-initiate simulation for other alternatives.
Key parameters for managing on-line look-ahead simulations are: (a) frequency of synchronization,
(b) selection of rescheduling points, (c) simulation time windows for look-ahead, (d) choice of
performance measures and (e) number of candidate alternatives. In the context of job-shop scheduling
environment, the interactions between these parameters have been analyzed and readers are referred to
(Son et al., 1999) for further details. In the following section and Section 4, we present features of the
ISP&E framework extended to utilize such on-line look-ahead simulation technology for guiding the
service scheduling phase (during execution) at a web services platform.
3. Description of the integrated service planning and execution framework
In this section, we describe the key functional modules of an ISP&E based web service platform.
Additionally, we provide a brief overview of the computational models underpinning the ISP&E
framework for process management. These computational models form the basis of the service planning
and simulation-based service execution strategies proposed in this paper. Additionally, to situate the
utility of our simulation-based controller for guiding service execution, we discuss the analogy between
manufacturing shop-floor control and process management in the web services environment.
3.1. Overview of ISP&E framework
A prototypical implementation of the Integrated Service Planning and Execution architecture is

shown in Fig. 5. Key elements of the framework illustrated in the figure are: (a) the planning module that
facilitates service composition, (b) the composite service execution module, and (c) the controller that
manages the execution of a service plan for individual service request. The world monitor (which
embeds the state manager) maintains the current execution state for each service plan and associated
service statistics.
The performance of the above architecture is critically dependent on the strategies embedded in the
controller. The controller executes the ISP& E cycle (shown in Fig. 1) for each individual service request
received at the service platform. Problem solving requests are provided to the platform (step 1, labeled
arrow in Fig.), and an appropriate service plan is composed (via planning) and dispatched to the
execution module via the controller (step 2), which dispatches requests to the services (step 3) and
receives responses (step 4) which are routed to the state manager (step 5). Based on the response the state
manager maintains the current execution state of the service plan and also updates the statistics on the
corresponding service in the service catalog (step 6). If the service plan is successfully executed,
the response is returned to the client (step 8). On interruption, the controller may decide to reschedule or
re-plan from the current state and re-initiate the cycle (step 7) or re-execute the remainder of the plan
SERVLET BASED ARCHITECTURE
Service Platform
CLIENTS
JSP
HTN/SHOP World
Request Planning Module Monitor
1
LISPSERVLET Service
7 9 Catalog
CONTROLLER 6
2
Response:
Execution 5
8 STATE
Module MANAGER
JAVA SERVLET
4
3
Requests WebServices
(AXIS/APACHE/XML! RPC)
Responses
Data Service Service Data
Fig. 5. The ISP&E architecture.

(step 2). The controller manages different interleaving strategies such as total or partial re-planning or re-
execution and coordinates the interaction between other modules. Further, the controller is responsible
for scheduling the different tasks for fulfilling each service request.
From the viewpoint of the execution module (implemented as a JAVA servlet), it receives multiple
service plans to be executed. Each such service plan has been generated by the planning module and is
dispatched to the execution module (with appropriate input data elements) and associated process
constraints. Service plans (for different requests) may share the same elementary web services and
possibly utilize common data stores and access shared memory resources at the service platform. The
execution module is thus responsible for effective resource usage and reliable execution of the service
plans. Considering that the service execution module may not have knowledge of the resources at each
individual web service, its task dispatch policy for each service plan has to be well-designed. Poor
execution performance may result and service requests may be delayed if component services are
overloaded or service dispatch policies are in conflict. Additionally, such current service performance
knowledge may also guide service selection phase (during planning-based service composition) for
newly arriving requests. This paper is focused on the development of a simulation-based mechanism
(internal to the execution module) to guide such process execution. Details of the simulation-based
execution module are described in Section 4.
3.2. Formal models underpinning ISP&E framework
The conceptual ISP&E framework is based on well-defined computational models for: (a) elementary
web services and service requests, (b) representation of composite services as service plans, and (c) the
service platform and its capabilities. These models guide the implementation described above and
experiments discussed in Section 5.
3.2.1. Models of elementary web services

There are two computational models that define an elementary web service, namely, an external
model that defines the capabilities of the web service (as viewed from the service platform), and an
operational (execution-oriented) model defining the internal behavior of the web service once a task
request is received. In the ISP&E framework, the external model of each elementary web service defines
multiple operators (also referred to as operations, actions or methods) at each individual service. The
collection of these operators defines the capabilities of a web service. A capability of a web service is the
kind of operations that can be requested of the web service. For example, there are many kinds of
browsing capabilities at the Amazon (www.amazon.com) website, differing in their search inputs. Each
possible type of web service capability is modeled as a request—response pair, called a service operator,
sij for service i, (1%i%n) and capability j, (1%i%m), where n is the number of web services and m is the
maximum number of operators per service. Assume that each request to a service operator is made in
terms of a set of input data bindings bi and the operator returns the results in terms of output bindings bo.
Additionally, each service capability sij may have constraints on input and output bindings,
preconditions and post conditions, etc. Constraints may also define the necessary preconditions that
need to be satisfied in the world to execute a method and also define postconditions that may be satisfied
when the operator execution completes successfully. We denote these constraints as ðciij ; coij Þ. Two
types of web service operator definitions are maintained at the service platform (at the service
catalog in Fig. 5), namely, (a) a declarative definition described by the aforementioned formalism,
and (b) a corresponding procedural definition describing the WSDL method calls for that service. The
procedural description is defined by the tuple (Imp, [inargs], [outargs], (tr, sa)), where Imp is the WSDL
signature and [inargs], [outargs] denotes the input and output parameters for the call. In the tuple, (tr,
sa), tr denotes the mean total round-trip response time for each call and sa, the current service
availability. The total response time is estimated based on collecting statistics when each call was
invoked and the corresponding response was received. Further, the availability is estimated as the ratio
of the number of successful calls to total number of calls for each service. These statistics are maintained
at the world monitor in conjunction with the procedural definition at the execution module.
Consideration of other possible service metrics is in progress. To summarize, each service Si is
represented as a set of service operators and each such operator is denoted by the tuple,
ðsij ; ciij ; coij ; Imp; ½inargs; ½outargs; ðtr; saÞÞ. This service capability model is sufficient to model both
synchronous request-reply calls and asynchronous interactions between the platform and a webservice.
The following operational model defines the execution behavior of each individual web service when
it receives task requests from the service platform. The basic operational model of each web service is
defined by the following:
† TAZ(t1, t2, t3,.,tn) defines the set of tasks (methods) that can be executed by the web service.
† LSZ ðls1 ; ls2 ; ls3 ; .Þ defines the sequence of local states traversed by the web service. Each local
state lsi is defined by the singleton (lthi), wherein lthi denotes the history of task requests processed
thus far. Note that web services may not explicitly store state depending on the implementation.
Further, each web service may receive concurrent requests.
† Assuming the web service is currently in a state, lsi, execution of a task request causes a transition.
The ensuing state, lsj is defined by: lsi!ti2TA/lsj.
Web services are agnostic of the global state. When multiple service requests arrive, choice of which
task to fulfill is done based on implementational policies at each web service. Additional, tasks (which
belong to multiple service plans at the platform) may arrive at a web service in any order. Thus,
processing at each individual web service is based on local knowledge at the web service.
3.2.2. Modeling service requests, the service platform and a composite process
Customers (or other programmable agents) access the service platforms and issue service requests.
Service requests to the platform are classified into two types, (a) Information seeking requests, and (b)
Transactional requests, including information update and decision-making tasks. For example, a service
platform supporting procurement provides for different types of transactional and informational requests
regarding the status of long-running computations. In the ISP&E framework, we support both types of
requests.
Transactional and Informational service requests can be specified in terms of the following: (a) the set
of tasks to be completed and the initial inputs, or (b) the initial inputs and final outputs. Further, these
requests can include constraints on the request inputs, request outputs, intermediary process states,
component service inputs and outputs. Service requests, denoted SRi, to a platform are modeled in terms
of the following tuple, ((t1, t2,.), si, sf, ci, cint, co). ti denotes the tasks requested, si and sf denote the
description of the initial and final states, ci, cint, co denotes the input, intermediate and output constraints.
Given service requests, SRi, the role of the service platform is to identify services Si (from its current
service catalog) that can fulfill the request and then generate a service plan consisting of a sequence of
service operators. During service planning, additional steps may be performed at the service platform to
facilitate: (a) decision-making operations, (b) packaging of data for inputs to web services methods, (c)
extraction of data from outputs of web services, and (d) support intermediary storage and
transformations of data. These computational steps may be modeled explicitly as operators at the
service platform, denoted pi, 1%i%N, or as intermediary and auxiliary procedures executed by the
planner. Such operators may include relational data manipulation operators such as SELECT and
PROJECT along with application-specific operators. Further, the service platform may provide a variety
of additional functions to query the current state of execution and schedule service access. In the current
ISP&E framework, we model the decision-making and data management service platform functions as
operator precondition evaluations executed by the planner.
Alternatively, instead of service planning, a composite service may be programmatically defined
(using a language such as BPEL). Each such composite service is predefined for a certain type of request
and makes specific assumptions about what may be requested. We note that such a procedural definition
uses the WSDL method signatures to develop a composite service.
Service requests to the platform can be fulfilled possibly by a single operator invoked at a single
elementary service Si or by a combination of operator invocations at one or more elementary services. The
sequence of multiple operator invocations to fulfill a particular service request defines a composite service.
A composite service invokes methods at possibly multiple elementary services or other statically defined
composite services. A composite service can be created by a service platform either at compile-time and
reused to serve many requests (a static composite service) or created dynamically when a service request is
received by the platform. Dynamic composite services may exist for the duration of fulfilling the service
request. We define a composite service (both dynamic and static) as a service plan, which is a sequence of
transactional service operators invocations that fulfill the service request. The composite service, denoted
SCi, is made up of a sequence of sij operators. For example, a service request to execute two methods and an
intermediary activity at the platform is defined by the following service plan: s14(*)/p1(*)/s14(*). The
symbol / denotes the sequence of invocation of the operators. The * in the parenthesis denote input and
output bindings to the operators. The task of service planning is to develop such service plans from the
available catalog of web service operators. The service execution module of the service platform executes
each web service operator according to the plan till the service request is fulfilled. The declarative service
plan is mapped into its procedural definition based on the WSDL definitions of each service method.
The procedural definition of a composite service plan is adapted from the generic workflow
metamodel discussed in (Leymann & Roller, 2000). Each service plan (as shown in the previous graph)
is transformed into its procedural counterpart by using the Imp definition for each sij from the model of
each service. Such a transformed web services process model, is called a process graph, G, and is
ð where:
defined as follows: GZ ðV; N; i; o; J; C; U; 3; E; F; D; DÞ,
† V is a finite set of data elements with each element having a finite domain. These data elements refer
to all the different pieces of data related to a process. In the context of web services, these data
elements refer to the domain related data used by the webservices. For example, customer and order
data may be used by a purchasing service.
† N is a finite set of tasks in the workflow. A task, t, is a specific step in the business process involving
some kind of computation, data retrieval, decision-making or problem-solving methodology. Tasks
are of two types, (a) elementary, and (b) composite. Composite tasks are defined recursively by
a subgraph:
† SGZ ðV; N; i; o; J; C; U; 3; E; F; D; DÞ. ð This enables definition of a task hierarchy at multiple levels
of abstractions. Tasks are defined for acquiring information from the manual users and from other
enterprise systems. Each task ti is defined by the set ðI; OÞ defining the inputs and outputs of each
task. I; OZ ðf1 ; f2 ; f3 ; .; fn Þ, fi 2F.
† i : N g Cg G/ §ðVÞ, wherein § denotes a power set. i denotes the input container map, defining
I, for each task in the process model.
† o: NgG/§(V). o denotes the output container map, defining O, for each task in the business process.
† J : N / E is a task implementation map for a task, with the input container of the task mapped to inputs
of the task implementation and the outputs of the implementation mapped to the output container of
task. The implementation map defines a mapping between the declarative task definition and its
procedural definition. A single task such as Estimate_Price in an online shopping scenario may be
implemented in multiple ways. Task implementations may be selected during execution based on
requirements of computational performance, accuracy and available resources.
† U : N / Q is the task assignment map which defines for each web service, the kinds of tasks the web
service is capable of executing. A single task can be provided by multiple web services. For example, a
single commodity product may be sold by many different online stores. The task assignment map
facilitates dispatching a task request to a web service during execution.
† 3 : N / C assigns to each activity an exit condition. This defines when a task is considered complete.
This enables defining post condition checking on tasks when responses are received for task requests.
† E 4N !N !C is a set of control connectors. For a control connector (A, B, p)2E, the predicate p 2C
is called a transition condition. The control connectors define the preconditions that should be satisfied
in the global state (defined below) that ensure that a task can executed. For example, before payment
can be received via credit card, availability of funds have to ensured. Control connectors may define a
variety of AND/OR conditions to define various types of conditional and iterative behavior.
† F : N /gA2N 4A assigns join conditions for a task which has multiple predecessors tasks that execute
in parallel. In the business process context, multiple components in an assembly may be ordered
concurrently and then their completion may signal the beginning of procuring assembly related
components. The completion of all predecessors tasks before a given task can execute is called a join.
Join conditions can be of many types in a plan such as (1) total—All predecessor tasks need to be
completed before successor task is activated (2) iterative—the successor task is activated every time
predecessor ends and (3) M-out of-N—successor is activated when any M out of N predecessor tasks
complete. These define different kinds of task synchronization as predecessor tasks may have varying
time durations during execution by service agents.
† D is a data connector map outlining data flow dependencies between the output container and the input
container of any two dependent tasks in the process graph. This defines a data dependency map for the
business process.
† Dð defines the process data connector map between a task defined by a process subgraph (could be
another process model). The input container of the task is the input container of the subprocess and the
output container of the task is the output container of the subprocess. For example, instantiation of a
subsystem ordering task in a BOM may be defined by a subgraph consisting of tasks for each
component of the subsystem. The process data map defines inputs and outputs of the subgraph.
The process graph thus defines a service plan to fulfill a given service request. Successful execution of
the service plan (the above process model) ensures that a service request is fulfilled. The aforementioned
process model may be predefined manually and hard-wired as a composite service provided by a service
platform. Alternatively, such process models may be created dynamically on the fly for each service
request. The ISP&E framework discussed in Section 1 (Madhusudan & Uttamsingh, 2004) supports the
dynamic generation of such service plans. A complete discussion of such workflow generation is beyond
the scope of this paper. However, an example is discussed in Section 5. We note that such a process
graph is conceptually equivalent to the notion of a process plan in manufacturing.
The task execution module of the service platform receives multiple service requests and their
associated service plans (process models). Given a process model for an individual service request, the
behavior of the service platform is formally described as follows:
† GSZ ðgs1 ; gs2 ; gs3 ; .Þ defines the sequence of global states traversed by the service platform for a
service request. Each global state gsi is defined by the pair (fsi, thi), wherein fsi denotes the data state
defined by the bundle of data entities and their respective values. thi denotes the task history defined
by the subset of completed tasks in N.
† Execution of a task (completion of a component service request) causes a transition in the global
state. Tasks are defined by a mapping, TM : GS/ T 2N for each state GS. The ensuing state is
defined by: GS !T / GS. The behavior of the service platform as defined may be deterministic (or
non-deterministic) in nature. Execution of a task results in a singleton ensuing state in well-defined
process models.
The behavior of the service platform can be summarized as follows for each service request: It starts
in some initial state gs0. It selects tasks, T to execute based on the mapping TM, evaluated on the current
global state. These tasks are dispatched to the respective web services based on the mapping U. Results
are received, the next global state, gsi is computed and the cycle is repeated. The service platform
maintains the global state updates in a persistent repository. The execution terminates when the process
graph is completely traversed and no more tasks are available to execute. This behavior is executed for
each service request. The complexity of the concurrent process models for multiple requests determines
the performance of and resource requirements at the service platform.
In the ISP&E framework, the overall coordination between the central service platform and individual
web services is structured as a master-slave framework. Depending on the coordination protocols, web
services are usually designed to cooperate with the central service platform involved and a web service
may not refuse to process a service request. However, in an open environment, web services have
autonomy in how they choose to fulfill the task request depending on their individual resource
availability and priority schemes between multiple task requests.
3.3. Analogy between shop-floor control and process management at the service platform
Based on the aforementioned computational models of the ISP&E framework, Table 1 lists analogical
structural and behavioral elements that may be recognized between the discrete manufacturing
environment and web services process environment. Key differences to note are: (a) parts are physical,
whereas a service request is logical, (b) however, each service request may be associated with a custom
service plan (generated in our framework via planning). The cost of creating a custom service plan may
be overwhelming due to the number of alternatives that may be possible (large number of processing
units). Selection of the best plan considering preferences is a computationally intensive activity.
Table 1
Analogical elements between shopfloor and web services environment
Feature Manufacturing Web services
Entity flowing through Parts (physical) A Service request (logical)
Task description A Process plan (fixed for a part) A Service plan (customized per request)
Processing units CNC Machines Elementary Web Services
Number of units Finite (order of 100 s) Order of thousands or more
Availability of units High Volatile
Controllability of units High Autonomous
Resources Consumed Raw materials Time and storage
Routing Physical network
Execution Controller Master Shop floor controller Controller (inside execution module)
Usage driven by Production demand User requests
Response time expectations Order of days, hours, minutes Order of milliseconds to minutes
Executing a plan may be a complex activity as processing units (web services may fail or access may be
unavailable). These processing units are usually autonomous and uncontrollable unlike a manufacturing
environment. Further, even the routing network may fail and affect behavior. Additionally, the complete
service planning and execution cycle may have to be performed under response time expectations of
order of minutes under dynamic conditions. This puts major stress on the planning and execution
strategies at the web service platform under constantly changing environments. In contrast, the master
controller in the job shop environment has stable process plans, and has to cope with lesser uncertainty in
a more stable environment (with more moderate demand variations). Thus the task of parts scheduling is
more manageable. In summary, the master shop controller has more robust knowledge of the job shop
environment unlike an execution controller at a web services platform. The web services execution
controller may not know the behavior of its individual component services, nor the profile of its service
requests and thus cannot cope with dynamics appropriately.
In such an environment, the utilization of any look-ahead knowledge (that may be gleaned from
current environmental knowledge) may be highly beneficial. Alternatively, past performance knowledge
may also guide execution strategies. Scheduling service plan execution using a concurrently running
simulation may help the execution module react much better to environmental dynamics than aggregate
heuristic strategies. For fulfilling large numbers of service requests concurrently, any performance gain
may be beneficial. Though in the ISP&E framework, one may replan (due to execution failure), re-
planning must be avoided (due to the high search costs) for the wrong reasons such as overloaded
services, failed networks or delays, or tight response time requirements. Using real-time simulation to
guide execution decisions may help in developing execution strategies for deciding when to replan and
when to schedule intelligently for re-execution.
4. Model of the simulation-based controller for service execution
We describe the architecture of the simulation-based controller inside the service execution module.
Additionally, we discuss the different types of scheduling policies that we investigate in the context of
improving service execution.
4.1. Controller framework
Fig. 6 illustrates the functional layout of a simulation-based controller and task dispatch mechanism
of the service execution module inside a web services platform. The figure also illustrates the
relationship of the execution module with other modules of the generic ISP& E architecture in Fig. 5.
The integrated simulation-based control and execution module consists of five components. Given
service plans from the planning module and current state information from the web services world, the
decision-planner (look-ahead manager), which we have implemented as an on-line simulation, will
develop a control policy and a trajectory of predicted performance that corresponds to that control
policy. Second, the statistical analyzer analyzes simulation results. Third, the decision-maker (1) uses
the control policy to make real-time decisions, (2) compares predicted performance with actual
performance resulting from these decisions, and (3) calls the decision-planner when the actual
performance deviates substantially from the predicted performance and when significant, unforeseen
events, such as service provider failures, network failures, and new request arrivals, occur. Fourth, the
decision-maker traverses the process graph (of the service plan) and sends the appropriate messages to
the executor dispatch mechanism. The dispatch mechanism is responsible for invoking service calls at
Status to World
Service Requests Monitor
Service
Replanning Requests
Controller
Plan
messages
Execution Module
Service
Composition Service
Monitor/
Module responses
Service Plans Status
Status Manager
Planner Web
Services
Requests
Decision Planner World
Decision
Maker
Messages
Simulation Executor
Dispatch Individual
Mechanism Method
calls
Best Control
Statistical rules, scheduling
Analyzer choices
Embedded realtime
Simulation module
Fig. 6. Simulation-based controller for service execution.

each individual elementary web service. The dispatched calls may be synchronous (blocking) or
asynchronous calls. Service responses (including failure events and time-out messages) are received at
the status manager and processed appropriately. Status information is provided to the world monitor to
update the system state to guide service planning. The same status information is also routed to the
decision-planner module which manages the look-ahead simulation to modify the current simulation
state (if necessary).
In our current implementation, each of the modules are implemented as concurrently running
threaded objects inside the service execution module. Communication amongst the modules is event-
based. The decision-planner module, the simulation engine and the statistical analyzer form the
simulation-based mechanism to guide the decision-maker module. The inputs to the decision-planner for
look-ahead simulation include (1) time window (planning horizon), (2) description of available web
services (current resource availability), (3) characteristics of the network, (4) currently executing service
requests, and (5) current state. The decision rules considered in our prototypical implementation include
(1) FCFS allocation, (2) SPT allocation, or (3) priority based on customers. The outputs of the simulation
include (1) mean value or trajectory of performance measures, (2) traces of executions, (3) alternatives,
and (4) key events. In this paper, the best control policy (set of control rules) and a trajectory of predicted
performance that corresponds to that control policy is considered.
4.2. Properties of simulation and search heuristics
Two conflicting objectives in the look-ahead simulation are the simulation execution time and the
number of alternatives to be evaluated. A search space in the look-ahead simulation for a fixed planning
horizon is a function of (1) parameters (x1,x2,.,xq) used in the look-ahead simulation (e.g., arrival rates,
service rates, parameters for disturbances), (2) number of decision points (p), and (3) number of
alternative rules for each decision point (np). A fixed set of parameters in the look-ahead simulation
correspond to an expectedQfuture scenario
Q of the system. The complete search space considered in the
look-ahead simulation is qiZ1 xi ! pjZ1 nj . xi values are either discrete or continuous, and continuous
ones need to be discretized. Methods to efficiently discretize continuous variables considering both the
search space and the predictability of the future have been developed recently (Kanetkar & Son, 2003).
However, a discussion of the same is beyond the scope of this paper.Q
Even for a single scenario, the search space if enumerated is pjZ1 nj . In this research, to reduce the
search space in the look-ahead simulation, the OptQuest algorithm (Glover, Kelly, & Laguna, 1999) has
been adopted since it is implemented within the Arena commercial simulation package. The OptQuest
algorithm incorporates a combination of three meta-heuristics: scatter search (SS), tabu search (TS), and
neural networks (NN). First, SS (a population-based approach) is used to create new points by linear
combinations of a set of points generated by heuristics or previous solution experience, accompanied by
rounding processes to assign integer values to discrete variables. The resulting new solutions, referred to
as child vectors, are evaluated by means of objective function values. A subset of new solutions is then
added to a subset of the previous trial solutions (parents) to produce new sets of solutions. Second, TS is
used to control the composition of reference points at each stage. TS exploits adaptive memories to
prevent the search from re-investigating the solutions that have already been evaluated. These memory
components allow the search to escape from local optimal solutions and guide the solution process to a
global optimal solution. Third, NN is used as a prediction model that helps the system to accelerate the
search by avoiding simulation runs whose results can be predicted as inferior. The NN is trained on
the data collected during the search. In the experiments in this paper (see Section 5), we demonstrate the
proposed system for two scenarios.
5. Implementation and experiments
Key modules of the ISP&E architecture of Fig. 5 have been prototyped based on the computational
models described in Sections 3 and 4. Details of the planning-based service composition are described in
(Madhusudan & Uttamsingh, 2004; Madhusudan et al., 2003). Service composition is enabled using the
Hierarchical Task Network (HTN) planning technique (Nau et al., 1999). The planning module is based
on a LISP implementation of the Simple Hierarchical Ordered Planning (SHOP) algorithm and is
deployed as a LISP servlet. The execution module and the world monitor have been implemented as
JAVA servlets. The world monitor is initialized with a set of web services corresponding to the service
catalog maintained in the planning module. The world monitor collects statistics on all the web services
over time as these services are accessed. These statistics are stored in embedded databases. Experimental
results on service performance and the effectiveness of the generic ISP&E cycle have been reported in
(Madhusudan & Uttamsingh, 2004). As outlined in Section 4, we also have prototyped a simulation-
based event-driven execution module, for the ISP&E architecture. The simulation engine currently
prototyped in our framework is based on ARENA.
Our initial experiments with the ISP&E framework indicated that the total response times for
generating and executing a service plan is highly dependent on the environmental dynamics
(Madhusudan & Uttamsingh, 2004). Further, coping with the dynamics may be possible, if effective
service scheduling policies are developed. The simulation-based service execution module described in
this paper is motivated by the need to develop such scheduling policies. To evaluate the feasibility of
utilizing such simulation-based mechanisms for service scheduling, we have conducted some
preliminary experiments, which we report below. The primary aim of these experiments has been to
investigate the effect of different scheduling policies in dynamic environments discussed in Section 4.
For experimental purposes, (considering that no web service experimental testbeds are available), we
have instantiated an online shopping domain (consisting of shopping services, credit verification and
transactional accounting webservices). We illustrate our approach in the context of shopping for a set of
items (possibly with interrelationship constraints) given a budget. First, we illustrate the different types
of service plans that may be generated for a service request by the service composition module. Then we
present the role of the simulation-based mechanism in guiding the service execution module.
5.1. Generating service plans
Consider three web services S1, S2 and S4, each selling a set of different items i with each item i having
a set of features j. These online services provide the following capabilities: (a) getting information
regarding items and their features from product catalogs, (b) getting information regarding item
availability (in terms of inventory levels), (c) getting prices of an item i, (d) placing orders, and (e)
making payments. Additionally we also model a credit card verification web service, S3, that provides
the ability to check credit cards. Table 2 lists the service operators in terms of their input and output
bindings for service S1. Operators s11, s12, s13, and s14 are transactional operators for logging on and
logging off the web service, placing the order and making a payment. Operator s15 is an information
Table 2
Service operators for web service S1
Wrapper Id Input view Output view
s11 (CUSTOMER_ID PASSWORD) (LOGSTATUS)
s12 (CUSTOMER_ID) (LOGSTATUS)
s13 (ORDERLIST QUANTITY) (ORDERID)
s14 (ORDERID PAYMENT) (PAYMENT_STATUS)
s15 (ITEM_FEATURELIST QUANTITY) (AVAILABILITY_STATUS QUANTITY)
s16 (ITEM_FEATURELIST) (PRICE)
This manuscript was processed by Area Editor Shimon Y. Nof.
gathering operator to query the web service for item availability and s16 is an operator for obtaining item
prices. Similar operators are defined for services S2 and S4. Service S3 has an operator to check for card
status.
Shown in Fig. 7 is the set of items and features available at each service (Note service Si is denoted as
WSi in our encoding). For purposes of illustration, we assume that these are available as part of the
description of each web service maintained by the service platform. For each item, information on its
features, prices and current availability (shown by the label QUANT) is available. This information is
obtained during execution by operators s15 and s16 and the catalog at the service platform updated.
A shopping service request, SR, to the platform consists of a list of items, the feature values for each
item and a budget for the purchase. This is provided (an example of shopping for three items) as follows:
((SHOPLIST (
((ITEM DVD-PLAYER) ((BRAND SONY)(WEIGHT 100))
(QUANT 2))
((ITEM MUSICCD) ((ARTIST PRINCE) (TITLE “HULLO”))
(QUANT 12))
((ITEM VIDEODVD) ((LANGUAGE ENGLISH)(TITLE “BLUE SKY”))
(QUANT 12))))
(BUDGET 3000))
In our implementation, such service requests are obtained via a form-based web interface and the
corresponding list representation developed from the same. The declarative representations for a variety
of service requests for a given domain can be generated from an appropriately designed user interface.
The approach is similar to current techniques used to search databases from web-based interfaces,
wherein user interface elements correspond to logic constructs for a SQL query.
For a total search of the plan space in response to our example service request, two of the six
alternative plans, generated by SHOP, are shown in Fig. 8. One of these plans may be selected and sent to
the service execution module for further execution. Note that the service plans are internally represented
in terms of the process graph representation discussed in Section 3. The figure shows only the signatures
of the operators (input and output bindings are not shown). The two plans differ in the items, quantity
ordered and the total price to be paid. The plans differ in the access sequence of these webservices. In the
first plan on the left, web service S4 is accessed first (plan steps 1–5) followed by S2 (steps 6–10) and S1
(step 11–15). In the plan on the right, webservices are accessed in a different order.
Fig. 7. Catalog at each web service.

Fig. 8. Two alternative service plans.
The two alternatives in Fig. 8 differ in (a) which web services are accessed, (b) what order, and
(c) the quantities ordered at each web service. For example: 12 MusicCDs are ordered in the
shopping request. These MusicCDs are bought in batches of 4 and 8 in the first alternative. In the
second plan alternative, these are bought in batches of 10 and 2. The batch size bought is dictated by
the available inventory at each web service at the time the order is placed. We note that different
quantities of items may be ordered at different web sites based on remaining budget, availability,
features and current prices leading to different plans. The choice of available web services, the items
available at each service, the available quantities of each item and the prices of each item define a
combinatorial state space. Different shopping strategies can be used to guide search and select
feasible solutions in this space.
To summarize, multiple service plans may generated to fulfill each service request received at the
service platform. The web service platform has to judiciously select from these alternative plans to
effectively fulfill a request and manage its resources. We study the effectiveness of using online
simulation in guiding the choice (from alternative plans) in the following section.
5.2. Executing service plans
Each service plan (generated in response to a service request) is executed by the service execution
module. In a production environment, multiple number of concurrent service plans may be executed by
the service execution. These service plans may access possibly common web services. Further,
depending on the nature of the tasks, behavior of the individual web services in terms of processing times
may be highly variable as indicated in (Braumandl, Kemper, & Kossmann, 2003; Gal & Eckstein, 2001).
For purposes of our evaluation, we assume that all customer service requests received at the
experimental service platform, are fulfilled by service plans similar to the plans discussed above. Given
this service loading profile, we evaluate the effectiveness of simulation-based scheduling policies in
guiding the service execution module, under a variety of experimental conditions. The experiments
discussed below focus only on evaluating the nature of the scheduling policies generated by a real-time
simulation module, (if it were running concurrently with the task dispatch mechanism). In the
experiments below, we run the simulation module offline, with the same inputs to simulate the real-
world context discussed above.
We note that performance modeling of computer systems (hardware) is a well-studied area (Jain,
2001). However, in the context of software systems, such as query processing in database systems,
transaction processing at transaction processing monitors and process execution in workflow
management systems, and service processing in the Internet, development of appropriate performance
modeling techniques is an active area of research. Our choice of stochastic distributions for request
arrival times, processing times etc. are guided by extant simulation studies in the above literature. Recent
research (Harchol-Balter, 2002) shows that many of the analytical models (based on queuing network
models) do not reflect actual dynamic behavior that is usually observed. Work in this area is nascent. We
note that the evaluation described herein is primarily oriented towards evaluating if real-time simulation
provides better task dispatch guidance in dynamic environments. Our current work is exploring the use
of distributions derived from histograms of real-world service request scenarios. Additionally, we note
that the simulation-based service scheduling approach was motivated by stress tests on the initial ISP& E
implementation with simplistic service scheduling mechanisms.
5.2.1. Experimental setup for evaluation of effects of real-time simulation

The system and settings considered in evaluating the effects of real-time simulation on service
scheduling are summarized below:
† Four web service providers (j2(1, 2, 3, 4)) are used as the underlying information environment.
Three of them (jZ1, 2, and 4) are shopping services, and the fourth (jZ3) is the credit card service
provider.
† For each service request i, the total responsePtime (Ti) is the summation of the platform operation
time ðTpi Þ and the individual service times sij . The platform operation time includes the plan
generation time (using planning-based service composition method described above) and platform
internal processing time. In realistic settings, the plan generation time will depend on the size of
the request (search space), and the internal processing time will depend on the condition of the
platform (e.g. resource usage). The number of alternative plans obtained from the planning-based
composition approach will also vary across different service requests. In this experiment, it is
assumed that the platform operation time (in seconds) is randomly generated from a triangular
distribution of (1, 15, 25). It is also assumed that two alternate plans shown in Fig. 8 will be
generated and considered for execution. In the experiment, 300 units of the same service request
are considered. The inter-arrival time between the service requests is randomly generated from an
exponential distribution of 100 ms. It is noted that more types and units of service requests can be
tested similarly.
† For each plan, the total execution time is the summation of individual service times. Each service
(sij) in the plan corresponds to the transmission time (tij) in milliseconds and the processing time
(pij) in seconds. In the real setting, the service times will depend on the loads, disk usage, data
availability, and other conditions. tij is generated from a uniform (10, 250) distribution. pij (j2(1–
3)) is generated from a uniform (1, 25) distribution for service providers 1–3. pij (jZ4) is
generated from a uniform (11, 35) distribution.
† To simulate network and service provider dynamics, individual service providers could fail during
their execution due to randomly generated events from a Bernoulli distribution with parameter p.
In the first scenario, failure settings are pZ10 and 30% for j2(2–4) and jZ1, respectively. In the
second scenario, failure settings are pZ5 and 50% for j2(2–4) and jZ1, respectively. When a
failure occurs, the executor attempts to execute again after waiting 10 s. Comparing alternative
plans 1 and 2, we note that for the given simulated conditions, alternative plan 2 is faster;
however, it is also less reliable in contrast to plan 1.
† In realistic settings, each service provider may have its own internal policy (e.g. scheduling
policy), which may not be observable from the platform. In this experiment, it is assumed that the
individual service provider will execute the operations based on the sequence of requests that has
been received from the web services platform.
† It is also assumed that the service platform can handle 100 transactions per sec concurrently.
Therefore, when there are more than 100 concurrently served requests, those excessive requests
will be queued at the service platform.
† The objective function considered is the minimization of the mean response time. Other objective
functions can be used in the similar manner.
† The decision problem considered in the simulation is to choose a plan from the set of two
alternative plans. The three decision rules considered are: (1) ‘choose plan 1 only’, (2) ‘choose
plan 2 only’, and (3) random choice.
† The planning horizon is 10,800 s.
Using these simulated conditions, the following experiments were considered to develop policies that
the service execution module may use. Firstly, predefined static plan selection rules were evaluated for
both scenarios. One of the static rules considered is that to fulfill a service request, either plans 1 or 2 may
be selected with a fixed, equal probability, pchooseZ0.5. In real-time simulation techniques, dynamic
rules allow such predefined plan selection parameters to be updated based on current world state. In the
second set of experiments, we study the effect of varying pchoose for a given set of simulated dynamic
conditions. These experiments suggest that both static and dynamic rules are needed to cope with
dynamic conditions in the web services environment. A simulation-based web services execution
module may run these simulations (run offline for test purposes) and use the rules thus developed to
guide its dispatch activities.
5.2.2. Observations
5.2.2.1. Using static rules. If the real-time simulation module were to use static dispatch rules, Fig. 9
shows three 95% confidence intervals of the average response time (that may be expected in fulfilling a
service request under the experimental conditions) according to three rules: (1) ‘choose plan 1 only’, (2)
‘choose plan 2 only’, and (3) random (equal chance) choice under the first scenario. As shown in Fig. 9,
95% confidence interval of

Plan Selection
response time
Plan 1 only 82.3 ≤ µ1 ≥ 84.0
Plan 2 only 76.2 ≤ µ2 ≥ 78.1
Rand selection (plans 1 and 2) 79.6 ≤ µ3 ≥ 81.2
Fig. 9. Confidence intervals for average response time under the first scenario.
the average response time from the ‘choose plan 2 only’ rule is significantly shorter than those from the
‘choose plan 1 only’ rule and the random rule. Thus plan 2 must be preferred in scenario 1. Please note
that the table below the confidence limits chart also provides the same description. On the other hand,
Fig. 10 (second scenario) shows completely different results, where the differences are not statistically
significant. The simulation results in Figs. 9 and 10 agree with our intuitions. Under the first scenario, the
difference of failure rates between the service provider 1 (pZ30%) and the other providers (pZ10%) is
relatively small. Therefore, time saving due to smaller processing times from the second alternative plan
(see Fig. 8) is more significant than time loss due to the system failure. Under the second scenario, the
difference of failure rates is as significant as the time saving between the alternative plans. Thus the
higher failure rates (due to environmental conditions) tends to minimize the differences between either
plan. Therefore, these experiments suggest that the optimal plan selection rule (policy) highly depends
95% confidence interval of

Plan Selection
response time
Plan 1 only 78.6 ≤ µ1 ≥ 80.6
Plan 2 only 78.9 ≤ µ2 ≥ 81.2
Rand selection (plans 1 and 2) 79.0 ≤ µ3 ≥ 80.5
Fig. 10. Confidence intervals for average response time under the second scenario.
Fig. 11. Optimization plot for min. average response time for the first scenario.
on the system condition. Online simulation may be used to then select the appropriate rule for currently
existing conditions.
5.2.2.2. Using OptQuest search method. In the previous experiment, three static rules have been applied,
and their results have been compared for two scenarios of failure rates. The random plan selection rule in
those simulations was based on the Bernoulli distribution with pchooseZ50%. In this section, we intend
to obtain the optimal value for pchoose, which will correspond to the minimal average response time for a
given scenario (simulation conditions). The Arena models of the previous section have been
appropriately modified, and OptQuest built as part of Arena has been used with search heuristics
discussed in Section 3. Fig. 11 shows the objective function (Y axis, min. of average response time)
evolving over different settings (number of simulation runs in X axis) for varying pchoose values for the
first scenario. As shown in the table in Fig. 11, the column plan1_percent, indicates the percentage that
plan 1 was chosen and minimal value of the objective (average response time in column Minimize
plan_both) was obtained. The minimum average response time corresponds to when pchooseZ0.038%.
This suggests that plan 2 should be preferred in scenario 1 and corroborates with the result obtained in
the static rule experiments.
On the other hand, Fig. 12 shows the objective function evolving over different settings of simulation
for the second scenario, where the minimum average response time corresponds to when pchooseZ94.7%
for plan 1. Thus under highly dynamic conditions, the advantages of plan 2 are minimized and plan 1
may be chosen. Thus, these experiments suggest that the optimal plan selection policy is highly
dependent on the system condition, which can be predicted using the simulation. These experiments
exploring the effectiveness of simulation suggest that the choice of a plan selection policy is highly
dependent on dynamic conditions and simulation may be used to guide the policy. Simulation may also
be used to guide other decisions such as resource provisioning and prioritizing service requests. We are
currently studying the effects of the real-time simulation module by deploying the same under real-world
scenarios. Data collection on service execution performance is currently in progress.
Fig. 12. Optimization plot for min. average response time for the second scenario.
6. Discussion and related work
The implementation and experimental studies support the feasibility of using real-time simulation to
guide the service execution module in dispatching tasks and cope with the dynamics of an open
environment. The success of real-time simulation in coordinating dynamic manufacturing production
environments has inspired this study into use of look-ahead simulation techniques to guide service
scheduling in a web services environment. Considering that the web services environment consists of
loosely coupled independent processing units with autonomy and the central web service platform may
only have partial knowledge about the world state, a concurrently running simulation may be a
computationally effective option to learn about possible future world states. Explicit deliberative
reasoning such as using logic-based state-space reasoning techniques may not be completely effective.
The proposed approach is similar to the use of machine learning techniques to learn about source (and
service) characteristics (Nie, Nambiar, Vaddi, & Kambhampati, 2002). A simulation may also provide
the best option to reason about a large number of interacting entities in the real-world. We are currently
evaluating the different types knowledge that may be gleaned from the simulation analysis and analyzing
the kinds of simulation scenarios that could be explored. Further, our ongoing experiments are focused
on evaluating the computational costs of managing and updating the simulation dynamically during
runtime.
The limitations of the proposed approach, include the cost of setting up and managing a concurrent
simulation to obtain partial insight into future world state. Implementation of the simulation-based
execution module is a difficult step. Also, from an overall viewpoint, the simulation needs to be
bootstrapped with the appropriate distributions (for the different sources of randomness) to reflect the
nature of the overall environment. Characterizing the web environment is an active area of current
research. (Gruser, Raschid, Zadorozhny, & Zhan, 2000) attempts to characterize the response time
characteristics of web services. In (Braumandl et al., 2003), simulation studies for analyzing quality-of-
service metrics in the Internet environment are described. The effect of stochastic conditions on different
types of information processing tasks is discussed in (Chen, Goes, Gupta, & Marsden, 2003; Drenick &
Smith, 1993). Stochastic process models have been developed for the same in (Gal & Eckstein, 2001).
These have assumed exponential and Poisson process distributions. Studies on task scheduling suggest
that many of the normal assumptions may be invalid and empirical distributions are being developed
(Harchol-Balter, 2002). In future work, we plan to conduct further studies on the simulation-based
ISP&E framework and develop appropriate analytical models for the same along the lines suggested
above.
The use of simulation for web services process management as proposed in this paper is similar in
spirit to recent work in (Chandrasekaran et al., 2003). However, there are some fundamental differences.
Firstly, our use of simulation is to guide the service execution module in scheduling service plans. In
(Chandrasekaran et al., 2003), simulation is used to evaluate each service plan to guide selection of a
plan during the service composition phase. Secondly, the composition of service plans is done with
manual guidance and simulations are run offline. In contrast, we use planning techniques for dynamic
service composition and online (real-time) simulation to guide service scheduling. Overall, our
simulation approach is used to guide decision-making in dynamic systems and provide guidance to the
execution controller. In (Chandrasekaran et al., 2003), though each service plan may be evaluated
individually using simulation, real-time performance depends on the dispatch rules used by the service
scheduler. Evaluating each service plan individually does not ensure that the service scheduler is not
going to introduce additional delays or optimize across multiple concurrently running service plans.
Overall, the implementation and experiments suggest the viability of on-line look-ahead simulation
for managing dynamic webservices-based process networks in the near future. From a computational
perspective, the ability to reason and react quickly to dynamic changes using online simulation may be a
better and robust approach than the use of closed-form policies based on analytical models. However,
implementing an effective simulation-based dispatch mechanism is a difficult and costly task.
Additionally, considering that the web environment is dynamic and open, it may never be possible to
characterize effectively the dynamics of the services, requests or networks (to improve the fidelity of a
simulation). However, the simulation may provide effective insight into the aggregated effects of the
various dynamic events in the web services environment. Many avenues exist for future research
including, improving the interface between the simulation and the decision-maker modules in the service
execution component, exploring the role of simulation in guiding re-planning versus re-execution,
dynamically updating the simulation and underlying distributions (based on change points in the real-
world), and performing large-scale real-world studies (including stress testing the implementation).
7. Concluding remarks
In this paper, we have: (a) proposed the development of online look-ahead simulation-based
approach for scheduling web service execution, (b) described the implementation of a viable
architecture to support the same, and (c) presented experimental studies to highlight the utility of a
simulation-based approach to cope with the dynamics in a web services environment. The study
suggests that real-time simulation may be a potentially effective approach to provide the requisite
scalability and reliability in the management of dynamic business process networks of the future, by
enabling exploration of alternative world states in a concurrent manner, and thus guiding service
execution. Though feasible, the suggested approach needs to be further evaluated in a variety of
domains and execution environments.
In the near term, we plan to continue evaluation of our implementation of the simulation-based
service execution model in the context of evaluating the ISP&E architecture in different domains. Areas
of ongoing research include developing techniques to speed up the simulation-based reasoning cycle in
the execution module, developing interleaving rules for guiding service composition (based on
simulation feedback), developing new dispatching rules for service scheduling, comparing the
simulation-based approach with analytical techniques (based on sequential decision-making models),
and developing resource provisioning models for individual web services.
Acknowledgements
We are grateful to the referees, whose comments have considerably improved the presentation of the
ideas in this paper.
References
Aalst, W.M.P. van der (1998). The application of petri nets to workflow management. The Journal of Circuits, Systems and
Computers, 8(1), 21–66.
Aalst, W.M.P. van der (1999). A petri net based workflow analyzer. Systems Analysis—Modelling-Simulation, 35(3), 345–357.
Aalst, W.M.P. van der, & Hee, K. M. . . (1996). Business process redesign: A petri-net based approach. Computers in Industry,
29(1–2), 15–26.
Amyot, D., Buhr, R. J. A., Gray, T., & Logrippo, L. (1999). Use case maps for the capture and validation of distributed systems
requirements Proceedings of RE’99, fourth IEEE international symposium on requirements engineering pp. 44–53.
Benatallah, B., Sheng, Q. Z., & Dumas, M. (2003). The self-serv environment for web services composition. IEEE Computer,
7(1), 40–48.
Blake, M. B. (2001). Agent-oriented approaches to B2B interoperability. The Knowledge Engineering Review, 16(4), 383–388.
Blake, M. B. (2002). An agent-based cross-organizational workflow architecture in support of web services. WETICE pp. 176–
181.
Blake, M. B., & Gini, M. (2002). Guest editorial: Agent-based approaches to B2B electronic commerce. International Journal
of Electronic Commerce, 7(1), 5–6.
Braumandl, R., Kemper, A., & Kossmann, D. (2003). Quality of service in an information economy. ACM Transactions on
Internet Technology, 3(4), 291–333.
Burner, Mike (2003). The deliberate revolution. ACM QUEUE, 1(1), 28–37.
Bussler, C., Maedche, A., & Fensel, D. (2002). A conceptual architecture for semantic enabled web services. ACM SIGMOD,
31(4), 24–29.
Cabrera, F., Copeland, G., Cox, B., Freund, T., Klein, J., Storey, T. et al. (2002). Web services transaction, http://www-106.ibm.
com/developerworks/library/ws-transpec/.
Cabrera, F., Copeland, G., Freund, T., Klein, J., Langworthy, D., Orchard, D., et al. (2002). Web services coordination, http://
www-106.ibm.com/developerworks/library/ws-coor/.
Cardoso, J. (2002). Quality of service and semantic composition of workflows. PhD Thesis, University of Georgia.
Casati, F., & Shan, M. (2001). Dynamic and adaptive composition of E-services. Information Systems, 26(3), 143–163.
Fabio, Casati, & Shan, Ming-Chien (2002). Event-based interaction management for composite E-services in eFlow.
Information Systems Frontiers, 4(1), 19–31.
Chakraborty, D., Perich, F., Joshi, A., Finin, T., & Yesha., Y. (2002). Middleware for mobile information access. In
Proceedings of the fifth international work-shop on mobility in databases and distributed systems (MDDS’2002).
Chandrasekaran, S., Miller, J. A., Silver, G., Arpinar, I. B., & Sheth, A. (2003). Performance analysis and simulation of
composite web services. Electronic Markets, 13(2).
Chen, A. N. K., Goes, P. B., Gupta, A., & Marsden, J. R. (2003). Database design in the modern organization: Identifying robust
structures under changing query patterns and arrival rate conditions. Decision Support Systems, 37(3), 435–447.
Consortium, OASIS. (2002). Universal description, discovery and integration of web services, http://www.uddi.org.
Consortium, W3. (2001). WSDL standards, http://www.w3.org/TR/wsdl.
Curbera, F., Goland, Y., Klein, J., Leymann F., Roller D., Thatte S., Weerawarana S. (2002). Business process execution
language, www.ibm.com/software/solutions/webservices/pdf/BPEL.pdf.
Drenick, P. E., & Smith, E. J. (1993). Stochastic query optimization in distributed databases. ACM Transactions on Database
Systems, 18(2), 262–288.
Fensel, D., & Bussler, C. (2002). The web service modeling framework—WSMF, http://www.swws.org/.
Gal, A., & Eckstein, J. (2001). Managing periodically updated data in relational databases: A stochastic modeling approach.
Journal of the ACM, 48(6), 1141–1183.
Ginis, R., & Chandy, K. M. (2003). Service composition issues for distributed business processes. In L. Zhang (Ed.),
Proceedings of the international conference on web.
Glover, F., Kelly, J. P., & Laguna, M. (1999). The optQuest callable library user’s documentation. Boulder, CO: Tech. Rept.
Optimization Technologies Inc..
Gruser, J., Raschid, L., Zadorozhny, V., & Zhan, T. (2000). Learning response time for websources using query feedback and
application in query optimization. VLDB Journal, 9(1), 18–37.
Harchol-Balter, M. (2002). Task assignment with unknown duration. Journal of the ACM, 49(2), 260–288.
Harmonosky, C. M., & Robohn, S. F. (1991). Real-time scheduling in computer integrated manufacturing. International
Journal of Computer Integrated Manufacturing , 331–340.
Jain, R. (2001). The art of computer systems performance analysis. Newyork, USA: Wiley.
Jennings, N., Norman, T., Faratin, P., O’Brien, P., & Odgers, B. (2000). Autonomous agents for business process management.
International Journal of Applied Artificial Intelligence, 14(2), 145–189.
Jones, A., Rabelo, L., & Yuchwera, Y. (1995). A hybrid approach for real-time sequencing and scheduling. International
Journal of Computer Integrated Manufacturing, 8, 145–154.
Kanetkar, R., & Son, Y. (2003). Fuzzy logic based reinforcement learning approach for dynamic job shop scheduling. In
Proceedings of the international conference on industrial engineering.
Leymann, Frank, & Roller, Dieter (2000). Production workflow. Saddle River, NI, USA: Prentice-Hall.
Leymann, F., Roller, D., & Schmidt, M. (2002). Web services and business process management. IBM Systems Journal, 41(2),
198–211.
Maamar, Z., Sheng, Q.Z., & Benatallah, B. (2003). On composite web services provisioning in an environment of fixed and
mobile computing resources. Information and technology management. Available online at http://www.cse.unsw.edu.au/
qsheng/papers/ITM-03.pdf.
Madhusudan, T. (2004). An intelligent mediator-based framework for enterprise application integration. ASME Journal of
Computing and Information Science in Engineering, 4(4), 294–304.
Madhusudan, T., & Uttamsingh, N. (2004). A declarative approach to composing web services in dynamic environments.
Decision Support Systems. In Press, available online at www.sciencedirect.com since Sept 1 2004.
Madhusudan, T., Cha, H.S., Uttamsingh, N., Mudireddy S.R., Garg, A., Sun, W., Chirtsabesan B. (2003). An experience report
on developing an automated web services platform. In Proceedings of the second workshop on e-business.
Mennie D., & Pagurek B. (2001). A runtime composite service creation and deployment infrastructure and its applications in
internet security, e-commerce, and software provisioning. Proceedings of the 25th annual international computer software
and applications conference (COMPSAC 2001) (pp. 371–376).
Miller, J. A., Sheth, A. P., Kochut, K. J., Wang, X., & Murugan, A. (1995). Simulation modeling within workflow technology.
In Proceedings of the 1995 winter simulation conference.
Nau, D. S., Cao, Y., Lotem, A., & Munoz-Avilla, H. (1999). SHOP: Simple hierarchical ordered planner Proceedings of
IJCAI-99 (pp. 968–973).
Nie, Z., Nambiar, U., Vaddi, S., & Kambhampati, S. (2002). Mining coverage statistics for websource selection in a mediator.
In Proceedings of ACM CIKM.
Papazoglou, M. P., & Georgakopoulos, D. (2003). Service-oriented computing. Communications of the ACM, 46(10),
25–28.
Reijers, H. A. (2003). (LNCS, no. 2617) Design and control of workflow processes. Verlag, Newyork, USA: Springer.
Reijers, H. A., & Aalst, W.M.P. van der (1999). Short-term simulation: Bridging the gap between operational control and
strategic decision-making Proceedings of the IASTED conference on modeling and simulation (pp. 417–421).
Son, Y., Rodriguez-Rivera, H., & Wysk, R. A. (1999). A multipass simulation-based realtime scheduling and shop floor control
system. Transactions of the Society for Computer Simulation International, 16(4), 159–172.
Son, Y., Wysk, R. A., & Jones, A. T. (2003). Simulation-based shop floor control: Formal model, model generation and control
interface. IIE Transactions on Design and Manufacturing, 35(1), 29–48.
Vinoski, S., & Lea, D. (2003). Middleware for web services. IEEE Internet Computing, Jan–Feb.
Wiederhold, G., Beringer, D., Sample, N., Mellout, L. (2000). Composition of multi-site services. In Proceedings of
IDPT’2000.
Wu, S. D., & Wysk, R. A. (1988). Multipass expert control system: A control and scheduling structure for flexible
manufacturing cells. Journal of Manufacturing Systems, 7(2), 107–120.
Zhao, J. L., & Stohr, E. A. (1999). Temporal workflow management in a claim handling system. In Proceedings of the
international joint conference on work activities, coordination and collaboration.

A Simulation Based Approach

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A Simulation Based Approach

Enviado por

Direitos autorais:

Formatos disponíveis

Computers & Industrial Engineering 49 (2005) 287–317

A simulation-based approach for dynamic process

Keywords: Online simulation; Web services; Business process management

User issues request

Select optimal plan

Rexecute World conditions

Check for execution failure

Fig. 1. Integrated service planning and execution cycle.

2. Background and literature survey

2.1. Issues in web services process management

SERVICE PLATFORM Step 4 Step 2

Request Step 4.2 Step 0

Fig. 2. Web services architecture.

Fig. 3. Example of a composite service.

2.2. Business process management and simulation-based control

services management is outlined in (Chandrasekaran et al., 2003). Agent-based technologies for

Lookahead Search Space

Fig. 4. Online simulation framework for real-time control.

3. Description of the integrated service planning and execution framework

3.1. Overview of ISP&E framework

A prototypical implementation of the Integrated Service Planning and Execution architecture is

SERVLET BASED ARCHITECTURE

Data Service Service Data

Fig. 5. The ISP&E architecture.

3.2. Formal models underpinning ISP&E framework

3.2.1. Models of elementary web services

4. Model of the simulation-based controller for service execution

4.1. Controller framework

Fig. 6. Simulation-based controller for service execution.

4.2. Properties of simulation and search heuristics

5. Implementation and experiments

5.1. Generating service plans

Fig. 7. Catalog at each web service.

Fig. 8. Two alternative service plans.

5.2. Executing service plans

5.2.1. Experimental setup for evaluation of effects of real-time simulation

95% confidence interval of

95% confidence interval of

6. Discussion and related work

Você também pode gostar