Hierarchical Architecture as a New Approach for Building Web Applications

Yousef Rastegari Afshin Salajegheh Samaneh Rastegari Emad Pejman Islamic Azad UniversityIslamic Azad UniversityUniversity Putra Malaysia Islamic Azad UniversitySouth Tehran Branch South Tehran Branch Serdang, Malaysia South Tehran Branch Tehran, Iran Tehran, Iran samaneh.rastegari@gmail.com Tehran, Iran emad.pejman@gmail.com rastegari.yousef@gmail.com salajegheh@iau.ac.ir
Abstract Controlling and testing a large scale web application is a time consuming and expensive job because of the huge number of pages and their actions. The hierarchical architecture proposed in this paper is a framework which can decreases nested relations between web pages. We can also use different programming methods like object oriented or structured over this model. One of the most important advantages of this architecture is increasing the control and security of the application in its different layers. This architecture also eases adding new modules to the main body of the program and software maintenance. Keywords- Software Engineering; Web Application; Portal; Hierarchical Architecture; Security

described in details. The implementation of proposed architecture including the pseudo code and a sample PHP program is presented is section 4. Finally, we conclude the paper in section 5.

I.

INTRODUCTION

A web application that has a set of pages includes scripts of one or more programming languages. These pages are called separately or nested. For example as shown in figure 1, you may call page A while this page includes a set of scripts in order to perform the requested process. Some of these scripts can be an independent page (page B in figure 1). Think about an online shopping system, suppose that page B is a Customer Authentication page and page A is a Login or Check out page. We need to authenticate a customer in check out process and include a Customer Authentication page in other pages. These nested includes are substantially growing and making serious problems for software developing teams that will be mentioned them in next section. Our proposed architecture for building web applications is the consequence of years of web programming and application developing which is formally presented in this paper. Reference [1] proposed a method of modeling web application architecture with UML, in which the design of web application is described from different viewpoints and levels of abstraction by three models: business model, navigation model and implementation model. There is a lack of study in their research since they didnt talk about increasing complexity of relations between thousands of scripts in huge web applications. The remainder of this paper is organized as follows: In section 2 we describe what web developers have done in building most of current web applications. Next in section 3, our proposed hierarchical architecture and its benefits are

Figure 1. Nested webpage call is implemented in response to user request

CURRECT ARCHITECTURE OF MOST OF WEB APPLICATINS Configuration management which consists of change requests control is hard to implement and most of the software developing companies that are in level one or two of CMMI (as an audit) [5] have problem with side effects of change requests and software maintenance. The change requests come from customers and you as a software owner need to implement them, otherwise you will loss the business. Also think about division of tasks in team programming which each group is responsible for some tasks. They want to progress them as separately as possible and finally integrate them. With the current methods of developing in which pages and software features are rigidly linked to each other, it is hard to see the advantages of team working. Although object oriented programming and class view help programmers to work together and use their coworkers class in further uses but using our proposed architecture will help them to significantly increase their cooperation. Web applications are the legacy software of the future. Developed under tight schedules, with high employee turnover, and in a rapidly evolving environment, these systems are often poorly structured and poorly documented. Maintaining such

II.

_____________________________________

978-1-4244-6055-7/10/$26.00 2010 IEEE

459

systems is problematic [2]. Adding new modules and features to a software with lowest side effect is desirable which is considered in our proposed architecture. Due to the lack of relations between separate pages and integrated architecture, software maintenance is easier than usual. Security is another important issue in software developing especially in web applications and web portals which have public users. We considered security walls in each levels of the hierarchical architecture. These security walls can prevent unauthorized access to the whole or some parts of software. They have granularity from the whole system (e.g. Login action) to a specific action (e.g. Add news). In the current architecture of web applications, each page has its own functionality and number of pages shows number of features. As an example, suppose News Management System which consists of addNews.php, editNews.php, deleteNews.php scripts, and each file shows a action. Although this architecture is responsible but it causes the following problems in large-scale web application developing: Time and expenses for: o o o Updating and testing Fault diagnosing Adding new modules and features (increasing the version)

functions (Action variables). Suppose News Management as a Section with News Group, New Membership, News Control as subsections and Add news, Edit news, Delete news as actions related to last subsection. Using above mentioned variables, the path to an action and its related form is determined. Every form has generally two states, first its not submitted and the user will see a raw form to fill it out. Second, its submitted and the information is sent to the server. We can check these two states by using do-action variable (depicted in figure 5). Figure 3 illustrates the logical view of our proposed hierarchical architecture. Considering figure 3, page index.php is the input and output entry of the software which all the requests are sent to it. Actually this page is the outer view of the software, and it is also the first level that end users are dealing with. From the point of view of end users, the software is summarized in this page and they have no idea of the sub structure of the software. All of the programming parameters such as such as GET, POST, SESSION, and SERVER variables are called and exchanged by using this page. Considering the below link, it shows that a user has requested the News Control subsection of News Management section and wants to add new news: http://www.example.com/index.php?section=newsManagemen t&subsection=newsControl&action=addNews At first, by receiving this request, we will show a form for adding new news. Then user will submit the form in order to send the required information. At this step some extra variables such as do-action will be sent to the software for further processing. If everything is satisfied (mandatory field are filled out, and etc.) then the new news will be added successfully. Following are some advantages of proposed architecture: Higher security control. User authentication and authorization is done in each level and it has the granularity from the whole system to a specific action too. Files such as CSS, JavaScript, global classes, and libraries are included in top levels and we do not need to include them in each page separately Making log files is easily done in each level for every user Adding new modules, classes, CSS files are easily done in each level Team working and work division is easily done with low dependency

Lower efficiency in team working Lower confidence and flexibility Redundancy in coding

Figure 2. Most of current web applications distribute their functions in web pages which link to each other or use each other. Every page is responsible for a action and some pages like CSS, Security, JavaScript and etc. files are included globally or locally if required

III.

HIERARCHICAL ARCHITECTUR OVERVIEW

In the proposed architecture the application input and output entries are summarized in only one page. The required HTML forms (templates) are selected based on the requested sections (Section, Subsection variables) and requested

460

Figure 4. Sample server files and directories

Figure 3. Hierarchical architecture integrates all web pages in root page which is the entry of system requests. All requests enter to this page and by using some determinant pages in each level the request is directed to the proper action and its related form. We guide the proper path by using GET or POST variables which are sent to root page

IV.

IMPLEMENTATION

The pseudo code of our proposed architecture is depicted in figure 5 and a sample implementation is shown in table 1. We used PHP programming language to show the sample but it is changeable to any other languages and also the levels can be added or deleted based on requirements. Suppose server files and directories are organized as we have shown in figure 4. Classes contains PHP class files (e.g. newsManagement.php), Includes contains all that we need to include globally or locally, for example all CSS, JavaScript and library files, and Templates contain all forms in template format (i.e. .tpl files).

Figure 5. Pseudo Code of Proposed Hierarchical Architecture

V.

CONCLUSION

In this paper, a hierarchical architecture was proposed as new approach for developing web applications. The proposed architecture is mostly suitable for large scale web applications and it may not reveal its advantages for small or medium scale ones. By integrating all of web pages in root page and designing the architecture in a hierarchical manner, developers can easily implement security policies, add new modules, CSS and include files with lowest side effects. Based on this

461

architecture, team working is also improved significantly, so each group can develop a path from the root to its related actions. REFERENCES
[1] J. Li, P. Chen, J. Chen, Modeling Web Application Architecture with UML, Proceedings of the 36th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS-Asia'00), IEEE Computer Society, p. 265, USA, 2000.

[2]

[3] [4] [5]

Ahmed E. Hassan, Richard C. Holt, Architecture recovery of web applications, Proceedings of the 24th International Conference on Software Engineering, p. 349-359, Orlando, Florida, 2002. Welling, Luke, Thomson, Laura, PHP and MySQL Web Development, SAMS Publishing, 2001. Achour, Mehdi, Friedhelm, Betz. PHP Manual, PHP Documentation Group, 2008-11-21, <http://www.php.net/docs.php>. F. Wang, R. Aihau, A Configuration Management Supporting System Based on CMMI, Proceeding of the first international MultiSymposium on computer and computational science (IMSCCS06), IEEE,2006

TABLE I.

SAMPLE HIRARCHICAL ARCHITECTURE IMPLEMENTATION IN PHP PROGRAMMING LANGAUGE [3][4]

index.php <?php //Get section, subsection, action variables section=$_GET[section]; $subsection=$_GET[subsection]; action=$_GET[action]; /* Determine movement path in hierarchical architecture by using section and subsection variables */ include (include/determine_movement_path.php); /* Your Custom Script Code */ ?> <html> <title>Web Application Index Page</title> <body> <!-- Your Custom HTML Code --> <?php include($form_to_show); ?> <!-- Your Custom HTML Code --> </body> </html> Implementing root sections (e.g. News management, User accounting, Order management and etc.) determine_movement_path.php <?php switch ($section) { //Section 1 case section1 : { checkUserAccess ($_SESSION[user_id], section1); include (class/section1_class.php); $section1_obj = new Section1(); //Continue determining path by subsection variables include (class/section1_determine_path.php);//Determine requested action in next level break } //Section 2 case section2 : { checkUserAccess ($_SESSION[user_id], section2); include (class/section2_class.php); $section2_obj = new Section2(); include (class/section2_determine_path.php);//Determine requested action in next level break } } ?> Implementing section1 actions (e.g. Add news, Edit news and etc.) section1_determine_path.php <?php switch($action) { case action1 : { checkUserAccess($_SESSION[user_id], section1, action1); if ($_POST[do_action]) { $result = $section1_obj->action1(); if ($result == false) { //Print error message and show the related form again $form_to_show = templates/section1_action1.tpl; } else { /*Action done successfully so show proper message/form to user and do your custom tasks*/ } } else { $form_to_show = templates/section1_action1.tpl; } }// End of case }// End of switch ?>

462