2. Literature review
2.1. Chapter overview
Having defined the problem to be solved in the previous chapter, this section of the report provides an overview of the J2EE platform used to develop the Online Project Marking System. This chapter also discusses the selection of J2EE design patterns and development framework.
2.2. J2EE platform
The Java 2 Platform, Enterprise Edition (J2EE), developed by Sun Microsystems, is a platform-independent development environment for Java based enterprise applications. J2EE provides support for a number of components which extend the Java 2 Platform to facilitate the development of web-based applications; namely Enterprise JavaBeans, Java Servlets API, Java Server Pages (JSP) and XML technology [J2EE (2005)].
The previous implementation of the Online Project Marking System was developed using J2EE and it was the client’s requirement for the new version to be based on the same technology. Due to this constraint, the suitability of alternative technologies such as PHP or the .NET framework has not been considered; instead, the following sections will focus more upon issues relating specifically to the J2EE platform.
2.2.1. J2EE components
The two most common J2EE components used for the development of web-based applications are Java Servlets and Java Server Pages (JSP). Servlets are Java programs which, once deployed in a servlet container, receive and process HTTP client requests, initiate server side resources and generate responses to be sent to the client. When compiled, a JSP page also becomes a servlet and, as such, either component could essentially be used to achieve the same goal. The main differences between JSP and servlets lie in their development: JSP is written as an HTML document with Java code embedded in the page, whilst servlets are developed as Java classes which generate HTML as their output.
Depending on the type of application being developed, either one of the technologies might be more appropriate – typically JSP is best suited to presentation oriented applications, whilst servlets provide a higher degree of maintainability for applications which perform complex processing. In some situations, an application such as the Online Project Marking System will fit in to both categories, requiring a complex interface which is driven by a sizeable amount of underlying business logic. In cases such as this, a more effective solution can be derived from the combination of the various J2EE technologies.
2.3. Software design patterns
Software design patterns are pre-defined solutions to recurring problems in software engineering. Although many patterns exist which can be applied to a wide range of platforms, the Sun Java Center has also published a set of patterns relating specifically to J2EE development projects [Alur, et al (2003)]. As Winn and Calder (2002) explain, adherence to software design patterns can significantly aid the process of development by providing expertly verified solutions and accepted standards for good practice.
2.3.1. The Model View Controller (MVC) pattern
One design pattern which has been adopted across a wide range of software development projects and platforms is the Model View Controller (MVC) pattern. The main concept behind MVC is the separation of design concerns in application development into three layers – the Model, View and Controller. The model component manages the business logic and application state, the view renders the model for display to the user and the controller translates interactions with the view into actions performed by the model. Figure 2.1 shows how the MVC layers are connected.
Figure 2.1 - MVC layer interaction [MVC (2005)]
The separation of design concerns through the use of MVC exposes a number of possibilities, including the ability to build a number of alternative view components which utilise the same model and controller. In addition, collaborative developments can be approached with more confidence and ease when the various components have been clearly separated.
As we mentioned above, J2EE technologies can be combined in order to achieve more effective application designs. In terms of J2EE developments, the MVC design pattern is embodied by the so-called Model 2 architecture where Java Beans are used to represent the model layer, JSP pages for the view and Java Servlets for the application controller. When a request is sent to a Model 2 application, the controller servlet initiates state changes in the model though the instantiation and manipulation of one or more JavaBeans. At the stage where a response is to be generated, the controller servlet selects an appropriate JSP page to supply the view. Figure 2.2 provides a diagrammatic representation of a typical Model 2 application.
Figure 2.2 - A Model 2 application [Seshadri (2005)]
Let us take the example of an application comprising of thirty controller servlets, fifteen of which generate their response by forwarding to a common view component - page1.jsp. The application is taking advantage of its opportunity to reuse the one view component by sharing it with a number of different operations. However, changes to the application structure, such as the redirection of the fifteen operations to a different view, page2.jsp, would result in maintenance being required on all of the fifteen controller servlets.
[SJP1] Offutt (2002) identifies maintainability as one of the key indicators of a high quality web application. The J2EE Front Controller Pattern [Front Controller (2005)] provides a means of enhancing this important characteristic in a typical Model 2 application.
2.3.2. The J2EE Front Controller Pattern
The Front Controller approach provides a mechanism for centralising request handling within a J2EE application [Alur, et al (2003)]. Centralisation is achieved through the provision of a single entry point for all requests - the Front Controller servlet. Traditionally, the Front Controller is used in conjunction with an Application Controller (also called a Dispatcher), responsible for action and view management. Action management refers to the process of locating actions to service particular requests, whilst view management relates to the selection and dispatch of appropriate views to form responses to requests.[SJP2]
The sequence diagram in Figure 2.3 illustrates how the Front Controller captures all incoming client requests and delegates to the Dispatcher to perform action and view management.
Figure 2.3 - Front Controller sequence diagram [Front Controller (2005)]
The primary advantage of using the Front Controller approach is that common control logic can be applied to all requests by the centralised controller. As we have already mentioned, action and view management is performed centrally but there are many other operations which can be more efficiently processed centrally such as authentication, error handling, logging and connections to persistence layers. The centralisation of such operations above all things helps to minimise the amount of duplicated control logic. Looking back at the typical Model 2 application described in the previous section, the Front Controller approach provides the same advantages, inherited from the MVC design pattern, but also provides a higher level of maintainability through the minimisation of duplicated code.[SJP4]
2.3.3. The Business Delegate Pattern
Another design pattern which supports the MVC approach of the separation of concerns is the Business Delegate Pattern [Business Delegate (2005)]. The Business Delegate Pattern provides a means of untying business (model) components from the application (controller) logic which uses them. The separation is achieved through the provision of an intermediate class called the Business Delegate which provides a set of interface methods (an Application Programming Interface) to hide the underlying complexities of interactions with business services.
The sequence diagram in Figure 2.4 illustrates how the Business Delegate acts as an intermediary between clients and the business-tier. Interactions with the Business Delegate interface by the client trigger, the look-up and invocation of business services.
Figure 2.4 - Business Delegate sequence diagram [Business Delegate (2005)]
There are a number of advantages to be gained from the adoption of the Business Delegate Pattern. Firstly, applications become more maintainable. The centralisation of the business-tier implementation in the Business Delegate provides a single point for maintenance. In addition, the clear separation of the business and application logic reduces the possibility that other components of the application will be affected by changes to the business-tier. Another advantage is that the Business Delegate provides a standard interface for clients to interact with business services; this ensures consistency in the usage of business services throughout the application.
2.4. [SJP5] J2EE development frameworks
We have seen how patterns can provide essential guidance for ensuring that good design practices are followed. Software development frameworks can also provide a number of benefits including the ability to re-use standardised application components and, in some cases, to provide one tier of an application in toto or in part.
Johnson (2005) highlights J2EE’s failure to provide adequate frameworks for enterprise application development, and explains how this lack of support has resulted in some organisations (typically larger companies) developing their own in-house frameworks. However, an increasing demand for standardisation in this area has also resulted in the emergence of a number of open source development frameworks.
2.4.1. Open source J2EE development frameworks
Johnson (2005) outlines some of the advantages offered by a well-designed open source development framework.
1. Firstly, the provision of re-usable, customisable components allows developers to create applications with minimal coding.
2. Also, the use of a framework ensures that applications follow a clearly defined and consistent structure which is especially useful for collaborative developments.
3. A further advantage provided by open source frameworks, compared with in-house solutions, is that they tend to be more thoroughly tested and are distributed with detailed documentation and example applications. Also, the fact that they are more widely used implies that they should be higher quality.
In terms of web application development, the most widely used open source framework at the time of writing is Jakarta Struts. This framework will be covered in more detail in the next section.
Another example of an open-source development framework, designed for providing access to persistent storage in the business layer of Java applications, is Hibernate developed by JBoss, Inc [Hibernate (2005)]. Hibernate addresses the problems and complexities associated with performing database access via JDBC by providing a means of mapping relational database tables to Java Objects.
It remains to be seen whether Sun Microsystems will address Java’s apparent deficiencies in terms of its provision of development frameworks; or if the number of open-source architectures supporting J2EE development will continue to rise in the future.
2.4.2. Jakarta Struts
Struts, a project of the Apache Software Foundation, provides the controller component of a Java Web Application and supports integration with a number of other technologies to enable development of the model and view components. In terms of the model component, Struts integrates with JDBC, EJB and third-party technologies such as the previously mentioned Hibernate framework. To support development of the view component, Struts provides a set of five tag libraries classed as view helpers and integrates with JSP, JSTL (JavaServer Standard Tag Library) and JSF (JavaServer Faces) [Struts (2005)].
The Struts controller consists of five core component classes [Husted, et al (2003)]. When building a Struts based application, it is these classes which are programmed and configured by developers in order to achieve the required functionality.
1. The ActionForward class is used to define hyperlinks within a Struts application. Each ActionForward object is assigned a logical name and path which is typically defined within an XML configuration file. The great advantage of the ActionForward object is that other components of the application, such as a JSP page, can refer to it by its logical name. This means that a change in a hyperlink can be cascaded throughout a Struts application by modifying the ActionForward in the configuration file.
4. The ActionForm class is responsible for the processing of HTML form input. The ActionForm performs validation based on rules which can either be programmed or configured via XML. In the event of an input error, the ActionForm redisplays the form to the user with the appropriate error messages. The ActionForm is a JavaBean with a set of properties which mirror the input fields of the HTML form. The main advantage of the ActionForm is that Struts automatically populates its associated properties with HTML form data, thus removing the need for developers to write code to extract form data from the HTTP request.
5. The Action class is defined to process HTML form data. Once an ActionForm has been validated, Struts passes it on to the Action specified in the HTML form action parameter for processing. The Action class is customised by developers in order to perform specific functions with the ActionForm data. An Action finishes by returning an ActionForward object to the controller which determines the response which will be sent back to the user.
6. The ActionMapping class provides a means of associating Action objects with a URI so that they can be referenced in an HTTP request. An ActionMapping specifies the request path and the Action to execute when the request is received. The ActionMapping can also be used to associate the Action with an ActionForm and a collection of ActionForwards. The main advantage of ActionMappings is the opportunity they provide for the reuse of Actions for multiple ActionMappings.
7. Struts implements the Front Controller Pattern described in section 2.3.2 through the provision of its ActionServlet class. The ActionServlet, when deployed in a servlet container, acts as the single entry point for all requests made to a web application. The primary function of the ActionServlet is to parse the ActionMappings located in the controller configuration file in order to locate and instantiate Actions and ActionForwards associated with the request URI. The ActionServlet is also responsible for the implementation of role based security and view selection.
[SJP6] In section 2.3.1 we examined the MVC design pattern, Table 2.1, taken from [Husted, et al (2003)] shows how the core Struts classes outlined above are related to the MVC pattern.
|
Class |
Description |
|
ActionForward |
A user gesture or view selection |
|
ActionForm |
The data for a state change |
|
ActionMapping |
The state change event |
|
ActionServlet |
The part of the Controller that receives user gestures and state changes and issues view selections |
|
Action classes |
The part of the Controller that interacts with the model to execute a state change or query and advises the ActionServlet of the next view to select |
Table 2.1 - Core Struts classes as they relate to MVC [Husted, et al (2003) p.45]
Having defined the core Struts classes, Figure 2.5 shows how they interact in order to process client requests.
As Husted et al (2003) explains, there are many advantages of using the Struts framework, the first being a great deal of flexibility for integration with the model and view components. In addition, the framework is relatively lightweight with only five tag libraries and five core classes for developers to become familiar with. Another important factor is the large amount of support available both from the vendor and developer communities, documentation [Struts Documentation (2005)] and example applications. Having said this, it should be taken into account that since the framework is open source, vendor support is not guaranteed and developer communities may not necessarily provide correct information.
Struts has been criticised by some for its implementation of the MVC design pattern. Knight and Naci (2002) highlight the potential for blurred application control and business logic within the Action classes, thus contravening the principles of MVC. It is, however, safe to assume that any developer wishing to adopt the principles of MVC would avoid such bad practice.[SJP7]
Figure 2.5 - Struts sequence diagram [Garnier (2005)]
|
2. The view extracts and displays data held in a HelperBean created by the Action. 3. The view extracts and displays data held in the ActionForm processed by the Action.[SJP8] |
Having researched alternative J2EE Web application frameworks, the current potential contender to Struts is the WebWork project [WebWork (2005)] from Open Symphony. WebWork is built upon the XWork framework [XWork (2005)], also from Open Symphony, and claims in its documentation [WebWork Documentation (2005)] to be superior to Struts in a number of areas. One example relates to the threading model employed, Struts instantiates one Struts Action for all requests with the implication that the Struts Action and all resources that it holds must be thread safe. WebWork claims that this mechanism is restrictive and instead instantiates a new WebWork Action for each request, therefore removing the need to thread safety.
Despite WebWork’s claims, the fact that Struts is widely documented both on the Internet and in printed literature indicates its popularity as a framework for J2EE Web development. It does not mean to say that in the future WebWork may become a stronger competitor as it matures in development and becomes more widely known.
2.5. Chapter summary
This chapter has outlined the J2EE platform and some of the associated design patterns and development frameworks which exist to support the development process. Having defined the technologies which have been used to devise the solution for this project, the next chapter will explain how the project requirements were established and documented.