Policy-Driven Middleware for Multi-Tenant SaaS Services Configuration

Policy-Driven Middleware for Multi-Tenant SaaS Services Configuration

Khadija Aouzal (SEEDS Team, STRS Lab, INPT, Rabat, Morocco), Hatim Hafiddi (SEEDS Team, STRS Lab, INPT, Rabat, Morocco & IMS Team, ADMIR Lab, ENSIAS, Rabat, Morocco), and Mohamed Dahchour (SEEDS Team, STRS Lab, INPT, Rabat, Morocco)
Copyright: © 2019 |Pages: 21
DOI: 10.4018/IJCAC.2019100105
OnDemand PDF Download:
No Current Special Offers


The multi-tenancy architecture allows software-as-a-service applications to serve multiple tenants with a single instance. This is beneficial as it leverages economies of scale. However, it does not cope with the specificities of each tenant and their variability; notably, the variability induced in the required quality levels that differ from a tenant to another. Hence, sharing one single instance hampers the fulfillment of these quality levels for all the tenants and leads to service level agreement violations. In this context, this article proposes a policy-driven middleware that configures the service according to the non-functional requirements of the tenants. The adopted approach combines software product lines engineering and model driven engineering principles. It spans the quality attributes lifecycle, from documenting them to annotating the service components with them as policies, and it enables dynamic configuration according to service level agreements terms of the tenants.
Article Preview


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.

Complete Article List

Search this Journal:
Volume 13: 1 Issue (2023)
Volume 12: 4 Issues (2022): 2 Released, 2 Forthcoming
Volume 11: 4 Issues (2021)
Volume 10: 4 Issues (2020)
Volume 9: 4 Issues (2019)
Volume 8: 4 Issues (2018)
Volume 7: 4 Issues (2017)
Volume 6: 4 Issues (2016)
Volume 5: 4 Issues (2015)
Volume 4: 4 Issues (2014)
Volume 3: 4 Issues (2013)
Volume 2: 4 Issues (2012)
Volume 1: 4 Issues (2011)
View Complete Journal Contents Listing