The Resources layer consists of a JBI Container Instance Cluster and a set of registries. The JBI Container Instance Cluster bundles together multiple JBI containers for purposes of performance improvements, see figure on architecture of an ESB instance below. Realizing multi-tenancy on this level means that both BCs and SEs are able to: handle service units and service assemblies containing tenant and user-specific configuration information, and process such deployment artifacts accordingly in a multi-tenant manner. For example, a new tenant-specific endpoint has to be created whenever a service assembly is deployed to this JBI component in order to ensure data isolation between tenants. The installation/uninstallation and configuration of BCs and SEs in a JBI Container Instance is performed through a set of standardized interfaces that also allow for backward compatibility with non-multi-tenant aware components. In terms of implementation technologies, ServiceMix is based on the OSGi Framework. OSGi bundles realize the ESB functionality complying to the JBI specification. The original ServiceMix BC for HTTP version 2011.01 and the original Apache Camel SE version 2011.01 are extended in our prototype in order to support multi-tenant aware messaging.
The Resources layer also contains three different types of registries: the Service Registry stores the services registered with the JBI environment, as well as the service assemblies required for the configuration of the BCs and SEs installed in each JBI Container Instance in the JBI Container Instance Cluster in a tenant-isolated manner; the Tenant Registry records the set of users for each tenant, the corresponding unique identifiers to identify them, as well all necessary information to authenticate them; finally, the Configuration Registry stores all configuration data created by tenants and the corresponding users, except from the service registrations and configurations that are stored in the Service Registry. Due to the fact that tenant or user actions affect more than one registries at the time, all operations and modifications on the underlying resources are implemented as distributed transactions based on a two-phase commit protocol to ensure consistency. The ServiceRegistry, TenantRegistry, and ConfigurationRegistry components are realized based on PostgreSQL version 9.1.1.
The Business Logic layer contains an Access Layer component, which acts as a multi-tenancy enablement layer based on role-based access control. The identification of tenants and users is performed based on unique tenantID and userID keys assigned to them by the Access Layer. The various Managers in this layer encapsulate the business logic required to manage and interact with the underlying components in the Resources layer: Tenant Registry, Configuration Registry, and Service Registry Managers for the corresponding registries, JBI Container Manager to install and uninstall BCs and SEs in JBI Containers in the cluster, and Service Assembly Manager for their configuration through deploying and undeploying appropriate service artifacts. The Business Logic layer of the proposed architecture is implemented as a Web application running in the Java EE 5 application server JOnAS version 5.2.2.
The Presentation layer contains the Web UI and the Web service API components which allow the customization, administration, management, and interaction with the other layers. The Web UI offers a customizable interface for human and application interaction with the system, allowing for the administration and management of tenants and users. The Web service API offers the same functionality as the Web UI, but also enables the integration and communication of external components and applications. It is realized based on the JAX-WS version 2.0.
The deployment and configuration of ESBMT are based on the automation platform Opscode Chef. Thus, it can be installed and configured in a virtual machine with or without usage of the 4CaaSt platform. A manual provides step-by-step guidance on how to deploy and configure ESBMT including information on how to set up accounting and monitoring is publicly available at ESB_MT_manual.pdf.
ESBMT has been validated by applying it to the Taxi Application scenario, which is a use case stemming from the EU project 4CaaSt. The video below introduces the architecture of the Taxi Application and demonstrates its usage.