Building Java EE network applications for different clients

Introduction: Learn how to use constructs to not only support browsers but also international network applications that support WAP, Imode, and other client devices.

In today's increasingly competitive world, many business practices are becoming more globalized in order to achieve maximum profitability. This has become a problem because applications developed by commercial organizations must be applied to consumers in many countries using different languages. What makes things more and more complicated is that previously limited application clients-desktops and browsers-are also developing rapidly. The new client types include portable computers, mobile phones, and other small devices. It is therefore necessary for international operators to increase the cost of development and design costs, upgradeable and maintainable solutions that deliver content in multiple languages to multiple devices-in other words, sending applications to different clients in a global economic circle.

This article is a case study that designs and develops an extensible, scalable, and cost-effective application based on Java EE to meet the needs of different clients. The objective of the sample application is not only a personal computer user but also a WAP mobile phone and imode phone, and it can cater to the international community by using an international technology tailored and localized for each region.

Figure 1: A typical application scenario that uses different user devices for internet-based applications running on a public server.

Using the needs of multiple formats and language responses based on the client language and devices means that you must perform the server application for two primary tasks:

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

· If the request is sent from the Web, the HTML format is exported.

· If the request is issued from a imode device, the output cHTML format.

· If the request is issued from a WAP device, the output WML format.

2. Support i18n (internationalization). That means the output will use the appropriate language, and the date and number formats should match the region where the client is located.

The dedicated Server software module, called Gateway, translates the client's request into an HTTP request. For example, a WAP gateway is responsible for translating WSP requests into HTTP requests (and vice versa) as well as parsing and interpreting responses. Similarly, using a VoiceXML request, a gateway made up of a voice browser is responsible for identifying the language and DTMF input, converting it into a standard request format, and translating the voicexml answer into speech.

Some problems that may exist

Table 1 gives you a number of problems with different client applications and possible solutions.

	reference answer
	The uses XML and XSLT. The XML file contains data that is shared by all clients. XSLT execution transforms the XML into a transformation request that is appropriate for each client's format. The generated answer to the Setting depends on the MIME type of the device that applies to the request. For example, in response to a WML request, the MIME type must be set to TEXT/VND.WAP.WML.
	always uses server-side conversions. Not all clients support client-side conversions.
	The uses the ResourceBundle and message bundle classes and the Java.text package.
can applications use cookies as state management? The
not using cookies, how to manage session data?