- From: Tex Texin <tex@xencraft.com>
- Date: Tue, 30 Mar 2004 15:12:04 -0500
- To: Web Services <public-i18n-ws@w3.org>, Tex Texin <tex@XenCraft.com>
5.2 Providing Language and Locale Negotiation 5.2.1 I-020: Correlation of Data Between Services in Different Languages Scenarios in this section address the requirements of services that employ intermediaries, as discussed in "Service Oriented Architecture Derivative Patterns Intermediary" (in Web Services Architecture document[WSA]). Editorial note Insert illustration. [Owner: Addison] In these scenarios, providers may offer services with support for either differing or a variety of international preferences. An intermediary service makes requests of these providers and uses the results to satisfy the requests coming from its clients. The intermediary service may process and/or integrate the results from different providers to create a new kind of service. The intermediary service may cache its results, or the results returned to it by its providers, for reuse with subsequent requests. Clients requesting intermediary services can have different international preferences. Therefore the intermediary service must be careful with its algorithms for determining when to reuse requests. Proper tracking of source data locale and requester locale is required. Also, correlation and/or aggregation of data may prove difficult if sound internationalization principles are not used. 5.2.3 I-012: Caching If caching does not take international preferences into account, it is possible that cached responses in the wrong language, format, or locale could be returned. 5.2.3 I-012: Locale Negotiation in Intermediary Services Alternatively, in scenario I-020, the intermediary service caches fault reasons and other data returned from its providers in each of the languages and cultural conventions that are requested of it, tracking the locales of each result. Requesters of the intermediary service identify the desired locale of expected results. With locale negotiation, the intermediary service can provide results and/or fault reasons that match the requester's international preferences.. 5.2.2 I-007: Locale Negotiation and Chained Services Chained services are a form of intermediary services. A (source) provider defines a service that has a requirement for a language or locale preference. Another (intermediary) service provider, defines the same service and invokes the first service to utilize its capabilities. The source provider defines an optional header containing a language request field. If the intermediary service does not also define the optional header, then when it receives a request it cannot communicate the requester's preferences to the source provider. The intermediary service might indicate its own international preference(s) to the source provider or none, accepting default values. Unless, the description of the intermediary's service declares its policy on addressing international preferences, its users may have incorrect expectations of the results. 5.4 Soap headers In a variation of these scenarios, a SOAP header can be used for locale negotiation between each layer of requester, intermediary and service. An example is a Web service wrapper to a legacy client/server application. ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
Received on Tuesday, 30 March 2004 15:27:05 UTC