JAFAR: DETAILED DESIGN OF A PATTERN-BASED J2EE FRAMEWORK

Transcription

1 JAFAR: DETAILED DESIGN OF A PATTERN-BASED J2EE FRAMEWORK Nicolas Guelfi, Paul Sterges Luxembourg University of Applied Sciences Software Engineering Competence Center 6, Rue Coudenhove-Kalergi L-1359 Luxembourg-Kirchberg, Luxembourg {nicolas.guelfi, paul.sterges}@ist.lu ABSTRACT 1 Framework-based development is one of the major challenges in the field of rapid development of distributed applications. J2EE-based web applications represent an extremely interesting context for which development frameworks should be provided. Unfortunately, there are few integrated frameworks for such environments developed from a software engineering perspective. This paper presents the detailed design of JAFAR, our patternbased J2EE framework. It provides a way for framework developers to concretely reuse our approach or to compare their approach to JAFAR. It also shows how such frameworks should be considered from a software engineering perspective, and it highlights the advantage of relating frameworks to a development methodology supported by a case tool. KEY WORDS Frameworks, Architecture, Design, J2EE, Design Patterns, CASE tools 1. INTRODUCTION The JAFAR framework has been developed in the context of the FIDJI project [1] of the Luxembourg University of Applied Sciences. The FIDJI project aims at defining a methodology for the development of reliable Java-based distributed applications. An important aspect of software development is the reuse of existing designs and implementations. Reuse can contribute to significantly reduce the cost of designing, implementing and validating an application. Because of its importance we have decided to examine one form of high-level reuse in more detail: the use of frameworks. The term framework has been defined in several different ways, for this paper we consider the following definition: A framework is a reusable, semi-complete infrastructure that can be specialized to produce custom applications. 1 This work is supported by the Luxembourg Ministry of Higher Education and Research under the title I project n MEN/IST/01/001 Frameworks are designed to be reusable and specialized in the context of a product line. [2] JAFAR is a framework for building Java 2 Enterprise Edition (J2EE) [3] web applications. JAFAR is based on Rational s PearlCircle Online Auction (PCOA) [4], which is a reference application developed to illustrate how Rational tools and how the Rational Unified Process can be used to build J2EE-based applications. When Rational developed this application they separated the generic, reusable parts from the application itself. The generic parts form a kind of implicit framework. We have extracted the generic parts from the PCOA application and based the development of JAFAR on it. The JAFAR framework implements many of Sun s J2EE patterns that are discussed in [5]. Moreover, the framework provides tools that help the framework users to implement these patterns in their own application. Rational XDE (extended Development Environment) [6] was used in the development of the framework: it was used to create the UML models that come with the framework and to implement it. The framework relies on Rational XDE s pattern engine to define transformation mechanisms and wizards that assist the framework user in building his application. However, it is important to note that the framework could be used with a different CASE tool, given that the tool supports the models, the transformation mechanisms, and the wizards. This paper presents the architecture and the design of the JAFAR framework. First, we present some general considerations concerning frameworks. Thereafter, we discuss what the JAFAR framework offers before examining how these features are implemented. 2. ARCHITECTURAL FRAMEWORK FOR J2EE APPLICATIONS As already presented in the introduction, a framework is a reusable infrastructure that can be specialized to produce custom applications [2]. We focus on architectural frameworks because they emphasize the resulting application architecture. In our opinion, an architectural

2 framework is, at least, composed of implementation code, transformation mechanisms, and documentation including the explanation of the use and the specialization of the framework. There are many advantages in implementing an application with an architectural framework. The framework has an existing structure that the architect can reuse, and the framework guides the developer in creating the application by specializing the framework. An architectural framework is often limited to one product line, and though should not be adapted to domains that fundamentally differ to the one it was built for. A product line is a group of products sharing a common, managed set of features that satisfy the specific needs of a selected market. [7]. We chose to study the web application product line. The applications of this product line have many recurrent services. A framework could then provide a common basic structure for web applications. The structure of a web-based application is constrained by technological choices. In this work we focus on Java technologies, and particularly on J2EE. The layered structure promoted by J2EE is made of a presentation layer and a business layer. J2EE offers Java Server Pages and Servlets for the presentation layer and Enterprise Java Beans for the business layer. We consider that a workflow layer should also be part of the structure of a J2EE application. This layer takes care of the requests coming from the presentation layer and dispatches them to the business layer. Its purpose is to centralize the use-case control logic on a distinct layer. To implement the workflow layer, standard technologies can be used like simple Java classes optionally coupled with XML files for easier customization. With this common J2EE configuration, the client needs an Internet browser, and the server needs to run an Application Server (Web container, EJB container) Web applications offer many kinds of services depending on their target domain (business, portals ). Despite the diversity of web applications domains, we can still extract some recurrent services. The generic concept of user is important. Features associated to users include: the possibility to access specific services only if the user is authenticated, the creation and the modification of a user account. All these different features can be grouped in user management common services. Another generic concept is the item, lots of web sites especially the e- business web sites deal with items (books, cds ). There are some features that are usually associated with items; there is the possibility to browse the items available, in some cases to buy the item, and some other cases to add new items. Web sites also provide functionalities involving the sending of s to the users (weekly newsletter, account creation confirmation ). The main service offered by an architectural framework for web applications can be the management of users (authentication, restricted access to specific services). Its architecture should be composed of recurrent architectural fragments of web applications that relate to the navigation through web pages and the dispatching to the appropriate code logic, the storage of the user data to a persistent media, and batch processing at regular intervals. 3. THE JAFAR FRAMEWORK JAFAR offers the features of a web application framework as described in Section FRAMEWORK SERVICES The JAFAR Framework provides: - software components that can be used to build a web application. Some of these components form a complete architecture into which the framework user only has to plug his own modules while others simply offer useful services that simplify the implementation of a web application. - transformations, defined using Rational XDE s pattern engine, that create software components based on their specification in a design model. - wizards, defined using Rational XDE s pattern engine, that simplify various tasks for the framework user by generating some of the model elements and implementation components. - four documents covering the framework. Software Components The JAFAR framework offers a presentation tier architecture in which the framework users can plug their web pages and the control logic that they require. It is based on Sun s Service to Worker pattern [5]. For each use case the framework user provides a dispatcher that implements the use case s workflow and a number of JSP pages that take care of the presentation. The web pages are included in a template that is defined in the framework. This template includes a header with a menu that the application user can use to access the application s functionality. This mechanism is based on Sun s Composite View pattern [5]. The JAFAR framework provides a form validation mechanism. Forms that are submitted to the application are validated by verifying whether their fields match given patterns. A configuration file provides the information about the forms that is necessary for the validation. The framework takes care of the user management. It allows application users that connect to the web site to create a new account; it handles the user login/logout, and allows the application users to manage their account

3 information. When a user creates a new account, the account must be activated before he can sign in with it. To activate his account, the user has to enter a secret number that is sent to him via . This ensures that the users provide valid addresses. The framework provides a number of utility services: it offers a messaging service that offers a simple way of sending s to the application s users and it provides a batch job service that allows the framework user to specify tasks that will be executed asynchronously. The batch job service supports three types of scheduling: immediate, deferred and periodic execution. Pattern-based Transformations The framework provides transformation mechanisms that create implementation components based on their specification in a design model. These transformation mechanisms have been defined using Rational XDE s pattern engine. The framework provides two such transformation mechanisms: one that creates a session bean based on a component interface specification and one that creates an entity bean based on an entity class. In both cases additional classes are generated to implement common J2EE design patterns [5]. For the session beans the framework generates a business delegate and a service locator class. For the entity beans the framework generates an implementation of the Value Object pattern. Wizards The framework provides wizards that guide the users in their work. Some of these wizards create a basic structure consisting of empty diagrams and packages that help the framework user to get started with new aspects of the application. For instance, there is one wizard that creates a partial implementation of a dispatcher based on information provided by the user. Documents The framework comes with four documents: - User Guide of a Pattern Based J2EE Framework [8]. It presents the main components of the framework and explains how they should be used to build an application. - Using and Specializing a Pattern Based J2EE Framework: The PCOA case study [9]. It explains how the framework should be used to build an application by studying a concrete case study. - Detailed Design of a Pattern Based J2EE Framework [10]. Presents the main components of the framework and their interrelationships to developers who want to modify the framework to adapt it to their needs. - Meta Development with Rational XDE using its extensibility mechanism [11]. It presents the JAFAR framework s use of XDE s meta development features to developers who want to use them to modify the framework. 3.2 USING THE JAFAR FRAMEWORK The process of using the framework involves four different aspects: - Modifying the framework configuration file. - Using the utility classes and services that come with the framework. - Extending classes and implementing interfaces with objects that will be plugged into the framework to customize its behavior. - Using the transformation mechanisms and wizards that the framework provides. A first illustration of using the framework can be found in [12]. A complete mini-development of a web-application using JAFAR has been made for the LUXDEAL application. LUXDEAL is an e-exchange web application that allows its members to exchange goods and services. This development has involved two engineers for a period of two weeks. All the four aspects of using the framework have been practiced completely. This work is described in [13]. This micro-development has shown that the framework considerably simplifies the development of a J2EE based application. The most time consuming aspect of the development has been the implementation of the user interface. Future versions of the framework should offer more support in this area. The process of using the framework as described in [8] and in [9] has a significant impact on the process of developing an application with JAFAR. The process of using the framework requires the framework user to provide design models that will serve as inputs for the transformation mechanisms. Additionally, JAFAR requires the framework user to organize the functionalities of his application according to use cases and business packages. The use of the framework therefore has a direct impact on the whole development process of an application. 4. DESIGN OF THE JAFAR FRAMEWORK In this section we will present an overview of the architecture and the design of the framework. Overview WEB TIER EJB TIER Request Dispatching Messaging Form Validation Batch Job Figure 1 : JAFAR architecture Application code Application Components User Mgmt

4 The framework s software components can be organized into three categories: the components that provide the presentation tier architecture, the components that implement utility services and the user management components. The framework uses some libraries from the Apache Software Foundation s Jakarta project [14]. It uses the Regex library for regular expression support in the form validator and the Digester library to load the framework s XML based configuration files. 4.1 Web tier architecture When building a web-based application using Java one is confronted with APIs and tools that are mainly targeted at solving technical problems. Unlike Swing for example they do not provide a framework into which you can plug your code. The result is that when building a Java-based web application you need to define an architecture for your web tier. The JAFAR framework provides a web tier architecture into which the application developer can plug his JSP pages and the associated control logic. It provides a clear separation between the control aspects and the view aspects. The control logic that is needed to implement the use case workflow is implemented by dispatchers. The dispatchers forward the requests to the JSP pages which implement the views. The framework provides a form validation mechanism that is based on regular expressions. Form validation In [15], Luis Blando describes four types of form validation checks. 1. Meta checks: determine whether all the required data have been submitted. 2. Syntactic checks: are performed on the individual fields that have been submitted. 3. Semantic checks: involve field dependencies. 4. Domain checks/errors: form a super-set of the semantic checks. They describe checks that cannot be performed by using the information provided in the form alone. The current version of the JAFAR framework only handles the first two types of checks. Figure 2 below shows the main classes of the validation mechanism. «ServletFilter» ValidatingFilter ValidatingFilterConfigManager Figure 2 : ValidatingFilter classes Validator When a client makes a request to the application the framework first does some preprocessing on the request. This is done by the ValidatingFilter servlet filter, which is an implementation of the Intercepting Filter pattern [5] that provides a form validation mechanism. First, it copies the request parameters into request attributes. Then it retrieves the Form request attribute, which indicates the name of the form that has been submitted (or null if no form has been submitted). In order to validate the form, the validation mechanism needs to access the validator configuration for this form. It needs to know which validators should be used for each of the form s fields and it needs to get the definition of these validators. This information is stored in the framework configuration file, which is accessed using the ValidatingFilterConfigManager class. The ValidatingFilter checks whether the form s fields have legal values. For each field the validation mechanism tests whether the field s values match the regular expressions defined for the field s validator. The field validation is done using the Validator class. After having analyzed the field values the ValidatingFilter sets a request attribute indicating the outcome of the validation. As mentioned before, the ValidatingFilter retrieves the form validation information using the ValidatingFilterConfigManager class. This class uses the Digester library to load the configuration contained in the framework s configuration file into JavaBeans (see figure 3 below). ValidatingFilterConfigManager UseCaseConfig FormConfig FieldConfig FieldConfigParameter ValidatorConfig ValidatorRuleConfig Figure 3 : JavaBeans storing the validation mechanism configuration The developer can define a number of validators. Each validator corresponds to a particular type of data. For each validator, an ordered set of rules is defined. Each of these rules contains a regular expression that will be used to verify whether a field value complies with the rule. For each rule there is a help message. When the validation of a field fails, the help message of the first rule that has been violated is displayed to the user.

5 The rules and help messages can be parameterized. Parameters are indicated in the strings defining the rules and the help messages using a leading and a trailing %. The string between these delimiters is the parameter name. When a parameterized validator is used, the framework user needs to provide values for the validator s parameters. For each field the configuration contains the information about what validator should be used. If the validator is a parameterized validator the values for the parameters for this field have to be indicated. The forms are organized on a use case basis. Request dispatching DefaultUseCases «HttpServlet» PresentationRequestController ResourceMap «JavaInterface» IDispatcher DefaultDispatcher ApplicationDispatcher Figure 4 : Service to Worker pattern implementation in JAFAR The architecture of the presentation tier is based on the Service to Worker pattern [5]. Figure 4 above shows the main classes of the request dispatching mechanism. After having been processed by the ValidatingFilter the requests that are made to the application are handled by the PresentationRequestController servlet. It delegates the implementation of the use case workflow logic to dispatchers. There is one dispatcher per use case. The dispatchers extend the DefaultDispatcher class, which implements a few utility methods and common behavior for the dispatchers. The PresentationRequestController uses the attribute that the ValidatingFilter has set to determine whether the request contains form data whose validation has failed. If this is the case, the current web page is redisplayed with error messages added next to the fields that contained invalid values, allowing the user to correct the values he filled in. Thereafter, the PresentationRequestController determines what use case the request is for based on the UseCase request parameter. If the request does not include the use case name it determines a default one using the DefaultUseCases class. Once the use case name is known the PresentationRequestController uses the ResourceMap class to retrieve the corresponding dispatcher, and it invokes this dispatcher s handle method. The dispatcher then retrieves state information that is passed as request attributes and takes action based on it. Finally, the dispatcher forwards the request to the JSP page that should be displayed. 4.2 Batch job service The batch job service allows the framework user to create tasks that are executed asynchronously. It supports three types of scheduling: - Immediate execution. The task is executed as soon as possible. - Deferred execution. The task is executed at a specific time and date. - Periodic execution. The task is executed periodically starting at a given time and date. The constraints that are placed on components running in the EJB container make it impossible to implement such a service without having an external client which acts as a timer and that launches the execution of these tasks. The batch job service consists of four main components, which are illustrated in Figure 5 below. Entity Bean Manager Worker Figure 5 : Main components of the batch job service Timer Relevant classes and interfaces: - IBatchJobWorkerClass. It is an interface that is implemented to define what a batch job will do. It contains the method that is invoked when the job is executed. - BatchJobValues. It is a class that contains attributes representing the information about a batch job. This information includes the name of the worker class, the date at which the batch job should be executed (for timed and periodic jobs), and the period in milliseconds (for periodic jobs). The BatchJobManager is a stateless session bean that allows the framework user to access the services offered by the batch job service. It allows creating new batch jobs, retrieving information about pending batch jobs and removing pending batch jobs. The BatchJob entity bean is responsible for persisting information about batch jobs that will be executed in the future. The BatchJobWorker is a message driven bean. It is notified by the timer or by the BatchJobManager when

6 there is a batch job that has to be executed. The batch job execution consists of instantiating the worker class that the framework user has specified and executing its start method. The BatchJobTimer is responsible for notifying the BatchJobWorker when there is a batch job that should be executed. It is an independent Java application that communicates with the BatchJobWorker using JMS queues. When a batch job is to be executed immediately the timer does not need to be informed and the job information does not need to be persisted. The BatchJobManager only needs to send a JMS message to the BatchJobWorker, which will execute the job. 4.3 User management The user management consists of three modules: - The user interface - The account manager - The sign in logger The user interface that comes with the framework implements everything that is needed for the user management. The framework user only needs to access the user management services when he wants to retrieve account information about a user. The account manager is implemented as a session bean that uses entity beans to persist the user information. It offers the services that are needed to add users, to retrieve user information and to modify user information. The user information is split into two entity beans: one for the basic user information, such as, the user name, login name, address, etc., and another for the credit card information. The one-to-one reference between these beans is implemented by storing the primary key of one of the beans as a reference to the other. The sign-in logger is implemented as a session bean that relies on an entity bean to persist the sign-in attempts of the users. For each attempt it stores the login name and a boolean indicating whether the attempt was successful. 4.4 Messaging service The JAFAR framework includes a simple messaging service that can be used to send s. The service is implemented using a stateless session bean. It uses JavaMail to send s. The service is restricted to sending plain text s using an SMTP server. The name of the SMTP server and the default address for the sender can be set in the configuration file. 4.5 Utility classes The framework comes with a number of utility classes: TimeStampHelper class The TimeStampHelper class offers a number of methods that allow to convert between String, long and java.util.date representations of a date. MoneyFormat class The MoneyFormat class contains a method that allows formatting an amount of money for display. UID class The UID class generates the unique IDs for entities. The current version of the framework only contains a simplified version of a unique ID generator. It uses an incremental counter that is stored in a static attribute and relies on synchronization primitives to guarantee the uniqueness of the IDs. This violates some of the programming restrictions specified in section of the EJB 2.0 specification [16]. As a consequence it only works if the framework is running in a single virtual machine on a single server. 4.6 Transformation tools & Wizards The framework comes with a number of transformation tools that create implementation elements based on their specification in a design model and a number of wizards that assist the users in common tasks. Both are implemented using Rational XDE s pattern engine. Patterns can be defined in XDE using a parameterized collaboration. Each pattern contains a number of parameters and a number of UML model elements. When applying a pattern in XDE the model elements in the pattern are bound to the corresponding model elements in the target model by providing the parameter values. XDE s pattern engine then merges the model elements contained in the pattern with those contained in the model and adds elements as necessary. The way this is done can be configured for each model element. Additionally, XDE allows defining scripts that are executed when applying a pattern. The framework s patterns sometimes make use of this feature. These scripts can access the internal APIs of XDE and are therefore quite powerful but also hard to implement. 5. CONCLUSION The detailed design presented in this paper provides the reader with a way of building its own framework for a similar product line. Furthermore, JAFAR is integrated in a global software engineering approach to distributed

7 applications development in which methodologies and CASE tools are of major importance. [17] The JAFAR framework provides a presentation tier architecture, a user management service, a batch job service, and a messaging service. It provides transformation mechanisms and wizards to assist the developer in his work. The implementation of the framework makes full use of the J2EE platform. There are a number of known issues with the framework: - The validation mechanism should be extended to include semantic and domain checks. - The primary key generation mechanism needs to be re-implemented to work with applications that are distributed on multiple virtual machines on multiple servers. - The user account management service should define an event model allowing the framework developer to provide listeners for events like the registration of a new user. - The framework should provide tools that simplify the creation of a user interface. (e.g. wizards for creating web forms) - The batch job service should be extended to provide more control on how batch jobs are executed. - The framework should provide solutions to security requirements. The JAFAR framework provides an interesting basis for building web applications. It offers prefabricated solutions for some of the most common problems that developers face when building web applications. Additionally, it provides code generation tools that accelerate the work. 6. ACKNOWLEDGEMENT We would like to thank Wojtek Kozaczynski and Jim Thario who gave us a lot of input on all the subjects covered by this paper. We also would like to thank the other FIDJI team members who were of great help for this work. REFERENCES [1] N. Guelfi, D. Hammouche, P. Sterges, O. Biberstein, FIDJI Project Annual Activities Report, Applied Computer Science Department technical report n TR- DIA-02-01, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2001 [2] G. Butler, Object Oriented Frameworks, 15 th European Conference on Object-Oriented Programming, Budapest, Hungary, 2001 [3] B. Shannon, Java 2 Platform Enterprise Edition Specification Version 1.3, Sun Microsystems, [4] W. Kozaczynski, PearlCircle Online Auction Reference Application Software Architecture Document v0.3, [5] D. Alur, J. Crupi and D. Malks, Core J2EE pattern (Upper Saddle River, NJ: Prentice-Hall PTR, 2001) [6] Rational Software Corporation, Rational XDE product, [7], P. Clements and L. Northrop, Software Product Lines: Practices and Patterns (Reading, MA: Addison- Wesley Pub Co, 2001). [8] P. Sterges, B. Ries, User Guide of a Pattern Based J2EE Framework, Applied Computer Science Department technical report n TR-DIA-02-02, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [9] B. Ries, P. Sterges, Using and Specializing a Pattern Based J2EE Framework: The PCOA case study, Applied Computer Science Department technical report n TR- DIA-02-03, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [10] B. Ries, P. Sterges, Detailed Design of a Pattern Based J2EE Framework, Applied Computer Science Department technical report n TR-DIA-02-04, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [11] B. Ries, Meta Development with Rational XDE using its extensibility mechanism, Applied Computer Science Department technical report n TR-DIA-02-05, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [12] N. Guelfi, B. Ries, Using and Specializing JAFAR, A Pattern Based J2EE Framework: An Auction Case Study, Applied Computer Science Department technical report n TR-DIA-02-06, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002 [13] B. Ries, P. Sterges, Development of the PROTOLUX application using the JAFAR framework, Applied Computer Science Department technical report n TR- DIA-02-07, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, [14] The Jakarta Project, [15] L. Blando, A Framework for a Rule-Based Form Validation Engine, 1999 [16] L.G.DeMichiel, L.U.Yalçinalp and S.Krishnan, Enterprise JavaBeans Specification Version 2.0, Sun Microsystems, [17] N. Guelfi, G. Perrouin, Rigourous Engineering of Software Architectures: Integrating ADLs, UML and Development Methodologies, Applied Computer Science Department technical report n TR-DIA-02-08, Luxembourg University of Applied Sciences, Luxembourg-Kirchberg, Luxembourg, 2002.