web-basics1 - Stony Brook University

Transcript web-basics1 - Stony Brook University

Web Services
Chapter 28
Web Basics
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
3
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.
4
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.
5
Protocol Stack
HTTP
TCP
Network Level
Protocol
Link Level
Protocol
Added features to support
client interactions (reliability
flow control, ..)
End-to-end protocol
Protocol for tranmitting packets
between neighboring nodes
6
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>://<host_name>/<file_name>
– <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.
7
HTTP Request Format
Start line:
<method> <URL> <protocol_version> CrLf
Followed by: <header>*
there can
Followed by: CrLf
be several
Followed by: <data>
header lines
<method> = GET | HEAD | POST | PUT | ….
<protocol_version> = HTTP/1.1 | ….
8
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
9
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 ….
10
HTTP Request Format
<header> = <field_name> : <value> CrLf
<field_name> =
From |
-- sender’s e-mail address
Accept |
-- acceptable response formats
User-Agent |
-- identifies requestor’s program
SOAPAction
-- identifies SOAP processor to receive
message (if data is a SOAP message)
If-Modified-Since |
Content-Type |
Host |
…
<data> = ASCII text (default)
-- send document only if modified
since <value> (used with GET)
-- type of data (application/soap+xml
for SOAP)
-- destination host
11
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
12
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
13
HTTP Response
Status line: <HTTP_version> <status_code> <reason_line> CrLf
Followed by: < header >*
Followed by: <data>
14
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 | ….
15
Simple Client/Server Interaction I
6. Server sends response message with requested html
page to browser
HTTP/1.0 200 Document follows
Date: <date>
Content-Type: text/html
Content-Length: integer
Expires: date
html document ~items/printers.html goes here
7. Server releases TCP connection (stateless)
8. Browser receives page and displays it
16
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:
GET /servlets/placeorder?name1=value1&name2=value2 HTTP/1.0
Values in input boxes encoded as suffix. Since ACTION
designates a servlet, server invokes placeorder
17
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.0
Content-Type: text/……………….
Content-Length: 54321
Printer=HP660&Name=Art+Bernstein
18
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
19
SOAP
Version 1.2
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
21
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.1
Host: www.SlowHawk.com
Content-Type: application/soap+xml
Content-Length: xxx
SOAPAction: yyy
<!– the SOAP message goes here 
22
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
23
SOAP Message
SOAP Envelope
SOAP Header
Header Block
optional
Header Block
SOAP Body
Message Body
required
24
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
25
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
26
RPC Request Message
Client invocation of procedure:
public Float getQuoteOp(String symbol);
generates SOAP 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>
27
RPC Response 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:getQuoteOpResponse
xmlns:n=“http://www.shearson.com/quoteService”>
<n:value xsi:type=“xsd:float”>
30.45
</n:value>
</n:getQuoteOpResponse>
</s:Body>
</s:Envelope>
28
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
29
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
30
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?
31
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
32
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
33
Data Encoding
<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/2003/05/soap-encoding”>
<n:symbol xsi:type=“xsd:string”>
IBM
</n:symbol>
</n:getQuoteOp>
</s:Body>
</s:Envelope>
34
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
35
Intermediaries
client
intermediary
intermediary
server
• 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
36
Example
purchasing
server
client
Proxy/
gateway
Message addressed to Proxy.
Contains target dept (purchasing),
client name, password,
and request body.
Proxy performs authentication.
accounting
server
inventory
server
Message addressed to target dept.
Contains authenticated Id and
request body.
Target department services the request.
37
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
38
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.
39
Example – Message Sent by Client
POST /purchasing/retailSale HTTP/1.1
-- method invoked at final destination
Host: 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>
40
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)
41
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
42
Example – Message Sent by Proxy
POST /purchasing/retailSale HTTP/1.1
-- method invoked at destination
Host: 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>
43
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
44
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
45
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
– ….
46
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)
47
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
48
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.
49
Embedding RPC-style SOAP in HTTP
POST /StockQuote HTTP/1.1
Content-Type: text/xml
Content-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>
</s:Body>
</s:Envelope>
50
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
51
Web Services Description
Language (WSDL)
Version 1.1
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
53
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?
54
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
55
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 containing
this declaration and the message declarations
56
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
57
Faults
<output message = “gs:getQuoteOpResp”/>
<fault name = “invalidSymbolFault”
message = “gs:invalidSymbolFaultMsg”/>
• 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
58
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>
59
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
60
Example
<schema>
<complexType name = “faultType”>
<sequence>
<element name = “faultCode” type = “string”/>
<element name = “faultDetail” type = “string”
minOccurs = “0” maxOccurs = “1”/>
</sequence>
</complexType>
</schema>
61
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
62
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
63
Example – Service and port
identifies
binding
<service name = “GetQuoteService”>
<port name = “GetQuoteRPC”
binding=“gq:GetQuoteSOAPBinding”>
<soap:address location = “http://www.shearson.com/quoteservice”/>
</port>
<!—Other ports go here -->
</service>
64
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
introduce
SOAP
namespace
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>
65
Example – RPC/encoded SOAP
Binding
identifies
portType
<binding name = “GetQuoteSOAPBinding” type = “tns:GetQuotePT”>
<soap:binding style = “rpc”
rpc style
transport = “ http://schemas.xmlsoap.org/soap/http/”/>
msg
<operation name = “getQuoteOp”>
<input>
for tags
SOAP
used in
<soap:body
extensions
messsage
encode
use = “encoded”
parameters
namespace =“ http://www.shearson.com/quoteservice”
encodingStyle =“ http://schemas.xmlsoap.org/soap/encoding”/>
</input>
Continued on next slide
encoding
rules
66
Binding Example - Continued
<output>
<soap:body
use = “encoded”
namespace =“ http://www.shearson.com/quoteservice”
encodingStyle =“ http://schemas.xmlsoap.org/soap/encoding/”/>
</output>
</operation>

</binding>
67
RPC/encoded 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:stockSymbol xsi:type=“xsd:string”>
IBM
</n:stockSymbol>
</n:getQuoteOp>
</s:Body>
</s:Envelope>
68
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!
69
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!
70
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
71
Example – RPC/literal SOAP
Binding
identifies
portType
<binding name = “GetQuoteSOAPBinding” type = “tns:GetQuotePT”>
<soap:binding style = “rpc”
rpc style
transport = “ http://schemas.xmlsoap.org/soap/http/”/>
msg
<operation name = “getQuoteOp”>
<input>
<soap:body
don’t encode
use = “literal”
parameters
namespace =“http://www.shearson.com/quoteservice”/>
</input>
<output> …. </output>
</operation>
</binding>
72
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>
73
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
74
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
75
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-way
pattern
76
Example (con’t)
SOAP body
contains XML
documents
<binding name = “sendInvBinding”
type = “ing:invoicePT>
<soap:binding style = “document”
transport = “http://schemas.xmlsoap.org/soap/http”/>
<operation name = “inv:sendInvoiceOp”>
body is an
<input>
instance of
<soap:body
part type
use = “literal”
namespace = “http://www.invoicesource.com/invoice”/>
</input>
</operation>
</binding>
77
Document/literal SOAP Binding
Alternative 1 – one part specified by a type
<types>
<schema>
<complexType name=“comptyp”> … </complexType>
<schema>
n is target
</types>
<message name=“msg”>
<part name=“part1” type=“n:comptyp” />
</message>
<soap:Envelope>
<soap:Body>
…instance of comptyp…
</soap:Body>
</soap:Envelope>
namespace of
this document
message can have only one
part in this case since the
schema of the body can have
only one type specification
78
Document/literal SOAP Binding
Alternative 2 – part specified by an element
<types>
<schema>
<element name=“elem” type=“n:comptyp” />
<complexType name=“comptyp”> … </complexType>
<schema>
</types>
Part is identified as an
<message name=“msg”>
<part name=“part1” element=“n:elem” />
</message>
element. An instance of
element is a child of
body, named with
element’s name, typed
with element’s type
<soap:Envelope>
<soap:Body>
<n:elem xmlns=“ …target ns of WSDL doc… “>
…instance of comptyp…
</n:elem>
</soap:Body>
</soap:Envelope>
79
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>
<soap:Body>
<inv:firstInvoice>

</inv:firstInvoice>
<inv:secondInvoice>

</inv:secondInvoice>
</soap:Body>
element specification
must be used
since message has
multiple parts
80
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>
81
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>
82
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>
83
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
84
Business Process Execution
Language for Web Services
(BPEL4WS)
Version 1.1
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).
86
Simple Example: Ordering
Stationery
cobegin
invoke Staples.StationeryQuote(staples-quote);
invoke Office-Max.StationeryQuote Service(max-quote);
coend;
state
if staples-quote < max-quote
{invoke Staples.StationeryPurchase}
else
{invoke Office-Max.StationeryPurchase}
87
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
88
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 …..
89
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>
90
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
91
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
92
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
93
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
94
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
95
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
96
Abstract BP – Non-determinism
computation that
assigns a value
to part x
non-deterministic
assignment
to property x
(alias of x)
switch(x)
switch(x )
Executable BP
Abstract BP
97
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
98
Communication – Client Side
• 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
99
Communication – Client Side
client
(synchronous invoke)
client
waits
•••
invoke
•••••
client
continues
receive
server exports
portType
(asynchronous invoke)
(asynchronous invoke)
client exports
(callback) operation
••••••
invoke
(asynchronous invoke)
•••
•••
invoke
server
problem: how do
you associate
request with
response?
100
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
101
Communication – Server Side
client
(synchronous invoke)
(asynchronous invoke)
(asynchronous invoke)
server exports
portType
receive
••
••••
receive
(asynchronous invoke)
client exports
(callback) portType
••
receive
reply
•••
invoke
invoke
receive
•••
invoke
server
invoke
102
Example: Purchase Order (PO) Service
sequencing
receive
purchase
order
concurrency
initiate
price
calculation
decide on
shipper
initiate
production
scheduling
complete
price
calculation
arrange
logistics
complete
production
scheduling
synchronization
invoice
processing,
reply
103
PO Service
PO Service
synchronous
invocation
receive
POMsg
operation
sendPurchOr
on portType
purchOrPT
customer
Body of PO
Service
InvMsg
reply
104
PO Service Interface (WSDL)
<definitions targetNamespace=“….”
xmlns=“http://schemas.smlsoap.org/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>
portType exported
<input message=“pos:POMsg/> -- arguments supplied
by PO Service
<ouput message=“pos:InvMsg”/> -- response
</operation>
prefix for target
</portType>
namespace in
…..
this document
105
</definitions>
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
<variable name=“PO” messageType=“lns:POMsg”/>
lns is prefix in BPEL document for the WSDL document
• Can be an XML simple type
• Can be an XML schema element (which might have a complex
type)
– Has an associated scope
106
Partner Link Type (WSDL)
• <partnerLinkType> describes the way two BPs interact:
- names a portType that must be declared in each
- associates <role> with each end of the interaction
WSDL extension for BPEL
<plnk:partnerLinkType name=“purchLT”>
<plnk:role name=“purchService”>
<plnk:portType name=“pos:purchOrPT”/>
</plnk:role>
</plnk:partnerLinkType>
Only one role (in this
case) since only
POService needs to
provide an portType
Not a process
(allows actual
partner to be
specified
dynamically)
partnerLinkType
is a unit of
collaboration
107
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>
description of a
possible relationship
between two BPs
BP playing role
of invoice
requester
invoiceCallbackPT
BP playing role
of invoice service
computePricePT
108
Partner Link (BPEL)
• 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.
partner
specification in
PO service
<partnerLinks>
<partnerLink name=“purchLink”
partnerLinkType=“lns:purchLT”
myRole=“purchService”/>

</partnerLinks>
name of
partnerLink
prefix lns refers to
WSDL document
hence PO service
must provide
purchOrPT
109
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>
110
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>
111
Linkage: Customer
to PO Service
plnk – prefix in WSDL doc refers
to WSDL extension
pos – target ns of WSDL doc
lns – prefix in PO Service refers
to WSDL doc
cns – prefix in customer refers
to WSDL doc
<plnk:partnerLinkType name=“purchLT>
<plnk:role name=“purchService”>
<plnk:portType name=“pos:purchOrPT”/>
</plnk:role>
</plnk:partnerLinkType>
WSDL interface exported
by PO Service
<partnerLink name=“linkToPurch”
partnerLinkType=“cns:purchLT”
partnerRole=“purchService”/>
partner
specification
in customer
process
<partnerLink name=“purchLink”
partnerLinkType=“lns:purchLT”
myRole=“purchService”/>
partner
specification
in PO Service
112
Partners
• 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.
<partnerLinks>
<partnerLink name=“invoiceProvider”
partnerLinkType=“lns:invoiceLT”
myRole=“invoiceRequester”
partnerRole=“invoiceServices”/>
</partnerLinks>
113
PO Service (BPEL)
<variables>
<variable name=“PO” messageType=“lns:POMsg”/>
<variable name=“Invoice” messageType=“lns:InvMsg”/>
</variables>
Both necessary since PO Service might communicate
with several BPs through the same portType
<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>
114
Interaction with Shipping Provider
PO service
decide on
shipper
(invoke)
operation requestShipping
on portType shippingPT
shipReqMsg
shipInfoMsg
arrange
logisitics
(receive)
scheduleMsg
operation sendSchedule on
port shippingCallbackPT
Shipping
service
role = shippingService
role = shippingRequester
115
Handling Shipping (WSDL)
<portType name=“shippingCallbackPT”>
<operation name=“sendSchedule”>
<input message=“…”/>
</operation>
</portType>
portType exported
by PO Service
<portType name=“shippingPT”>
<operation name=“requestShipping”>
<input message=“…”/>
<output message=“…”/>
</operation>
</portType>
portType exported
by shipping
service
116
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>
WSDL
<partnerLink name=“shippingProvider”
partnerLinkType=“lns:shippingLT”
myRole=“shippingRequester”
partnerRole=“shippingService”/>
BPEL
(PO service)
117
Handling Shipping (BPEL)
contains
input
message
<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>
118
Links (BPEL)– Synchronizing
Concurrent Activities w/i a BP
• Production scheduling cannot be completed until
logistics have been arranged
Concurrent sequence activities in flow
initiate
production
scheduling
decide on
shipper
arrange
logistics
link
source
complete
production
scheduling
target
• data produced by
arrange logistics is
needed by complete
production scheduling
• data communicated
through globally shared
variable
119
Links
decide on
shipper
arrange
logistics
complete
production
scheduling
<flow>
<links>
<link name=“ship-sched”/>
</links>
<sequence>
<assign> …. </assign>
<invoke partnerLink= ….> </invoke>
<receive partnerLink= ….
shipping
variable=“shippingSched”>
<source linkName=“ship-sched”/>
</receive>
concurrent
</sequence>
<sequence>
<invoke partnerLink=….> </invoke>
<invoke partnerLink=….
scheduling
inputVariable=“shippingSched”>
<target linkName=“ship-sched”/>
</invoke>
</sequence>
….
120
</flow>
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’/>
121
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
122
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)
123
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 a
conversation
124
Using Correlation Sets
• A particular receive operation can be used in a BP
to accept the start of a new conversation
asynchronous
purchase request
<receive partnerLink =“Buyer”
portType=“SP:PurchasingPT”
create a new correlation
operation=“asynchPurchase”
set value for BP instance
variable=“PO”>
<correlations>
<correlation set=“PurchaseOrder” initiate=“yes”/>
</correlations>
</receive>
• All subsequently arriving messages with same
value of PurchaseOrder will be directed to this BP
125
Using Correlation Sets
• Response returns the correlation set value
– Asynchronous (callback) response to previous
invocation
<invoke partnerLink “Buyer”
use the set to
portType=“SP:BuyerPT”
address the
operation=“asynchPurchaseResp”
message
variable=“PO”>
<correlations>
<correlation set=“PurchaseOrder” initiate=“no”/>
</correlations>
</invoke>
– A reply to a synchronous invocation would be similar
126
Multiple Correlation Sets
messages of a
single conversation
buyer
invoke(corrSet=“PO” init=“yes”)
server
receive(corrSet=“PO” init=“yes”)
receive(corrSet=“PO” init=“no”
corrSet=“inv” init=“yes”)
invoke(corrSet=“PO” init=“no”
corrSet=“inv” init=“yes”)
subsequent messages sent and received use
correlation set inv
messsage
contains both
correlation sets
127
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>
128
Data Manipulation
• Data (state) stored in variables (used for messages and
local storage)
• Expressions use expression language (XPath default) to
access data in variables
query string
– Executable processes can use:
bpws:getVariableData (‘variableName’, ‘partName’, ‘locationPath’?)
– All processes can use:
bpws:getVariableProperty(‘variableName’, ‘propertyName’)
property alias contains
query string
– 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.
129
Assignment
• Allows copying of data
• One form (for executable processes):
<assign>
<copy>
<from variable=“v1” part=“p1” query=“q1”/>
<to variable=“v2” part=“p2” query=“q2”/>
</copy>
</assign>
– 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)
130
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>
131
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>
132
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>
133
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.
134
Providing Web Service Operations
• receive waits for an invocation to arrive
<receive partnerLink=“customer” portType=“lns:purchOrPT”
operation=“sendPurchOr” variable=“POmsg”/>
</receive>
– specifies a partnerLink, since a portType can be
associated with several partnerLinkTypes
connected to different BPs
135
Providing Web Service Operations
• Initiating a new instance of a BP:
<receive partnerLink=“customer” portType=“lns:purchOrPT”
operation=“sendPurchOr” variable=“POmsg”
createInstance=“yes”>
</receive>
– 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:
<correlation set=“PurchaseOrder” initiation=“yes”/>
136
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
<reply partnerLink=“customer” portType=“lns:purchOrPT”
operation=“sendPurchOr” variable=“Invoice”/>
• Response to an asynchronous invocation is made
using an invoke on a callback operation
– partnerLink between requestor and requestee must have
two roles
137
Other Basic Activities
• <terminate>
• <wait until=“deadline”>
or
<wait for=“duration”>
• <empty>
138
Structured Activities
• <sequence>

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

</case>
<otherwise>

</otherwise>
</switch>
Involves only
properties if
process is abstract
at least one case
element; conditions
evaluated in order
if present, executed
if all conditions
fail, else an empty
otherwise is assumed
139
Structured Activities
• <while condition=“bool-exp”>

</while>
• <pick>
-- waits for the occurrence of first event
<onMessage partnerLink=“..” portType=“..”
at least one,
operation=“..” variable=“..”>
acts like
 receive
</onMessage>
<onAlarm for=“durationExp” | until=“deadlineExp”> zero or

more
</onAlarm>
</pick>
140
Structured Activities
• <flow> concurrently executes nested (child)
activities
• Terminates when all children terminate
executed
concurrently
<sequence>
<flow>
<invoke partnerLink=… />
<invoke partnerLink=… />
</flow>
<invoke partnerLink=…/>
</sequence>
141
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
142
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
143
Endpoint References
• A message part can have type
EndpointReferenceType (as defined in WSAddressing)
• 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
144
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
145
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
146
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>
147
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>
148
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)
149
Assignment and Endpoint
References
• Sending an address: from child of copy can have form
<from partnerLink=“ … ”
endpointReference=“myRole|partnerRole ”/>
– 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)
<to partnerLink=“ … ” />
150
Links – Synchronizing Flow
<flow>
Activities
<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
151
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
variable name
<source linkName=“AtoB”
property name
transitionCondition=“getVariableProperty(‘eval’, ‘risk’) = ‘low’ ”/>
- The transitionCondition determines the link status (positive or
negative) when the activity terminates
152
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>
153
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”/>
…….
must specify an incoming
</sequence>
link for activity X
X starts when control point
reaches sequence and status
of both incoming links is true
154
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.
155
Link
Semantics
<flow>
<link name=“AtoC”/>
<link name=“BtoC”/>
<sequence>
<switch>
<case condition=“C1”>
<sequence name=“A”>
<source linkName=“AtoC”/>
….
</sequence>
</case>
<case condition=“C2”>
<sequence name=“B”>
<source linkName=“BtoC”/>
….
</sequence>
</case>
</switch>
…….
</flow>
<sequence name=“C”>
<target name=“AtoC”/>
<target name=“BtoC”/>
………
- 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)
156
transitionCondition is “true”
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
157
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
158
Link
Semantics
<flow suppressJoinFailure=“yes”>
<link name=“AtoC”/>
<sequence>
<switch>
<case condition=“C1”>
<sequence name=“A”>
<source linkName=“AtoC”/>
….
</sequence>
</case>
<case condition=“C2”>
<sequence name=“B”>
….
</sequence>
</case>
</switch>
…….
</flow>
<sequence name=“C”>
<target name=“AtoC”/>
………
- 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
159
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.
160
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
161
Faults
• Source of faults (con’t):
– Fault response to an invoke. The reply:
<reply partnerLink=“customer” portType=“lns:loanServicePT”
operation=“request” variable=“error”
faultName=“unableToHandleRequest”/>
raises the fault unableToHandleRequest in BP
that has synchronously invoked request on portType:
<portType name=“loanServicePT”>
<operation name=“request”>
<input message=“lns:creditInfoMsg”/>
<output message=“lns:approvalMsg”/>
<fault name=“unableToHandleRequest” message=“errorMsg”/>
</operation>
</portType>
162
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 ….
Re-throw the same fault
</catch>
and/or clean-up and/or
</faultHandlers>
invoke a compensation
handler
163
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”
….. >
or
<catch
faultName=“unable…”
faultVariable=“error”>
…. handle the fault….
</catch>
</invoke>
implicit scope
<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…
164
</scope>
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.
165
Fault Flow of Control
A
B
catch f
throw g
or
exit
or
either way, B is
exited abnormally
throw f
166
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., twophase commit) over multiple invocations by a BP
167
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
168
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”
-- invSeller is
operation=“syncPurch” inputVariable=“sendPO”
name of scope
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>
169
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
170
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)
171
Handler Invocation
A
catch f
compensate B
fault handler
for f
compensate C
compensate D
compensation
handler for B
B
Although B, C and
D may have exited
normally, A will
exit abnormally
in this case
C
compensation
handler for C
D
compensation
handler for D
throw f
172
Compensation
<scope>
<faultHandlers>
<catch faultName=“unableTo…” faultVariable=“error”>
<compensate scope=“invBank”/>
</catch>
</faultHandlers>
<sequence>
<invoke name=“invBank” partnerLink=“myBank”
fault
portType=“bankPT” operation=“Op” ….>
compensate
<compensationHandler>
<invoke partnerLink=“myBank” portType=“bankPT”
operation=“cancelOP” …..>
</invoke>
normal
</compensationHandler>
exit
</invoke>
<invoke partnerLink=“loanApprovProc”
portType=“lns:loanservicePT” operation=“request” ….. >
</invoke>
fault returned; abnormal
exit
…………
173
Default Handlers
• Problem: Suppose a fault handler
is not declared
default
handler
for f
A
B
C
compensation
handler for C
• 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
throw f
174
Default Handlers
• Problem: Suppose a
compensation handler
is not declared
fault handler
for f
default
compensation
handler
catch f
compensate B
A
B
C
compensation
handler for C
• Compensation handler for C
cannot be called from within A
• Solution: default compensation
handler automatically invokes
declared compensation handlers
of immediately enclosed scopes
throw f
175
Structure of a BP
<process name=“…” abstractProcess=“yes|no” … />
<partnerLinks> … </partnerLinks>
<variables> … </variables>
<correlationSets> … </correlationSets>
<faultHandlers> … </faultHandlers>
<compensationHandlers> … </compensationHandlers>
activity
</process>
176