Building Internationalized J2EE Web Applications for Disparate Clients

n today's competitive world many businesses are becoming global in order to reach the widest possible target audience. That's a problem, because applications developed by those organizations must be suitable for use by customers in many countries who speak and understand different languages. To complicate matters further, the formerly limited set of application clients—desktop machines and browsers—is expanding rapidly. New client types include handheld computers, phones, and other small-form-factor devices. Therefore, organizations have an increasing need to develop and design cost effective, scalable and maintainable solutions capable of delivering content to multiple devices in multiple languages—in other words, to deliver applications to disparate clients in a global economy.

This article is a case study in designing and developing a J2EE-based, open ended, extensible, scalable and cost effective application that meets the needs of disparate clients. The sample application targets not only PC users, but also WAP-enabled Mobile phones and iMode phones, and it caters to the international community by using internationalization techniques that are customizable and localizable to each region's needs.

Figure 1 shows a typical application scenario, with different user devices all accessing the Internet-based application running on a common server.

Figure 1: A typical application scenario, with different user devices all accessing the Internet-based application running on a common server.

The need to respond in multiple formats and languages according to the client language and device means the server application must perform two major tasks for each request:

1. Determine the appropriate output format for the requesting device. For example:

• If request originates from Web, then output HTML.
• If request originates from an iMode device, then output CHTML.
• If request originates from a WAP device, then output WML.

2. Support I18N (internationalization). That means the output should be in the appropriate language, and date and number formats should match the client's locale.

Special server software modules called gateways translate the user agent requests to HTTP requests. For example a WAP gateway is responsible for converting the WSP request into an HTTP request (or vice versa) and also for parsing and interpreting the response. Similarly, with a VoiceXML request, the gateway consists of a Voice Browser responsible for recognizing the speech and DTMF input, converting that to a standard request format, and converting the VoiceXML response into speech.

---