Contract, Policy and Addressing

1. Contract, Policy and Addressing Daniel Fisherdanielf@newtelligence.com newtelligence AG

2. Complexity Complexity ServicesFrom Tightly Coupled Objects… To Loosely Coupled Services Your Partner You Programming Language Programming Language Database Database Agreements Object Model Object Model Contract Operating System Operating System Application Application

3. Contracts • Enable loose coupling • by preventing binary dependencies • Enable robustness in operations • by agreeing on infrastructure behaviors • Establish reliability (and accountability) • by defining measurable service quality levels

4. Service Contracts Illustrated Service Interface Process Service DocumentA DocumentC1 DocumentC2 Contract Service Interface Contract EitherC1 or C2 Service Interface DocumentB Service Interface Process

5. Service Contract Definition • Defines application-level protocols • Defines all messages and their format • Defines all possible message sequences • Styles: • One-Way • Request/Response • Dialog • … • Service interfaces specify roles in contracts

6. Service Contract Definition • Addresses • Where is a service located • Example: • http://server:8080/ep • net.tcp://server:808/ep • Bindings • What is the protocol and content delivery format • Examples: • WS-I Basic Profile 1.1: SOAP 1.1, UTF-8, HTTP • MS Profile: SOAP 1.2, Binary, TCP Framing

7. Policies • A Policy is a set of assertions made about • Addresses • Bindings • Service Interfaces • Servers • … • Policy-sets are attached, embedded or otherwise associated with contracts • A Policy specifies dynamic, negotiable configuration information for a contract implementation.

8. Organization A Policy Organization B Policy Buyer Service Local Service Local Service Contract and Policy Illustrated Runtime contract Policy 1. Supports X.509 Cert or Kerberos ST for AuthN 2. Supports UTF-8, UTF-16, SOAP 1.2, 1.1 … Seller Service Design time Contract 1. I’ll send a PO 2. You’ll send a confirmation … • Runtime Contract • 1. Use X.509 Cert for AuthN • 2. Use UTF-8, SOAP 1.2 • …

9. WS-MetadataExchange WS-PolicyAssertions WS-Policy Attachment WS-Policy WSDL Metadata in the Web Service Architecture P2P EAI B2B Grid Connected Applications Devices Mobile Business Process … Management Secure Reliable Transacted Metadata Messaging XML Transports

10. Policy Contract, Policy, and SOAP WS-PolicyWS-PolicyAssertionsWS-PolicyAttachment <soap:Envelope> <soap:Header> … </soap:Header> <soap:Body> … </soap:Body></soap:Envelope> Service Contract Message Contract W3C XML Schema WSDL 1.1 / 1.2 Schema WSDL

11. Contracts in a Web services World • Contract mapped to specifications • XML Schema • Data Types • WSDL/XML Schema • Messages • WSDL • Message exchange patterns • WS-Policy • Quality of service rules and requirements

12. Introducing XML Schema • XML Schema is • a general purpose type description language • an XML document definition language • an totally, over-the-top complicated committee standard • Knows two fundamental constructs for types • Simple types: strings, numbers, dates • Complex types: compositions of simple & complex types • Knows two fundamental document particles • Elements and Attributes • Provides 1001 ways to define the same thing

13. Data Types • Built-In Types • Primitive data types are those that are not defined in terms of other data types • Many of the built-in types are defined as subsets of another type's value space, also known as derivation by restriction • User Defined Types • Simple types cannot have element content and cannot carry attributes • Complex types allow elements in their content and may carry attributes • Derived data types are those that are defined in terms of other data types

14. Types Samples <xsd:simpleType name=“Probability”> <xsd:restriction base="xsd:double"> <xsd:minInclusive value="0"/> <xsd:maxInclusive value="100"/> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="PurchaseOrder"> <xsd:sequence> <xsd:element name="CompanyName" type="xsd:string"/> <xsd:element name="Items"> <xsd:complexType> <xsd:sequence> <xsd:element name="Item" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Quantity" type="xsd:int"/> <xsd:element name="UnitPrice" type="xsd:double"/> <xsd:element name="ExtendedPrice" type="xsd:double"/> </xsd:sequence> <xsd:attribute name="sku" type="xsd:string"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:string"/> </xsd:complexType>

15. Evolving Schemas • Evolving • Allow documents and messages to evolve over time • Allows for compatible changes to clients or services • Special type of evolvability is versioning • Versioning • Forward-/backward compatible evolution • Incompatible evolution • Schema must be versioned in order to guarantee both progress and compatibility

16. Open Content Model • XML Schema complex types have several content models • Element/Attribute wildcards enables high degree of resiliency • Also known as Open Content Model • Substitution with some restrictions <schema targetNamespace="http://workshop" xmlns="..."> <element name=“Person"> <complexType> <xs:sequence> <xs:element name="Name" type="xs:string" /> <xs:any processContents="lax" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute processContents="lax"/> </complexType> </element> </schema>

17. Evolving Complex Types (Part 1) <schema targetNamespace="http://workshop" xmlns="..."> <element name=“Person"> <complexType> <xs:sequence> <xs:element name="Name" type="xs:string" /><xs:any processContents="lax" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute processContents="lax"/> </complexType> </element> </schema>

18. Evolving Complex Types (Part 2) <schema targetNamespace="http://workshop" xmlns="..."> <element name=“Person"> <complexType> <xs:sequence> <xs:element name="Name" type="xs:string" /><xs:element name=“City” type=“xs:string” /> <xs:any processContents="lax" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute processContents="lax"/> </complexType> </element> </schema>

19. Introducing WSDL • WSDL = Web Services Description Language • WSDL describes • Messages • Operations • Port Types (Interfaces) • Bindings • Services (bound port types) • WSDL is typically generated for you

20. WSDL Skeleton <!-- WSDL definition structure --> <definitions name="MathService” targetNamespace="http://example.org/math/" xmlns="http://schemas.xmlsoap.org/wsdl/" > <!-- Abstract definitions --> <types> ... </types> <message> ... </message> <portType> ... </portType> <!-- Concrete definitions --> <binding> ... </binding> <service> ... </service> </definition>

21. Abstract Concrete WSDL Elements • Definitions • Types • Define or import XML schema types • Messages • References to types • PortTypes • Define Operations • References to message (in/out) • Bindings • Reference to PortType • Define transport and encoding • Services • Reference to PortType and corresponding Binding • Define endpoint

22. Get Policy B‘s „In“Policy A‘s „Out“ compatible toB‘s „In“? Yes to Y to Y to Y send receive Policy-Driven Behavior Service A Service B

23. Policy and Web services • Three major specifications for policies • WS-Policy • statements about resources • express receiver requirements for incoming messages (e.g. transports, security) • Can be used to match requirements to capabilities • at runtime • WS-PolicyAssertions • Predefined basics • WS-PolicyAttachment • Attaching policy expression to a subject (e.g., EPR)

24. Introducing WS-Policy • WS-Policy • Provides a general framework for describing and communicating policies for Web services • A framework for making statements about resources • A policy statement contains one or more policy assertions • One use is to express receiver requirements for incoming messages • transport selection • security negotiation • Useful beyond messages: servers, services, ports, types, ...

25. WS-Policy • Policy expresses choices over domain-specific assertions • Operators and usages allow writing policies in a compact form • Preferences are hints in choosing between alternatives • Not mandatory information to follow ExactlyOne All All A B C D

26. WS-Policy Operators

27. WS-Policy Example Usage Preference <wsp:Policy xmlns:wsp=‘http://schemas.xmlsoap.org/ws/2002/12/policy’> <wsp:ExactlyOne wsp:Usage=‘wsp:Required’> <wsp:All wsp:Preference=‘1’> <wsse:SecurityToken TokenType=‘wsse:X509v3’ /> <wsse:Algorithm Type=‘wsse:AlgEncryption’ URI=‘...’/> </wsp:All> <wsp:All wsp:Preference=‘100’> <wsse:SecurityToken TokenType=‘wsse:Kerberosv5ST’ /> <wsse:Algorithm Type=‘wsse:AlgEncryption’ URI=‘...’/> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> Domain specific assertions Operator

28. WS-PolicyAssertions • TextEncoding: Character encoding • Language: Natural (human) language • SpecVersion: URI asserting compliance with spec • MessagePredicate: XPath (or other) statement about message <wsp:TextEncoding Encoding='utf-8' /> <wsp:Language Language='en-US' /> <wsp:SpecVersion wsp:Usage='wsp:Required' URI='http://schemas.xmlsoap.org/ws/2002/04/secext' /> <wsp:MessagePredicate wsp:Usage='wsp:Required' > count(wsp:GetHeader(.)/wsse:Security) = 1 </wsp:MessagePredicate>

29. WS-PolicyAttachment • Defines what a policy applies to • Associates domain expression with policy • Domain expression indicates scope • Policy makes statements about that scope <wsp:PolicyAttachment> <wsp:AppliesTo> <wsa:EndpointReference> <wsa:Address>http://workshop.org/node</wsa:Address> </wsa:EndpointReference> </wsp:AppliesTo> <wsp:Policy> . . . </wsp:Policy> </wsp:PolicyAttachment>

30. Policy and WSDL • Policy can be applied to WSDL constructs • PortType, binding, service • By pointer (reference) and/or by embedding • Policy is more general than WSDL’s binding element (wsdl:binding) • Think wsdl:portType + wsp:Policy

31. Policy and WSDL Sample • Associating policies with WSDL <wsdl:definitions name="Inventory" xmlms:wsdl="http://schemas.xmlsoap.org/wsdl" targetNamespace=”http://example.com/inventory.wsdl” ... xmlns:ps="http://example.com/policies"> <wsp:UsingPolicy wsdl:Required="true"/> <wsdl:message name="LookupResponse„ wsp:PolicyRefs="ps:Q1"> <wsdl:part name="key" type="xs:string„ wsp:PolicyRefs="ps:Q2" /> <wsdl:part name="value" type="xs:string„ wsp:PolicyRefs="ps:Q3" /> <wsdl:part name="hint" type="xs:string" /> </wsdl:message> </wsdl:definitions>

32. A word on security • Polices are often stored in configuration files • Access to these files must be secured • eg. ACLs for service accounts on Windows • Sensitive data • File encyption/decription • DPAPI • Make sure the file has not been tampered with • Sign it‘s content

33. Technology Mapping • In .NET there exist several technologies which support the afore mentioned standards and specifications • ASMX • WSE • Indigo • Critical to see what technology is available when and in which extent • Determine the differences of the various approaches • Check for other toolkits and implementations to ensure platform and vendor interoperability

34. ASMX • …

35. WSE • Web Services Enhancements (WSE) for Microsoft .NET • A product that gives developers access to enhanced Web services functionality from the WSA • Addressing, security, policy etc. • Version 3.0 delivers an extension to ASMX to support WS-* specifications in HTTP-based Web services • Version 3.0 offers new and standalone SOAP Messaging functionality and programming model • WSDL and policy are intrinsically supported • In fact, nearly everything in WSE is driven by policy • WSE provides an interception-based mechanism of assertion enforcement or validation • No concept or glue implementation like WS-MetadataExchange

36. Windows Communication Foundation(Indigo) • WCF is Microsoft’s next generation platform for all types of communication • The WCF “service model” is what developers will be faced with mostly • Integrates fully with the CLR type system • First-class WSDL and policy support • Supports message- and method-based programming • WCF implements WS-MetadataExchange to negotiate metadata

37. Recap • Contracts and policy are the entry to the world of services • Contracts and policy have to be applied in the Web services space through appropriate specifications • XML Schema provides the base for modeling data and messages • WSDL is responsible for describing the the service‘s interaction contract and message exchange patterns • Policies enable and enforce contracts with WS-Policy et. al. in the Web services area • Microsoft offers a range of technologies and products to support the notion of contract and policy for service Oriented Architecture-based software development

38. Addressing - Basic Considerations • URLs are not sufficient to cover all aspects of service addressing. • Peer-to-Peer, Request/Response communication on the same thread and channel is an simplified optimization of bidirectional message exchange • Notifications and events through volatile callbacks are a simplified optimization of pub/sub messaging

39. Basic Considerations • Consequently, we need: • A richer model for address expressions • Ways to reply via separate threads and channels • Ways to route messages through intermediaries • Ways to standardize event management and delivery

40. Messages wsa:MessageID Messages are immutable, uniquely identifiable data containers that serve to relay information for a specific purpose from a sender to a well-known recipient wsa:Action wsa:To wsa:From

41. Actions and Destinations • Identifier • Messages are immutable and uniquely identifiable • wsa:MessageID identifies a message • wsa:RelatesTo specifies a relationship to a MessageID • Sender • wsa:From identifies the sender (identifier, not location) • Recipient • Resides at a known or dynamically determinable destination • wsa:To header identifies recipient (not location) • Action • Specifies the sender's idea about what is supposed to be happening with the message content • wsa:Action header identifies action

42. wsa:To • Identifies the message recipient (endpoint) • May be a logical or network address • MUST be present in each message using WS-Addressing <wsa:To> http://tempuri.org/svc/endpoint </wsa:To>

43. wsa:From • Identifies the message sender • May be a logical or network address • Optional, but should be supplied <wsa:From> http://tempuri.org/client/endpoint </wsa:From>

44. wsa:Action • Identifies the intended activity at the recipient • Usually corresponds to wsdl:operation/@soapAction • Usually corresponds to SOAPAction: HTTP Header • MUST be present in each message using WS-Addressing <wsa:Action> http://tempuri.org/svc/endpoint/action </wsa:Action>

45. Client Service Asynchronous Reply Correlation <wsa:MessageID> uuid:A43FE910-A4E3-59d2-… </wsa:MessageID> <wsa:RelatesTo> uuid:E467D97B-84B8-4C14-… </wsa:RelatesTo> <wsa:MessageID> uuid:E467D97B-84B8-4c14-… </wsa:MessageID> EPR

46. wsa:MessageID • Identifies the message uniquely • MUST be present in each message using WS-Addressing <wsa:MessageID> uuid:586F2AB1-8595-420d-9994-36091E55857A </wsa:MessageID>

47. wsa:RelatesTo • Specifies the relationship to another message • Usually the initial request message that the current message is a reply to • MUST be present if the message is a reply <wsa:RelatesTo> uuid:586F2AB1-8595-420d-9994-36091E55857A </wsa:RelatesTo>

48. Policy Policy Client Service Schema Schema WSDL WSDL Location EPR Endpoint Reference Contract Reference Reply Path Policy Reference <wsa:EndpointReference> </wsa:EndpointReference> Location Reference XYZ <wsa:Address>address</…> <wsa:ReferenceProperties>…</…><wsa:ReferenceParameters>…</…> EPR Instance Reference <wsa:PortType>pt</…><wsa:ServiceName>sn</…> <wsp:Policy>…</…>

49. Endpoint References • An endpoint reference (EPR) encapsulates: • A network or logical address • An optional set of reference properties • Stable properties of the endpoint • Resolved into SOAP Headers at bind-time for SOAP • An optional set of reference parameters • Parameters of this endpoint reference instance • Resolved into SOAP Headers at bind-time for SOAP • Optional port-type and service-name of the endpoint • Serves to correlate with available service metadata • Associated policy rules (WS-Policy)

50. Policy Client Service OtherService Schema WSDL Reference Passing Bind & Invoke Pass Reference EPR EPR Service Reference