Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Service Oriented Architecture
Contract Versioning

          Kjell-Sverre Jerijærvi
             Microsoft Services
      ...
SOA Design Maturity
0:   Just a Bunch of Web-Services
1:   Design Policies for Contracts
2:   Service Models and Data Mode...
SOA Principles
 Standardized Service Contracts
 Service Loose Coupling
 Service Abstraction
 Service Reusability
 Service ...
Versionable Artifacts
 Contracts: Service, Messages, Data
         WSDL: Service Interface + Messages + Policies
         ...
Why Contract Versioning
 Without formal contract versioning guidelines,
 bad effects are likely:
   Too many versions of t...
Versioning Guidelines
 Define standards
   Service version conventions
   Rules for WSDL design
   Rules for XSD design
  ...
The Ripple Effect
         Consumers


Standardized Service Contracts


     Composite Services

                         ...
Versioning Overview
Artifact                  Change                            Major   Minor Point
Service               ...
SCHEMAS
Messages & Data Types
Schema Versioning
 Schema design guidelines
   Use backwards compatible schemas
   Support forwards compatible schemas (ex...
Schema Compatibility
Recommendation
 It is recommended to have a simple and explicit schema
 versioning policy

 Use a “Fl...
Compatibility Overview

Strategy          Change                 Major   Minor   Point   FW
Strict            Breaking    ...
Versioning F/S Revisited
Artifact                  Change                            Major   Minor Point
Service          ...
Schema Versioning Rules
 The Schema version MUST be independent of the Service
 Version itself, however, an increment in s...
Schema Version Tracking
 Schemas MUST include mandatory major version in the
 XML namespace

 XML Namespace values MUST be...
Naming Conventions I
 Namespaces and artifact names used by schemas will be
 versioned by the industry standard YYYY/MM fo...
Compatible with…
 Compatibility is “not” between consumers and
 providers

 Consumers must be compatible with the
 Standar...
Schema Compatibility
  Backwards Compatible Schema
                                           RECEIVER: v1.1 XSD
      SEN...
Service Backwards
Compatibility
  Consumer v1.0                        Provider v1.1
                                     ...
Backwards Providers
 Providers that handle old request message schema
 versions received are backwards compatible services...
Service Forwards
Compatibility
  Consumer v1.1                            Provider v1.0
      v1.1 REQUEST XSD
         1....
Forwards Consumers
 Consumers that handle upgraded response message
 schema versions are forwards compatible consumers
 Pr...
Schema Wildcards
 Loose compatibility through schema wildcards
 Both request messages and response messages can be
 forwar...
Extensions are different
from Versions
 Extensions are common when consumer specific variations
 are needed
    i.e. speci...
SCHEMA MODELS
Federated, Composable Information Models
Schema Models
                BPM: HumanTask + Workflow
             Business Process                  Business Process
  ...
Model Mismatch:
ER vs XML Schema
   Customer                    Order                                 Shipment
           ...
DSL-Driven Models
   Enterprise
                                 Enterprise
     Data
                                   D...
SERVICE INTERFACES
Capabilities / Operations
Service Versioning
 Must allow for multiple generations of versioning of service
 design artifacts and runtime endpoints
 ...
Service Contract Design
 Define service version convention into three categories:

    Major version change (breaking chan...
Naming Conventions II
 Namespaces and artifact names used by WSDL must follow
 same conventions as for schemas

 Major, mi...
Versions: Active, Published, Discovery

                                               published

                        ...
Active Service Versions
 There should not be more than 3 major versions of the same
 service running in the production env...
Service Registry
 Potential consumers will always be directed to the
 published (latest major) version of a service in the...
Other Service Artifacts
 These recommendations do not attempt to model extended
 service metadata
    Attachments
    Anno...
SERVICE MODELS
Utility, Entity, Activity, Process, Task, Workflow
Service Ontology
Workflow




                     Human Task -                    Human Task -         Business
         ...
DESIGN GUIDELINES
Services, Messages, Data Types
Service & Messages Design
 Web-Services Interoperability best practices:
 WS-I BasicProfile 1.x
 www.ws-i.org

 Recommende...
Document/Literal Wrapped WSDL

  These are the basic characteristics of the document/literal
  wrapped pattern:
     The  ...
Data Type Design
 Prefer Venetian Blind pattern over Salami Slice pattern

 DO NOT use anonymous types in XML schemas
 (un...
XSD Best Practices
 XML schema design alternatives for this instance
 document:

 <Book>
    <Title>Illusions</Title>
    ...
Russian Doll
<xsd:element name=quot;Bookquot;>
     <xsd:complexType>
        <xsd:sequence>
            <xsd:element name...
Salami Slice
<xsd:element name=quot;Titlequot; type=quot;xsd:stringquot;/>
<xsd:element name=quot;Authorquot; type=quot;xs...
Venetian Blind
                                             Namespace exposure toggling:
<xsd:simpleType name=quot;Titlequ...
WCF Contract Design
 Prefer using the WCF DataContractSerializer (DCS) over the
 XmlSerializer

 DCS prefers Venetian Blin...
Wrapped Arrays
<xs:complexType name=quot;ItemType”>
    <xs:sequence>
    <xs:element name=quot;Idquot; type=quot;xs:longq...
WSDL Operation Message
<wsdl:message name=quot;GetItemRequest”>
     <wsdl:part element=quot;tns:GetItemRequestTypequot; n...
WSDL Fault Message
<wsdl:message name=quot;GetCustomerRequestquot;>
     <wsdl:part element=quot;tns:GetCustomerRequestquo...
INTEROPERABILITY
Diversity & Composability
Platform Diversity



          .NET


   JAVA
Schema Interop Issues
 Consumers might not support normalized/modular WSDL+XSD,
 but require a single/flat WSDL file
    M...
Service Interop Issues
 Support level for WS* standards varies wildly between platforms

 SOAP 1.1 or SOAP 1.2
    WS* sup...
Web Service Contract Design
and Versioning for SOA




  Thomas Erl, David Orchard et.al. (826 pages)
  http://www.soabook...
Credits
 John Evdemon
 http://msdn.microsoft.com/en-us/library/ms954726.aspx
 Jean-Jacques Dubray
 http://ebpml.org/com/an...
References
 Principles of Service Design: Service Versioning
 http://msdn.microsoft.com/en-us/library/ms954726.aspx
 Using...
QUESTIONS?
© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be...
Upcoming SlideShare
Loading in …5
×

of

Soa Contract Versioning Slide 1 Soa Contract Versioning Slide 2 Soa Contract Versioning Slide 3 Soa Contract Versioning Slide 4 Soa Contract Versioning Slide 5 Soa Contract Versioning Slide 6 Soa Contract Versioning Slide 7 Soa Contract Versioning Slide 8 Soa Contract Versioning Slide 9 Soa Contract Versioning Slide 10 Soa Contract Versioning Slide 11 Soa Contract Versioning Slide 12 Soa Contract Versioning Slide 13 Soa Contract Versioning Slide 14 Soa Contract Versioning Slide 15 Soa Contract Versioning Slide 16 Soa Contract Versioning Slide 17 Soa Contract Versioning Slide 18 Soa Contract Versioning Slide 19 Soa Contract Versioning Slide 20 Soa Contract Versioning Slide 21 Soa Contract Versioning Slide 22 Soa Contract Versioning Slide 23 Soa Contract Versioning Slide 24 Soa Contract Versioning Slide 25 Soa Contract Versioning Slide 26 Soa Contract Versioning Slide 27 Soa Contract Versioning Slide 28 Soa Contract Versioning Slide 29 Soa Contract Versioning Slide 30 Soa Contract Versioning Slide 31 Soa Contract Versioning Slide 32 Soa Contract Versioning Slide 33 Soa Contract Versioning Slide 34 Soa Contract Versioning Slide 35 Soa Contract Versioning Slide 36 Soa Contract Versioning Slide 37 Soa Contract Versioning Slide 38 Soa Contract Versioning Slide 39 Soa Contract Versioning Slide 40 Soa Contract Versioning Slide 41 Soa Contract Versioning Slide 42 Soa Contract Versioning Slide 43 Soa Contract Versioning Slide 44 Soa Contract Versioning Slide 45 Soa Contract Versioning Slide 46 Soa Contract Versioning Slide 47 Soa Contract Versioning Slide 48 Soa Contract Versioning Slide 49 Soa Contract Versioning Slide 50 Soa Contract Versioning Slide 51 Soa Contract Versioning Slide 52 Soa Contract Versioning Slide 53 Soa Contract Versioning Slide 54 Soa Contract Versioning Slide 55 Soa Contract Versioning Slide 56 Soa Contract Versioning Slide 57 Soa Contract Versioning Slide 58 Soa Contract Versioning Slide 59
Upcoming SlideShare
Web Service Versioning
Next
Download to read offline and view in fullscreen.

4 Likes

Share

Download to read offline

Soa Contract Versioning

Download to read offline

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Soa Contract Versioning

  1. 1. Service Oriented Architecture Contract Versioning Kjell-Sverre Jerijærvi Microsoft Services December 2008
  2. 2. SOA Design Maturity 0: Just a Bunch of Web-Services 1: Design Policies for Contracts 2: Service Models and Data Models 3: Governed Services & Contracts 4: Closed-Loop SOA Governance
  3. 3. SOA Principles Standardized Service Contracts Service Loose Coupling Service Abstraction Service Reusability Service Autonomy Service Statelessness Service Discoverability Service Composability Σ Service-Orientation & Interoperability http://www.soaprinciples.com/
  4. 4. Versionable Artifacts Contracts: Service, Messages, Data WSDL: Service Interface + Messages + Policies XSD: Data contracts as XML schemas Interface v2.0 Interface v1.0 Deployment Implementation v2.0 Deployment Schema Policy Schema End point Implementation v1.1 Policy End point Operation Policy Implementation v1.0 Operation © JJDubray
  5. 5. Why Contract Versioning Without formal contract versioning guidelines, bad effects are likely: Too many versions of the same service running in production Maintaining mapping between consumers and many service versions is troublesome Consumers will not know which version to use if too many versions are available New business rules will not be used by old consumers if old versions do not get deprecated
  6. 6. Versioning Guidelines Define standards Service version conventions Rules for WSDL design Rules for XSD design Version conventions for WSDL/schema namespaces Version conventions for WSDL/schema artifact names Define policies & governance Number of service versions supported How to identify a service and its version How each version of the service is represented in the service registry Processes for service lifecycle management and how a service is represented in the repository
  7. 7. The Ripple Effect Consumers Standardized Service Contracts Composite Services Flow & Decisions Services Service Logic (code) Aggregate Schemas Schemas
  8. 8. Versioning Overview Artifact Change Major Minor Point Service Breaking X Service Non-Breaking X Composite Service Incompatible Service X Composite Service Compatible Service X Service Incompatible Schema X Service Compatible Schema X Schema Breaking X Schema Non-breaking X Schema Aggregate Incompatible Schema X Schema Aggregate Compatible Schema X Code Bug fix / maintenance X Code Safe modifications X Code Semantic / Unsafe modifications X Other service artifacts Any modification X
  9. 9. SCHEMAS Messages & Data Types
  10. 10. Schema Versioning Schema design guidelines Use backwards compatible schemas Support forwards compatible schemas (extensibility) Elective: consumer variations (extensions) Schemas should be designed for extensibility, not to avoid versioning (wildcards) Compatibility MUST be defined by a versioning scheme Major (breaking change): incompatible Minor (non-breaking change): compatible Compatibility can be either backwards or forwards or both
  11. 11. Schema Compatibility Recommendation It is recommended to have a simple and explicit schema versioning policy Use a “Flexible/Strict” compatibility strategy Flexible: Safe changes to schemas are backwards compatible and cause just a point version Strict: All unsafe schema changes must cause a new schema version and thus a new service version Do not require forwards compatible schemas (Loose, wildcard extensibility) Avoid implementing some smart automagical mechanism for handling schema version issues in the service logic Rather use backwards compatibility, explicit schema versions and support multiple active service versions
  12. 12. Compatibility Overview Strategy Change Major Minor Point FW Strict Breaking X Strict Non-Breaking X Flexible Breaking X Flexible Non-Breaking X Loose Breaking X X Loose Non-Breaking X X Flexible/Strict Breaking X + Flexible/Strict Non-Breaking, Safe X + Flexible/Strict Non-Breaking, Unsafe X +
  13. 13. Versioning F/S Revisited Artifact Change Major Minor Point Service Breaking X Service Non-Breaking U S Composite Service Incompatible Service X Composite Service Compatible Service U S Service Incompatible Schema X Service Compatible Schema U S Schema Breaking X Schema Non-breaking U S Schema Aggregate Incompatible Schema X Schema Aggregate Compatible Schema U S Code Bug fix / maintenance X Code Safe modifications X Code Semantic / Unsafe modifications X Other service artifacts Any modification X
  14. 14. Schema Versioning Rules The Schema version MUST be independent of the Service Version itself, however, an increment in schema version MUST result in an increment of the Service version An increment of the version of a type included or imported in a schema MUST result in a version increment of this schema A Major increment of the schema version of an operation message type MUST result in a major increment of the service version A message consumer receiving message of an incompatible version MUST generate an exception, even if the message could be understood and processes by removing any portion that was not recognized
  15. 15. Schema Version Tracking Schemas MUST include mandatory major version in the XML namespace XML Namespace values MUST be constant for a given schema type and a given major version Message type schemas should include minor and point version custom attributes on the message type root element of type xsd:int Whether XML validation is used or not, each message consumer MUST verify that the major version is compatible with its implementation (through XML namespace) Minor and Point versions MUST NOT affect namespace
  16. 16. Naming Conventions I Namespaces and artifact names used by schemas will be versioned by the industry standard YYYY/MM format for namespaces: urn://schemas.microsoft.com/customer/2006/01/ Likewise the YYYY-MM format for files: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext- 1.0.xsd
  17. 17. Compatible with… Compatibility is “not” between consumers and providers Consumers must be compatible with the Standardized Service Contracts Providers must be compatible with the Standardized Service Contracts …this also facilitates principle #2: Service Loose Coupling
  18. 18. Schema Compatibility Backwards Compatible Schema RECEIVER: v1.1 XSD SENDER: v1.0 XSD 1..n Elements 1..n Elements v1.0 XML Wildcard Wildcard 1..n Elements (optional) Wildcard Forwards Compatible Schema SENDER: v1.1 XSD 1..n Elements RECEIVER: v1.0 XSD 1..n Elements Wildcard v1.1 XML 1..n Elements (optional) Wildcard Wildcard
  19. 19. Service Backwards Compatibility Consumer v1.0 Provider v1.1 v1.1 REQUEST XSD v1.0 REQUEST XSD 1..n Elements 1..n Elements v1.0 XML Wildcard Wildcard 1..n Elements (optional) Wildcard v1.1 RESPONSE XSD v1.0 RESPONSE XSD 1..n Elements 1..n Elements v1.1 XML Wildcard Wildcard 1..n Elements (optional) Wildcard
  20. 20. Backwards Providers Providers that handle old request message schema versions received are backwards compatible services Consumers are responsible for handling old response message schema versions sent by providers The service provider implementation MUST keep track of the schemas for all the minor versions for incoming messages and validate each incoming message based on its minor version number for a given major version Schema duck-typing can be used to deduce version Service Virtualization and intelligent routing is an alternative mechanism for backwards compatibility
  21. 21. Service Forwards Compatibility Consumer v1.1 Provider v1.0 v1.1 REQUEST XSD 1..n Elements v1.0 REQUEST XSD 1..n Elements Wildcard v1.1 XML 1..n Elements (optional) Wildcard Wildcard v1.1 RESPONSE XSD v1.0 RESPONSE XSD 1..n Elements v1.0 XML 1..n Elements Wildcard Wildcard 1..n Elements (optional) Wildcard
  22. 22. Forwards Consumers Consumers that handle upgraded response message schema versions are forwards compatible consumers Providers are responsible for handling upgraded request message schema versions sent by consumers Extensibility design guidelines enable existing consumers to continue operate unchanged even when the service provider is upgraded in a forwards compatible way If the consumer validates the incoming messages sent by the provider, they will pass validation (because of the extensibility rules defined) Breaking changes is conveyed using a new major version and thus a new XML namespace
  23. 23. Schema Wildcards Loose compatibility through schema wildcards Both request messages and response messages can be forwards compatible Might lead to fuzzy contracts with unclear semantics and poor discoverability Implemented using XSD Extensibility <xs:any namespace=”##targetNamespace” processContents=”lax” minOccurs=0 maxOccurs=”unbounded” /> <xs:any namespace=”##other” processContents=”lax” minOccurs=0 maxOccurs=”unbounded” />
  24. 24. Extensions are different from Versions Extensions are common when consumer specific variations are needed i.e. specialized relationships between consumers and providers (independently of other consumers) Extensions MUST be implemented within a single element under the root element of the message type Recommended element name is <ConsumerArea> They MUST be separate from the general versioning patterns Extensions NEED NOT be processed by other message consumers Extensions MAY belong to any namespace
  25. 25. SCHEMA MODELS Federated, Composable Information Models
  26. 26. Schema Models BPM: HumanTask + Workflow Business Process Business Process Integration (domain CRM) Integration (domain OHS) Task: Event: Task: Event: Message Message Message Message Contract A Contract B Contract K Contract L Resource Type 1 Resource Type 2 Resource Type n Resource Domain Model Federated CIM MDM SOA CIM: Common Information Model realm EAI CDM: Common Data Model BPI domain information model: business event messages as projections of CIM data entitites Federated models: required for B2x integration, cannot enforce model on the outside world Enterprise canonical CIM model: might be feasible, but federated models are recommended
  27. 27. Model Mismatch: ER vs XML Schema Customer Order Shipment 0..n 0..n name PO# address 1 0..n ????? Customer PO Shipment name Customer Customer address name name POs address address PO# Shipment POs PO# PO#
  28. 28. DSL-Driven Models Enterprise Enterprise Data Data Model Based on Model DSL Message Message Type Message references references TypeXML Type Schema Message Message Generate Type Message Message Based on Type references DSL Type Type Definition Message Message WSDL Type Type Message Type
  29. 29. SERVICE INTERFACES Capabilities / Operations
  30. 30. Service Versioning Must allow for multiple generations of versioning of service design artifacts and runtime endpoints Must support multiple versions for Service Requests at runtime for the same endpoint Must allow for multiple branch versioning Must support the following use cases Create a new service version Change message type schema Change service interface Change service bindings Change service non machine readable metadata Consume a new service version Create a new consumer version Decommission a service version
  31. 31. Service Contract Design Define service version convention into three categories: Major version change (breaking change) Dropping deprecated operations Change an operation signature in a manner that could break consumer compatibility Change service input and output message type Service has gone through a major rewrite Minor version change (non-breaking change) Change of the service contract (schema, interface, etc) but maintain the compatibility of the existing consumers Consumers may still consider whether the change of the service contract is acceptable Point version change (build number) Change of service implementation but maintaining the service contract the same
  32. 32. Naming Conventions II Namespaces and artifact names used by WSDL must follow same conventions as for schemas Major, minor, point are appended in the service name CONTOSO_3_1_120 for v3.1.120 Consumer can connect to a particular ACTIVE version of a service by using the WS-Addressing “To” element soap://contoso/services/customer_3 soap://contoso/services/customer_3_pre No separate version elements are needed in the SOAP header
  33. 33. Versions: Active, Published, Discovery published active v1.0 (decommissioned) v1.1 (deprecated) v2.0 (decommissioned) v2.1 (deprecated) V3.0 (deprecated, pre) discoverable v3.1 (latest major) time
  34. 34. Active Service Versions There should not be more than 3 major versions of the same service running in the production environment Maintain immediate predecessor minor/point version of the latest major version of the service If new major service version is introduced and there are already 3 versions of service running, the oldest version of the service must be decommissioned N  Latest (Major) version (Published) N-  Immediate Predecessor (minor/point) version of the Latest Major (Deprecated) N – 1  Deprecated N – 2  Deprecated N – 3  Decommissioned Once the next major version is released (N+1), the immediate predecessor of N, (aka N-) must be decommissioned Use a SOA governance process to enforce that the consumers upgrade to the newer “Active” versions to maintain the support from the service Provider
  35. 35. Service Registry Potential consumers will always be directed to the published (latest major) version of a service in the registry, they cannot search for minor or point versions Potential consumers can only search for the 3 last major version of a service This approach eliminates the need for managing too many versions There is no need to alter the manner in which green page queries are performed in the UDDI model Use a repository to maintain and document the relationship among multiple versions of the same service in a meaningful manner Registry (or registar role) will be responsible for notifying consumers of new published versions
  36. 36. Other Service Artifacts These recommendations do not attempt to model extended service metadata Attachments Annotations Other non-machine readable metadata Changes to service artifact versions MUST be indicated as at least as point versions (since the implementation should change at a minimum) When this type of metadata changes, there are enough mechanisms in this guideline to convey and detect Incompatible version Compatible versions …even when the contract did not change
  37. 37. SERVICE MODELS Utility, Entity, Activity, Process, Task, Workflow
  38. 38. Service Ontology Workflow Human Task - Human Task - Business Episodic Process Episodic Process Process Information Models I&AM: Claims - AuthZ BizProcess (Documents) Orchestrations Composite Services / Service Bus BizEvents Process - Resource LifeCycle Common Information Model Services (Resources) Capability Activity Entity Entity LOB Systems MDM realm
  39. 39. DESIGN GUIDELINES Services, Messages, Data Types
  40. 40. Service & Messages Design Web-Services Interoperability best practices: WS-I BasicProfile 1.x www.ws-i.org Recommended WSDL style: Document/Literal Wrapped (D/LW) One message in – One message out Use Message Exchange Patterns Data contracts wrapped in Messages One Way, Request-Response, Notify
  41. 41. Document/Literal Wrapped WSDL These are the basic characteristics of the document/literal wrapped pattern: The input and output message has a single part Look ma, The part is an element no attributes The element's complex type has no attributes The input element has the same name as the operation Strengths There is no type encoding info Everything that appears in the soap:body is defined by the schema, so you can easily validate this message You have the method name in the SOAP message Document/literal is WS-I compliant, and the wrapped pattern meets the WS-I restriction that the SOAP message's soap:body has only one child Weaknesses The WSDL is complicated
  42. 42. Data Type Design Prefer Venetian Blind pattern over Salami Slice pattern DO NOT use anonymous types in XML schemas (unqualified Russian Doll pattern) Use wrapped arrays/collections Elective: allow extensibility after element and attribute definitions New forward compatible versions of a schema MUST be extended within the target namespace of the original schema Extensibility to other namespaces MUST be disallowed in places other than the reserved extensibility point
  43. 43. XSD Best Practices XML schema design alternatives for this instance document: <Book> <Title>Illusions</Title> <Author>Richard Bach</Author> </Book>
  44. 44. Russian Doll <xsd:element name=quot;Bookquot;> <xsd:complexType> <xsd:sequence> <xsd:element name=quot;Titlequot; type=quot;xsd:stringquot;/> <xsd:element name=quot;Authorquot; type=quot;xsd:stringquot;/> </xsd:sequence> </xsd:complexType> </element>
  45. 45. Salami Slice <xsd:element name=quot;Titlequot; type=quot;xsd:stringquot;/> <xsd:element name=quot;Authorquot; type=quot;xsd:stringquot;/> <xsd:element name=quot;Bookquot;> <xsd:complexType> <xsd:sequence> <xsd:element ref=quot;Titlequot;/> <xsd:element ref=quot;Authorquot;/> </xsd:sequence> </xsd:complexType> </xsd:element> Global Element Declaration, @substitutionGroup Namespace exposure: always ”qualified”
  46. 46. Venetian Blind Namespace exposure toggling: <xsd:simpleType name=quot;Titlequot;> ”qualified” or ”unqualified” <xsd:restriction base=quot;xsd:string” /> </xsd:simpleType> <xsd:simpleType name=quot;Namequot;> <xsd:restriction base=quot;xsd:string” /> </xsd:simpleType> <xsd:complexType name=quot;Publicationquot;> <xsd:sequence> <xsd:element name=quot;Titlequot; type=quot;Titlequot;/> <xsd:element name=quot;Authorquot; type=quot;Namequot;/> </xsd:sequence> </xsd:complexType> <xsd:element name=quot;Bookquot; type=quot;Publicationquot;/>
  47. 47. WCF Contract Design Prefer using the WCF DataContractSerializer (DCS) over the XmlSerializer DCS prefers Venetian Blind, supports Salami Slice Document/Literal Wrapped WSDL is required by DCS Follow message part naming conventions defined by Microsoft DCS supports only elements for data, not attributes Not supported: <amount currency=”NOK”>123</…> Wrapped arrays/collections are preferred by DCS DCS: elementFormDefault must be ”qualified” DCS: element substition not supported (@substitutionGroup)
  48. 48. Wrapped Arrays <xs:complexType name=quot;ItemType”> <xs:sequence> <xs:element name=quot;Idquot; type=quot;xs:longquot; /> <xs:element name=quot;Value” type=quot;xs:stringquot; /> </xs:sequence> </xs:complexType> <xs:complexType name=quot;ItemListTypequot;> <xs:sequence> <xs:element minOccurs=quot;0quot; maxOccurs=quot;unboundedquot; name=quot;Itemquot; type=quot;tns:ItemTypequot;/> </xs:sequence> </xs:complexType> <xs:element name=quot;ItemListquot; type=quot;tns:ItemListTypequot; />
  49. 49. WSDL Operation Message <wsdl:message name=quot;GetItemRequest”> <wsdl:part element=quot;tns:GetItemRequestTypequot; name=quot;parameters” /> </wsdl:message> <wsdl:message name=quot;GetItemResponse”> <wsdl:part element=quot;tns:GetItemResponseType” name=quot;parameters” /> </wsdl:message> <wsdl:portType name=quot;InspectValues”> <wsdl:operation name=quot;GetItem”> <wsdl:input message=quot;tns:GetItemRequestquot; name=quot;GetItemRequestquot;></wsdl:input> <wsdl:output message=quot;tns:GetItemResponsequot; name=quot;GetItemResponsequot;></wsdl:output> </wsdl:operation> </wsdl:portType>
  50. 50. WSDL Fault Message <wsdl:message name=quot;GetCustomerRequestquot;> <wsdl:part element=quot;tns:GetCustomerRequestquot; name=quot;parametersquot; /> </wsdl:message> <wsdl:message name=quot;GetCustomerResponsequot;> <wsdl:part element=quot;tns:GetCustomerResponsequot; name=quot;parametersquot; /> </wsdl:message> <wsdl:message name=quot;FaultDetailListquot;> <wsdl:part element=quot;fault:FaultDetailListquot; name=quot;detailquot; /> </wsdl:message> <wsdl:portType name=quot;CustomerServicequot;> <wsdl:operation name=quot;GetCustomerquot;> <wsdl:input … /> <wsdl:output … /> <wsdl:fault message=quot;tns:FaultDetailListquot; name=quot;FaultDetailListquot; /> </wsdl:operation> </wsdl:portType>
  51. 51. INTEROPERABILITY Diversity & Composability
  52. 52. Platform Diversity .NET JAVA
  53. 53. Schema Interop Issues Consumers might not support normalized/modular WSDL+XSD, but require a single/flat WSDL file Most legacy ASMX consumers Most Java tools (e.g. Eclipse) Most AJAX toolkits Rich Internet Application (RIA) platforms (e.g. Flex/Flash) Some Web2.0 mashup tools XSD data types might not be supported by platform .NET has no support for e.g. xs:date, xs:positiveInteger Unsupported data types typically become string objects Some xs:nillable elements might not be supported by platform Some elements might be required to be xs:nillable by platform Use of attributes for data Use of attributes to annotate data elements
  54. 54. Service Interop Issues Support level for WS* standards varies wildly between platforms SOAP 1.1 or SOAP 1.2 WS* support in WCF defaults to Soap12Addressing10 Most legacy platforms support only Soap11 Typical WS-Security interop issues: Which version of the standard the platforms support Token type for authentication Message or transport security Order and level of encryption and signing Establishment of secure conversations Some platforms do not support WS-Policy/WS-SecurityPolicy No policy metadata in WSDL, e.g. when using Java Spring-WS All policy metadata must be communicated out-of-band
  55. 55. Web Service Contract Design and Versioning for SOA Thomas Erl, David Orchard et.al. (826 pages) http://www.soabooks.com/wsc/default.asp
  56. 56. Credits John Evdemon http://msdn.microsoft.com/en-us/library/ms954726.aspx Jean-Jacques Dubray http://ebpml.org/com/an_introduction_to_soa4.swf David Orchard http://www.xml.com/pub/a/2004/10/27/extend.html http://www.w3.org/TR/xmlschema-guide2versioning/ Don Smith http://blogs.msdn.com/donsmith Roger L. Costello & co http://www.xfront.com/GlobalVersusLocal.html Russel Butek http://www.ibm.com/developerworks/webservices/library/ ws-whichwsdl/
  57. 57. References Principles of Service Design: Service Versioning http://msdn.microsoft.com/en-us/library/ms954726.aspx Using Message Contracts http://msdn.microsoft.com/en-us/library/ms730255.aspx Practical WCF DataContract Rules http://kjellsj.blogspot.com/2008/03/wcf-datacontractserializer- schema-rules.html WCF DataContract Rules http://msdn2.microsoft.com/en-us/library/ms733112.aspx Which WSDL style http://www.ibm.com/developerworks/webservices/library/ws- whichwsdl/
  58. 58. QUESTIONS?
  59. 59. © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
  • TravisGray3

    Sep. 2, 2019
  • waelmohesnmahemoud

    Nov. 9, 2018
  • MohamedZakarya2

    May. 16, 2017
  • gschmutz

    Dec. 22, 2010

Views

Total views

4,680

On Slideshare

0

From embeds

0

Number of embeds

20

Actions

Downloads

166

Shares

0

Comments

0

Likes

4

×