If a Web service is created from a specific agent which is not internationalized and later the agent is internationalized, then the service itself may have to be redeployed because the parameter list, headers, or other information have changed. The developer of the agent is responsible for supplying the fields, logic, and semantics that will be used to achieve international capabilities. This is an internationalization example of a general SOAP/WSDL problem.
One way that Web service authors might avoid this issue with a particular service would be to add international or multi-language support via an optional header after initial deployment without changing service descriptors (WSDL and XSD) that may already be in wide use.
The international considerations in doing this include:
Scenario A: There is a Service "A" which is not internationalized. Some senders start using this service. Later a new version is created that is internationalized, "B". "B" cannot simply replace "A" because the service signature has changed. "A" must remain deployed until all users have switched.
Scenario B: There is a Service "A" which is not internationalized. Later a new internationalized version, "B", is created that is internationalized but which uses the same fields and required values as "A". Senders that used "A" may be switched to "B" without warning. Now the behavior may differ... (users expecting "A" may get different results than they expect).
Scenario C: There is a Service "A" which is not internationalized. Later a new version is created that adds optional fields to enable internationalized behavior and this new service "B" replaces "A". Existing senders to "A" do not notice the change, but new senders can use the optional fields to get internationalized results. This may be a way to avoid the problems with "B", but may be difficult to maintain over time.
Scenario D: Service "B" is deployed in place of Service "A". The new service either generates faults (to deprecate the original invocation) or acts as an intermediary that invokes the original service "A" at some new location. "B" can then record senders that are using the original service as a way of assisting in migration.
@@following may be junk@@
Without guidance from the client, assumptions have to be made that are unsuitable. For example, the locale of the server may be used to format the response. When the service is internationalized, the only option is to ask for locale as an additional input, changing the service contract.
There is an important functional and semantic difference between a field supplied in the actual service invocation (that is, as part of the data) and one supplied in the envelope (that is, as part of the protocol) because when supplied as part of the data, developers must always take care to create, populate, read, and process the fields. Internationalization of an existing service therefore takes the form of deploying a new service (since the inputs have changed).
By contrast, if locale and language preferences are part of an optional header, the developer gains several advantages. First, both the provider and the service can read the locale and language preference. (The service must be provided with a specific API to obtain the locale and language from the provider, or it can be silently managed by the provider.) Services that require external environmental changes to activate their locale-sensitivity can have the provider perform this processing for them. Multiple services in the same "chain" can inherit the same locale and language context. Most important, though, the client-side environment can be optimized to provide the locale and language preferences of the end user automatically, without developers having to write code to obtain the values and populate the inputs of the Web Service.