Lecture Notes course 02267 Software Development of Web Services Hubert Baumeister huba@dtu.dk Fall 2014 Contents 1 Web Service Coordination 1 1.1 What is Coordination......................................... 1 1.2 Modeling Conversations....................................... 6 1.3 From Coordination to Composition.................................. 8 2 Conversation Controller 13 3 WS-* Standards 15 3.1 WS-* Standards............................................ 15 3.2 WS-Addressing............................................ 15 3.3 WS-ReliableMessaging........................................ 17 3.4 WS-Policy............................................... 20 1 Web Service Coordination 1.1 What is Coordination Business Process 1
Business Process involving client, supplier, and shipper Papazoglou, Web services, 2008 Composition View 2
The supplier represents a composed Web service Coordination View 3
The interaction of the client, supplier, and shipper is the focus of Web service coordination Composition / Orchestration 4
Composition / orchestration describes how a Web service is constructed from other Web services (internal view) is controlled by a central entity (e.g. the Composition engine): Conductor Coordination / Choreography Coordination / Choreography describes how Web services interact (external view) In principle not controlled, each participant agrees to play its part (but conversation controller) Each Web service in a coordination can be again based on a composition of Web services Coordination Business processes require complex interaction between participants Usually more than just a single Web service call Interactions are schematic Participants need to adhere to a protocol (exchange of messages) Problems Modelling coordination protocols Enforcing coordination protocols 5
Classification of protocols 1.2 Modeling Conversations How to specify coordination protocols? Concepts State machine State Machines I Activity diagram Sequence diagram (single conversations) Note that collaboration diagrams and sequence diagrams, in general, model only single conversations Multiple conversations are modelled with sets of sequence/collaboration diagrams receive quote Quote received /reply quotes Quote sent receive order goods Goods ordered receive cancel order Order canceled receive make payment Order completed States are the states of the protocol after sending a message or receiving a message Transitions describe the activities being performed (e.g. sending or receiving a message) 6
State Machines II initial cancel order create order order created get order unpayed pay payed get status update order UML state machines: e.g. UML Distilled by Martin Fowler http://proquest.safaribooksonline. com.globalproxy.cvt.dk/0321193687 Example Sequence Diagram Roles are boxes with a line indicating the lifeline of the role Exchange of messages is modelled by arrows between the lifelines The sequence of messages is expressed by their order w.r.t. the lifeline Activity Diagram 7
Swimlanes are used for the different roles Boxes describe actions denoting message sends and receipts Arrows between boxes describe the sequence of actions and alternative paths Comparision State machines Message exchange between two partners Focus on states of the protocol Activity diagram Message exchange between several partners Focus on activities Sequence diagram Message exchange between serveral partners Focus on single conversations only 1.3 From Coordination to Composition Coordination can be used to derive Composition Coordination protocols can be used to derive skeleton processes These processes can then be extended to the real composed Web services Advantage Composite process obeys coordination protocol 8
Coordination Protocol: Procurement Process From Coordination to Composition I 9
Coordination protocol 10
Extracted abstract process From Coordination to Composition II 11
Executable process based on the abstract process (I)(II) 12
2 Conversation Controller Conversation controllers Problem Who checks that the conversation protocols are followed? Two answers: Each participant checks conformance 13
defensive programming Easy to implement But only local checks are possible A third party checks for conformance Conversation controller (e.g. WS-Coordination) All messages need to be routed through the controller! Global conformance checks are possible Should be able to manage several conversation instances! Example for a horizontal protocol! WS-Coordination Goals: Support for coordination protocols Defines coordination contexts Information needed to implement coordination and how to include them in SOAP General framework for implementing coordination Specific protocols rely on the WS-Coordination infrastructure e.g. WS-BusinessActivy, WS-AtomicTransaction, e.t.c. http://docs.oasis-open.org/ws-tx/wscoor/2006/06/ Central or distributed coordination Central coordination Distributed coordination Coordination protocol Rules for message exchange Coordination context Runtime information needed for the coordination 14
WS-Coordination: Central coordination 3 WS-* Standards 3.1 WS-* Standards WS-* Standards Web services are based on message exchange Problems Addressing WS-Addressing Reliability WS-ReliableMessaging Security of messages WS-Security What kind of features / policies are supported by a Web-services Policies can be about addressing, reliable messaging, security policies, qualitiy of service policyes (QoS) etc. WS-Policy 3.2 WS-Addressing WS-Addressing Problem POST /axis/echostring.jws HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.4 Host: 127.0.0.1:8070 Cache-Control: no-cache Pragma: no-cache SOAPAction: "" 15
Content-Length: 436 <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope> <soapenv:body> <ns1:echo> <string xsi:type="xsd:string">hello Service</string> </ns1:echo> </soapenv:body> </soapenv:envelope> The called Web service (it is possible to have several answers) WS-Addressing a) knows who sent the message from the SOAP message b) knows who sent the message from the HTTP header c) knows who is the intended receiver from the SOAP message d) knows who is the intended receiver from the HTTP header Problem: Solution SOAP Message does not contain information who sent a message and to whom the message was addressed Transport independent encoding of these information in SOAP headers WS-Addressing Example: WS-Addressing SOAP message sent to http://fabrikam123.example/purchasing <S:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <S:Header> <wsa:messageid> uuid:6b29fc40-ca47-1067-b31d-00dd010662da </wsa:messageid> <wsa:to>http://fabrikam123.example/purchasing</wsa:to> <wsa:replyto> <wsa:address>http://business456.example/client1</wsa:address> </wsa:replyto> <wsa:action>http://fabrikam123.example/submitpo</wsa:action> </S:Header> <S:Body> <!--... --> </S:Body> </S:Envelope> Message Information Headers Uniquely identifies a message <MessageID> xs:anyuri </MessageID> Recipient of the message <To>xs:anyURI</To> (Mandatory) Semantics of the message (e.g., delete, deleteack, purchaseorder,... ) <Action>xs:anyURI</Action> (Mandatory) 16
Message relationship <RelatesTo RelationshipType=...?>xs:anyURI</RelatesTo> Sender of a message can be used for responses (depending on transport protocol) can be used for asynchornous call-backs, etc. <From>endpoint-reference</From> Overrides from information for replies/call-backs <ReplyTo>endpoint-reference</ReplyTo> Where to send a fault message <FaultTo>endpoint-reference</FaultTo> 3.3 WS-ReliableMessaging WS-ReliableMessaging Which of these statements are correct? a) SOAP messages sent via HTTP are guaranteed to reach their recipient b) It is guaranteed that SOAP messages sent via HTTP arrive in order (if they arrive at all) c) It is possible to detect if a SOAP message sent via HTTP did not reach its recipient d) It is possible to detect that a SOAP message sent via HTTP reached its recipient WS-ReliableMessaging Reliable Messaging Addresses the problem that SOAP messages can be lost during transmission Ensures that messages are retransmitted until acknowledged Ensures that messages arrive in sequence http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cs-01.html Thomas Erl, Service-Oriented Architecture 17
WS-ReliableMessaging Is an example of a horizontal protocol Message exchange / resent is transparent to the application Retransmits are done by the ReliableMessaging layer WS-ReliableMessaging Example Create Sequence Calculator example (add message) 18
Request Response Standard message: add operation Request Standard message: add operation 19
Response Delivery assurances Types AtMostOnce Messages are not resent if lost AtLeastOnce Messages are resent if lost It is possible that the same message arrives serveral times ExactlyOne Messages are resent if lost Higher adminstrative effort is needed to ensure that the same message does not arrive two times InOrder Which type to use is not part of the WS-ReliabilityMessaging protocol! Different strategies how to send and request acknowledgements 3.4 WS-Policy WS-Policy WS-Policy is a general framework for defining rules that Web services have to follow Web service either support a WS-Policy or not A WS-Policy is similar to a boolean expression (e.g. A 1 (A 2 A3)) 20
WS-Policy does not have standard assertions Assertions are defined in their own name space (e.g. WS-SecurityPolicy (http://www.oasis-open. org/committees/download.php/16569/) WS-Policy 1.2: http://www.w3.org/submission/ws-policy/ WS-Policy Example WS-Policy Example Example using WS-SecurityPolicy <wsp:policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > <wsp:exactlyone> <sp:basic256rsa15 /> <sp:tripledesrsa15 /> </wsp:exactlyone> </wsp:policy> Use either Basic256Rsa15 or TripleDesRsa15 for encryption. Basic256Rsa15 T ripledesrsa15 Assertions (Atomic) assertions are written in a domain specific assertion language (represented by a namespace) Assertions can contain again WS-Policy elements Eg. WS-RM: http://schemas.xmlsoap.org/ws/2005/02/rm/wsrm-policy.xsd <InactivityTimeout>, <BaseRetransmissionInterval>, <ExponentialBackoff>, <AcknowledgementInterval> 21
Attaching policies to operations WSDL for a service that contains a WS-Policy element <wsp:policy wsu:id="calculatorwsportbindingpolicy"> <wsp:exactlyone> <wsp:all> <wsaws:usingaddressing xmlns:wsaws="http://www.w3.org/2006/05/addressing/wsdl"/> <wsrm:rmassertion/> </wsp:all> </wsp:exactlyone> </wsp:policy>... <binding name="calculatorwsportbinding" type="tns:calculatorws"> <wsp:policyreference URI="#CalculatorWSPortBindingPolicy"/>... 22