O'Reilly logo

Patterns: Implementing Self-Service in an SOA Environment by Fernando Teixeira, Shashi Shrimali, Peter Hood, Sandy Grewal, Diego Cotignola, Anup Aggarwal, Carla Sadtler

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required