Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 290C: Formal Models for Web Software Lectures 13: An Overview of Web Services Instructor: Tevfik Bultan.

Similar presentations


Presentation on theme: "CS 290C: Formal Models for Web Software Lectures 13: An Overview of Web Services Instructor: Tevfik Bultan."— Presentation transcript:

1 CS 290C: Formal Models for Web Software Lectures 13: An Overview of Web Services Instructor: Tevfik Bultan

2 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

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

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

5 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

6 Web Services Standards Stack Data Type Service Orchestration Protocol WS-BPEL Web Service Standards Implementation Platforms Microsoft.Net, Sun J2EE WSDL, UDDI SOAP XML Schema XML WS-CDL Choreography

7 What are Web Services? Web services can be described as –web accessible software that provide interfaces for service description, discovery, and interaction

8 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

9 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

10 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

11 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 Register Search Request Response

12 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 Register Search Request Response SOAP WSDL UDDI

13 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

14 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

15 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

16 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

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

18 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

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

20 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

21 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) Atomic Service Atomic Service Orchestrated Service SOAP WSDL Choreography Web Services Choreography Description Language (WS-CDL) WS-BPEL Orchestrated Service WS-BPEL SOAP WS-CDL

22 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

23 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

24 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

25 IBlink: register() IBlink: reject() IBlink: accept() RIlink: report() IBlink: ack() IBlink: cancel() RIlink: bill() Investor reject() accept() bill() Callback port report() Data port IBlink: register() IBlink: reject() IBlink: accept() BRlink: request() IBlink: ack() IBlink: cancel() RIlink: bill() Stock Broker Firm register() cancel() Service Port request() Delegate Port Service PortOutput Port RIlinkBRlink IBlink BRlink: request() RIlink: report() Research Dept. ack() Stock Analysis Service

26 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

27 XML (eXtensible Markup Language) XML is a markup language like HTML Similar to HTML, XML tags are written as followed by HTML vs. XML –In HTML, tags are used to describe the appearance of the data... –In XML, tags are used to describe the content of the data rather than the appearance XML documents can be modeled as trees where each internal node corresponds to a tag and leaf nodes correspond to basic types

28 investorID Register 1234 requestList AAAABBBB payment accountNum 56 stockID An XML Document and Its Tree 1234 AAAA BBBB 56

29 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

30 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

31 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 g 1, g 2 denotes an ordered sequence where the first member is of type g 1 and the second member is of type g 2 g 1 & g 2 denotes an unordered sequence where one member is of type g 1 and the other member is of type g 2 g | g denotes a choice between type g 1 and type g 2, i.e., either type g 1 or type g 2, but not both

32 An MSL Type Declaration and an Instance Register[ investorID[xsd:int] & requestList[ stockID[xsd:string]{1,50} ] & payment[ creditCardNum[xsd:int] | accountNum[xsd:int] ] 1234 AAAA BBBB 56

33 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 AAAABBBB payment accountNum 56 stockID

34 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

35 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

36 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

37 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 q 1 / q 2 returns each node which matches q 2 starting at a child of a node which matches q 1 q 1 // q 2 returns each node which matches q 2 starting at a descendant of a node which matches q 1 q 1 [ q 2 ] applies q 2 to the children of the nodes which match q 1 q [ exp ] returns the nodes that match q and for children of which the expression exp evaluates to true

38 Example XPath Queries investorID Register 1234 requestList AAAABBBB payment accountNum 56 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

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

40 WSDL Example: Declaring Message Types <definitions targetNamesspace = "http://..." xmlns:broker = "http://.../broker/broker.xsd">...

41 WSDL Example: Declaring Message Types The following is a paragraph taken from broker.xsd used in the Register declaration in the previous slide <xsd:element name = "stockid" type="string" minOccurs="1" maxOccurs="10"/>

42 WSDL Example: Declaring Message Ports...

43 IBlink: register() IBlink: reject() IBlink: accept() RIlink: report() IBlink: ack() IBlink: cancel() RIlink: bill() Investor reject() accept() bill() Callback port report() Data port IBlink: register() IBlink: reject() IBlink: accept() BRlink: request() IBlink: ack() IBlink: cancel() RIlink: bill() Stock Broker Firm register() cancel() Service Port request() Delegate Port Service PortOutput Port RIlinkBRlink IBlink BRlink: request() RIlink: report() Research Dept. ack() Stock Analysis Service

44 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

45 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

46 BPEL: Partner Links <variable name = "registerVar" messageType = "Register"/>...

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

48 BPEL: Control Flow <receive partnerlink = "IBlink“ operation = "register“ variable = "registerVar">...... <invoke partnerlink = "BRlink" operation = "request“ variable = "requestVar" >......

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

50 SAS Choreography Model 1 23 4 6 5 78 10 9 1211 register reject terminate accept request reportack request report ack cancel billcancel bill terminate State machine representation of the SAS choreography model

51 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

52 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


Download ppt "CS 290C: Formal Models for Web Software Lectures 13: An Overview of Web Services Instructor: Tevfik Bultan."

Similar presentations


Ads by Google