Name: Dynamic QoS based Supply Chain
Author(s): Kunal Verma, Amit Sheth, John Miller, Rohit Aggarwal
URL(s) or other references:
 A.P. Sheth, W.M.P. van der Aalst, and I.B. Arpinar, Processes Driving the Networked Economy: Process Portals, Process Vortexes, and Dynamically Trading Processes, IEEE Concurrency, 7 (3), pp. 18-31.
 Jiong Sun, Norman M. Sadeh, Dynamic supply chain formation: integrating multi-attribute auctions and finite capacity scheduling, Proceedings of the 4th ACM conference on Electronic commerce
 D.D. Zeng and K.P. Sycara. Agent-facilitated real-time flexible supply chain structuring. In Proc. of the Agents'99 Workshop "Agent-Based Decision-Support for Managing the Internet-Enabled Supply-Chain"), pages 21--28, Seattle, WA, 1999
 Abhijit Patil, Swapna Oundhakar, Amit Sheth, Kunal Verma, METEOR-S Web service Annotation Framework, The World Wide Web Conference, 2004 (WWW2004)
 Jorge Cardoso, Amit Sheth, John Miller, Jonathan Arnold, and Krys Kochut, , “Quality of Service for Workflows and Web Service Processes,” Journal of Web Semantics, 2004 Prepublication copy at: http://lsdis.cs.uga.edu/lib/download/CSM+QoS-WebSemantics.pdf
 Daniel J. Mandell and Sheila A. McIlraith, A Bottom-Up Approach to Automating Web Service Discovery, Customization, and Semantic Translation., In the Proceedings of WWW2003 Workshop on E-Services and the Semantic Web (ESSW '03).
 RosettaNet PIP3A4
Kaarthik Sivashanmugam, John Miller,
Amit Sheth, and Kunal Verma, Framework for Semantic Web Process Composition,
International Journal of Electronic Commerce (accepted) , 2004 Prepublication
Domains: e-commerce, supply chain, B2B
This usage scenario illustrates the use of selection criteria in the dynamic composition of Semantic Web Services. A key feature of the scenario is the use of quality of service (QoS) as an essential criterion for dynamic selection of services. An industry sector which we feel that this approach will be particularly useful is supply chain management. Traditionally, supply chains are static with close collaborations between suppliers and retailers. In the last few years, exchanges  and auctions  have been used to add dynamism to these chains. The advent of Web services will allow easy integration of suppliers with manufactures. This can lead to the creation of dynamic supply chains. We will illustrate this with a simple scenario related to ordering computer parts.
Consider a scenario where a retailer gets an order and he must procure parts from suppliers based its on inventory levels. Current supply chains , are based on tight integration with supplier partners, where suppliers produce parts on the basis of the retailer’s forecasting software. So far, high cost of integration made it impractical for the retailer to integrate a number of suppliers in their processes and dynamically choose the suppliers based on their quotes. With the help of industry wide acceptance of standards such as Business Process Execution Language for Web Services (BPEL4WS), Web Service Description Language (WSDL) and Simple Object Access Protocol (SOAP), Web Services offer the potential of low cost and immediate integration with other applications. However, initial research and most of the industrial technology development efforts thus far have been focused on static integration using Web services. Subsequently there has been proposals , architectures  and research   in dynamic trading processes and more specifically dynamic supply chains. This use case builds upon a small, more practical subset related to extending static supply chain to dynamic supply chain through a dynamic Web process technology, and also utilizes recent approaches based on the research on semantic Web and semantic Web services/processes.
Designing dynamic Web processes (as done in ), starts with specifying abstract processes, which capture high level requirements of the process. Subsequently, candidate services must be discovered on the basis of the required functionality. This use case uses ontologies and semantic metadata for representation/annotation  and automated discovery of candidate services. Service selection should be based on domain constraints, behavioural signatures, and Quality of Service (QoS) parameters (also referred to as Web Service Policies ). In case of the option of having a number of candidate services, strategies for optimization, while considering domain constraints will have to be developed.
Retailer, Suppliers, Client
Retailer wants to choose the best suppliers based on its business logic. The suppliers want to maximize their profit as well as increase their business with the retailer.
Dynamic QoS based Supply Chain
Same as scenario actors
Retailer wants to optimize its supply chain on the basis of up to date quotes from suppliers based on its quality of service criteria.
Details of specifying QoS for web services are discussed in , , and that of calculating QoS of (end-to-end) workflows and Web processes (resulting from Web services composition) have been discussed in . The central idea is to reduce a workflow to a single task and calculate aggregate QoS. For illustration purposes, we have included two reduction algorithms.
Reduction of a Sequential System: The figure below illustrates how two sequential workflow tasks ti and tj can be reduced to a single task tij. In this reduction, the incoming transitions of ti and outgoing transition of tasks tj are transferred to task tij.
This reduction can only be applied if the following two conditions are satisfied: a) ti is not a xor/and split and b) tj is not a xor/and join. These conditions prevent this reduction from being applied to parallel, conditional, and loop systems. To compute the QoS of the reduction, the following formulae are applied:
Reduction of a Parallel System: The figure below illustrates how a system of parallel tasks t1, t2, …, tn, an and split task ta, and an and join task tb can be reduced to a sequence of three tasks ta, t1n, and tb. In this reduction, the incoming transitions of ta and the outgoing transition of tasks tb remain the same. The only outgoing transitions from task ta and the only incoming transitions from task tb are the ones shown in the figure below.
The QoS of tasks ta and tb remain unchanged. To compute the QoS of the reduction the following formulae are applied:
Steps outlined in the process can be divided into eight parts:
1. Client Application: The client application may be a web interface which is used to create orders to be sent to the retailer. After the process of ordering the parts requested by the client is finished, the client application is also used to display the order confirmation. The client also supplies QoS parameters for the process based on the generic QoS and domain specific ontology. The QoS parameters may include domain specific parameters like Hard Disk speed, read delay, etc. or general parameters like max cost, max delivery time etc.
2. Upon receiving the client request, the purchase order is processed. This processing is equivalent to the seller side processing in RosettaNet PIP3A4  and the use case ‘Semantic Web enabled Business Protocol Standards’ (Zaremba/Bussler)  but, the seller in our case is the retailer which itself acts as a buyer and further requests quotes from and sends POs to its suppliers. The processing involves the following sub-steps:
Aggregate QoS parameters for the suppliers are defined
on the basis of the clients
order. For example, if a client specifies $10000 as the maximum cost, the retailer may
specify the aggregate cost of the process to be less than $9500.
· Inventory is checked for part availability.
· If all parts are available then the process goes to step 8.
· Otherwise, potential suppliers are selected from a local database of preferred suppliers. This database provides the information of suppliers for each part ordered and also contains information on how to invoke the web service of this supplier to obtain quotes and to place the final order.
3. The list of potential suppliers is sent to the proxy web service. The proxy then invokes the GetQuote web service of all the potential suppliers in parallel. Presently in BPEL, the binding has to be done at compile time itself. The proxy removes this restriction and invokes web services at execution time   .
Retailer Order Handling Process
4. The supplier web services will send their respective quotes back. The client may specify some QoS parameters in the user request. The quotes received from the individual suppliers will also contain specific values of these QoS parameters. Upon receiving some or all of the quotes, the quote list is forwarded to the proxy.
5. The proxy is Semantic Web enabled which optimizes on the basis of user’s constraints and dynamically invokes the web service of the best supplier. This optimization can be done using techniques like linear programming. The proxy selects the best quote(s) from the list after matching the QoS parameters specified by the client with those specified in the individual quotes. After the selection of the quote(s), the proxy places the final order with the respective supplier(s) by invoking their SendOrder web service and sending a purchase order.
6. The suppliers will process the purchase order and send back a purchase order confirmation which may contain the order confirmation number and expected delivery date.
7. The retailer schedules delivery on the basis on the supplier(s) dates.
8. This information is sent to the client application. Services can also be monitored to verify that QoS is maintained. Suppliers may also provide a GetStatus web service which will aid the client to get the status of their order.
We have developed specifications for augmenting BPEL4WS with service templates for each invocation of a Web service in . A service template is created by using functional and execution semantics as well as QoS specifications of all the operations of the Web service in the process.
QoS specifications for individual Web services and processes have been defined in . There is the need for a generic QoS ontology (currently a prototype is under development in the METEOR-S project). In addition, domain specific ontologies can be used to represent domain specific QoS metrics, as well as other process constraints like inter service dependencies as illustrated in 
 Currently under development for a subsequent proposal to this or other group.