This paper describes an alternate three-tiered architecture, coupled with an adaptive light reusable middleware component (RIKA). The paper identifies several significant issues with the standard three-tier model and proposes a solution via an alternate three-tier model that makes use of the adaptive component. Finally, the paper highlights the role of RIKA in mitigating these problems within the alternate architecture.
Heterogeneous distributed computing, multi-tiered architecture, middleware, RIKA, XML-RPC, HTTP.
In recent years there has been a dramatic growth in distributed computing environments. Unfortunately, the size and variety of heterogeneous computer systems make distributed computing difficult and complex [1]. Thanks to improvements in computer technology, the problem of size can be dealt with by separating systems into two roles, namely client and server. Clients seek information from a remote server, which offers services that produce information for the clients. However, there is a wide variety of computing systems with different architectures and different operating systems. Interoperability is the key to mitigating the problem of heterogeneity. To make systems interoperable, middleware is usually required. Middleware is software that ewraps upf the architectural details of a system and offers services to other systems on heterogeneous platforms across a network [2].
Middleware can be used as a bridge between client and server. The client / server architecture consists of two, three or more tiers. In general, the logic of two-tiered and three-tiered architectures is intrinsically different, but the three-tiered and multi-tiered architectures are basically the same. Responsibility for application specific tasks can be minimized in each tier, and the roles can be separated into each tier. This helps to ensure low coupling between tiers, with high cohesion within each tier. The two-tiered architecture suffers from scalability and modularity issues, hence a multi-tiered approach is best.
Unfortunately both the multi-tiered architecture and the use of middleware have disadvantages. As the number of tiers increases, the cohesion of each tier increases, but the coupling between tiers does not decrease ? a change to one tier will affect neighboring tiers. Having more than three tiers causes coupling and test issues. Each tier has its own role that can be easily tested, but testing the entire system becomes increasingly complex as the number of tiers increase. Furthermore, existing middleware protocols only achieve limited interoperability, while suffering from reduced portability and greater design complexity.
This paper proposes a two-pronged strategy. An alternate Three-Tiered architecture is proposed to tackle some of the client / sever architecture issues. A generic software component called RIKA (Reusable Interoperable Komponent Architecture) is proposed to solve middleware problems and improve the heterogeneity issues.
The standard three-tiered architecture consists of the presentation, application and data access tiers. The main problems encountered with the three-tiered model arise from the separation of application and data access. The problem is many applications require a high coupling between the bottom two tiers. For example if a vendor-specific relational database product is used in the data access tier, the interface to the product is usually called ODBC (Object DataBase Connectivity) . In addition to the ODBC, driver software is required to access a specific database. Therefore, changing database architectures dramatically affects the system at the application tier.
In the modified three-tiered architecture, the application tier and the data access tier in the traditional three tier model are combined into one tier, called the service tier. A new tier, known as the light-application tier, is then inserted between the presentation tier and the service tier. The role of the service tier becomes focused more on communicating with the database, and the role of the light-application tier focuses on handling concurrent access and communications with the service tier. The service tier handles concurrent accesses to the database instance and manages changes to the database. This service tier prepares a number of its own services that override methods or features of the database such as select, insert, create, and so on. It is the responsibility of the light-application tier to choose the appropriate service interfaces. Naturally, this service tier must include minimum-security issues regarding access to the client.
The light-application tier and the service tier are loosely coupled. The light application tier only cares about changes to the interfaces. Merging the application tier and the data access tier into the service tier resolves the coupling issues. This ensures that, no matter how the tiers are distributed, application and data access will always reside together in the same location.
RIKA is a client-side software component designed to be a flexible connector between the client and server. RIKA uses XML-RPC as the middleware protocol. RIKA can adopt any interfaces at any time, including the necessary data types and function (method) declarations. In another words, RIKA can adopt any services that the server offers to the component that deploys RIKA. RIKA implements XML transfer functionality. It allows flexibly changing the structure of XML that the client expects. This is called the RIKA mapping. To perform its role, RIKA requires information about the service. The information can be specified in a service configuration file, the format of which is XML with a schema defined by the RIKA component.
Figure 3 shows a model that uses RIKA in the modified three-tiered architecture.
Page limitations prevent a detailed discussion of how RIKA is implemented and used. However, a detailed description will shortly be published elsewhere [3].
The work presented here has examined some of the problems of heterogeneous distributed computing, especially those of the multi-tiered architecture and of middleware. A modified three-tiered architecture with RIKA was introduced as the solution for the problems identified.
Under the standard three-tiered model, the application tier and the data access tier are tightly coupled because of the database vendor dependency. The suggestion made here is to merge these tiers together (thus resolving, at least partly, the coupling issues). A new tier, known as the light-application tier then acts as a bridge between the presentation and service tiers. This solution increases the cohesion of each tier and prevents the overall system from becoming overly complex. However, to solve coupling issues with other tiers, there needs to be a mechanism that can adjust to changes in the interfaces at each tier. The mechanism proposed here is the RIKA component.
The advantages of using a system such as RIKA are improved interoperability between different systems, and portability that allows a system to connect and communicate with any other system. The roles of the system are separated into that of the service provider and the user of the service. This allows the service provider to concentrate on maintaining it services, and delegate the responsibility for adjusting to service changes to the user of the service. RIKA offers an easy way to adapt to the changes. This increases cohesion of the system and reduces the coupling between systems.