Patterns: Implementing Self-Service in an SOA Environment

Chapter 9. JSF front-end scenario 257

flow could change, and after creating a profile, the customer might be forwarded

to a different area to enter additional details. In that case, we could simply

change the navigation rule on web-config.xml, such that createSuccess would

now lead to a new page called CustomerDetail.jsp. This would be done without

having to touch any of the JSP files, or Java classes.

9.3.2 JSF managed bean design

Once we have designed the end-to-end screen flow of our JSF application, we

need to understand how data is exchange between screens, and how the

back-end functions are accessed. In JSF, this is accomplished by the use Java

beans managed by the JSF framework.

The managed beans can be declared with four different scopes:

򐂰 Request

The bean is persisted between two pages, the current page and the target

next page, or on a page reload. In that case, the bean is stored in the

HTTPServletRequest.

򐂰 Session

The bean is stored in the HTTPSession and exists for the life of a user’s

session.

򐂰 Application

The bean is stored in the ServletContext and exists for the life cycle of the

JSF application, with one instance for all users.

򐂰 None

The bean is not stored anywhere, and can only be used as a temporary

variable

From a logical perspective, managed beans are used in multiple ways in the JSF

applications. In the following sections, we discuss the different applications of

managed beans, and specifically how they are used in the ITSOMart front-end.

Backing beans

A typical Faces JSP page is composed of multiple input and output UI JSF

components (text fields, output texts, selection lists, and so on). Backing beans

are managed beans used to bind these UI components to Java objects that can

be accessed by the application.

When using Rational Software Architect to create a Faces JSP page, a backing

bean is automatically created, and a definition for it is added to the

faces-config.xml file. This bean will be used to bind with the JSF UI components

258 Patterns: Implementing Self-Service in an SOA Environment

in the JSP page. Although technically speaking we could edit the configuration

file and change this JSP to bean mapping, there is no particular reason to that.

Therefore, following this default behavior, the design of the ITSOMart application

is such that each JSP page will have a unique corresponding backing bean.

The backing beans are declared with request scope. Because the bean’s

purpose is strictly to interact with the one JSP file in particular, there is no reason

its information needs to be stored beyond the request.

Action beans

In addition to rendering data, the other key operation in a Faces JSP page is to

trigger an action. These actions cause the application to perform some operation

and might include navigating to another page. They are triggered by JSF UI

components such as command buttons and links.

From a JSF design perspective, we could declare a managed bean dedicated

explicitly to handle actions. However, this is not strictly necessary. The default

behavior of Rational Software Architect is to create an action handler method in

the standard backing bean associated with the JSP page. In that case, the

backing bean is logically also an action handling bean.

The ITSOMart front-end follows the simple approach of placing the action

handler on the backing bean. There is little need for dedicated action classes,

since the relevant operations are already clearly isolated in the

OrderSystemSessionFacade object, as seen in the object model on 9.2.3,

“Object model” on page 246.

For example, again using the create customer case, the pc_CreateCustomer

backing bean has a doCreateCustomeAction method. This method is bound as

the handler for the Create button (a JSF <hx:commandExButton> UI component)

on the CreateCustomer.jsp page.

Data beans

Although backing beans get and set data on a specific page, they are not meant

to carry data across multiple screens. Therefore, if an application has persistent

data which needs to be carried through to multiple screens, a dedicated

managed bean is generally used for that purpose.

The scope of the data bean depends on the requirement of the application. The

most common scenario for e-business applications, is probably that a certain

amount of data gets carried through a user session, the shopping cart being the

classic case. In that case, the managed bean should be declared with session

scope. The declaration of the data bean is done in the faces-config.xml

configuration file.