The support of multi-tenancy is an essential requirement for leveraging the full capacity of Cloud computing. Multi-tenancy enables service providers to maximize the utilization of their infrastructure and to reduce the servicing costs per customer, which benefits customers too and in addition allows them to reap the advantages of Cloud based applications configurable for the needs of different tenants. Nowadays, new applications or services are typically compositions of multiple existing services and Service Composition Engines (SCE) provide the required functionality to enable their definition and execution. Support of multi-tenancy of service compositions still remains an unsolved issue. Towards the goal of enabling multi-tenancy of service compositions, we identify the need for a middleware capable of enabling such compositions. Therefore, we define a general architecture for the realization of a multi-tenant SCE solution. This architecture is prototypically realized based on an open-source SCE implementation and integrated into an existing multi-tenant aware Enterprise Service Bus (ESB). The resulting middleware provides configurability of service compositions, tenant-aware communication and tenant-based administration and management of the SCE and the ESB.
Figure 1 shows the general architecture of our approach with its two components: a SCE Multi-tenancy Manager (SCE-MT Manager) and the Multi-tenant Service Composition Engine (SCEMT). The main goal of the approach is to provide as much as possible of the multi-tenancy functionality in a reusable way by outsourcing it to a new middleware component, namely the SCE-MT Manager. This component acts as a Multi-tenancy Enablement Layer and provides a surrounding container for a set of potentially different SCE implementations. Therefore, in the best case the SCE implementations must only be adapted to integrate with the SCE-MT Manager to become multi-tenant aware without providing all the required functionality on their own.
The Integration Layer enables the communication between the SCE-MT Manager and the set of connected SCE instances over a Web Service or a Messaging Application Programming Interface (API).
The Data Access Layer contains a variety of External Registry Clients which enable the integration of different external registries, like the Service Registry, the Tenant Registry or the Configuration Registry (see Figure 1). The Service Registry is used to independently store the Deployment Bundles (collection of process models (e.g. BPEL), service descriptions (e.g. WSDL), data type definitions (e.g. XML Schema)) of all tenants. The Tenant Registry stores all tenant related information (e.g. authorization and authentication data) and therefore enables the management of tenants and their users. Furthermore, the contained tenant data is used in all other registries to uniquely assign a resource (e.g. services, configuration data) to a tenant. The distributed Configuration Registry holds tenant-based configuration data. For example, configuration data for process models or a SCE instance registered by a tenant.
The Application Layer contains a set of modules where each module complies with a different requirement to provide multi-tenancy support for the connected SCE implementations. The Security module contains all security related functionality and enables Communication Isolation, like the authentication of incoming requests. Furthermore, it realizes Administration Isolation by the authentication of any access to the Configuration Registry or the Service Registry. The Configurability module handles the management of tenant-based configurations. The Scalability module provides functionality to enable scaling out SCEMT. This contains for example the automatic allocation/deallocation of SCE instances based on the current workload. The Performance Isolation module provides some functionality to analyze the performance of all registered SCE instances (e.g. based on event data) and potentially reject new incoming requests of a tenant if he exceeds his quotas.
As described above, the SCE implementations have to be adapted to integrate with the SCE-MT Manager (see Figure 1). In the following we focus on the new or adapted components. The Message Exchange Processor handles the correct routing of incoming and outgoing messages to their corresponding services (process models). This component must be extended to enable tenant-aware communication in both directions. This means the tenant information assigned to an incoming message should be forwarded to the underlying layers and tenant information should be added to each outgoing message to identify the tenant it belongs to. In addition to that, the two engine databases shown in Figure 1 should be extended to store any tenant-specific data (e.g. process models, configurations) in a tenant-isolated manner. The Application Layer must be adapted to support the tenant-based configuration of the SCE and process models. Therefore, the Configuration Manager is introduced which provides the required functionality to configure the SCE and its process models on a tenant basis. The SCE-MT Manager uses the Configuration Interface to invoke the internal configuration logic provided by the Configuration Manager from the outside. To enable the correlation of tenant-aware message exchanges and provide Communication Isolation, the Correlator has to be extended. The Process/Instance Manager component has to be extended to enable the authentication and authorization of any calls of the Management Interfaces. We decided to realize this inside the engine to be able to provide fine-grained access permissions on an operation-level in a future version of our realization. But it would be also possible to provide this functionality over the SCE-MT Manager.
Figure 2 shows the overall architecture of our SCEMT realization. Instead of implementing the complete functionality to provide multi-tenancy support for the SCE on our own, we integrate and reuse two existing middleware components. The use of a multi-tenant aware Enterprise Service Bus ESBMT – developed at our institute – provides us Communication Isolation for the (process model) services exposed by the SCE. ESBMT is based on the open source Enterprise Service Bus implementation Apache ServiceMix version 4.3.0 (ServiceMix). Furthermore, we use the powerful integration and routing capabilities of the ESB to connect all components (SCE-MT Manager, SCEMT and JBIMulti2; see Fig. 2) and to hide the complex structure of the integrated system from the users at the same time. Since we also need a secure administration and management interface for the SCE, for example to register configuration data of process models, we extended JBIMulti2 – a tenant-aware web application for the administration and management of JBI environments which is provided with ESBMT.
As in the original ESBMT setup, all registry components are realized based on PostgreSQL version 9.1.1. We added a new Event Registry which stores all event messages emitted by a SCE (e.g. during process instance execution) in a tenant isolated manner. The existing ConfigurationRegistry and ServiceRegistry are extended to store some new SCE and process model related data. The registries are also used to integrate the SCE-MT Manager with the JBIMulti2 application without having any duplicated data or the need to synchronize data between two separated sets of databases.
JBIMulti2 is extended to support the tenant-based administration and management of SCEs. Therefore, the Web Service API is extended with some new operations which are realized in the corresponding components of the Business Logic layer. For example, a new operation to register configuration data for a process model is added to the Web Service API and its implementation is added to the ConfigurationRegistryManager (see Figure 2). The new SCE-MT Manager Client enables the required communication with the SCE-MT Manager. For example if new configuration data for a process model is registered, a corresponding message is sent by the client to the SCE-MT Manager over its queue (see Figure 2, SCE-MT Manager Messages.queue).
The JMSManagementService OSGi Bundle is responsible for the installation/uninstallation and configuration of Binding Components (BC) and Service Engines (SE) and the deployment/undeployment of Service Assemblies (SA) and Service Units (SU) to those BCs or SEs in a JBI environment. All corresponding operations (e.g. installation, deployment) are performed through a set of standardized interfaces provided by Service Mix. We extended the functionality by enabling the feature-based installation/uninstallation of BCs and SEs using the interfaces provided by Apache Karaf which is included in ServiceMix.
The SCEMT realization itself is based on an extended version of the open source BPEL Engine Apache Orchestration Director Engine (ODE) version 1.3.5. The extensions are developed in the context of the ODE-PGF project and the SimTech project. ODE-PGF provides a standardized BPEL event model, ways to change the engine's internal behavior upon receipt of an event and the publishing of execution events over a messaging channel. In the context of the SimTech project, ODE-PGF was extended with adaptation and flexibility concepts to support the execution of simulation workflows. SCEMT is integrated as a JBI SE into the ESB by using the provided JBI Integration Layer of ODE. To provide multi-tenancy support in the used ODE version, we applied the identified adaptations and extensions introduced in our approach (see Figure 1) to the underlying implementation.
The SCE-MT Manager is realized as an OSGi bundle and is installed to the underlying OSGi platform on which ServiceMix is built on. Therefore, we detail and implement the three layer architecture introduced in our approach (as shown on the bottom left of Figure 2). The Messaging API is used to enable the communication between the SCE-MT Manager, JBIMulti2 and the connected SCEMT implementations. The SCE Manager module provides the required functionality to manage a dynamic changing set of SCE instances and their integration into the ESB during runtime, to support scalability in a future version. The Process Manager module is aware of the status of a process model and where it is actually deployed. As a result, a tenant user does not need to know on which SCE instance(s) its process models are deployed or his process instances are executed. The Event Manager stores all emitted event messages from any connected SCE instance into the new Event Registry to enable the later use of the event data. The Configuration Manager realizes the configuration of SCE instances and process models. Therefore, it collects the configuration data from the Configuration Registry and sends this data encapsulated in messages to a set of SCE instances.