Migration to Multitier Application Architecture: A Case Study

Mirta Baranović, Ladislav Mačkala Faculty of Electrical Engineering and Computing, University of Zagreb Unska 3, HR-10000 Zagreb, Croatia [email protected], [email protected] and Denis Kranjčec University Computing Centre (SRCE), Zagreb Marohnićeva bb, HR-10000 Zagreb, Croatia [email protected]

Abstract. During the migration of an and voice service (Studophone) have been application to a new system, it is usually introduced to facilitate the administrative desirable to start using new tools while keeping procedures to all the involved parties. The existing models. However, challenges brought by system was based on the Informix RDBMS with new often lead to modifications in applications written in INFORMIX-4GL. architecture of the existing system. for Studomat was written in Visual Two similar applications with different Basic, while software for Studonet was created architecture not sharing the same code base later using CGI, HTML and JavaScript present a possible point of improvement. technologies. Development of a new multi-tier application Migration to modern technologies is based on open standards was an attempt to solve achieved by design of a completely new system. problems brought by old architecture. Special Character based user interfaces are replaced with attention was given to implementation of specific graphical ones, programming language is feature of existing applications. Quality solution used, and so is JavaScript in combination with was achieved using stable platform and design HTML and XML technologies. Although, the patterns. first goal of migration to new technologies is to keep existing architecture and to add a small Keywords. , Application number of new features, most often it is Migration, . impossible to resist the challenges that new brings. Modified architecture of this 1. Introduction new system combined with aforementioned technologies will allow, among other things, Computerization of the system of high integration of Studomat and Studonet education in the Republic of Croatia [2] is a applications that will simplify the code project that started at the end of 1998. It is large maintenance and improve the scalability of the in size and complexity and requires a number of system. years to be completed. The project is based upon the experience gathered since 1992 on a similar 2. Old Studomat/Studonet application project implemented on the Faculty of Electrical Engineering and Computing (FER) of the Applications that had been developed in the University in Zagreb [1]. This implementation old system enabled the students’ interaction with covers a complete evidence of syllabuses, the the Faculty administration. Information became educational program fulfillment, course more available to the students and the and all the students' activities, starting administrative tasks became easier to achieve. from the entrance examination, education and examinations to the graduation thesis and issuing 2.1. Functionality of graduation certificate (diploma) and its supplement with the evidence of the student's The basic idea was to install the application performance. on a kiosk-like device with a touch screen and a Devices like kiosks with touch screen printer and to put such a kiosk in a place with monitors (Studomat), Internet access (Studonet) public access at faculties, thus granting the students 24 hours availability and consequently Requirements placed on Studonet were very greater independence of Student Service working different from those placed on Studomat because hours. intended functionality consisted of simple menus The Studomat offered following options to with a minimal set of business rules on the client the students: with emphasis on its availability and on small • Applying for an exam or canceling that requirements while connecting the client through application, viewing the results of web interface. Hence, Studonet architecture is a written exams variation of three-tier architecture most • Enrolling in a new academic year: commonly used by web applications. choosing courses for senior students and Studomat and Studonet shared some of their choosing the mentor to guide the functionality so it made sense to base them on graduation thesis the same part of business rules. • Printing of various documents and grade lists Client (Standalone Application) Printer 1 • Notifying students about matters of + NATIVE . Presentation Logic . interest via e-mail + . NATIVE Business Logic DBMS • Presenting the summary of all relevant Printer N VisualBasic Application information pertaining to the student Business Logic Data An improvement of the system was the ODBC Stored development of a named Procedures Tables Triggers

Studonet that allowed students to accomplish Presentation Logic simple, but often required tasks using Internet ODBC from the comfort of their own room, without Client (Web Browser) CGI Script having to come to their faculties. User Interface HTTP(S) HTML JavaScript 2.2. Model Figure 1. Studomat and Studonet

Entire information system was based on a 2.3. Implementation relational DBMS. Decisions about application architecture design were made by analyzing Studomat is a standalone application written requirements placed on application. in MS Visual Basic using ODBC for One part of mentioned functions of the access and native printer access. Visual Basic system such as enrolling in a new academic year and its development environment made the and choosing courses encompasses very design of rich GUI possible, and full integration demanding interaction between a user and the with Windows allowed good application. This interaction consists of printer control. Documents were in MS Word navigation through a complex menu tree because format. it is based on an extremely complicated business Analysis yielded that one Studomat covered rules system. Transaction complexity level is the needs of roughly 1000 students, which, for high and includes interaction with 30 or more FER, meant 3-4 Studomats and 2 printers. database tables. Overload occurred several times a year when a One Studomat (kiosk with installed large number of students wanted to accomplish application) can be connected to several printers. similar actions in the same time. The server part Then it controls them, checks their status and of Studonet was created using CGI technology evenly distributes the workload during printing. that was the only available server-side Documents to be printed are dynamically created technology at the time of development. The because they consist of database data and static client part of Studonet was created using a text. combination of HTML and JavaScript language Considering all mentioned above, the only which is sufficient for design of a simple user choice for Studomat application was two-tier interface. application architecture (also known as client- Studonet later appeared to be rather sensitive server). Known flaws of two-tier architecture to workload because of limited scalability of CGI had little significance because of the rather small technology because it starts separate processes number of Studomats. for each new client. 3. New Studomat application Maximum data security is an aspect that cannot be neglected because user's confidential During the development of the new data are transferred over web. information system that is expected to include all Since a number of applications were already institutions of higher education in Croatia, a new developed for the new system, it would be version of Studomat had to be developed as well. desirable, if possible, to use the existing In the analysis phase all problems discovered programming code. Existing applications were during the development and exploitation of the developed using our own framework [6] old system and requirements placed on the new designed for development of standalone system were taken into account. applications, which could also be used. Intensive use of design patterns would make 3.1. Motivation the interchange of ideas within the development team easier and the maintenance of programming The new application is supposed to contain all code less demanding. of Studonet's and Studomat's functionality and The choice of technologies should be, as also some additional enhancements. Similarly to much as possible, based on open systems and the old system, the new application should have industrial standards rather than on proprietary two different "allotropic modifications" based on technologies in order to maximally avoid vendor old Studomat and Studonet with similar set of -in. functions and requirements. The first idea was to take the complete code 3.2. Choice of technologies base of the old Studomat/Studonet and, after some modifications, use it in the new system. Starting from the requirements for open Another solution was to write the whole architecture, industrial standards and object- programming code from scratch using the insight oriented programming language, Java appeared and experience gained during development of the to be the optimal choice, taking into account that old Studomat. applications for the new system and the From performed analysis it was concluded framework they are based on were written in that the greatest potential problem of this new Java 2 Standard Edition. system would be the different code base and low As a logical extension Java 2 Enterprise scalability. Edition was considered. The Java 2 Platform, The part of business rules that was located in Enterprise Edition (J2EE) defines the standard the database was a solid basis, but each form of for developing multi-tier enterprise applications. the application contained a part of business logic J2EE simplifies enterprise applications by basing and the complete presentation logic. That made them on standardized, modular components, by the debugging and adding of new features a providing a complete set of services to those difficult and error prone task. Adding support for components, and by handling many details of new technologies, that are yet to come (mobile application behavior automatically, without clients, web services), would be expensive and complex programming. the problem of code maintenance would All J2EE technologies have proved constantly grow. themselves on the market as stable, reliable and Scalability has become important because to complete which was also an important factor in the contrary of the old system (4000 users), the choosing the development platform. new system has to be able to handle continuous The choice of technology for user interface growth of the number of users up to about design was between HTML/JavaScript 100000 when all institutions enter the system. combination and Java applets. Although Java Several Studomat-kiosks, realized as typical fat applets appears as a natural combination with clients that keep connection to the database open Java as server technology, still HTML/ all the time would be substituted by about 150 of JavaScript seems to be a better choice, mainly Studomat-kiosks that continually overload the because of small requirements on the client, but database. Web load would also increase also because of maturity of this standard. HTML significantly and more than CGI technology definitely brings a certain trade-off because it is could support. inappropriate for design of complex user interfaces. Document printing introduced an additional consequently minimizes both, the network traffic dose of complexity because the old solution was and the number of network calls that introduce completely inadequate for the new platform. latency. This solution conceals internal model XML standard together with belonging structure from the client, and changes in internal technologies (XSL, XSL-FO) and PDF as an end structure of the model do not imply changes in document format is a good choice. the client. Data exchanged between the presentation 3.3. Model layer and the business logic layer frequently are not of simple data types but rather complex The choice of application architecture is a structures because they represent data extracted strategic decision in the application development from multiple tables in the database. To avoid process. Based on all available parameters, remote procedure call overhead during access to multi-tier architecture consisting of a thin client, and manipulation of data, Data Transfer Objects a middle-tier with presentation logic, a middle- design pattern [3] was used. When a client tier with business rules and a database was requests data, it calls a method in the business chosen [4]. logic layer who then fetches all the required data The client controls data presentation for the from the data layer and creates a Data Transfer user and the capturing of user’s actions. Object, Java class which contains and The presentation layer was realized as a set encapsulates bulk data in one network of components that are executed on a web server. transportable bundle. The same principle is used The standard design pattern for this layer is a when a client wants to create, modify or erase Model-View-Controller design pattern [5]. data, except in that case the client creates a Data The component (Java Servlet) that represents Transfer Object and sends it to the EJB layer the is the only input into the using one network call. application. When a request arrives, as first, the security checks are completed and then a second User Presentation Business Rules Data Interface Layer Layer Layer Layer controller component to process the received Front Model Controller EJB2 request is chosen. The controller component Java Servlet takes over the request and determines which Web 1 2 5a Browser Business Method Call HTTP Request Instantiate SQL Call 4a methods of the model and with what arguments 3 Controller should be called. HTML Business Method Call + EJB1 The model is represented by a Java JavaScript (acting Data Java class as Session Enterprise Bean component which is located in Facade) the business logic layer and on whom different HTML page operations are performed. 8 View JavaBean 6 4b SQL Call 7 Business Method Call 5b JavaServer After the state of the model has been Pages changed, the controller receives data and passes EJB3 them to the View which is represented by a JavaServer Pages component, which displays the Figure 2. Architecture details new state of the model to the user. The JavaServer Pages component receives only the The data layer is represented by relational necessary data for user interface generation database. through custom tag library in HTML and The issue of document printing is solved JavaScript. using a separate Java application acting as the In Enterprise JavaBean components a part of server to which Enterprise JavaBeans are the business rules and all of the database access connected as clients and are sending their code are implemented. The presentation layer printing requests. These requests contain only the controller uses them as models, calling their basic data for the PrinterServer application to methods thus indirectly manipulating data in the receive the requests from the EJB component data layer. using RMI protocol. The PrinterServer then The business logic layer was created using extracts data from the database, generates an Session Façade design pattern [3]. This provides XML document, by a series of transformations great independence of the presentation layer brings it into the final form (PDF) and prints it from business logic. Calling of just one remote on one of the connected printers, performing method performs complete business logic and it automatically load-balancing between connected There are some small differences in the printers. interface and some big differences in the E-mail sending is realized using a message functionality when the application is not used queue. If a student performs a certain action on from an Internet kiosk. All options demanding the Studomat, causing results about which s/he interaction with other systems are disabled, e.g. wants to be notified, the EJB sends a message to documents are printed on a printer situated at the the application for notification using the JMS faculty and the student must be there to pick it which then generates an e-mail and sends it to up. the user (student). The Studomat does not wait Due to security and nondisclosure of for the message to be sent because message confidential data, special care had to be taken to sending proceeds asynchronously. prevent that the presented web pages are cached on the computer using Studomat application. Client (Web Browser) This was done to avoid situations where a User Interface Message Queue student uses the Studomat in some Internet cafe HTML Web Server JavaScript Presentation Logic and all viewed pages remain cached on the Send Mail

HTTP(S) Servlet Internet cafe computer. Real life experience has

Printer 1 ... Printer N Java Server Pages shown that web browsers do not comply with

Application Server RMI settings selected in the HTTP protocol and the Java Printing viewed web pages, despite explicitly instructing API Business Logic RMI otherwise, can be cached on local hard disks. The Enterprise JavaBeans DBMS only solution that really disables caching is to Print Server direct all requests through servlets.

Java Application RMI Business Logic At first, a complete implementation of JDBC Data Stored Procedures Tables business rules within the EJB layer was planned. Triggers However, after initial testing, it became clear that Figure 3. Architecture overview using the Entity EJBs, due to the extremely complex database structure, is sometimes very 3.4. Implementation demanding on computer resources, what results in long response times and it was decided that Throughout the implementation of each of the this solution is not acceptable. aforementioned application layers, the choices The next introduced and tested solution was made were constantly questioned and better a partial implementation of business rules in data solutions to the encountered problems were layer in the form of stored procedures. Due to the searched for. The general idea was to use as mentioned transaction complexity, these many proved concepts as possible. procedures were written in a modular fashion to The choice of HTML and JavaScript in user avoid code duplication and to simplify interface design brought some anticipated maintenance. At first, this solution seemed as a problems with different implementations of these good one, but after being tested with a bigger standards in different web browsers. Differences workload, it resulted in DBMS overload and between HTML implementations are minimal, congestion because of intensive use of stored while the story with JavaScript is much worse, so procedures. In a complex, real world example, a in the end, a separate JavaScript code had to be call of procedure that determines which courses a written for each supported web browser. student can choose resulted with 1500 successive Special attention was given to the design of procedure calls. For a simulation of 15 students user interface with the ability to display data in a choosing courses concurrently and repeatedly, clear and unambiguous way and to enable average response time was 109 s. A simulation meaningful and precise interaction with the with 30 students fully congested the database. application. Afterwards it was concluded that it was Each segment of this user interface is necessary to reduce the modularity in stored completely suitable for the touch screen on procedures. Now, in the same example, the Studomat kiosks: the menus are placed on one number of procedure calls was reduced to 400 side to avoid moving hands over the screen, and and average time decreased to 10 s (for 15 the button size corresponds to the size of the students). Increasing of number of students didn't fingers. During logging on to the system, virtual increase average time significantly. Other keyboard is displayed. operations performed on the Studomat aren't so demandable and can be easily ignored in industrial standards, all the set goals have been performance measuring. The maximum number achieved, but with some compromises. of students choosing courses simultaneously is Scalability was accomplished using multi-tier estimated to be about 150 (when system is fully architecture; the unified code base decreases implemented). maintenance costs and bug problems and makes Also some temporary results from stored the addition of new features easier. The choice of procedures are cached in EJB layer for later use. Java platform and Linux operating system After these alterations had been made, the resulted in a stable system, while the quality and response time dropped significantly, and the readability of the programming code and the application was able to bear a substantially larger possibility of verification of founded concepts number of users without DBMS congestion. was achieved by applying various design patterns. The security was realized using several 3.5. Achieved goals elements in all the layers. Implementation of all the necessary features has been accomplished. Our aspiration to unique code base demanded During the system development, certain abandoning the existing model of "allotropic concepts had to be altered and adapted due to modifications" with different architecture in poor performance caused by a distinctive favor of a single unified application with all situation. The database appeared to be the business rules and all the features, achieving greatest problem due to very complex different functionality by different (or at least transactions and occasional very complex data modified) user interface and presentation logic. extraction. Much of the time was spent finding The introducing of a new type of client is much the optimal model of implementation of business easier because it is only necessary to program a rules, but, in the end, the results were more than lesser part of the presentation logic for a desired satisfactory. type of client, while most of the existing presentation logic and the complete business 5. References logic are reusable. This minimizes and centralizes code maintenance, makes addition of [1] D. Kalpić, J. Anzil, V. Dumanić, H. new features easier, decreases the number of Zoković: Student Administration System, bugs and consequently decreases the cost of the Proceedings of the 15th International entire system. Conference on Information Technology The scalability and performance problems Interfaces, Pula, Croatia, June 15-18, 1993, are very well solved using distributed application pp. 123-128 concept which is the basis for multi-tier [2] D. Kalpić, M. Baranović, V. Mornar, S. application architecture. The presentation logic Krajcar: Development of an Integral and the business rules are distinctly separated in University Management System, this model and are located in separate Proceedings of the International Conference components. on Systems Engineering, Communications Using the PrintServer concept for printer and Information Technologies, Punta control completely accomplishes the goal, Arenas, Chile, April 16-19, 2001-05-23 because it enables the necessary control over [3] F. Marinescu: EJB Design Patterns, Wiley printers, and raises its scalability by allowing Computer Publishing, 2002 printers and print servers to be added depending [4] N. Kassem and the Enterprise Team: on workload. Designing Enterprise Applications with Java 2 Platform, Enterprise Edition, Sun 4. Conclusion Microsystems, 2000 [5] E. Gamma, R. Helm, R. Johnson, J. Strategic decisions made during development Vlissides: Design Patterns, Elements of of a new application reflect in the choice of Reusable Object-Oriented Systems, application architecture and technology. By Addison-Wesley, 1998 migrating from an application having two forms [6] M. Baranović, S. Zakošek, L. Mačkala: of similar functionality but different code base Creating Database-aware Java Classes and proprietary technology to the application Based on Extended Data Dictionary and with scalable, multi-tier architecture having a Abstract Classes, SCI2001/ISAS 2001, unique code base, based on open technology and Orlando, 2001