WSDL describes a service interface Policies generally deï¬ne

  WSDL describes a service interface   Not sufficient: many other aspects of a service 

needs to be modeled   Policies generally define the other requirements, 

constraints, and properties of a service  

<soap:Envelope> <soap:Header> <wsa:To>http://stock.contoso.com/realquote</wsa:To>

<wsa:Action>http://stock.contoso.com/GetRealQuote </wsa:Action> </soap:Header> <soap:Body>...</soap:Body> </soap:Envelope>

<Policy> <wsap:UsingAddressing /> </Policy>

policy assertion

<Policy> <wsap:UsingAddressing /> <sp:TransportBinding>... </sp:TransportBinding> </Policy>

<Policy> <ExactlyOne> <sp:TransportBinding> ... </sp:TransportBinding> <sp:AsymmetricBinding> ... </sp:AsymmetricBinding > </ExactlyOne> </Policy>

<Policy> <All> <wsap:UsingAddressing /> <sp:TransportBinding>... </sp:TransportBinding> </All> </Policy>

  Capability, not requirements 

<Policy>

<ExactlyOne> <sp:TransportBinding> ... </sp:TransportBinding> <sp:AsymmetricBinding> ... </sp:AsymmetricBinding > </ExactlyOne> </Policy>

<mtom:OptimizedMimeSerialization wsp:Optional="true"/

<sp:TransportBinding> <Policy> <sp:TransportToken> <Policy> <sp:HttpsToken RequireClientCertificate="false" /> </Policy> </sp:TransportToken> <sp:AlgorithmSuite> <Policy> <sp:Basic256Rsa15 /> </Policy> </sp:AlgorithmSuite> ... </Policy> </sp:TransportBinding>

  Wsu:Id and Name   ID is relative. Refer as                           http…. .xml/#common   Name: absolute 

<Policy wsu:Id="common"> <mtom:OptimizedMimeSerialization wsp:Optional="true"/> <wsap:UsingAddressing /> </Policy>

<Policy Name:=”http://…/common"> <mtom:OptimizedMimeSerialization wsp:Optional="true"/> <wsap:UsingAddressing /> </Policy>

<Policy wsu:Id="secure"> <All> <PolicyReference URI= "http://something.com/policy/common” /> <ExactlyOne> <sp:TransportBinding>...</sp:TransportBinding> <sp:AsymmetricBinding>...</sp:AsymmetricBinding > </ExactlyOne> </All> </Policy>

  Disjunction of conjunctions 

<Policy> <ExactlyOne> <All> <sp:TransportBinding>...</sp:TransportBinding> </All> <All> <sp:AsymmetricBinding>...</sp:AsymmetricBinding > </All> </ExactlyOne> </Policy>

 What happens if we attach many policies?  Maybe to different WSDL elements? 

  Conjunction of policies   In normal form, it is the cartesian product 

  A family of related specs:   WS‐Policy defines the base syntax   WS‐PolicyAssertions contains a set of common message assertions   WS‐PolicyAttachment describes how to attach policies to WSDL contracts 

and UDDI entities   WS‐SecurityPolicy contains security assertions    Etc...  WS-Policy

WS-PolicyAssertions WS-PolicyAttachment WS-SecurityPolicy

  Can attach policies to various WSDL elements   E.g. to a message, operation, port, binding, or service 

  The attachment point defines the scope of the policy 

  Think about modularization and reuse 

<wsdl:binding name="SecureBinding" … > <PolicyReference URI="#secure" /> <wsdl:operation name="GetRealQuote" > ...</wsdl:operation> ... </wsdl:binding>

  In a separate part or doc, specify which policy is attached to what

<wsp:PolicyAttachment>  <wsp:AppliesTo>    <wsa:EndpointReference xmlns:fabrikam="..." >       …   </wsa:EndpointReference>  </wsp:AppliesTo>  <wsp:PolicyReference URI="http://www.fabrikam123.com/policies#DSIG" />  </wsp:PolicyAttachment>  

  TextEncoding assertions (character sets)   Language    Version of WS specs   Predicates on messages 

<wsp:ExactlyOne> <wsp:Language wsp:Usage="wsp:Required" wsp:Preference="10” Language="da"/> <wsp:Language wsp:Usage="wsp:Required" wsp:Preference="7” Language="en-gb"/> <wsp:Language wsp:Usage="wsp:Required" wsp:Preference="1” Language="en"/> </wsp:ExactlyOne>

  Assertions relate to   security tokens,   message integrity,   message confidentiality,   message visibility to SOAP intermediaries,   constraints on the security header   age of a message

<wsdl:definitions>   <wsp:UsingPolicy Required="true"/>   <wsp:Policy Id="Auth.xml>     <wssp:Identity>       <wssp:SupportedTokens>         <wssp:SecurityToken TokenType="http://docs.oasis‐open.org/wss/

2004/01/oasis‐200401‐wss‐x509‐token‐profile‐1.0#X509v3">         </wssp:SecurityToken>       </wssp:SupportedTokens>     </wssp:Identity>   </wsp:Policy> </wsdl:definitions> 

  Policies   Optional, conjunctive   Attaching policies to WSDL   Combining policies   Assertions, security 

 Ws‐policy intro   http://msdn2.microsoft.com/en‐us/library/ms996497.aspx 

  Specs  Web Services Policy Framework (WS‐Policy), current version v 1.5 ▪  http://www.w3.org/TR/ws‐policy/ 

 No guaranteed delivery  No ordered delivery  No approach to handling delivery failures 

 Solutions  WS‐Reliability (OASIS standard, nov 2004)  WS‐ReliableMessaging 

 Goal: enable two applications to communicate in a reliable way 

 Protocols handled by the middleware 

App App

WSRM component

WSRM component

m m M+rm

acks

 AtMostOnce: messages delivered once, without duplication. Messages might be lost 

 AtLeastOnce: Each message sent will be delivered, or an error is raised. Messages might be sent more than once in order to ensure that the message arrives. 

 ExactlyOnce: The messages are delivered once, and once only. Failure to acknowledge the messages raises an error.  

  InOrder: The messages are sent in order. If the order is not retained, then an error is raised.   this assurance does not imply that the message cannot be resent if necessary.  

 A sequence is created for every set of message exchanges that needs to be “reliable” (e.g., in order) 

 Sequence has URI, and incremental number  The middleware takes care of inserting the headers, sending acks for each message 

 Ack returns ranges of message numbers  Source verifies correspondence 

<wsrm:CreateSequence> <wsrm:AcksTo>ENDPOINT</wsrm:AcksTo> <wsrm:Expires>800</wsrm:Expires> </wsrm:CreateSequence>

<wsrm:CreateSequenceResponse> <wsrm:Identifier>URI</wsrm:Identifier> <wsrm:Expires>500</wsrm:Expires> </wsrm:CreateSequenceResponse>

 To request a sequence from the destination, the source sends a message with an embedded CreateSequence header block. This provides the following information:  An acknowledgement endpoint   An expiry duration  An optional sequence offer ‐‐ This can be used for two‐way communication. 

 A security token ‐‐ You can use it to validate messages between the source and destination, as supported by WS‐Security 

<wsrm:Sequence> <wsrm:Identifier>SequenceURI</wsrm:Identifier> <wsrm:MessageNumber>1</wsrm:MessageNumber> </wsrm:Sequence>

<wsrm:Sequence> <wsrm:Identifier>SequenceURI</wsrm:Identifier> <wsrm:MessageNumber>4</wsrm:MessageNumber> <wsrm:LastMessage/> </wsrm:Sequence>

<wsrm:SequenceAcknowledgement> <wsrm:Identifier>SequenceURI</wsrm:Identifier> <wsrm:AcknowledgementRange Upper=”3" Lower=”2"/> </wsrm:SequenceAcknowledgement>

 SOAP does not provide a standard way to specify where a message is going, where to respond, or where to report an error  Left to the transport 

 Also, it does not specify correlation!  Incorporate message addressing information into soap messages 

 Web Services Addressing 1.0 ‐ Core  W3C Recommendation 9 May 2006 

 Web Services Addressing 1.0 ‐ SOAP Binding  W3C Recommendation 9 May 2006 

 Web Services Addressing 1.0 ‐ Metadata  W3C Working Draft February 2007 

 Defines endpoint references and message addressing properties 

 endpoint references: info needed to access an endpoint  URI  Addressing parameters (see bindings)  Quality information (metadata) 

<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Address>http://example.com/fabrikam/acct</wsa:Address> </wsa:EndpointReference>

<S:Header> <wsa:MessageID>http://example.com/someotheruniquestring</wsa:MessageID> <wsa:RelatesTo>http://example.com/someuniquestring</wsa:RelatesTo> <wsa:To>http://example.com/business/client1</wsa:To> <wsa:Action>http://example.com/fabrikam/mail/DeleteAck</wsa:Action> </S:Header> … </S:Envelope>

<S:Header> <wsa:MessageID>http://example.com/someuniquestring</wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://example.com/business/client1</wsa:Address> </wsa:ReplyTo> <wsa:To>mailto:fabrikam@example.com</wsa:To> <wsa:Action>http://example.com/fabrikam/mail/Delete</wsa:Action> </S:Header>

 How to define addressing properties in WSDL docs? 

 Addressing assertion, specified as ws‐policy  The meaning of this assertion, when present in a policy alternative, is that WS‐Addressing is required to communicate with the subject 

 wsp:Optional="true” if I support but do not require 

  Addressing   http://www.w3.org/2002/ws/addr/   See core and metadata specs   Short desc from BEA: http://dev2dev.bea.com/pub/a/2005/01/

ws_addressing_intro.html   Reliable messaging 

  Ws‐reliablemessaging (non std) ▪  http://specs.xmlsoap.org/ws/2005/02/rm/ws‐reliablemessaging.pdf 

▪  http://msdn2.microsoft.com/en‐us/library/ms951271.aspx   Ws‐reliability (std)   http://www.oasis‐open.org/committees/wsrm/ 

 Defines a way for supporting coordination protocols 

 It is a meta‐specification, a generic way to define actual coordination mechanisms 

 A method for informing parties about which ROLE they should play in a conversation  

 A method for informing parties about the port of a service participating to a conversation  

 A method for transporting coordination contexts into soap headers 

 Coordination protocol  set of rules governing the conversation (e.g., 2PC prepare/

commit, or our business protocols…)  Coordination type 

 A set of related protocols (e.g., prepare/commit + outcome notification) 

 An instance of a type can include several instances of each protocol 

 Coordination context  Data structure (called coordination) marking messages belonging 

to the same instance of the coordination type 

 Activation   A participant requests a new coordination context.  A new 

instance is created  Registration 

 A participant declares to the coordinator that it is a participant   Interactions 

 These are protocol‐specific 

 Note: activation and registration are general (horizontal) 

central coordination

distributed coordination

Copyright Springer Verlag Berlin Heidelberg 2004

CreateCoordinationContext - ... - coordination type - reply address

CreateCoordinationContextResponse - ... - coordination context - identifier - coordination type - registration address - ... ActivationCoordinatorPortType

coordinator

ActivationRequestorPortType

Web service

Copyright Springer Verlag Berlin Heidelberg 2004

register - ... - protocol identifier - registration callback address - participant service address registerResponse

- ... - coordinator protocol-handling address

coordinator

RegistrationCoordinatorPortType

Web service RegistrationRequestorPortType

Needed to inform about protocol-specific interfaces

protocol-specific messages from participant to coordinator

protocol-specific messages from coordinator to participant

coordinator

XCoordinatorPortType

Web service XParticipantPortType

Copyright Springer Verlag Berlin Heidelberg 2004

Not defined by ws-coord. It is assumed that coord and participants will have protocol-specific port types

Web service A activation participant

registration participant

protocol participant

coordinator C activation coordinator

registration coordinator

protocol coordinator

Web service B activation participant

registration participant

protocol participant

1. create CC 2. X1

3. register 4. protocol coordinator

5. operational message 6. register

7. protocol coordinator 8. protocol-specific message

9. protocol-specific message

Web service implementation

Web service implementation

Copyright Springer Verlag Berlin Heidelberg 2004

Web service A coordinator Ca Web service B coordinator Cb

1. create CC 2. X1

3. register 4. protocol coordinator

5. operational message 6. create CC

7. X2 8. register

9. register

10. protocol coordinator 11. protocol coordinator

12. protocol message 13. protocol message

14. protocol message 15. protocol message

Copyright Springer Verlag Berlin Heidelberg 2004

 Coordination context  Activation and registration interfaces/protocols 

 Architecture for centralized and distributed coordination 

 Distributed transaction management  Elements of 2PC  Elements of long running transactions 

 Set of protocol specs  Aug 2005, Microsoft, IBM, BEA, others 

 Built on top of WS‐Coord  Components: 

 Atomic transactions ‐ Coordinates short‐duration activities 

 Business activities ‐ For long‐running activities 

 Leverages WS‐Coordination: Defines a coordination type to support atomic transactions.  Create a new atomic transaction CoordinationContext  Add an interposed coordinator to an existing transaction.  Propagate the CoordinationContext in messages between web 

services.  Register for participation in coordination protocols, depending on 

the participant's role in the activity.   Protocols include Completion, PhaseZero, 2PC and 

OutcomeNotification. 

 Participant tells coord to abort or commit  Coordinator communicates decision to participant 

 Volatile:  After receiving commit request, coord sends prepare 

invitations.  All participant registered for this protocol to answer before 

any durable2PC participant is contacted  Participants not required to be notified of outcome 

 Durable:  After the above, the durable participants are involved 

 Also based on WS‐C  Saga‐like semantics: actions applied and committed. If needed, they are compensated 

  May consume many resources over a long duration.

  There may be a significant number of atomic transactions involved.

  Individual tasks within a business activity can be seen prior to the completion of the business activity.

  Exception handling mechanisms may require business logic to reverse the effects of a previously completed task.

  Participants in a business activity may be in different domains of trust where all trust relationships are established explicitly.

 AtomicOutcome: all participants close or compensate 

 MixedOutcome: results may differ 

 Messages sent to coordinator:  Completed: coord replies with close or compensate 

 Fault: coord replies with faulted  Compensated, Closed, Canceled, Exit 

 Messages sent to participants:  Close, Cancel, Compensate, Exited 

 Both accept:  getStatus and Status 

 Same as above, but coord can tell participant that work is complete (no more work to be done) 

 WS‐Coordination  ftp://www6.software.ibm.com/software/developer/library/WS‐Coordination.pdf 

 Atomic transactions  ftp://www6.software.ibm.com/software/developer/library/WS‐AtomicTransaction.pdf 

 Business activity  ftp://www6.software.ibm.com/software/developer/library/WS‐BusinessActivity.pdf