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>
8
HTTP Request Format
Start line: <method> <URL> <protocol_version> CrLfFollowed by: <header>*Followed by: CrLfFollowed by: <data>
<method> = GET | HEAD | POST | PUT | ….<protocol_version> = HTTP/1.1 | ….
there canbe severalheader lines
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
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> <!-- header blocks go here --> </s:Header>
<s:Body> <!-- an XML document goes here --> </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: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>
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: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>
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>
</s:Body></s:Envelope>
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
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>
<!-- other operations go here -->
</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> <!-- WSDL declarations go here --></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>
<!-- other operations go here -->
</binding>
68
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>
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”> <!-- the complex type definition goes here --></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> <!-- instance of invoiceType goes here --> </inv:firstInvoice> <inv:secondInvoice> <!-- instance of invoiceType goes here --> </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> <!-- specification of other services goes here --></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
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
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
100
Communication – Client Side
client server
invoke
invoke
invoke
receive
• • •
• •
• •
•
• •
• •
• •
• •
• server exportsportType
client exports (callback) operation
(synchronous invoke)
(asynchronous invoke)
clientwaits
clientcontinues
problem: how doyou associaterequest withresponse?
• • •
(asynchronous invoke)
(asynchronous invoke)
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)
(asynchronous invoke)
receive
reply
receive
receive
invoke
invoke
receive invoke(asynchronous 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”/> <!-- other partnerLink’s go here --></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”/> <!-- supports getFarePT --> <partnerLink name=“yyyy”/> <!-- supports purchaseTicketPT --> </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
completeproductionscheduling
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
completeproductionscheduling
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> <!-- list of activities --> </sequence>• <switch> <case condition=“bool-expr”>
<!-- activity --> </case> <otherwise> <!-- activity --> </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
Structured Activities
• <while condition=“bool-exp”> <!-- iteratively executed activity --> </while>• <pick> -- waits for the occurrence of first event <onMessage partnerLink=“..” portType=“..” operation=“..” variable=“..”> <!-- activity to process message --> </onMessage> <onAlarm for=“durationExp” | until=“deadlineExp”> <!-- timeout activity --> </onAlarm> </pick>
at least one,acts likereceive
zero or more
141
Structured Activities
• <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.
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
compensationhandler for C
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
compensationhandler for C
fault handlerfor f
catch f compensate B