web services chapter 28. web basics 3 internet collection of physically interconnected computers....

Web Services

Chapter 28

Web Basics

3

Internet

• Collection of physically interconnected computers.

• Messages decomposed into packets.

• Packets transmitted from source to destination using a store-and-forward technique.

• Routing algorithm directs packets to destination

4

Connection-Oriented Protocol

• Prior to transmission: connection is established between source and destination. Each maintains state information:

– Sequence numbers, acknowledgements provide reliability

• guarantee that packet loss or duplication will be detected

• packets arrive in the order they were sent

– Buffers, flow control algorithm guarantee transmission rate appropriate to both sender and receiver

– Destination address

– Characteristics of connection (e.g., out-of-band messages)

• Transmission Control Protocol (TCP) is connection-oriented.

• Problem: Overhead of setting up & taking down connection.

5

Hypertext Transfer Protocol (HTTP)

• A high level protocol built on top of a TCP connection for exchanging messages (with arbitrary content)

– Each (request) message from client to server is followed by a (response) message from server to client.

– Facilitates remote invocation of methods on the server.

• Web: A set of client and server processes on the Internet that communicate via HTTP.

6

Protocol Stack

HTTP

TCP

Link LevelProtocol

Protocol for tranmitting packets between neighboring nodes

Network LevelProtocol End-to-end protocol

Added features to supportclient interactions (reliabilityflow control, ..)

7

Clients and Servers

• Client: browser capable of displaying HTML pages.

• Web Server: stores pages for distribution to clients.

• Pages identified by Uniform Resource Locator (URL).

– <protocol>: protocol to be used to communicate with host.

• Example - http, ftp

– <host_name>: Directory server translates this into the host’s internet address

• Example – www.cs.sunysb.edu becomes 155.233.123.532

– <file_name>: name of file on host.

<protocol>://<host_name>/<file_name>

9

Request Methods

• GET: response body contains data identified by argument URL

• HEAD: response header describes data identified by argument URL (no response body)

– Use: has page changed since last fetched?

• PUT: request body contains page to be stored at argument URL

10

Request Methods

• DELETE: delete data at argument URL

• POST: request body contains a new object to be placed subordinate to object at argument URL

– Use: adding file to directory named by URL

– Use: information entered by user on displayed form

• Others ….

11

HTTP Request Format

<header> = <field_name> : <value> CrLf

<field_name> = From | -- sender’s e-mail addressAccept | -- acceptable response formatsUser-Agent | -- identifies requestor’s programSOAPAction -- identifies SOAP processor to receive

message (if data is a SOAP message)

If-Modified-Since | -- send document only if modified

since <value> (used with GET)Content-Type | -- type of data (application/soap+xml

for SOAP)Host | -- destination host…

<data> = ASCII text (default)

12

Simple Client / Server Interaction I

1. User supplies URL (clicks on link)

http://yourbusiness.com/~items/printers.html

2. Browser translates <host_name> (yourbusiness.com) to host_internet_address (using name server)

3. Browser assumes a port number of 80 for http (if no port is explicitly provided as part of <host_name> )

Program at port 80 interprets http headers

13

Simple Client / Server Interaction I

4. Browser sets up TCP connection to yourbusiness.com at

(host internet address, 80)

5. Browser sends http message

GET ~items/printers.html HTTP/1.0

over connection

14

HTTP Response

Status line: <HTTP_version> <status_code> <reason_line> CrLf

Followed by: < header >*

Followed by: <data>

15

HTTP Response

<status_code> = 3 digits

Ex: 2xx -- success

4xx -- bad request from client

5xx -- server failed to fulfill valid request

<reason_line> = explanation for human reader

<header> = <field_name> : <value> CrLf

<field_name> = Allowed | -- methods supported by URL

Date | -- creation date for response

Expires | -- expiration date for data

Last-Modified | -- creation date for object

Content-Length | Content-Type | ….

16

Simple Client/Server Interaction I

6. Server sends response message with requested html page to browser

7. Server releases TCP connection (stateless)8. Browser receives page and displays it

HTTP/1.0 200 Document followsDate: <date>Content-Type: text/htmlContent-Length: integerExpires: date

html document ~items/printers.html goes here

17

Simple Client/Server Interaction II

1. Page displayed by browser is a form with tag

<FORM ACTION=“http://yourbusiness.com/servlets/placeorder”

METHOD=…>

2. Client fills input boxes

3. If METHOD=GET, client sets up connection to yourbusiness.com and sends http request:

Values in input boxes encoded as suffix. Since ACTION

designates a servlet, server invokes placeorder

GET /servlets/placeorder?name1=value1&name2=value2 HTTP/1.0

18

Simple Client / Server Interaction II

4. If METHOD=POST, client sends http request invoking POST to yourbusiness.com; data contains values in input boxes.

POST /servlets/placeorder HTTP/1.0Content-Type: text/……………….Content-Length: 54321

Printer=HP660&Name=Art+Bernstein

19

HyperText Transfer Protocol (HTTP 1.1)

1. Client sets up TCP connection to server named in URL

2. Client sends a request

3. Client receives a response

4. If (server has not disconnected) goto 2 else goto 1

- Only actively used connections are maintained

SOAP

Version 1.2

21

What is SOAP?

• The de facto standard for Web Service communication that provides support for:– Remote procedure call (RPC) to invoke methods on

servers

– Messaging to exchange documents

– Extensibility

– Error handling

– Flexible data encoding

– Binding to a variety of transports (e.g., SOAP, SMTP)

• We will discuss Version 1.2

22

HTTP Binding

• A SOAP message must be carried by some transport protocol– HTTP is frequently used for this purpose

– Message is the data part of a request invoking POST

POST /fareService/getFareOp HTTP/1.1Host: www.SlowHawk.comContent-Type: application/soap+xmlContent-Length: xxxSOAPAction: yyy

<!– the SOAP message goes here

23

SOAP and XML

• Since XML is language and platform independent, it is the lingua franca for the exchange of information in a heterogeneous distributed system.

• SOAP supports the transmission of arbitrary XML documents

• For RPC, SOAP provides a message format for invoking a procedure and returning results in XML

24

SOAP Message

Message Body

Header Block

Header Block

SOAP Body

SOAP Header

SOAP Envelope

required

optional

25

SOAP Envelope<s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope”> <s:Header>  </s:Header>

<s:Body>  </s:Body></s:Envelope>

http://www.w3.org/2003/05/soap-envelope identifies a name space that defines the structure of a SOAP message

26

Using SOAP

• For document exchange, the XML document being exchanged is nested directly in SOAP envelope.– Referred to as document-style SOAP– Conversational mode of message exchange

• For RPC, SOAP defines the format of the body of messages to be used for invocation and response.– Referred to as RPC-style SOAP– Uses a request-response pattern– Parameters are passed by value/result

27

RPC Request Message

<s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>

<s:Body><n:getQuoteOp xmlns:n=“http://www.shearson.com/quoteService”>

<n:symbol xsi:type=“xsd:string”>IBM

</n:symbol></n:getQuoteOp>

</s:Body></s:Envelope>

Client invocation of procedure:public Float getQuoteOp(String symbol);

generates SOAP request message:

28

RPC Response Message


<s:Body><n:getQuoteOpResponse xmlns:n=“http://www.shearson.com/quoteService”>

<n:value xsi:type=“xsd:float”>30.45

</n:value></n:getQuoteOpResponse>


29

RPC Request/Response Messages

• Conventions:– Name of the request structure is same as method name.

– Name of response structure is same as method name concatenated with “Response”

– Name and order of in and in/out parameters in request structure same as name and order in signature

– Value of method (if returned) is first child element of response structure; out and in/out parameters follow, their name and order same as name and order in signature

30

Data Encoding• Problem: SOAP provides a language/platform

independent mechanism for invoking remote procedures– Argument values are carried in an XML document

– Caller and callee may use different representations of the same types (e.g., Java, C)

– A mechanism is needed for mapping from caller’s format to XML syntax and from XML syntax to callee’s format (referred to as serialization/deserialization)

• Example: mapping a Java array to XML syntax

31

Serialization

• Serialization is simple for simple types (integer, string, float,…) since they correspond to XML Schema types.– Translate from binary to ASCII using XML

schema specified format

• Serialization not so simple for complex types– Ex: What tags will be used for an array? Will it be

stored by rows or by columns? How will a sparse array be sent?

32

Encoding Style

• encodingStyle attribute used to identify the serialization rules to encode the data contents of an element– An arbitrary set of rules can be used– SOAP defines its own set of rules– Message is referred to as RPC/encoded

• RPC refers to the format of the message as a whole

• Encoded refers to the fact that argument values have been represented using the rule set specified in the encoding style attribute

33

SOAP Encoding Style

• SOAP defines its own graphical data model for describing complex types and rules for transforming instances of the model into serialized ASCII strings– Vendors provide serializers (and deserializers)

which maps each local type to an instance of the model and then transforms the local representation to the encoded data using the SOAP rules

34

Data Encoding


<s:Body><n:getQuoteOp xmlns:n=“http://www.shearson.com/quoteService” s:encodingStyle=“http://www.w3.org/2003/05/soap-encoding”>

<n:symbol xsi:type=“xsd:string”>IBM

</n:symbol></n:getQuoteOp>


35

SOAP Extensibility

• A SOAP message goes from client to server to advance some application related cause.

• It is often the case that some orthogonal issues related to the message must be handled:– Security: encryption, authentication, authorization– Transaction management– Tracing– Logging

36

Intermediaries

• To support scalability and decentralization, these issues need not be handled by the server.– Intermediaries between client and server are used

• Intermediaries perform orthogonal services as the message passes along a route

intermediary intermediaryclient server

37

Example

clientProxy/

gateway

purchasingserver

accountingserver

inventoryserverMessage addressed to Proxy.

Contains target dept (purchasing), client name, password, and request body.

Proxy performs authentication.

Message addressed to target dept.Contains authenticated Id and

request body.Target department services the request.

38

Requirements

• Information directed to each intermediary and to final destination kept separate– Intermediaries can be easily added/deleted, route

changed

• SOAP does not specify how routing is to be done– It is up to each node along the chain to know

where to send the message next• Information carried in the message may direct routing

39

Header

• SOAP envelope defines an optional header containing an arbitrary number of header blocks. Each block:– Has an optional role and should be processed

by an intermediary that can perform that role– Can have its own namespace declaration

• Eliminates the possibility of interference between groups that independently design headers.

40

Example – Message Sent by ClientPOST /purchasing/retailSale HTTP/1.1 -- method invoked at final destinationHost: proxy.yourcompany.com -- initial destination intermediary …….<s:Envelope xmlns:s=….> <s:Header>

<td:targetdept xmlns:td=“….” s:role=“company-proxy.com” -- identifies intermediary s:mustUnderstand=“true”> -- this header better be processed

purchasing -- identifies next node</td:targetdept><auth:authinfo=“….” s:role=“company-proxy.com” -- identifies intermediary s:mustUnderstand=“true” > -- this header better be processed

<auth:name> madonna </auth:name><auth:passwd> xxxxxx </auth:passwd>

</auth:authinfo> </Header> <s:Body> …… </s:Body></s:Envelope>

41

Processing Model• An intermediary has an assigned set of roles• On receiving a message, it identifies the blocks

whose role attribute matches an element of its set (or has value next)– A block without a role attribute is targeted for final

destination

• The intermediary – can modify/delete its block – can insert new blocks– should retarget the message to the next destination– can do anything (frowned upon)

42

Must Understand

• An intermediary can choose to ignore a block directed to it

• If mustUnderstand attribute has value “true” intermediary must process the block or else abort the message and return a fault message

43

Example – Message Sent by Proxy

POST /purchasing/retailSale HTTP/1.1 -- method invoked at destinationHost: purchasing.yourcompany.com -- initial intermediary …….<s:Envelope xmlns:s=….> <s:Header>

<cc:ClientCredentials xmlns:cc=“….” s:mustUnderstand=“true” > -- this block better be processed by

-- destination (no role specified)<cc:clientId> 122334 </cc:clientId>

</ cc:ClientCredentials > </Header> <s:Body> …… </s:Body> -- same body</s:Envelope>

44

Example – Message Sent by Proxy

• Proxy has deleted the two headers– Verified that user is valid using <name> and

<passwd> and determined Id– Retargeted message to final destination using

<targetdept>

• Proxy has inserted a new header containing Id– Final destination uses Id to determine

authorization

45

WS-Addressing

• Problem: As described up to this point destination address (including target SOAP processor) is not included in SOAP message– This information is contained in transport header

(e.g., SOAPAction header in HTTP)– Information has to be supplied separately to the

transport and the mechanism for doing this is different for different transports

• SOAP is not transport-neutral

46

WS-Addressing

• Solution: Include the information in SOAP header blocks.

• WS-Addressing is defined for this purpose:– <wsa:To> - destination URL– <wsa:Action> - message intent (analogous to

SOAPAction)– <wsa:MessageID> - unique Id– <wsa:ReplyTo> - address for reply – <wsa:RelatesTo> - Id of another message– ….

47

WS-Addressing

• The type EndpointReferenceType is defined to carry references to endpoints (e.g., value of ReplyTo)– Contains destination address as well as

additional information that might be needed to send a message to that address:

• Identity of WSDL elements describing destination (port type, service,..)

• Policy information (e.g., should message be encrypted)

48

SOAP Faults• SOAP provides a message format for communicating

information about errors containing the following information:

– Fault category identifies error (not meant for human consumption) –

• VersionMismatch

• MustUnderstand – related to headers

• Sender – problem with message content

• Receiver – error had nothing to do with the message

– human readable explanation

– node at which error occurred (related to intermediaries)

– application specific information about Client error

49

Embedding SOAP in HTTP: POST

• For document-style SOAP, the envelope is the body of an HTTP POST.– The HTTP response message simply acknowledges

receipt of HTTP request messsage

• For RPC-style SOAP, the envelope containing the SOAP request is the body of an HTTP POST; the envelope containing the SOAP response (or fault) is the body of the corresponding HTTP response.

50

Embedding RPC-style SOAP in HTTP

POST /StockQuote HTTP/1.1Content-Type: text/xmlContent-Length: …..

<s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <s:Body>

<n:getQuoteOp xmlns:n=“http://www.shearson.com/quoteService” s:encodingStyle=“http://www.w3.org/2001/06/soap-encoding”>

<n:stockSymbol xsi:type=“xsd:string”>IBM

</n:stockSymbol></n:getQuoteOp>


51

Embedding Soap in HTTP: GET

• In some situations the client simply wants to retrieve an XML document– An HTTP GET request message is sent with no

data (no SOAP content)– Document (actually a SOAP envelope) is

returned as the data in the HTTP response

Web Services Description Language (WSDL)

Version 1.1

53

Goals of WSDL

• Describes the formats and protocols of a Web Service in a standard way– The operations the service supports – The message(s) needed to invoke the operations– The binding of the messages to a communication

protocol– The address to which messages should be sent

54

WSDL Description

• A Web Service is described at both the abstract and concrete levels

• Abstract Level (corresponds to portType Description Language)

– What are the operations that are supported?– What messages are needed to invoke the operations?

• Concrete Level– How are the messages bound to a transport protocol?– What is the Web address to which the messages should

be sent?

55

WSDL Abstract Level

• At the abstract level, obtaining a service is like executing a method of an object

• WSDL defines the following elements– An portType is like an object; it consists of a set of

operations

– An operation is like a method; it is invoked by messages

– A message is composed of parts

– A part is like a parameter and has an associated type

56

Example <portType name = “GetQuotePT”>

<operation name = “getQuoteOp”>

<input message = “gs:getQuoteOpReq”/>

<output message = “gs:getQuoteOpResp”/>

<fault name = “invalidSymbolFault”

message = “gs:invalidSymbolFaultMsg”/>

</operation>



</portType>

gs is the target namespace of the document containingthis declaration and the message declarations

57

Patterns• The messages exchanged when an operation is

invoked conform to a pattern• WSDL 1.1 has defined two patterns:

– Request/response• Input sent by requestor, output produced by service• Requestor might wait for response (e.g., RPC) or

might not– Choice is a function of how operation is used and would

be specified at a higher level

– One-way• Input sent by requestor, no response expected

58

Faults

• Request/response pattern allows a fault message to replace the output message if server detects a fault

• One-way pattern does not allow fault message

<output message = “gs:getQuoteOpResp”/><fault name = “invalidSymbolFault” message = “gs:invalidSymbolFaultMsg”/>

59

Example – Message Definitions<message name = “getQuoteOpReq”> <part name = “stockSymbol” type = “xsd:string”/></message>

<message name = “getQuoteOpResp”> <part name = “stockSymbol” type = “xsd:string”/> <part name = “QuoteValue” type = “xsd:float”/></message>

<message name = “invalidSymbolFaultMsg”> <part name = “faultInfo” type = “gs:faultType”/></message>

60

Parts of a Message

• A message can have many parts– Each part can be bound to a different position

within the physical message sent by the transport

• With SOAP parts can be distributed over body and header blocks

• Each part can have a simple or complex type defined in an XML schema

61

Example

<schema>

<complexType name = “faultType”>

<sequence>

<element name = “faultCode” type = “string”/>

<element name = “faultDetail” type = “string”

minOccurs = “0” maxOccurs = “1”/>

</sequence>

</complexType>

</schema>

62

Concrete Level• The concrete level defines how portTypes and

operations are bound to transports and addresses• A given portType can be bound to several different

transports and addresses– A Web Service might support a portType using several

different transports• For example, the operations can be invoked using SOAP over

either HTTP or SMTP

– The same portType might be supported by several different Web Services using the same or different transports

– In all of these cases, semantically identical service should be provided at each address

63

Concrete Level

• At the concrete level, WSDL defines the following elements– A binding describes how the messages of a

portType are mapped to the messages of a particular transport

– An port maps a binding to a Web address– A service is a collection of ports that host

related portTypes

64

Example – Service and port

<service name = “GetQuoteService”>

<port name = “GetQuoteRPC” binding=“gq:GetQuoteSOAPBinding”>

<soap:address location = “http://www.shearson.com/quoteservice”/>

</port>

<!—Other ports go here -->

</service>

identifiesbinding

65

WSDL Extensibility

• A binding maps a portType to a particular transport– It must be capable of targeting a variety of transports

– Each transport has its own idiosynchrosies

• WSDL is extended by introducing a different namespace for each transport

<definitions xmlns=“http://schemas.xmlsoap.org/wsdl/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/ targetNamespace=http://www.shearson.com/quoteservice> </definitions>

introduce SOAP

namespace

66

Example – RPC/encoded SOAP Binding

<binding name = “GetQuoteSOAPBinding” type = “tns:GetQuotePT”>

<soap:binding style = “rpc”

transport = “ http://schemas.xmlsoap.org/soap/http/”/>

<operation name = “getQuoteOp”>

<input>

<soap:body

use = “encoded”

namespace =“ http://www.shearson.com/quoteservice”

encodingStyle =“ http://schemas.xmlsoap.org/soap/encoding”/>

</input>

Continued on next slide

identifiesportType

SOAPextensions

rpc stylemsg

encodeparameters

encodingrules

for tags used inmesssage

67

Binding Example - Continued

<output>

<soap:body

use = “encoded”

namespace =“ http://www.shearson.com/quoteservice”

encodingStyle =“ http://schemas.xmlsoap.org/soap/encoding/”/>

</output>

</operation>



</binding>

68

RPC/encoded Message


<s:Body><n:getQuoteOp xmlns:n=“http://www.shearson.com/quoteService”>

<n:stockSymbol xsi:type=“xsd:string”>IBM

</n:stockSymbol></n:getQuoteOp>


69

Encoding

• Problem: Serializer serializes arguments (parts) in accordance with rules specified by encodingStyle attribute– Receiver can deserialize arguments since style is

specified in the message

• But message has a declared type– How can we be sure that the rules produce an instance of

the type?

– In fact they might not!

70

Example – Encoding Style

• Suppose there are n arguments of the same type.– Serializer might produce a message containing

n instances of the type.

• But suppose in a particular invocation all arguments have same value.– Serializer might produce a message containing

n pointers to a single instance of the value.– Then the value of each argument (a pointer) is

not an instance of the type!

71

Encoded Vs. Literal

• If use=“encoded”, arguments are encoded in accordance with the specified encoding style

• If use=“literal”, arguments are instances of part types specified in the message declaration

• Yields two distinct styles for invoking a remote procedure:– rpc/encoded– rpc/literal

72

Example – RPC/literal SOAP Binding

<binding name = “GetQuoteSOAPBinding” type = “tns:GetQuotePT”> <soap:binding style = “rpc” transport = “ http://schemas.xmlsoap.org/soap/http/”/> <operation name = “getQuoteOp”> <input> <soap:body use = “literal” namespace =“http://www.shearson.com/quoteservice”/> </input> <output> …. </output> </operation></binding>

identifiesportType

rpc stylemsg

don’t encodeparameters

73

RPC/literal SOAP Binding<types> <schema> <complexType name=“comptyp”> … </complexType> <schema></types>

<message name=“msg”> <part name=“part1” type=“comptyp” /></message>

<soap:Envelope> <soap:Body> <n:myProc xmlns:n=“…”> <n:part1> …instance of comptyp… </n:part1> </n:myProc> </soap:Body></soap:Envelope>

74

RPC/encoded and RPC/literal

• RPC style specified for both bindings – There is no schema describing the (entire)

message body• Child of body element uses name of procedure

• Each grandchild corresponds to a parameter and uses parameter name

• Might be a grandchild for result returned

– Hence, validation is not possible

75

Sending Documents

• Increasingly, Web communication is– Asynchronous

• Web Services are loosely coupled (as opposed to tightly coupled, object-oriented systems that are developed in a more integrated fashion and are more oriented towards rpc)

• More appropriate for delay prone/failure prone environments

– Messages contain XML documents (instead of procedure arguments)

– A wide variety of communication patterns (as opposed to simply request/response) are useful

76

Example - Document Style Messaging

<message name = “sendInvoiceMsg”> <part name = “invoice” type = “inv:invoiceType/></message>

<portType name = “invoicePT”> <operation name = “sendInvoiceOp”> <input message = “inv:sendInvoiceMsg”/> </operation></portType>

one-waypattern

77

Example (con’t)

<binding name = “sendInvBinding” type = “ing:invoicePT> <soap:binding style = “document” transport = “http://schemas.xmlsoap.org/soap/http”/> <operation name = “inv:sendInvoiceOp”> <input> <soap:body use = “literal” namespace = “http://www.invoicesource.com/invoice”/> </input> </operation></binding>

SOAP bodycontains XML

documents

body is aninstance ofpart type

78

Document/literal SOAP Binding

<types> <schema> <complexType name=“comptyp”> … </complexType> <schema></types>

<message name=“msg”> <part name=“part1” type=“n:comptyp” /></message>

<soap:Envelope> <soap:Body>

…instance of comptyp… </soap:Body></soap:Envelope>

Alternative 1 – one part specified by a type

message can have only onepart in this case since theschema of the body can haveonly one type specification

n is targetnamespace ofthis document

79

Document/literal SOAP Binding

<types> <schema> <element name=“elem” type=“n:comptyp” /> <complexType name=“comptyp”> … </complexType> <schema></types>

<message name=“msg”> <part name=“part1” element=“n:elem” /></message>

<soap:Envelope> <soap:Body> <n:elem xmlns=“ …target ns of WSDL doc… “> …instance of comptyp… </n:elem> </soap:Body></soap:Envelope>

Alternative 2 – part specified by an element

Part is identified as anelement. An instance ofelement is a child of body, named with element’s name, typed with element’s type

80

Sending Multiple Documents<element name=“firstInvoice” type=“inv:invoiceType” /><element name=“secondInvoice” type=“inv:invoiceType” /><complexType name=“invoiceType”> </complexType>

<message name = “sendInvoiceMsg”> <part name = “invoice1” element = “inv:firstInvoice” /> <part name = “invoice2” element = “inv:secondInvoice” /></message>

element specification must be usedsince message has multiple parts

<soap:Body> <inv:firstInvoice>  </inv:firstInvoice> <inv:secondInvoice>  </inv:secondInvoice></soap:Body>

81

Sending Messages By Email: Simple Mail Transfer Prototol

<service name = “GetQuoteSMTPService”> <port name = GetQuoteSMTP” binding=“gq:GetQuoteSMTPBinding”/> <soap:address location = “mailto:[email protected]”/> </port></service>

82

Mail Example (continued)<binding name = “GetQuoteSMTPBinding” type = “tns:GetQuotePT”> <soap:binding style = “document” transport=“http://schemas.xmlsoap.org/soap/smtp ”/> <operation name = “getQuoteOp”> <input> <soap:body use=“literal”/> </input> <output> <soap:body use=“literal”/> </output> </operation></binding>

83

Complete WSDL Document<definitions targetNamespace=“….” xmlns=“ …” other namespaces > <types> <!– specification of XML Schema types used in this document --> </types> <messsage> … </messsage> <!– specification of other messages goes here--> <portType> … </portType> <!– specification of other portTypes goes here--> <binding> … </binding> <!– specification of other bindings goes here--> <service> <port> … </port> <!– specification of other ports goes here--> </service> </definitions>

84

What WSDL Cannot Do

• WSDL describes how each operation can be invoked– E.g., getQuoteOp

• Many services require a sequence of operations– Send this message, receive that message, if this happens

send this other message to another port, etc– The sequence cannot be described in WSDL

• BPEL describes the logic of a Web Service– How it is impemented– How it communicates with other busienss processes– Sometimes called an orchestration language

Business Process Execution Language for Web Services

(BPEL4WS)

Version 1.1

86

BPEL vs. WSDL

• WSDL supports a stateless model which describes operations supported by web servers– One or two messages needed for client/server

communication

– No mechanism for describing state between operations

• A business process (BP) typically characterized by long-running, statefull sequence of operations with one or more web services (business partners).

87

Simple Example: Ordering Stationery

cobegin invoke Staples.StationeryQuote(staples-quote); invoke Office-Max.StationeryQuote Service(max-quote);coend; if staples-quote < max-quote {invoke Staples.StationeryPurchase} else {invoke Office-Max.StationeryPurchase}

state

88

New Issues

• A language for business processes:– Must be able to communicate with other Web Services

– Must be able to access and modify data received in messages

• Use XPath to extract information from messages

– Must have control constructs• sequence, switch (if), flow (concurrency), while, link

(synchronize concurrent processes), invoke, etc

– Must be able to handle faults

89

Example (BPEL)

<sequence> <flow> <invoke partnerLink=“Staples” portType=“staplesPurchasePt” operation=“requestQuote” inputVariable=“stationeryReq” outputVariable=“staplesStationeryQuote”> </invoke> <invoke partnerLink=“OfficeMax” portType=“officeMQuotePT” operation=“requestQuote” inputVariable=“stationeryReq” outputvariable=“officeMStationeryQuote”> </invoke> </flow> ….. Continued on next slide …..

90

Example (BPEL) <switch>

<case condition=“bpws:getVariableProperty(staplesStationeryQuote, quote) < bpws:getVariableProperty(officeMStationeryQuote, quote)” /> <invoke partnerLink=“Staples” portType=“staplesQuotePt” operation=“purchStationery” inputVariable=“stationeryPurch” outputVariable=“stationeryResp”> </invoke> </case <otherwise> <invoke partnerLink=“Office Max” portType=“officeMQuotePT” operation=“purchStationery” inputVariable=“stationeryPurch” outputVariable=“stationeryResp”> </invoke> </otherwise> </switch></sequence>

91

Business Process (BP)

• A BP consists of both internal computations and invocations of operations exported by Web service partners

• The operations it exports constitute its interface to its partners

• The sequence of invocations it executes is referred to as a protocol and – is data dependent– responds to exceptional conditions

92

Abstract Vs. Executable BPs

• Executable BP – complete description of BP (including all computations)

• Abstract BP – contains only externally visible (communication related) behavior of BP– Not executable– Intention: Internal decision making algorithm and data

manipulation not described (although this is not enforced)

• Languages for describing abstract and executable BPs share a common core, but differ primarily in data handling capabilities

• BPEL4WS is used to specify both abstract and executable BPs

93

Executable BPs

• BPEL is sufficient for describing a complete (executable) BP that– Relies on Web services and XML data– Is portable (platform independent)

• Executable BP is a complete specification of the Web service– Actual implementation, however, might not use BPEL,

• Abstract BP specifies external interface and can be exported for use by business partners

94

Abstract BP

• Unfolding of protocol related portion of BP – depends on properties - a subset of the data contained in

messages

– Ex. Message invoking getQuoteRequest might have parts instrumentType (with value stock or bond) and symbol (which identifies a particular instrument of that type)

• instrumentType will be a property if it affects the course of the protocol

• symbol will not if it does not affect the course of the protocol

• Only properties are visible to abstract BP

95

Abstract Vs Executable BP• Internal computation of executable BP not included in

abstract BP– If assignment is to a variable that is not a property, it is

eliminated from abstract process• Ex. Address data might not affect the protocol

– If assignment is to a variable that is a property, it (generally) affects the protocol

• Ex. Value of bidPrice might affect protocol: – if (bidPrice>1000) invoke webService1 else invoke webService2– bidPrice will be a property, but its value is computed by an

internal algorithm

• The computation that produces the new value is generally not relevant to the protocol

96

Abstract BP – Non-determinism

• Description of abstract BP allows assignment of non-deterministic values to properties to model this

• Abstract and executable BPs differ in data handling ability– Executable can explicitly manipulate all data– Abstract can access only properties and can

assign non-deterministic values to them– Executable cannot assign non-deterministic

values to anything

97

Abstract BP – Non-determinism

computation that assigns a value

to part x

non-deterministicassignment

to property x(alias of x)

switch(x) switch(x )

Executable BP Abstract BP

98

Communication – Client Side

• Invoking an operation of a portType (specified in WSDL) exported by server– Client assigns message to operation’s input

variable– Client executes invoke on operation

• Asynchronous (one-way WSDL pattern): – Client resumes execution immediately

• Synchronous (request/response WSDL pattern):– Client waits for response and then resumes execution

» Synchronization imposed by BPEL– Client can access response message in operation’s output

variable

99


• Receiving an invocation of an operation exported by client– Client executes receive on operation

– Client waits for message

– Client can access message in variable associated with operation and resume execution

– Ex: an asynchronous response to a prior invocation on a callback portType

100


client server

invoke

invoke

invoke

receive

• • •

• •

• •

•

• •

• •

• •

• •

• server exportsportType

client exports (callback) operation

(synchronous invoke)

(asynchronous invoke)

clientwaits

clientcontinues

problem: how doyou associaterequest withresponse?

• • •



101

Communication – Server Side

• Accepting an operation invocation on an (exported) portType (specified in WSDL)– Server executes receive on operation and waits

• Responding to a synchronous operation invocation– Server executes reply on operation (rpc)

• Invoking a client’s exported (callback) operation– Server executes invoke on operation

102

Communication – Server Side

client server

invoke• •

• • •

• •

• •

• •

• •

• server exportsportType

client exports (callback) portType

(synchronous invoke)


receive

reply

receive

receive

invoke

invoke

receive invoke(asynchronous invoke)


103

Example: Purchase Order (PO) Service

initiateprice

calculation

completeprice

calculation

arrangelogistics

invoiceprocessing,

reply

decide on shipper

completeproductionscheduling

receivepurchase

order

initiateproduction scheduling

concurrencysequencing

synchronization

104

PO Service

customer

receive

reply

Body of PO Service

Body of PO Service

POMsg

InvMsg

operationsendPurchOron portTypepurchOrPT

synchronous invocation

PO Service

105

PO Service Interface (WSDL)

<message name=“POMsg”> <part name=“custInfo” type=“sns:custInfo”/> <part name=“purchOr” type=“sns:purchOr”/></message><message name=“InvMsg”> <part name=“IVC” type=“sns:Invoice”/></message>…..<portType name=“purchOrPT”> <operation name=“sendPurchOr> <input message=“pos:POMsg/> -- arguments supplied <ouput message=“pos:InvMsg”/> -- response </operation></portType>…..

portType exportedby PO Service

<definitions targetNamespace=“….” xmlns=“http://schemas.smlsoap.org/wsdl/” …>

</definitions>

prefix for targetnamespace in this document

106

Variables (BPEL)

• Variables maintain the state of a BP– Used to store messages that have been sent or received or

for local storage (no message involved)– Has an associated type:

• Can be a message type

• Can be an XML simple type• Can be an XML schema element (which might have a complex

type)

– Has an associated scope

<variable name=“PO” messageType=“lns:POMsg”/>

lns is prefix in BPEL document for the WSDL document

107

Partner Link Type (WSDL)

<plnk:partnerLinkType name=“purchLT”> <plnk:role name=“purchService”> <plnk:portType name=“pos:purchOrPT”/> </plnk:role></plnk:partnerLinkType>

• <partnerLinkType> describes the way two BPs interact: - names a portType that must be declared in each - associates <role> with each end of the interaction

Only one role (in this case) since only

POService needs to provide an portType

partnerLinkTypeis a unit of

collaboration

Not a process (allows actual partner to be

specified dynamically)

WSDL extension for BPEL

108

Partner Link Type (WSDL)<plnk:partnerLinkType name=“invoicingLT”> <plnk:role name=“invoiceService”> <plnk:portType name=“pos:computePricePT”/> </plnk:role> <plnk:role name=“invoiceRequester”> <plnk:portType name=“pos:invoiceCallbackPT”/></plnk:partnerLinkType>

BP playing roleof invoicerequester

BP playing roleof invoice service

invoiceCallbackPT computePricePT

description of apossible relationship between two BPs

109

Partner Link (BPEL)

<partnerLinks> <partnerLink name=“purchLink” partnerLinkType=“lns:purchLT” myRole=“purchService”/> </partnerLinks>

hence PO service must provide purchOrPT

• Connection to another BP described by a partner link • <partnerLink> construct in BPEL names a process and associates it with a role in that link.

prefix lns refers to WSDL document

name of partnerLink

partner specification in

PO service

110

Partner (BPEL)

• A BP might interact with another BP – called a partner - through several partnerLinks– Need a mechanism that asserts that the same BP is at

the other end of a set of partnerLinks– Ex: BPs might support getFarePT and

purchaseTicketPT; an acceptable partner is one that supports both<partners> <partner name=“ticketVendor”> <partnerLink name=“xxxx”/>  <partnerLink name=“yyyy”/>  </partner></partners>

111

Process Name

• Each BP is assigned a name in the <process> tag

<process name=“customer” … namespace declarations … … query language (default XPath) … … expression language (default XPath)… > … declarations and process body …</process>

<process name=“purchOrProcess” … similarly … > … declarations and body of PO service …</process>

112

Linkage: Customerto PO Service

<plnk:partnerLinkType name=“purchLT> <plnk:role name=“purchService”> <plnk:portType name=“pos:purchOrPT”/> </plnk:role></plnk:partnerLinkType>

<partnerLink name=“linkToPurch” partnerLinkType=“cns:purchLT” partnerRole=“purchService”/>

<partnerLink name=“purchLink” partnerLinkType=“lns:purchLT” myRole=“purchService”/>

WSDL inter-face exportedby PO Service

partner specificationin customer process

partnerspecificationin PO Service

plnk – prefix in WSDL doc refers to WSDL extensionpos – target ns of WSDL doclns – prefix in PO Service refers to WSDL doccns – prefix in customer refers to WSDL doc

113

Partners

<partnerLinks> <partnerLink name=“invoiceProvider” partnerLinkType=“lns:invoiceLT” myRole=“invoiceRequester” partnerRole=“invoiceServices”/></partnerLinks>

• In general: - A partnerLinktype is not specific to a particular BP; it is a global, bilateral (WSDL) description of the interaction between two BPs. - A partnerLink declaration (BPEL) describes how the local BP interacts with other BPs through a partnerLinktype.

114

PO Service (BPEL)<variables> <variable name=“PO” messageType=“lns:POMsg”/> <variable name=“Invoice” messageType=“lns:InvMsg”/></variables>

<sequence> <receive partnerLink=“purchLink” portType=“lns:purchOrPT” operation=“sendPurchOr” variable=“PO”/> </receive>

<flow> …. concurrent body…. </flow>

<reply partnerLink=“purchLink” portType=“lns:purchOrPT” operation=“sendPurchOr” variable=“Invoice”/></sequence>

Both necessary since PO Service might communicate with several BPs through the same portType

115

Interaction with Shipping Provider

decide onshipper(invoke)

arrangelogisitics(receive)

Shippingservice

shipReqMsg

shipInfoMsg

operation requestShippingon portType shippingPT

operation sendSchedule onport shippingCallbackPT role = shippingService

role = shippingRequester

scheduleMsg

PO service

116

Handling Shipping (WSDL)

<portType name=“shippingCallbackPT”> <operation name=“sendSchedule”> <input message=“…”/> </operation></portType>

<portType name=“shippingPT”> <operation name=“requestShipping”> <input message=“…”/> <output message=“…”/> </operation></portType>

portType exportedby PO Service

portType exportedby shippingservice

117

Handling Shipping

<plnk:partnerLinkType name=“shippingLT”> <plnk:role name=“shippingService”> <plnk:portType name=“pos:shippingPT”/> </plnk:role> <plnk:role name=“shippingRequester”> <plnk:portType name=“pos:shippingCallBackPT/> </plnk:role></plnk:partnerLinkType>

<partnerLink name=“shippingProvider” partnerLinkType=“lns:shippingLT” myRole=“shippingRequester” partnerRole=“shippingService”/>

WSDL

BPEL (PO service)

118

Handling Shipping (BPEL)

<sequence> <assign> <copy> <from variable=“PO” part=“custInfo” /> <to variable=“shippingReq” part=“custInfo” /> </copy> </assign> <invoke partnerLink=“shippingProvider” portType=“lns:shippingPT” operation=“requestShipping” inputVariable=“shippingReq” outputVariable=“shippingInfo” > </invoke> <receive partnerLink=“shippingProvider” portType=“lns:shippingCallbackPT” operation=“sendSchedule” variable=“shippingSchedule”/> </sequence>

contains input

message

119

Links (BPEL)– Synchronizing Concurrent Activities w/i a BP

• Production scheduling cannot be completed until logistics have been arranged

decide onshipper

arrangelogistics


initiateproductionscheduling

source target

link

Concurrent sequence activities in flow

• data produced byarrange logistics isneeded by completeproduction scheduling• data communicatedthrough globally sharedvariable

120

Links<flow> <links> <link name=“ship-sched”/> </links> <sequence> <assign> …. </assign> <invoke partnerLink= ….> </invoke> <receive partnerLink= …. variable=“shippingSched”> <source linkName=“ship-sched”/> </receive> </sequence> <sequence> <invoke partnerLink=….> </invoke> <invoke partnerLink=…. inputVariable=“shippingSched”> <target linkName=“ship-sched”/> </invoke> </sequence> ….</flow>

shipping

scheduling

arrangelogistics


decide on shipper

concurrent

121

Properties (WSDL)

• Some message data is protocol-relevant.– Used in conditional behavior of BP– Used to relate messages sent to a particular instance of a BP

• A property declares a global name that can be assigned to data items that may be parts of several different message types and carry the same meaning– taxpayerID might be a part of one message type in one

namespace (e.g., Internal Revenue), ssn might be a part of another in a different namespace (e.g., Social Sec. Admin)

– Both might represent the same information of type txtyp:SSN

<bpws:property name=“customerID” type=“txtyp:SSN’/>

122

Property Alias (WSDL)• Used to associate a property name with a field in

message part– A particular property can be associated with different

fields in different messages

<bpws:property name=“customerID” type=“txtyp:SSN’/><bpws:propertyAlias propertyName=“customerID” messageType=“txmsg:taxpayerInfo” part=“taxpayerID” query=“/socialSecNum” /></bpws:propertyAlias>

query string – specified in XPath - to locate the field in

the part

123

Correlation Sets (BPEL)

• A web service might be configured with multiple instances of a BP to concurrently handle (stateful) conversations with multiple clients.– All receive requests over the same port

• With SOAP over HTTP, messages arrive on port 80

• A mechanism is needed to:– Route an arriving message that is part of a particular

conversation to the correct BP instance• Messages of a particular conversation can be recognized by the

fact that they will generally all carry some identifying value(s) (e.g., customerID and orderNum)

124

Correlation Sets

• A correlation set is a set of properties whose value is shared by all messages in a particular conversation.– Hence, an address is really:

(host address, port, correlation set)– A correlation set identifies the BP instance

<correlationSet name=“PurchaseOrder” properties=“cor:customerID cor:orderNum”/>

aliased to items of information contained in the messages of aconversation

125

Using Correlation Sets

• A particular receive operation can be used in a BP to accept the start of a new conversation

• All subsequently arriving messages with same value of PurchaseOrder will be directed to this BP

<receive partnerLink =“Buyer” portType=“SP:PurchasingPT” operation=“asynchPurchase” variable=“PO”> <correlations> <correlation set=“PurchaseOrder” initiate=“yes”/> </correlations></receive>

create a new correlation set value for BP instance

asynchronouspurchase request

126

Using Correlation Sets• Response returns the correlation set value

– Asynchronous (callback) response to previous invocation

– A reply to a synchronous invocation would be similar

<invoke partnerLink “Buyer” portType=“SP:BuyerPT” operation=“asynchPurchaseResp” variable=“PO”> <correlations> <correlation set=“PurchaseOrder” initiate=“no”/> </correlations></invoke>

use the set toaddress the message

127

Multiple Correlation Sets

buyer serverinvoke(corrSet=“PO” init=“yes”) receive(corrSet=“PO” init=“yes”)

receive(corrSet=“PO” init=“no” invoke(corrSet=“PO” init=“no” corrSet=“inv” init=“yes”) corrSet=“inv” init=“yes”)

subsequent messages sent and received use correlation set inv

messsagecontains bothcorrelation sets

messages of asingle conversation

128

Multiple Correlation Sets

• With synchronous invocation, two messages are involved; the pattern attribute associates a correlation set with a message.

invoke (partnerLink=“Buyer” portType=“SP:BuyerPT” operation=“synchPurchaseResp” inputVariable=“PO” outputVariable=“invoice”> <correlations> <correlation set=“PurchaseOrder” initiate=“yes” pattern=“out”/> (initiated in outbound msg) <correlation set=“InvoiceResp” initiate=“yes” pattern=“in”/> (initiated in inbound msg, which contains both sets) </correlations></invoke>

129

Data Manipulation• Data (state) stored in variables (used for messages and local storage)• Expressions use expression language (XPath default) to access data

in variables– Executable processes can use:

– All processes can use:

– Returns the part (or, if the locationPath is specified the field within the part) in the named variable.

• If a single node is not specified, a fault is returned.

bpws:getVariableData (‘variableName’, ‘partName’, ‘locationPath’?)

bpws:getVariableProperty(‘variableName’, ‘propertyName’)

query string

property alias contains query string

130

Assignment• Allows copying of data • One form (for executable processes):

– query is an absolute expression (if XPath is the query language) that identifies a single node w/i the document fragment specified by part

– from child can also contain a literal value or a simple arithmetic expression (for data transformation)

<assign> <copy> <from variable=“v1” part=“p1” query=“q1”/> <to variable=“v2” part=“p2” query=“q2”/> </copy></assign>

131

Assignment in Abstract Process

• A non-deterministic value from a property’s domain can be assigned to the property by an abstract process using opaque assignment– Allows simulation of execution traces

<assign> <copy> <from opaque=“yes”/> <to variable=“v2” property=“p2”/> </copy></assign>

132

Invoking Web Service Operations

• invoke might have child elements related to faults and compensation (discussed subsequently), and links and correlation (discussed previously)

• invoke specifies a partnerLink, since a portType can be associated with several partnerLinkTypes connected to different BPs

<invoke partnerLink=“shippingProvider” portType=“lns:shippingPT” operation=“requestShipping” inputVariable=“shippingRequest” outputVariable=“shippingInfo”></invoke>

133

Invoking Web Service Operations• invoke can be

– Synchronous• input and output variables specified• waits for a response• fault message can be specified

– Asynchronous • no output variable specified• no waiting• fault message not allowed

<invoke partnerLink=“invoiceProvider” portType=“lns:computePricePT” operation=“initiatePriceCalc” inputVariable=“PO”></invoke>

134

Synchronous Vs. Asynchronous Invocation

• Web service communication characterized by:– Services are not always available.– Loads tend to be unpredictable.

• Attempts to handle too many requests in real time can lead to thrashing and failure.

– Many requests can’t be handled instantly even with low loads.

• Hence, asynchronous invocation will play an increasingly important role.

135

Providing Web Service Operations

• receive waits for an invocation to arrive

– specifies a partnerLink, since a portType can be associated with several partnerLinkTypes connected to different BPs

<receive partnerLink=“customer” portType=“lns:purchOrPT” operation=“sendPurchOr” variable=“POmsg”/> </receive>

136

Providing Web Service Operations• Initiating a new instance of a BP:

– createInstance=“yes” => a new instance of the BP is created and this is its initial activity.

• The receive should be the first activity in the BP (since prior activities will not be executed within the new instance)

• If the message is the start of a conversation then a correlation child element should be specified:

<receive partnerLink=“customer” portType=“lns:purchOrPT” operation=“sendPurchOr” variable=“POmsg” createInstance=“yes”> </receive>

<correlation set=“PurchaseOrder” initiation=“yes”/>

137

Providing Web Service Operations

• reply is used to respond to a synchronous invocation.– connection between receive and reply based on

constraint that not more than one synchronous request from a particular (partnerLink, portType, operation) can be outstanding at a time

• Response to an asynchronous invocation is made using an invoke on a callback operation– partnerLink between requestor and requestee must have

two roles

<reply partnerLink=“customer” portType=“lns:purchOrPT” operation=“sendPurchOr” variable=“Invoice”/>

138

Other Basic Activities

• <terminate>

• <wait until=“deadline”>

or

<wait for=“duration”>

• <empty>

139

Structured Activities

• <sequence>  </sequence>• <switch> <case condition=“bool-expr”>

 </case> <otherwise>  </otherwise> </switch>

at least one case element; conditionsevaluated in order

if present, executedif all conditionsfail, else an emptyotherwise is assumed

Involves only properties if

process is abstract

140


• <while condition=“bool-exp”>  </while>• <pick> -- waits for the occurrence of first event <onMessage partnerLink=“..” portType=“..” operation=“..” variable=“..”>  </onMessage> <onAlarm for=“durationExp” | until=“deadlineExp”>  </onAlarm> </pick>

at least one,acts likereceive

zero or more

141


• <flow> concurrently executes nested (child) activities

• Terminates when all children terminate

<sequence> <flow> <invoke partnerLink=… /> <invoke partnerLink=… /> </flow> <invoke partnerLink=…/> </sequence>

executedconcurrently

142

WSDL Review

• WHAT: portType describes abstract functionality (operations, messages)

• HOW: binding describes how elements of a portType (operations, messages) are mapped to a particular transport protocol (e.g., SOAP over HTTP)

• WHERE: port maps a binding to an address (particular server at a URL)– service is a collection of related ports

143

Endpoint References

• A BP is statically dependent on the portTypes with which it communicates

• However, the endpoint associated with a portType (and hence the identity of the BP instance with which it communicates) can change dynamically– Endpoints can be sent in messages

• Hence, a BP can dynamically bind to another BP

– Example: client can send a callback portType to which server can send response

144

Endpoint References

• A message part can have type EndpointReferenceType (as defined in WS-Addressing)

• Each role in a partnerLink has an associated EndpointReference

• An EndPointReference received in a message can be assigned to a partner link to dynamically establish a connection

145

WS-Addressing Specification for Endpoint Reference

<wsa:EndpointReference …namespace declarations… > <wsa:Address> … a URI … </wsa:Address> -- required <wsa:ReferenceProperties> … properties (child elements) are inserted here … </wsa:ReferenceProperties> <wsa:portType> …</wsa:portType> <wsa:ServiceName> … </wsa:ServiceName> <wsa:Policy> … </wsa:Policy></wsa:EndpointReference>

• wsa identifies WSDL extension namespace for endpoint references• Information to identify a particular instance of a BP can also be supplied

146

Endpoint Reference

• Properties: – Opaque to all but the service that created the endpoint (i.e., the

service that will receive messages sent to the endpoint)• A service sending a message to the endpoint blindly and literally copies

properties into header blocks in the message• Similar to a cookie

– Examples:• TransactionId• Customer identification• Context handle that identifies customer to creator

• portType: identifies the associated portType• ServiceName: identifies the associated service

147

Endpoint Reference Example<message name=“buyerData”> …. <part name=“serviceReference” type=“wsa:EndpointReferenceType”/> <part …. /></message>

<portType name=“buyerPT”> <operation name=“submit”> <input message=“tns:buyerData”/> </operation></portType>

<portType name=“buyerCallbackPT”> <operation name=“answer” …. </portType>

<plnk:partnerLinkType name=“buyerStoreLT”> <plnk:role name=“store”> <plnk:portType name=“tns:buyerPT”/> </plnk:role> <plnk:role name=“buyer”/> <plnk:portType name=“buyerCallbackPT”/> </plnk:role></plnk:partnerLinkType>

148

Endpoint Reference Example<partnerLink name=“buyer” partnerLinkType=“as:buyerStoreLT” myRole=“store” partnerRole=“buyer”/><variable name=“buyerData” messageType=“as:buyerData”/>……<sequence> <receive name=“acceptFromBuyer” partnerLink=“buyer” portType=“as:buyerPT” operation=“submit” variable=“buyerData”/> ….. <assign> <copy> <from variable=“buyerData” part=“serviceReference”/> <to partnerLink=“buyer”/> </copy> </assign> <invoke name=“respondToBuyer” partnerLink=“buyer” portType=“as:buyerCallbackPT” operation=“answer” inputVariable=“…” /></sequence>

149

Endpoint Reference

• Since the partnerLink, portType and operation are (statically) specified in the invoke statement, the exchange of an endpointReference allows a BP to dynamically bind to a BP that supports that operation and portType (not to any BP)

150

Assignment and Endpoint References

• Sending an address: from child of copy can have form

– A BP might want to send its own address (e.g., for a callback) or its partner’s address

• Receiving an address: to child must be associated with partnerRole (can’t change your own address)

<from partnerLink=“ … ” endpointReference=“myRole|partnerRole ”/>

<to partnerLink=“ … ” />

151

Links – Synchronizing Flow Activities<flow>

<links> <link name=“XtoY” /> <link name=“CtoD”/> </links> <sequence name=“X”> <source linkName=“XtoY”/> <invoke name=“A”…/> … </sequence> <sequence name=“Y”> <target linkName=“XtoY”/> <receive name=“C”…> <source linkName=“CtoD”/> </receive> … </sequence> <invoke name=“D”…> <target linkName=“CtoD”/> </invoke></flow>

- any activity can have a source or target child element- every link must have exactly one activity w/i the flow as its source and one as its target- sequence Y can’t start until sequence X completes- source and target need not be nested at same level (CtoD)- link must not cross a while boundary- links must not create a loop

152

Link Semantics at the Source

• Each source child of an activity has an implicit or explicit transitionCondition attribute whose value is:

- Implicit: true when activity terminates

- Explicit: the value of the transitionCondition expression when the activity terminates

<source linkName=“AtoB”

transitionCondition=“getVariableProperty(‘eval’, ‘risk’) = ‘low’ ”/>

- The transitionCondition determines the link status (positive or negative) when the activity terminates

variable nameproperty name

153

Link Semantics at the Target• Without considering links, an activity is ready to execute in

accordance with normal flow-of-control rules (sequence, switch, etc.)• In addition, an activity might be the target of several links.

- Every such activity has a joinCondition which can be evaluated when the status of all incoming links has been determined. Execution starts when the activity is ready and its joinCondition is true. • Default joinCondition: status of at least one incoming link is true

<sequence name=“X” > <target linkName=“AtoX”/> <target linkName=“BtoX”/> …….</sequence>

154

Link Semantics at the Target

• joinCondition can be explicitly provided as an attribute using getLinkStatus() function.

<sequence name=“X” joinCondition=“bpws:getLinkStatus(AtoX) AND bpws:getLinkStatus(BtoX)”> <target linkName=“AtoX”/> <target linkName=“BtoX”/> …….</sequence>

must specify an incominglink for activity X

X starts when control point reaches sequence and status of both incoming links is true

155

Link Semantics at the Target

• If the joinCondition evaluates to false a joinFailure fault is thrown, else the activity is started

• If an activity, X, will not be executed (e.g. a case in a switch, an activity that does not complete due to a fault) then the status of all outgoing links from X is set to negative.

156

Link Semantics

<flow> <link name=“AtoC”/> <link name=“BtoC”/><sequence><switch> <sequence name=“C”> <case condition=“C1”> <target name=“AtoC”/> <sequence name=“A”> <target name=“BtoC”/> <source linkName=“AtoC”/> ……… …. </sequence> </case> <case condition=“C2”> <sequence name=“B”> <source linkName=“BtoC”/> …. </sequence> </case></switch>……. </flow>

- only one case is executed- joinCondition at C cannot be evaluated until status of both links are determined- if C1 is chosen for execution the status of BtoC is set to negative (if that were not done C would never start)- default joinCondition at C is true when either C1 or C2 completes - since their (default) transitionCondition is “true”

157

Link Semantics

• Problem – in some cases a false joinCondition is not a fault; it is an indication that the activity should not be performed in at a particular point in the execution– In that case the status of all outgoing links should

be set to false so that the joinCondition of other activities can be evaluated

• Solution – use activity attribute suppressJoinFailure

158

Link Semantics

• If value of the suppressJoinFailure attribute of an activity, A, is yes, then if the joinCondition of A or any nested activity has value false when it is ready to execute – status of all of it’s outgoing links is set to negative– it is skipped and execution continues (as if it had

terminated without raising a fault)– referred to as dead-path-elimination

159

Link Semantics <flow suppressJoinFailure=“yes”>

<link name=“AtoC”/><sequence><switch> <sequence name=“C”> <case condition=“C1”> <target name=“AtoC”/> <sequence name=“A”> ……… <source linkName=“AtoC”/> …. </sequence> </case> <case condition=“C2”> <sequence name=“B”> …. </sequence> </case></switch>……. </flow>

- C is executed if C1 is chosen- if C1 is not chosen the status of AtoC is set to negative and a joinFailure would occur- suppressing joinFailure allows C to be silently skipped

160

Scope

• Nested scoping is provided through the scope activity in the conventional way.

• Variables, fault and compensation handlers, and correlation sets can be declared.

• Properties are global since they are mapped to data in messages.

161

Faults

• Fault has a unique name and an (optional) fault variable describing the event

• Sources of faults:– Explicit raising of a fault <throw faultName=“trouble” faultVariable=“descr”/>

– Standard BPEL faults bpws:joinFailure - joinCondition has value false bpws:conflictingReceive – two receive’s for same

partnerLink, portType and operation pending within a flow at the same time

162

Faults• Source of faults (con’t):

– Fault response to an invoke. The reply:

raises the fault unableToHandleRequest in BP

that has synchronously invoked request on portType:

<reply partnerLink=“customer” portType=“lns:loanServicePT” operation=“request” variable=“error” faultName=“unableToHandleRequest”/>

<portType name=“loanServicePT”> <operation name=“request”> <input message=“lns:creditInfoMsg”/> <output message=“lns:approvalMsg”/> <fault name=“unableToHandleRequest” message=“errorMsg”/> </operation></portType>

163

Faults

The reply raises the unableToHandleRequest fault in BP linked through customer. Fault is handled there by:

<faultHandlers> <catch faultName=“unableToHandleRequest” faultVariable=“error”> …. handle the fault …. </catch></faultHandlers>

Re-throw the same fault and/or clean-up and/or invoke a compensationhandler

164

Handlers• Handler is associated with an implicit or explicit

scope; catches faults that occur in that scope

<invoke partnerLink=“loanApprovProc” portType=“lns:loanservicePT” operation=“request” ….. > <catch faultName=“unable…” faultVariable=“error”> …. handle the fault…. </catch></invoke>

<scope> <faultHandlers> <catch faultName=“unableTo…” faultVariable=“error”> …. handle the fault … </catch> …other handlers … </faultHandlers> …activities … <invoke partnerLink=“loanApprovProc” portType=“lns:loanservicePT” operation=“request” … > </invoke> …activities…</scope>

or

implicit scope

165

Fault Flow of Control• When a fault f occurs in some scope, B

– Execution of activities within are terminated

– If a fault handler for f or a catchAll handler has been declared local to B, it is executed and execution resumes in the next enclosing scope at the activity following B

– Else f is thrown in the next enclosing scope

– In both cases B is said to have exited abnormally

• The handler might reverse changes it has made to variables global to B and invoke compensation handlers for scopes nested in B that have completed normally.

166

Fault Flow of ControlA

B catch f throw g or exit

throw f

either way, B isexited abnormally

or

167

Atomicity• A BP is a long running process involving

invocations of operations at a number of web services, S1, S2, …Sn.

• It is unrealistic to treat a BP as a single transaction, since a particular service Si will not hold locks for the duration of the BP

• Instead, an invocation at Si might be treated as a transaction that commits when it executes reply– BPEL does not support global atomicity (e.g., two-

phase commit) over multiple invocations by a BP

168

Long-Running Business Transactions (LRT)

• Reversing the effect of a BP relies on compensation– a web service might offer a compensating operation

for a synchronous operation– Ex. CancelPurchase compensates for Purchase

• BPEL supports an LRT by providing compensation handlers – Allows application to specify a recovery strategy

using compensating operations– No guarantee of atomicity or isolation

169

Compensation Handler• Handler can be in the scope of invoke or declared local to

scope containing invoke– Undoes the effect of the scoped activities

<invoke name=“invSeller” partnerLink=“seller” portType=“SP:Purch” operation=“syncPurch” inputVariable=“sendPO” outputVariable=“getResponse”> <correlations> <correlation set=“PurchOr” initiate=“yes” pattern=“out”/> </correlations> -- pattern=“out” indicates set applies to request msg <compensationHandler> <invoke partnerLink=“seller” portType=“SP:Purch” operation=“cancelPurch” inputVariable=“getResponse” outputVariable=“getConfirm”> <correlations> <correlation set=“PurchOr” pattern=“out”/> </correlations> </invoke> </compensationHandler></invoke>

-- invSeller isname of scope

170

Invoking Compensation

• Compensation can only be performed for a scope (e.g., invoke, scope) that has completed normally– A compensation handler is not “installed” until the

associated scope has completed normally.• Hence handler must be invoked from outside the scope

– Compensation occurs when a failure is detected• Hence handler is invoked from a global fault or another

compensation handler

171

Invoking Compensation

• At most one compensation handler can be explicitly declared local to a scope (in contrast to fault handlers)

• Scope has a name; handler is invoked using <compensate name=“scopeName”/>

• Handler is installed when scope is exited normally (at that point compensation is meaningful)

172

Handler InvocationA

B

C

throw f

catch f compensate B

compensate Ccompensate D

fault handlerfor f

compensationhandler for B

compensationhandler for C

Although B, C andD may have exitednormally, A willexit abnormallyin this case

D compensationhandler for D

173

Compensation<scope> <faultHandlers> <catch faultName=“unableTo…” faultVariable=“error”> <compensate scope=“invBank”/> </catch> </faultHandlers> <sequence> <invoke name=“invBank” partnerLink=“myBank” portType=“bankPT” operation=“Op” ….> <compensationHandler> <invoke partnerLink=“myBank” portType=“bankPT” operation=“cancelOP” …..> </invoke> </compensationHandler> </invoke> <invoke partnerLink=“loanApprovProc” portType=“lns:loanservicePT” operation=“request” ….. > </invoke> …………

fault

compensate

normalexit

fault returned; abnormal exit

174

Default Handlers

• Problem: Suppose a fault handler is not declared

• Compensation handler for C cannot be called from within A

• Solution: default fault handlers automatically invoke declared compensation handlers of immediately enclosed scopes and then rethrow the fault

A

B

C

default handlerfor f

throw f


175

Default Handlers

• Problem: Suppose a compensation handler is not declared

• Compensation handler for C cannot be called from within A

• Solution: default compensation handler automatically invokes declared compensation handlers of immediately enclosed scopes

A

B

C

defaultcompensation handler

throw f


fault handlerfor f

catch f compensate B

176

Structure of a BP

<process name=“…” abstractProcess=“yes|no” … />

<partnerLinks> … </partnerLinks> <variables> … </variables> <correlationSets> … </correlationSets> <faultHandlers> … </faultHandlers> <compensationHandlers> … </compensationHandlers> activity</process>