With the advent of Internet-based business models such as e-commerce, applications are more likely to include clients and servers that operate in different locales and geographical regions. These differences introduce challenges to the task of designing a sound client-server infrastructure. Specifically, clients and servers can:
- Execute on computers having different endian architectures or code sets.
- Be located in different locales.
- Be located in different time zones.
Computers with differing endian architectures or code sets
Clients and servers can reside in computers having different endian architectures: a client could reside in a little-endian CPU, while the server code runs in a big-endian one. Or a more complex situation may exist, a client might want to invoke a business method on a server running in a code set different from that of the client.
A client-server infrastructure must define precise endian and code set tracking and conversion rules. Both CORBA and J2EE have addressed the problems of endian and code set mismatches. The language-neutral CORBA formalism uses byte order indicator in all marshaled data streams to indicate the byte order of the originating machine; in case of an endian mismatch, the receiving side can perform byte swapping for endian correction. The code set mismatch is addressed by CORBA using a comprehensive framework for code set conversion.
J2EE has nearly eliminated these problems in a unique way by relying on its Java Virtual Machine (JVM), which encodes all string data in UCS-2 format and externalizes everything in big-endian format. The JVM employs a set of platform-specific programs for interfacing with the native platform. These programs perform any necessary code set conversions between UCS-2 and the native code set of a platform.
Computers located in different locales
Client and server processes can execute in geographical locations having different locales. For example, a Spanish client might invoke a business method upon an object residing on an American server. Some business methods can be locale-sensitive in nature; for example, given a business method that returns a sorted list of strings, the Spanish client expects that list to be sorted according to the Spanish collating sequence, not in the server's English collating sequence. Since data retrieval and sorting procedures run on the server, the locale of the client must be available in order to perform a legitimate sort.
A similar consideration applies when the server has to return strings containing date, time, currency, exception messages, and so on, that is formatted according to the client's cultural expectations.
Neither the CORBA nor the J2EE specifications have architecturally addressed this locale mismatch problem, and other options involving extra parameters are not practical or have limitations. For example, requiring an extra parameter could require interface changes, which is a serious concern for deployed applications.
Computers located in different time zones
Client and server processes can execute in geographical locations having different time zones. Until now, all internationalization literature and resources have concentrated mainly on code set and locale-related issues. They have generally ignored the time zone issue, even though business methods can be sensitive to time zone as well as to locale. For example, suppose that a vendor makes the claim that "orders received before 2:00 PM will be processed by 5:00 PM the same day". The times given, of course, are in the time zone of the server that is processing the order. It is important to know the client's time zone in order to give customers in other time zones the correct times for same-day processing.
Other time zone-sensitive operations include time stamping messages logged to a server, and accessing file or database resources. The concept of Daylight Savings Time (DST) further complicates the time zone issue. Neither the CORBA nor the J2EE specifications address time zone issues adequately, and conventional methods of solving this problem are limited.
The conventional method for solving locale and time zone mismatch across remote application components is to pass one or more extra parameters on all business methods needed to convey the client-side locale or time zone to the server. Although simple, this technique has the following limitations when used in EJB applications:
- It is intrusive because it requires that one or more parameters be added to all bean methods in the call chain to locale-sensitive or time zone-sensitive methods.
- It is inherently error-prone.
- It is impracticable within applications that do not afford modification, such as legacy applications.
| 
