Most programming languages and operating environments use an internationalization model that assumes that the user's preferences (generally embodied as an something called a 'locale') are maintained by the operating environment. Traditional Web technologies such as .Net or J2EE provide proprietary ways to exploit this international support in Web applications.
Web services are a standardized way of invoking logic over the Web using standards. By relying on open standards such as XML, XML Schema, HTTP, and so forth they can be platform neutral and foster interoperability.
One way that Web services promote interoperability is by providing for service composition. That is, different features can be applied to the same service without modifying the service itself. For example, a service can reference both the WS-Secuirty and WS-ReliableMessaging standards without the two standards having to consider the ramifications of the other.
While these features make Web services a compelling solution to the problem of composite enterprise app development, they also present a problem for Web service internationalization: Web services are open and standards based. Internationalization models are closed and proprietary.
The W3C Internationalization Working Group is currently developing a new charter that includes work items to address the basic problem of internationalization in Web services (see Appendix A for complete background).
Given that the problems with basic internationalization are addressed, how does this interact with service capabilities and constraints?
A "WS-Internationalization" should provide semantics so that identifiers are as clear and platform neutral as possible. There should be the possibility of vendor specific extensions so that vendors can leverage platform extensions.
When a Web service is deployed, there are four basic patterns for how it may be internationalized:
Each of these patterns may apply to a service or an aspect of the service. By describing the "international policy" separately for a service or sevice aspect, different end-points or bindings of the same service can provide different locale-affected behavior or different localizations. Or the logic might differ in a culturally sensitive manner.
Once one posits services that can be locale-affected and which obey policies in their Web service descriptions, it is a short journey to composing a service's international constraints and capabilities with other features. For example, a service might be provisioned so that specific binding return messages in a specific language. Or the processing rules might differ based on the language requested.
Because thinking about Web service internationalization incorporates the idea of policies and capabilities directly, internationalization provides many specific use cases that illustrate the problems and potential for work in this area.
A Web service wishes to indicate that its processing is locale-neutral and that it returns messages in French. This capability might be described in a WSDL feature.
A requester wishes to receive messages, including SOAP Fault messages and service outputs, in a specific language. (In other words, it needs to perform locale-negotiation with the provider). A specific range of language and locale values that are acceptable to the requester is sent to the provider. The provider can perform locale negotiation based on the service's locale policy and the requester's international preferences to generate the best matching results.
A Web service wishes to indicate that its processing is locale-affected and it is capable of responding to user requests for specific behavior (this is the definition of "client influenced"). The specific range of available behaviors (locales, languages) is described in the WSDL as an aspect of the "international preferences policy" and requesters can pre-negotiate the locale by selecting from the available choices.
A service is deployed with the "client influenced" policy. Requesters need to know what languages or locales are available in order to know if this service binding can support the specific international requirements. The actual service provisioning sometimes is as, if not more, important than the fact that a particular policy can be applied.
A user might wish to find a service that performs a process in French and English (with a default of French), which provides loan rate quotes for mortgages on Spanish property (using the local rates and regulations) using the Euro currency and based on the credit score of the end user.
This service is client influenced in terms of the language of the user messages it produces, although there are constraints on its capabilities (only French and English); it is data driven in terms of the processing (Spanish interest rates and regulatory requirements); and locale-neutral in terms of the function it performs (currency is actually a locale-neutral data structure, looking up the rate given the loan amount and credit score is not specifically locale affected, although regional rules may come into play).
The same service is implemented in a generic manner, with different language, regional, and regulatory regime capabilities configured using external data sources. The same service signature is provided so that composite applications can be built up that do not depend on the specific country, language, or other requirements. The resulting composite application can be deployed with specific capabilities (binding 'A' does Spanish mortgages, binding 'B' does French car loans, binding 'C' does Euro-zone credit card applications in twelve languages).
public static boolean getCreditApproval(Currency amount, long creditScore)
Here the language and country-of-origin are configuration parameters not supplied in the service invocation. This makes service maintenance and deployment easier: you can add countries by providing a configuration file and a new endpoint.
There are several items of work that need to be accomplished.
First, internationalization standards for Web services need to be created. These include standardized locale identifiers as well as SOAP and WSDL Features to describe the exchange of locale settings and policies.
Second, there need to be "constraint and capability" mechanisms in place so that service providers and requesters can negotiate language and locale settings (along with a host of other preferences and "environment variables"). Ideally these capabilities are generalized and not overly specific to internationalization or other specialized domains (like security, reliability, transactionality, etc.).
Third, meta-data systems such as a more advanced UDDI, possibly based on Semantic Web technologies, can be created to allow composite applications to be built, deployed, managed, and monitored across the extended enterprise.
Creation of a WS-International, complete with standardized "international preference" and policy identifiers will allow Web services to provide interoperability and localized behavior. Combined with standards for describing complex service behavior and configurations (constraints and capabilities), the creation of rich composite applications can be assured.
If Web services leverage proprietary internationalization models they risk exposing the underlying implementation which breaks interoperability. But Web services require the same international capabilities as traditional applications in order to provide language and culturally affected processing.
How can Web services have both internationalized behavior and platform neutral interoperability?
The W3C I18N Working Group has recently published a Note [1] that discusses this problem in detail. Requirements based on the findings in this note were used as inputs to a new draft charter for the Internationalization Core Working Group [2].
Creating a non-proprietary internationalization model actually requires very little standardization. The Internationalization Working Groups believes that this work includes:
Let's consider an example of a simple Java method converted to a Web service. For simplicity we'll write a little "internationalization demo" that converts a date to a human-readable string. Here's how such a method might be implemented:
public static String getDateString(Date date) {
if (date == null) date = new Date();
DateFormat df = DateFormat.getDateTimeInstance(DateFormat.LONG,
DateFormat.MEDIUM);
return df.format(date);
}In this example, a Date object is formatted as a String using the default locale of the JVM where the program is executing. The locale setting of this method is not part of the service's signature and wouldn't appear in parameter list necessary for invoking this method.
This method does require some modifications if we wish to use it in a distributed setting, say a J2EE program:
public static String getDateString(Date date) {
if (date == null) date = new Date();
Locale userLocale = request.getLocale();
DateFormat df = DateFormat.getDateTimeInstance(DateFormat.LONG,
DateFormat.MEDIUM, userLocale);
return df.format(date);
}The change to the method's implementation is minimal: the developer must know to get the locale from the HTTPServletRequest object, in this case. Note that a comparison with C# is instructive: there is no need to change code in .NET, since the service provider sets the thread "culture" (the Microsoft equivalent of a locale) from the request.
Now there is something mystical about how the J2EE system got the locale into the method. The Java proprietary Locale object was set in the Request object by processing the user's HTTP Accept-Language header and doing some (proprietary) mapping to Java's representation (the Locale object). The locale can then be accessed by a Java program.
Both of the examples above produce localized behavior using information maintained by the application's environment. The developer may need to do something in the body of the code to access this capability (as in the second example), but the method signature remains the same.
It is important to recognize that changing the method signature to get localized behavior is a poor implementation choice. It not only exposes the platform's implementation, but it requires the service author to create gallons of unusual code:
public static String getDateString(Date date, String locale) {
if (locale == null) locale = "";
if (date == null) date = new Date();
Locale userLocale;
if (locale.length()==0) {
userLocale = Locale.getDefault();
} else {
// parse string locale and create a Locale object, about 20 lines of code.
}
DateFormat df = DateFormat.getDateTimeInstance(DateFormat.LONG,
DateFormat.MEDIUM, userLocale);
return df.format(date);
}The example method shown above also requires intervention by the developer on several levels. For example, if the developer wants to use IANA language identifiers for the string parameter 'locale', then the WSDL needs to specify the type xsi:language. Furthermore, differences in system capability and identifier standardization may result in unusual results from the service.
This suggests that Web services requires rather more attention to an "internationalization model" than traditional Web content.
[WSUS] "Web Services Internationalization Usage Scenarios", W3C Working Group Note, Bannerjee, Dürst, McKenna, et al., July 30, 2004
[IUC26] "Why Web Services Are Not Internationalized (Yet)", Internationalization and Unicode Conference #26 paper, Addison Phillips
[DRAFT] "Proposed Draft Charter, W3C I18N Core WG", no official standing, Addison Phillips, Martin Dürst