Web services
Download
1 / 176

Web Services - PowerPoint PPT Presentation


  • 67 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Web Services' - nita


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Web services

Web Services

Chapter 28



Internet
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


Connection oriented protocol
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.


Hypertext transfer protocol http
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 followedby 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.


Protocol stack
Protocol Stack

HTTP

TCP

Added features to support

client interactions (reliability

flow control, ..)

Network Level

Protocol

End-to-end protocol

Link Level

Protocol

Protocol for tranmitting packets

between neighboring nodes


Clients and servers
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>


Http request format
HTTP Request Format

Start line: <method> <URL> <protocol_version> CrLf

Followed by:<header>*

Followed by: CrLf

Followed by: <data>

<method> = GET | HEAD | POST | PUT | ….

<protocol_version> = HTTP/1.1 | ….

there can

be several

header lines


Request methods
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


Request methods1
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 ….


Http request format1
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 | --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)


Simple client server interaction i
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


Simple client server interaction i1
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


Http response
HTTP Response

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

Followed by: < header >*

Followed by: <data>


Http response1
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 | ….


Simple client server interaction i2
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 follows

Date: <date>

Content-Type: text/html

Content-Length: integer

Expires: date

html document ~items/printers.html goes here


Simple client server interaction ii
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


Simple client server interaction ii1
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


Hypertext transfer protocol http 1 1
HyperText Transfer Protocol (HTTP 1.1)

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

2. Client sends a request

3. Client receives a response

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

- Only actively used connections are maintained


SOAP

Version 1.2


What is soap
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


Http binding
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 arequest 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 


Soap and xml
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


Soap message
SOAP Message

SOAP Envelope

SOAP Header

Header Block

optional

Header Block

SOAP Body

Message Body

required


Soap envelope
SOAP Envelope

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

<s:Header>

<!-- header blocks go here -->

</s:Header>

<s:Body>

<!-- anXML 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


Using soap
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


Rpc request message
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>


Rpc response message
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>


Rpc request response messages
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


Data encoding
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


Serialization
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?


Encoding style
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


Soap encoding style
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


Data encoding1
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>


Soap extensibility
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


Intermediaries
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


Example
Example

purchasing

server

Proxy/

gateway

client

accounting

server

inventory

server

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


Requirements
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


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


Example message sent by client
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>


Processing model
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)


Must understand
Must Understand

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

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


Example message sent by proxy
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>


Example message sent by proxy1
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


Ws addressing
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


Ws addressing1
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

    • ….


Ws addressing2
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)


Soap faults
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


Embedding soap in http post
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.


Embedding rpc style soap in http
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>


Embedding soap in http get
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



Goals of wsdl
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


Wsdl description
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?


Wsdl abstract level
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


Example1
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 containing

this declaration and the message declarations


Patterns
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


Faults
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


Example message definitions
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>


Parts of a message
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


Example2
Example

<schema>

<complexType name = “faultType”>

<sequence>

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

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

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

</sequence>

</complexType>

</schema>


Concrete level
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


Concrete level1
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


Example service and port
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>

identifies

binding


Wsdl extensibility
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


Example rpc encoded soap binding
Example – RPC/encoded SOAP Binding

identifies

portType

<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

rpc style

msg

for tags

used in

messsage

SOAP

extensions

encode

parameters

encoding

rules


Binding example continued
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>


Rpc encoded message
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>


Encoding
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!


Example encoding style
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!


Encoded vs literal
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


Example rpc literal soap binding
Example – RPC/literal SOAP Binding

identifies

portType

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

rpc style

msg

don’t encode

parameters


Rpc literal soap binding
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>


Rpc encoded and rpc literal
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


Sending documents
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


Example document style messaging
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


Example con t
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”>

<input>

<soap:body

use = “literal”

namespace = “http://www.invoicesource.com/invoice”/>

</input>

</operation>

</binding>

body is an

instance of

part type


Document literal soap binding
Document/literal SOAP Binding

Alternative 1 – one part specified by a type

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

n is target

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


Document literal soap binding1
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>

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

Part is identified as an

element. An instance of

element is a child of body, named with element’s name, typed with element’s type


Sending multiple documents
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 used

since 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>


Sending messages by email simple mail transfer prototol
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>


Mail example continued
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>


Complete wsdl document
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>


What wsdl cannot do
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



Bpel vs wsdl
BPEL vs. WSDL (BPEL4WS)

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


Simple example ordering stationery
Simple Example: Ordering Stationery (BPEL4WS)

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


New issues
New Issues (BPEL4WS)

  • 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


Example bpel
Example (BPEL) (BPEL4WS)

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


Example bpel1
Example (BPEL) (BPEL4WS)

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


Business process bp
Business Process (BP) (BPEL4WS)

  • 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


Abstract vs executable bps
Abstract Vs. Executable BPs (BPEL4WS)

  • 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


Executable bps
Executable BPs (BPEL4WS)

  • 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


Abstract bp
Abstract BP (BPEL4WS)

  • 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 willnot if it does not affect the course of the protocol

  • Only properties are visible to abstract BP


Abstract vs executable bp
Abstract Vs Executable BP (BPEL4WS)

  • 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


Abstract bp non determinism
Abstract BP – Non-determinism (BPEL4WS)

  • 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


Abstract bp non determinism1
Abstract BP – Non-determinism (BPEL4WS)

computation that

assigns a value

to part x

non-deterministic

assignment

to property x

(alias of x)

switch(x)

switch(x )

Abstract BP

Executable BP


Communication client side
Communication – Client Side (BPEL4WS)

  • 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


Communication client side1
Communication – Client Side (BPEL4WS)

  • 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


Communication client side2
Communication – Client Side (BPEL4WS)

clientserver

invoke

invoke

invoke

receive

(synchronous invoke)

• • •

client

waits

(asynchronous invoke)

server exports

portType

• • •

client

continues

• • •

(asynchronous invoke)

problem: how do

you associate

request with

response?

• • • • • •

• • • • •

(asynchronous invoke)

client exports

(callback) operation


Communication server side
Communication – Server Side (BPEL4WS)

  • 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


Communication server side1
Communication – Server Side (BPEL4WS)

clientserver

invoke

(synchronous invoke)

receive

• • •

reply

(asynchronous invoke)

receive

server exports

portType

invoke

• • •

(asynchronous invoke)

receive

invoke

• •

• • • •

• •

(asynchronous invoke)

receive

invoke

client exports

(callback) portType


Example purchase order po service
Example: Purchase Order (PO) Service (BPEL4WS)

receive

purchase

order

concurrency

sequencing

initiate

price

calculation

decide on

shipper

initiate

production

scheduling

complete

price

calculation

arrange

logistics

complete

production

scheduling

synchronization

invoice

processing,

reply


Po service
PO Service (BPEL4WS)

PO Service

receive

synchronous

invocation

POMsg

Body of PO

Service

customer

operation

sendPurchOr

on portType

purchOrPT

InvMsg

reply


Po service interface wsdl
PO Service Interface (WSDL) (BPEL4WS)

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

<input message=“pos:POMsg/> -- arguments supplied

<ouput message=“pos:InvMsg”/> -- response

</operation>

</portType>

…..

portType exported

by PO Service

prefix for target

namespace in this document

</definitions>


Variables bpel
Variables (BPEL) (BPEL4WS)

  • 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


Partner link type wsdl
Partner Link Type (WSDL) (BPEL4WS)

•<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

Not a process (allows actual partner to be specified dynamically)

<plnk:partnerLinkType name=“purchLT”>

<plnk:role name=“purchService”>

<plnk:portType name=“pos:purchOrPT”/>

</plnk:role>

</plnk:partnerLinkType>

partnerLinkType

is a unit of collaboration

Only one role (in this case) since only POService needs to provide an portType


Partner link type wsdl1
Partner Link Type (WSDL) (BPEL4WS)

<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

BP playing role

of invoice service

invoiceCallbackPT

computePricePT


Partner link bpel
Partner Link (BPEL) (BPEL4WS)

• 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

name of partnerLink

prefix lns refers to WSDL document

<partnerLinks>

<partnerLink name=“purchLink”

partnerLinkType=“lns:purchLT”

myRole=“purchService”/>

<!-- other partnerLink’s go here -->

</partnerLinks>

hence PO service must provide purchOrPT


Partner bpel
Partner (BPEL) (BPEL4WS)

  • 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>


Process name
Process Name (BPEL4WS)

  • 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>


Linkage customer to po service

plnk – (BPEL4WS) 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

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 exported

by PO Service

partner

specification

in customer

process

partner

specification

in PO Service


Partners
Partners (BPEL4WS)

• 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>


Po service bpel
PO Service (BPEL) (BPEL4WS)

<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


Interaction with shipping provider
Interaction with Shipping Provider (BPEL4WS)

PO service

operation requestShipping

on portType shippingPT

decide on

shipper

(invoke)

shipReqMsg

Shipping

service

shipInfoMsg

scheduleMsg

arrange

logisitics

(receive)

operation sendSchedule on

port shippingCallbackPT

role = shippingService

role = shippingRequester


Handling shipping wsdl
Handling Shipping (WSDL) (BPEL4WS)

<portType name=“shippingCallbackPT”>

<operation name=“sendSchedule”>

<input message=“…”/>

</operation>

</portType>

<portType name=“shippingPT”>

<operation name=“requestShipping”>

<input message=“…”/>

<output message=“…”/>

</operation>

</portType>

portType exported

by PO Service

portType exported

by shipping

service


Handling shipping
Handling Shipping (BPEL4WS)

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


Handling shipping bpel
Handling Shipping (BPEL) (BPEL4WS)

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>


Links bpel synchronizing concurrent activities w i a bp
Links (BPEL)– Synchronizing Concurrent Activities w/i a BP (BPEL4WS)

  • Production scheduling cannot be completed until logistics have been arranged

Concurrent sequence activities in flow

• data produced by

arrange logistics is

needed by complete

production scheduling

• data communicated

through globally shared

variable

decide on

shipper

initiate

production

scheduling

arrange

logistics

complete

production

scheduling

link

source

target


Links

<flow> (BPEL4WS)

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

Links

decide on

shipper

shipping

arrange

logistics

concurrent

complete

production

scheduling

scheduling


Properties wsdl
Properties (WSDL) (BPEL4WS)

  • 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’/>


Property alias wsdl
Property Alias (WSDL) (BPEL4WS)

  • 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


Correlation sets bpel
Correlation Sets (BPEL) (BPEL4WS)

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


Correlation sets
Correlation Sets (BPEL4WS)

  • 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


Using correlation sets
Using Correlation Sets (BPEL4WS)

  • 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

asynchronous

purchase request

<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


Using correlation sets1
Using Correlation Sets (BPEL4WS)

  • 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 to

address the

message


Multiple correlation sets
Multiple Correlation Sets (BPEL4WS)

messages of a

single conversation

buyer server

invoke(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

messsage

contains both

correlation sets


Multiple correlation sets1
Multiple Correlation Sets (BPEL4WS)

  • 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>


Data manipulation
Data Manipulation (BPEL4WS)

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

query string

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

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

property alias contains query string


Assignment
Assignment (BPEL4WS)

  • 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>


Assignment in abstract process
Assignment in Abstract Process (BPEL4WS)

  • 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>


Invoking web service operations
Invoking Web Service Operations (BPEL4WS)

  • 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>


Invoking web service operations1
Invoking Web Service Operations (BPEL4WS)

  • 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>


Synchronous vs asynchronous invocation
Synchronous Vs. Asynchronous Invocation (BPEL4WS)

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


Providing web service operations
Providing Web Service Operations (BPEL4WS)

  • 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>


Providing web service operations1
Providing Web Service Operations (BPEL4WS)

  • 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”/>


Providing web service operations2
Providing Web Service Operations (BPEL4WS)

  • 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”/>


Other basic activities
Other Basic Activities (BPEL4WS)

  • <terminate>

  • <wait until=“deadline”>

    or

    <wait for=“duration”>

    • <empty>


Structured activities
Structured Activities (BPEL4WS)

Involves only properties if process is abstract

  • <sequence>

    <!-- list of activities -->

    </sequence>

    • <switch>

    <case condition=“bool-expr”>

    <!-- activity -->

    </case>

    <otherwise>

    <!-- activity -->

    </otherwise>

    </switch>

at least one case

element; conditions

evaluated in order

if present, executed

if all conditions

fail, else an empty

otherwise is assumed


Structured activities1
Structured Activities (BPEL4WS)

  • <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 like

receive

zero or

more


Structured activities2
Structured Activities (BPEL4WS)

  • <flow> concurrently executes nested (child) activities

  • Terminates when all children terminate

<sequence>

<flow>

<invoke partnerLink=… />

<invoke partnerLink=… />

</flow>

<invoke partnerLink=…/>

</sequence>

executed

concurrently


Wsdl review
WSDL Review (BPEL4WS)

  • 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


Endpoint references
Endpoint References (BPEL4WS)

  • 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


Endpoint references1
Endpoint References (BPEL4WS)

  • 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


Ws addressing specification for endpoint reference
WS-Addressing Specification for Endpoint Reference (BPEL4WS)

<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


Endpoint reference
Endpoint Reference (BPEL4WS)

  • 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


Endpoint reference example
Endpoint Reference Example (BPEL4WS)

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


Endpoint reference example1
Endpoint Reference Example (BPEL4WS)

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


Endpoint reference1
Endpoint Reference (BPEL4WS)

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


Assignment and endpoint references
Assignment and Endpoint References (BPEL4WS)

  • 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=“ … ” />


Links synchronizing flow activities
Links – Synchronizing Flow Activities (BPEL4WS)

<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


Link semantics at the source
Link Semantics at the Source (BPEL4WS)

• 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 name

property name


Link semantics at the target
Link Semantics at the Target (BPEL4WS)

• 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>


Link semantics at the target1
Link Semantics at the Target (BPEL4WS)

• 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 incoming

link for activity X

X starts when control point

reaches sequence and status

of both incoming links is true


Link semantics at the target2
Link Semantics at the Target (BPEL4WS)

  • 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 activitythat does not complete due to a fault) then the status of all outgoing links from X is set to negative.


Link semantics

<flow> (BPEL4WS)

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

Link Semantics

  • 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”


Link semantics1
Link Semantics (BPEL4WS)

  • 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


Link semantics2
Link Semantics (BPEL4WS)

  • 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

    • itis skipped and execution continues (as if it had terminated without raising a fault)

    • referred to as dead-path-elimination


Link semantics3
Link (BPEL4WS)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


Scope
Scope (BPEL4WS)

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


Faults1
Faults (BPEL4WS)

  • 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


Faults2
Faults (BPEL4WS)

  • 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>


Faults3
Faults (BPEL4WS)

The reply raises theunableToHandleRequest 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 compensation

handler


Handlers
Handlers (BPEL4WS)

  • Handler is associated with an implicit or explicit scope; catches faults that occur in that 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…

</scope>

<invoke

partnerLink=“loanApprovProc”

portType=“lns:loanservicePT”

operation=“request”

….. >

<catch

faultName=“unable…”

faultVariable=“error”>

…. handle the fault….

</catch>

</invoke>

or

implicit scope


Fault flow of control
Fault Flow of Control (BPEL4WS)

  • 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, itis 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.


Fault flow of control1
Fault Flow of Control (BPEL4WS)

A

B

catch f

throw g

or

exit

or

either way, B is

exited abnormally

throw f


Atomicity
Atomicity (BPEL4WS)

  • 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


Long running business transactions lrt
Long-Running Business Transactions (LRT) (BPEL4WS)

  • 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


Compensation handler
Compensation Handler (BPEL4WS)

  • 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 is

name of scope


Invoking compensation
Invoking Compensation (BPEL4WS)

  • 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


Invoking compensation1
Invoking Compensation (BPEL4WS)

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


Handler invocation
Handler Invocation (BPEL4WS)

fault handler

for f

A

catch f

compensate B

B

compensation

handler for B

compensate C

compensate D

C

compensation

handler for C

compensation

handler for D

D

Although B, C and

D may have exited

normally, A will

exit abnormally

in this case

throw f


Compensation
Compensation (BPEL4WS)

<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

normal

exit

fault returned; abnormal exit


Default handlers
Default Handlers (BPEL4WS)

A

  • 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

B

default

handler

for f

C

compensation

handler for C

throw f


Default handlers1
Default Handlers (BPEL4WS)

catch f

compensate B

fault handler

for f

A

  • 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

B

default

compensation

handler

C

compensation

handler for C

throw f


Structure of a bp
Structure of a BP (BPEL4WS)

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

<partnerLinks> … </partnerLinks>

<variables> … </variables>

<correlationSets> … </correlationSets>

<faultHandlers> … </faultHandlers>

<compensationHandlers> … </compensationHandlers>

activity

</process>


ad