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.
Considerations and Recommendations
Table 1 shows some of the major considerations and recommendations for a disparate client application.
|How can you provide support for multiple user agents?
Use common server side code for all user agents…
Use XML and XSLT. The XML documents contain data common to all clients. The XSLT performs the transformations required to change the XML into the format appropriate for each user agent.
Set the generated response depending MIME types appropriately for the requesting device. To respond to a WML request, for example, the MIME type must be set to text/vnd.wap.wml.
|Should you perform XSLT Transformations on the server or on the client?
|Always use server-side transformations. Not all user agents support client-side transforms.
|How can you provide support for I18N?
UTF-8 encoding format MUST be used.
Use the ResourceBundle and Message Bundle classes and java.text package.
|Can the application rely on cookies for state management?
|Without cookies, how can you manage session data?
|Use URL re-writingsome user agents don’t support cookies.
|Should you use absolute or relative URLs to reference server resources?
|Use absolute URLs to avoid potential problems with user-agents that don’t support relative URLs.
Sample Application Overview
In this simple example scenario the first JSP page in the application displays a page containing hyperlinks. When the user clicks on a link, the application responds with a specific page. to accept choices and second one will be a resultant page. The figures below show how the application looks when accessed from a Web browser (see Figure 2), from a WAP emulator (see Figure 3) and from an iMode phone (see Figure 4). As you can see, the content of this sample application is extremely simple, so you can concentrate on how the application generates appropriate language and device specific responses.
|Figure 2 – User making a request with a WEB user agent
|Figure 3 – User making request with a WAP user agent
|Figure 4 – User making request with an iMode user agent
The complete request/response cycle for this application consists of four main components:
- A JSP page, which provides the logic that processes the request and drives the response sequence.
- An XML generator, responsible for generating an XML page.
- An XSL stylesheet, which formats the response appropriately for the requesting user agent. XSLT is used for server side transformation.
- A Resource Bundle file, which provides I18N support
Figure 5 shows a sequence diagram that illustrates the order in which the application initiates each of the components to complete a request/response cycle.
|Figure 5 – The sequence diagram shows the generalized interaction of the main application components
Figure 6 shows the top-level application deployment architecture, and illustrates the placement and the interaction sequence between the components.
|Figure. 6: Disparate Client Support Application Deployment Architecture (J2EE)