1 / 27

Web service and XML Extensibility and Versioning

Web service and XML Extensibility and Versioning. David Orchard W3C Lead BEA Systems. Distributed Architectures. Description Registry. Description. Contains. Describes. Uses. Client. Service. Message. Examples: Registry: UDDI, Google, Email Description: WSDL, Sample msgs, word

nassor
Télécharger la présentation

Web service and XML Extensibility and Versioning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Distributed Architectures Description Registry Description Contains Describes Uses Client Service Message 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 • <s:complexType name=“NameType">  <s:sequence>    <s:element name=“first" type="s:string" minOccurs="1" maxOccurs="1"/> <s:any processContents="lax" namespace="##any“ minOccurs="0" maxOccurs="unbounded" />  </s:sequence>  <s:anyAttribute/></s:complexType> • <ns:name> <ns:first>Dave</ns:first> <ns:last>Orchard</ns:last> </ns:name>

  12. First Solution Problem • Problem: Can’t create new Schema for this • Illegal: • <s:complexType name=“NameType">  <s:sequence>    <s:element name=“first" type="s:string" minOccurs="1" maxOccurs="1"/>    <s:element name=“last" type="s:string" minOccurs=“0" maxOccurs="1"/> <s:any processContents="lax" namespace="##any“ minOccurs="0" maxOccurs="unbounded" />  </s:sequence>  <s:anyAttribute/></s:complexType>

  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 <any targetNamespace=“ns”> are NOT allowed • <s:element name=“last" type="s:string" minOccurs=“0" maxOccurs="1"/><s:any processContents="lax" namespace="##any“ minOccurs="0" maxOccurs="unbounded" /> • <s:element ref=“ns2:last” minOccurs=“0" maxOccurs="1"/><s:any processContents="lax" namespace="##other” minOccurs="0" maxOccurs="unbounded" />

  14. Second Solution • <s:complexType name=“NameType">  <s:sequence>    <s:element name=“first" type="s:string" minOccurs="1" maxOccurs="1"/> <s:any processContents="lax" namespace="##other“ minOccurs="0" maxOccurs="unbounded" />  </s:sequence>  <s:anyAttribute/></s:complexType> • <ns:name> <ns:first>Dave</ns:first> <ns2:last>Orchard</ns2:last> </ns:name>

  15. Second Solution Problem • Problem: Can’t create new Schema for this • Illegal: • <s:complexType name=“NameType">  <s:sequence>    <s:element name=“first" type="s:string" minOccurs="1" maxOccurs="1"/>    <s:element ref=“ns2:last” minOccurs=“0" maxOccurs="1"/> <s:any processContents="lax" namespace="##other“ minOccurs="0" maxOccurs="unbounded" />  </s:sequence>  <s:anyAttribute/></s:complexType>

  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 • <name><first/><areacode/>….. <phone><last/>

  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 • <s:complexType name=“name">  <s:sequence>    <s:element name=“first" type="s:string" minOccurs="1" maxOccurs="1"/>    <s:element name="Extension" type=“ns:ExtensionType" minOccurs="0" maxOccurs="1"/> <s:any processContents="lax" namespace="##other“ minOccurs="0" maxOccurs="unbounded" />  </s:sequence>  <s:anyAttribute/></s:complexType><s:complexType name="ExtensionType"><s:sequence> <s:any processContents="lax" namespace="##targetnamespace“ minOccurs="0"maxOccurs="unbounded" /></s:sequence><s:anyAttribute/></s:complexType>

  19. Sample • <ns:name> <ns:first>Dave</ns:first> <ns:extension> <ns:last>Orchard</ns:last> </ns:extension> </ns:name> • Another revision • <ns:name> <ns:first>Dave</ns:first> <ns:extension> <ns:last>Orchard</ns:last> <ns:extension> <ns:middle>Bryce</ns:middle> </ns:extension> </ns:extension> </ns:name>

  20. Schema V2 <s:complexType name=“name"><s:sequence>    <s:element name=“first" type="s:string" minOccurs="1" maxOccurs="1"/>    <s:element name="Extension" type=“ns:LastExtensionType" minOccurs="0" maxOccurs="1"/> <s:any processContents="lax" namespace="##other“ minOccurs="0" maxOccurs="unbounded" />  </s:sequence>  <s:anyAttribute/></s:complexType><s:complexType name="LastExtensionType"><s:sequence>    <s:element name=“last" type="s:string" minOccurs=“0" maxOccurs="1"/>    <s:element name="Extension" type=“ns:ExtensionType" minOccurs="0" maxOccurs="1"/> <s:any processContents="lax" namespace="##other“ minOccurs="0" maxOccurs="unbounded" /></s:sequence><s:anyAttribute/></s:complexType> <s:complexType name="ExtensionType">

  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 • <ns:name xmlns:ns=“myns” xmlns:ns2=“extns”> <ns:first>Dave</ns:first> <ns2:last>Orchard</ns2:last></ns:name>

  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 • <ns:name xmlns:ns=“myns” xmlns:ns2=“extns”> <ns:first>Dave</ns:first> <ns2:last>Orchard</ns2:last></ns:name> • Required last name • <ns2:name xmlns:ns2=“extns”> <ns2:first>Dave</ns2:first> <ns2:last>Orchard</ns2:last></ns2:name>

  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 <last> 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 • <soap:header> <ns2:last xmlns:ns2=“extns” soap:mustUnderstand=“1”>Orchard</ns2:last> </soap:header> <soap:body> <ns:name xmlns:ns=“myns”> <ns:first>Dave</ns:first> </ns:name> … • Another solution: provide a mustUnderstand model • <ns:name xmlns:ns=“myns” xmlns:ns2=“extns”> <ns:first>Dave</ns:first> <ns2:last ns:mustUnderstand=“1”>Orchard</ns2:last></ns:name>

  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?

More Related