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

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. First Solution Dave Orchard

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

13. 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 –

14. Second Solution Dave Orchard

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

16. 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 – …..

17. 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

18. Third solution

19. Sample Dave Orchard Another revision Dave Orchard Bryce

20. Schema V2

21. #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

22. #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

23. #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

24. #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

25. 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

26. 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

27. Thank you, Questions?