150 likes | 329 Views
Web Services:. Internationalization and Service Capabilities. Constraints and Capabilities Workshop Presented by Addison P. Phillips Director, Globalization Architecture webMethods, Inc. About This Presentation.
E N D
Web Services: Internationalization andService 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…
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?