Transcript Approaches to Delivering Localized Software

Web Services:
Internationalization and
Service Capabilities
Constraints and Capabilities Workshop
Presented by Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc.
About This Presentation
 Web service constraints and capabilities: Internationalization
makes a good use case.
 The classic internationalization model
 Applying the internationalization model to Web services
 Why constraints? Why capabilities?
W3C Internationalization Working Group
 Web Services Internationalization Usage Scenarios
 Web Services Internationalization Requirements
 (draft) Internationalization Core WG charter
Web Services and Internationalization
 So Web Services are internationalized, right?
 Locale-neutral representation (XML Schema)
 No user interface (machine-to-machine)
 Inherits XML’s rich support for Unicode, language tags, and so
forth
 “Internationalization is the problem of the service author, not
the provider.”
Programming Paradigms: the classic I18N model
 Desktop
 Locales in the environment
 Web Application
 Locale-related APIs and state mechanisms
 Web Service?
 Uh…
Web Services are a Platform
The Importance of Composition and WS*
 Web Services (SOAP, WSDL) allow you to use “features” and
“properties” to add capabilities.
 Use different features together to get different results.
 WS-* standardization provides:
 Quality-of-Service
 Execution State
International Patterns: What are they?
 Four Patterns:
 Locale Neutral
 Service Determined
 Client Influenced
 Data/Resource Driven
What does that service do?
 Services generally run in the locale of the server where they
are installed
 May not be the same as the WS Provider
 May not give the results the user expects
 No way for the user to control it
 Developers must program services to provide international
capabilities
 Provide locale model
 Provide localization model and capabilities
 Define multiple endpoints for different locales
 “Providers” do nothing for you.
Web Service Descriptions
 Exchange a locale that is explicitly in the service signature.
 No standards exist for doing this
 Strong platform and programming language dependency
 Exchange a locale that is implied in the service’s operation.
 Web service descriptions don’t convey this information.
 Describe how a particular endpoint will work.
 There may be multiple endpoints in multiple geographies.
Invocation
 Language negotiation
 Services still need human readable messages.
 Faults (exceptions) need human readable messages.
 Service may retrieve, process, store, or otherwise access text.
 Locale negotiation
 Making the service do what the user wants.
 Collation, calendar, text processing, currency, routing, addressing,
formatting, business rules, tax authority, legal requirements, etc.
Basic Conclusions
 Web services need “international preferences”
 Personally: these are “locales”
 Web service descriptions need to describe “policies”
 “This service runs in the fr-FR locale.”
 “The requester can tell me what locale to use.”
 “If you request a locale I don’t support, I return a Fault
message.”
 Locale identifiers are needed.
 You can tell me what locale to run in… if we can agree on what
the identifier means.
 Web service discovery needs more internationalization.
Constraints and Capabilities
 Internationalization model describes capabilities:
 Policy? Runtime locale? Etc.
 Internationalization model describe constraints:
 Available locales
 Available resources
 Available language content
 Runtime restrictions
Summary
 Internationalization is an excellent example of the kinds of
Web service constraints and capabilities that need to be
communicated.
 Standardization is necessary to ensure interoperability.
 It won’t happen by magic.
 Plays well with others?
Q&A