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:[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
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