International Conference on Computer Science and Information Technology (ICCSIT'2011) Pattaya Dec. 2011

Evaluating Presentation Layer Development Frameworks for EJB Applications in J2EE Architecture

Ohm Samkoses, Dipl. -Inform. Matthias Vianden, Prof. Dr. rer. nat. Horst Lichter

gathering and analysis, multiple rounds of frameworks Abstract—For medium to large organizations, information selection with different criteria, prototype implementations, systems play an important role for information storage and retrieval. and results evaluation. The chosen frameworks for prototype They are used to support business processes such as decision-making. development should fulfill most of the requirement and the In information systems, huge amountof data needs to be manipulated prototypes implementation should reflect the solution for each and visualized. One way to handle this complexity is to use Enterprise JavaBeans (EJB) [1] in a J2EE architecture. Since EJB has requirement clearly, and must be able to work with the not been designed to work in the Presentation Layer, suitable existing system's environment: the back-end is managed by Presentation Layer Development frameworks are introduced to EJB 3.0, and IBM Websphere Application Server 7.0. enhanced thepresentation layer of the information systems. The MeDIC (Metric Definition Integration Calculation) system and XAM II. TASKS / STEPS (eXam Assignment and Management) system [2] are typical representatives of such information system. A. First frameworks selection Nowadays, many frameworks, such as Server Faces (JSF), First step was to narrow-down the scope of the focused Wicket, and Tapestry, exist to cover the Presentation Layer. They framework based mainly on framework popularity. Other provide a variety of features and architecture enhancements. The goal of this research paper is to evaluate frameworks for the Presentation factors were general criteria [3], such as, Layer of information systems, which shared the same architecture learning curve, testability, configuration complexity, amount with the proposed architecture of the MeDIC and XAM system. of artifact produced, architecture and pattern, tools and IDE, and supports from community. This first selection aimed for Keywords—J2EE Architecture; Enterprise JavaBeans; 5-10 frameworks as an output. Presentation Layer Development Frameworks; Information System; B. Frameworks analysis I. INTRODUCTION The outputs from the first framework selection were analyzed at this step. The selected frameworks were compared Nthe proposed architecture, the Data Layer and Business to each other under five general web framework criteria: Logic Layer are managed by EJB. The Presentation Layer I configuration complexity, learning curve, testability, communicates to the Business Logic Layer via Application community and support, tools and IDE. Facade. The Presentation Layer is currently implemented using JSP/Servlet technology. However, the current design C. Requirements gathering and analysis still has several defects, for instance: code redundancy, huge All attendances were developers, who experienced using the amount of classes, and low reusability. In consequence, J2EE system based on the proposed architecture. Also requirements presentation development frameworks minimize those defects prioritization was used to identify the important factor of each and improve the efficiency of the system, which shared the requirement. similarities with the proposed architecture. The goal of this research paper is to evaluate frameworks . Second frameworks selection for the Presentation Layer based on the proposed architecture, In the previous step, 3-4 frameworks were aimed to be including the current solution (JSP/Servlet). The steps to selected as an output. The main factor of the selection is the achieve the goal of this research paperincluderequirements requirements, the general web framework criteria were also affected, but less because the requirements represent the characteristics of the solution itself. In contradiction, even a Ohm Samkoses is a master degree candidate of Thai-German Graduate framework fulfills most of the requirements, it should not fail School of Engineering (TGGS),King Mongkut's University of Technology North Bangkok (KMUTNB), Bangkok, Thailand (phone: (+66)87-550-3738; on the general web framework criteria, which represent the e-mail: [email protected]). characteristic of high quality, efficient, productive web Dipl. -Inform. Matthias Vianden,is a research assistant of the Research framework. Group Software Construction (SWC), RWTH Aachen university, Germany (e- mail: [email protected]). E. Prototypes implementation Prof. Dr. rer. nat. Horst Lichteris a professor at RWTH Aachen university and head of the Research Group Software Construction (SWC)(e-mail: The selected frameworks wereimplemented for a proof of [email protected]). concept. For each prototype, there were five aspects need to be

37 International Conference on Computer Science and Information Technology (ICCSIT'2011) Pattaya Dec. 2011 mentioned: working environment and tools, framework's basic following seven most widely-used frameworks are selected for concepts, complete architecture after the integration of further research and analysis: framework, project structure and artifacts produced, and steps • Spring MVC (SpringSource.org) to migrate from the existing system. • Java Server Faces (J2EE and JSR Standard) F. Results evaluation • Wicket (Apache Software Foundation) All implemented frameworks were analyzed against the • Seam (JBoss) requirements. The result from the comparison against general • Struts2 (Apache Software Foundation) web framework criteria in step 2 also affects the evaluation at • Tapestry (Apache Software Foundation) this point. • (Stripes) These important steps were demonstrated and explained in detail in the following chapters of this report. • The existing system, pure JSP and Servlet

III. BACKGROUND Even though, web frameworks give you many benefits,but there are several criteria that should not be neglected. For The architecture of the existing system is based on the J2EE example, testability, learning curve, community and support, architecture. Follow the J2EE approach, the system is divided tools and IDE, architecture and patterns, configuration into 3 layers: Presentation layer, Business Logic layer, and complexity, and amount of artifact produced. Data layer. The following diagram shows the comparison result of the The presentation layer composed with plain JSPs and frameworks selected from the 1st framework selection, in the Servlets. The request from the browser will be centralized to context of some part of the criteria explained in previous the Action Handler Servlet and delegates to the corresponding section. Action class. The Action class communicates with the Application Facade in the Business logic layer. The Business Layer and Data layer are managed by EJB framework. The Application Facade delegates the request sends by Actions in Presentation Layer to the corresponding Controller. The controllers are the interfaces to simplify the business logic in Management. The Entity persisted, and the results from the database render in JSP page in the presentation layer.

Fig. 2Result from the output of first frameworks selection

V. REQUIREMENT GATHERING AND ANALYSIS There were 5 attendances. All of theattendants are developers working in the MeDIC or the XAM project. All attendances were free to express their own opinions about the original prototype, expected characteristics of the new architecture, and prioritize all requirements. Fig. 1Architecture diagram of the existing system The purpose of this requirements meeting is to get technical feedbacks and suggestions from the users of the original On the client layer, the existing system uses the Command prototype and use those information as criteria for the 2nd pattern to encapsulate the request parameters. All requests frameworks selection and comparison. The selected pass through the Action Handler then the Action Handler frameworks will be analyzed in detail, implemented as delegates the request to the corresponding Action class. Both prototype of the existing system, and evaluated in the Action Handler and Actions are all ordinary Servlets built for following chapters. These following contents are the request delegation and communication to the business layer. requirements: One example of the problem caused by this pattern is huge amount of Actionclasses since, for each user operation, one action class needs to be created. In consequence, at least ten 1st priority (1) According to the feedback from user, convention over action classes must be created per Entity (create, retrieve, configuration framework is preferred. One factor that affect update, delete, and assign actions), this will increase the complexity is large files in the system especially, dramatically, if there are more object types in the system. configuration files such as xml files. There are very few tools/IDE, which support xml auto-completion and IV. FIRST FRAMEWORK SELECTION verification. Based on the statistic from Google Trends [4] and Zero Asynchronous JavascriptAnd XML () is a web Turnaround's Java EE productivity report 2011 [5], these development method used on the client-side to create

38 International Conference on Computer Science and Information Technology (ICCSIT'2011) Pattaya Dec. 2011 interactive web application. With AJAX, web application can Wicket, and Tapestry. Also, delegation and navigation send and retrieve the data from web server asynchronously (in supported can be achieved by Business Process Management the background) without any sign of page refresh. For the framework integration such as jBPM. However, only Spring existing system, any frameworks have AJAX support are MVC and Seam supports perfect integration with jBPM, and advantageous, but the system must still working perfectly, only JSF and Struts2 have navigation rule. The navigation rule even without AJAX controls the flow of page navigation. Seam might be the most Community and support also important. The chosen direct solution of this requirement since, Seam provides both framework's community should be active and provides navigation rule and jBPM to control page flow and business support. process flow. 2nd priority (2) Spring MVC and Stripes have serious problem with poor The framework should be Component-based and support IDE support (3). Even Wicket has no official IDE support, but inheritance architecture. since Wicket composed of HTML templates and pure Java, Reusability is always first factor to indicates the quality of any Java IDEs and HTML editor provides full support. Other the software system. For the backend and business logic, one frameworks passed this requirement especially, JSF and Seam. way to obtains the reusability is through inheritance structure. After the requirements analysis, three frameworks were Most of the web application view created by markup chosen to implement the prototypes. Those three frameworks language, which does not support inheritance structure, or any are Wicket, JSF, and Struts2. mechanism that provides the reusability. One Originally, Seam was chosen instead of JSF because, it way to accomplished the 2nd priority requirement is fulfils all requirements. Seam is a full-stack framework which component-based architecture framework. integrates several frameworks together. For presentation layer, In component-based aspect, each page considered as a Seam provides various choices including JSF and Wicket. component, and each page can be constructed with multiple There are several advantages of Seam using JSF over stand components, which means, each component can be reused to alone JSF including performance improvement.Due to construct pages, which shared some similarity as many time as integration conflict between Seam environment and existing needed without code duplication. environment, the prototype implementation using Seam failed. Also, the framework should be able to manage the request Most of the frameworks are not qualified. Spring MVC fails delegation automatically. This request delegation is most of the requirements especially, almost first 3 priority responsible for moving a particular request through the right requirements. Tapestry was precluded because of theserious class. In the original prototype, the ActionHandler Servlet is problem about no backward compatibility supported. responsible for the manual request delegation. The framework, Stripesfails 1st and 3rd priority requirements because the which support better flow control is needed. project is not actively developed and has no official IDE 3rd priority (3) supported. Since all other frameworks are precluded, Struts2 is The framework with good IDE support such as auto- the best choice amongst the frameworks left. completion, UI builder, multiple project support is needed. 4th priority (4) VII. PROTOTYPE IMPLEMENTATION The framework should provide high testability. A. JBoss Seam VI. SECOND FRAMEWORKS SELECTION Seam provides alternative presentation layer development frameworks fully integrated with EJB covered backend.The EJB provided by Seam is the proposed architecture from the beginning, and two out of three presentation layer integration provided by Seam are the chosen frameworks (JSF, Wicket). The benefits of Seam integration other than the enhancements mentioned in chapter two is the ease of prototype development. Seam tied Wicket and JSF seamlessly to the backend and does not required any Action beans. Also, it is simple to develop the next prototype after the first one by changing only view technology without changing anything at the backend.

Fig. 3 Result from the output of second framework selection Unfortunately, Seam prototype implementation failed. The cause of the failure is suspected to be the incompatibility of For the artifact complexity (1), almost of the frameworks Seam and IBM Websphere 7.0 Application Server (WAS). passed, except Spring MVC and Stripes. Spring MVC has a Even the JBoss community's resource already stated the Seam serious problem with very high configuration complexity installation on IBM Websphere 7.0 Application Server [6], but (pure XML, configuration over convention), and Stripes has a in practical use, it is not working in the existing environment. small community and not actively developed. In consequence, the prototype implementation plan changed For the component-based, inheritance structure architecture, back to the original plan, which is developedbythe remaining and the request delegation supported (2), four frameworks prototype independently without Seam. have component-based architecture, which are JSF, Seam,

39 International Conference on Computer Science and Information Technology (ICCSIT'2011) Pattaya Dec. 2011

B. Java Server Faces (JSF) is responsible for writing the model code, and for JSF has a very complex architecture, which consists of creating a central configuration file struts-config.xml that several design patterns working behind the scene [7]. binds together withmodel, view and controller. Developers only need to know five components: FacesServlet, UI Components, JSP, Managed Beans, and Navigation Rules. The FacesServlet is the front controller of the system. All the requests from the client have been translated into mapped action and delegated to the corresponding page and the response from the system is sent back to the requested client. Every JSF pages contain JSF components both basic components (JSTL tags, Facelets), which represent only standard HTML, or third party libraries (PrimeFaces, ADF Faces, Trinidad, IceFaces, ), which provide advance widgets like trees, grids, tabs, or personal custom components. Each component's value might bound to the value in Managed Bean, and some components have event listeners, which call Fig.5 New proposed architecture with Wicket integration the methods in the Managed Bean, when triggered. Those methods in the Managed Bean handle the communication with Interceptor is the core concept of Struts2, which provides the backend. The Navigation rules manage all page flowsof great code redundancy reduction. Many Action beans the system. sharecommon concern. Several Action beans need similar

input validation. Some needs a file upload to be pre-processed. Another Action beans might need double form submission protection. Interceptors can execute code before and after the Action bean is invoked. Features like double-submit guards, type conversion, object population, validation, file upload, page preparation, and more, are all implemented with the help of Interceptors. Each and every Interceptor is pluggable, so developers can decide exactly which features an Action bean needs to support. Also, if a lot of Action beans areplugged with the same pattern of interceptors, Interceptor stack can be defined in the struts.xml to provide even more convenient. For example, every Action beans which related to very important Fig.4 New proposed architecture with JSF integration task need to apply double-submit guards, user session validation, and encryption interceptor. Instead of spending C. three lines to apply all requiredinterceptoron every Action Wicket's architecture is very simple. It is mainly composed beans, registering an interceptor stack contained three required of HTML templates bind tightly to POJOs with the same interceptors, and spentonly a line for applying the stack to the name. These paired HTML templates and POJOs represent Action beans is more productive. web pages. Minimum number of artifact to build a page is two: one HTML page, and a POJO. In consequence, huge amount of artifacts are produced. However, Wicket's component-based architecture greatly reduces the complexity of artifacts. The developer may use basic Wicket components or even, create custom components using the same method as building a page. As a result, more than half of the artifact especially, HTML files have few simple lines of components' interface declaration, and POJOs are well-structured, highly reusable, and easyto understand with inheritance structure. The flow is quite simple. The Request Cycle acts like a front controller, delegates the request to the corresponding page, thenthe user interface components in HTML template will be initialized by POJO bound to that HTML. Fig.6 New proposed architecture with Struts2 integration

D. Apache Struts2 VIII. RESULTS AND EVALUATION The goal of Struts is to separate the model from view and From the current result, the most suitable framework to controller. Struts2 introduced Action bean as the controller to replace the proposed architecture is Apache Wicket. Struts2 is facilitatethe writing of templates for the view or presentation eliminated from the list because, it does not completely fulfill layer (typically in JSP, but XML/XSLT, Tiles, FreeMarker the first priority requirement (configuration complexity, and Velocity are also supported). The web application community and supports) and does not fail the main second

40 International Conference on Computer Science and Information Technology (ICCSIT'2011) Pattaya Dec. 2011 requirement (component-based, inheritance structure existing system, Customer and Contract Management System. supported framework). Even Struts2 is widely used and The result is Seam prototype implementation whichwas a Interceptors provides great reusability, but compared to failure and the rest were successes. Finally, all results indicate Wicket and JSF, Struts2 does not answer our question. that Wicket is the most suitable framework to replace the The efficiency of Wicket and JSF are proximate. Both of proposed architecture. them fulfill most of the requirements. Wicket completely fulfill first and fourth priority requirements with zero REFERENCES configuration, very vibrant community, and powerful unit [1] Debu Panda, Reza Rahman, Derek Lane, "EJB3 in Action", Second testing API, while JSF also fulfill first requirement with Edition, Manning, 2007 some artifact complexity and few simple configurations. [2] Dipl. Inform. Matthias Vianden (contact), Bachelor thesis However, JSF has some problem on testing each layer SystematischeVerwaltung von Klausuren und Übungen, unpublished [3] Matt Raible, Comparing Web Frameworks, 2007, Raible Design, separately. Facelets and navigation rule fulfilled the second http://static.raibledesigns.com/repository/presentations/ComparingJava priority requirement of JSF with template inheritance and WebFrameworks-ApacheConEU2007.pdf user interface flow managementwhile Wicket was [4] Web page of Raible Designs, based on Google Trends statistic, August completely fulfillingthe component-based inheritance 2, 2011, http://raibledesigns.com/rd/entry/re_which_is_the_hottest, August structure without any extra technology, but Wicket does not [5] Java EE Productivity Report 2011, Zero Turnaround, July, 2010, provide user interface flow management at all. The third http://zeroturnaround.com/java-ee-productivity-report-2011/ requirement JSF and Wicket are proximal. JSF has very [6] Gavin King & Pete Muir & Norman Richards & Shane Bryzak&Michael good tools and IDE supported, while Wicket does not need Yuan & Mike Youngstrom& Christian Bauer & Jay Balunas & Dan Allen & Max Rydahl Andersen & Emmanuel Bernard &Nicklas any additional tools or IDE. Karlsson& Daniel Roth & Matt Drees& Jacob Orshalick& Denis Since the result from comparingthe requirements alone Forveille&Marek Novotny &JozefHartinger, "Seam - Contextual cannot indicates which one is the most suitable framework to Components. A Framework for Enterprise Java 2.2.1.Final", Seam replace the proposed architecture, other important factorwhich Official Website [7] Daniel Perovich& Leonardo Rodriguez & Andres Vignaga, needs to be considered. The reason why Wicket was chosen is "Architecture of Component-based Information Systems over the J2EE JSF has a very serious issue on very high memory Platform", August, 2005 consumption rate, while one of the Wicket's prominent points [8] Peter Thomas, "Seam / JSF vs. Wicket: performance comparison", is its light-weightiness. Many source did the comparison September 27, 2011, Increment Operations,Avialble at: http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket- between JSF and Wicket memory usage, and some source performance-comparison even provesthat even JSF enhanced with Seam's JSF memory consumption optimization consumes more memory than stand alone Wicket [8]. Combining with very low learning curve and simple architecture with complete separation of presentation layer and business logic layer, Wicket is the best choice amongst all frameworksto replace the proposed architecture.

IX. SUMMARY This research paper indicates that Wicket is the most suitable J2EE-based presentation layer development framework for replacing the presentation layer of the proposed architecture. On the first step, seven frameworks were chosen based on popularity and general web framework criteria in order toroughly filtered out the low quality web frameworks from this research paper scope. Those frameworks are Spring MVC, Java Server Faces (JSF), JBoss Seam, Apache Wicket, Apache Struts2, , and Stripes. The main criteria of this research paper is the requirements gathered from the developers who had experience in using any system based on the existing architecture (proposed architecture). The requirements were gathered, prioritized, and analyzed into four main prioritized requirements and became the main criteria for the second round selection. Against requirements and general web framework criteria, seven frameworks were analyzed and compared. The result was four frameworks were chosen for the prototypes implementation. Those frameworks are Seam, JSF, Wicket, and Struts2. The purpose of the prototypes implementation is to prove the concepts and frameworks comparison in the same environment. All prototypes' structures were based on the structure of the

41