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.
In SaaS applications, which are mainly built following a multitenant architecture, the support of service variability among tenants is limited. It is due to the principle of sharing the same instance of the SaaS service between the tenants; thus, the particularities of each tenant's needs are not considered. Having to customize and adapt a SaaS service to tenants' needs and their specific contexts, while maintaining multi-tenancy, has emerged as a persisting challenge. The SaaS service adaptation has not only to be according to the functional requirements of the different tenants, but it has also to cope with the non-functional requirements in their various levels that are subject to change in time and space: i.e. within the same tenant and between tenants, respectively. 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. Software Product Lines Engineering (SPLE) has largely tackled the variability management field in the literature. It enables high reusability in shorter time, at lower costs and with higher quality by creating product families or lines that share commonalities and have variation points. The derivation of the final product is performed at the level of those variation points while considering the interand intra-dependencies between the artifacts of a product line. Our proposed approach is based on the SPLE principles to build SaaS services tailored to tenant-specific Service Level Agreements (SLAs). We defined the Domain Engineering phase to build SLA families. Based on domain analysis, the non-functional requirements of
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.