| CONTENTS | PREV | NEXT | INDEX | Designing Enterprise Applications with the J2EETM Platform, Second Edition |
There are a variety of ways to internationalize J2EE applications:
- Use resource bundles in code--for programmatic control of internationalization; see Section 10.2.1 on page 316.
- Use custom tags--for JSP pages that vary by locale only in data values; see Section 10.3.3.4 on page 328.
- Use a separate JSP page for each locale--for pages that have a different structure for each locale; see Section 10.3.3.5 on page 330.
- Transform XML with XSLT--to internationalize XML content.
An application may use any or all of these techniques. This section covers the final option, using XML and XSLT to localize and communicate locale within and between applications.
One flexible way to create internationalized content is to use locale-specific XSLT stylesheets to style model data that are represented as XML. For example, an enterprise bean might use JMS to asynchronously send localized XHTML to a user by email.
XSL stylesheets are very effective for creating customized, dynamic structured content in any application tier. The application component (JSP page, servlet, or enterprise bean) can create XML that represents localized model data that are the results of a service request. An XSL styling component can then produce localized content, inserting and styling model data from the XML document. The name of the stylesheet that performs the localization is based on the requested locale, which is encoded in the XML itself. Localizations for new locales can be created by simply generating model data for the new locale, and then styling that data with a new XSL stylesheet. This approach cleanly separates business logic (the XML data) from presentation (the template text in the stylesheets).
An example of this approach, including a description of a way to communicate locale among decoupled application components, appears in Section 10.6.3 on page 338).
The Java programming language represents values of type String, StringBuffer, and Character as Unicode. As a result, enterprise bean methods that use these types consistently preserve international character values, including method invocations through EJB local and remote interfaces.
Enterprise bean business method signatures may include locale information when business logic depends on locale or where the data returned by a bean method is localized. Examples of enterprise beans whose behavior may be locale-dependent include components for tax calculation or shipping, or components that deal directly with external systems such as Web services or clients. A catalog enterprise bean might include method signatures with locale to indicate the language for viewing the catalog's entries.
Placing locale in session state can greatly simplify code localization. Instead of including a Locale argument in every business method signature, consider placing the current Locale in session state, either as an HttpSession attribute (for Web-only applications) or by using a stateful session bean (for applications using enterprise beans). A Locale stored in session state can be determined once, early in the session, and then used by all components for the remainder of the session.
Most large organizations have not one, but several mission-critical business applications. Seldom are these applications integrated "out of the box." The art of integrating disparate enterprise applications to work together as a whole is called Enterprise Application Integration (EAI).
A currently-popular EAI strategy uses messaging to link together coarse-grained, loosely-coupled applications. For example, Web services use Internet protocols and data formats (often HTTP and XML) to send and receive messages that are formatted as XML documents.
When one internationalized enterprise application requests a service from another application, the requesting application must somehow indicate the locale of the request, so that the data encoded in the request can be properly interpreted. J2EE applications often communicate among themselves and with other IT systems using XML message passing. In particular, EJB components may communicate with external applications using JMS to send and receive payloads of XML messages. Web-tier components may provide XML Web services via HTTP to end users or to other information systems. Each of these scenarios requires a way to indicate locale.
Applications that send XML messages should encode the locale of the request, the requested locale of the response, or both, as strings in an element of the XML message. The naming conventions used for resource bundles provide a useful and widely-understood way to represent a locale as a string.
Code Example 10.1 shows a sample XML message representing an invoice localized for the United States English locale. As in this case, the locale of the request and the response are usually the same, so only a single locale element is necessary.
<?xml version="1.0" encoding="UTF-8"?> <invoice> <orderid>1234</orderid> <locale>en_US</locale> </invoice>
| Code Example 10.1 Sample XML Message with United States English Locale |
The same message with a Japanese locale appears in Code Example 10.2 below.
<?xml version="1.0" encoding="UTF-8"?> <invoice> <orderid>1234</orderid> <locale>ja_JP</locale> </invoice>
| Code Example 10.2 An XML Message with Japanese Locale |
Note that the string used to represent the locale follows the naming convention for resource bundle class name suffixes. Choose a universal encoding such as UTF-8 for all such XML messages, and be sure to include the document encoding in the XML declaration, as the code examples show.
A message receiver may use the locale encoded in the request to localize the content of an XML message it receives. The sample application contains a multilingual mailer application that transforms XML messages into localized emails to customers. A sample scenario appears in Figure 10.6 above. In this diagram, an EJB component in Application 1 sends an XML message via JMS to a multilingual mailer application. The mailer application receives JMS messages (using a message-driven bean), localizes the message contents, and sends the localized contents as emails to users.
The message-driven bean in the mailer application receives and merges the XML payload (invoice.xml) of each JMS message with a stylesheet containing template text. The bean selects an XSL stylesheet based on the incoming message type (inv in this case) and the requested locale. The stylesheet contains XSL template rules that create email body text by inserting values from the XML document into localized template text. The result of the XSL transformation is an email message localized to the locale requested by the incoming message.
This flexible solution provides a simple way to extend the mailer application for new locales. To add a new locale, a developer need only generate localized values from the model (as XML), create an XSL stylesheet for the new locale, and follow the stylesheet naming convention. The mailer application will correctly style incoming messages for the new locale.
Notice that this design maintains MVC separation: The data sent in the XML message is model data, the XSL stylesheet generates the view (the "view" is the email being sent to the customer), and the bean acts as a controller that selects and assembles the view. The stylesheet in this design acts much like a JSP page, outputting template text with dynamic data values matched from the XML document. Yet this example does not use the Web tier at all: It occurs entirely in the EJB tier and in message-oriented middleware.
MVC separation is especially important for enterprise application integration, because enterprise applications communicate most effectively at the level of data and application model. Legacy interface engines that rely on "screen scraping" exist solely to simulate an application model by interacting with a view. The legacy interface layer would be entirely unnecessary if the model were available directly as a service.
The example presented above shows just one way that locale that is communicated between applications may be used to produce localized content.