RE: Intermediary services replace 5.2.1, .2, .3

Hi Tex,

I'm incorporating this text, but it's a little confusing. The scenario 5.2.1
appears to be introductory text to the section?

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: public-i18n-ws-request@w3.org
> [mailto:public-i18n-ws-request@w3.org]On Behalf Of Tex Texin
> Sent: mardi 30 mars 2004 15:12
> To: Web Services; Tex Texin
> Subject: Intermediary services replace 5.2.1, .2, .3
>
>
>
> 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 Monday, 5 April 2004 13:59:10 UTC