Session 3561 Web Services Advanced Topics (P 1) IBM Software Group Beyond SOAP, WSDL, and UDDI Kelvin R. Lawrence DE & CTO, Emerging Internet Software Standards klawrenc@us. ibm. com http: //www. ibm. com/developerworks/blogs/dw_blog. jspa? blog=730 Christopher Ferris Senior Technical Staff Member chrisfer@us. ibm. com http: //www. ibm. com/developerworks/blogs/dw_blog. jspa? blog=440 © 2005 IBM Corporation Revision: 4, Mar 3 rd 2006
2 Agenda (Parts 1 and 2) An overview of several new technologies for Web Services: Ø The Web Services “stack” of technologies • A quick update on the basic web services specs. Ø Detailed look at some advanced web services topics: • Security and the Security Roadmap • Policy • Trust, Secure Conversation and Federation • • Addressing Reliable Messaging Transactions Resource Framework Notification Management Business Process Modeling and Execution Part 1 Part 2 Ø Questions 2 Web Services Advanced Topics , March 3 rd 2006 (V 4) 2
3 Web Services – a Simple View Business Processes Quality of Service Description Messaging Business Process Execution Language For Web Services (BPEL 4 WS) Reliability Transactions Management Security Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) Extensible Markup Language (XML) Other Protocols Other Services Progress in 2005: WS Reliable Exchange (WS-RX) TC Formed at OASIS, May 2005 Ø Reliable message exchanges between two Web Services OASIS WS-Security Interop Event at Gartner conference, April 2005 Ø 14 companies demonstrated interoperable WS-Security implementations WS Distributed Management approved by OASIS, March 2005 Ø Management of Web services & Management Using Web services WS Trust, Secure. Conversation, Security. Policy, WS-AT, WS-BA, WS-C submitted to OASIS RAMP Profile published 3 Web Services Advanced Topics , March 3 rd 2006 (V 4) 3
4 Web Services – A “Stack” View Business Process Execution Language (BPEL) WS-Coordination WS-Transactions WS-Security family of specifications WSDL WS-Policy SOAP, SOAP Attachments XML, XML Infoset Transports 4 WS-Reliable Messaging WS-Distributed Management Business Processes Quality of Service UDDI Description and Discovery Other protocols Other services Messaging and Encoding Transport Web Services Advanced Topics , March 3 rd 2006 (V 4) 4
5 Technologies Discussed In This Session Business Process Execution Language (BPEL) WS-Coordination WS-Transactions WS-Security family of specifications WSDL WS-Policy SOAP, SOAP Attachments XML, XML Infoset Transports 5 WS-Reliable Messaging WS-Distributed Management Business Processes Quality of Service UDDI Description and Discovery Other protocols Other services Messaging and Encoding Transport Web Services Advanced Topics , March 3 rd 2006 (V 4) 5
6 Quick SOAP, WSDL & UDDI Update 6 Web Services Advanced Topics , March 3 rd 2006 (V 4) 6
7 Basic Web Services (SOAP, WSDL, UDDI) SOAP uses XML messages for a request and response model of conversation between programs request Service Provider Service Requester response WSDL describes the interface a requester uses to invoke a service. Development tools use the WSDL document to generate SOAP code automatically. UDDI can be used to publish details of one or more services. 7 Development tools WSDL - Web Services Description Language operations, message descriptions, bindings IBM Rational Studio, Microsoft Visual Studio, Eclipse Web Services Advanced Topics , March 3 rd 2006 (V 4) 7
8 SOAP Message Structure One way messages, or Request and Response style messages 4 Request invokes a method on a remote object 4 Response returns result of running the method REMINDER: SOAP is not just about RPC SOAP specification defines an "envelope“ 4"envelope" wraps the message itself 4 the “envelope” contains a header (optional) and a body 4 message is a different vocabulary 4 namespace prefix is used to distinguish the two parts Application specific Vocabulary. SOAP Envelope Vocabulary. 8 Me ssa ge Envelope Web Services Advanced Topics , March 3 rd 2006 (V 4) 8
9 A SOAP Message <s: Envelope xmlns: s="http: //www. w 3. org/2003/05/soap-envelope"> <s: Header>…</s: Header> <s: Body> <m: Get. Last. Trade. Price xmlns: m="Some-URI"> <symbol>IBM</symbol> App. specific </m: Get. Last. Trade. Price> message </s: Body> </s: Envelope> 9 SOAP Envelope Web Services Advanced Topics , March 3 rd 2006 (V 4) 9
10 Status of SOAP, WSDL and UDDI SOAP 1. 1, WSDL 1. 1 and UDDI 2. 0 widely deployed today Ø Covered by WS-I Basic Profile 1. x W 3 C published the SOAP 1. 2 Recommendation Ø June 2003 Ø “Recommendation” status means finished, a W 3 C standard Ø Specs available at http: //www. w 3. org/TR/soap • SOAP Version 1. 2 Part 0: Primer • SOAP Version 1. 2 Part 1: Messaging Framework • SOAP Version 1. 2 Part 2: Adjuncts W 3 C Published WSDL 2. 0 Candidate Recommendation document Ø January 2006 Ø Specs available at http: //w 3. org/tr/wsdl 20 UDDI 3. 0. 2 declared an OASIS Standard (2. 0 already an OASIS standard) Ø February 2005 Ø http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=uddi-spec 10 Web Services Advanced Topics , March 3 rd 2006 (V 4) 10
11 Web Services and Security 11 Web Services Advanced Topics , March 3 rd 2006 (V 4) 11
12 Web Services and Security http: //www-128. ibm. com/developerworks/webservices/library/specification/ws-secmap Business Processes Business Process Execution Language WS-Coordination WS-Security WS-Reliable Messaging Quality of Service WS-Policy UDDI Description and Discovery WS-Transactions WSDL SOAP, SOAP Attachments XML, XML Infoset Transports Other protocols Messaging and Encoding Other services WS-Secure Conversation WS-Federation WS-Authorization Transport WS-Security Policy WS-Trust WS-Privacy WS-Security (framework) Kerberos profile REL profile Mobile profile 12 X. 509 profile Username profile SAML profile Web Services Advanced Topics , March 3 rd 2006 (V 4) 12
13 Why HTTPS is not enough for Web Services HTTPS is transport-level security Ø Ø 13 Point-to-point: lasts only for duration of the connection “All or nothing” encryption only Weak integrity concept Does not support other security mechanisms Web Services Advanced Topics , March 3 rd 2006 (V 4) 13
14 Security considerations with SOAP messaging Ø how to include security credentials in the message Ø how to use element-wise encryption: expose some parts for routing, hide critical data from unauthorized parties Ø how to use digital signatures Ø security must persist from originator to processing end-point, for the life of the transaction Ø security survives call to external business partner Ø use with, or instead of, protocol-level security 14 Web Services Advanced Topics , March 3 rd 2006 (V 4) 14
15 WS-Security: SOAP Message Security A foundational set of SOAP message extensions for building secure Web services Ø Defines new elements to be used in SOAP header for message-level security Defines the use of formerly incompatible proven and emerging security technologies: Ø Kerberos, PKI, HTTPS, IPSEC, Xr. ML Ø XML Signature, XML Encryption, XKMS from W 3 C Ø SAML, XACML from OASIS WS-Security 1. 1 standard (January 2006) Ø http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=wss Ø Widely supported in application servers and development tools from several vendors, including IBM, Microsoft, BEA, … 15 Web Services Advanced Topics , March 3 rd 2006 (V 4) 15
16 SOAP Message Structure With Security Added The SOAP specification defines the “envelope” vocabulary Ø The "envelope" wraps the message itself Ø The message is a different vocabulary Ø A namespace prefix is used to distinguish vocabularies WS-Security defines the <Security> element, which allows security extensions to be placed in <soapenv: header> Ø Username/password Ø Encryption details Ø XML Signature Ø x. 509 certificate Ø Kerberos ticket app-specific message vocabulary SOAP header: security extensions Ø Rights (REL) Ø SAML 16 SOAP envelope vocabulary Web Services Advanced Topics , March 3 rd 2006 (V 4) 16
17 The WS-Security Namespaces In the following examples you will see the WS-Security namespaces used (wsse: or wsu: prefix): The OASIS namespace URLs are too long to fit in the examples cleanly, so for reference here they are: WSSE (Web Services Security Extension) http: //docs. oasis-open. org/wss/2004/01/oasis-200401 -wsswssecurity-secext-1. 0. xsd WSU (Web Services Utility) http: //docs. oasis-open. org/wss/2004/01/oasis-200401 -wsswssecurity-utility-1. 0. xsd 17 Web Services Advanced Topics , March 3 rd 2006 (V 4) 17
18 The WS-Security <Security> element The WS-Security specification defines a vocabulary that can be used inside the SOAP envelope. <wsse: Security> is the “container” for security-related information. Define and use WS-Security namespace <S: Envelope xmlns: S="http: //www. w 3. org/2002/06/soap-envelope"> <S: Header> <wsse: Security xmlns: wsse=“…”> Security information </wsse: Security> </S: Header> <S: Body> App-specific content </S: Envelope> 18 </S: Body> SOAP Envelope Web Services Advanced Topics , March 3 rd 2006 (V 4) 18
19 The <Username. Token> element This element can be used to provide a user name within a <wsse: Security> element, for Basic Authentication <S: Envelope xmlns: S="http: //www. w 3. org/2002/06/soap-envelope"> <S: Header> <wsse: Security xmlns: wsse=“…”> <wsse: Username. Token wsu: ID=“my. Token”> <wsse: Username>kelvin</wsse: Username> <wsse: Password>elephant</wsse: Password> </wsse: Username. Token> Security Info </wsse: Security> </S: Header> <S: Body> App-specific content </S: Body> </S: Envelope> 19 Web Services Advanced Topics , March 3 rd 2006 (V 4) 19
20 The <Binary. Security. Token> element Signed security tokens, such as a Kerberos ticket or x. 509 certificate, are binary content. They must be encoded for inclusion in the wsse: Security container <S: Envelope xmlns: S="http: //www. w 3. org/2002/06/soap-envelope"> <S: Header> <wsse: Security xmlns: wsse=“…”> <wsse: Binary. Security. Token wsu: ID=“my. Token” Value. Type=“wsse: Kerberosv 5 ST” Encoding. Type=“wsse: Base 64 Binary> XIFNWZz 99 UUbalq. IEm. JZc 0 </wsse: Binary. Security. Token> Security Info </wsse: Security> </S: Header> <S: Body> App-specific content </S: Body> </S: Envelope> 20 Web Services Advanced Topics , March 3 rd 2006 (V 4) 20
21 XML Digital Signature Standard The XML Digital Signature standard defines rules for creating a digital signature and representing that signature as XML content Ø XML-Signature Syntax and Processing 1. 0: W 3 C Recommendation, February 2002 Ø http: //www. w 3. org/Signature/ Ø Definition of schema for the signature (Key. Info) Ø Procedures for computing and for verifying such signatures Ø Signature survives parsing/generation operations Ø Sign entire document, portions, or combinations of these Ø Can create multiple signatures with arbitrary keys Related specification: XML Exclusive Canonicalization Ø Specifies order of processing in computing a signature Ø http: //www. w 3. org/TR/xml-exc-c 14 n/ 21 Web Services Advanced Topics , March 3 rd 2006 (V 4) 21
22 XML Digital Signature Provides proof of integrity of XML content Ø The signed data has not changed since it was sent Ø Does NOT provide confidentiality Based on hash functions and encryption 1. Generate a hash from the data to be signed 2. Encrypt the digest to create the signature 3. The signature is sent with original content for verification purposes To verify the signature 1. Regenerate a digest of the original data that was signed 2. Decrypt the first encrypted digest (i. e. the signature) 3. Compare the two digests; a match verifies the content Along with Auditing, XML Digital Signature gives us Non-repudiation We’ll look at signatures from a Web services perspective in a moment 22 Web Services Advanced Topics , March 3 rd 2006 (V 4) 22
23 Hash functions A hash or message digest function reduces an arbitrary stream of bytes to a fixed-size number Ø the number is usually 128 or 160 bits in length It has two important properties: 1. Any change to the original input stream, even a small change, will produce a change in the hash code 2. Given an input stream and its hash code, it’s practically impossible to find a second stream with the same hash code Message Digest Algorithm 23 Message Digest Web Services Advanced Topics , March 3 rd 2006 (V 4) 23
24 General Digital Signature Processing 3 Message Digest Message Digest 4 2 Asymmetric Signature Algorithm 2 Private Key Sender 3 Signature Asymmetric Verification Algorithm 5 4 1 Asymmetric Key Pair Generation Public Key Receiver May be retrieved from a key registry 1 Public and private keys belong to the sender 3 Signature appended to message and sent 4 Compute new digest, decrypt signature, compare, valid if equal 24 Web Services Advanced Topics , March 3 rd 2006 (V 4) 24
25 XML Digital Signature An XML digital signature is stored in a <Signature> element It has three main parts <Signed. Info> – Information about what is signed <Signature. Value> – The value of the digital signature itself <Key. Info> – The public key used to verify the signature Steps: Ø Calculate a <Digest. Value> and create <Reference> elements for data to be signed Ø Add <Digest. Value> and <Reference> elements into <Signed. Info> Ø Sign the entire <Signed. Info> element to create a <Signature. Value> element Ø Add <Signed. Info>, <Signature. Value>, and <Key. Info> to <Signature> 25 Web Services Advanced Topics , March 3 rd 2006 (V 4) 25
26 Example: XML Signature 26 Signature Block Web Services Advanced Topics , March 3 rd 2006 (V 4) 26
27 Using XML Digital Signatures with SOAP As we have seen, XML Digital Signatures tells us how to sign arbitrary XML content How do we use XML Signatures with SOAP messages? ØWS-Security defines a new element in the SOAP header to hold XML Signature(s) on the content ØStandardization of these elements allows implementations from different vendors to interoperate with signatures ØWS-I Basic Security Profile (work in progress) specifies usage details to ensure interoperability. • The bulk of the profile work is now complete. • WS-I still has to finish up the work on the testing tools and sample applications to get comfortable that remaining issues have been found/ironed out. 27 Web Services Advanced Topics , March 3 rd 2006 (V 4) 27
28 Example : SOAP with XML Signature <S: Envelope> <S: Header> <wsse: Security S: must. Understand="1" xmlns: wsse=“…"> <wsse: Binary. Security. Token Encoding. Type="wsse: Base 64 Binary"> MIIDQTCC 4 Zz. O 7 t. Iger. Plaid 1 q. . . [truncated] </wsse: Binary. Security. Token> <ds: Signature xmlns: ds="http: //www. w 3. org/2000/09/xmldsig#">. . see XML Signature example for full content. . . </ds: Signature> </wsse: Security> </S: Header> <S: Body> <m: Order. Aircraft quantity=“ 1” type=“ 777” config=“Atlantic” xmlns: m=“http: //www. boeing. com/Aircraft. Order. Submission”/> </S: Body> <S: Envelope> 28 Web Services Advanced Topics , March 3 rd 2006 (V 4) 28
29 XML Encryption The XML Encryption standard defines ways to encrypt all or part of an XML document ØThe encrypted information is replaced with a single <Encrypted. Data> element ØYou can encrypt different parts of the same document with different keys ØYou can encrypt the whole document, a single element, or just the text of an element 29 Web Services Advanced Topics , March 3 rd 2006 (V 4) 29
30 Symmetric Encryption The same secret key is used to both encrypt and decrypt the message Plain text 2 message Symmetric Cipher Encrypt 3 Cipher text 4 Symmetric Cipher Decrypt 4 2 1 Sender 30 5 Plain text message Secret Key 1 Receiver Web Services Advanced Topics , March 3 rd 2006 (V 4) 30
31 Symmetric Encryption Fast Common algorithms are Triple DES (3 DES), AES, … Drawback: the key must remain secret, and it must be distributed securely to anyone we want to talk with ØIf we want secure conversations with n partners, we have to distribute n keys to them If the partner is local, we can hand them the key on any convenient digital media But if they are distant, this isn’t convenient, and we can’t safely send it to them using the Internet! 31 Web Services Advanced Topics , March 3 rd 2006 (V 4) 31
32 Asymmetric Encryption Each owner has a pair of complementary keys Ø They are different from each other Ø Encrypt with one, decrypt only with the other (in either direction) Ø We give one away (the Public key) and keep the other secret (the Private key) Ø If anyone encrypts a message with our public key, only we can decrypt the message (with our private key) Ø Conversely, if we encrypt a message with our private key, only our public key will decrypt it. So… • If a recipient successfully decrypts that message with our public key, they know we sent the message Ø Drawback: asymmetric encryption is slower than symmetric encryption 32 Web Services Advanced Topics , March 3 rd 2006 (V 4) 32
33 Asymmetric Encryption Encrypt with the receiver's Public Key -- only the receiver can decrypt the message Plain text message 2 Asymmetric Cipher Encrypt 3 Cipher text 4 Asymmetric Cipher Decrypt Plain text 5 message 4 2 1 Sender Public Key Asymmetric Key Pair Generation Private Key Receiver 1 Public and private keys belong to the receiver Public Key Cryptography, the basis for PKI 33 Web Services Advanced Topics , March 3 rd 2006 (V 4) 33
34 What’s in <Encrypted. Data> An <Encrypted. Data> element contains these elements Ø <Encryption. Method> – The algorithm used to encrypt the data Ø <Key. Info> – Information about the key used to encrypt the data Ø <Cipher. Data> – Contains the • <Cipher. Value> element, which in turn - Contains the actual encrypted data As we'll see shortly, XML encryption in the context of Web services changes the format a little 34 Web Services Advanced Topics , March 3 rd 2006 (V 4) 34
35 W 3 C XML Encryption specifications Who: W 3 C Working Group Ø http: //www. w 3. org/Encryption/ Ø Started as joint proposal by IBM, Microsoft, Entrust Purpose: Ø Encrypting data and representing the result in XML Ø Can encrypt: an entire XML document, elements, element content, arbitrary data, or a combination of these Ø <Encrypted. Data> replaces encrypted element or content, or is the root of an encrypted document Status: W 3 C Recommendations, December 2002 Ø XML Encryption Syntax and Processing 1. 0 Ø Decryption Transform for XML Signature 1. 0 Availability: Ø Web. Sphere 6 Ø Apache XML Security project: http: //xml. apache. org/security/index. html 35 Web Services Advanced Topics , March 3 rd 2006 (V 4) 35
36 WS-Security Utilizes W 3 C XML Encryption <Encrypted. Data> element replaces the content being encrypted. It contains: Ø <Encryption. Method> Algorithm used to encrypt the data Ø <Cipher. Data> • <Cipher. Value> Element containing the encrypted data <Encrypted. Key> element placed in security header, contains Ø <Encryption. Method> Algorithm used to encrypt symmetric key Ø <Key. Info> Identifier of key used to encrypt symmetric key Ø <Cipher. Data> • <Cipher. Value> Encrypted symmetric key value Ø <Reference. List> List of <Data. Reference>s to content encrypted with this symmetric key 36 Web Services Advanced Topics , March 3 rd 2006 (V 4) 36
37 Example: entire <body> contents encrypted <Pay. Balance. Due xmlns='http: //example. org/paymentv 2'> <Name>John Smith<Name/> <Credit. Card Limit='5, 000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> Unencrypted original content </Credit. Card> Red text is data to be encrypted Green text is left unencrypted </Pay. Balance. Due > <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' of encryption Result Type='http: //www. isi. edu/in-notes/iana/assignments/mediatypes/text/xml'> <Cipher. Data><Cipher. Value>A 23 B 4 C 6</Cipher. Value></Cipher. Data> </Encrypted. Data> “Pay. Balance. Due” element identity is hidden in encrypted form. We can't even see what kind of transaction it is! 37 (The real cipher would be longer than this) Web Services Advanced Topics , March 3 rd 2006 (V 4) 37
38 Example: one element and sub-elements encrypted <Pay. Balance. Due xmlns='http: //example. org/paymentv 2'> Red text is data to be encrypted <Name>John Smith<Name/> Green text is left unencrypted <Credit. Card Limit='5, 000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </Credit. Card> </Pay. Balance. Due > <Pay. Balance. Due xmlns='http: //example. org/paymentv 2'> <Name>John Smith<Name/> <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' Type='http: //www. isi. edu/in-notes/iana/assignments/mediatypes/text/xml'> <Cipher. Data><Cipher. Value>A 23 B 4 C 6</Cipher. Value></Cipher. Data <Credit. Card> group was replaced > by <Encrypted. Data> element </Encrypted. Data> </Pay. Balance. Due > 38 Web Services Advanced Topics , March 3 rd 2006 (V 4) 38
39 Example: element text (only) encrypted <Pay. Balance. Due xmlns='http: //example. org/paymentv 2'> Red text is data to be encrypted <Name>John Smith<Name/> Green text is left unencrypted <Credit. Card Limit='5, 000' Currency='USD'> <Number>4018 2445 0277 5567</Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </Credit. Card> </Pay. Balance. Due > <Pay. Balance. Due xmlns='http: //example. org/paymentv 2'> <Name>John Smith<Name/> <Credit. Card Limit='5, 000' Currency='USD'> <Number> <Encrypted. Data xmlns='http: //www. w 3. org/2001/04/xmlenc#' Type='http: //www. isi. edu/in-notes/iana/assignments/media-types/text/xml'> <Cipher. Data><Cipher. Value>A 23 B 4 C 6</Cipher. Value></Cipher. Data> </Encrypted. Data> </Number> Text was replaced by an <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> Encrypted. Data element </Credit. Card> </Pay. Balance. Due > 39 Web Services Advanced Topics , March 3 rd 2006 (V 4) 39
40 Status of WS-Security http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=wss Latest WS-Security specifications and work in progress: Ø The OASIS Standard for WS-Security 1. 0 was approved, April 2004 • WS-Security (core) specification • Username Token Profile • X. 509 Token Profile Ø The OASIS Standard for WS-Security 1. 1 has just been approved Ø WS-Security 1. 1 (errata, updates, new profiles) - Kerberos Token Profile SAML Token Profile Rights Expression Language (REL) Token Profile Soap With Attachments (SWA) Profile Ø The WSS Technical Committee has also produced • WS-Security 1. 0 Errata (non normative) 40 Web Services Advanced Topics , March 3 rd 2006 (V 4) 40
41 41 Web Services Advanced Topics , March 3 rd 2006 (V 4) 41
42 Web Services and Policy 42 Web Services Advanced Topics , March 3 rd 2006 (V 4) 42
43 Web Services Policy Framework Business Process Execution Language WS-Coordination Business Processes WS-Security WS-Reliable Messaging Quality of Service WS-Policy UDDI Description and Discovery Other protocols Other services Messaging and Encoding WS-Transactions WSDL SOAP, SOAP Attachments XML, XML Infoset Transports Transport WS-Policy Assertions WS-Policy (framework) 43 WS-Security Policy other policies WS-Policy Attachments Web Services Advanced Topics , March 3 rd 2006 (V 4) 43
44 What is a policy? A policy is a set of capabilities, requirements, preferences, and general characteristics about entities in a system The elements of a policy (policy assertions) can express: ØSecurity requirements or capabilities ØVarious Quality of Service (Qo. S) characteristics ØAny other kinds of policies that are required by a service WS-Policy defines a general purpose, extensible model and grammar (“framework”) for describing policies in a Web services system ØSimple, declarative policies ØMore complex, conditional policies 44 Web Services Advanced Topics , March 3 rd 2006 (V 4) 44
45 WS-Policy http: //ibm. com/developerworks/webservices/library/ws-polfram WS-Policy defines the framework for policy definition WS-Policy Assertions WS-Security Policy WS-Policy (framework) other policies WS-Policy Attachments ØThe container element <Policy> ØThe organizing operator elements <All>, <Exactly. One> ØThe “Optional” attribute ØAn inclusion / reuse mechanism WS-Policy does NOT define: ØAny specific policy assertions. These are defined by, WSSecurity. Policy, WS-RM Policy and others yet to be invented. ØThe binding to a policy subject. • This is defined in WS-Policy. Attachment. 45 Web Services Advanced Topics , March 3 rd 2006 (V 4) 45
46 Policy Operators <wsp: Policy xmlns: wsp=". . . " xmlns: wsse=". . . "> <wsp: Exactly. One> <wsp: All/> <some-ns: assertion 1 /> <some-ns: assertion 2 /> </wsp: All> <wsp: All/> <some-ns: assertion 3 /> <some-ns: assertion 4 /> </wsp: All> </wsp: Exactly. One> </wsp: Policy> Operators can be Exactly. One, or All. In this example: • The primary operator Exactly. One, is a policy statement (alternative) • The subordinate operator All, groups two related policy assertions 46 Web Services Advanced Topics , March 3 rd 2006 (V 4) 46
47 Policy Inclusion <wsp: Policy wsu: Id="audit" xmlns: wsu=". . . " xmlns: wssx=". . . "> <wssx: Audit wsp: Optional=“true”/> </wsp: Policy> <wsp: Policy xmlns: wsse=". . . "> <wsp: Policy. Reference URI="#audit"/> <wsse: Security. Token. Type="wsse: X 509 v 3“ /> </wsp: Policy> <wsp: Policy. Reference> allows assertions to be shared among policy expressions. It includes the content of one policy expression in another expression. In this example: • the wsu: ID attribute defines a reference to the <wssx: Audit> element • the <wssx: Audit> element effectively replaces the <wsp: Policy. Reference> element in the policy statement. 47 Web Services Advanced Topics , March 3 rd 2006 (V 4) 47
48 Reusing a portion of a policy <wsp: Policy xmlns: Security. NS=". . . " xmlns: cus=". . . "> <cus: Assert 1> <wsp: Exactly. One wsu: Id="options"> <cus: Option 1 /> <cus: Option 2 /> <cus: Option 3 /> </wsp: Exactly. One > </cus: Assert 1> <cus: Assert 2> <wsp: Policy. Reference URI="#options"/> </cus: Assert 2> </wsp: Policy> The identification mechanism for <wsp: Policy. Reference> can also be used with operator elements. In this example: • the wsu: ID attribute defines a reference to the <wsp: Exactly. One> group • the < wsp: Exactly. One > group effectively replaces the <wsp: Policy. Reference> element in the policy statement. 48 Web Services Advanced Topics , March 3 rd 2006 (V 4) 48
49 WS-Security. Policy Business Processes Business Process Execution Language WS-Coordination WS-Security WS-Reliable Messaging Quality of Service WS-Policy UDDI Description and Discovery Other protocols Other services Messaging and Encoding WS-Transactions WSDL SOAP, SOAP Attachments XML, XML Infoset Transports Transport WS-Policy Assertions WS-Policy (framework) 49 WS-Security Policy other policies WS-Policy Attachments Web Services Advanced Topics , March 3 rd 2006 (V 4) 49
50 Security Policy Example <wsp: Policy xmlns: wsp=". . . “xmlns: sp=". . . "> <sp: Symmetric. Binding > <wsp: Policy> <sp: Protection. Token> <wsp: Policy> <sp: Kerberos. V 5 APREQToken sp: Include. Token=". . . /Include. Token/Once" /> </wsp: Policy> </sp: Protection. Token> <sp: Sign. Before. Encrypting /> Note that wsp: Policy can be <sp: Encrypt. Signature /> nested to scope assertions and </wsp: Policy> also that wsp: Policy includes an </sp: Symmetric. Binding> implicit wsp: All <sp: Signed. Parts> <sp: Body/> <sp: Header Namespace="http: //schemas. xmlsoap. org/ws/2004/08/addressing" /> </sp: Signed. Parts> <sp: Encrypted. Parts> <sp: Body/> </sp: Encrypted. Parts> </wsp: Policy> 50 Web Services Advanced Topics , March 3 rd 2006 (V 4) 50
51 WS-Security. Policy (Status) Spec (and schema) Submitted to OASIS October 2005 Ø http: //schemas. xmlsoap. org/ws/2005/07/securitypolicy/ Being worked on by the OASIS WS-SX TC Ø http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=ws-sx 51 Web Services Advanced Topics , March 3 rd 2006 (V 4) 51
52 WS-Policy. Attachments Business Process Execution Language WS-Coordination Business Processes WS-Security WS-Reliable Messaging Quality of Service WS-Policy UDDI Description and Discovery Other protocols Other services Messaging and Encoding WS-Transactions WSDL SOAP, SOAP Attachments XML, XML Infoset Transports Transport WS-Policy Assertions WS-Policy (framework) 52 WS-Security Policy other policies WS-Policy Attachments Web Services Advanced Topics , March 3 rd 2006 (V 4) 52
53 WS-Policy. Attachment Specification http: //ibm. com/developerworks/webservices/library/ws-polatt/ Defines means of associating a policy expression with one or more subjects or resources: Ø arbitrary XML element(s) (policy is defined as part of the definition of the subject) Ø arbitrary non-XML resource(s) (policy is externally bound) Describes the use of these mechanisms with WSDL and UDDI artifacts: Ø How to reference policies from WSDL definitions • Messages and Port. Types Ø How to associate policies with specific instances of WSDL services • Services and Ports Ø How to associate policies with UDDI entities • business. Service and binding. Template Ø How to define a policy expression in a UDDI registry as a t. Model Such bindings need to be able to be secured (so they can be trusted) 53 Web Services Advanced Topics , March 3 rd 2006 (V 4) 53
54 Resources: Policy All specs are available on http: //ibm. com/developerworks ØSearch for WS-Policy to get the entire list Web Services Policy Framework Ø http: //www-128. ibm. com/developerworks/library/specification/ws-polfram/index. html Understanding WS-Policy processing Ø http: //www-128. ibm. com/developerworks/webservices/library/ws-policy. html Whitepaper: “Web Services Security: Moving up the stack“ Øhttp: //ibm. com/developerworks/webservices/library/ws-secroad/ 54 Web Services Advanced Topics , March 3 rd 2006 (V 4) 54
55 Trust, Secure Conversation and Federation 55 Web Services Advanced Topics , March 3 rd 2006 (V 4) 55
56 Beyond Message Security http: //ibm. com/developerworks/webservices Business Process Execution Language WS-Coordination WS-Security WS-Reliable Messaging Quality of Service WS-Policy UDDI Description and Discovery WS-Transactions WSDL SOAP, SOAP Attachments XML, XML Infoset Transports Other protocols Messaging and Encoding Other services WS-Secure Conversation WS-Federation WS-Authorization Transport WS-Security Policy WS-Trust WS-Privacy WS-Security (framework) Kerberos profile Xr. ML profile XCBF profile 56 X 509 profile Username profile SAML profile Web Services Advanced Topics , March 3 rd 2006 (V 4) 56
57 WS-Trust http: //ibm. com/developerworks/webservices/library/ws-trust/ Security Token Service A model for direct and brokered trust relationships ØThird parties and intermediaries Service Requester Service Provider ØManage credentials across different trust domains Defines: ØThe “security token service” • A trusted authority for security tokens implemented as a Web service ØSOAP messages sent to this service for security token issuance, validation and exchange (request/response). 57 Web Services Advanced Topics , March 3 rd 2006 (V 4) 57
58 WS-Trust Request/Response Requesting a token: <wst: Request. Security. Token Context=". . . "> <wst: Token. Type>. . . </wst: Token. Type> <wst: Request. Type>. . . </wst: Request. Type> </wst: Request. Security. Token> Responding with a token: <wst: Request. Security. Token. Response Context=". . . "> <wst: Token. Type>. . . </wst: Token. Type> <wst: Requested. Security. Token>. . . </wst: Requested. Security. Token> </wst: Request. Security. Token. Response> 58 Web Services Advanced Topics , March 3 rd 2006 (V 4) 58
59 WS-Secure Conversation http: //ibm. com/developerworks/webservices/library/ws-secon/ Establish a secure, shared security context in which to exchange multiple messages Defines the mechanisms for ØEstablishing and sharing security contexts ØDeriving session keys from security contexts Defines 3 ways of establishing a security context ØSecurity context token created by a security token service ØSecurity context token created by one of the communicating parties and propagated with a message ØSecurity context token created through negotiation 59 Web Services Advanced Topics , March 3 rd 2006 (V 4) 59
60 Security. Context. Token Example § Security. Context header § Identifies the security § § context using a URI Indicates the creation time of the security context Indicates the expiration time of the security context Holds the shared secrets of the security context References a shared secret of the security context <wsse: Security. Context. Token wsu: Id=". . . "> <wsu: Identifier>. . . </wsu: Identifier> <wsu: Created>. . . </wsu: Created> <wsu: Expires>. . . </wsu: Expires> <wsse: Keys> <xenc: Encrypted. Key Id=". . . ">. . . </xenc: Encrypted. Key> <wsse: Security. Token. Reference>. . . </wsse: Keys> </wsse: Security. Context. Token> 60 Web Services Advanced Topics , March 3 rd 2006 (V 4) 60
61 Standards Update WS-Trust & WS-Secure. Conversation ØSpecs & schemas submitted to OASIS, October 17 th 2005 Øhttp: //schemas. xmlsoap. org/ws/2005/02/trust Ø http: //schemas. xmlsoap. org/ws/2005/02/sc Being worked on by the new WS-SX TC Ø http: //lists. oasis-open. org/archives/members/200510/msg 00007. html Ø http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=ws-sx 61 Web Services Advanced Topics , March 3 rd 2006 (V 4) 61
62 WS-Federation http: //ibm. com/developerworks Requester’s organization Security Token(s) Security Token Service A federation is a collection of security realms (e. g. partner organizations) Œ that have established trust to share security information about users Security Service Token(s) belonging to the realms: Requester Provider’s organization TRUST Security Token Service Security Token(s) w Ø identification, authentication Ø attributes, authorization Service Provider Security Token(s) Policy The WS-Federation Specification: Ø builds on the WS-Trust model Ø can share this data using different or like mechanisms Ø defines mechanisms for the brokering of trust and for security token exchange between trust domains Ø does not require local identities at target services Ø optionally allows hiding of identity info and other attributes 62 Web Services Advanced Topics , March 3 rd 2006 (V 4) 62
63 WS-Federation - purpose Suppose: ØA value network is composed of various organizations, systems, applications, and business processes. ØParticipants include customers, employees, partners, suppliers, and distributers ØThere is no single entity for identity, authentication, authorization, etc, because the cost of centralized identity management is high. Instead, there may be several such entities. ØWe need to manage security across multiple trust domains and among multiple business partners using multiple identity authorities. WS-Federation is a specification to solve this and other problems. 63 Web Services Advanced Topics , March 3 rd 2006 (V 4) 63
64 Building on other security technologies WS-Federation is not intended as a complete security solution. Instead, it builds on other Web services technologies: ØWS-Policy specs can be used to indicate that a Web service requires a set of claims (security tokens and related message elements) in order to process an incoming request ØWS-Trust mechanisms can be used by the requester to acquire additional security tokens it may require ØWS-Security (WSS-SOAP Message Security) defines SOAP extensions used to provide security tokens ØWS-Metadata. Exchange defines a mechanism for exchanging policies, WSDL, and schemas for services within the federation 64 Web Services Advanced Topics , March 3 rd 2006 (V 4) 64
65 Security Token Services A generic service that issues or exchanges security tokens using a common model and set of messages. ØFollows the WS-Trust specification. ØMay be part of requester organization, provider organization, or a third party trusted by both of these. Common functions: ØVerify credentials for entrance to a security realm ØEvaluate the trust of supplied security tokens ØIdentity Provider – performs peer entity authentication and can make identity claims in issued security tokens 65 Web Services Advanced Topics , March 3 rd 2006 (V 4) 65
66 A Simple Direct Trust Federation Scenario Œ Security tokens from Requester’s organization are used to acquire security Requester’s organization Security Token(s) Security Token Service Œ Security Service Token(s) Requester 66 Provider’s organization TRUST Security Token Service Security Token(s) w Service Provider Security Token(s) Policy tokens from Provider’s organization w which are required by the provider for the service request message. The requester’s token is exchanged, stamped, or cross-certified by provider’s Security Token Service. Web Services Advanced Topics , March 3 rd 2006 (V 4) 66
67 Another Direct Trust Federation Scenario Œ Security tokens from Requester’s organization are sent directly to Requester’s organization Security Token(s) Security Token Service Provider’s organization TRUST Œ Security Service Token(s) Requester 67 Security Token Service Security Token(s) w Service Provider Security Token(s) Policy provider’s service. w The service uses its Security Token Service to understand validate the requester’s security token. The validation response is sent as a security token which includes authentication and authorization data. Web Services Advanced Topics , March 3 rd 2006 (V 4) 67
68 Federation Scenario with Indirect Trust Third-party Security Token(s) Security Token Service Œ Security Service Token(s) Requester 68 w x TRUST Security Token Service Requester’s organization Security Token(s) Policy Provider’s organization Security Token Service Security Token(s) In that case, the two organizations may choose to use a trusted third party to establish and confirm trust for the transaction. w. The provider asks the third party to verify the security token y There may not be a direct trust relationship between requester and provider organizations. x. The third party contacts Service Provider Security Token(s) Policy the requester to verify the security token Steps 1, 2, and 5 are as before. Web Services Advanced Topics , March 3 rd 2006 (V 4) 68
69 Multi-party Federation There might be several organizations involved in a business process, with multiple trust realms. Steps 4 and 5 are the same as 2 and 3, except they are for a different transaction from a different provider. Provider 1 Requester’s organization Security Token Service TRUST Service Provider 69 w Provider 2 TRUST Security Token Service x Œ Service Requester y Service Provider Web Services Advanced Topics , March 3 rd 2006 (V 4) 69
70 Delegation A Web service provider may need to access another Web service on behalf of a requester. The delegator provides security tokens to allow or indicate proof of delegation. There are other possible variations on this scenario. Requester’s organization Delegator’s organization Security Token Service Œ Service Requester 70 TRUST w Provider 2 TRUST Security Token Service x Service Provider y Service Provider Web Services Advanced Topics , March 3 rd 2006 (V 4) 70
71 Resources: WS-Federation http: //ibm. com/developerworks/webservices Federation of Identities in a Web services world ØOverview of goals and technologies Ø http: //www-128. ibm. com/developerworks/webservices/library/ws-fedworld/ Web Services Federation Language ØThe specification itself Ø http: //www-106. ibm. com/developerworks/webservices/library/ws-fed/ WS-Federation: Active Requestor Profile WS-Federation: Passive Requestor Profile ØThese specs define how the WS-Federation model is applied to active and passive requestors 71 Web Services Advanced Topics , March 3 rd 2006 (V 4) 71
72 WS-Security Implementation in Web. Sphere SOAP request header construction • Security token generation • Digital signature generation • Content encryption Client SOAP request header processing • Validate security tokens • Set up security context • Decrypt content • Digital signature validation Web. Sphere App Server Request Response Handler Deployment Descriptor Requester App Deployment Descriptor SOAP response header processing • Decrypt content • Digital signature validation 72 Provider App SOAP response header construction • Digital signature generation • Content encryption Web Services Advanced Topics , March 3 rd 2006 (V 4) 72
73 Deployment Descriptor for Security requirements WS-Security requirements are specified as security constraints in the Deployment Descriptor: Deployment Descriptor Ø Should the message be digitally signed or encrypted? Ø What is the trust mode for identity assertion? Ø What are the security tokens to be used as the caller identity? The Security Handlers act on the specified constraints to enforce WS-Security requirements This approach supports a separation of roles: Ø Developer of Web Service provider or requester app Ø Assembler or deployer of Web Service It also makes it easy to revise security requirements, since they are specified separately from the application code. Ø Microsoft. Net approach generates code to handle security; this is less flexible for dealing with changing security requirements 73 Web Services Advanced Topics , March 3 rd 2006 (V 4) 73
74 Time for a break END OF PART 1 We’ll continue this thread of discussion in the “Part 2” session. I hope to see you all there. 74 Web Services Advanced Topics , March 3 rd 2006 (V 4) 74
IBM Software Group Web Services Advanced Topics Beyond SOAP, WSDL, and UDDI Thanks for attending. © 2005 IBM Corporation
Session 3562 IBM Software Group Web Services Advanced Topics (P 2) Beyond SOAP, WSDL, and UDDI Kelvin R. Lawrence CTO, Emerging Internet Software Standards klawrenc@us. ibm. com http: //www. ibm. com/developerworks/blogs/dw_blog. jspa? blog=730 Christopher Ferris Senior Technical Staff Member chrisfer@us. ibm. com http: //www. ibm. com/developerworks/blogs/dw_blog. jspa? blog=440 © 2005 IBM Corporation Revision: 3, October 27 th 2005
77 Agenda (Parts 1 and 2) An overview of several new technologies for Web Services: Ø The Web Services “stack” of technologies • A quick update on the basic web services specs. Ø Detailed look at some advanced web services topics: • Security and the Security Roadmap • Policy • Trust, Secure Conversation and Federation • • Addressing Reliable Messaging Transactions Resource Framework Notification Management Business Process Modeling and Execution Part 1 Part 2 ØQ & A 77 Web Services Advanced Topics , March 3 rd 2006 (V 4) 77
78 Web Services – A “Stack” View Business Process Execution Language (BPEL) WS-Coordination WS-Transactions WS-Security family of specifications WSDL WS-Policy SOAP, SOAP Attachments XML, XML Infoset Transports 78 WS-Reliable Messaging WS-Distributed Management Business Processes Quality of Service UDDI Description and Discovery Other protocols Other services Messaging and Encoding Transport Web Services Advanced Topics , March 3 rd 2006 (V 4) 78
79 Technologies Discussed In This Session Business Process Execution Language (BPEL) WS-Coordination WS-Transactions WS-Security family of specifications WSDL WS-Policy SOAP, SOAP Attachments XML, XML Infoset Transports 79 WS-Reliable Messaging WS-Distributed Management Business Processes Quality of Service UDDI Description and Discovery Other protocols Other services Messaging and Encoding Transport Web Services Advanced Topics , March 3 rd 2006 (V 4) 79
80 Web Services and Addressing 80 Web Services Advanced Topics , March 3 rd 2006 (V 4) 80
81 WS-Addressing Goals Ø Allow specific service endpoint instances to be referenced. Ø Allow endpoint descriptions to be dynamically created/customized. Ø Enable asynchronous messaging. • Can be used to help build reliable/asynchronous message exchanges • When combined with WS-Reliable. Messaging for example. Ø Independent of transport or messaging system (ie app. level). Ø Allow other specs to be built easily on top of this one. Status Ø W 3 C Candidate Recommendation (August 17 th 2005) Ø Core spec • http: //www. w 3. org/TR/ws-addr-core/ Ø SOAP Binding • http: //www. w 3. org/TR/ws-addr-soap/ 81 Web Services Advanced Topics , March 3 rd 2006 (V 4) 81
82 WS-Addressing "Asynchronous" MEPs (message exchange patterns) need some form of addressing information carried in the SOAP messages WS-Addressing defines: § An Endpoint Reference (EPR) schema type § To, From, Reply. To, Faults. To SOAP header blocks § Also defines message properties such as: ØMessage. Id ØRelates. To ØAction 82 Web Services Advanced Topics , March 3 rd 2006 (V 4) 82
83 EPR -> SOAP mapping <wsa: Endpoint. Reference xmlns: wsa=". . . " xmlns: x=". . . "> <wsa: Address> http: //www. fabrikam 123. example/acct </wsa: Address> <wsa: Reference. Parameters> <x: Customer. Key>123456789</x: Customer. Key> <x: Shopping. Cart>ABCDEFG</x: Shopping. Cart> </wsa: Reference. Parameters> </wsa: Endpoint. Reference> 83 Web Services Advanced Topics , March 3 rd 2006 (V 4) 83
84 Yields. . . <S: Envelope xmlns: S="http: //www. w 3. org/2003/05/soap-envelope" xmlns: wsa=". . . " xmlns: x=". . . "> <S: Header>. . . <wsa: To>http: //example. com/acct</wsa: To> <x: Customer. Key wsa: Is. Reference. Parameter='true'> 123456789 </x: Customer. Key> <x: Shopping. Cart wsa: Is. Reference. Parameter='true'> ABCDEFG </x: Shopping. Cart>. . . </S: Header> <S: Body>. . . </S: Body> </S: Envelope> 84 Web Services Advanced Topics , March 3 rd 2006 (V 4) 84
85 Addressing SOAP header blocks (aka MAPs) <wsa: To>xs: any. URI</wsa: To> ? <wsa: From>wsa: Endpoint. Reference. Type</wsa: From> ? <wsa: Reply. To>wsa: Endpoint. Reference. Type</wsa: Reply. To> ? <wsa: Fault. To>wsa: Endpoint. Reference. Type</wsa: Fault. To> ? <wsa: Action>xs: any. URI</wsa: Action> <wsa: Message. ID>xs: any. URI</wsa: Message. ID> ? <wsa: Relates. To Relationship. Type="xs: any. URI"? > xs: any. URI </wsa: Relates. To> * <wsa: Reference. Parameters>xs: any*</wsa: Reference. Parameters> ? 85 Web Services Advanced Topics , March 3 rd 2006 (V 4) 85
86 Status WS-Addressing W 3 C Member Submission Aug 2004 Ø http: //www. w 3. org/Submission/2004/SUBM-ws-addressing-20040810/ WS Addressing WG chartered Sept 2004 WG working a very aggressive schedule ØCandidate Recommendation - August 2005 • http: //www. w 3. org/TR/ws-addr-core • http: //www. w 3. org/TR/ws-addr-soap ØExpect W 3 C REC early 2006 86 Web Services Advanced Topics , March 3 rd 2006 (V 4) 86
87 A Word About Faults WS-Addressing defines a <Fault. To> element. ØCan have faults sent to different place than main-line application messages. ØA particular piece of software may not care about the main line processing of messages but may be setup to specifically handle error notifications. 87 Web Services Advanced Topics , March 3 rd 2006 (V 4) 87
88 Web Services and Reliable Messaging 88 Web Services Advanced Topics , March 3 rd 2006 (V 4) 88
89 WS-Reliable. Messaging Business Process Execution Language (BPEL) WS-Coordination WS-Transactions WS-Security family of specifications WSDL WS-Policy SOAP, SOAP Attachments XML, XML Infoset Transports 89 WS-Reliable Messaging WS-Distributed Management Business Processes Quality of Service UDDI Description and Discovery Other protocols Other services Messaging and Encoding Transport Web Services Advanced Topics , March 3 rd 2006 (V 4) 89
90 WS-RM: Web Services Reliable Messaging Goal: Define a protocol to assure reliable message exchange between distributed applications exchange in the presence of software component, system, or network failures. Errors in transmission may disrupt a conversation ØMessages can be lost, duplicated, or arrive in a different order than they were sent ØHost systems may fail and lose volatile state Delivery Assurances supported ØAt-Most-Once, At-Least-Once, Exactly-Once, Ordered ØWhen this is not possible, a fault is raised on the Initial Sender, or the Ultimate Receiver, or both 90 Web Services Advanced Topics , March 3 rd 2006 (V 4) 90
91 WS-Reliable. Messaging: Features WS-RM (WS-Reliable. Messaging) defines: Ø A messaging protocol to identify, track, and manage reliable delivery between a source and a destination. Ø Defines a SOAP binding for interoperability WS-RM is extensible: Ø Bindings for other protocols may also be defined Ø Additional functionality (e. g. security) can be composed. WS-RM integrates with and complements other specs Ø Integrating WS-RM and WS-Security yields secure and reliable message exchange Ø WS-RM uses the WS-Policy specifications for defining and attaching reliable messaging policy assertions 91 Web Services Advanced Topics , March 3 rd 2006 (V 4) 91
92 The Reliable Messaging model Requester App Provider App x Deliver u Send Source (e. g. sender’s platform) 92 w Acknowledge v Transmit Destination (e. g. receiver’s Platform) Requester App sends a message for reliable delivery Source transmits the message (one or more times) Destination receives and acknowledges the message Destination delivers the message to the Provider App Web Services Advanced Topics , March 3 rd 2006 (V 4) 92
93 Setup for Reliable Messaging There are three requirements that must be satisfied prior to using Reliable Messaging: 1. Source must resolve Destination’s endpoint reference 2. Source must obtain Destination’s policies, if any, and send messages that conform to these requirements 3. A security context must be set up if required 93 Web Services Advanced Topics , March 3 rd 2006 (V 4) 93
94 Protocol Elements <Sequence> Ø Carries the Identifier and Message. Number that uniquely identifies the message within the Sequence context <Sequence. Acknowledgement> Ø Carries the Identifier that uniquely identifies the Sequence context Ø Carries Acknowledgement. Range elements that cover the entire set of messages received by the RM Destination for the Sequence <Ack. Requested> Ø Requests that the RM Destination send a Sequence. Acknowledgement immediately 94 Web Services Advanced Topics , March 3 rd 2006 (V 4) 94
95 Sequence Lifecycle <Create. Sequence operation> Ø A request to establish a new Sequence context Ø RM Destination creates a new Sequence context and assigns it a unique Identifier and sends Create. Sequence. Response <Close. Sequence operation> ØRM Source informs RM Destination it is done with the Sequence ØUsed for premature or normal termination <Terminate. Sequence operation> Ø RM Source sends this to RM Destination upon receipt of the Sequence. Acknowledgement that covers the complete set of messages in the Sequence <Bilateral Sequence Negotiation> Ø Optimization of the case in which the RM Source endpoint can anticipate that the RM Destination endpoint will be requesting a Sequence for reliably delivered response messages 95 Web Services Advanced Topics , March 3 rd 2006 (V 4) 95
96 Example A sequence is initiated using <Create. Sequence> Ø This is a required part of the protocol The RM Destination creates the Sequence ID The RM Source labels messages with a <Sequence>: Ø Constructs the <sequence> using the identifier returned from the destination during <Create. Sequence> (a unique sequence group id e. g. “http: //fabrikam 123. com/abc”) Ø Sends first message with id and message number 1 Ø Sends second message with id and message number 2 Ø Sends third message with id and message number 3 The <Sequence> element looks like this for the third message: <wsrm: Sequence. . . > <wsrm: Identifier>http: //fabrikam 123. com/abc</wsrm: Identifier> <wsrm: Message. Number>3</wsrm: Message. Number> </wsrm: Sequence> 96 Web Services Advanced Topics , March 3 rd 2006 (V 4) 96
97 Example (continued) Suppose message 2 is lost or delayed. The Destination: Ø Ø Ø Receives message 1 Receives message 3 Acknowledges receipt of messages 1 and 3, like so: <wsrm: Sequence. Acknowledgement> <wsrm: Identifier>http: //fabrikam 123. com/abc</wsrm: Identifier> <wsrm: Acknowledgement. Range Lower=“ 1" Upper=“ 1“/> <wsrm: Acknowledgement. Range Lower=“ 3" Upper=“ 3“/> <wsrm: Sequence. Acknowledgement> Notes: Ø The <Acknowledgement. Range> indicates a range of received messages, from a lower number to an upper number Ø More than one <Acknowledgement. Range>s can be used when there are gaps in the sequence of received message (as here) 97 Web Services Advanced Topics , March 3 rd 2006 (V 4) 97
98 Example (continued) The Source: Ø receives acknowledgement for messages 1 and 3 Ø decides to resend message 2 with same sequence group ID, along with a tag requesting immediate acknowledgement The Destination: Ø receives re-sent message 2, sends acknowledgement The Source receives the acknowledgement. The sequence is now complete. Meanwhile: Ø Destination later receives the lost copy of message 2 Ø Destination identifies and drops duplicate message (sequence id and number were retained to detect duplicates). 98 Web Services Advanced Topics , March 3 rd 2006 (V 4) 98
99 WS-RM Protocol Endpoint B Endpoint A Create. Sequence(Acks. To=EPRA) Create. Sequence. Response(Id=123) Sequence(Id=123, Message. Number=1) Sequence(Id=123, Message. Number=2) Sequence(Id=123, Message. Number=3) Close. Sequence(Id=123) Close. Sequence. Response(Id=123), Seq. Ack(Id=123, Ack. Range=1, 1, Ack. Range=3, 3) Sequence(Identifier=123, Message. Number=2) Seq. Ack(Id=123, Ack. Range=1, 3) Terminate. Sequence(Id=123) Terminate. Sequence. Response(Id=123) 99 Web Services Advanced Topics , March 3 rd 2006 (V 4) 99
100 Fault Management <Sequence. Fault>, used with the SOAP fault mechanism, signals specific exceptions in reliable message processing Some fault codes: Øwsrm: Sequence. Terminated Øwsrm: Unknown. Sequence Øwsrm: Invalid. Acknowledgement Øwsrm: Message. Number. Rollover (message number overflows unsigned long) Øwsrm: Last. Message. Number. Exceeded (message number is greater than number of previously received message that was marked “Last. Message”) Øwsrm: Sequence. Refused (can’t start requested sequence) 100 Web Services Advanced Topics , March 3 rd 2006 (V 4) 100
101 Security Considerations WS-RM recommends use of WS-Security when security is required ØThe <wsrm: Sequence> header needs to be signed with the body in order to "bind" the two together Ø<wsrm: Sequence. Acknowlegement> header MAY be signed independently (this reply, independent of the message, may not be a security concern) ØBecause Sequences commonly exchange a number of messages, it is recommended that a security context be established using WS-Secure. Conversation. 101 Web Services Advanced Topics , March 3 rd 2006 (V 4) 101
102 WS-RM Specification Status A new OASIS Technical Committee (TC) was formed in June 2005 ØWeb Services Reliable Exchange (WS-RX) TC ØThe TC has produced a Working Draft (July 2005) • WS-Reliable Messaging 1. 1 • http: //www. oasis-open. org/committees/download. php/13493/WS-Reliable. Messagingv 1. 0 -wd-01. pdf ØThe TC hopes published its 3 rd Committee Draft (Feb 2006) • Some changes to the protocol specified in the submission. • Namespace has changed since 2 nd CD 102 Web Services Advanced Topics , March 3 rd 2006 (V 4) 102
103 Reliable Messaging - Further Reading Spec as submitted to OASIS (input document) Ø http: //www. ibm. com/developerworks/webservices/library/specification/ws-rm / Whitepapers Ø Reliable Message Delivery in a Web services world • http: //www. ibm. com/developerworks/library/ws-rmdev Ø Implementation Strategies for WS-Reliable Messaging • http: //www-128. ibm. com/developerworks/webservices/library/ws-rmimp/index. html Ø WS-RM Reloaded • http: //www. ibm. com/developerworks/webservices/library/ws-rmreload/ Ø WS-RM and WS-R: Can SOAP be reliably delivered from confusion • http: //www. ibm. com/developerworks/library/ws-rmpaper/ Sample code available in the IBM ETTK Ø http: //www. alphaworks. ibm. com/tech/ettk Ø Completed 2 nd round of interop testing May 2004 103 Web Services Advanced Topics , March 3 rd 2006 (V 4) 103
104 Web Services and Transactions 104 Web Services Advanced Topics , March 3 rd 2006 (V 4) 104
105 Web Services Transactions Business Process Execution Language (BPEL) WS-Coordination WS-Transactions WS-Security family of specifications WSDL WS-Policy SOAP, SOAP Attachments XML, XML Infoset Transports 105 WS-Reliable Messaging WS-Distributed Management Business Processes Quality of Service UDDI Description and Discovery Other protocols Other services Messaging and Encoding Transport Web Services Advanced Topics , March 3 rd 2006 (V 4) 105
106 Why Transactions ? Data must be kept “consistent” A Jim knows Sum = A + B B Jim No matter what software or hardware failure, Jim expects his money to obey the law of conservation of cash: it neither evaporates nor suddenly appears from nowhere (the latter is acceptable to him, but not to the bank). 106 Move some $ Web Services Advanced Topics , March 3 rd 2006 (V 4) 106
107 The Problem – The need for Coordination Web Services are self-contained business applications Ø Based on industry standard technologies of WSDL, UDDI and SOAP Ø Provide a means for different organizations to connect their applications to conduct business across a network. Currently lack the facility to ensure consistency and reliability. Require a mechanism for all participants in a distributed application to achieve a mutually agreed outcome. Activities may have large spectrum of different behaviors Ø There is no one size fits all transaction model appropriate for all web-service-based applications. Ø Trying to define one is more futile than herding cats. • Need to consider ACID 2 PC, open nested, compensation, long-running with reconciliation, client-session scoping, . . • ACID = Atomicity (all or none) , consistency, isolation (lock), duability (long lasting) 107 Web Services Advanced Topics , March 3 rd 2006 (V 4) 107
108 Web Services Focus In Three Areas WS-Coordination WS-Atomic. Transaction WS-Business. Activity OASIS has formed the WS-TX Technical Committee (Dec 2005) http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=ws-tx 108 Web Services Advanced Topics , March 3 rd 2006 (V 4) 108
109 Specifications WS-C defines a framework for deploying coordination protocol sets Ø Activation Service Ø Registration Service Ø Coordination Context WS-AT & BA define coordination types for specific transaction models Ø Atomic transactions where the results of operations are not made visible until the completion of the unit of work. Ø Business transactions where the results of operations are made visible before the completion of the unit of work and need to be compensated rather than rolled back to undo the work. 109 Web Services Advanced Topics , March 3 rd 2006 (V 4) 109
110 Elements of WS-Coordination Defines the coordination context and provides a mechanism for resource managers to register interest in the context so that (for example) they are driver by termination protocols. §Activation service ØHow to create a context §Registration service ØHow to register interest in a context 110 Web Services Advanced Topics , March 3 rd 2006 (V 4) 110
111 Simplified WS-BA / WS-AT Comparison WS-AT Ø Short duration • Locks de rigueur Ø Suited for more controlled environment Ø Classical resource manager mapping – think database (not business processes crossing business boundaries). Ø Easier to think about and program • • “Rollback” or “commit” Automatic rollback in abnormal/error termination case. Ø All RM’s move in one direction (everybody commits or rolls back in unison). 111 WS-BA Ø Longer duration • • Avoid locks Treat even small things as individual transactions “reserve a seat” not “schedule a trip”. Do things step by step. Undo a “mess” using compensation logic. Ø Suited for loosely coupled environment Ø Business process mapping Ø More complex • “Compensate” Ø More flexible RM participation • They don’t have to trust applications so much Web Services Advanced Topics , March 3 rd 2006 (V 4) 111
112 WS Transactions Downloads From IBM ETTK available now Ø WS-C, WS-AT, and WS-BA Ø Example code Websphere Application Server 6. 0 Ø WS-C, WS-AT Code (ETTK, WAS, more) at Ø http: //www. alphaworks. ibm. com/webservices/ Articles, specifications at Ø http: //www. developerworks. ibm. com 112 Web Services Advanced Topics , March 3 rd 2006 (V 4) 112
113 Web Services Resources, Notification and Management 113 Web Services Advanced Topics , March 3 rd 2006 (V 4) 113
114 Management of Resources Business Process Execution Language (BPEL) WS-Coordination WS-Transactions WS-Security family of specifications WSDL WS-Policy SOAP, SOAP Attachments XML, XML Infoset Transports 114 WS-Reliable Messaging WS-Distributed Management Business Processes Quality of Service UDDI Description and Discovery Other protocols Other services Messaging and Encoding Transport Web Services Advanced Topics , March 3 rd 2006 (V 4) 114
115 Motivation for Web Services Resource Framework Stateful entities exist in most systems Ø Data in a purchase order Ø Current usage agreement for resources Ø Metrics associated with work load on a server Hitherto: no standard way to deal with state in Web services context Ø Each system does it in “idiosyncratic way” Ø Integration impediment Goal: Ø Formalize a mechanism to represent “state” in Web services Ø In order to help unify Grid computing, Systems management and ebusiness computing 115 Web Services Advanced Topics , March 3 rd 2006 (V 4) 115
116 What do we mean by Stateful Resource ? A specific set of state data expressible as an XML document; Has a well-defined identity and lifecycle; and Known to, and acted upon, by one or more Web services. Many possible implementations ØFiles, Database tables, EJB Entities, XML documents, Composed from multiple data sources, etc. Lifecycle expressed in terms of resource creation and destruction ØMultiple independent instances may be created and destroyed ØIdentity is assigned at creation time 116 Web Services Advanced Topics , March 3 rd 2006 (V 4) 116
117 WS-Resource: Web service + associated resource ØIn other words: • A resource with an associated Web service A WS-Resource has: ØIdentity: Can be uniquely identified/referenced ØLifetime: Often created & destroyed by clients ØState: Can be expressed as an XML document ØType: Its Web service interface An EPR “points to” a WS-Resource ØWS-Resource Qualified Endpoint Reference ØImplied Resource Pattern 117 Web Services Advanced Topics , March 3 rd 2006 (V 4) 117
118 Creating/Locating a WS-Resource Endpoint Reference Run-time environment message 118 address id Interface address Endpoint Reference Web Service resource message Web Services Advanced Topics , March 3 rd 2006 (V 4) 118
119 Scope of WS-Resource. Framework How How 119 to represent state in a Web services context is state referenced and “identified” in Web services is state modeled in XML and WSDL is state accessed through Web services to reason about lifetime of state to aggregate/collect stateful resources to reason about fault messages Web Services Advanced Topics , March 3 rd 2006 (V 4) 119
120 WS-Resource. Properties Defines: ØHow to use XML schema to model elements of resource state ØHow to associate resource’s state model with WSDL port. Type ØStandard operations for getting, setting, querying, ØStandard mechanism to use WS-Notification to subscribe for state value changes Why: ØBasis for standard resource inspection, monitoring and state management 120 Web Services Advanced Topics , March 3 rd 2006 (V 4) 120
121 Resource. Properties Document and WSDL Resource. Properties document is associated with the wsdl port. Type: <wsdl: port. Type name="Process" wsrp: Resource. Properties="process: Process. Properties"> <wsdl: operation name="find. Hosting. Operating. System"> <wsdl: operation name="Get. Resource. Property"> … <wsdl: operation name="Query. Resource. Properties"> … <wsdl: operation name="Destroy"> … </wsdl: port. Type> @Resource. Properties provides metadata to assist developers and value-add tooling 121 Web Services Advanced Topics , March 3 rd 2006 (V 4) 121
122 WS-Resource. Properties Operations Get. Resource. Property <wsrp: Get. Resource. Property> QName </wsrp: Get. Resource. Property> ØSimple single resource property element getter ØRequired Ø<wsrp: Get. Resource. Property> process: handle </wsrp: Get. Resource. Property> Ø<wsrp: Get. Resource. Property. Response> <process: handle>1577 </process: handle> </wsrp: Get. Resource. Property> 122 Web Services Advanced Topics , March 3 rd 2006 (V 4) 122
123 WS-Resource. Properties Operations Query. Resource. Properties ØExecute an expression against the resource properties document ØOptional ØQuery. Expression defines dialect by URI • XPath 1. 0, 2. 0 • XQuery • SQL • Steves. Amazing. Query. Expression <wsrp: Query. Resource. Properties> <wsrp: Query. Expression dialect=”URI”> xsd: any </wsrp: Query. Expression> </wsrp: Query. Resource. Properties> 123 Web Services Advanced Topics , March 3 rd 2006 (V 4) 123
124 WS-Resource. Properties Set Resource Properties ØModify a resource property document Øoptional <wsrp: Set. Resource. Properties> { <wsrp: Insert > xsd: any* </wsrp: Insert> | <wsrp: Update > xsd: any * </wsrp: Update> | <wsrp: Delete Resource. Property=”QName” /> }+ </wsrp: Set. Resource. Properties> 124 Web Services Advanced Topics , March 3 rd 2006 (V 4) 124
125 Status of WS-Resource. Framework Version 1. 2 Committee Specifications ØJanuary 20, 2006 ØSubmitted for consideration as OASIS Standard 125 Web Services Advanced Topics , March 3 rd 2006 (V 4) 125
126 WS-Notification Family of documents and specifications Brings enterprise quality publish and subscribe messaging to Web services ØLoosely coupled, asynchronous messaging in a Web services context WS Notification exploits WS Resource framework and other Web services technologies 126 Web Services Advanced Topics , March 3 rd 2006 (V 4) 126
127 WS-Notification Family of Documents WS-Notification is a family of documents: ØPublish-Subscribe for Web services • Whitepaper describing roles, concepts, terms, etc. ØBase Notification • Basic interfaces: Producer, Consumer, Subscription ØTopics • Topics and Topic. Spaces model in XML • Topic Expression Dialects ØBrokered Notification • Mechanisms of Publish and the Broker role 127 Web Services Advanced Topics , March 3 rd 2006 (V 4) 127
128 Base Message Exchange Pattern 128 Web Services Advanced Topics , March 3 rd 2006 (V 4) 128
129 WS-Base Notification Defines the Web services interfaces for Notification. Producers and Notification. Consumers ØIt includes standard message exchanges Øalong with operational requirements expected of them. This is the base specification on which the other WSNotification specification documents depend. Direct, point to point, notification ØWS-Base Notification ØPublish-Subscribe Notification for Web Services 129 Web Services Advanced Topics , March 3 rd 2006 (V 4) 129
130 WS-Notification ØBrings enterprise quality publish and subscribe messaging to Web services • Loosely coupled, asynchronous messaging in a Web services context ØWS Notification exploits WS Resource framework and other Web services technologies ØDirect and Brokered notification ØTopics and Topic Spaces ØBuilds on WS-Resource Framework 130 Web Services Advanced Topics , March 3 rd 2006 (V 4) 130
131 WS-Notification Status TC Chartered April 2004 TC published Committee Drafts for public review November 28, 2005 ØWS-Base Notification v 1. 3 Public Review CD ØWS-Brokered Notification v 1. 3 Public Review CD ØWS-Topics v 1. 3 Public Review CD 131 Web Services Advanced Topics , March 3 rd 2006 (V 4) 131
132 Two Major Facets Of Web Services Management Using Web Services (MUWS) Ø Management applications on a web services platform Ø Using web services to describe and access manageability of resources Management Of Web Services (MOWS) Ø An implementation of Management Using Web Services where the resource being managed is also a Web Service. 132 Web Services Advanced Topics , March 3 rd 2006 (V 4) 132
133 Management Using Web Services (MUWS) 133 Web Services Advanced Topics , March 3 rd 2006 (V 4) 133
134 WSDM History – Since Charter in Feb 2003 Broad representation Ø Management Vendors – IBM, HP, CA, BMC, … Ø Middleware Vendors – IBM, BEA, Oracle, Tibco, SAP Ø Web services Management Vendors – IBM, HP, CA, Actional, Amberpoint, SOA Manager, , Web. Methods … Ø IT Resource Vendors – IBM (Data. Power), HP, Dell, EMC, Fujitsu, Hitachi, Cisco, Intel, Novell, Sun … WSDM 1. 0 approved March 2005 Internal Interop April 2005 Ø IBM, HP, CA, Dell, Tibco, Hitachi, Datapower Public Demonstration June 2005 Ø IBM, HP, Tibco, Hitachi, Datapower WDSM 1. 1 in development for a 2 Q 2006 Standardization Ø Dependency on standardized versions of WS-Addressing, WS-RF, WS-Notification 134 Web Services Advanced Topics , March 3 rd 2006 (V 4) 134
135 Why add in this new layer? Managers need “end to end” access to manageability Ø Across platforms, languages, applications, AND existing management technologies Ø Federated management is required. Ø SLA Monitoring, Workflows, Work balancing, Utility computing, pay-per-Quality of Service… Ø Standards are just starting, we’re developing technology to help us solve these upcoming challenges Ubiquitous, low entry point infrastructure Ø HTTP & the Web It’s just distributed computing, again Ø So leverage Web services infrastructure for scalability, security, etc. , don’t re-invent it Integration/interoperability between business and IT management domains of the enterprise Ø Management systems gain visibility into business applications and processes Ø Business applications and processes can take advantage of the manageability of resources 135 Web Services Advanced Topics , March 3 rd 2006 (V 4) 135
136 Web Services Distributed Management (WSDM) Web services architecture replaces or ‘hides’ the traditional Manager/Agent architecture Managers always ‘talk’ to the resource while the actual Web Service endpoint may be supported by any number of management agents Web Services de-couple manageability capabilities from Ø HOW you access the resource Ø WHERE you access the resource Ø HOW the resource is implemented Ø WHEN the resource was implemented 136 Web Services Advanced Topics , March 3 rd 2006 (V 4) 136
137 Business Process Modeling and Execution 137 Web Services Advanced Topics , March 3 rd 2006 (V 4) 137
138 Business Process Execution Language (BPEL) WS-Coordination WS-Transactions WS-Security family of specifications WSDL WS-Policy SOAP, SOAP Attachments XML, XML Infoset Transports 138 WS-Reliable Messaging WS-Distributed Management Business Processes Quality of Service UDDI Description and Discovery Other protocols Other services Messaging and Encoding Transport Web Services Advanced Topics , March 3 rd 2006 (V 4) 138
139 Requirements for Business Processes We need a model for describing simple or complex exchanges that characterize business partner interactions ØStateful, long-running interactions involving two or more parties ØSequences of peer-to-peer message exchanges • Synchronous exchanges • Asynchronous exchanges with correlation 139 Web Services Advanced Topics , March 3 rd 2006 (V 4) 139
140 WSDL provisions for Web services Organizes Web services interfaces as Ø“port types” – groups of related operations Øthe operations themselves Defines Web services as Øa stateless interaction model of Øindividual peer-to-peer message exchanges • Synchronous exchanges or • Uncorrelated asynchronous exchanges Port Type operations 140 Web Services Advanced Topics , March 3 rd 2006 (V 4) 140
141 Separation of WHAT from HOW Business Process: what to do Ø a sequence of activities models a business process Ø IT provides tools to allow business people to define, monitor, and manage business processes WSDL: how to execute activities Ø an activity can be a Web service, defined by a SOAP interface and a WSDL description; internal, or from a business partner Ø a business process can be externalized as an activity for a client app or another business process 141 Business Process: WHAT WSDL: HOW A B C D E Application Web Services Advanced Topics , March 3 rd 2006 (V 4) 141
142 The WS-BPEL Specification http: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=wsbpel A model for describing simple or complex exchanges that characterize business partner interactions Øuse standard Web services to invoke partner’s process Øexpose resulting business process as a Web service Ødefine control elements for workflow Øcreate a fully-executable, portable script Technology proposal by IBM, BEA, and Microsoft Øversion 1. 0 published in August 2002 Øversion 1. 1 published in April 2003 Øa merger of IBM’s WSFL and Microsoft’s XLang ØSubmitted to OASIS TC with royalty-free terms Builds on and extends XML and Web Services specifications Øexpressed in XML Øuses and extends WSDL ØWSDL and XML Schema for data model ØXPath for assignments, conditions, etc 142 Web Services Advanced Topics , March 3 rd 2006 (V 4) 142
143 Web Services and Choreography A Business Process Ø is composed of choreography elements (“activities”) to define behavior Ø activities include ability to invoke Web services, control flow, etc REQUESTER Ø resulting business process is exposed as one or more Web services The BPEL model describes: Operation sequencing constraints Service Behavior (ordered activities) Service identity management Dynamic partner and service selection 1 A Port type B 2 3 C E D Port type Activities 143 Web Services Advanced Topics , March 3 rd 2006 (V 4) 143
144 BPEL and portability A BPEL script will run on any BPEL-compliant engine, so it’s platform- and vendor-neutral BPEL Modeling Tool Create with your favorite BPEL Modeling Tool 1 2 C 3 BPEL Model A E B D Port type BPEL Execution Environment 144 BPEL Execution Environment Run on any BPELcompliant platform Web Services Advanced Topics , March 3 rd 2006 (V 4) 144
145 U Handling an incoming request A The <receive> activity <process> Ø specifies partner, port type, operation it expects to receive Ø does a blocking wait Ø wakes up when the specified message is received Ø proceeds to next activity Ø optionally specifies that a new BP instance should be created on receiving the message B The <reply> activity Ø specifies same partner, port type, and operation as <receive> Ø sends the response message Ø proceeds to next activity Note: this is the synchronous model Ø Asynch model discussed on next page. operation <partner. Links> Buyer links A <receive> Other Activities B <reply> Port type Seller’s Business Process 145 Web Services Advanced Topics , March 3 rd 2006 (V 4) 145
146 Invoking a Web Service A partner can invoke a service from another partner using SOAP and WSDL. Two models: P Synchronous <process> <partner. Links> links U Seller <invoke> (synchronous) P <receive> <reply> <invoke> sends a message and the protocol waits for the response Q Asynchronous <invoke> sends a message and the BPEL engine waits for a response on the “callback” operation Note: services that are invoked can be ordinary Web services or other business processes. 146 <invoke> (asynchronous)Q <receive> <invoke> “callback” operation Port type Buyer’s Business Process Seller’s Business Processes Web Services Advanced Topics , March 3 rd 2006 (V 4) 146
147 The <sequence> and <flow> activities <sequence> activities run one at a time in the order they are listed <sequence> <flow> activities run concurrently Ø the flow activity does not complete until all its activities complete (synchronization) Ø flow branches are often <sequence>s <flow> A A B B 147 Web Services Advanced Topics , March 3 rd 2006 (V 4) 147
148 Combining flows and sequences Port type <process> <sequence> <flow>s and <sequence>s can nest to any required depth Ø a <sequence> can contain <flow>s <receive> <flow> Ø a <flow> can contain <sequence>s Ø activities link other Business Processes or Web services <reply> 148 Web Services Advanced Topics , March 3 rd 2006 (V 4) 148
149 Cross-dependencies Port type <process> A <link> can be used to alter the behavior of a <flow>, crossing the boundaries of <sequence> and <flow> as required. In this example: Ø X is declared as the source of the link Ø Y is declared as the target of the link Ø When X completes, the link becomes “active <sequence> <flow> W X Y Ø Both W and X must complete before Y can run. If either is not completed, Y waits until both are completed. 149 Web Services Advanced Topics , March 3 rd 2006 (V 4) 149
150 BPEL Data Model Variables* represent <process> context input Ø Like object instance data Ø Persistent messages shared between activities in a business process Ø Can also be used for any required non-message data Ø Define input/output of activities or context for fault- and compensation handlers activity <variable> output Port type message Ø Defined by WSDL messages or using XML Schema Ø Global or scoped definition Ø Can be manipulated via <assign> activity often using the <copy>, <from> and <to> elements. <process> Port type * Variables were called “containers” in BPEL 1. 0 150 Web Services Advanced Topics , March 3 rd 2006 (V 4) 150
151 Process Instances and Correlation Manage interaction between stateful service instances <correlation. Set> Tokens chosen for <correlations> customer. ID ØInstance identification via selected “token” in messages exchanged between services order. No Ø<correlation. Set> identifies tokens ØUsed by activities to address appropriate service instances init ØGlobal or scoped definition activities use Port type <process> For more info: http: //www-106. ibm. com/developerworks/webservices/library/ws-bp 151 Web Services Advanced Topics , March 3 rd 2006 (V 4) 151
152 Other BPEL Features These can be defined (or redefined) within a <scope>: ØFault handling ØEvent handling ØCompensation ØVariables ØCorrelation sets ØConcurrency Compensation handling Ødefine flow for undoing previously completed activities Fault handling Ødefine steps for handling a fault thrown by any activity <wait> Øfor interval Øuntil specified time <switch> ØLike C++/Java switch except condition for each case <if>, <then>, <elseif> ØWorks as you would expect. <pick> ØCombination of <receive> and switch ØHandle one of a list of expected incoming messages Event handling 152 Web Services Advanced Topics , March 3 rd 2006 (V 4) 152
153 Executable and Abstract Processes Executable processes Abstract processes ØComplete business process details Ø specify constraints of message exchange ØCan be run on all compliant environments Ø describe business protocol Q R Ø simplified model for use in business partner integration Variable 1 A Property 1 Variable n S B U C V D 153 . . . Property n A Hide Complexity B C T D Property = 42 Web Services Advanced Topics , March 3 rd 2006 (V 4) 153
154 BPEL and Standardization An OASIS TC is now working to standardize BPEL 2. 0 Øhttp: //www. oasis-open. org/committees/tc_home. php? wg_abbrev=wsbpel Latest Committee Draft (1 st September 2005) Øhttp: //www. oasis-open. org/committees/download. php/14616/wsbpel-specificationdraft. htm BPEL 1. 1 Specification – published April, 2003 Øhttp: //ibm. com/developerworks/library/ws-bpel ØSubmitted as input to the OASIS work. 154 Web Services Advanced Topics , March 3 rd 2006 (V 4) 154
155 Changes in BPEL 2. 0 (from 1. 1) Major differences between 1. 1 and 2. 0: ØAdded if-then-else, repeat. Until, validate, for. Each • Completion condition in for. Each activity ØAdded extension. Activity element. ØVariable initialization ØXPath access to variable data: "$variable[. part]/location" ØXML schema variables for WS-I compliant doc/lit-style WS interactions ØLocally declared message. Exchange for correlating receive and reply activities. 155 Web Services Advanced Topics , March 3 rd 2006 (V 4) 155
156 BPEL 4 People http: //www. ibm. com/developerworks/webservices/library/specification/ws-bpel 4 people/ WS-BPEL Extension for People – BPEL 4 People Goal: ØDefine BPEL extensions for Human user interactions that • Allow for the definition of human user interactions as part of a BPEL process - Simple scenarios, such as manual approval - Complex scenarios where the data input will be performed by the human user • Allow for the reuse of independently defined human tasks 156 Web Services Advanced Topics , March 3 rd 2006 (V 4) 156
157 BPEL Extensions for Sub-Processes http: //www. ibm. com/developerworks/webservices/library/specification/ws-bpelsubproc/ WS-BPEL 2. 0 Extensions for Sub-Processes Key features: Ø Modularization and re-use, in a portable, interoperable way. Ø Allows for the definition of sub-processes that can be reused within the same or across multiple WS-BPEL processes. Ø Invocation of a business process as a sub-process of another business process, such that its lifecycle is coupled to the lifecycle of the parent process. Ø Allows “fragments” to be defined and invoked without having to <invoke> an entire new process with its own context. Ø Describes different invocation scenarios and introduces an appropriate coordination protocol used for interoperable invocation of sub-processes across infrastructures from different vendors. 157 Web Services Advanced Topics , March 3 rd 2006 (V 4) 157
158 Resources – BPEL whitepapers and specs Visit http: //ibm. com/developerworks/webservices ØBPEL 4 WS 1. 1 Specification ØPaper: “Automating business processes and transactions in Web services: An introduction to BPELWS, WS-Coordination, and WSTransaction” ØPaper: “Business processes in a Web services world: A Quick Overview of BPEL 4 WS” ØA series of papers: “Understanding BPEL 4 WS” (explains the new alpha. Works BPEL editor and runtime) Search for “BPEL 4 WS” and “BPEL” for full list. 158 Web Services Advanced Topics , March 3 rd 2006 (V 4) 158
159 Time for a break! END OF PART 2 Thanks for sticking with us, I hope this was useful. 159 Web Services Advanced Topics , March 3 rd 2006 (V 4) 159
IBM Software Group Web Services Advanced Topics (P 2) Beyond SOAP, WSDL, and UDDI Thanks for attending. © 2005 IBM Corporation
Скачать презентацию Session 3561 Web Services Advanced Topics P 1
407f158004447219561331df8ac4c6c8.ppt