A Layered Architecture based on Java for Internet and Intranet Information Systems

Fidel CACHEDA, Alberto PAN, Luca ARDAO, ngel VIA Departamento de Electrnica y Sistemas Facultad de Informtica, Universidad de A Corua Campus de Elvia s/n, 15071 A CORUA Telephone: +34-981-167000 Ext. 1323 Fax: +34-981-167160 Email: {fidel, alberto, lucia, avc}@gris.des.fi.udc.es
Abstract. In this paper we present an architecture for building Information Systems that can be adapted to several runtime environments. Our architecture is structured in three layers: client, services and data layers. All the layers are independent, making the system more flexible and scalable. The core of the IS is implemented in Java to make possible platform and database independence. One of the most popular Spanish Internet Search Directories: BIWE (http://www.biwe.es), implements this architecture.

1. Introduction Since the World Wide Web started at CERN in 1991 its growth has been incredible, owing to the large amount of heterogeneous information (i.e. personal Web pages, research publications, etc) that can support. One of the main factors that has contributed to the growth of the Internet have been the Information Systems (ISs). An IS is an organized combination of people, hardware, software, communication networks and data resources that collects, transforms and delivers information [1]. The importance of handling the information has forced many enterprises and organizations to use these systems (ISs) to manage their Intranet and Internet services. The ISs solve the problem of the continuous information updates, by the dynamically generation of the information, avoiding the impression of obsolete information. Nevertheless, an important characteristic of current ISs is the possibility of adaptation to several runtime environments. This characteristic lets the same IS be valid for Internet and Intranets, and even for very dynamic environments where the number of users, the amount and type of information is continuously changing. Here we present a multi-platform architecture for ISs that allows system adaptations, creating a flexible and scalable IS. Also we present an implementation example of the architecture in a Spanish Internet Search Directory called BIWE. In the next section we describe the objectives we want to obtain with this architecture. In Section 3 we explain the different layers of the proposed architecture to describe in Section 4 the implementation. In Section 5 we describe the industrial benefits of our architecture and in Section 6 we show several configurations for the implementation BIWE. Finally we expose the conclusions obtained from the implementation of our architecture. 2. Objectives We believe that an IS suitable for different and changing environments should address the following basic requirements:

Platform independence: The system should support different Operating Systems (OS) in order to obtain an IS adaptable to any kind of environment. This will allow, for instance, run a low-loading service on an ordinary PC running Windows, while a highloading service could run on a high-performance UNIX server. Database independence: Directly related to the previous requirement, to achieve a total independence, the IS should avoid any restriction with the database management system used in each environment. Both requirements are useful when the system is purchased by third-party entities since the system will seamlessly run in the environment of the buyer entity (consider environment equivalent to operating system and database management system). Protocol communication independence: An IS should be designed to use any communication protocol with clients and any language as user interface. Therefore, an IS could choose the more suitable user interface for each environment. Extensibility: The system architecture should give support for adding easily new services and features. Also, the IS should allow its users to develop their own services (apart from the existing services), without knowledge about the internal working of the system, just using open frameworks on which all the services are based. Scalability: The IS should provide a layered architecture that can be distributed in different ways depending on the system requirements and the network configuration of its environment. This will let the system give a better performance to different environments and be prepared to support the changes of the system requirements (think that in Internet it is usual that a successful service could increase its number of users in a factor of 10 or even more).

3. Description of the architecture Nowadays the most commonly used architecture for the development of ISs in Internet is a three-layer architecture [4]. The proposed architecture is built on a data layer, a services layer and a client layer. The connection between the layers can be done through a network, it does not have to take place in the same machine. In the Figure 1 we can see a diagram of the architecture with its the different layers and interconnections.

Figure 1: The high-level architecture diagram

The data layer includes all the elements of the system that store data in a physic device. The data layer is composed by a database management system, although any other storage system that can interchange information with the next layer according to the specified interfaces could be used. The tasks of this layer are to store, update and retrieve data, creating a central point for any data access. The connection with the services layer is a

key issue because the attainment of total independence between both layers is an aspect very important. The independence between these layers means that the IS will be able to change the database management system (the core of the data layer) without any changes in the services layer. There are many different types of interfaces between databases and services (ODBC, JDBC, PL/SQL, etc.) but we will deal with this subject in the next section. The main task of the services layer is to provide all the services requested by the client layer using, if it is necessary, the data layer for accessing stored information. The services layer is the more complex and important part of the architecture, from the point of view of the independence among the other layers. The elements of this layer are a Web server, a set of services, a Data Access Framework and a Graphic Interface Framework (see Figure 2).

Figure 2: The services layer diagram

The services are provided by a Web server, (the better way to offer services over Internet or Intranets), that is the interaction point with the client layer. The Data Access Framework is the single element of this layer that interacts with the data layer, so it is the central point for any access to information stored in the database. Furthermore, this element isolates logic changes of the database to the rest of services layer to obtain transparency with the database. The Graphic Interface Framework must generate the HTML code that is sent to client layer over Internet. For this purpose, this element is divided in two components: a basic component that generates the HTML code, and a more complex component that takes data structures from the data layer and uses the basic components to generate a graphic interface to be used by all services. Using this functionality, this framework, which for a Internet IS uses HTML to generate the graphic interface, could generate any other type of communication language suitable for other kind of system (i.e., PDF), and the rest of the services layer would not need any changes. Of course, the client layer should be able to interact using this new standard of communication. Finally, the client layer interacts with the services layer and it is the interface between users and services. In our system, this layer will be composed basically by a Web browser that allows users to see the results of their requests to the different services. This layer would be present for all the users, but at the same time is the simplest layer. In any case, this layer can be more useful if it could be able to execute services that come directly from the services layer over the network. This means that the client layer will have a part of the services layer running on its same machine. But not all the services will go to this layer, just

specific services that can be executed there. These services will not need any interaction with the Graphic Interface Framework since they are just applications running in the client side, but they may need to interact with the Data Access Framework. This interaction can be done by two different ways: taking the Data Access Framework to the client layer (so the Data Access Framework accesses the data layer through Internet) or interacting with the Data Access Framework directly through Internet [3]. In the Figure 3 we show the first configuration for the client layer.

Figure 3: The client layer diagram

From a generic point of view, the main advantage of this architecture is the flexibility provided by the independence between the different layers. This means that the core of the IS could be located in several computers (we will see an example of this configuration in section 6). And moreover, this flexibility also improves the robustness of the system due to services and/or data can be replicated in different computers, obtaining a fault tolerant system. More specifically, this architecture forces the services to access the data layer through the data access interface, which makes possible to perform many changes on the database without having to change the services, just the Data Access Framework. In the same way, as the services use the Graphic Interface Framework to generate the graphic interface, the client layer could use any other type of language instead of HTML only having to change this framework. Another advantage of this architecture is the fact that the data access and the graphic interface components are both frameworks, so developers can design new services without having to know anything about the data and the client layers. Moreover, external users could develop their own services using these frameworks distributing the service layer over many different servers.

4. Implementation At this point, we summarize the main implementation decisions. Our decisions point at achieving OS and database management system independence. In the data layer a relational database has been used, and the independence of the database access has been achieved using the JDBC 1.0 API. For the implementation of the Internet Search Directory BIWE, we have used Oracle 7.3.3 database management system and the Weblogic JDBC1.0 driver for Oracle. The services layer has been written in JAVA. The services have been mainly implemented as JAVA servlets instead of traditional CGIs. All the system administration is

centralized in a JAVA applet and some administration services have been implemented as standalone JAVA applications. Now, we detail the reasons for the decisions above. JAVA language was chosen mainly because of its platform-independence feature. Other JAVA features that were considered useful for our implementation were the following: JAVA is an Object-Oriented language. This allows an easy and natural implementation of our object-oriented architecture. Multi-threading support in JAVA is very flexible, easy to program and of good efficiency for our purposes. JAVA is quickly becoming the "de facto" standard for building distributed applications on Internet. There is already an important number of developed and on-going efforts for enhancing the development of distributed applications in JAVA. JAVA servlets were chosen as the main way to implement front-end services because of their advantages over traditional CGIs: Servlets are a standard way of executing server-side JAVA programs. So with them we achieve both platform independence and web server independence (as long as the main web servers in the market already provide servlets support). Servlets allow multi-threading. They are loaded in memory only once and launch a different thread for each request, which is more efficient than the execution of a CGI. We chose a relational database system because it provides a reliable, efficient and robust access to data along with facilities for creating secure infrastructures. For accessing to the relational database, JDBC has been used to achieve platform and database independence. Nevertheless, it is important to point that, like other database independent methods for accessing data (as ODBC), JDBC can be slower than native database-dependent methods. So, for services where efficiency could be critical we recommend establishing a test planning to know whether the difference is actually relevant in that specific case or not. In our system, the results obtained of the tests showed that the difference was irrelevant for our system and it also let us presume that in very few systems it could make a difference. In any case, our object-oriented design would let us seamlessly create child classes of the currently used classes for accessing the database, in a way that those services which needed to use native interfaces to the database could do it without changing the programming interface.

5. Industrial benefits An IS based on this architecture can be implemented in different Operating Systems and can also use different database management systems without any changes on the system. This means that the system can be installed in any enterprise using the hardware and software available. At the same time, the system could start with a reduced investment, and later, using its distributed characteristics could increase the performance with a light improvement of the equipment. Another important benefit of this architecture is that users (or customers) can develop their own services using the open frameworks of the IS. This implies that third-party entities can adapt themselves easily the IS to its new requirements. All these benefits mean that the ISs developed using this architecture are immediately exportable to third-party entities (enterprises, institutions, etc.) because of their easy adaptation to any environment and to new requirements.

6. Architecture Configurations Two main elements of our Internet Search Directory are: It can work with any database management system with an available JDBC driver. It can work with any Web server with JAVA servlets support. These features along with the capability of distributing the architecture layers in one or several computers, make possible a lot of valid configurations. Now we detail two of them we have implemented and tested on our Search Directory. 6.1 Configuration I: 2 layers - 1 computer This is the simplest configuration, where the data layer and the services layer run on the same machine. We are using a Sun Microsystems Ultra Sparc 10 with one processor running at 300 MHz and 256 Mbytes of RAM. From the software point of view, the OS is Solaris 2.5.1, we use Oracle 7.3.3. as database management system and SUN Java Web Server 1.2.

Figure 4: The configuration I diagram

This is the configuration that is being used now in the production system. Though the system answers more than a million queries per month and that we are using low-cost hardware, the system keeps fast response times, even with high load situations. The main advantage of this configuration is: The reduced cost and the high performance obtained. The disadvantages of this configuration are: The reduced ability of the system to grow once the maximum capacities of the computer are reached. The Internet Search Directory is low protected since all the information system core layers are exposed to attacks through Internet. 6.2 Configuration II: 1 layer - 1 computer This configuration tries to make use of the characteristics of the architecture proposed. The main aspect of this configuration is that the data and the services layer are in different computers, and also in different operating systems. In this configuration the data layer is placed in a Sun Microsystems Ultra Enterprise 3000 with two processors at 167 MHz. and 256 Mbytes of RAM with the operating system Solaris 2.5.1. From the software point of view, this layer uses the same database management system used as in the previous configuration, Oracle 7.3.3. The services layer is placed in a less powerful computer, a Pentium with one processor at 166 MHz. and 64 Mbytes of RAM with Linux as the main operating system. In this case, the software requirements are different from the previous case. Now we use the Apache Web server and Jrun Servlet Engine to support all the services developed as servlets. Both computers are in the same LAN.

Figure 5: The configuration II diagram

The purpose of this configuration is to divide the workload of the Search Directory. This is the reason why the database management system is located in a powerful computer: the main workload of the system is located in the database access as result of the multiple information requests done by users at the same time. On the other hand, the services layer processes the results obtained by the data layer, so its requirements are fewer. The advantages of this configuration are: The performance obtained by the Internet Search Directory is much higher. The system is more secure because it is possible to install a firewall that just isolates the computer with the service layer, keeping the data layer in a secure environment. The main disadvantage of this configuration is: The system is not as fault tolerant as in the previous configuration, because the correct functioning of the Search Directory depends on two different computers and the connection between them.

7. Conclusions We have presented an architecture for building ISs adaptable to different environments. Our architecture is structured in three layers and aims to provide with scalability, extensibility, efficiency and platform independence (both, OS and database independence). Our first working system following this architecture is BIWE, one of the most popular Spanish Internet Search Directories. BIWE has been implemented in JAVA, using JDBC 1.0 for accessing to an Oracle 7.3.3 database. JAVA servlets have been used for building services on the services layer. Using this architecture and implementation we construct two different configurations for BIWE. The first one is simple and of low cost, but at the same time has a very high performance. The second one uses the advantages of the architecture to make a more distributed and efficient system, obtaining a high performance improvement, showing how easily the performance of the system can be increased. Future researches around the architecture proposed will try to distribute the different layers of our IS. We will start distributing the data layer, then the services layer and finally we will distribute both, the data and services layers.

References [1] J. A. OBrien, Introduction to Information Systems. An Internetworked Enterprise Perspective, Second Alternate Edition, Ed. Irwin/McGraw-Hill, ISBN: 0-256-25196-7 [2] V.N. Gudivada et al., "Information Retrieval on the World Wide Web", IEEE Internet Computing, Vol. 1, No 5, Sept. 1997, pp 58-68. [3] A. Puliafito, O. Tomarchio, L. Vita and K.S. Trivedi, "Increasing application accessibility through Java", IEEE Internet Computing, Vol. 2, No 4, July 1998, pp 70-87. [4] G. Wiederhold, "Mediators in the Architecture of Future Information Systems.", IEEE Computer, March 1992, pp 38-49.