Since this paper addresses globalization requirements in the Web services architecture and introduces the corresponding high-level architecture that is built on the globalization architecture, it is a good starting point for readers who are interested in providing globalization solutions in a Web services architecture implementation.
Globalization, as the design and execution of a globalized system, is not a feature. It is an architecture. To succeed in the global marketplace, IBM must define the architecture required to support global e-business and focus on the enabling technology to provide the key capabilities for globalization.
There are many benefits derived from following the globalization architecture, including:
- A single server can support applications in multiple languages, thus reducing the cost and time needed to develop, deploy, and deliver applications worldwide.
- The server deployment can be designed based on load levels and resources rather than language support requirements.
- The same version and patch level of a product can be used on servers throughout the world, thereby reducing the cost of support, maintenance, and training.
- Each product will handle the data (for example collation, date/time format) in a consistent manner in compliance with established industry standards, so the solution built on those products can assure consistent handling.
The IBM e-business globalization architecture has five interrelated base requirements, as illustrated in Figure 1.
Figure 1. IBM globalization architecture
Having a single executable means that one program codebase supports all languages, countries, or regions. Software programs must be developed that allow the single executable to handle the cultural needs of all supported countries or regions. In this way, the culture- and language-independent program codebase calls culture- and language-dependent information at run time, thus greatly reducing the cost and efforts invested and simplifying the process as well.
The single executable is the most important requirement of the five. This is the key requirement for ensuring that a global system can be designed, built, and maintained efficiently and correctly.
Since the single executable requires that one single program codebase support all languages, the program codebase needs to know which language it shall serve. This information comes from the concept of locale. In English, the word locale means a place where something happens or has happened. In globalization, generally speaking, it means a language and a country or region. For example, en_US stands for English in United States, ja_JP stands for Japanese in Japan, and fr_FR stands for French in France. Sometimes, more specific information is required. For example, in Germany, there are at least two ways of sorting textual data -- de_DE alone is not sufficient. This is often done by either using a locale variant (like the current JDK model, de_DE_Traditional) or using a locale keyword lookup (such as the OpenI18N locale naming convention, de_DE@collation=Traditional.)
Figure 2 shows how the locale model working with a single executable could provide a globalized solution in a simple typical scenario:
Figure 2. Single executable and locale model
- There are three customers. They're from the United States, Japan, and France, and their preferred languages are English (in the United States), Japanese (in Japan) and French (in France) respectively.
- The application is built on a single executable base and retrieves back-end data based on the customer's cultural preferences.
- The back-end data system is built on a locale model base -- that is, a data system categorized by locale information that serves globalized applications.
- The typical data flow is as follows:
- The application gets the request from the customer along with the locale information.
- The single executable passes the locale information to the back-end data system.
- The back-end data system finds the correct data, and sends it back to the single executable.
- The single executable sends the data back to the customer.
Thus, the customer's cultural preferences are fulfilled.
Because the single executable supports all languages, it needs an encoding system to be able to provide a unique number for every character, no matter what the platform, program, or language. (An encoding system is a method of assigning numbers to individual characters so that a computer can process those characters.) Unicode (see Resources) evolved to define this encoding system. Unicode can represent every character in the world by providing a single consistent character-to-number mapping schema; Unicode enables applications to provide multilingual support.
Since having a single executable means having one and only one executable for multiple locales, there must be a standardized approach (called localization packs) for working with different sets of locale-specific program data. There are two kinds of localization packs: application-dependent -- such as menus, dialogs, and other user-interface elements -- and application-independent -- such as collation tables, transliteration rules, and the names of date and time elements. The localization pack manager is the module that manages the location, loading, and accessing of localization pack resources. Figure 3 shows their relationship.
Figure 3. Localization pack and localization pack manager
A very simple example helps to explain this concept. In an application program, a single key (msg1) is associated with a single string value (Hello). Because many language versions are needed, corresponding localization packs can be created, as in Figure 4.
Figure 4. Localization pack for hello message
Input and output of multilingual data
Globalization also requires the ability to input text in different languages with a keyboard, mouse, or other device and to properly present it in those languages on the screen or printer. By using linguistic services, a more human-friendly interface such as speech input can be enabled for the end user. Generally, the operating system will support these functions. Usually, the application does not need to care about this directly.
Web services globalization model
Web services are the open standard that makes dynamic e-business possible, just as TCP/IP made the Internet possible and HTTP made the World Wide Web possible. Dynamic e-business applications using Web services will be running over open networks and have global reach. Web services need to be able to support global dynamic e-business. To satisfy this requirement, the base elements of globalization architecture that were introduced in the previous section must be applied to Web services.
Web services are changing rapidly -- not only the standards, but also the technologies. This section only takes a brief look at the base architecture.
Globalization in Web services looks like Figure 5. Universal Description, Discovery, and Integration (UDDI), as a standards-based specification for describing and enabling discovery of Web services, provides a multilingual business description through the attribute xml: lang= .... . Web Services Description Language (WSDL), as a language used to describe service interfaces, is globalization-independent because it only deals with the physical binding for service provider and service requester. The SOAP protocol is used for sending and receiving data in a Web services system, and it uses XML for carrying data, which is all represented in Unicode. (Defined by W3C, SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. See Resources for more information.) To run a globalized business in a Web services system, both service provider and service requester need to enable globalization following the IBM base globalization architecture illustrated in Figure 1.
Figure 5. Globalization Web services architecture
The base elements for a global Web services system are the same as those for a global application.
A Web services system contains many programs running on many machines. To have a global Web services deployment, each program in the system, including the implementation of the service itself, needs to strictly follow the single executable policy. Just as a single executable is the foundation for a global application, it is also the foundation for a global Web services system.
In the globalized Web services architecture, this requirement needs the most focus. To ensure a workable locale model for a Web services system, the way of transmitting end-user locale information must be consistent and standardized so that it can go through a series of service providers correctly. (The definition of locale follows RFC 1766, an internet standard which defines the tag for the identification of languages. It follows ISO 3166 for country code and ISO 639 for language code. Now IBM has started to work towards putting end-user locale definitions on SOAP headers.) Here's a potential scenario: a travel agent service gets an end-user request, then it contacts an airline service for that end-user. The airline service must return a reservation according to that end-user's cultural preferences, such as date and time representations, currency representations, measurement representations, etc.
There are different implementation approaches for implementing Web services in a global environment. However, the basic working pattern is similar:
- Publish a multilingual business using UDDI:
- Define a multilingual business.
- Publish a multilingual business.
- Find a multilingual business.
- Implement a multilingual business using SOAP:
- Prepare the multilingual environment.
- Implement multilingual Web services:
- The service provider must provide an interface with locale information in order to support a multilingual business operation. (There is no current standard in SOAP for communicating locale/language information. You can switch to the standard as soon as it becomes available.)
- The service requester typically:
- Determines the user's preferred language.
- Calls a multilingual-supported service provider and passes the user's language preference.
- Returns the result in the specified language to the user.
SOAP uses XML for carrying data, so it is platform-independent and programming language-independent. Therefore, the data exchanged in Web services is all represented as XML, and XML is all represented in Unicode, which in turn is the key to multilingual data. This means that standards can guarantee multilingual support.
XML also has tags, such as lang, to label certain fields to indicate language settings for the linguistically meaningful information, such as descriptions. So, Web services actually re-enforce a global data representation. Figure 6 shows an example:
Figure 6. Multilingual business description
Just as the single executable requirement applies to all the programs that make up the Web services architecture, the localization pack requirement also applies to all the programs. This element is the same for Web services as for normal applications. See Figure 7 for an airline company that wants to provide multilingual services in a Web services system.
Figure 7. Localization pack in a service provider
Input and output of multilingual data
There is no special requirement for input and output inside a Web services system, because usually this element is handled by the operating system or another program and not directly represented to a user.
The base requirements of a globalization architecture, single executable, locale model, multilingual data, localization pack, and input and output for multilingual data can be applied when considering globalization solutions in the Web services architecture. Web services are quickly changing and have a very rich domain. This article documents only the foundation for globalization in Web services.
- Read "Enabling Web services for globalization using WebSphere Application Server Version 4.0" by Xiao Hui Zhu, Ting Yong Zhu, and Yang Wang (IBM WebSphere Developer Domain, November 2002).
- Check out the IBM redbook, "E-business globalization solution design guide: Getting started".
- Visit the Unicode consortium.
- Find out more on SOAP.
- Browse the IBM globalization site at http://www-3.ibm.com/software/globalization/.
Xiao Hui Zhu is a software engineer at IBM Software Development Lab in China. She has worked for IBM since November, 1994, starting her career as a project manager in the Globalization organization and performing various roles, including tester, architect, coordinator, and consultant. Currently, she is the technical leader for the Globalization Certification Laboratory located in Shanghai. She welcomes your comments on this article. You can contact her at zhuxiaoh@cn.ibm.com. Thanks in advance!
