Architectural Stability and Middleware : An Architecture-Centric Evolution Perspective

Architecture stability refers to the extent to which a software system can endure changes in requirements, while leaving the architecture of the software system intact. We argue that changes in non-functional requirements are critical to threat the stability of a software architecture over its projected lifetime. We claim that focusing the analysis on the “coupling” of middleware and software architectures is a step towards understanding the ramifications of the change in the so called middleware-induced architectures. Middleware-induced architectures follow an architecture-centric evolution approach, as the emphasis is placed on the induced architecture and the provided middleware primitives to simplify the construction of distributed systems, realize many of the non-functional requirements (e.g., scalability, fault tolerance, etc.) and facilitate their evolution over time. To support the claim, we use a case study and we observe how a software architecture, when induced by distinct middleware, differs in coping with changes in nonfunctional requirements. We conclude by hinting on future research directions in the area. 1. Architectural Stability and Middleware Software requirements, whether functional or nonfunctional, are generally volatile; they are likely to change and evolve over time. The change is inevitable as it reflects changes in stakeholders’ needs and the environment in which the software system works. The change may “break” the software system architecture necessitating changes to the architectural structure (e.g., changes to components and interfaces), architectural topology (e.g., architectural style), or even changes to the underlying architectural infrastructure (e.g., middleware). It may be expensive and difficult to change the architecture as requirements evolve [10]. Consequently, failing to accommodate the change leads ultimately to the degradation of the usefulness of the system. Hence, there is a pressing need for flexible software architectures that tend to be stable as the requirements evolve. By a stable architecture, we refer to the extent to which a software system can endure changes in requirements, while leaving the architecture of the software system intact. We refer to the presence of this “intuitive” phenomenon as architectural stability [1]. Ongoing research on relating requirements to software architectures has considered the architectural stability problem as an open research challenge and difficult to handle [7, 10, 13, 18]. van Lamsweerde [18] acknowledges that: “the conflict between requirements volatility and architectural stability is a difficult one to handle”. Nuseibeh [13] noted that many architectural stability related questions are difficult and remain unanswered. Examples include: what software architectures (or architectural styles) are stable in the presence of changing requirements, and how do we select them? What kinds of changes are systems likely to experience in their lifetime, and how do we manage requirements and architectures (and their development processes) in order to manage the impact of these changes? In [2, 7], we reflected on the architectural stability problem with a particular focus on developing distributed software architectures induced by middleware. Specifically, we considered the architecture stability problem from the distributed components technology in the face of changes in non-functional requirements. We argued that addition or changes in functional requirements could be easily addressed in distributed component-based architectures by adding or upgrading the components in the business logic. However, changes in non-functional requirements are more critical; they can stress an architecture considerably, leading to architectural “breakdown”. Such a “breakdown” often occurs at the middleware level and is due to the incapability of the middleware to cope with the change in non-functional requirements (e.g., increased load demands). This may drive the architect/developer to consider ad-hoc or propriety solutions to realize the change, such as modifying the middleware, extending the middleware primitives, implementing additional interfaces, etc. Such solutions could be problematic, costly, and unacceptable. We argue that changes in non-functional requirements are critical to threat the stability of the software architecture over its projected lifetime. We claim that “coupling” middleware with software architectures is a step towards understanding the ramifications of the change in distributed systems that are built on top of middleware. To support the claim, we observe how a software architecture, when induced by distinct middleware, differs in coping with changes in non-functional requirements. We hint on “tactics” that requirements engineering must consider to proactively engineer stable architectures to facilitate evolution of the system and its environment. 2. Middleware-Induced Architectures The requirements that drive the decision towards building a distributed system architecture are usually of a nonfunctional and global nature. Scalability, openness, heterogeneity, and fault-tolerance are just examples. The current trend is to build distributed systems architectures with middleware technologies such as Java 2 Enterprise Edition (J2EE) [17] and the Common Object Request Broker Architecture (CORBA) [14]. Middleware-induced architectures follow an architecture-centric approach to evolution, as the emphasis is placed on the induced architecture for simplifying the construction of distributed systems by providing high-level primitives, which shield the application engineers from the distribution complexities, managing systems resources, and implementing low-level details, such as concurrency control, transaction management, and network communication. These primitives are often responsible for realizing many of the non-functional requirements (e.g., scalability, fault tolerance, etc.) in the architecture of the system induced and facilitating their evolution over time. Despite the fact that architectures and middleware address different phases of software development, the usage of middleware can influence the architecture of the system being developed. Conversely, specific architectural choices constrain the selection of the underlying middleware [6]. Once a particular middleware system has been chosen for a software architecture, it is extremely expensive to revert that choice and adopt a different middleware or a different architecture. The choice is influenced by the non-functional requirements. Unfortunately, the requirements tend to be unstable and evolve over time and threat the stability of the architecture. Non-functional requirements often change with the setting in which the system is embedded, for example when new hardware or operating system platforms are added as a result of a merger, or when scalability requirements increase as a result of having to build webbased interfaces that customers use directly [8]. Hence, as the non-functional requirements of the software system evolve, “coupling” middleware and architectures becomes the focal point for understanding the stability of the distributed software system architecture in the face of the change. 3. Case Study: The Evidence We observe how a software architecture, when induced by distinct middleware, differs in coping with changes in nonfunctional requirements. The experiment is fully documented in [2]. We use the Duke’s Bank application, an online banking application provided by Sun [17], as part of the J2EE reference application. Given the software architecture of the Duke’s Bank, we have instantiated from the core architecture two versions, each induced by a different middleware: one with CORBA and the other with J2EE. We have observed how a likely future change in scalability could impact the architectural structure of each version. Scalability denotes the ability to accommodate a growing future load, be it expected or not. We look at the changes in scalability demands as a representative of a critical change in non-functional requirements that could impact the architecture at its various levels: structure, topology, and infrastructure. The ability to scale the software system of a given architecture is revealing to its stability, for the change may break the architecture and/or ripple to impact other non-functionalities such as faulttolerance, performance, reliability, availability, when poorly accommodated by the system. Further, the challenge of building a scalable system is to support changes in the allocation of components to hosts without breaking the architecture of the software system, or changing the design and code of a component [8]. We note that the stability notion is relative to the change. Hence, what we observe is how the architecture of the given system, when induced by a particular middleware cope with the scalability change. Though the experiment is conducted in a controlled environment, we regard the Duke’s bank application to be adequately representative of medium-size component-based distributed application. The architecture of the Duke’s Bank application is a 3-tier style, given in Figure 1. The architecture has two clients: an application client used by administrators to manage customers and accounts, and a Web client used by customers to access account statements and perform transactions. The server-side components perform the business methods: these include managing customers, accounts, and transactions. The clients access the customer, account, and transaction information maintained in a database.