Page 2 of 2   « previous page

Using ResourceBundle - The Java Way
J2SE applications store all locale-specific resources in classes called resource bundles. Resource bundles support internationalization by separating localized data from the code that uses it. Each ResourceBundle instance contains localized resources for a particular locale, usually loaded from a file. A resource bundle is a map of key/value pairs, where keys are the names that are shared across locales, and values are the resources localized to the resource bundle's locale. Application code references locale-specific resources by key rather than storing them directly. It works well for transactional applications with modest UIs, e.g., online banking, where language-dependent features are limited to a few thousand messages. However, this approach would never scale to millions of messages. Moreover, since bundle keys are typically used in the application code, the code has to be changed if you want to add even a single new message. Ironically, adding support for a whole new language can be done without touching the code; however, you can guess which has a bigger effect on application maintainability. Finally, it offers no help in internationalization of Business Objects - referencing bundle keys form database schema would lead to an integrity maintenance nightmare, and bundles are loaded atomically, which leads to scalability issues when working with large datasets.

Directories, Tags & Tools - The WebLogic Way
The WLP I18N framework builds on the ResourceBundle approach and adds a number of useful features and capabilities:

• Tag i18n:getMessage provides a convenient wrapper around MessageBundle. It now supports reloadable and non-escaped message bundles.
• Tag i18n:localize allows defining the language, country, variant, and base bundle name to be used throughout a page.
• Tags l10n:include, l10n:forward, and l10n:resolve can be used for searching for a localized version of the page.
• The framework looks up and loads localized copies of resources, such as portals, portlet files, skeleton files, portlet content JSPs, static HTML, and image files contained in locale directories.
• Localization of component property pages through locale markup in the portal administration.
• Ability to add custom locale providers.

Since BEA's I18N framework is based on the standard J2SE internationalization technology, taking aside the convenience, they exhibit identical weaknesses. And although the Portal stores some locale markup data in the database, the lookup and retrieval mechanism is encapsulated in the framework and is not open to the applications for use with their own data.

Polyglot Architecture
When it became apparent that none of the existing internationalization technologies can meet the above requirements either as-is or with minimal enhancements, we set out to design our own, code-named Polyglot. Our approach is centered on the use of Polyglot objects in place of all language-dependent attributes of Business Objects and presentation elements. This allows all language information to be carried with the object throughout its life cycle within Model and Controller layers. The language-specific rendering is deferred to the View, permitting a single entity to be accessed by multiple users who want to see it in different languages.

Adding Polyglot to an existing application is as simple as changing the type of all language-dependent attributes from String to Polyglot. For example, the top left corner of the Food Portal model from Figure 1 will now look as shown in Figure 3.

The database schema will change as shown in Figure 4. As you can see all language-dependent columns are replaced with foreign keys to the Polyglot table that consists of a Polyglot_ID, which serves as a primary key, and a VARCHAR column for each supported locale. The column names match Java locale names exactly. The first column designates the default locale and is not nullable. All other values are optional.

No two Web applications are exactly alike, and neither are their internationalization and performance requirements. To give portal developers a wider range of options, the Polyglot framework shown in Figure 5 comes with three different concrete implementations, which offer different language resolution strategies. They all implement Polyglot interface and share a common base class PolyglotBase. The main method toString() takes a single argument, identifying desired locale, and returns localized value. A second toString() without parameters returns the value for the default locale.

Class PolyDictionary is a singleton that reads the meta-information from the polyglot table. It keeps the list of supported locales, and keeps track of the default locale. Method getLocaleId() finds closest available matching locale for a requested locale, e.g., for the polyglot table presented in Figure 4 it would return en_US_POSIX for en_US, en for en_UK and de_CH for de. It also assigns integer indexes to locales that are used for fast access to values.

Polyglot Implementations
Class BundleGlot is the most lightweight Polyglot implementation and is perfect for applications with a smaller number of language-dependent messages. It uses class PolyglotBundle to bulk-load the entire Polyglot table into memory, so BundleGlot instances contain just the ID. It has similar or better performance than the ResourceBundle. However, since it uses the same database schema and Java infrastructure as the other two, it can always be scaled up transparently to the rest of the application as the message count increases.

Class SimpleGlot is the direct implementation of the Polyglot pattern; it contains the message values for all of the supported languages, which are read from the database at the same time as the parent object. This option works best for applications that have a large or volatile set of messages but need to support just a few languages.

Finally, DeferredGlot offers the most scalable option in terms of number of messages and supported languages, beyond the limits of when caching stops being feasible. Similarly to BundleGlot, its instances only contain the ID. However, instead of preloading the messages, it does quite the opposite. Its method toString() uses the PlaceholderPattern object to create specially formatted placeholders containing polyglot ID and resolved locale values. The application then uses a response Filter to parse ServletResponse and find all of the placeholders. Having determined all of the message/locale combinations required for rendering the current page, polyglot filter reads all of the values from the database in a single hit, and replaces the placeholders with the appropriate messages.

Conclusion
Polyglot architecture offers a useful alternative to the internationalization mechanisms available in Java and specifically in the WebLogic platform. It can be used to meet performance and volume requirements of a wide variety of Portals and other Web Applications, and is free from many of the limitations of solutions based on ResourceBundle. Polyglots offer a uniform internationalization mechanism, spanning the Model to the View layers, and can be used to handle tasks on both ends of the spectrum, thus offering a universal and scalable approach to internationalization.

References

• Publishing Business Objects In Portals (The July 2004 issue of WLDJ contains detailed descriptions of the examples used in this article): http://wldj.sys-con.com/read/45559.htm
• The "J2EE Internationalization and Localization" chapter of Designing Enterprise Applications with the J2EE Platform, Second Edition offers a good overview of Java internationalization capabilities: http://java.sun.com/blueprints/guidelines/ designing_enterprise_applications_2e/i18n/i18n.html
• WebLogic Server Internationalization Guide: http://e-docs.bea.com/wls/docs81/i18n/
• Documentation on BEA's Internationalization and Localization JSP Tags: http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html

Page 2 of 2   « previous page