Service Manager

The SM manages the life cycle of services. The architecture of the Service Manager is de-picted in Figure 3.5 and basically consists of two areas: A Service Manager Interface (SMI) which receives query documents and—depending on internal state—eventually delegates its processing and a Service Management Area (SMA), providing an area to load services (dis-played on the left side) and facilities for instantiating services on the NexusDS node (dis(dis-played at the bottom).

The Service Management Area provides an environment for service execution. Thereby it offers an interface to receive incoming query documents. It also provides an interface for the Service Loader (SL) to start, stop, or pause the execution of a service instance. This component provides a life-cycle management for services. Finally, the Service Management Area offers an interface for instantiating services.

In order to load and start services on a NexusDS node, the Service Loader looks up and re-trieves service package binaries from the Service Repository Service. The Service Loader also holds services already retrieved in a local cache, instantiates the services in the Service Man-agement Area (if necessary) and removes services which are no longer needed. The Service Loader furthermore provides a small registry of all service instances running on the local node.

This is needed for the Service Manager Interface to answer the question if a service already running on this NexusDS node is capable of processing the query document. The answer to this question is useful for the Service Manager Interface when deciding whether to process a query document locally or not.

Once services have been instantiated and started, they are ready to process incoming doc-uments. During the instantiation process, each service also publishes its specific connection information. This service-specific connection information is needed for direct service invoca-tion as described in Section 3.5.1.1. The direct invocation mechanism is useful if a specific service instance should receive the query document. The default way is to send the query document to the Service Manager, which then handles the invocation of the correct service transparently, either by a locally running instance or a remote one.

The decision whether a local or a remote service instance should process the query doc-ument is taken by the Service Manager Interface. The decision can be made depending on different criteria, such as the current load on the NexusDS node or if a service is already run-ning, offering the requested service. In this sense, the Service Manager Interface acts as a component which makes its routing decisions, depending on the local load situation and con-tents of the query document. The internal functioning of this component is similar to the idea of an Enterprise Service Bus (ESB) [33]. The ESB provides an architectural approach for ser-vice and application integration in enterprises. These enterprises usually have a heterogeneous service infrastructure. The ESB approach tightens the communication between those loosely coupled and heterogeneous services by a shared communication bus. However, point-to-point connections between different services are still possible. The Service Manager Interface works in a similar way: It represents a shared communication bus for services and applications of

Figure 3.5:Architecture of the Service Manager (SM)

NexusDS and routes query documents (as well as the corresponding resulting documents) de-pending on the local load situation and on its contents.

When an inquirer invokes the Service Manager by sending a query document to it, the following steps are performed by the Service Manager (as shown in Figure 3.5): The query document, having a specific document format, is received by the Service Manager Interface 1m. The Service Manager Interface needs to decide whether the query document is processed locally or must be forwarded to a remote Service Manager-instance. The Service Manager Interfacefirst checks if the local workload allows a local processing of the query document, i. e.

by asking the local Monitoring Service-instance 2^m. If the result is positive, i. e. no overload situation is detected, it is checked if the service necessary for query document processing is already loaded and running on the local node 3^m. If the service instance is not locally available, a lookup in the Service Repository Service is needed 4^m. The Service Repository Service returns the service binaries. The binaries are locally stored in a service cache and theloaded service

3.5 NexusDS Components Architecture 93 is also registered locally after instantiation. Moreover, the instantiated services also register to the Service Repository Service in order to be discoverable and directly accessible (see Section 3.5.1.1). This last step is necessary since something might go wrong when instantiating the service. Once the requested service is locally available, the original query document is passed on to the service instance 5^m. The service instance then processes the query document and produces a feedback or resulting document which is sent back to the inquirer 6^m. After the resulting document has been sent to the inquirer, the request has been successfully processed.

However, the Service Manager Interface might decide to forward the query document to an alternative Service Manager instance running on a different NexusDS node. This might happen if e. g. the load situation prohibits the local processing of the query document 7^m. In this case the remote Service Manager performs steps 1^mto 7^m, as described above, instead of the Service Manager the document was originally sent to. It is important to note that the inquirer always receives the resulting document by the original Service Manager instance the query document was sent to. This is because the interaction between the inquirer and the service being invoked is synchronous. The same also holds for inter-service communication.

3.5.1.1 Direct Service Invocation

All services in NexusDS have the same interface. This applies in particular to the SM, which however is a special service managing the life cycle of services. Nevertheless, the interface used for communication is the same as in other services. From this point of view all services are similar, although they differ in their implementation details. Besides applications, services can send query documents to (other) services when necessary. This means that beside service invocation using the Service Manager, applications and services can also directly invoke other services. This is useful if a certain service instance on a specific NexusDS node should receive the query document instead of (from an inquirer’s point of view) an arbitrary service instance.

Each time the Service Manager Interface instantiates a service, the service also registers itself at a globally accessibleservice registry, the Service Repository Service. Thus, an application or services can query the Service Repository Service to get the endpoint information of a specific service instance and directly send a query document.

Two basic communication principles are possible, indirect communication anddirect com-munication. The indirect communication is performed by sending the query document to an arbitrary Service Manager instance running on a NexusDS node. The Service Manager delivers the document to the correct endpoint. Alternatively, thedirect communicationis performed by querying the Service Repository Service about available service instances of interest, directly sending the document to them. This communication mechanisms allows direct interaction with a specific service instance and implements a loosely coupled interconnection of services according to the SOA principle described in Section 2.5.6.

An example for the direct communication pattern is between the Core Graph Service and the Operator Execution Service. The Core Graph Service receives a NPGM SP graph which must be transformed into an NEGM SP graph. The NEGM SP graph is then directly sent to the

Operator Execution Service instances involved in the processing. Thus, both communication mechanisms are needed in order to make the services work properly. Other communication patterns are also possible, mainly depending on the actual service.