Patterns: Implementing Self-Service in an SOA Environment

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

application.

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

approach.

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

errors.

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