J2EE Architecture Best Practices (Continued)

In most applications, unfortunately, security does not appear to add any real business value, so it gets swept under the rug until the end. When this happens, security-related code just gets bolted on without any consideration of the solution's long-term maintainability or robustness. Another symptom of this security neglect is the absence of comprehensive server-side validation, which, as I illustrated in Lesson 1, is an important part of a secure Web application.

Remember, security in a J2EE Web application is not just about using the proper declarations in the web.xml or ejb-jar.xml file, or about using J2EE technologies such as Java Authentication and Authorization Service (JAAS). It is about having a well-thought-out plan and then implementing an architecture that supports it.

Lesson 3: I18N is Not a Just a Buzzword Anymore
The reality of today's world is that non-native English speakers will access your public Web application. This is especially true with e-government initiatives that allow constituents (residents of a state) to interact with their governmental agencies online. Examples include renewing your driver's license or vehicle registration. Many people whose primary language is not English will likely access such applications. Internationalization (or "i18n" because there are 18 characters between the "i" and the "n" in "internationalization") enables your application to work in multiple languages.

Obviously if you have hard-coded text in your JSP pages, or if your Java code returns hard-coded error messages, then you will have a tough time creating a Spanish version of your Web application. However, text is not the only piece that must be "externalized" in a Web application that supports multiple languages. Graphics and images should also be configurable because many images have text embedded in them. In extreme cases, images (or colors) that mean one thing in one culture portray a completely different meaning in another culture. Similarly, any Java code that formats numbers and dates must be localized. But, here's the biggie: Your page layout might require change as well.

For example, if you use HTML tables to format and display your menu options, application headers, or footers, then you might have to change the column widths at a minimum and possibly some other aspects of the table for each supported language. To accommodate for varying colors and fonts, you might have to use a separate stylesheet for each language.

It should be obvious by now that creating an "internationalizable" Web application is an architectural challenge rather than an application challenge. A well-architected Web application means that your JSP pages and all business-related (application-specific) Java code are oblivious to the selected locale. The moral here: Don't take internationalization for granted just because Java and the J2EE platform support it. You must architect your solution with internationalization in mind from day one.

Lesson 4: Avoid Common Mistakes With MVC Presentation
J2EE development has matured enough that most projects use some form of an MVC architecture, such as Struts, on the presentation tier. A common theme I see in such projects is the misuse of the MVC pattern. Here are a few examples.

A common misuse is that all the business logic is implemented in the model layer (for example, in the Action Beans in Struts). Remember that the presentation layer's model layer is still part of the presentation layer. The proper way to use this model layer is to call the appropriate business layer services (or objects) and forward the results to the view layer. In design pattern terms, the MVC presentation layer's model should be implemented as a Façade for the business layer. Better yet, use the Business Delegate pattern discussed in Core J2EE Patterns. This excerpt from the book elegantly summarizes the gist and benefits of implementing your model as a Business Delegate:

The Business Delegate acts as a client-side business abstraction; it provides an abstraction for, and thus hides, the implementation of the business services. Using a Business Delegate reduces the coupling between presentation-tier clients and the system's business services. Depending on the implementation strategy, the Business Delegate may shield clients from possible volatility in the implementation of the business service API. Potentially, this reduces the number of changes that must be made to the presentation-tier client code when the business service API or its underlying implementation changes.