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

Architecture of ServiceGlobe

 

Figure 1: Classification of Services

External services are services currently deployed on the Internet, which are not provided by ServiceGlobe itself. Such services are stationary, i.e., running only on a dedicated host, are realized on arbitrary systems on the Internet, and have arbitrary interfaces for their invocation. Since we want to be able to integrate these services independent of their actual invocation interface, e.g., RPC, we use adaptors to transpose internal requests to the external interface and vice versa. This way, we are also able to access arbitrary applications, e.g., ERP applications. Thus external services can be used like internal services and, from now on, we consider only internal services.

Internal services are native ServiceGlobe services. They are implemented in Java using the service API provided by the ServiceGlobe system. Of course, it is feasible to use a specialized programming language, e.g., XL [FK01], or a graphical tool to draw a representation (similar to a workflow graph) of a service, but that is not the focus of our work. ServiceGlobe services use SOAP to communicate with other services. Services receive a single XML document as input and generate a single XML document as result. There are two kinds of internal services, namely dynamic services and static services. Static services are location-dependent, i.e., they cannot be executed dynamically on arbitrary ServiceGlobe servers. Such services may require access to certain local resources, e.g., a local DBMS to store data, or require certain permissions, e.g., access to the file system, that are only available on dedicated servers. These restrictions prevent the execution of static services on arbitrary ServiceGlobe servers. In contrast, dynamic services are location-independent. They are state-less, i.e., the internal state of such a service is discarded after a request was processed, and do not require special resources or permissions. Therefore, they can be executed on arbitrary ServiceGlobe servers.

There is an orthogonal categorization for internal services into adaptors, atomic services, and composite services. We have already defined adaptors. Atomic services are internal services not using any other service. Composite services are higher-value services assembled from other internal services. These services are, in this context, called basis services, because the composite service is based on them. Note, that a composite service can also be used as a basis service for another higher-value composite service.

Internal services are executed on service hosts, i.e., hosts connected to the Internet which are running the ServiceGlobe runtime engine. ServiceGlobe's internal services are mobile code, therefore their executables are loaded on demand from code repositories onto service hosts or, more precisely, into the service hosts' runtime engines. A UDDI server is used to find an appropriate code repository storing a certain service. Service hosts offer a SOAP service (called runtime service loading) to execute dynamic services. Thus, the set of available services is not fixed and can be extended at runtime by everyone participating in the ServiceGlobe federation. If internal services have the appropriate permissions, they can also use resources of service hosts, e.g., databases. These permissions are part of the security system of ServiceGlobe which is based on [SBK01] and they are managed autonomously by the administrators of the service hosts. This security system also deals with the security issues of mobile code introduced by runtime service loading. Thus, service hosts are protected against malicious services.

Runtime service loading allows service distribution of dynamic services to arbitrary service hosts, opening optimization potential: Several instances of a dynamic service can be executed on different hosts for load balancing and parallelization purposes. Dynamic services can be instantiated on service hosts having the optimal execution environment, e.g., a fast processor, large memory, or a high-speed network connection to other services. Of course, this feature also contributes to reliable service execution because unavailable service hosts can be replaced dynamically by available service hosts. Together with runtime service loading this provides the flexibility needed for load balancing or optimization issues.

 

Figure 2: Architecture of a ServiceGlobe Enabled Web

Figure 2 gives an overview of the basic components of the ServiceGlobe system and their mutual interaction (based on our e-procurement scenario): The negotiator services use external services (adaptors are omitted in the figure) and the tire purchasing service uses two dynamic services. At first, a client sends a SOAP request to execute the tire purchasing service to a service host. This service is loaded from a code repository (if not already cached) and instantiated on the service host. The tire purchasing service deploys several basis services (here, two negotiator services) during execution. Therefore, suitable service hosts are located by UDDI requests and the negotiator services are loaded and executed on them on behalf of the tire purchasing service. The negotiator services deploy external tire dealer and forwarding agency services to calculate their results.