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 replanning, 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
User issues request

289

Parse request Replan Generate feasible service plans

PLAN GENERATION MODULE

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

autonomy and dynamic characteristics of web services make the development of an integrated framework for web services composition and execution a formidable task. namely. (b) enable dynamic service selection at the service platform for concurrent service requests. 2. 2. Background and literature survey The approach described in this paper builds on two streams of research. and (d) guide reactive execution control in a web services environment.-J. In this section. In the long term. developing enabling technologies for process management at web services platforms and recent advances in real-time simulation technology. Y. Web services architecture. Son / Computers & Industrial Engineering 49 (2005) 287–317 environment. Implications of the approach and related work is discussed in Section 6 and concluding remarks are given in Section 7.290 T.2 Step 4.1. Section 5 describes our implementation and prototypical experiments. 2. three key roles are SERVICE REQUESTORS (Customer) Request Step 1 Compose SERVICE BROKERS (Registry) Step 4 Monitor & Manage SERVICE EXECUTION & MONITORING SERVICE PLATFORM Step 3 SERVICE COMPOSITION Step 2 Access Stores Service Descriptions Request SERVICE PROVIDERS (Services) S1 Step 4. In the framework. 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. Madhusudan. . The basic architectural model of web services is illustrated in Fig. Issues in web services process management The heterogeneity.1 S2 S3 Step 0 Publish WSDL S31 S32 Fig. 2. (c) coordinate resource provisioning at web services. online simulation technologies may be used in the context of the ISP&E framework to: (a) reduce costs of replanning under dynamic conditions. Section 3 describes the computational models underpinning the ISP&E framework. The rest of the paper is organized as follows: Section 2 provides a background to web services and online simulation technologies. Section 4 describes the simulation-based control mechanism for scheduling at the web services platform.

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

network outages etc) leading to faulty behavior and variable response times. Current approaches to service discovery. Y. 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. This service coordination has to be managed for all concurrently running service requests. (2) retrieve WSDL documents from the locations. requiring open-loop execution of composite services without feedback. Further. Alternatively. possibly with limited flexibility for service definition and execution. reasoning among constraints and making choices can be complex. explicit state management has to be performed at the service platform since WSDL is a stateless protocol. It invokes each task request at an individual web service and manages the intermediary states and data flows appropriately. Without an explicit scheduling and resource allocation strategy either at the service platform or at each individual elementary web service. (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. 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. hotel reservation and car rental) in an order of service requests defined by the customer. Service composition may be highly combinatorial if a number of alternative services are available with similar functionality. 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 execution module of a service platform facilitates execution of a composite service. The above steps are executed for each service (flight reservation. (a) elementary service descriptions at UDDI may provide limited static information about service capabilities and their dynamic behavior. Multiple customers may concurrently access such a predefined service. Son / Computers & Industrial Engineering 49 (2005) 287–317 based on a category code in a business registry and identify their online locations. pricing and discounts.292 T. the network or the component web services. It is the responsibility of the users to react to the situation. Research efforts towards facilitating the service definition. the reasons of failure may be either at the platform. choices amongst alternative flights. without a well-defined fault tolerance model and eventbased communication standards. such a sequence may be predefined by an intermediary provider and then may be accessed by a customer. namely. The task of flight reservations involves decisionmaking regarding seat selection. (e) the framework is a loosely coupled autonomous distributed systems environment. by the intermediary. service composition and execution coordination at the service platform have to additionally cope with the following limitations of UDDI and WSDL technologies. composition. eFlow is a service platform based on facilitating . Madhusudan. In extant approaches to service execution.-J. During composite service execution. Even while invoking a single service. and execution have adopted techniques from workflow management systems. However. The service plan definition for such composite services are hard-coded as a sequence of Simple Object Access Protocol (SOAP) calls. desirable response times and service quality cannot be maintained nor guaranteed. data and constraints between the services. such as airport constraints and arrival/departure information need to be input manually and checked by the customer. fulfillment of a single service request may fail based on the volatility of the network or dynamics at the component web services. and (3) invoke service method calls by referring to the WSDL documents. (d) the SOAP-based WSDL protocol is slow and may be exposed to different kinds of network dynamics (such as lost messages. An intermediary may provide a composite service with all the tasks pre-sequenced and support services (for service specific information) pre-included. (c) for each individual composite service (or a plan) in execution. and may not be transparent to the user.

2000). Petri Net based techniques have been used for workflow redesign and workflow control (Reijers. Finin. Recent research on the role of simulation in the context of web . primarily for enabling service redesign. 1999). BPEL provides constructs to explicitly refer to web services methods and manage the data-flow between services. Ginis & Chandy. The composition approach in (Casati & Shan. Wiederhold et al. Recent work has extended this framework for service execution considerations described in (Maamar et al. Strategies to cope with failures may be domain or programmer dependent but are encoded in the service definition before execution. 1996). 2002). Kochut. Mennie & Pagurek. 1999. Wang. & Murugan. A similar approach is advocated in the development of Business Process Execution Language (BPEL) (Curbera et al. & Yesha. an event-based approach for control and coordination amongst web services is outlined.. Such approaches cannot address all possible exigencies that may be encountered during execution. wherein sub-states identify component services (Benatallah et al. more robust techniques are required as outlined in (Burner. 2002. 2003). 2002.T. The program defining a composite web service is interpreted by an execution engine in a manner similar to workflow systems. 2003). 2003). 2. Service execution in the BPEL framework allows for programmer-defined compensating transactions thus enabling service recovery. Blake & Gini. 1998. Aalst & Hee. 2002). Silver.. Perich. Petri Net based simulation and formal models have formed the basis of well-developed tools for workflow analysis (Aalst. Miller. for reliable and large-scale business process management. 2002). 1999. Further discussion on the ISP&E approach with real-time simulation is deferred to Section 6. The primary focus towards composition is from a software perspective including component-based design of large scale systems (Amyot. Further.. Simulation for workflow management has been utilized for estimating workflow model performance (Leymann & Roller. Composite services are evaluated for performance metrics.. 2003). Sheth. 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. 2001). 2003). the service platform functions like a workflow execution engine performing tasks of dispatching service calls. 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. 2002). Business process management and simulation-based control Simulation for business process management has attracted significant interest in the workflow management systems community. 2000). Semantic composition of web services based on ontologies is addressed in (Cardoso. 1995). 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. Resource allocation and service provisioning in mobile and distributed environments have also been recently addressed in (Chakraborty. using discrete event simulation described in (Chandrasekaran. Leymann et al. Buhr. A variety of agent-based approaches to service execution and coordination have also been proposed (Blake. Madhusudan. In (Casati & Shan. Composition is enabled by matching service capability descriptions to requirements based on similarity measures.-J. & Logrippo. 2003). 2001. 2001.. Y. Composition in the SelfServ system is based on manually defining state transition diagrams. Son / Computers & Industrial Engineering 49 (2005) 287–317 293 service process composition and enactment (Casati & Shan. mediating and transforming intermediary data. In all the approaches. & Sheth. Arpinar. receiving responses. Simulation for temporal management and coordination of workflows has been proposed in (Zhao & Stohr. Gray. Joshi. 2001) is based on adapting templates of predefined composite processes.2. thus executing all the steps in a service plan.

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

unforeseen events. update currently selected simulation with real-world status and re-initiate simulation for other alternatives. Y.-J. such as equipment failures or reduced throughput levels occur. Based on disturbances or at predefined periods. 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. we describe the key functional modules of an ISP&E based web service platform. the interactions between these parameters have been analyzed and readers are referred to (Son et al. Selection of the best alternative is performed based on system performance and process management goals. In the context of job-shop scheduling environment. Madhusudan. we provide a brief overview of the computational models underpinning the ISP&E .T. 3. Additionally. Online simulation framework for real-time control. 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.. (b) selection of rescheduling points. † The executor uses the control policy to make real-time decisions in the real-world. (c) simulation time windows for look-ahead. (d) choice of performance measures and (e) number of candidate alternatives. In the following section and Section 4. 1999) for further details. 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. 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. Son / Computers & Industrial Engineering 49 (2005) 287–317 Current State 295 LOOKAHEAD MANAGER STATE MANAGER Action CONTROLLER REAL WORLD TASK EXECUTION MECHANISM Lookahead Search Space Multiple Simulations/Scenarios Current State Control Rule Execute Action RealWorld Statistical Analyzer Rule Selection Fig. Key parameters for managing on-line look-ahead simulations are: (a) frequency of synchronization. Description of the integrated service planning and execution framework In this section. 4. Select the most promising path based on the performance metric and initiate realworld execution. and when significant.

If the service plan is successfully executed.-J. we discuss the analogy between manufacturing shop-floor control and process management in the web services environment. 5. The performance of the above architecture is critically dependent on the strategies embedded in the controller. . Overview of ISP&E framework A prototypical implementation of the Integrated Service Planning and Execution architecture is shown in Fig. These computational models form the basis of the service planning and simulation-based service execution strategies proposed in this paper. labeled arrow in Fig. 1) for each individual service request received at the service platform. and an appropriate service plan is composed (via planning) and dispatched to the execution module via the controller (step 2). (b) the composite service execution module. Y. The ISP&E architecture. to situate the utility of our simulation-based controller for guiding service execution. 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 Request 1 HTN/SHOP Planning Module LISPSERVLET 7 CONTROLLER 2 Response: 8 Execution Module JAVA SERVLET 4 3 Requests (AXIS/APACHE/XML! RPC) Responses WebServices 5 World Monitor Service 9 Catalog 6 STATE MANAGER Data Service Service Data Fig. Madhusudan. The controller executes the ISP& E cycle (shown in Fig. and (c) the controller that manages the execution of a service plan for individual service request. the response is returned to the client (step 8). 3. which dispatches requests to the services (step 3) and receives responses (step 4) which are routed to the state manager (step 5).296 T. Key elements of the framework illustrated in the figure are: (a) the planning module that facilitates service composition. Additionally. Son / Computers & Industrial Engineering 49 (2005) 287–317 framework for process management. Problem solving requests are provided to the platform (step 1.). On interruption. The world monitor (which embeds the state manager) maintains the current execution state for each service plan and associated service statistics.1. 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). 5.

preconditions and post conditions. 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. called a service operator. The controller manages different interleaving strategies such as total or partial re-planning or reexecution and coordinates the interaction between other modules. The collection of these operators defines the capabilities of a web 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. 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. there are many kinds of browsing capabilities at the Amazon (www. 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. We denote these constraints as ðciij . actions or methods) at each individual service. Madhusudan. it receives multiple service plans to be executed. Y. 5). co Þ.1. (1%i%n) and capability j. 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. A capability of a web service is the kind of operations that can be requested of the web service. Details of the simulation-based execution module are described in Section 4. These models guide the implementation described above and experiments discussed in Section 5. Two ij types of web service operator definitions are maintained at the service platform (at the service catalog in Fig. Further. Additionally.com) website. Poor execution performance may result and service requests may be delayed if component services are overloaded or service dispatch policies are in conflict. 3.-J. This paper is focused on the development of a simulation-based mechanism (internal to the execution module) to guide such process execution. Considering that the service execution module may not have knowledge of the resources at each individual web service. sij for service i. namely. an external model that defines the capabilities of the web service (as viewed from the service platform). Son / Computers & Industrial Engineering 49 (2005) 287–317 297 (step 2). (1%i%m).2. (a) a declarative definition described by the aforementioned formalism.2. The execution module is thus responsible for effective resource usage and reliable execution of the service plans. namely. differing in their search inputs. For example. where n is the number of web services and m is the maximum number of operators per service. 3. . Models of elementary web services There are two computational models that define an elementary web service. Each possible type of web service capability is modeled as a request—response pair. In the ISP&E framework. each service capability sij may have constraints on input and output bindings. and (c) the service platform and its capabilities. the external model of each elementary web service defines multiple operators (also referred to as operations. etc. its task dispatch policy for each service plan has to be well-designed. and an operational (execution-oriented) model defining the internal behavior of the web service once a task request is received. such current service performance knowledge may also guide service selection phase (during planning-based service composition) for newly arriving requests.amazon. From the viewpoint of the execution module (implemented as a JAVA servlet). Additionally.T. the controller is responsible for scheduling the different tasks for fulfilling each service request.

Further. The ensuing state. Note that web services may not explicitly store state depending on the implementation. (a) Information seeking requests. [inargs]. 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 . † Assuming the web service is currently in a state. ci. t3. co denotes the input. sa)). execution of a task request causes a transition. Imp. [outargs] denotes the input and output parameters for the call. si.). Further. ci. ls3 . Further. component service inputs and outputs. where Imp is the WSDL signature and [inargs]. ðsij . The total response time is estimated based on collecting statistics when each call was invoked and the corresponding response was received. The procedural description is defined by the tuple (Imp.2. Thus..2. SRi. intermediary process states. saÞÞ. and (b) Transactional requests. t2. ðtr. Given service requests. lsi. The following operational model defines the execution behavior of each individual web service when it receives task requests from the service platform. ciij . 3. we support both types of requests. In the ISP&E framework. or (b) the initial inputs and final outputs. ½outargsŠ. lsj is defined by: lsi!ti2TA/lsj. [outargs]. including information update and decision-making tasks. co). ½inargsŠ. tr denotes the mean total round-trip response time for each call and sa. sa). wherein lthi denotes the history of task requests processed thus far. a service platform supporting procurement provides for different types of transactional and informational requests regarding the status of long-running computations. Y.tn) defines the set of tasks (methods) that can be executed by the web service. these requests can include constraints on the request inputs. to a platform are modeled in terms of the following tuple. Son / Computers & Industrial Engineering 49 (2005) 287–317 and (b) a corresponding procedural definition describing the WSDL method calls for that service. Additional. † LSZ ðls1 . To summarize. In the tuple. Consideration of other possible service metrics is in progress. These statistics are maintained at the world monitor in conjunction with the procedural definition at the execution module. Service requests. the current service availability. (tr. ls2 .298 T.Þ defines the sequence of local states traversed by the web service. the service platform and a composite process Customers (or other programmable agents) access the service platforms and issue service requests. each web service may receive concurrent requests. cint. (tr.. t2. Madhusudan. Service requests to the platform are classified into two types. intermediate and output constraints. This service capability model is sufficient to model both ij synchronous request-reply calls and asynchronous interactions between the platform and a webservice. denoted SRi. tasks (which belong to multiple service plans at the platform) may arrive at a web service in any order. si and sf denote the description of the initial and final states. the availability is estimated as the ratio of the number of successful calls to total number of calls for each service.-J. request outputs. co . When multiple service requests arrive. 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. each service Si is represented as a set of service operators and each such operator is denoted by the tuple. ti denotes the tasks requested. Modeling service requests. choice of which task to fulfill is done based on implementational policies at each web service. sf. For example. processing at each individual web service is based on local knowledge at the web service. ((t1. . cint.. Each local state lsi is defined by the singleton (lthi). The basic operational model of each web service is defined by the following: † TAZ(t1. Web services are agnostic of the global state.

J. where: † V is a finite set of data elements with each element having a finite domain. We note that such a procedural definition uses the WSDL method signatures to develop a composite service. The composite service. Such a transformed web services process model. F. and (d) support intermediary storage and transformations of data. and (b) composite. additional steps may be performed at the service platform to facilitate: (a) decision-making operations.-J. DÞ. or as intermediary and auxiliary procedures executed by the planner. customer and order data may be used by a purchasing service. C. During service planning. (a) elementary. 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. we model the decision-making and data management service platform functions as operator precondition evaluations executed by the planner. Such operators may include relational data manipulation operators such as SELECT and PROJECT along with application-specific operators. i. For example. In the current ISP&E framework. t. Y. is called a process graph. Madhusudan. a service request to execute two methods and an intermediary activity at the platform is defined by the following service plan: s14(*)/p1(*)/s14(*). These computational steps may be modeled explicitly as operators at the service platform. A task. We define a composite service (both dynamic and static) as a service plan. (c) extraction of data from outputs of web services. (b) packaging of data for inputs to web services methods. Each such composite service is predefined for a certain type of request and makes specific assumptions about what may be requested. The task of service planning is to develop such service plans from the available catalog of web service operators.T. G. 2000). 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 * in the parenthesis denote input and output bindings to the operators. which is a sequence of transactional service operators invocations that fulfill the service request. is made up of a sequence of sij operators. These data elements refer to all the different pieces of data related to a process. E. U. Further. D. A composite service invokes methods at possibly multiple elementary services or other statically defined composite services. these data elements refer to the domain related data used by the webservices. For example. 1%i%N. o. The sequence of multiple operator invocations to fulfill a particular service request defines a composite service. instead of service planning. 3. data retrieval. Alternatively. Composite tasks are defined recursively by a subgraph: . denoted SCi. Son / Computers & Industrial Engineering 49 (2005) 287–317 299 service operators. decision-making or problem-solving methodology. 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. † N is a finite set of tasks in the workflow. The procedural definition of a composite service plan is adapted from the generic workflow metamodel discussed in (Leymann & Roller. The symbol / denotes the sequence of invocation of the operators. Dynamic composite services may exist for the duration of fulfilling the service request. In the context of web services. Tasks are of two types. is a specific step in the business process involving some kind of computation. a composite service may be programmatically defined (using a language such as BPEL). N. denoted pi. and is ð defined as follows: GZ ðV. 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 service platform may provide a variety of additional functions to query the current state of execution and schedule service access.

for each task in the process model. OZ ðf1 . † E 4N !N !C is a set of control connectors. 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 predicate p 2C is called a transition condition. p)2E. In the business process context. † J : N / E is a task implementation map for a task. o. defining O.. † F : N /gA2N 4A assigns join conditions for a task which has multiple predecessors tasks that execute in parallel. 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. These define different kinds of task synchronization as predecessor tasks may have varying time durations during execution by service agents. defining I. C. OÞ defining the inputs and outputs of each task. N. wherein § denotes a power set. The completion of all predecessors tasks before a given task can execute is called a join. . B. 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. For example. 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. This enables definition of a task hierarchy at multiple levels of abstractions.300 T. For a control connector (A. The control connectors define the preconditions that should be satisfied in the global state (defined below) that ensure that a task can executed. This enables defining post condition checking on tasks when responses are received for task requests. ð † D defines the process data connector map between a task defined by a process subgraph (could be another process model). Y. fn Þ. i. Successful execution of the service plan (the above process model) ensures that a service request is fulfilled. fi 2F. I. Madhusudan. † i : N g Cg G/ §ðVÞ. The process data map defines inputs and outputs of the subgraph. The task assignment map facilitates dispatching a task request to a web service during execution. Task implementations may be selected during execution based on requirements of computational performance. DÞ. f2 . A single task such as Estimate_Price in an online shopping scenario may be implemented in multiple ways. Each task ti is defined by the set ðI. o denotes the output container map. A single task can be provided by multiple web services. multiple components in an assembly may be ordered concurrently and then their completion may signal the beginning of procuring assembly related components. a single commodity product may be sold by many different online stores. J. This defines when a task is considered complete. Son / Computers & Industrial Engineering 49 (2005) 287–317 ð † SGZ ðV. The aforementioned . 3. Control connectors may define a variety of AND/OR conditions to define various types of conditional and iterative behavior. † U : N / Q is the task assignment map which defines for each web service. E. availability of funds have to ensured. † 3 : N / C assigns to each activity an exit condition. † o: NgG/§(V). For example. D. † 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. for each task in the business process. Tasks are defined for acquiring information from the manual users and from other enterprise systems. before payment can be received via credit card. i denotes the input container map. the kinds of tasks the web service is capable of executing. U. The implementation map defines a mapping between the declarative task definition and its procedural definition. F. This defines a data dependency map for the business process. f3 . For example. The process graph thus defines a service plan to fulfill a given service request.-J. accuracy and available resources.

Each global state gsi is defined by the pair (fsi. These tasks are dispatched to the respective web services based on the mapping U. TM : GS/ T 2N for each state GS. . Alternatively. (b) however.T. in an open environment. Madhusudan.Þ defines the sequence of global states traversed by the service platform for a service request. Y. It selects tasks. However. The behavior of the service platform can be summarized as follows for each service request: It starts in some initial state gs0. such process models may be created dynamically on the fly for each service request.-J. The task execution module of the service platform receives multiple service requests and their associated service plans (process models). A complete discussion of such workflow generation is beyond the scope of this paper. gs3 . 3. The ISP&E framework discussed in Section 1 (Madhusudan & Uttamsingh. The complexity of the concurrent process models for multiple requests determines the performance of and resource requirements at the service platform. We note that such a process graph is conceptually equivalent to the notion of a process plan in manufacturing. 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. † Execution of a task (completion of a component service request) causes a transition in the global state. each service request may be associated with a custom service plan (generated in our framework via planning). an example is discussed in Section 5. 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). The service platform maintains the global state updates in a persistent repository. the overall coordination between the central service platform and individual web services is structured as a master-slave framework. evaluated on the current global state. The ensuing state is defined by: GS !T / GS. Table 1 lists analogical structural and behavioral elements that may be recognized between the discrete manufacturing environment and web services process environment. thi denotes the task history defined by the subset of completed tasks in N. This behavior is executed for each service request. The execution terminates when the process graph is completely traversed and no more tasks are available to execute. the next global state. Tasks are defined by a mapping. wherein fsi denotes the data state defined by the bundle of data entities and their respective values. whereas a service request is logical. However. gs2 . Selection of the best plan considering preferences is a computationally intensive activity. thi). Key differences to note are: (a) parts are physical. Son / Computers & Industrial Engineering 49 (2005) 287–317 301 process model may be predefined manually and hard-wired as a composite service provided by a service platform. 2004) supports the dynamic generation of such service plans.3. Depending on the coordination protocols. 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. . the behavior of the service platform is formally described as follows: † GSZ ðgs1 . 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. T to execute based on the mapping TM. Given a process model for an individual service request. Results are received. In the ISP&E framework. Analogy between shop-floor control and process management at the service platform Based on the aforementioned computational models of the ISP&E framework. gsi is computed and the cycle is repeated.

we discuss the different types of scheduling policies that we investigate in the context of improving service execution. 4. and has to cope with lesser uncertainty in a more stable environment (with more moderate demand variations). the utilization of any look-ahead knowledge (that may be gleaned from current environmental knowledge) may be highly beneficial. Son / Computers & Industrial Engineering 49 (2005) 287–317 Table 1 Analogical elements between shopfloor and web services environment Feature Entity flowing through Task description Processing units Number of units Availability of units Controllability of units Resources Consumed Routing Execution Controller Usage driven by Response time expectations Manufacturing Parts (physical) A Process plan (fixed for a part) CNC Machines Finite (order of 100 s) High High Raw materials Physical Master Shop floor controller Production demand Order of days. nor the profile of its service requests and thus cannot cope with dynamics appropriately. any performance gain may be beneficial. the master shop controller has more robust knowledge of the job shop environment unlike an execution controller at a web services platform. Further. 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. the complete service planning and execution cycle may have to be performed under response time expectations of order of minutes under dynamic conditions. Additionally. minutes Web services A Service request (logical) A Service plan (customized per request) Elementary Web Services Order of thousands or more Volatile Autonomous Time and storage network Controller (inside execution module) User requests 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). Y. This puts major stress on the planning and execution strategies at the web service platform under constantly changing environments. Alternatively. failed networks or delays. In summary. In contrast. Scheduling service plan execution using a concurrently running simulation may help the execution module react much better to environmental dynamics than aggregate heuristic strategies.-J. Thus the task of parts scheduling is more manageable. Model of the simulation-based controller for service execution We describe the architecture of the simulation-based controller inside the service execution module. The web services execution controller may not know the behavior of its individual component services. the master controller in the job shop environment has stable process plans. replanning must be avoided (due to the high search costs) for the wrong reasons such as overloaded services. even the routing network may fail and affect behavior. These processing units are usually autonomous and uncontrollable unlike a manufacturing environment. Additionally. past performance knowledge may also guide execution strategies. Madhusudan. For fulfilling large numbers of service requests concurrently. In such an environment. one may replan (due to execution failure). Though in the ISP&E framework.302 T. . hours. or tight response time requirements.

6. Simulation-based controller for service execution. will develop a control policy and a trajectory of predicted performance that corresponds to that control policy. unforeseen events. the decision-maker (1) uses the control policy to make real-time decisions. Y.1. Third. the statistical analyzer analyzes simulation results. such as service provider failures. The figure also illustrates the relationship of the execution module with other modules of the generic ISP& E architecture in Fig. . network failures. 6 illustrates the functional layout of a simulation-based controller and task dispatch mechanism of the service execution module inside a web services platform. Controller framework Fig. Fourth. and new request arrivals. (2) compares predicted performance with actual performance resulting from these decisions. Given service plans from the planning module and current state information from the web services world.T. The integrated simulation-based control and execution module consists of five components. Madhusudan. Son / Computers & Industrial Engineering 49 (2005) 287–317 303 4. The dispatch mechanism is responsible for invoking service calls at Service Requests Service Controller Status to World Monitor Replanning Requests Plan messages Execution Module Service Composition Module Planner Decision Planner Requests Decision Maker Messages Monitor/ Status Manager Service responses Web Services World Service Plans Status Simulation Executor Individual Dispatch Mechanism Method calls Statistical Analyzer Best Control rules. scheduling choices Embedded realtime Simulation module Fig. 5. the decision-planner (look-ahead manager). occur.-J. the decision-maker traverses the process graph (of the service plan) and sends the appropriate messages to the executor dispatch mechanism. and (3) calls the decision-planner when the actual performance deviates substantially from the predicted performance and when significant. which we have implemented as an on-line simulation. Second.

to reduce the jZ1 search space in the look-ahead simulation. Q Even for a single scenario. Third. TS exploits adaptive memories to prevent the search from re-investigating the solutions that have already been evaluated. referred to as child vectors. (3) alternatives. The resulting new solutions.2. These memory components allow the search to escape from local optimal solutions and guide the solution process to a global optimal solution. Madhusudan.. Son / Computers & Industrial Engineering 49 (2005) 287–317 each individual elementary web service. A search space in the look-ahead simulation for a fixed planning horizon is a function of (1) parameters (x1. the best control policy (set of control rules) and a trajectory of predicted performance that corresponds to that control policy is considered.g. & Laguna. are evaluated by means of objective function values. accompanied by rounding processes to assign integer values to discrete variables. The OptQuest algorithm incorporates a combination of three meta-heuristics: scatter search (SS). the OptQuest algorithm (Glover. The dispatched calls may be synchronous (blocking) or asynchronous calls. (2) number of decision points (p)..xq) used in the look-ahead simulation (e.. A fixed set of parameters in the look-ahead simulation correspond to an expected future scenario of the system. the search space if enumerated is p nj . The inputs to the decision-planner for look-ahead simulation include (1) time window (planning horizon). each of the modules are implemented as concurrently running threaded objects inside the service execution module. (4) currently executing service requests. tabu search (TS). and (5) current state. 4. A subset of new solutions is then added to a subset of the previous trial solutions (parents) to produce new sets of solutions. The decision rules considered in our prototypical implementation include (1) FCFS allocation. Second.x2. Y. Kelly. the simulation engine and the statistical analyzer form the simulation-based mechanism to guide the decision-maker module. and neural networks (NN). The outputs of the simulation include (1) mean value or trajectory of performance measures. However. Methods to efficiently discretize continuous variables considering both the search space and the predictability of the future have been developed recently (Kanetkar & Son. or (3) priority based on customers. 1999) has been adopted since it is implemented within the Arena commercial simulation package. xi values are either discrete or continuous. a discussion of the same is beyond the scope of this paper. and (3) number of alternative rules for each decision point (np).-J. (2) SPT allocation. 2003). The decision-planner module. In this paper. and continuous iZ1 jZ1 ones need to be discretized. First. Service responses (including failure events and time-out messages) are received at the status manager and processed appropriately. The NN is trained on . arrival rates. parameters for disturbances). In our current implementation. 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. In this research. 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. (2) description of available web services (current resource availability). The complete search space considered in the Q Q look-ahead simulation is q xi ! p nj . Status information is provided to the world monitor to update the system state to guide service planning. (3) characteristics of the network.304 T. 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). TS is used to control the composition of reference points at each stage. service rates. 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. Communication amongst the modules is eventbased. (2) traces of executions. and (4) key events.

For experimental purposes. 2004). Madhusudan. if effective service scheduling policies are developed. Table 2 lists the service operators in terms of their input and output bindings for service S1. 5. we have instantiated an online shopping domain (consisting of shopping services. 1999). (b) getting information regarding item availability (in terms of inventory levels). we also have prototyped a simulationbased event-driven execution module. Further. we demonstrate the proposed system for two scenarios. Madhusudan et al. S2 and S4. S3. we have conducted some preliminary experiments. These online services provide the following capabilities: (a) getting information regarding items and their features from product catalogs. 5. and (e) making payments. 2003). We illustrate our approach in the context of shopping for a set of items (possibly with interrelationship constraints) given a budget. Details of the planning-based service composition are described in (Madhusudan & Uttamsingh. each selling a set of different items i with each item i having a set of features j. 2004. 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. coping with the dynamics may be possible. we illustrate the different types of service plans that may be generated for a service request by the service composition module. The simulation-based service execution module described in this paper is motivated by the need to develop such scheduling policies. Y. and s14 are transactional operators for logging on and logging off the web service.. The execution module and the world monitor have been implemented as JAVA servlets.1.. As outlined in Section 4. Experimental results on service performance and the effectiveness of the generic ISP&E cycle have been reported in (Madhusudan & Uttamsingh. that provides the ability to check credit cards. s13. The world monitor is initialized with a set of web services corresponding to the service catalog maintained in the planning module. In the experiments in this paper (see Section 5). 2004). The primary aim of these experiments has been to investigate the effect of different scheduling policies in dynamic environments discussed in Section 4. The world monitor collects statistics on all the web services over time as these services are accessed. Son / Computers & Industrial Engineering 49 (2005) 287–317 305 the data collected during the search. The simulation engine currently prototyped in our framework is based on ARENA. These statistics are stored in embedded databases. (c) getting prices of an item i. First. (d) placing orders.T. Then we present the role of the simulation-based mechanism in guiding the service execution module. s12. credit verification and transactional accounting webservices). Additionally we also model a credit card verification web service. Operators s11. placing the order and making a payment. which we report below. (considering that no web service experimental testbeds are available). To evaluate the feasibility of utilizing such simulation-based mechanisms for service scheduling. Service composition is enabled using the Hierarchical Task Network (HTN) planning technique (Nau et al. Operator s15 is an information . Generating service plans Consider three web services S1. The planning module is based on a LISP implementation of the Simple Hierarchical Ordered Planning (SHOP) algorithm and is deployed as a LISP servlet. Implementation and experiments Key modules of the ISP&E architecture of Fig. for the ISP&E architecture.-J. 5 have been prototyped based on the computational models described in Sections 3 and 4.

-J. quantity ordered and the total price to be paid. The plans differ in the access sequence of these webservices. generated by SHOP. For each item. For a total search of the plan space in response to our example service request. 7 is the set of items and features available at each service (Note service Si is denoted as WSi in our encoding). such service requests are obtained via a form-based web interface and the corresponding list representation developed from the same. A shopping service request. we assume that these are available as part of the description of each web service maintained by the service platform. The two plans differ in the items. . This information is obtained during execution by operators s15 and s16 and the catalog at the service platform updated.306 T. The declarative representations for a variety of service requests for a given domain can be generated from an appropriately designed user interface. Similar operators are defined for services S2 and S4. Y. two of the six alternative plans. Madhusudan. For purposes of illustration. In the first plan on the left. information on its features. Son / Computers & Industrial Engineering 49 (2005) 287–317 Table 2 Service operators for web service S1 Wrapper Id s11 s12 s13 s14 s15 s16 Input view (CUSTOMER_ID PASSWORD) (CUSTOMER_ID) (ORDERLIST QUANTITY) (ORDERID PAYMENT) (ITEM_FEATURELIST QUANTITY) (ITEM_FEATURELIST) Output view (LOGSTATUS) (LOGSTATUS) (ORDERID) (PAYMENT_STATUS) (AVAILABILITY_STATUS QUANTITY) (PRICE) This manuscript was processed by Area Editor Shimon Y. webservices are accessed in a different order. 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. wherein user interface elements correspond to logic constructs for a SQL query. SR. Service S3 has an operator to check for card status. prices and current availability (shown by the label QUANT) is available. 8. The approach is similar to current techniques used to search databases from web-based interfaces. gathering operator to query the web service for item availability and s16 is an operator for obtaining item prices. to the platform consists of a list of items. The figure shows only the signatures of the operators (input and output bindings are not shown). are shown in Fig. Shown in Fig. Nof. 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. 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.

-J. . Catalog at each web service. Y. Son / Computers & Industrial Engineering 49 (2005) 287–317 307 Fig. Madhusudan.T. 7.

In a production environment. The choice of available web services. The web service platform has to judiciously select from these alternative plans to effectively fulfill a request and manage its resources.2. 8 differ in (a) which web services are accessed.-J. For example: 12 MusicCDs are ordered in the shopping request. Y. We note that different quantities of items may be ordered at different web sites based on remaining budget. multiple service plans may generated to fulfill each service request received at the service platform. 5. The batch size bought is dictated by the available inventory at each web service at the time the order is placed. Two alternative service plans. these are bought in batches of 10 and 2. Further. The two alternatives in Fig. features and current prices leading to different plans. the items available at each service. These service plans may access possibly common web services. (b) what order. Madhusudan. Son / Computers & Industrial Engineering 49 (2005) 287–317 Fig. To summarize. In the second plan alternative. and (c) the quantities ordered at each web service. availability. 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.308 T. Executing service plans Each service plan (generated in response to a service request) is executed by the service execution module. . multiple number of concurrent service plans may be executed by the service execution. We study the effectiveness of using online simulation in guiding the choice (from alternative plans) in the following section. 8. These MusicCDs are bought in batches of 4 and 8 in the first alternative.

Recent research (Harchol-Balter. 2. and the internal processing time will depend on the condition of the platform (e. Three of them (jZ1. 5. In the experiment. such as query processing in database systems. 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. 2002) shows that many of the analytical models (based on queuing network models) do not reflect actual dynamic behavior that is usually observed. The inter-arrival time between the service requests is randomly generated from an exponential distribution of 100 ms. 4)) are used as the underlying information environment. (if it were running concurrently with the task dispatch mechanism). the total responseP Á (Ti) is the summation of the platform operation À time sij . and the fourth (jZ3) is the credit card service provider. resource usage). 8 will be generated and considered for execution. and 4) are shopping services. Our current work is exploring the use of distributions derived from histograms of real-world service request scenarios. are guided by extant simulation studies in the above literature. It is noted that more types and units of service requests can be tested similarly. Gal & Eckstein. 300 units of the same service request are considered. Y. For purposes of our evaluation. we run the simulation module offline. 2001). . 2003.T. development of appropriate performance modeling techniques is an active area of research. In this experiment. The number of alternative plans obtained from the planning-based composition approach will also vary across different service requests. 3. However. we evaluate the effectiveness of simulation-based scheduling policies in guiding the service execution module. Our choice of stochastic distributions for request arrival times. We note that performance modeling of computer systems (hardware) is a well-studied area (Jain.1. Work in this area is nascent.-J. processing times etc. † For each service request i. In realistic settings. Given this service loading profile. in the context of software systems.2. Additionally. we assume that all customer service requests received at the experimental service platform. & Kossmann. Son / Computers & Industrial Engineering 49 (2005) 287–317 309 depending on the nature of the tasks. We note that the evaluation described herein is primarily oriented towards evaluating if real-time simulation provides better task dispatch guidance in dynamic environments. behavior of the individual web services in terms of processing times may be highly variable as indicated in (Braumandl. the plan generation time will depend on the size of the request (search space). It is also assumed that two alternate plans shown in Fig. The platform operation time includes the plan time ðTpi Þ and the individual service times generation time (using planning-based service composition method described above) and platform internal processing time. 2. Kemper.g. under a variety of experimental conditions. In the experiments below. 2001). and service processing in the Internet. are fulfilled by service plans similar to the plans discussed above. 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. The experiments discussed below focus only on evaluating the nature of the scheduling policies generated by a real-time simulation module. 15. it is assumed that the platform operation time (in seconds) is randomly generated from a triangular distribution of (1. transaction processing at transaction processing monitors and process execution in workflow management systems. Madhusudan. 25). with the same inputs to simulate the realworld context discussed above.

it is also less reliable in contrast to plan 1. and (3) random choice. † The planning horizon is 10.1. failure settings are pZ5 and 50% for j2(2–4) and jZ1.2. we note that for the given simulated conditions. pchooseZ0. the executor attempts to execute again after waiting 10 s. the service times will depend on the loads. (2) ‘choose plan 2 only’. pij (jZ4) is generated from a uniform (11. the total execution time is the summation of individual service times.800 s. In real-time simulation techniques. 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. we study the effect of varying pchoose for a given set of simulated dynamic conditions. 9. Using static rules. tij is generated from a uniform (10. If the real-time simulation module were to use static dispatch rules. Each service (sij) in the plan corresponds to the transmission time (tij) in milliseconds and the processing time (pij) in seconds. 250) distribution. Fig. predefined static plan selection rules were evaluated for both scenarios.2.-J. † The decision problem considered in the simulation is to choose a plan from the set of two alternative plans. 35) distribution. which may not be observable from the platform. Comparing alternative plans 1 and 2. As shown in Fig. dynamic rules allow such predefined plan selection parameters to be updated based on current world state. Observations 5. Son / Computers & Industrial Engineering 49 (2005) 287–317 † For each plan. Therefore. . disk usage. When a failure occurs. failure settings are pZ10 and 30% for j2(2–4) and jZ1. † It is also assumed that the service platform can handle 100 transactions per sec concurrently. respectively. 5. Y. † In realistic settings. In this experiment. Madhusudan. and other conditions. 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’. pij (j2(1– 3)) is generated from a uniform (1. In the second scenario. † To simulate network and service provider dynamics. In the first scenario. These experiments suggest that both static and dynamic rules are needed to cope with dynamic conditions in the web services environment. equal probability. data availability. those excessive requests will be queued at the service platform.310 T. either plans 1 or 2 may be selected with a fixed. In the real setting. One of the static rules considered is that to fulfill a service request. 25) distribution for service providers 1–3. In the second set of experiments. respectively.2.g. when there are more than 100 concurrently served requests.2. and (3) random (equal chance) choice under the first scenario. alternative plan 2 is faster. scheduling policy). † The objective function considered is the minimization of the mean response time. (2) ‘choose plan 2 only’. individual service providers could fail during their execution due to randomly generated events from a Bernoulli distribution with parameter p. Using these simulated conditions. The three decision rules considered are: (1) ‘choose plan 1 only’. however. Other objective functions can be used in the similar manner.5. 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. each service provider may have its own internal policy (e. Firstly. the following experiments were considered to develop policies that the service execution module may use.

9 ≤ µ2 ≥ 81. Therefore. Confidence intervals for average response time under the second scenario.T.3 ≤ µ1 ≥ 84. 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.0 76.6 ≤ µ3 ≥ 81. Under the second scenario. Son / Computers & Industrial Engineering 49 (2005) 287–317 311 Plan Selection Plan 1 only Plan 2 only Rand selection (plans 1 and 2) 95% confidence interval of response time 82. these experiments suggest that the optimal plan selection rule (policy) highly depends Plan Selection Plan 1 only Plan 2 only Rand selection (plans 1 and 2) 95% confidence interval of response time 78. 10. Madhusudan. 9 and 10 agree with our intuitions. .2 79. 10 (second scenario) shows completely different results. 8) is more significant than time loss due to the system failure. time saving due to smaller processing times from the second alternative plan (see Fig. where the differences are not statistically significant.6 ≤ µ1 ≥ 80.0 ≤ µ3 ≥ 80. Fig.2 ≤ µ2 ≥ 78.6 78.5 Fig. 9. Under the first scenario. The simulation results in Figs. the difference of failure rates is as significant as the time saving between the alternative plans. Therefore.2 Fig. the difference of failure rates between the service provider 1 (pZ30%) and the other providers (pZ10%) is relatively small.-J. Thus the higher failure rates (due to environmental conditions) tends to minimize the differences between either plan. Y.1 79. Thus plan 2 must be preferred in scenario 1. On the other hand. Confidence intervals for average response time under the first scenario. Please note that the table below the confidence limits chart also provides the same description.

of average response time) evolving over different settings (number of simulation runs in X axis) for varying pchoose values for the first scenario. indicates the percentage that plan 1 was chosen and minimal value of the objective (average response time in column Minimize plan_both) was obtained. In the previous experiment. In this section. Y. Fig. min. where the minimum average response time corresponds to when pchooseZ94. on the system condition. This suggests that plan 2 should be preferred in scenario 1 and corroborates with the result obtained in the static rule experiments. average response time for the first scenario. which will correspond to the minimal average response time for a given scenario (simulation conditions).312 T. 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. The minimum average response time corresponds to when pchooseZ0. We are currently studying the effects of the real-time simulation module by deploying the same under real-world scenarios. . and their results have been compared for two scenarios of failure rates.2. On the other hand.038%. and OptQuest built as part of Arena has been used with search heuristics discussed in Section 3. 11. The random plan selection rule in those simulations was based on the Bernoulli distribution with pchooseZ50%. Son / Computers & Industrial Engineering 49 (2005) 287–317 Fig. three static rules have been applied. 11 shows the objective function (Y axis.-J.2. Madhusudan.2. Online simulation may be used to then select the appropriate rule for currently existing conditions. Thus. Fig. Optimization plot for min. these experiments suggest that the optimal plan selection policy is highly dependent on the system condition. we intend to obtain the optimal value for pchoose. which can be predicted using the simulation. The Arena models of the previous section have been appropriately modified. the column plan1_percent. 5. Data collection on service execution performance is currently in progress. Thus under highly dynamic conditions.7% for plan 1. the advantages of plan 2 are minimized and plan 1 may be chosen. Simulation may also be used to guide other decisions such as resource provisioning and prioritizing service requests. As shown in the table in Fig. 12 shows the objective function evolving over different settings of simulation for the second scenario. 11. Using OptQuest search method.

Y. The limitations of the proposed approach. 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. Characterizing the web environment is an active area of current research. 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. & Marsden. The proposed approach is similar to the use of machine learning techniques to learn about source (and service) characteristics (Nie. Goes. Drenick & . Also. A simulation may also provide the best option to reason about a large number of interacting entities in the real-world. 2003). 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. Son / Computers & Industrial Engineering 49 (2005) 287–317 313 Fig. simulation studies for analyzing quality-ofservice metrics in the Internet environment are described. & Kambhampati. Implementation of the simulation-based execution module is a difficult step. Explicit deliberative reasoning such as using logic-based state-space reasoning techniques may not be completely effective.-J. Vaddi. 2000) attempts to characterize the response time characteristics of web services. Raschid. (Gruser. In (Braumandl et al.T.. our ongoing experiments are focused on evaluating the computational costs of managing and updating the simulation dynamically during runtime. Gupta. average response time for the second scenario. 2002). 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. 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. 2003. include the cost of setting up and managing a concurrent simulation to obtain partial insight into future world state. 6. & Zhan. The effect of stochastic conditions on different types of information processing tasks is discussed in (Chen. Optimization plot for min. Madhusudan. Zadorozhny. 12. Nambiar. Further.

. dynamically updating the simulation and underlying distributions (based on change points in the realworld). 2002). Additionally. by enabling exploration of alternative world states in a concurrent manner. considering that the web environment is dynamic and open. . Madhusudan. simulation is used to evaluate each service plan to guide selection of a plan during the service composition phase. However. requests or networks (to improve the fidelity of a simulation). our use of simulation is to guide the service execution module in scheduling service plans. and (c) presented experimental studies to highlight the utility of a simulation-based approach to cope with the dynamics in a web services environment. Many avenues exist for future research including. we have: (a) proposed the development of online look-ahead simulation-based approach for scheduling web service execution. exploring the role of simulation in guiding re-planning versus re-execution. Studies on task scheduling suggest that many of the normal assumptions may be invalid and empirical distributions are being developed (Harchol-Balter. 2001). 2003). the composition of service plans is done with manual guidance and simulations are run offline. However. Stochastic process models have been developed for the same in (Gal & Eckstein. the suggested approach needs to be further evaluated in a variety of domains and execution environments. Overall. and performing large-scale real-world studies (including stress testing the implementation). 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. our simulation approach is used to guide decision-making in dynamic systems and provide guidance to the execution controller. Son / Computers & Industrial Engineering 49 (2005) 287–317 Smith. real-time performance depends on the dispatch rules used by the service scheduler. though each service plan may be evaluated individually using simulation. 2003). 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. implementing an effective simulation-based dispatch mechanism is a difficult and costly task. In (Chandrasekaran et al. However. and thus guiding service execution. it may never be possible to characterize effectively the dynamics of the services. In future work. (b) described the implementation of a viable architecture to support the same. Concluding remarks In this paper. 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). Secondly. we use planning techniques for dynamic service composition and online (real-time) simulation to guide service scheduling. 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. improving the interface between the simulation and the decision-maker modules in the service execution component.314 T. there are some fundamental differences.-J. Firstly. Y. the simulation may provide effective insight into the aggregated effects of the various dynamic events in the web services environment.. From a computational perspective. 1993). 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. These have assumed exponential and Poisson process distributions. 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. In contrast. Though feasible. 7. In (Chandrasekaran et al..

Systems Analysis—Modelling-Simulation... J. Langworthy. D. The self-serv environment for web services composition. 44–53. . http:// www-106. F. & Dumas. & Shan. & Hee. A. Middleware for mobile information access. Ming-Chien (2002). The Journal of Circuits. Cabrera..P. Mike (2003). Z.. Information Systems. 29(1–2). T. 26(3). Areas of ongoing research include developing techniques to speed up the simulation-based reasoning cycle in the execution module. (2002). In Proceedings of the fifth international work-shop on mobility in databases and distributed systems (MDDS’2002). 13(2). A..com/developerworks/library/ws-coor/.. (2002). 24–29.M. 143–163. A.. Aalst. 3(4). Bussler. 21–66.. L. 176– 181. R. (2001). ACM SIGMOD. 7(1). M. & Yesha. (2002). Gray... 7(1). Orchard. (2003). 31(4). University of Georgia. Kemper.. & Fensel. G. The Knowledge Engineering Review.. M.. A. ACM Transactions on Internet Technology. An agent-based cross-organizational workflow architecture in support of web services. Freund. 8(1). Benatallah. References Aalst. Miller. Quality of service in an information economy. Blake.. Braumandl. Acknowledgements We are grateful to the referees.. B.-J. Information Systems Frontiers.ibm. T. A. developing interleaving rules for guiding service composition (based on simulation feedback). The application of petri nets to workflow management. Performance analysis and simulation of composite web services. Q. B. Quality of service and semantic composition of workflows. J. 4(1).. & Logrippo. Casati. van der. WETICE pp. 1(1). Business process redesign: A petri-net based approach. Dynamic and adaptive composition of E-services. Web services coordination. G. (1999). Joshi. Casati. Y..P.. F. Sheng. D. J.. Klein. D. B. Blake. 15–26. Electronic Markets. . T.. 19–31. (2003). Web services transaction. & Gini. W. van der (1999). Finin.. Madhusudan.. Use case maps for the capture and validation of distributed systems requirements Proceedings of RE’99. J.ibm. Y. Computers in Industry. Guest editorial: Agent-based approaches to B2B electronic commerce. 35(3). International Journal of Electronic Commerce. B. Son / Computers & Industrial Engineering 49 (2005) 287–317 315 In the near term. R. Event-based interaction management for composite E-services in eFlow. M. The deliberate revolution. B. 40–48. D.T. M.. Amyot. I. Agent-oriented approaches to B2B interoperability. S. Klein. F. developing new dispatching rules for service scheduling.M. J. A conceptual architecture for semantic enabled web services. B. D... ACM QUEUE. Aalst. Buhr. (2001). D. PhD Thesis. & Shan. . (2002). (2002).. van der (1998). 16(4). Cox. 291–333. Storey. whose comments have considerably improved the presentation of the ideas in this paper. 5–6. fourth IEEE international symposium on requirements engineering pp. T.. (2003). K. 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. Copeland. et al. Chandrasekaran. comparing the simulation-based approach with analytical techniques (based on sequential decision-making models). G. et al. IEEE Computer. M. Cardoso. Chakraborty. (2002). com/developerworks/library/ws-transpec/..P. & Sheth. A petri net based workflow analyzer. Maedche. http://www-106. & Kossmann. 28–37. W. Freund. Blake. Burner. Systems and Computers. Arpinar. C. Fabio. M.M. and developing resource provisioning models for individual web services. (2002). 383–388. F. Copeland. Silver.. W.. T.. A. 345–357. Cabrera. (1996). Perich. M.

371–376). 9(1). K. & Zhan.. 46(10). N.com since Sept 1 2004.. J. Journal of the ACM. A.). 49(2). (2003). & Schmidt. Sheth. The art of computer systems performance analysis. Proceedings of the 25th annual international computer software and applications conference (COMPSAC 2001) (pp. Business process execution language. F. A. Fensel. W3..pdf. & Uttamsingh. Miller.. Drenick. Decision Support Systems. Y. (2002). Service composition issues for distributed business processes. P.. discovery and integration of web services. P. & Benatallah. Zhang (Ed. OASIS.. H. & Bussler. A. J. & Kambhampati. In Proceedings of the second workshop on e-business. Lotem. (1995). & Eckstein.... Jones. Maamar. Son / Computers & Industrial Engineering 49 (2005) 287–317 Chen. Nau. Klein... In Proceedings of ACM CIKM. P. B. A. http://www. On composite web services provisioning in an environment of fixed and mobile computing resources. Newyork. P. (1993). F. Saddle River. & Roller. Communications of the ACM. Madhusudan. Consortium. A runtime composite service creation and deployment infrastructure and its applications in internet security. J.... S.org/.org/TR/wsdl. Gupta. http://www. Chirtsabesan B. Available online at http://www. Uttamsingh. Nambiar. no. P. In Proceedings of the 1995 winter simulation conference. Leymann F. & Smith. Proceedings of the international conference on web. Harmonosky. & Laguna. Madhusudan. An intelligent mediator-based framework for enterprise application integration. 25–28. Madhusudan. (2002). 968–973).uddi.. H. & Marsden. J. Web services and business process management.316 T. Real-time scheduling in computer integrated manufacturing. Sheng. Cao. R.. (2003). R. Rabelo. C. (1991). A. Production workflow... USA: Springer.Z. D. L. D. L. Decision Support Systems. Kelly. D. Rept.com/software/solutions/webservices/pdf/BPEL.. 2617) Design and control of workflow processes. Z. (2002). E. Leymann. M.. 8. Curbera. O’Brien. V. Goes. (1995). (LNCS..S. Database design in the modern organization: Identifying robust structures under changing query patterns and arrival rate conditions. T. 1141–1183. X. and software provisioning. Weerawarana S. Madhusudan.. A. J. Z. F. Consortium. Q.. 4(4). Gruser. Mudireddy S. 260–288. (2003)... & Murugan. Newyork.. S. E.w3. W. (2000)..unsw. U.cse. Mennie D. T. Dieter (2000). Roller. M. Vaddi. In Proceedings of the international conference on industrial engineering. A. Frank. e-commerce. & Robohn. (2002). R. Kochut.. (2003). Kanetkar. N. Ginis. In L. Reijers.. (2001). M. Jennings. Papazoglou. N. A. Glover. www. 37(3). 18–37. NI. R. USA: Prentice-Hall. International Journal of Applied Artificial Intelligence.swws. 331–340.edu.. Harchol-Balter.. P.. Thatte S. available online at www. An experience report on developing an automated web services platform. In Press. VLDB Journal. Cha.. H. & Yuchwera. (2001).R. 41(2).. M. T. Gal. Raschid. 145–154.. 48(6). T. S. J. 14(2). Simulation modeling within workflow technology. & Son. S.. ACM Transactions on Database Systems.. International Journal of Computer Integrated Manufacturing .. (1999).-J. Y.. Autonomous agents for business process management. (2004). A declarative approach to composing web services in dynamic environments. D. Service-oriented computing.. Journal of the ACM. Verlag. International Journal of Computer Integrated Manufacturing.. A. & Pagurek B. J. 435–447. Optimization Technologies Inc. (2002). Managing periodically updated data in relational databases: A stochastic modeling approach. Nie. N. T.org. (2003). Y. Goland. & Odgers. Roller D. Y. The optQuest callable library user’s documentation. & Munoz-Avilla. M. (2003). Zadorozhny... http://www. The web service modeling framework—WSMF. CO: Tech. Sun. 145–189. B.. (2004). K. Stochastic query optimization in distributed databases. A. . 18(2). & Georgakopoulos. 262–288. (2001). & Chandy.ibm. Fuzzy logic based reinforcement learning approach for dynamic job shop scheduling. Information and technology management. (1999). M. Task assignment with unknown duration. (2000).. IBM Systems Journal.pdf.. Boulder. Learning response time for websources using query feedback and application in query optimization. P. WSDL standards..sciencedirect. Leymann. ASME Journal of Computing and Information Science in Engineering. Jain. Faratin. B. 198–211. Garg. A hybrid approach for real-time sequencing and scheduling.au/ qsheng/papers/ITM-03. Norman.. Y. (2003). K. SHOP: Simple hierarchical ordered planner Proceedings of IJCAI-99 (pp. 294–304. (2002). (2001). C. Universal description. Mining coverage statistics for websource selection in a mediator. J. F. USA: Wiley.. Wang..

Wysk. & Wysk. . 16(4). R. E. S. Zhao. L. Short-term simulation: Bridging the gap between operational control and strategic decision-making Proceedings of the IASTED conference on modeling and simulation (pp. 29–48. A multipass simulation-based realtime scheduling and shop floor control system.. Y. model generation and control interface.M. A. (1999). Beringer. G. IIE Transactions on Design and Manufacturing. (2000). 417–421). 7(2). W. Son. D. D. & Stohr.P. & Aalst.. R. Transactions of the Society for Computer Simulation International. A. A. & Jones. Journal of Manufacturing Systems. Wiederhold. S. IEEE Internet Computing. N. & Wysk.. Middleware for web services. Son. Sample... (1988). Jan–Feb. A. Y. D. Composition of multi-site services.. A. Mellout. H. L.. van der (1999). Rodriguez-Rivera. 35(1). Madhusudan. H. (2003). 107–120. (1999). Simulation-based shop floor control: Formal model.. Wu.. Y.-J. J. (2003). & Lea. In Proceedings of IDPT’2000. 159–172. A.. coordination and collaboration. Vinoski. R.. Temporal workflow management in a claim handling system. In Proceedings of the international joint conference on work activities. Multipass expert control system: A control and scheduling structure for flexible manufacturing cells. Son / Computers & Industrial Engineering 49 (2005) 287–317 317 Reijers. T.T.

Sign up to vote on this title
UsefulNot useful