Dimitri Van Landuyt

Efficient customization of multi-tenant Software-as-a-Service applications with service lines

Application-level multi-tenancy is an architectural approach for Software-as-a-Service (SaaS) applications which enables high operational cost efficiency by sharing one application instance among multiple customer organizations (the so-called tenants). However, the focus on increased resource sharing typically results in a one-size-fits-all approach. In principle, the shared application instance satisfies only the requirements common to all tenants, without supporting potentially different and varying requirements of these tenants. As a consequence, multi-tenant SaaS applications are inherently limited in terms of flexibility and variability. This paper presents an integrated service engineering method, called service line engineering, that supports co-existing tenant-specific configurations and that facilitates the development and management of customizable, multi-tenant SaaS applications, without compromising scalability. Specifically, the method spans the design, implementation, configuration, composition, operations and maintenance of a SaaS application that bundles all variations that are based on a common core. We validate this work by illustrating the benefits of our method in the development of a real-world SaaS offering for document processing. We explicitly show that the effort to configure and compose an application variant for each individual tenant is significantly reduced, though at the expense of a higher initial development effort.

Building a Customizable Business-Process-as-a-Service Application with Current State-of-Practice

Application-level multi-tenancy is an increasingly prominent architectural pattern in Software-as-a-Service (SaaS) applications that enables multiple tenants (customers) to share common application functionality and resources among each other. This has the disadvantage that multi-tenant applications are often limited in terms of customizability: one application should fit the needs of all customers.

Domain-driven discovery of stable abstractions for pointcut interfaces

The benefits of defining explicit pointcut interfaces in aspect-oriented applications have been advocated by many. A pointcut interface exposes a set of crosscutting abstract behaviours (as named pointcut signatures) that multiple aspects in the application can use. In accordance with the dependency inversion and stable dependencies principles, a pointcut interface should expose only stable abstractions in order to maximally promote its reuse across a family of applications. In this paper, we propose a domain-driven architecture method for designing such stable pointcut interfaces. The method employs systematic reengineering of use case models to discover stable abstractions that are anchored in the domain model of the application. During architecture design, these stable domain abstractions are mapped to pointcut interfaces. As part of this mapping activity, the architecture is constrained to ensure that the pointcut interfaces can be implemented correctly. We have applied this method in two applications, where we validate that pointcut interfaces can be reused for implementing the composition logic of different aspects without requiring modification to their pointcut signatures. Moreover, the method consistently yields pointcut interface hierarchies.

Towards a container-based architecture for multi-tenant SaaS applications

SaaS providers continuously aim to optimize the cost-efficiency, scalability and trustworthiness of their offerings. Traditionally, these concerns have been addressed by application-level middleware platforms that implement a multi-tenant architecture. However, the recent uprise and industry adoption of container technology such as Docker and Kubernetes, exactly for the purpose of improving the cost-efficiency, elasticity and resilience of cloud native services, triggers the unanswered question whether and how container technology may affect such multi-tenant architectures. To answer this question, we outline our ideas on a container-based multi-tenant architecture for SaaS applications. Subsequently, we make an assessment of the technical Strengths, Weaknesses, Opportunities, and Threats (SWOT) which should be taken into account by a SaaS provider when considering the adoption of such container-based architecture.

Continuous evolution of multi-tenant SaaS applications: a customizable dynamic adaptation approach

Applying application-level multi-tenancy in Software-as-a-Service (SaaS) offerings yields a number of compelling benefits: sharing a single instance of the application between large numbers of customer organizations increases cost efficiency and allows the SaaS provider to attain true economies-of-scale benefits. There is however a main downside to this: increased sharing of resources causes the SaaS application to be very difficult to modify after initial development and deployment without affecting service continuity: any change potentially affects the service levels promised to all enrolled tenant organizations and their end users. This rigidity is a key impediment as now the SaaS provider must evolve and maintain the SaaS offering at run time, on a gradual, per-tenant basis. This in turn causes a reality of multiple co-existing versions of individual components and as such introduces substantial management complexity. To address these challenges, this paper motivates and defines key requirements that allows per-tenant, SLA-aware and gradual upgrades in the context of multi-tenant SaaS applications. In addition, we define an approach that allows the involved stakeholders (tenants, SaaS operators, SaaS developers, etc.) to customize the dynamic enactment of upgrades, and provide a number of alternative software upgrade strategies that represent different service quality trade-offs.

Variability middleware for multi-tenant SaaS applications: a research roadmap for service lines

Software product line engineering (SPLE) and variability enforcement techniques have been applied to run-time adaptive systems for quite some years, also in the context of multi-tenant Software-as-a-Service (SaaS) applications. The focus has been mainly on (1) the pre-deployment phases of the development life cycle and (2) fine-grained (tenant-level), run-time activation of specific variants. However, with upcoming trends such as DevOps and continuous delivery and deployment, operational aspects become increasingly important. In this paper, we present our integrated vision on the positive interplay between SPLE and adaptive middleware for multi-tenant SaaS applications, focusing on the operational aspects of running and maintaining a successful SaaS offering. This vision, called Service Lines, is based on and motivated by our experience and frequent interactions with a number of Belgian SaaS providers. We concretely highlight and motivate a number of operational use cases that require advanced variability support in middleware and have promising added value for the economic feasibility of SaaS offerings. In addition, we provide a gap analysis of what is currently lacking from the perspectives of variability modeling and management techniques and middleware support, and as such sketch a concrete roadmap for continued research in this area.

Documenting Early Architectural Assumptions in Scenario-Based Requirements

In scenario-based requirement elicitation techniques such as quality attribute scenario elicitation and use case engineering, the requirements engineer is typically forced to make some implicit early architectural assumptions. These architectural assumptions represent initial architectural elements such as supposed building blocks of the envisaged system. Such implicitly specified assumptions are prone to ambiguity, vagueness, duplication, and contradiction. Furthermore, they are typically scattered across and tangled within the different scenario-based requirements. This lack of modularity hinders navigability of the requirement body as a whole. This paper discusses the need to explicitly document otherwise implicit architectural assumptions. Such an explicit intermediary between quality attribute scenarios and use cases enables the derivation and exploration of interrelations between these different requirements. This is essential to lower the mental effort required to navigate these models and facilitates a number of essential activities in the early development phases such as the selection of candidate drivers in attribute-driven design, architectural trade-off analysis and architectural change impact analysis.

Object-NoSQL Database Mappers: a benchmark study on the performance overhead

In recent years, the hegemony of traditional relational database management systems (RDBMSs) has declined in favour of non-relational databases (NoSQL). These database technologies are better adapted to meet the requirements of large-scale (web) infrastructures handling Big Data by providing elastic and horizontal scalability. Each NoSQL technology however is suited for specific use cases and data models. As a consequence, NoSQL adopters are faced with tremendous heterogeneity in terms of data models, database capabilities and application programming interfaces (APIs). Opting for a specific NoSQL database poses the immediate problem of vendor or technology lock-in. A solution has been proposed in the shape of Object-NoSQL Database Mappers (ONDMs), which provide a uniform abstraction interface for different NoSQL technologies.Such ONDMs however come at a cost of increased performance overhead, which may have a significant economic impact, especially in large distributed setups involving massive volumes of data.In this paper, we present a benchmark study quantifying and comparing the performance overhead introduced by Object-NoSQL Database Mappers, for create, read, update and search operations. Our benchmarks involve five of the most promising and industry-ready ONDMs: Impetus Kundera, Apache Gora, EclipseLink, DataNucleus and Hibernate OGM, and are executed both on a single node and a 9-node cluster setup.Our main findings are summarised as follows: (i) the introduced overhead is substantial for database operations in-memory, however on-disk operations and high network latency result in a negligible overhead, (ii) we found fundamental mismatches between standardised ONDM APIs and the technical capabilities of the NoSQL database, (iii) search performance overhead increases linearly with the number of results, (iv) DataNucleus and Hibernate OGM’s search overhead is exceptionally high in comparison to the other ONDMs.

Towards managing variability in the safety design of an automotive hall effect sensor

This paper discusses the merits and challenges of adopting software product line engineering (SPLE) as the main development process for an automotive Hall Effect sensor. This versatile component is integrated into a number of automotive applications with varying safety requirements (e.g., windshield wipers and brake pedals). This paper provides a detailed explanation as to why the process of safety assessment and verification of the Hall Effect sensor is currently cumbersome and repetitive: it must be repeated entirely for every automotive application in which the sensor is to be used. In addition, no support is given to the engineer to select and configure the appropriate safety solutions and to explain the safety implications of his decisions. To address these problems, we present a tailored SPLE-based approach that combines model-driven development with advanced model composition techniques for applying and reasoning about specific safety solutions. In addition, we provide insights about how this approach can reduce the overall complexity, improve reusability, and facilitate safety assessment of the Hall Effect sensor.

The OCareCloudS project: Toward organizing care through trusted cloud services

The increasing elderly population and the shift from acute to chronic illness makes it difficult to care for people in hospitals and rest homes. Moreover, elderly people, if given a choice, want to stay at home as long as possible. In this article, the methodologies to develop a cloud-based semantic system, offering valuable information and knowledge-based services, are presented. The information and services are related to the different personal living hemispheres of the patient, namely the daily care-related needs, the social needs and the daily life assistance. Ontologies are used to facilitate the integration, analysis, aggregation and efficient use of all the available data in the cloud. By using an interdisciplinary research approach, where user researchers, (ontology) engineers, researchers and domain stakeholders are at the forefront, a platform can be developed of great added value for the patients that want to grow old in their own home and for their caregivers.