CS 290C: Formal Models for Web Software

Lectures 13: An Overview of Web Services

Instructor: Tevfik Bultan

Web Revolution

• Sharing information using Internet has been a big success

• Key components – Internet– Internet protocols such as TCP/IP– WWW and HTTP– HTML format– Web browsers

• Sharing information using the http+html+browser framework has been successful in a lot of applications– List your favorite web sites here

What Next?

• There are applications where http+html+browser framework does not work– Business to business applications

• HTML is developed for displaying information in a way that is understandable for humans

• HTML is not very useful in helping computers understand the content

• Basic QuestionCan we extend the interaction and sharing that WWW

created among humans tointeraction and sharing among services where the

services share information and collaborate using the Internet?

More Questions

• What should be the format that the services share the information?

• How will the information format be defined?• What protocol will the computers use to send and receive

information?• How can a computer find out about the information provided

by another computer?• How can we describe the interaction among multiple

computers?

Some Proposed Answers

• What should be the format that the services share the information? – XML

• How will the information format be defined?– XML Schema

• What protocol will the services use to send and receive information?– SOAP

• How can a service find out about the information provided by another service?– WSDL, UDDI

• How can we describe the interaction among multiple services?– BPEL, WS-CDL

Web Services Standards Stack

Data

Type

Service

Orchestration

Protocol

WS-BPEL

Web Service Standards

Impl

emen

tati

on

Pla

tfor

ms

Mic

roso

ft .N

et, S

un J

2EE

WSDL, UDDI

SOAP

XML Schema

XML

WS-CDLChoreography

What are Web Services?

• Web services can be described as – web accessible software that provide interfaces for

• service description,• discovery, and • interaction

Web Services: Challenges

• Web services implemented using different implementation platforms should be able to interact with each other – There are different implementation platforms such

as .Net or J2EE

• It should be possible to modify an existing web service without modifying other services that interact with it

• Web services should be able tolerate pauses in availability of other services and slow data transmission

Web Services: Challenges

Can’t we solve these challenges with existing technologies?

• Existing technologies for distributed computing such as CORBA and RMI require tight coupling among applications

• It is not possible to specify interactions among services using stateless protocols

Web Services: Characteristics

Web services address these challenges with the following common characteristics:

• Standardized data transmission via XML

• Loose coupling among interacting web services through standardized interfaces

• Message based communication

Web Services

• The World Wide Web Consortium (W3C) defines a Web service as – "a software system designed to support interoperable

machine-to-machine interaction over a network”

• The basic architecture

Service Requester

Service Provider

Service Broker

RegisterSearch

Request

Response

Web Services Standards Stack

Data

Type

Service

Registry

Protocol

Universal Description, Discovery & Integration (UDDI)

Web Services Description Language (WSDL)

Simple Object Access Protocol (SOAP)

XML Schema (XSD)

Extensible Markup Language (XML)

Service Requester

Service Provider

Service Broker

RegisterSearch

Request

Response

SOAP

WSDLWSDL

UDDI

Web Services Characteristics/Goals

• Interoperability– Platform independent (.NET, J2EE)– Service interactions across organizational boundaries

• Loose coupling– Standardized data transmission via XML– Interaction based on standardized interfaces such as

WSDL

• Communication via messages– Synchronous and asynchronous messaging

Basic Usage of Web Services

• What we have so far supports basic client/server style interactions

• Example: Amazon E-Commerce Web Service (AWS-ECS) • AWS-ECS WSDL specification lists 40 operations that

provide differing ways of browsing Amazon’s product database such as– ItemSearch, CartCreate, CartAdd, CartModify, CartGet,

CartClear• Based on the AWS-ECS WSDL specification one can

implement clients that interact with AWS-ECS

Service Requester

Service Provider

Request

Response

SOAP

WSDL

Client Server

Composing Services

• Can this framework support more than basic client/server style interactions?

• Can we compose a set of services to construct a new service?

• For example:– If we are building a bookstore service, we may want to

use both Amazon’s service and Barnes & Noble’s service in order to get better prices

• Another (well-known) example:– A travel agency service that uses other services (such

as flight reservation, hotel reservation, and car rental services) to help customers book their trips

Composing Services

Two dimensions:

1. Define an executable process that interacts with existing services and executes them in a particular order and combines the results to achieve a new goal• Orchestration: From atomic services to stateful

services

2. Specify how the individual services should interact with each other. Find or construct individual services that follow this interaction specification• Choreography: Global specification of interactions

among services

Orchestration vs. Choreography

• Orchestration: Central control of the behavior of a distributed system• Like a conductor conducting an orchestra• Conductor is in charge during the performance

• Orchestration specifies an executable process, identifying when and how that process should interact with other services– Orchestration is used to specify the control flow of a

composite web service (as opposed to an atomic web service that does not interact with any other service)

Orchestration vs. Choreography

• Choreography: Specification of the behavior of a distributed system without centralized control• Choreographer specifies the behavior of the dancing

team• Choreographer is not present during the execution

• A choreography specifies how the services should interact– It specifies the legal sequences of messages exchanged

among individual services (peers)– It is not necessarily executable

• A choreography can be realized by writing an orchestration for each peer involved in the choreography– Choreography as global behavior specification– Orchestration as local behavior specification that

realizes the global specification

Orchestration with WS-BPEL

• Web Services Business Process Execution Language (WS-BPEL) is an orchestration language

• A WS-BPEL specification describes the execution logic using basic and structured activities– Basic activities: RECEIVE, REPLY, INVOKE, ASSIGN, THROW, TERMINATE, WAIT,

EMPPTY, RECEIVE, REPLY, INVOKE

– Structured activities: SEQUENCE, SWITCH, WHILE, PICK, FLOW, SCOPE, COMPENSATE

• WS-BPEL supports messaging (RECEIVE, REPLY, INVOKE) and multi-threading (FLOW)

Choreography with WS-CDL

• Web Services Choreography Description Language (WS-CDL)

• WS-CDL specifications describe ``peer-to-peer collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal.''

• A WS-CDL specification describes the interaction ordering among a set of peers using basic and structured activities– Basic activities: INTERACTION, PERFORM, ASSIGN, SILENT ACTION, NO ACTION

– Structured activities: SEQUENCE, PARALLEL, CHOICE, PICK, FLOW, SCOPE, COMPENSATE

Web Services Standards Stack

Data

Type

Service Orchestration

Protocol

Web Services Business Process Execution Language (WS-BPEL)

Web Services Description Language (WSDL)

Simple Object Access Protocol (SOAP)

XML Schema (XSD)

Extensible Markup Language (XML)

AtomicService

AtomicService

OrchestratedService

SOAP

WSDL

WSDL

Choreography Web Services Choreography Description Language (WS-CDL)

WS-BPEL

OrchestratedService

WS-BPEL

SOAP

SOAP

SOAP

SOAPWS-CDL

An Example: Stock Analysis Service

The stock analysis service involves: – three peers Investor, Stock Broker Firm, and Research

Department

Here is how the stock analysis service operates:• Investor initiates the stock analysis service by sending a register message to the Stock Broker Firm

• The Stock Broker Firm may accept or reject the registration

• If the registration is accepted, the Stock Broker Firm sends an analysis request to the Research Department

An Example: Stock Analysis Service

• Research Department sends the results of the analysis directly to the Investor as a report

• After receiving a report the Investor can either send an ack to the Stock Broker Firm or cancel the service

• Then, the Stock Broker Firm either sends the bill for the services to the Investor, or continues the service with another analysis request

An Example: Stock Analysis Service (SAS)

register ack, cancel

accept, reject, bill

request,

terminate

report

Investor (Inv)

Research Dept.(RD)

Stock Broker(SB)

• SAS is a composite service that contains three individual services

<invoke> IBlink: register()

<On Message> IBlink: reject()

<On Message> IBlink: accept()

<receive> RIlink: report()

<invoke> IBlink: ack()

<invoke> IBlink: cancel()

<receive> RIlink: bill()

<receive> RIlink: bill()

Investor

reject()

accept()

bill()

Callback port

report()

Data port

<receive> IBlink: register()

<invoke> IBlink: reject()

<invoke> IBlink:

accept()<invoke> BRlink: request()

<receive> IBlink: ack()

<receive> IBlink: cancel()

<invoke> RIlink: bill()

<invoke> RIlink: bill()

Stock Broker Firm

register()

cancel()

Service Port

request()

Delegate Port

Service PortOutput PortRIlink BRlink

IBlink

<receive> BRlink: request()

<invoke> RIlink: report()

Research Dept.

ack()

Stock Analysis Service

Stock Analysis Service

• In the following slides I will discuss how different parts of the stock analysis service can be described using emerging web service standards– Message contents: XML– Message type: XML Schema– Message ports: WSDL– Behavior: BPEL

XML (eXtensible Markup Language)

• XML is a markup language like HTML• Similar to HTML, XML tags are written as

<tag> followed by </tag>• HTML vs. XML

– In HTML, tags are used to describe the appearance of the data

<b> </b> <i> </i> <br> <p> ...– In XML, tags are used to describe the content of the data

rather than the appearance

<date> </date> <address> </address>• XML documents can be modeled as trees where each

internal node corresponds to a tag and leaf nodes correspond to basic types

investorID

Register

1234

requestList

AAAA BBBB

payment

accountNum

56

stockID stockID

An XML Document and Its Tree

<Register><investorID>1234</investorID><requestList><stockID>AAAA</stockID><stockID>BBBB</stockID></requestList><payment><accountNum>56</accountNum></payment></Register>

XML Schema

• XML provides a standard way to exchange data over the internet.

• However, the parties which exchange XML documents still have to agree on the type of the data – what are the tags that will appear in the document, in

what order, etc.

• XML Schema is a language for defining XML data types

MSL (Model Schema Language)

• MSL (Model Schema Language) is a compact formal model language which captures most features of XML Schema

• Basic MSL syntax

g | b | t [ g ] | g { m , n }

| g , g | g & g | g | g

g is an XML type (i.e., an MSL type expression)

is the empty sequence

b is a basic type such as string, boolean, int, etc.t is a tag m and n are positive integers[ ] { } & , | are MSL type constructors

MSL Semantics

• t [ g ] denotes a type with root node labeled t with children of type g

• g { m , n } denotes a sequence of size at least m and at most n where each member is of type g

• g1 , g2 denotes an ordered sequence where the first member is of type g1 and the second member is of type g2

• g1 & g2 denotes an unordered sequence where one member is of type g1 and the other member is of type g2

• g | g denotes a choice between type g1 and type g2, i.e., either type g1 or type g2, but not both

An MSL Type Declaration and an Instance

Register[ investorID[xsd:int] & requestList[ stockID[xsd:string]{1,50} ] & payment[ creditCardNum[xsd:int] | accountNum[xsd:int] ]]

<Register><investorID>1234</investorID><requestList><stockID>AAAA</stockID><stockID>BBBB</stockID></requestList><payment><accountNum>56</accountNum></payment></Register>

An MSL Type Declaration and an Instance

Register[ investorID[1234] & requestList[ stockID[AAAA] , stockID[BBBB] ] & payment[ accountNum[56] ]]

MSL can also be used as a compact language for specifying data instances

investorID

Register

1234

requestList

AAAA BBBB

payment

accountNum

56

stockID stockID

XPath

• In order to write specifications or programs that manipulate XML documents we need: – an expression language to access values and nodes in

XML documents

• XPath is a language for writing expressions (queries) that navigate through XML trees and return a set of answer nodes

• An XPath query defines a function which – takes and XML tree and a context node (in the same

tree) as input and – returns a set of nodes (in the same tree) as output

XPath Syntax

Basic XPath syntax:

q . | .. | b | t | *

| /q | //q | q / q | q // q

| q [ q ] | q [ exp ]

q is an XPath query

exp denotes a predicate on basic types, i.e., on the leaf nodes of the XML tree

b denotes a basic type such as string, boolean, int, etc.

t denotes a tag

XPath Semantics

Given an XML tree and a node n as a context node

. returns n

.. returns the parent of n

Given an XML tree and a set of nodes

* returns all the nodes

b returns the nodes that are of basic type b

t returns the nodes which are labeled with tag t

XPath Semantics Contd.

Starting at the context node• /q returns the nodes that match q• //q returns the nodes that match q starting at any

descendant

• q1 / q2 returns each node which matches q2 starting at a child of a node which matches q1

• q1 // q2 returns each node which matches q2 starting at a descendant of a node which matches q1

• q1 [ q2 ] applies q2 to the children of the nodes which match q1

• q [ exp ] returns the nodes that match q and for children of which the expression exp evaluates to true

Example XPath Queries

investorID

Register

1234

requestList

AAAA BBBB

payment

accountNum

56

stockID stockID

//payment/* returns the node labeled accountNum/Register/requestList/stockID/string returns the nodes labeled AAAA and BBBB//stockID[string=AAAA]/string returns the node labeled AAAA//*[int>100]/int returns the node labeled 1234

WSDL (Web Services Description Language)

• WSDL is an XML-based language used to declare and publish the public interfaces of Web services

• With the WSDL description, the invoker of a particular web service can learn about – the web service location– the calls supported by the web service– the format of the messages to place a call

• WSDL uses XML Schema to define message types– Contents of the messages are XML documents

• WSDL specifications declare message ports– input ports, output ports etc.

WSDL Example: Declaring Message Types

<definitions targetNamesspace = "http://..." xmlns:broker = "http://.../broker/broker.xsd"><message name = "Register"> <part name = "investorID" type="xsd:int"/> <part name = "requestList" type ="broker:RequestList"> <part name = "payment" type="broker:Payment"></message><message name = "Accept"> <part name = "investorID" type="xsd:string"/> <part name = "registerID" type="xsd:int"/></message><message name = "Request"> <part name = "investorID" type="xsd:string"/> <part name = "registerID" type ="xsd:int"/> <part name = "stockID" type ="xsd:string"/></message>...

WSDL Example: Declaring Message Types

The following is a paragraph taken from broker.xsd used in the Register declaration in the previous slide

<xsd:schema xmlns:xsd = "http://.../XMLSchema">

<xsd:complexType name = "RequestList"> <xsd:element name = "stockid" type="string" minOccurs="1" maxOccurs="10"/> </xsd:complexType>

WSDL Example: Declaring Message Ports<portType name = "BrokerService"> <operation name = "register"> <input message = "Register"> </operation> <operation name = "cancel"> <input message = "Cancel"> </operation> <operation name = "ack"> <input message = “Ack"> </operation></portType>...<binding name = "brokerServiceBinding" type="BrokerService"> <soap:binding stype="document" /></binding><service name= "StockBroker"> <port name = "toInvestor" binding = "brokerServiceBinding"> <soap:address location="http://broker.com/register"/> </port></service>

<invoke> IBlink: register()

<On Message> IBlink: reject()

<On Message> IBlink: accept()

<receive> RIlink: report()

<invoke> IBlink: ack()

<invoke> IBlink: cancel()

<receive> RIlink: bill()

<receive> RIlink: bill()

Investor

reject()

accept()

bill()

Callback port

report()

Data port

<receive> IBlink: register()

<invoke> IBlink: reject()

<invoke> IBlink:

accept()<invoke> BRlink: request()

<receive> IBlink: ack()

<receive> IBlink: cancel()

<invoke> RIlink: bill()

<invoke> RIlink: bill()

Stock Broker Firm

register()

cancel()

Service Port

request()

Delegate Port

Service PortOutput PortRIlink BRlink

IBlink

<receive> BRlink: request()

<invoke> RIlink: report()

Research Dept.

ack()

Stock Analysis Service

BPEL (Business Process Execution Language)

• The simple function call model employed by WSDL makes it hard to capture long running complex composite web services such as the stock analysis service– the ordering between the calls can not be expressed in

WSDL

• The control flow (i.e., the behavior) of the peers of the stock analysis service can be specified using BPEL

BPEL: Partner Links

• In the BPEL specification, first a set of partner-links are declared– The partner links for the example in the stock analysis

service are named IBLink, BRLink and RLink• Each partner link connects a pair of port declared in the

WSDL specification• After the declaration of the partner links, BPEL specification

for each peer includes the control flow of the corresponding peer with the associated receive and send operations through the partner links and WSDL ports

BPEL: Partner Links

<process name = "StockBrokerFirm"><partnerlinks> <partnerlink name = "IBlink" ... /> <partnerlink name = "BRlink" ... /><partnerlinks><variables> <variable name = "registerVar" messageType = "Register"/> ...</variables>

BPEL: Control Flow

• BPEL borrows many control structures from common programming languages, such as – sequence, while, switch, etc.

• The atomic operations in BPEL are – invoke, receive, and reply

• used for sending and receiving messages; and– assign

• used for updating values of the variables.• Since assignments are conducted on complex type

variables (WSDL messages declared as XML Schema types), BPEL supports XPath expressions to identify the sources and the destinations of the assignment statements.

BPEL: Control Flow

<sequence> <receive partnerlink = "IBlink“ operation = "register“ variable = "registerVar"> </receive> <assign> <copy> <from variable = "registerVar“ part = "investorID"/> <to variable = "acceptVar“ query = "//investorID"/> </copy> </assign> <switch> <case condition = "opaque"> ... </case> ... <while condition = "bCond"> <invoke partnerlink = "BRlink" operation = "request“ variable = "requestVar" > </invoke> </while> ... </switch> ...</sequence>

Choreography with WS-CDL

• The BPEL specification for SAS specifies the service from the perspective of three different participants: Investor, Stock Broker and the Research Department

• A choreography specification specifies the interactions among all participants from a global perspective.

• WS-CDL is a language for specifying choreographies.

SAS Choreography Model

1

23

4

6

5

7 8

10

9

12 11

register

reject

terminate

accept

request

report ack

request

report

ackcancel

bill cancel

bill

terminate

• State machine representation of the SAS choreography model

Choreography with WS-CDL

• Web Services Choreography Description Language (WS-CDL)

• WS-CDL specifications describe ``peer-to-peer collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal.''

• A WS-CDL specification describes the interaction ordering among a set of peers using basic and structured activities– Basic activities: INTERACTION, PERFORM, ASSIGN, SILENT ACTION, NO ACTION

– Structured activities: SEQUENCE, PARALLEL, CHOICE, PICK, FLOW, SCOPE, COMPENSATE

Formal Modeling and Verification of Web services

• There has been a lot of work on modeling and verification of web services

• These efforts mostly focused on analyzing composite services specified using orchestration and choreography languages

• For example, can we formally model a given BPEL or WS-CDL specification and automatically verify its properties

• I will give an overview of some work on this area in the next lecture