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

Performance Experiments

Table 1 shows the intervals used for the generation of random network latencies. After that, we randomly generated a service environment by spreading a given number of tire dealer services, forwarding agency services, and service hosts across the cities. Every tire dealer involved in the scenario had three service hosts in the same MAN, such that arbitrary services could be executed near the tire dealers. In our benchmarks, we spread 12 tire dealers, 35 forwarding agencies, and 36 service hosts across 100 cities. We used 1 Sun Ultra 450 (4x450 MHz), 7 Sun Ultra 10 (333 MHz), and 2 Sun Ultra 1 (167 MHz) workstations for the simulation. The Ultra 450 was used to run all tire dealer and forwarding agency services. As already mentioned in Section 3, the implementation of the tire purchasing service is split up into two services: the main tire purchasing service and a negotiator service, so we can choose where to execute the individual services. We considered three different allocation schemas:

central:

The tire purchasing service and one static negotiator service are executed at the client.

partially distributed:

The tire purchasing service is executed at the client and several static negotiator services are distributed across the WAN. We always use the negotiator service closest to the considered tire dealer service. In our benchmarks we used three static negotiators.

fully distributed:

The tire purchasing service is executed at the client and all negotiator services are dynamically instantiated and executed at service hosts near the tire dealers. According to our scenario, the number of dynamic negotiators is equal to the number of tire dealer services.

Table 2 shows the results. As expected, the third allocation schema results in the fastest execution. The main reason for this is that we use forwarding agency services near the tire dealers which results in cheap communication. Furthermore, the negotiator services executed on several service hosts work in parallel which reduces execution time even further. Parallel execution is only possible because the original e-service is split up into two small dynamic services. As an additional advantage, it is easier to implement two small services than a large one. Better reusability is a further advantage of smaller, more general services.

The last column of Table 2 shows the time spent for UDDI queries (this time is already included in the overall time). The time is proportional to the number of UDDI queries posed in the given schema, i.e., ``fully distributed'' poses the most UDDI queries, ``central'' the least. It should be noted that the ``fully distributed'' schema has the least execution time although it spends the most time for UDDI queries. As a further note, we must mention that the query capabilities of UDDI Version 2.0 are much more elaborate than the ones of UDDI Version 1.0. We expect that the next UDDI versions will extend UDDI's query capabilities even more and that, as a consequence, the time spent for UDDI queries will not be a dominant factor in e-service execution in the future.