Architecture Aware Data Management

Adaptability in Multi-tier Information Systems

Multi-tier architectures are now the standard for advanced information systems. The information system exports its functionality via business methods that, e.g., maintain a shopping cart, perform purchase transactions, or search for specific product information. Once a client has connected to the information system, it can call these methods as needed. The method execution takes place on an application server (also called middle-tier). All critical data is stored in a database system. Whenever a method has to access such data (retrieval or update), the application server makes the corresponding calls to the database system. The database system is called the backend-tier. In the current, web-centric world, a web-server is often placed between the client and the application server. In this case, clients are often web-browsers, and the web-server is responsible to accept the http requests, transform them to calls to the application server, and return the responses of the application server to the client in form of dynamically generated web-pages. A web-server is also considered a middle-tier component.

In the commercial world, J2EE, .NET, and CORBA are specifications for the middle-tiers of such multi-tier architectures. Application servers provide far reaching functionality and services that help in the development of information systems. Important services are various communication mechanisms (remote procedure calls, messaging systems, persistent queues, etc.), transaction management, security, access control, persistence, and many more.
The fact that application servers introduce an additional layer of complexity, and that both web and application servers use a wide range of new technology leaves us with many challenging problems.

Our research looks at several issues in regard to such multi-tier architectures:

Fault-Tolerance: 7/24 availability is crucial for many of these information systems. Hence, such systems must be able to handle the crash of individual components, e.g., the crash of the web-server, the applicatin server, or the database system. Ideally, such crash is transparent to the client, i.e., the client always receives exactly one response for each request it sends to the system. Furthermore, the crash of a component may not leave the system in an inconsistent state. Replication is widely used to provide such fault-tolerance. The idea is that servers are replicated and if one replica crashes the work assigned to this replica can failover to another replica. In principle, each tier can be replicated. We have several projects on database replication. Furthermore, we have developed replication strategies for application servers. Our work in this area consists of several parts:

Since an application server is not the last component in the multi-tier architecture but makes calls to the database backend-tier, any solution for application server replication must take the interaction between application server and database system, and the behavior of the database system into account. We analyze what interaction patterns exist between these components. In particular, we look at transaction management, and how the actions of transactions can affect both application server and database system.
We have to define what correctness means. This must be done from the perspective of the client, e.g., that he/she always receives an appropriate response to a request, and from the perspective of the application server and database system, e.g., the state they maintain should be consistent.
Based on the model and the correctness criteria we have developed algorithms that provide fault-tolerance in an efficient manner. Requests are executed by a primary server, and state changes are propagated to backup servers which can take over if the primary crashes. Execution at the clients, the primary, and the backups is carefully coordinated to provide the degree of correctness that is required.
We have implemented our algorithms witin a concrete application server architecture, namely the J2EE specification. Our replication tool is open-source and can be accessed via SourceForge.

Load Balancing: Replication cannot only be used for fault-tolerance. Since the work to be performed at backups is not as time consuming as the work at the primary, the backups can be primary servers for other clients. Hence, by adding new server replicas to the system we are able to handle more client requests. There are two main issues to handle. First, how to distribute clients over the server to optimally distribute the load. The second is how to maintain the system if replicas leave the system due to crashes or necessary maintenance, or join the system after recovery or as new replicas in order to increase system capacity. Such system configurations have to be performed in a transparent manner without interrupting ongoing processing in the system.
Fault-tolerance across the entire system: Even if each individual tier provides fault-tolerance mechanisms, e.g., through replication, it is not clear that the server system in its entirety provides fault-tolerance and correctness. We have analyzed how we can reason about the correctness of the entire system given fault-tolerant properties of the individual tiers. From there, we have derived interaction patterns that guarantee system-wide fault-tolerance.

Collaboration

Part of the work has been performed in the context of the Adapt project (Middleware Technologies for Adaptive and Composable Distributed Components). Adapt was a RTD project funded by the Information Sociaty Technologies Programme of the European Commision under FP5, and the Programme de soutien à la recherche (PSR) of the Ministère du Développement économique, de l'innovation et de l'exportation (MDEIE) du Québec, Canada.