260 Patterns: Implementing Self-Service in an SOA Environment
constructed, and the definition is added to the faces-config.xml configuration file,
it can be reused to validate any applicable JSF component.
For example, in the case of the ITSOMart application, we have defined a custom
validation class: EmailValidator. The EmailValidator
class implements a special
validation for e-mail addresses. Once defined and included in faces-config.xml,
the function is reused for e-mail format validation in multiple screens.
9.3.4 Error handling
The error handling on the ITSOMart front-end is relatively simple. Because this is
a sample application, we chose to spend more time on the sunny day scenario,
rather than on the rainy day one. The following sections focus on the design
considerations we contemplated when incorporating error handling to our JSF
Validation errors
The previous section discusses how data is validated, but does not describe how
validation errors are eventually presented to the user. There are a few options
available in the JSF framework using error display UI components.
Although it is possible to use a separate JSP error page, from a human factors
perspective, it is generally preferred to display input validation errors in the same
page where they were entered. In that case, we can follow two different
approaches. The validation errors can be shown specifically for each field, in
which case the error message is positioned right next to the component being
validated. The other option is to have a single error display field which displays
all the errors of the page. JSF offers UI components which accommodate either
In the ITSOMart application, we opted for the approach of associating validation
errors to each individual component. The approach of grouping all validation
errors in one place might have reduced screen clutter, but it requires some
specialized coding and configuration to work in a reasonable way. Associating
error display fields for each individual input component is relatively easy to
accomplish using Rational Software Architect, and offers a clear indication of
where the error occurred.
Figure 9-9 on page 261 shows a section of the Create Customer screen in the
ITSOMart application, illustrating the messages displayed in case of validation
Chapter 9. JSF front-end scenario 261
Figure 9-9 Create customer input validation
Application and system errors
There is nothing particularly unique about the way we handle application and
system errors in the JSF framework. Errors from the back-end are captured with
exceptions just as in any other Java-based application. What JSF does have in
its favor, is the flexible screen navigation framework that makes it quite simple to
redirect responses to the appropriate error pages. As we have seen before, JSF
actions return a plain outcome string, which gets mapped separately into a target
JSP page.
For example, assume our create customer action checks for the appropriate
exceptions, and chooses to report on the following conditions: a customer
already exists with that e-mail, there was a DB2 error inserting the data, or there
was another system exception (the
catch all case). In that case, our action
handler would return three possible error strings: duplicateEmail, dbError, or
systemError. Now all we would have to do is setup the navigation rules such that
these strings would direct the application to an appropriate JSP error page.
Better yet, many of the error pages and navigation rules can easily be reused for
all other pages.
Note that although we could have implemented that level of detail in the create
customer error handling, in reality we did not. As we mentioned earlier, we
wanted to concentrate our effort on other aspects of the technology. As it is, in
the ITSOMart application, all internal application or system errors map to the

Get Patterns: Implementing Self-Service in an SOA Environment now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.