ibm software group © 2005 ibm corporation web services advanced topics (p1) beyond soap, wsdl, and...

IBM Software Group

© 2005 IBM Corporation

Web Services Advanced Topics (P1)Beyond SOAP, WSDL, and UDDI

Kelvin R. LawrenceDE & CTO, Emerging Internet Software [email protected]://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=730

Christopher FerrisSenior Technical Staff [email protected]://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

Revision: 4, Mar 3rd 2006

Session 3561

2 2

2

Web Services Advanced Topics , March 3rd 2006 (V4)

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

Questions

Part 1

Part 2

3 3

3


Business Processes

Quality of Service

Description

Messaging

Business Process Execution LanguageFor Web Services (BPEL4WS)

SecurityReliability ManagementTransactions

Web Services Description Language (WSDL)

Simple Object Access Protocol (SOAP)

Extensible Markup Language (XML)Other Protocols Other Services

Web Services – a Simple View

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, SecureConversation, SecurityPolicy, WS-AT,WS-BA,WS-C submitted to OASISRAMP Profile published

4 4

4


WS-Policy

WS-Security family of

specifications

UDDI

Web Services – A “Stack” View

Qualityof Service

Messagingand Encoding

Transport

BusinessProcesses

Other protocolsOther services

Business Process Execution Language (BPEL)

Descriptionand DiscoveryWSDL

SOAP, SOAP Attachments

XML, XML Infoset

Transports

WS-Coordination

WS-Transactions

WS-Reliable Messaging

WS-DistributedManagement

5 5

5


WS-Policy


specifications

UDDI

Technologies Discussed In This Session

Qualityof Service


Transport

BusinessProcesses





XML, XML Infoset

Transports

WS-Coordination

WS-Transactions



6 6

6


Quick SOAP, WSDL & UDDI Update

7 7

7


Basic Web Services (SOAP, WSDL, UDDI)

SOAP uses XML messages for a request and response model of conversation between programs

ServiceRequester

ServiceProvider

request

WSDL describes the interface a requester uses to invoke a service.

WSDL - Web Services Description Language

operations,message descriptions,

bindings

response

IBM Rational Studio, Microsoft Visual Studio,

Eclipse

Developmenttools

Development tools use the WSDL document to generate SOAP code automatically.

UDDI can be used to publish details of one or more services.

8 8

8


SOAP Message Structure

SOAP EnvelopeVocabulary.

Application specificVocabulary.

One way messages, orRequest and Response style messages

Request invokes a method on a remote objectResponse returns result of running the method

REMINDER: SOAP is not just about RPC

SOAP specification defines an "envelope“"envelope" wraps the message itselfthe “envelope” contains a header (optional) and a bodymessage is a different vocabularynamespace prefix is used to distinguish the two parts Message

Envelope

9 9

9


A SOAP Message

<s:Envelopexmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header>…</s:Header> <s:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>IBM</symbol> </m:GetLastTradePrice> </s:Body>

</s:Envelope> SOAP Envelope

App. specific message

10 10

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

W3C published the SOAP 1.2 Recommendation June 2003 “Recommendation” status means finished, a W3C standard Specs available at http://www.w3.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

W3C Published WSDL 2.0 Candidate Recommendation document January 2006 Specs available at http://w3.org/tr/wsdl20

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

11 11

11


Web Services and Security

12 12

12


Descriptionand DiscoveryWS-Policy

Web Services and Securityhttp://www-128.ibm.com/developerworks/webservices/library/specification/ws-secmap

WS-ReliableMessaging

UDDI


Transport

BusinessProcesses


Business Process Execution Language

WSDL


XML, XML Infoset

Transports

WS-Coordination

WS-Transactions

WS-SecurityQuality

of Service

WS-SecurityPolicy WS-Privacy

WS-SecureConversation WS-Authorization

X.509profile

Kerberosprofile

RELprofile

Usernameprofile

Mobileprofile

SAMLprofile

WS-Security (framework)

WS-Trust

WS-Federation

13 13

13


Why HTTPS is not enough for Web Services

HTTPS is transport-level security Point-to-point: lasts only for duration of the connection “All or nothing” encryption only Weak integrity concept Does not support other security mechanisms

FIREW

ALL

B ack endA pplication

"SECURE"

H TTPS to JM S

G atew ay

H TTP S securitystops here

SECURE?

In ternet

B usinessPartner

SE C U R E?

In ternet

S erviceR equester

A pp

14 14

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

FIR

EW

AL

L

B ack endA pplication

In tranet

In ternetServiceR equester

A ppG atew ay

credentialsSO A P m essage

B usinessPartner

In ternet

15 15

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, XrML XML Signature, XML Encryption, XKMS from W3C SAML, XACML from OASIS

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, …

16 16

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

Rights (REL)

SAML

app-specificmessage

vocabulary

SOAPenvelope

vocabulary

SOAP header:security

extensions

17 17

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

18 18

18


<S:Envelope

xmlns:S="http://www.w3.org/2002/06/soap-envelope">

<S:Header>

<wsse:Security xmlns:wsse=“…”>

</wsse:Security>

</S:Header>

<S:Body> </S:Body>

</S:Envelope>

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.

Security information

App-specific content

SOAP Envelope

Define and use WS-Security namespace

19 19

19


The <UsernameToken> elementThis element can be used to provide a user name within a <wsse:Security> element, for Basic Authentication

App-specific content

Security Info

<S:Envelope xmlns:S="http://www.w3.org/2002/06/soap-envelope"> <S:Header> <wsse:Security xmlns:wsse=“…”> <wsse:UsernameToken wsu:ID=“myToken”> <wsse:Username>kelvin</wsse:Username> <wsse:Password>elephant</wsse:Password> </wsse:UsernameToken> </wsse:Security> </S:Header> <S:Body>

</S:Body></S:Envelope>

20 20

20


The <BinarySecurityToken> elementSigned 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

Security Info

<S:Envelope xmlns:S="http://www.w3.org/2002/06/soap-envelope"> <S:Header>

<wsse:Security xmlns:wsse=“…”>

<wsse:BinarySecurityToken wsu:ID=“myToken” ValueType=“wsse:Kerberosv5ST” EncodingType=“wsse:Base64Binary> XIFNWZz99UUbalqIEmJZc0 </wsse:BinarySecurityToken>

</wsse:Security> </S:Header>

<S:Body> App-specific content </S:Body></S:Envelope>

21 21

21


XML Digital Signature Standard

The XML Digital Signature standard defines rules for creating a digital signature and representing that signature as XML contentXML-Signature Syntax and Processing 1.0: W3C

Recommendation, February 2002

http://www.w3.org/Signature/

Definition of schema for the signature (KeyInfo)

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.w3.org/TR/xml-exc-c14n/

22 22

22


XML Digital SignatureProvides 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 encryption1. 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 signature1. 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

23 23

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

MessageMessage

DigestAlgorithm

MessageDigest

24 24

24


General Digital Signature Processing

Message

PrivateKey

AsymmetricKey Pair

Generation

PublicKey

Sender

Receiver1

AsymmetricVerificationAlgorithm

MessageDigest

4

4

5

4 Compute new digest, decrypt signature, compare, valid if equal

Message3

3Signature

Message

May be retrievedfrom a key registry

1 Public and private keys belong to the sender

AsymmetricSignatureAlgorithm

2

2

MessageDigest

3 Signature appended to message and sent

25 25

25


XML Digital Signature

An XML digital signature is stored in a <Signature> elementIt has three main parts<SignedInfo> – Information about what is signed

<SignatureValue> – The value of the digital signature itself

<KeyInfo> – The public key used to verify the signature

Steps:Calculate a <DigestValue> and create <Reference>

elements for data to be signedAdd <DigestValue> and <Reference> elements into <SignedInfo>

Sign the entire <SignedInfo> element to create a <SignatureValue> element

Add <SignedInfo>, <SignatureValue>, and <KeyInfo> to <Signature>

26 26

26


Example: XML Signature<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#wssecurity_body_id_2601212934311668096_1040651106378"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>AWQKpmksMpzzT4PxcizO980gVHw=</DigestValue> </Reference> </SignedInfo>

<SignatureValue>bNhT+DsNN9PR [binary data has been truncated]</SignatureValue>

<KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#wssecurity_binary_security_token_id_1603091_4272645"/> </wsse:SecurityTokenReference> </KeyInfo>

</Signature>

Public K ey (optional)

Signature Value

What is signed?

Signature Block

27 27

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 contentStandardization 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.

28 28

28


<S:Envelope> <S:Header> <wsse:Security S:mustUnderstand="1" xmlns:wsse=“…"> <wsse:BinarySecurityToken EncodingType="wsse:Base64Binary"> MIIDQTCC4ZzO7tIgerPlaid1q ... [truncated] </wsse:BinarySecurityToken> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ....see XML Signature example for full content... </ds:Signature> </wsse:Security> </S:Header>

<S:Body> <m:OrderAircraft quantity=“1” type=“777” config=“Atlantic” xmlns:m=“http://www.boeing.com/AircraftOrderSubmission”/> </S:Body><S:Envelope>

Example : SOAP with XML Signature

29 29

29


XML Encryption

The XML Encryption standard defines ways to encrypt all or part of an XML documentThe encrypted information is replaced with a single <EncryptedData> 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

30 30

30


Symmetric Encryption

The same secret key is used to both encrypt and decrypt the message

Plain textmessage

Sender Receiver

1

Plain textmessage

5

1

2

SymmetricCipher

Encrypt

2

SecretKey

SymmetricCipher

Decrypt

4

4

3 Ciphertext

31 31

31


Symmetric Encryption

Fast

Common algorithms are Triple DES (3DES), 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!

32 32

32


Asymmetric Encryption

Each owner has a pair of complementary keysThey are different from each otherEncrypt 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

33 33

33


Asymmetric Encryption

Encrypt with the receiver's Public Key -- only the receiver can decrypt the message

Plain textmessage

Sender

Receiver

AsymmetricCipher

Encrypt

2

2 3Cipher

text

Plain textmessage5

PublicKey

PrivateKey

AsymmetricKey Pair

Generation

1

Public Key Cryptography, the basis for PKI

AsymmetricCipher

Decrypt

4

4

1 Public and private keys belong to the receiver

34 34

34


What’s in <EncryptedData>

An <EncryptedData> element contains these elements <EncryptionMethod> – The algorithm used to

encrypt the data

<KeyInfo> – Information about the key used to encrypt the data

<CipherData> – Contains the • <CipherValue> 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

35 35

35


W3C XML Encryption specifications

Who: W3C Working Group http://www.w3.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 <EncryptedData> replaces encrypted element or content, or is

the root of an encrypted document

Status: W3C Recommendations, December 2002 XML Encryption Syntax and Processing 1.0 Decryption Transform for XML Signature 1.0

Availability: WebSphere 6 Apache XML Security project:

http://xml.apache.org/security/index.html

36 36

36


WS-Security Utilizes W3C XML Encryption

<EncryptedData> element replaces the content being encrypted. It contains:

<EncryptionMethod> Algorithm used to encrypt the data

<CipherData>• <CipherValue> Element containing the encrypted data

<EncryptedKey> element placed in security header, contains <EncryptionMethod> Algorithm used to encrypt

symmetric key

<KeyInfo> Identifier of key used to encrypt symmetric key

<CipherData>• <CipherValue> Encrypted symmetric key value

<ReferenceList> List of <DataReference>s to content encrypted with this symmetric key

37 37

37


Example: entire <body> contents encrypted

<PayBalanceDue xmlns='http://example.org/paymentv2'> <Name>John Smith<Name/> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCard></PayBalanceDue >

<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'> <CipherData><CipherValue>A23B4C6</CipherValue></CipherData></EncryptedData>

“PayBalanceDue” element identity is hidden in encrypted form. We can't even see what kind of transaction it is!

(The real cipher wouldbe longer than this)

Unencrypted original contentRed text is data to be encryptedGreen text is left unencrypted

Result of encryption

38 38

38


Example: one element and sub-elements encrypted


<PayBalanceDue xmlns='http://example.org/paymentv2'> <Name>John Smith<Name/> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'> <CipherData><CipherValue>A23B4C6</CipherValue></CipherData> </EncryptedData></PayBalanceDue >

<CreditCard> group was replaced by <EncryptedData> element

Red text is data to be encryptedGreen text is left unencrypted

39 39

39


Example: element text (only) encrypted


<PayBalanceDue xmlns='http://example.org/paymentv2'> <Name>John Smith<Name/> <CreditCard Limit='5,000' Currency='USD'> <Number> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'> <CipherData><CipherValue>A23B4C6</CipherValue></CipherData> </EncryptedData> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration></CreditCard></PayBalanceDue >

Text was replaced by an EncryptedData element

Red text is data to be encryptedGreen text is left unencrypted

40 40

40


Status of WS-Securityhttp://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)

41 41

41


42 42

42


Web Services and Policy

43 43

43


Web Services Policy Framework

WS-SecurityWS-ReliableMessaging

UDDI

Qualityof Service


Transport

BusinessProcesses



WSDL


XML, XML Infoset

Transports

WS-Coordination

WS-Transactions

WS-PolicyDescription

and Discovery

WS-PolicyAttachments

WS-SecurityPolicy

WS-PolicyAssertions other policies

WS-Policy(framework)

44 44

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 capabilitiesVarious Quality of Service (QoS) characteristicsAny 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 systemSimple, declarative policiesMore complex, conditional policies

45 45

45


WS-Policyhttp://ibm.com/developerworks/webservices/library/ws-polfram


WS-SecurityPolicy



WS-Policy defines the framework for policy definitionThe container element <Policy>The organizing operator elements <All>, <ExactlyOne>The “Optional” attributeAn inclusion / reuse mechanism

WS-Policy does NOT define:Any specific policy assertions. These are defined by,

WS-SecurityPolicy, WS-RM Policy and others yet to be invented.

The binding to a policy subject. •This is defined in WS-PolicyAttachment.

46 46

46


Policy Operators

<wsp:Policy xmlns:wsp="..." xmlns:wsse="..."> <wsp:ExactlyOne> <wsp:All/> <some-ns:assertion1 /> <some-ns:assertion2 /> </wsp:All>

<wsp:All/> <some-ns:assertion3 /> <some-ns:assertion4 /> </wsp:All> </wsp:ExactlyOne></wsp:Policy>

Operators can be ExactlyOne, or All. In this example:• The primary operator ExactlyOne, is a policy statement

(alternative)• The subordinate operator All, groups two related policy assertions

47 47

47


Policy Inclusion

<wsp:Policy wsu:Id="audit" xmlns:wsu="..." xmlns:wssx="...">

<wssx:Audit wsp:Optional=“true”/>

</wsp:Policy>

<wsp:Policy xmlns:wsse="...">

<wsp:PolicyReference URI="#audit"/>

<wsse:SecurityToken TokenType="wsse:X509v3“ />

</wsp:Policy>

<wsp:PolicyReference> 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:PolicyReference> element in the policy statement.

48 48

48


Reusing a portion of a policy

<wsp:Policy xmlns:SecurityNS="..." xmlns:cus="..."> <cus:Assert1> <wsp:ExactlyOne wsu:Id="options"> <cus:Option1 /> <cus:Option2 /> <cus:Option3 /> </wsp:ExactlyOne > </cus:Assert1> <cus:Assert2> <wsp:PolicyReference URI="#options"/> </cus:Assert2></wsp:Policy>

The identification mechanism for <wsp:PolicyReference> can also be used with operator elements. In this example:

• the wsu:ID attribute defines a reference to the <wsp:ExactlyOne> group• the < wsp:ExactlyOne > group effectively replaces the

<wsp:PolicyReference> element in the policy statement.

49 49

49


WS-SecurityPolicy


UDDI

Qualityof Service


Transport

BusinessProcesses



WSDL


XML, XML Infoset

Transports

WS-Coordination

WS-Transactions


and Discovery




WS-SecurityPolicy

50 50

50


Security Policy Example

<wsp:Policy xmlns:wsp="...“xmlns:sp="..."> <sp:SymmetricBinding > <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:KerberosV5APREQToken sp:IncludeToken=".../IncludeToken/Once" /> </wsp:Policy> </sp:ProtectionToken> <sp:SignBeforeEncrypting /> <sp:EncryptSignature /> </wsp:Policy> </sp:SymmetricBinding> <sp:SignedParts> <sp:Body/> <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" /> </sp:SignedParts> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts></wsp:Policy>

Note that wsp:Policy can be nested to scope assertions and also that wsp:Policy includes an implicit wsp:All

51 51

51


WS-SecurityPolicy (Status)

Spec (and schema) Submitted to OASIS October 2005http://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

52 52

52




UDDI

Qualityof Service


Transport

BusinessProcesses



WSDL


XML, XML Infoset

Transports

WS-Coordination

WS-Transactions


and Discovery

WS-SecurityPolicy




53 53

53


WS-PolicyAttachment Specificationhttp://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 PortTypes

How to associate policies with specific instances of WSDL services• Services and Ports

How to associate policies with UDDI entities• businessService and bindingTemplate

How to define a policy expression in a UDDI registry as a tModel

Such bindings need to be able to be secured (so they can be trusted)

54 54

54


Resources: Policy

All specs are available on http://ibm.com/developerworksSearch 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.htm

l

Whitepaper: “Web Services Security: Moving up the stack“http://ibm.com/developerworks/webservices/library/ws-secroa

d/

55 55

55


Trust, Secure Conversation and Federation

56 56

56


Descriptionand DiscoveryWS-Policy

Beyond Message Securityhttp://ibm.com/developerworks/webservices


UDDI


Transport

BusinessProcesses



WSDL


XML, XML Infoset

Transports

WS-Coordination

WS-Transactions

WS-SecurityQuality

of Service

WS-SecurityPolicy WS-Privacy

WS-SecureConversation WS-Authorization

X509profile

Kerberosprofile

XrMLprofile

Usernameprofile

XCBFprofile

SAMLprofile

WS-Security (framework)

WS-Trust

WS-Federation

57 57

57


WS-Trusthttp://ibm.com/developerworks/webservices/library/ws-trust/

A model for direct and brokered trust relationshipsThird parties and intermediaries

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).

ServiceRequester

ServiceProvider

SecurityToken

Service

58 58

58


WS-Trust Request/Response

<wst:RequestSecurityToken Context="..."> <wst:TokenType>...</wst:TokenType> <wst:RequestType>...</wst:RequestType></wst:RequestSecurityToken>

Responding with a token:

<wst:RequestSecurityTokenResponse Context="..."> <wst:TokenType>...</wst:TokenType> <wst:RequestedSecurityToken>...</wst:RequestedSecurityToken></wst:RequestSecurityTokenResponse>

Requesting a token:

59 59

59


WS-Secure Conversationhttp://ibm.com/developerworks/webservices/library/ws-secon/

Establish a secure, shared security context in which to exchange multiple messages

Defines the mechanisms forEstablishing and sharing security contexts

Deriving session keys from security contexts

Defines 3 ways of establishing a security contextSecurity 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

60 60

60


SecurityContextToken Example

SecurityContext 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:SecurityContextToken wsu:Id="...">

<wsu:Identifier>...</wsu:Identifier>

<wsu:Created>...</wsu:Created>

<wsu:Expires>...</wsu:Expires>

<wsse:Keys>

<xenc:EncryptedKey Id="...">...

</xenc:EncryptedKey>

<wsse:SecurityTokenReference>...

</wsse:SecurityTokenReference>

...

</wsse:Keys>

</wsse:SecurityContextToken>

61 61

61


Standards Update

WS-Trust & WS-SecureConversationSpecs & schemas submitted to OASIS, October 17th

2005

http://schemas.xmlsoap.org/ws/2005/02/trusthttp://schemas.xmlsoap.org/ws/2005/02/sc

Being worked on by the new WS-SX TC http://lists.oasis-open.org/archives/members/200510/msg00007.ht

ml

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx

62 62

62


WS-Federationhttp://ibm.com/developerworks

SecurityToken Service

SecurityToken(s)

ServiceRequester

SecurityToken(s)


SecurityToken(s)

ServiceProvider

Policy

TRUST

Requester’s organization

Provider’s organization

SecurityToken(s)

Œ

A federation is a collection of securityrealms (e.g. partner organizations)that have established trust to share security information about users belonging to the realms: identification, authentication attributes, authorization

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

63 63

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 distributersThere 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.

64 64

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-MetadataExchange defines a mechanism for exchanging policies, WSDL, and schemas for services within the federation

65 65

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

66 66

66



SecurityToken(s)

ServiceRequester

SecurityToken(s)


SecurityToken(s)

ServiceProvider

Policy

TRUST



SecurityToken(s)

A Simple Direct Trust Federation Scenario

Security tokens from Requester’s organization are used

Œ

Œ

to acquire security tokens from Provider’s organization

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.

67 67

67


Another Direct Trust Federation Scenario

Security tokens from Requester’s organization are

Œ

sent directly to provider’s service.

The service uses its Security Token Service to understand and validate the requester’s security token.

The validation response is sent as a security token which includes authentication and authorization data.


SecurityToken(s)

ServiceRequester

SecurityToken(s)


SecurityToken(s)

ServiceProvider

Policy

TRUST

Œ



SecurityToken(s)

68 68

68



Federation Scenario with Indirect Trust

SecurityToken(s)

ServiceRequester

SecurityToken(s)


SecurityToken(s)

ServiceProvider

Policy

There may not be a direct trust relationship between requester and provider organizations.

In that case, the two organizations may choose to use a trusted third party to establish and confirm trust for the transaction.

The provider asks the third party to verify the security token

The third party contacts the requester to verify the security token

Steps 1, 2, and 5 are as before.



SecurityToken(s)

Third-party Security Token Service

SecurityToken(s)

TR

US

T

Œ

Policy

TR

US

T

69 69

69



ServiceRequester


ServiceProvider

TRUST


Provider 2

Multi-party Federation

Œ


ServiceProvider

Provider 1

TRUST

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.

70 70

70



ServiceProvider


ServiceProvider

TRUST

Delegator’s organization

Provider 2

Delegation


ServiceRequester


TRUST

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.

Œ

71 71

71


Resources: WS-Federationhttp://ibm.com/developerworks/webservices

Federation of Identities in a Web services worldOverview of goals and technologies http://www-128.ibm.com/developerworks/webservices/library/ws-

fedworld/

Web Services Federation LanguageThe 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

72 72

72


WS-Security Implementation in WebSphere

Client

Handler

Request

Response

SOAP request header construction • Security token generation• Digital signature generation• Content encryption

RequesterApp

SOAP request header processing• Validate security tokens• Set up security context• Decrypt content• Digital signature validation

WebSphere App Server

Handler

Request

Response

ProviderApp

SOAP response header construction • Digital signature generation• Content encryption

SOAP response header processing• Decrypt content• Digital signature validation

DeploymentDescriptor


73 73

73


Deployment Descriptor for Security requirements

WS-Security requirements are specified as security constraints in the 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


74 74

74


Time for a break

END OF PART 1We’ll continue this thread of discussion in the “Part 2” session. I hope to see you all there.

IBM Software Group


Web Services Advanced TopicsBeyond SOAP, WSDL, and UDDI

Thanks for attending.

IBM Software Group



Kelvin R. LawrenceCTO, Emerging Internet Software [email protected]://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=730

Christopher FerrisSenior Technical Staff [email protected]://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

Revision: 3, October 27th 2005

Session 3562

77 77

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

Q & A

Part 1

Part 2

78 78

78


WS-Policy


specifications

UDDI

Web Services – A “Stack” View

Qualityof Service


Transport

BusinessProcesses





XML, XML Infoset

Transports

WS-Coordination

WS-Transactions



79 79

79


WS-Policy


specifications

UDDI

Technologies Discussed In This Session

Qualityof Service


Transport

BusinessProcesses





XML, XML Infoset

Transports

WS-Coordination

WS-Transactions



80 80

80


Web Services and Addressing

81 81

81


WS-Addressing

GoalsAllow 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-ReliableMessaging for example. Independent of transport or messaging system (ie app. level).Allow other specs to be built easily on top of this one.

StatusW3C Candidate Recommendation (August 17th 2005)Core spec

• http://www.w3.org/TR/ws-addr-core/SOAP Binding

• http://www.w3.org/TR/ws-addr-soap/

82 82

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, ReplyTo, FaultsTo SOAP header blocks Also defines message properties such as:MessageId

RelatesTo

Action

83 83

83


EPR -> SOAP mapping

<wsa:EndpointReference xmlns:wsa="..." xmlns:x="...">

<wsa:Address>

http://www.fabrikam123.example/acct

</wsa:Address>

<wsa:ReferenceParameters>

<x:CustomerKey>123456789</x:CustomerKey>

<x:ShoppingCart>ABCDEFG</x:ShoppingCart>

</wsa:ReferenceParameters>

</wsa:EndpointReference>

84 84

84


Yields...

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="..." xmlns:x="... "> <S:Header> ... <wsa:To>http://example.com/acct</wsa:To> <x:CustomerKey wsa:IsReferenceParameter='true'> 123456789 </x:CustomerKey> <x:ShoppingCart wsa:IsReferenceParameter='true'> ABCDEFG </x:ShoppingCart> ... </S:Header> <S:Body> ... </S:Body> </S:Envelope>

85 85

85


Addressing SOAP header blocks (aka MAPs)

<wsa:To>xs:anyURI</wsa:To> ? <wsa:From>wsa:EndpointReferenceType</wsa:From> ? <wsa:ReplyTo>wsa:EndpointReferenceType</wsa:ReplyTo> ? <wsa:FaultTo>wsa:EndpointReferenceType</wsa:FaultTo> ? <wsa:Action>xs:anyURI</wsa:Action> <wsa:MessageID>xs:anyURI</wsa:MessageID> ?

<wsa:RelatesTo RelationshipType="xs:anyURI"?>

xs:anyURI

</wsa:RelatesTo> * <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?

86 86

86


Status

WS-Addressing W3C Member Submission Aug 2004 http://www.w3.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.w3.org/TR/ws-addr-core•http://www.w3.org/TR/ws-addr-soap

Expect W3C REC early 2006

87 87

87


A Word About Faults

WS-Addressing defines a <FaultTo> 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.

88 88

88


Web Services and Reliable Messaging

89 89

89


WS-Policy


specifications

UDDI

Qualityof Service


Transport

BusinessProcesses





XML, XML Infoset

Transports

WS-Coordination

WS-Transactions




90 90

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 conversationMessages can be lost, duplicated, or arrive in a

different order than they were sentHost systems may fail and lose volatile state

Delivery Assurances supportedAt-Most-Once, At-Least-Once, Exactly-Once, OrderedWhen this is not possible, a fault is raised on the Initial

Sender, or the Ultimate Receiver, or both

91 91

91


WS-ReliableMessaging: Features

WS-RM (WS-ReliableMessaging) 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

92 92

92


RequesterApp

Source(e.g. sender’s

platform)

Destination(e.g. receiver’s

Platform)

The Reliable Messaging model

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

ProviderApp

Send

Transmit

Deliver

Acknowledge

93 93

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

94 94

94


Protocol Elements

<Sequence>Carries the Identifier and MessageNumber that uniquely

identifies the message within the Sequence context

<SequenceAcknowledgement>Carries the Identifier that uniquely identifies the Sequence

context

Carries AcknowledgementRange elements that cover the entire set of messages received by the RM Destination for the Sequence

<AckRequested>Requests that the RM Destination send a

SequenceAcknowledgement immediately

95 95

95


Sequence Lifecycle

<CreateSequence operation>A request to establish a new Sequence contextRM Destination creates a new Sequence context and assigns it a

unique Identifier and sends CreateSequenceResponse

<CloseSequence operation>RM Source informs RM Destination it is done with the

SequenceUsed for premature or normal termination

<TerminateSequence operation>RM Source sends this to RM Destination upon receipt of the

SequenceAcknowledgement 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

96 96

96


Example

A sequence is initiated using <CreateSequence>

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 <CreateSequence> (a unique sequence group id e.g. “http://fabrikam123.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://fabrikam123.com/abc</wsrm:Identifier> <wsrm:MessageNumber>3</wsrm:MessageNumber></wsrm:Sequence>

Christopher Ferris

The RM Destination creates the Sequence ID as part of the CreateSequence operation... the RM Source then uses the returned Sequence Identifier on all messages in the sequence.

97 97

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

<wsrm:Identifier>http://fabrikam123.com/abc</wsrm:Identifier> <wsrm:AcknowledgementRange Lower=“1" Upper=“1“/> <wsrm:AcknowledgementRange Lower=“3" Upper=“3“/>

<wsrm:SequenceAcknowledgement>

Notes: The <AcknowledgementRange> indicates a range of received

messages, from a lower number to an upper number More than one <AcknowledgementRange>s can be used when

there are gaps in the sequence of received message (as here)

98 98

98


Example (continued)

The Source:receives acknowledgement for messages 1 and 3decides 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 2Destination identifies and drops duplicate message

(sequence id and number were retained to detect duplicates).

99 99

99


WS-RM Protocol

Endpoint A Endpoint B

CreateSequence(AcksTo=EPRA)CreateSequenceResponse(Id=123)

Sequence(Id=123, MessageNumber=1)



CloseSequence(Id=123)

CloseSequenceResponse(Id=123), SeqAck(Id=123, AckRange=1,1, AckRange=3,3)

Sequence(Identifier=123, MessageNumber=2)

SeqAck(Id=123, AckRange=1,3)

TerminateSequence(Id=123)

TerminateSequenceResponse(Id=123)

100 100

100


Fault Management

<SequenceFault>, used with the SOAP fault mechanism, signals specific exceptions in reliable message processing

Some fault codes:wsrm:SequenceTerminatedwsrm:UnknownSequencewsrm:InvalidAcknowledgementwsrm:MessageNumberRollover (message number

overflows unsigned long)wsrm:LastMessageNumberExceeded (message number

is greater than number of previously received message that was marked “LastMessage”)

wsrm:SequenceRefused (can’t start requested sequence)

101 101

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:SequenceAcknowlegement> 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-SecureConversation.

102 102

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-ReliableMessaging-v1.0-wd-01.pdf

The TC hopes published its 3rd Committee Draft (Feb 2006)•Some changes to the protocol specified in the submission.•Namespace has changed since 2nd CD

103 103

103


Reliable Messaging - Further Reading

Spec as submitted to OASIS (input document) http://www.ibm.com/developerworks/webservices/library/specification/ws-rm/

WhitepapersReliable 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 2nd round of interop testing May 2004

104 104

104


Web Services and Transactions

105 105

105


WS-Policy


specifications

UDDI

Web Services Transactions

Qualityof Service


Transport

BusinessProcesses





XML, XML Infoset

Transports

WS-Coordination

WS-Transactions



106 106

106


Why Transactions ?

Data must be kept “consistent”

Jim knowsSum = A + B

A

B

Move some $

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).

Jim

107 107

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 2PC, open nested, compensation, long-running with

reconciliation, client-session scoping, ....• ACID = Atomicity (all or none) , consistency, isolation (lock), duability (long lasting)

108 108

108


Web Services Focus In Three Areas

WS-Coordination

WS-AtomicTransaction

WS-BusinessActivity

OASIS has formed the WS-TX Technical Committee (Dec 2005)

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx

109 109

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.

110 110

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 serviceHow to create a context

Registration serviceHow to register interest in a context

111 111

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).

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

112 112

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

113 113

113


Web Services Resources, Notification and Management

114 114

114


WS-Policy


specifications

UDDI

Management of Resources

Qualityof Service


Transport

BusinessProcesses





XML, XML Infoset

Transports

WS-Coordination

WS-Transactions



115 115

115


Motivation for Web Services Resource Framework

Stateful entities exist in most systemsData 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 contextEach 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 e-business computing

116 116

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 destructionMultiple independent instances may be created and

destroyed

Identity is assigned at creation time

117 117

117


WS-Resource

WS-Resource: Web service + associated resourceIn 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-ResourceWS-Resource Qualified Endpoint Reference

Implied Resource Pattern

118 118

118


Run-time environment

message

Inte

rface

WebService

message

address

Endpoint Reference

resource

Endpoint Reference

address

id

Creating/Locating a WS-Resource

119 119

119


Scope of WS-ResourceFramework

How to represent state in a Web services context

How is state referenced and “identified” in Web services

How is state modeled in XML and WSDL

How is state accessed through Web services

How to reason about lifetime of state

How to aggregate/collect stateful resources

How to reason about fault messages

120 120

120


Defines:How to use XML schema to model elements of

resource state How to associate resource’s state model with WSDL

portTypeStandard 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

WS-ResourceProperties

121 121

121


ResourceProperties Document and WSDL

ResourceProperties document is associated with the wsdl portType:<wsdl:portType name="Process"

wsrp:ResourceProperties="process:ProcessProperties">

<wsdl:operation name="findHostingOperatingSystem">

<wsdl:operation name="GetResourceProperty"> …

<wsdl:operation name="QueryResourceProperties"> …

<wsdl:operation name="Destroy"> …

</wsdl:portType>

@ResourceProperties provides metadata to assist developers and value-add tooling

122 122

122


WS-ResourceProperties Operations

GetResourceProperty

Simple single resource property element getterRequired<wsrp:GetResourceProperty> process:handle</wsrp:GetResourceProperty>

<wsrp:GetResourcePropertyResponse> <process:handle>1577 </process:handle></wsrp:GetResourceProperty>

<wsrp:GetResourceProperty> QName </wsrp:GetResourceProperty>

123 123

123


WS-ResourceProperties Operations

QueryResourcePropertiesExecute an expression against the resource properties

document

Optional

QueryExpression defines dialect by URI•XPath 1.0, 2.0•XQuery•SQL•StevesAmazingQueryExpression

<wsrp:QueryResourceProperties> <wsrp:QueryExpression dialect=”URI”> xsd:any </wsrp:QueryExpression> </wsrp:QueryResourceProperties>

124 124

124


WS-ResourceProperties

Set Resource PropertiesModify a resource property document

optional

<wsrp:SetResourceProperties> { <wsrp:Insert > xsd:any* </wsrp:Insert> |

<wsrp:Update > xsd:any * </wsrp:Update> |

<wsrp:Delete ResourceProperty=”QName” /> }+ </wsrp:SetResourceProperties>

125 125

125


Status of WS-ResourceFramework

Version 1.2 Committee SpecificationsJanuary 20, 2006

Submitted for consideration as OASIS Standard

126 126

126


WS-Notification

Family of documents and specifications

Brings enterprise quality publish and subscribe messaging to Web servicesLoosely coupled, asynchronous messaging in a Web

services context

WS Notification exploits WS Resource framework and other Web services technologies

127 127

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 TopicSpaces model in XML•Topic Expression Dialects

Brokered Notification•Mechanisms of Publish and the Broker role

128 128

128


Base Message Exchange Pattern

Subscriber NotificationProducer NotificationConsumer

Subscribe

wsa:EndpointReference

Notify

129 129

129


WS-Base Notification

Defines the Web services interfaces for NotificationProducers and NotificationConsumersIt includes standard message exchanges

along with operational requirements expected of them.

This is the base specification on which the other WS-Notification specification documents depend.

Direct, point to point, notification WS-Base Notification

Publish-Subscribe Notification for Web Services

130 130

130


WS-Notification

WS-NotificationBrings 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

131 131

131


WS-Notification Status

TC Chartered April 2004

TC published Committee Drafts for public review November 28, 2005WS-Base Notification v1.3 Public Review CD

WS-Brokered Notification v1.3 Public Review CD

WS-Topics v1.3 Public Review CD

132 132

132


Two Major Facets Of Web Services Management

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.

133 133

133


Management Using Web Services (MUWS)

134 134

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,,WebMethods … IT Resource Vendors – IBM (DataPower), HP, Dell, EMC, Fujitsu, Hitachi,

Cisco, Intel, Novell, Sun …

WSDM 1.0 approved March 2005Internal 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 2Q2006 Standardization Dependency on standardized versions of WS-Addressing, WS-RF, WS-

Notification

135 135

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

up-coming 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

136 136

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

137 137

137


Business Process Modeling and Execution

138 138

138


WS-Policy


specifications

UDDI


Qualityof Service


Transport

BusinessProcesses





XML, XML Infoset

Transports

WS-Coordination

WS-Transactions



139 139

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

Public Processes

Private Processes

140 140

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

141 141

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

Application

WSDL:HOW

C

E

BusinessProcess:

WHAT

A

D

B

142 142

142


The WS-BPEL Specificationhttp://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 processexpose resulting business process as a Web servicedefine control elements for workflowcreate a fully-executable, portable script

Technology proposal by IBM, BEA, and Microsoftversion 1.0 published in August 2002version 1.1 published in April 2003a merger of IBM’s WSFL and Microsoft’s XLangSubmitted to OASIS TC with royalty-free terms

Builds on and extends XML and Web Services specificationsexpressed in XMLuses and extends WSDLWSDL and XML Schema for data modelXPath for assignments, conditions, etc

143 143

143


Port type

1

2

3

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

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

A

CB

DE

Activities

Port type

Port type

Port type

RE

QU

ES

TE

R

144 144

144


BPEL and portability

A BPEL script will run on any BPEL-compliant engine, so it’s platform- and vendor-neutral

BPEL Execution

Environment

BPEL Modeling

Tool

BPEL Modeling

Tool

BPEL Modeling

Tool

BPEL Execution

Environment

BPEL Execution

Environment

BPEL Model

1

2

3

A

CB

DE

Create with your favorite BPEL Modeling Tool

Run on any BPEL-compliant platform

Port type

145 145

145


Handling an incoming request

Buyer

<process>

Port type

OtherActivities

<reply>

A

B

Seller’s Business Process

<partnerLinks>links

The <receive> activity 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

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.

<receive>

operation

A

B

U

146 146

146


Invoking a Web Service

Seller

<process>

Port type

<invoke>(synchronous) P

<invoke>(asynchronous)

Buyer’s Business Process

Seller’sBusiness

Processes

<partnerLinks>links

“callback”operation

Q

<receive>

<reply>

<receive>

<invoke>

A partner can invoke a service from another partner using SOAP and WSDL.

Two models:

Synchronous

<invoke> sends a message and the protocol waits for the response

Asynchronous<invoke> sends a message and the BPEL engine waits for a response on the “callback” operation

P

Q

Note: services that are invoked can be ordinary Web services or other business processes.

U

147 147

147


The <sequence> and <flow> activities

<sequence> activities run one at a time in the order they are listed

A

<sequence>

B

<flow> activities run concurrently the flow activity does not

complete until all its activities complete (synchronization)

flow branches are often <sequence>s

A B

<flow>

148 148

148


Combining flows and sequences

<flow>s and <sequence>s can nest to any required depth a <sequence> can

contain <flow>s

a <flow> can contain <sequence>s

activities link other Business Processes or Web services

Port type

<process>

<sequence>

<flow>

<receive>

<reply>

149 149

149


Cross-dependencies

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 Both W and X must

complete before Y can run. If either is not completed, Y waits until both are completed.

Port type

<process>

<sequence>

<flow>

X

Y

W

150 150

150


BPEL Data Model

Variables* represent <process> context 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

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.

output

input

<variable>

message

activity

<process>

Port type

Port type

* Variables were called “containers” in BPEL 1.0

151 151

151


Process Instances and Correlation

Manage interaction between stateful service instancesInstance identification via selected “token” in messages exchanged between services

<correlationSet> identifies tokens

Used by activities to address appropriate service instances

Global or scoped definition

orderNocustomerID

<correlationSet>

init

use

activities

Tokens chosen for

<correlations>

<process>Port type

Port type

For more info: http://www-106.ibm.com/developerworks/webservices/library/ws-bpelcol6/

152 152

152


Other BPEL Features

These can be defined (or redefined) within a <scope>:

Fault handlingEvent handlingCompensationVariablesCorrelation setsConcurrency

Compensation handlingdefine flow for undoing

previously completed activities

Fault handlingdefine steps for handling a

fault thrown by any activity

<wait>for intervaluntil specified time

<switch>Like C++/Java switch except

condition for each case

<if>, <then>, <else>, <elseif>Works as you would expect.

<pick>Combination of <receive>

and switch

Handle one of a list of expected incoming messages

Event handling

153 153

153


Executable and Abstract Processes

A

B C

D

Property 1 Property n...

Property = 42

A

B C

V

Q R

T

D

U

S Variable n

Variable 1

Hide Complexity

Executable processesComplete business

process details

Can be run on all compliant environments

Abstract processesspecify constraints of

message exchange

describe business protocol

simplified model for use in business partner integration

154 154

154


BPEL and Standardization

An OASIS TC is now working to standardize BPEL 2.0http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=

wsbpel

Latest Committee Draft (1st September 2005)http://www.oasis-open.org/committees/download.php/14616/wsbpel-specifica

tion-draft.htm

BPEL 1.1 Specification – published April, 2003http://ibm.com/developerworks/library/ws-bpel

Submitted as input to the OASIS work.

155 155

155


Changes in BPEL 2.0 (from 1.1)

Major differences between 1.1 and 2.0:Added if-then-else, repeatUntil, validate, forEach

•Completion condition in forEach activity

Added extensionActivity 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 messageExchange for correlating receive and reply activities.

156 156

156


BPEL4Peoplehttp://www.ibm.com/developerworks/webservices/library/specification/ws-bpel4people/

WS-BPEL Extension for People – BPEL4People

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

157 157

157


BPEL Extensions for Sub-Processeshttp://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.

158 158

158


Resources – BPEL whitepapers and specs

Visit http://ibm.com/developerworks/webservices

BPEL4WS 1.1 Specification

Paper: “Automating business processes and transactions in Web services: An introduction to BPELWS, WS-Coordination, and WS-Transaction”

Paper: “Business processes in a Web services world: A Quick Overview of BPEL4WS”

A series of papers: “Understanding BPEL4WS” (explains the new alphaWorks BPEL editor and runtime)

Search for “BPEL4WS” and “BPEL” for full list.

159 159

159


Time for a break!

END OF PART 2Thanks for sticking with us, I hope this was useful.

IBM Software Group



Thanks for attending.