ECLIPSE WEB TOOLS PLATFORM developing java web applications PHẦN 3 docx

In the following sections, we discuss the basic object structure of Web MVC

frameworks (see Figure 5.4). This architecture is implemented by many of the

previously mentioned frameworks.

124 CHAPTER 5 • Web Application Architecture and Design

Model

JSP Page

Controller

Action

<<web>>

Input

Controller

Output

Controller

<<wap>>

Input

Controller

Web Service

Controller

JSP

XML

Input

Controller

Application

Controller Business

Logic

http

wap

Figure 5.4 MVC for the Web

Input Controller

The input controller is a central feature. There is a single input controller for all

pages in a Web application. The input controller parses input, determines the

parameter-passing mechanisms, extracts any necessary information from the

request, cooperates with the application controller to determine the next opera￾tion (typically called an action), and invokes that action in the correct context.

By having a single component as an input controller, any knowledge of HTTP or

naming conventions is localized at the request level. This reduces the amount of

code duplication and the total size of code. This also makes it easier to modify

any of the input processing functions because there is a single point of modifica￾tion. Note that the input controller component is typically a servlet, and there

may be one instance for accessing the applications over HTTP via a regular Web

browser and another instance for mobile applications using a Wireless

Application Protocol (WAP) enabled device.

Application Controller

The application controller is typically a regular Java object. It coordinates logic

related to the application flow, handles errors, maintains longer-term state (includ￾ing references to the business objects), and determines which view to display. The

application controller needs to understand requests, and how they participate in

the organized flow of the application, and forward these requests to the planned

responses. Web requests are HTTP encoded, string, and string-based key-value

pairs. Application controllers typically need a mapping of these input keys to the

application objects that manage the flow. Most frameworks maintain these map￾pings in complex XML configuration files, such as the struts-config.xml file

used in Struts. For example, URI sequences like the following are known by the

input controller,

/leagueplanet/addPlayer.do

This relies on a naming convention, with the disadvantages described earlier,

but because this is the only component used in this way, the impact is minimized.

In a better design, a single application controller is typically responsible for mul￾tiple Web pages and activities. In a simple application, a single application con￾troller might be responsible for all pages. In a complex application, there are

typically multiple application controllers for the different areas of the applica￾tion. By using a single, well-encapsulated object as the central point of reference

for encapsulating information, the application controller resolves the issues of

information hiding and naming conventions. Rather than storing isolated pieces

of information in the session, the information can be stored in business objects

and accessed using messages from the application controller. Programming lan￾guage mechanisms let you track the use of the application controller and busi￾ness objects, making it easier for you to modify your code. You also get static

type checking as an additional validation of data usage.

There are several designs for application controllers. The Struts framework

refers to them as actions while JSF calls them managed backing beans. In Struts

there can be many actions. For example, if your application has two use cases

that support creating teams and adding players to these teams, you may perform

these using two corresponding actions. The program listing in Example 5.2 is a

summary of how these action classes might look in a Struts application.

Example 5.2 Struts Action Class Example Code

public class CreateTeamAction

{

public void execute(..){}

}

Web Applications 125

public class AddPlayerAction

{

public void execute(..){}

}

Clearly, these team and player actions are related. For example, you add

players to teams. However, Struts does not have a mechanism to group the

actions. For example, multiple actions that are a part of the same flow, like an

online registration process, cannot be grouped.

This shortcoming in Struts is addressed by other Struts-based frameworks,

such as the Eclipse Pollinate project, where the application controller is a Java

object called the page flow. The page flow is a class that encapsulates a group of

actions as methods and defines a structure for describing the flow between them.

In Pollinate, you would have implemented the same use case using a single page

flow class. The action classes and their behavior shown in Example 5.2 would

have been implemented as methods in a page flow.

The program listing in Example 5.3 demonstrates the ability to group actions

and associate them with an object, such as the page flow. Having an application

controller for a related group of actions increases your ability to express the appli￾cation logic. Additionally, you can maintain state for this flow in an object rather

than using HTTP specific request and session APIs.

Example 5.3 Page Flow Class Example Code

public class LeaguePlanetPageFlow extends PageFlowController

{

public Forward createTeam(){..}

public Forward addPlayer(){..}

}

The two most popular MVC implementations for Java Web applications,

Struts and JSF, are very similar in concept. Some claim that JSF is closer to MVC

than Struts due to the availability of a rich stateful component set at the view

layer and support for an event-based model to manage controller interactions

(e.g., button-clicked events). JSF also provides an extensive standard tag library

to reduce the amount of Java code in JSPs (see Example 5.4).

Example 5.4 JSF JSP Tags

<h:panelGroup>

<h:commandButton id="submitCreateTeam" action="#{JsfLeaguePlanetBean.createTeam}" value="Create Team" />

<h:commandButton id="submitAddPlayer" action="#{JsfLeaguePlanetBean.addPlayer}" value="Add Player" />

</h:panelGroup>

126 CHAPTER 5 • Web Application Architecture and Design

However, one must always keep in mind that these frameworks exist on top

of the stateless HTTP protocol. JSF has the concept of an application controller

in the form of managed backing beans (see Example 5.5). These beans can

encapsulate a group of related activities, a capability that Struts lacks. Finally,

the concept of page flow does not exist in either JSF or Struts. This information

is implicit in the controllers and XML-based configuration files.

Example 5.5 JSF-Managed Backing Bean

public class JsfLeaguePlanetBean

{

public String createTeam(...){}

public String addPlayer(...){}

}

The input controller will invoke one of many possible actions on each request.

One of its responsibilities is to determine the correct action to invoke. This deci￾sion depends on both the input from the client and the application’s current state,

so it is determined by the application controller. We represent the result of this

determination as the ApplicationController object (ApplicationController is

an implementation of the Command pattern described in [Gamma1995]).

Business objects are plain Java objects that contain only business logic. They

should have no knowledge of any other layers. The application controller is the only

component that manipulates the business objects (see Figure 5.4 earlier). These char￾acteristics make it much easier to develop and test the business logic in isolation from

the Web infrastructure. If the application is designed properly, the business objects

are isolated, allowing you to use the same implementation for a thin-client Web

application, a more rich-client implementation, or even a traditional desktop UI.

View

In a J2EE application, views are typically JSPs that can access the application

controller and business objects. Views should contain as little code as possible,

delegating most functionality to the application controller or business objects.

Only code directly related to presentation in the current page should be used in a

page. The JSP specification also defines tag libraries (taglibs) for defining cus￾tomized JSP tags that encapsulate complex view layer behavior. It is preferable to

use taglibs to create custom tags to remove complex code from the pages alto￾gether. Figure 5.4 (earlier) shows two different view mechanisms. The JSP Page

Controller uses a JSP implementation appropriate for a Web browser or WAP

device. The Web Service Controller responds to the same request and produces

an XML response suitable for consumption by other applications, such as a

.NET system, or a rich-client application.

Web Applications 127

128 CHAPTER 5 • Web Application Architecture and Design

beehive beehive beans

Presentation

beehive mvc Struts jsfjsf

Business Logic

beehive

Data

beehive dao

beehive beans

Figure 5.5 Java Application Framework

OSGi

The OSGi Alliance (formerly the Open Services Gateway Initiative) defines a standard

for providing Java-based service platforms.The specification defines a framework for

an application life cycle model and a service registry.

OSGi implementations such as Eclipse Equinox, Felix, and Knoplerfish provide com￾plete and dynamic component models, something that has been missing in standard

Java runtime environments.This means applications or components, which are called

OSGi bundles, can be installed, started, stopped, updated and uninstalled, even

remotely, without requiring a reboot.

Java Application Frameworks

There are a number of Open Source Java frameworks that help implement Web

application best practices. In this section we’ll quickly review some of them

(see Figure 5.5). These frameworks simplify development of Java Web applica￾tions. They provide capabilities that improve the testability and maintainability

of the code and simplify development. They separate architectural concerns and

integrate well with application servers.

Apache Beehive

The Beehive project provides a framework for lightweight, metadata-driven

components that reduce the coding necessary for J2EE. Beehive addresses all

three layers of Web applications. The framework is based on annotations, partic￾ularly JSR 175 metadata [JSR175]. It uses other Apache projects such as Struts

and Axis. It has NetUI for presentation, Controls framework for lightweight

components and Web Service Metadata (WSM), an implementation of JSR 181,

and an annotation-driven model for building Java Web services [JSR181].

Apache Struts

Apache Struts is a framework to provide a control layer based on standard Java

Web technologies, like JSPs and servlets, and other Apache projects. It is a varia￾tion of the MVC design pattern.

JavaServer Faces

JSF is a JCP standard, JSR 127 [JSR127], that defines a set of JSP tags and Java

classes to simplify Web UI development. It is hoped that JSF will standardize

tools and components by providing a single-component framework for JSP and

servlets. JSF provides a framework for the presentation layer and also draws on

the MVC concepts. JSF is a part of the Java EE 5 specification.

Spring

Spring offers a framework that covers the complete stack of the layers in a

Java Web application. The framework implements the Inversion of Control

and Dependency Injection design patterns uniformly across all components. It

provides Spring MVC and Web flows for the presentation layer. It provides a

light-weight container to implement the business logic using POJOs, and there￾fore claims to eliminate the need for EJBs. It also provides solutions to manage

the application data.

Web Applications 129

OSGi is gaining momentum as a general service platform because it can scale from

embedded devices to enterprise systems. Eclipse, and therefore WTP, is an example of

an OSGi-based system. IBM and BEA are building their next-generation application

servers using OSGi platforms. What is more interesting is that we can also use OSGi

to develop simple business components and services that are assembled in runtime to

provide business services. For example, you can run Spring 2.0-based applications on

OSGi runtimes.

Pico Container

Pico Container is a light-weight framework that is also based on the Inversion

of Control and Dependency Injection patterns. Similar to Spring, it also grew

as a reaction to the complexity of J2EE development, specifically against the

difficulties associated with EJB development.

Hibernate

Hibernate is an Object Relational Mapping (ORM) framework. It allows

developers to implement object relational persistence and query services for

POJOs without any modifications to Java code.

The EJB3 Entity Beans specification, and specifically the Java Persistence API

(JPA) that has evolved from it, increases the attractiveness of Hibernate and

ORM frameworks alike to solve this difficult problem.

Service-Oriented Architecture (SOA)

SOA is about separating parts of your business into meaningful units, called serv￾ices, and building applications that are integrated using services. Service orientation

is encapsulation of business logic. A service is an application of a fundamental OO

concept, separating the implementation from the interface. Combined with stan￾dard languages such as XML, common protocols for transport such as HTTP, and

the capability of searching and binding to a service provider at runtime, SOA has

rapidly become the preferred integration technology for a diverse set of systems.

SOA and Web services are based on many standards such as XML; XML Schema;

Web Service Description Language (WSDL); Universal Description, Discovery, and

Integration (UDDI); SOAP; JAX-RPC; and many WS-* specifications. A detailed

description of SOA is beyond the scope of this book. However, we will describe

how you can use WTP to build service-oriented Web applications, primarily using

Web service technologies.

Providing Services: The Service Layer

The purpose of the service layer in your application is to expose your business

and application capabilities as services. Your applications are only as interesting

as the clients that use them. The classic question, if a tree falls in the forest and no

one is there to hear it, does it make a sound? applies here.

Many types of clients can use services:

❍ Rich Client Applications that consume services from many providers

❍ Embedded Systems, such as mobile phones

130 CHAPTER 5 • Web Application Architecture and Design