Date post: | 18-Jan-2016 |
Category: |
Documents |
Upload: | audra-moore |
View: | 217 times |
Download: | 0 times |
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
David OrchardW3C LeadBEA Systems
Web service and XML Extensibility and Versioning
Distributed Architectures
Client ServiceMessage
DescriptionDescriptionRegistry
Describes
Contains
Uses
Examples:Registry: UDDI, Google, Email Description: WSDL, Sample msgs, wordMessage 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
• <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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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" />
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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/>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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
• <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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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">
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
#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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
#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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
#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
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
#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>
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
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?