David Orchard W3C Lead BEA Systems Web service and XML Extensibility and Versioning

Distributed Architectures ClientService Message Description Registry Describes Contains Uses Examples: Registry: UDDI, Google, Description: WSDL, Sample msgs, word Message formats: SOAP, XML, HTML

Loosely Coupled Various definitions of Loose Coupling #1: Interface to Programming environment –Changes in programs affect interface? –XML helps with this problem Need to bind XML to language #2: Interface changes breaking application –If the data structure changes, then client breaks –The “version” problem, new version of interface

Program change Software Indirection from Address –Insulates client from sender In Distributed Objects, client connects directly to object Use only the data needed –Validate only the data needed, ignore the rest –Other portions of the message can change Pipeline aka Handler chains –Modularize the places that change –Massage the data if possible to older interface Mapping layers –Map Data into programming language –Can provide multiple mappings of data into the same service

Handler Chains Handler chains (aka Pipelines) are chains of processing steps Handler A -> Handler B -> Application Allow loose coupling between the components –And can add the handlers in without changing the application Example: –Handler A is a WS-Security handler Decrypts an encrypted message Verifies Signature –Handler B is a Reliability handler Persistently stores message and sends an Acknowledgement Handler chains work best with SOAP headers –Well defined framework for extensibility

Extension & Versioning Perhaps the biggest goal of loose coupling is to allow distributed extension and evolution Versioning a super hard problem This introduces some rules to guide design Achieve backwards and forwards compatible evolution of interface

Compatibility definitions Backwards Compatible –Newer software can read older versions of documents –ie. Update Schema and older documents validate Forwards Compatible –Older software can read newer versions of documents Incompatible extensions mean that software must be upgraded

Web services ext & vers WSDL perspective, what can change? –Add/change/delete message content –Add/delete operations –Add/delete bindings –Add/delete interfaces In general, changing operations, bindings, interfaces is incompatible change –Though adding an input operation is compatible Much can be done for message content

Rules for data versioning #1: Allow Extensibility –any namespace –other namespaces –Extension element + other namespaces #2: Ignore Unknown content #3: Keep Namespace if compatible change #4: Use version attribute for “minor” version –only if needed #5: Use MustUnderstand Model

Rule #1: Allow Extensibility Allow elements in other namespaces Allow attributes in any namespace Schema Wildcard element’s attributes: –ProcessContents is for schema validation Lax allows WSDL to control validation –Namespace for which namespaces are allowed Schema does not have a “default” extensibility model –sometimes called open content model

First Solution Dave Orchard

First Solution Problem Problem: Can’t create new Schema for this Illegal:

Why so complex? XML DTDs and XML Schema require “deterministic content models”. “the content model ((b, c) | (b, d)) is non-deterministic, because given an initial b the XML processor cannot know which b in the model is being matched without looking ahead to see which element follows the b.” This means optional elements followed by are NOT allowed –

Second Solution Dave Orchard

Second Solution Problem Problem: Can’t create new Schema for this Illegal:

Extension schema choices extension is required - incompatible extension is optional, either: –Lose the extensibility point This means only 1 new version –Do not add the extension into the schema Validate any extensions found if you can Can’t validate the “right” extensions are in the “right” place – …..

Extension element There is another, though more complex, way to do this Extension element for same namespace This element has only a wildcard This does the “swap” extensibility for element content trick

Third solution

Sample Dave Orchard Another revision Dave Orchard Bryce

Schema V2

#2: Must Ignore unknowns Receivers must ignore content they don’t understand This is critical for compatible changes –Sender can put new information in without breaking receiver example, receiver must ignore ns2:last Dave Orchard

#3: Preserve NS if possible Change a Namespace ONLY if a non-compatible change is done –A required element is added –Semantics of existing elements change Optional last name Dave Orchard Required last name Dave Orchard

#4: Version attribute Use version attribute for minor version Identify a version of a particular namespace Software can “know” whether an extension is supported or not –can choose to use or not ie, client knows isn’t supported –Client doesn’t send

#5: Use MustUnderstand When adding required functionality Extension authors may not “own” namespace Provide or use Must Understand rule Overrides the Must Ignore rule Example: add required ns2:last as SOAP header Orchard Dave … Another solution: provide a mustUnderstand model Dave Orchard

Versioning architecture Very difficult to have multiple versions of service –Typically the data model changes and requires new data Easier to try for compatible evolution of interface and data

Versioning activities W3C TAG work –Web architecture doc, finding WSDL 2.0 –version attribute –primer XML Schema 1.1 –1.0 doesn’t make extensibility easy explicit wildcards and determinism constraints –1.1 may relax determinism RelaxNG has open content model

Thank you, Questions?