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

  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>

  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:[email protected]</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


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


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


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


 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

wsdl describes a service interface policies generally deï¬ne

Documents