wsdl describes a service interface policies generally deï¬ne

of 63 /63

Author: others

Post on 11-Feb-2022




0 download

Embed Size (px)


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></wsa:To>
<wsa:Action> </wsa:Action> </soap:Header> <soap:Body>...</soap:Body> </soap:Envelope>
<Policy> <All> <wsap:UsingAddressing /> <sp:TransportBinding>... </sp:TransportBinding> </All> </Policy>
Capability, not requirements 
<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= "” /> <ExactlyOne> <sp:TransportBinding>...</sp:TransportBinding> <sp:AsymmetricBinding>...</sp:AsymmetricBinding > </ExactlyOne> </All> </Policy>
<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:  WSPolicy defines the base syntax  WSPolicyAssertions contains a set of common message assertions  WSPolicyAttachment describes how to attach policies to WSDL contracts 
and UDDI entities  WSSecurityPolicy 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="" />   </wsp:PolicyAttachment>  
<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="
2004/01/oasis200401wssx509tokenprofile1.0#X509v3">          </wssp:SecurityToken>        </wssp:SupportedTokens>      </wssp:Identity>    </wsp:Policy>  </wsdl:definitions> 
Policies  Optional, conjunctive  Attaching policies to WSDL  Combining policies  Assertions, security 
Wspolicy intro ms996497.aspx 
Specs  Web Services Policy Framework (WSPolicy),  current version v 1.5 
No guaranteed delivery  No ordered delivery  No approach to handling delivery failures 
Solutions  WSReliability (OASIS standard, nov 2004)  WSReliableMessaging 
Goal: enable two applications to  communicate in a reliable way 
Protocols handled by the middleware 
App App
WSRM component
WSRM component
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 twoway  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=" addressing"> <wsa:Address></wsa:Address> </wsa:EndpointReference>
How to define addressing properties in WSDL  docs? 
Addressing assertion, specified as wspolicy  The meaning of this assertion, when present in a  policy alternative, is that WSAddressing is  required to communicate with the subject 
wsp:Optional="true” if I support but do not  require 
Addressing  See core and metadata specs  Short desc from BEA:
ws_addressing_intro.html  Reliable messaging 
Defines a way for supporting coordination  protocols 
It is a metaspecification, 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 protocolspecific 
central coordination
distributed coordination
CreateCoordinationContext - ... - coordination type - reply address
CreateCoordinationContextResponse - ... - coordination context - identifier - coordination type - registration address - ... ActivationCoordinatorPortType
register - ... - protocol identifier - registration callback address - participant service address registerResponse
- ... - coordinator protocol-handling address
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
registration participant
protocol participant
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
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 WSCoord  Components: 
Atomic transactions  Coordinates shortduration  activities 
Business activities  For longrunning activities 
Leverages WSCoordination: 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 
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 WSC  Sagalike 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) 
WSCoordination developer/library/WSCoordination.pdf 
Atomic transactions developer/library/WSAtomicTransaction.pdf 
Business activity developer/library/WSBusinessActivity.pdf