The Web transcends national boundaries and many sites reach global audiences, which brings into the spotlight the problem of internationalization of Web applications. The Java community has an established approach for supporting multilingual applications through resources stored in ResourceBundle, which works well in examples but has many shortcomings when applied to real world problems.

In this area, BEA has closely followed mainstream Java. The WebLogic internationalization toolkit consists of a thin wrapper around ResourceBundle and tools for maintaining parallel UI components, thus inheriting the same limitations.

On the other end of the spectrum, Content Management Systems are often used for internationalizing large information portals. They find and deliver the appropriate content by tagging it with language metadata. They offer high scalability and near real-time content availability, but can only internationalize content, or files, offering no support for application data. Unfortunately neither of these approaches offers a viable solution for complex data-driven sites like Amazon or Travelocity. As a result, developers often resort to maintaining parallel sites for each language.

This article expands the topic of Business Objects in Web applications introduced in the feature "Publishing Business Objects in Portals" (WLDJ July 2004). It follows the Food Portal and Knowledge Repository examples, whose internationalization requirements could not be met with traditional Java or BEA tools and called for a different approach. This resulted in the development of Polyglot architecture, which closes the gap by adding the internationalization support on the level of Business Objects.

The Object of Internationalization
As a reminder, in the first article we introduced the concept of Business Objects in the context of Web portals as highly structured application data that has the following characteristics:

• Business Objects are strongly typed.
• Business Objects must have all of their attributes present and often have stringent constraints on their values (e.g., Coupon.Discount must be a positive number between 1 and 99, SpecialOffer.EndDate must be a valid date in future, etc.).
• Business Objects can relate to other Business Objects (e.g., Coupon extends SpecialOffer), which in turn can feature Products, which belong to a Brand, etc. Some attributes can be complex types or Dependent Objects; for example, Recipe includes a list of RecipeIngredients, which consists of Product, Quantity, and UnitOfMeasure. When presenting such objects through a portal, it is essential to be able to traverse these relationships and maintain their integrity, as dependents and parents are published or unpublished.
• Business Objects differ from other types of application data, such as bank account information or historical stock prices, because they have the same publishability requirements and associated life cycle as other types of content; e.g., Products are introduced and discontinued, SpecialOffers expire, Vacancies are filled.

Food & Nutrition Portal
The portal is targeted to the food enthusiasts. It features a wide range of content about food, various cuisines, and related matters. It receives content via distributed submission and publishes from a broad base of contributors as well as member companies, who use it to promote their products. The portal uses traditional content, such as articles, ads, features, campaigns, as well as business objects including products, brands, and packaging options, which can be added to the product catalog; recipes featuring these products, which go into the recipe box; and special offers promoting these products, etc. The simplified domain object model is presented in 1. The system supports various modes of browsing and searching and has rich navigation capabilities along class relationships.

Global Knowledge Repository
This repository is an Information Portal that aggregates systematized information from diverse Information Sources, and presents it organized along the taxonomy, similar to the one found in Yahoo's Directory. This taxonomy, implemented as a traversable multi-hierarchy of Navigation Nodes, is capable of building indexes at any level. All information on the site is tied back to its Sources, which form another hierarchy with administrative and semantic delegation.

All informational pages on the site, including navigation nodes, info sources, and standalone pages, are publishable by the contributors without any involvement of developers or site administrators. Both content and navigational assets are assembled at rendering time from atomic elements or contentlets. The simplified domain object model is presented in 2.

Both systems were developed on WebLogic, and in this article we will keep using these examples to highlight the internationalization requirements of data-rich portals. We used blue font to identify language-dependent attributes in the class models.

The Problem
As highlighted in the preceding examples, we need a uniform way to add internationalization to both View and Model tiers of Web applications. The ideal approach should be scalable to real-life limits in terms of both the number of localized elements and supported languages. It should not rely on replication of data and should be architecturally neutral, supporting different presentation technologies and types of data access, including Entity Beans, where an instance of Recipe can be read once from the database, cached in the Container and then rendered for different users in their preferred language. Finally, that approach should be object oriented, so that adding internationalization to application requirements does not distort its Domain Object Model.

Existing Solutions
Maintaining Parallel Sites - The Traditional Way
This is a tried-and-true brute force solution. It is the easiest to implement, but it does not meet most of the above criteria and has many disadvantages: it does not scale well when you have to add support for additional languages, requiring almost linear efforts. And since parallel sites require parallel databases, the probability of introducing data inconsistency grows even faster. Nevertheless, this approach is widely used and is recommended by BEA for localizing WLP 8.1.