TU München - Fakultät für Informatik
Lehrstuhl III: Datenbanksysteme

Description of the Tire Purchasing Demo

In this demo, we present the ServiceGlobe system and several of its key concepts using an automobile industry e-procurement scenario. For simplicity, we do not describe a complete e-procurement solution comprising of a marketplace service and automobile industry supplier services. Instead, we concentrate on the example of tire purchasing.

Tire Purchasing Scenario

In this scenario a car manufacturer requires an e-service for the task of purchasing tires and employing a forwarding agency to deliver these tires. In detail, this e-service has to perform the following tasks: First, it has to invite offers from available tire dealers for a given type and quantity of tires. Second, it must invite offers for the delivery of these tires to the car manufacturer. Third, it must calculate the cheapest combined offer for the purchase of tires from a tire dealer and the delivery of these tires by a forwarding agency. At last, the e-service must place purchase orders, based on the cheapest combined offer, at both, the tire dealer and the forwarding agency. If placing of a purchase order fails, the second cheapest combined offer should be tried (and so on).

The new e-service is split into two separate, dynamic services: a tire purchasing service and a negotiator service. This allows an optimized service execution by pushing negotiator services to service hosts close to tire dealers. The negotiator service instances are executed on several service hosts in parallel and thus it is assured that communication with the forwarding agency services is cheap. Using a graphical tool, the resulting services look like the graphs shown in Figure 1.

**Figure 1:** Graphical Representations of the Services

The tire purchasing service is the main service which is called directly by the car manufacturer. First, the service queries UDDI for tire dealer services (using a UDDI tModel). Using this technique, the service is independent of the available tire dealer services at a particular time and the implementation need not be changed to remove outdated or add new tire dealers. For every tire dealer service, we look for a service host close to the location of the tire dealer to minimize communication costs to the tire dealer service as well as to the forwarding agency services later on. Next, we execute a negotiator service on each of these service hosts. For performance reasons, all negotiator services are executed in parallel. Finally, we wait for the results of all negotiators. A timeout handles services that do not respond in time. After collecting the results, the combined offers (tires and delivery) are sorted by price and the tire purchasing service tries to contract a tire dealer and a forwarding agency starting with the cheapest offer. If one of the two participants fails for any reason, the contract conclusion is aborted and the next (more expensive) offer is used.

A negotiator service is called with information about which tire dealer it should contact. Its first action is to invite an offer from the given tire dealer. After that, it calls forwarding agency services using an all-mode call. Additionally, a QoS constraint filtering all forwarding agencies geographically close to the tire dealer is used. In our example, it is assumed that forwarding agencies in the neighborhood of tire dealers have the cheapest offers due to short routes. The negotiator invites offers from all selected forwarding agency services in parallel and waits for the results, calculates the overall costs (tires and delivery), and determines the five cheapest offers. These offers are sent back as result.

What will be shown

The demo consists of two applications. First, a frontend to the tire purchasing service allows to enter data into a form and execute the service. The frontend also allows to view all XML documents exchanged between the various services in the execution. Second, a map application depicts all services and their location graphically. It allows to add and remove tire dealer and forwarding agency services at runtime, to view all interactions between the services, and to influence the execution by setting individual timeouts, simulate failures, and so on.
Using these applications we demonstrate some of the major concepts of ServiceGlobe. First, we show where and how dynamic service selection takes place in our e-procurement scenario: Negotiator services contact several forwarding agencies, using dynamic service selection and an additional QoS constraint filtering all forwarding agencies geographically close to the corresponding tire dealer. Second, we demonstrate runtime service loading and service distribution: The tire purchasing service can be instantiated on every service host on the Internet (which we simulate, of course). The negotiator services are pushed close to the location-dependent tire dealer services such that communication overhead is reduced. This leads to load balancing (different service hosts for negotiators), to parallelization (negotiators work in parallel), and to profit from cheaper communication costs (execution close to tire dealers).

Lehrstuhl für Datenbanksysteme
Letzte Änderung: 25.05.2005 um 14:37:50