Towards the Internationalization of Web Services
Debasish Banerjee
WebSphere Internationalization Architect
IBM Corporation
Rochester, MN, USA
Summary An infrastructure for distributed localization in the domain of web services is introduced. The infrastructure is built on top of the existing Internationalization Service for the Java™ 2 Enterprise Edition (J2EE) components. A proposed SOAP internationalization header carries the service requester’s internationalization information. Internationalization handlers installed at the service requester and provider sides interact with the Internationalization Service to extract the internationalization information from, or associate it to the threads of executions. The ongoing and future web services internationalization work is also highlighted.
1. Introduction Web service is rapidly emerging as the basis for the next generation of the eCommerce infrastructure. Web service interfaces describe network accessible operations, which can be invoked using SOAP [14, 15]. Typically, web services act as wrappers over server-side components, which allow clients to dynamically discover and invoke the desired services. The server-side components can be developed using any established client-server technology, but their actual implementation mechanisms are abstracted out in their published WSDL [16] definitions which are available in relevant UDDI registries [12, 13].
Discussion about internationalization in the domain of Internet and web services is being vigorously pursued [6, 10, 17]. The majority of the internationalization discussions and publications concentrate on character sets, proper creation and rendering of multilingual XML documents, the proper use of Unicode, multilingual names, etc. None of the Internet internationalization forums have addressed the issue of localization in distributed Internet environments. The present paper attempts to address the issue of distributed internationalization in the domain of web services.
2. Distributed Internationalization Apart from the already well-explored issues of code set and endian mismatches [3], in real life situations, there can be locale and time zone mismatches between a web service requester (client) and a web service provider. In the existing web service architectures and implementations, a service provider freely imposes its locale and time zone in all the locale- and time zone-sensitive operations requested by a client.
| Desired Result | Actual Result |
| viernes 1 de febrero de 2002 | Friday February 1, 2002 |
| 12.345.678,09 € | $12,345,678.09 |
| pint | piña |
| piña | pint |
| pylon | pylon |
Figure 1 |
|
Figure 1 depicts a locale mismatch scenario between a Spanish requester and an American service provider implementing a web service activity returning formatted date, formatted currency and collated list. The existing web services implementations will typically return all the results in American locale. Ideally, following the rule of ‘local-remote transparency’ in distributed environments, the client should expect the locale-sensitive results in it’s (Spanish) locale and not in the service provider’s (American) locale.
Again, in modern eCommerce environments, the requester and the provider machines can be located across different time zones resulting in time zone mismatches. Some business method computations can be time zone-sensitive in nature. Financial transactions containing the requester’s timestamp can be cited as an example. Quite similar to the case of locales, the present web service providers impose their time zone on the client requested time zone-sensitive computations.
In [3] we introduced ‘Internationalization Service’; an infrastructure for distributed internationalization in heterogeneous managed environments. The Internationalization Service transparently propagates the internationalization context consisting of the locale and time zone information using IIOP in J2EE or CORBA environments. The present paper extends the applicability of internationalization service in the domain of web services.
3. Web Service Internationalization The proposed solution for the web services internationalization assumes the existence of internationalization service for the underlying managed components implementing the WSDL interfaces. The internationalization scheme can be divided into three logically separate strategies:
The above mentioned strategies are explained briefly in the following.
3.1 SOAP Internationalization Header A new SOAP header is defined for propagating the internationalization information in web service requests. The SOAP header is the XML representation of the internationalization context [3], and consists of a non-empty ordered chain of stringified locales and a time zone identifier. The stringified representation of locale and time zone is modeled after JavaTM. Refer to Appendix A for the proposed XML schema for the SOAP internationalization header. Note that, the mustUnderstand SOAP attribute is absent in the proposed header, non-internationalized web service provider nodes can simply ignore any propagated SOAP internationalization header without generating any fault.
3.2 Internationalization Service SPIs The internationalization service associates two internationalization contexts [3] with a thread of execution -- the caller internationalization context, and the invocation internationalization context. The caller internationalization context is extracted from the inbound IIOP request, and the invocation internationalization context is determined according to the specified internationalization context management policy [2]. The thread context manager internal table of the internationalization service maintains the association between executing threads and the corresponding internationalization contexts.
The existing internationalization service is enhanced by the introduction of two new SPIs. The first SPI (SPI1) is for extracting the invocation internationalization context associated with the current thread of execution from the thread context manager table. The second SPI (SPI2) is for associating a caller internationalization context with the current thread of execution, again in the thread context manager table. These two SPIs in collaboration with the web service internationalization handlers (see Section 3.3) are instrumental in widening the scope of the existing internationalization service into the paradigm of web services.
3.3 Internationalization Handlers At the web service requester side, a web service internationalization handler transparently intercepts an outbound SOAP request, queries the invocation internationalization context associated with the current thread of the execution using SPI1, creates a SOAP internationalization header (see Section 3.1) using the result returned by SPI1, and attaches the created header to the outgoing SOAP request.
The internationalization handler at the web service provider side transparently intercepts an inbound SOAP request, extracts the caller internationalization context from the SOAP header, and uses SPI2 to associate the extracted context as the caller internationalization context with the current thread of execution in the thread context manager table.
There can potentially be impedance mismatches between the data types used to represent the internationalization context in the thread context manager table and the XML data types used to represent the same information in the SOAP header. The internationalization handlers perform necessary data type transformations to compensate for any impedance mismatch. The existence of internationalization handlers makes the propagation of internationalization context completely transparent. Web services programmers do not need to be aware of the existence and the use of the SOAP internationalization header.
The infrastructure provided by Axis [1], the Apache open group’s emerging implementation of web services for Java environments, is used to register the internationalization handlers. Any other similar infrastructure can be used to install the internationalization handlers.
For the proper localization of relevant business computations, the actual implementation classes have to use the APIs provided by the internationalization service [3] in conjunction with the internationalization infrastructure supported by the underlying programming environment, like the JavaTM 2 Standard Edition (J2SE).
4. Conclusions The approach presented here should be considered as just the starting point for the complete internationalization of web services. The paper addresses the fundamental issue of the transparent propagation of the requester’s internationalization information in all SOAP requests. The orchestration of the provider-side internationalization handlers with the existing internationalization service allows a web service provider to localize the results according to the desired internationalization context.
Internationalization contexts need to be incorporated in the real life business flow models, both for web services [7, 11] and for other work flow domains. The notion of internationalization should also be considered as web service endpoint properties [9]. Service requesters will then be able to scrutinize the internationalization capabilities of various service providers offering similar services before deciding on binding to specific providers. As part of its overall effort, [4] intends to formalize the interaction between J2EE components and web services regarding internationalization context and internationalization service.
Acknowledgements
David Zavala and Casey Swenson of IBM, Rochester participated in many stimulating discussions. Chris Johnson of IBM Rochester helped us in defining the XML schema. Rongzhong Guo of IBM Rochester generated the html version of the document. Betsy Baartman of IBM, Rochester provided numerous suggestions for improving the quality of presentation.
References
Appendix A
<?xml version="1.0" encoding="windows-1252"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:annotation>
<xsd:documentation>
<info>
The XML schema for the 'internationalization
context--a non-empty
sequence of locales and a time zone identifier
</info>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType name="InternationalizationContextType">
<xsd:sequence>
<xsd:element ref="Locales"/>
<xsd:element name="TimeZoneID" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Locale" type="LocaleType"/>
<xsd:element name="Locales" type="LocalesType"/>
<xsd:element name="LanguageCode" type="xsd:string"/>
<xsd:element name="CountryCode" type="xsd:string"/>
<xsd:element name="VariantCode" type="xsd:string"/>
<xsd:complexType name="LocalesType">
<xsd:sequence>
<xsd:element ref="Locale" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="LocaleType">
<xsd:choice>
<xsd:group ref="LocaleGroup1"/>
<xsd:group ref="LocaleGroup2"/>
<xsd:group ref="LocaleGroup3"/>
<xsd:group ref="LocaleGroup4"/>
<xsd:group ref="LocaleGroup5"/>
<xsd:group ref="LocaleGroup6"/>
</xsd:choice>
</xsd:complexType>
<xsd:group name="LocaleGroup1">
<xsd:sequence>
<xsd:element ref="LanguageCode"/>
<xsd:element ref="CountryCode"/>
<xsd:element ref="VariantCode"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="LocaleGroup2">
<xsd:sequence>
<xsd:element ref="LanguageCode"/>
<xsd:element ref="CountryCode"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="LocaleGroup3">
<xsd:sequence>
<xsd:element ref="LanguageCode"/>
<xsd:element ref="VariantCode"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="LocaleGroup4">
<xsd:sequence>
<xsd:element ref="CountryCode"/>
<xsd:element ref="VariantCode"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="LocaleGroup5">
<xsd:sequence>
<xsd:element ref="CountryCode"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="LocaleGroup6">
<xsd:sequence>
<xsd:element ref="LanguageCode"/>
</xsd:sequence>
</xsd:group>
<xsd:element name="InternationalizationContext"
type="InternationalizationContextType"/>
</xsd:schema>
References in this document to IBM products or services do not imply that IBM intends to make them available in every country.
The following terms are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both:
IBM WebSphere
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others.
Information is provided "AS IS" without warranty of any kind.
All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.
Information in this presentation concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products.
All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction.
Some information in this presentation addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here.
Photographs shown are of engineering prototypes. Changes may be incorporated in production models.
© Copyright IBM Corp. 2002. All Rights Reserved.