Web services
This presentation is the property of its rightful owner.
Sponsored Links
1 / 176

Web Services PowerPoint PPT Presentation


  • 52 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Web Services

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


Web basics

Web Basics


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


Web services

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


Web services description language wsdl

Web Services Description Language (WSDL)

Version 1.1


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


Business process execution language for web services bpel4ws

Business Process Execution Language for Web Services (BPEL4WS)

Version 1.1


Bpel vs wsdl

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


Simple example ordering stationery

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


New issues

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


Example bpel

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


Example bpel1

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>


Business process bp

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


Abstract vs executable bps

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


Executable bps

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


Abstract bp

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

  • 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

  • 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

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

  • 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

  • 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

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

  • 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

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

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

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)

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

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

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

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

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

  • 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

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

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

<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

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)

<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

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

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

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

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

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

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

  • 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

  • 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

  • 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

  • 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

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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • <terminate>

  • <wait until=“deadline”>

    or

    <wait for=“duration”>

    • <empty>


Structured activities

Structured Activities

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

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

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

  • 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

  • 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

  • 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

<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

  • 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

<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

<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

  • 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

  • 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

<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

• 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

• 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

• 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

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

<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

  • 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

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

  • 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

  • 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

  • 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

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

  • 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

  • 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

A

B

catch f

throw g

or

exit

or

either way, B is

exited abnormally

throw f


Atomicity

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


Long running business transactions lrt

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


Compensation handler

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 is

name of scope


Invoking compensation

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


Invoking compensation1

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)


Handler invocation

Handler Invocation

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

<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

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

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

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

<partnerLinks> … </partnerLinks>

<variables> … </variables>

<correlationSets> … </correlationSets>

<faultHandlers> … </faultHandlers>

<compensationHandlers> … </compensationHandlers>

activity

</process>


  • Login