Dynamic QoS based Supply Chain

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 [1][2] and auctions [3] 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 [4], 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 [5], architectures [6] and research [7] [8] 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 [9]), 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 [10] 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 [11]). In case of the option of having a number of candidate services, strategies for optimization, while considering domain constraints will have to be developed.

Issues

This scenario shows the use of QoS in conjunction with semantics for creating and optimizing dynamic business processes. Critical to the selection of relevant services is the notion of QoS, also called as policy (WSPolicy). QoS of a Web service describes performance and other quantitative aspects of a Web service. QoS criteria can either be generic or domain specific. [12] [17] have described generic QoS metrics, a standard component of these metrics involves time, cost and reliability. There is a need for a well accepted ontology for the generic QoS criteria[1]. Even more relevant to service selection may be domain specific criteria such as part delivery time and part specific details like reliability of the part. Domain specific ontologies are crucial for agreement about domain specific parameters.

Actors & Goals

Retailer, Suppliers, Client

Stakeholders & Interests

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.

Modification History

Created: 17^th March 2004

Use Case Title:

Dynamic QoS based Supply Chain

Actors/Roles

Same as scenario actors

Goals/Context

Retailer wants to optimize its supply chain on the basis of up to date quotes from suppliers based on its quality of service criteria.

Assumptions

Existence of QoS ontologies
Execution Engine capable of dynamic orchestration [14][15]

Steps

Process QoS

Details of specifying QoS for web services are discussed in [11], [17], and that of calculating QoS of (end-to-end) workflows and Web processes (resulting from Web services composition) have been discussed in [12]. 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 t_iand t_jcan be reduced to a single task t_ij. In this reduction, the incoming transitions of t_iand outgoing transition of tasks t_jare transferred to task t_ij.

This reduction can only be applied if the following two conditions are satisfied: a) t_iis not a xor/and split and b) t_jis 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 t₁, t₂, …, t_n, an and split task t_a, and an and join task t_bcan be reduced to a sequence of three tasks t_a, t_1n, and t_b. In this reduction, the incoming transitions of t_aand the outgoing transition of tasks t_bremain the same. The only outgoing transitions from task t_aand the only incoming transitions from task t_bare the ones shown in the figure below.

The QoS of tasks t_aand t_bremain unchanged. To compute the QoS of the reduction the following formulae are applied:

Process Execution

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 [16] and the use case ‘Semantic Web enabled Business Protocol Standards’ (Zaremba/Bussler) [13] 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 [14] [15] .

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.

Ontologies and Semantic Descriptions

We have developed specifications for augmenting BPEL4WS with service templates for each invocation of a Web service in [18]. 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 [12]. 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 [14]

Reasoning Techniques Required

Constraint analysis.

Potential use of deductive reasoning for Semantic Web service discovery and/or to match requestor’s and supplier’s QoS

[1] Currently under development for a subsequent proposal to this or other group.

Description