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 Question
Can we extend the interaction and sharing that WWW
created among humans to
interaction 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
WS-CDL
Orchestration
WS-BPEL
Service
WSDL, UDDI
Protocol
SOAP
Type
XML Schema
Data
XML
Web Service
Standards
Implementation
Platforms
Choreography
Microsoft .Net, Sun J2EE
Web Services Standards Stack
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
Broker
Search
Register
Request
Service
Provider
Service
Requester
Response
Web Services Standards Stack
Registry
Universal Description, Discovery & Integration (UDDI)
Service
Web Services Description Language (WSDL)
Protocol
Simple Object Access Protocol (SOAP)
Type
XML Schema (XSD)
Data
Extensible Markup Language (XML)
Service
Broker
UDDI
Register
Search
WSDL
WSDL
Request
Service
Requester
SOAP
Response
Service
Provider
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
WSDL
Request
Service
Requester
Client
SOAP
Response
Service
Provider
Server
• 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
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 (WSBPEL) 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,
multi-threading (FLOW)
REPLY, INVOKE)
and
Choreography with WS-CDL
• Web Services Choreography Description Language (WSCDL)
• 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
Choreography
Web Services Choreography Description Language (WS-CDL)
Orchestration
Service
Web Services Business Process Execution Language (WS-BPEL)
Web Services Description Language (WSDL)
Simple Object Access Protocol (SOAP)
Protocol
Type
XML Schema (XSD)
Extensible Markup Language (XML)
Data
WSDL
WS-BPEL
SOAP
Atomic
Service
Orchestrated
Service
SOAP
SOAP
WS-CDL
WS-BPEL
Orchestrated
Service
WSDL
SOAP
SOAP
Atomic
Service
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)
• SAS is a composite service that contains three individual
services
Investor
(Inv)
report
register
ack, cancel
Stock Broker
(SB)
accept,
reject, bill
request,
terminate
Research Dept.
(RD)
Stock Analysis Service
Investor
Stock Broker Firm
<invoke>
IBlink: register()
<On Message>
IBlink: accept()
<invoke>
IBlink: ack()
<receive>
RIlink: report()
<receive>
IBlink: register()
Callback
port
<On Message>
IBlink: reject()
reject()
Service
Port
IBlink
register()
<invoke>
IBlink: accept()
<invoke>
IBlink: reject()
accept()
cancel()
<receive>
RIlink: bill()
bill()
ack()
<invoke>
IBlink: cancel()
<invoke>
RIlink: bill()
<invoke>
BRlink: request()
<receive>
IBlink: ack()
<receive>
IBlink: cancel()
<invoke>
RIlink: bill()
<receive>
RIlink: bill()
Delegate Port
Data port
report()
Research Dept.
RIlink
Output Port
<receive>
BRlink: request()
<invoke>
RIlink: report()
BRlink
Service Port
request()
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
An XML Document and Its Tree
<Register>
<investorID>
1234
</investorID>
<requestList>
<stockID>
AAAA
</stockID>
<stockID>
BBBB
</stockID>
</requestList>
<payment>
<accountNum>
56
</accountNum>
</payment>
</Register>
Register
investorID
1234
requestList
payment
stockID stockID accountNum
AAAA
BBBB
56
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
payment
stockID stockID accountNum
AAAA
BBBB
56
MSL can also be used
as a compact language
for specifying data instances
Register[
investorID[1234] &
requestList[ stockID[AAAA] , stockID[BBBB] ] &
payment[ accountNum[56] ]
]
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
Register
investorID
1234
requestList
payment
stockID stockID accountNum
AAAA
BBBB
56
//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>
Stock Analysis Service
Investor
Stock Broker Firm
<invoke>
IBlink: register()
<On Message>
IBlink: accept()
<invoke>
IBlink: ack()
<receive>
RIlink: report()
<receive>
IBlink: register()
Callback
port
<On Message>
IBlink: reject()
reject()
Service
Port
IBlink
register()
<invoke>
IBlink: accept()
<invoke>
IBlink: reject()
accept()
cancel()
<receive>
RIlink: bill()
bill()
ack()
<invoke>
IBlink: cancel()
<invoke>
RIlink: bill()
<invoke>
BRlink: request()
<receive>
IBlink: ack()
<receive>
IBlink: cancel()
<invoke>
RIlink: bill()
<receive>
RIlink: bill()
Delegate Port
Data port
report()
Research Dept.
RIlink
Output Port
<receive>
BRlink: request()
<invoke>
RIlink: report()
BRlink
Service Port
request()
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
• State machine representation of the SAS choreography
model
1
3
6
register
request
reject
accept
2
report
7
cancel
ack
8
request
5
9
report
terminate
4
12
terminate
bill
11
cancel
10
ack
Choreography with WS-CDL
• Web Services Choreography Description Language (WSCDL)
• 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 WSCDL specification and automatically verify its properties
• I will give an overview of some work on this area in the next
lecture