Policy-Driven Middleware for Multi-Tenant SaaS Services Configuration

Introduction

Software as a Service (SaaS) applications are generally built based on the multi-tenancy architecture (Kabbedijk et al., 2015). This architecture style allows serving multiple tenants with a single instance of the application. Hence, it enables, among others, high utilization of resources, easy maintenance and cost efficiency. However, it limits the support of service variability among tenants, since the same instance of the SaaS service is shared between them and the particularities of each tenant’s needs are not considered. To cope with this, customization and adaptation techniques must be enforced to get SaaS services tailored to tenants’ needs and their specific contexts, while maintaining multi-tenancy.

Note that not only has the SaaS service to be adapted to functional requirements of the different tenants, but it has also to meet non-functional requirements in their various levels. In fact, the required service quality level may differ from a tenant to another. For example, a tenant can just require minimal security level as it needs solely to be authenticated and has no other security concerns; while another may require a high security level and advanced and supplementary security mechanisms such as access control and encryption. There are also situations when the same tenant changes its desired quality level through time; for instance, when there is an increase of service requests in a critical period, the tenant may want to decrease the response time and to increase the uptime value in order to smoothly perform his requests. Therefore, the application needs to be adapted dynamically in order to meet every tenant’s quality requirements as if he is the only one to consume the service.

However, configuring the service utterly for each tenant, at a time, is a heavy and tedious task for developers and architects. Thus, commonalities and variations among tenants regarding quality attributes should be first captured. This is one of the principles of Software Product Lines Engineering (SPLE) that enables high reusability in shorter time, at lower costs and with higher quality (Pohl et al., 2005). The SPLE paradigm allows creating product families or lines sharing commonalities and differing in some aspects. These aspects are generally represented as variation points, in most of the variability modeling languages, e.g. Feature Model (FM) (Batory, 2005), Orthogonal Variability Modeling (OVM) (Pohl et al., 2005), Extended Feature Model (Benavides et al., 2005), etc. In order to derive the final product tailored to specific needs, configuration and adaptation mechanisms are performed at the level of variation points while considering the dependencies between all the different artifacts composing the final product and the product line as well. SPLE involves two complementary phases: Domain Engineering and Application Engineering. Domain Engineering allows the management of a product line or family as a whole and not as individual products. It follows “for reuse” development strategy, starting by domain analysis to identify the commonalities and variabilities among the requirements, and aiming at defining the architecture of a product line, its reusable artifacts and the relationships and dependencies between them. Application Engineering, on the other hand, follows “by reuse” development strategy. In this phase the final products are derived by configuring the artifacts defined in the Domain Engineering phase to meet specific requirements. It allows also conformity checking to validate that the final derived product is conformed to the specific needs it intends to respond to.