OOTI course Distributed Systems

Transcription

1 OOTI course Distributed Systems 2013, Sep. 26 Oct 01 Lecture 4: Web Services

2 Agenda Introduction Motivation Definition Architectural styles Naming: URIs Web services technologies Orchestration Replication R.H. Mak PAGE 1

3 Motivation The desire for an open distributed system Interoperability and portability on a global scale, i.e., across the Internet on arbitrary hardware and software platforms at multiple quality levels Extendibility with new resources and services with contributions from various vendors/ developers R.H. Mak PAGE 2

4 Basic organization of the Web Many variations on this scheme, e.g., Client-side caching Clusters of servers Multiple-tiers No indication how the client discovers the service! R.H. Mak PAGE 3

5 Layers and client / server functionality 3-layer organization of data access: cuts possible at many places cuts define tiers (a,b) thin client changing control the user interface has small overhead; it typically runs on a machine that is a client to the application server however, after connection, the user interface becomes a server for the application (c,d) thick client (e) file server J.J. Lukkien PAGE 4

6 Combining layering and C/S in a distributed fashion Development (logical): layering ( presentation, business and data tier (layer) ) Deployment: Client-Server interactions between the components also called: multi-tier client-server organization note: middle layer plays both client and server roles that is actually what layering + request/reply is J.J. Lukkien PAGE 5

7 Web service A Web service is nothing but a traditional service that is made available over the Internet. (quote from TvS) Adheres to a collection of standards that allow it to be discovered and accessed over the Internet by client applications that adhere to those standards Can be composed of more elementary services. The cooperation of elementary services that constitute a complex service need to be coordinated Service oriented architectures organize the application s services plus services needed for discovery, coordination (and many more) into a distributed system. R.H. Mak PAGE 6

8 Service a unit of functionality coarse-grained, e.g., stock market ticker, not a mathematical function like the sinus. accessed via a well-defined interface delivered at a well-defined quality level Agreed upon by server provider and consumer in a service level agreement (SLA) A service is a logical concept. A service is realized by a component. Components that provide the same service can (will) differ in their nonfunctional properties depending on their vendor/developer. R.H. Mak PAGE 7

9 Service oriented (SOA) style Motivation: Separate functionality ( service ), the implementation, the deployment context and the application context Build applications by very late (dynamic) binding Integration of enterprise information systems Structure (conceptual): Vocabulary SOA, service, interface, discovery, composition, binding, orchestration, choreography Rules Application is built ad-hoc out of services that communicate in a standardized manner via a network see e.g. REST Service is a self-contained functionality. It does not depend on state of other services, or of the system (OS, language) it is running on. Services are discoverable Typical behavior Providers publish services; Applications ( orchestrations ) discover services, and bind their interfaces Service broker (registry) can exist to manage discovery process Applications send data objects through a number of services as a work flow Often XML based RPC (SOAP) Services are typically kept simple and focused on single task Note: SOA is a huge research domain in business information systems J.J. Lukkien PAGE 8

10 Enterprise application organization J.J. Lukkien PAGE 9

11 RESTful Web service A RESTful Web service is a Web service that is resource-oriented, i.e., organized as a set of resources Documents of various types are served to clients (similar to WWW) Not only static documents, but also dynamically generated upon request Resources may have multiple representations (e.g. in English and Chinese) Format for representations is free, although XML is popular in which all operations on resources are cast in the form of a CRUDoperation (create, read, update, delete) HTTP-messages (GET,PUT,POST,DELETE) are used to specify those operations; URLs both specify the (location of) the resource and parameters for the operation; often a HTTP message consist of a header only, thus creating a light-weight protocol with a uniform interface e.g. GET to obtain a list of bookmarks, instead of a RPC getmybookmarks(webservices) R.H. Mak PAGE 10

12 RESTful Web service that is stateless; servers do not maintain application state, i.e., information from previous interactions with a client, hence the client must supply this information in successive operations of course, servers maintain resource state, in the form of representations that supports client-side caching Through HTTP cache control mechanisms that support code on demand Servers may send code necessary to execute other representations they have sent Usually JAVAscript R.H. Mak PAGE 11

13 REST: REpresentational State Transfer Motivation: special usage of C&S aiming at portability independent development & deployment reduction of interaction complexity reliability scalability Vocabulary user agent, origin server, gateway, proxy cache, layer state code-on-demand resource, resource identifier (e.g. URL), representation, metadata Rules stateless communication (no server state) response is labeled as cache-able, and can then be cached uniform interface between components decouples structure from functionality layering client functionality can be adapted by code-ondemand Structure (model in the process view from R. Fielding, Architectural Styles and the Design of Network-based Software Architectures) Typical behavior as (layered) C&S, but only a single service (interface) Prime example: WWW PAGE 12

14 Recap: naming on the Web By means of Uniform Resource Identifiers (URIs) either a URL(ocator) or a URN(ame);on the Web mostly URLs Recap question: How are these Names resolved? Often-used structures for URLs. a) Using only a DNS name. b) Combining a DNS name with a port number. c) combining an IP address with a port number. R.H. Mak PAGE 13

15 Agenda Introduction Web services technologies SOAP WSDL, WADL UPnP Orchestration Replication R.H. Mak PAGE 14

16 Messages use carrier protocols EXAMPLE? R.H. Mak PAGE 15

17 Messages use carrier protocols On the Web, HTTP serves as the bottle. R.H. Mak PAGE 16

18 SOAP message in an envelope envelope header header element header element body body element body element Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012 R.H. Mak PAGE 17

19 Example: simple request without headers env:envelope xmlns:env =namespace URI for SOAP envelopes env:body m:exchange xmlns:m = namespace URI of the service description m:arg1 Hello m:arg2 World In this figure and the next, each XML element is represented by a shaded box with its name in italic followed by any attributes and its content Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012 R.H. Mak PAGE 18

20 Example: reply corresponding to the request env:envelope env:body xmlns:env = namespace URI for SOAP envelope m:exchangeresponse xmlns:m = namespace URI for the service description m:res1 World m:res2 Hello Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012 R.H. Mak PAGE 19

21 Example: Soap request in xml format POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> SOAP = HTTP + XML Notice: No header Taken from R.H. Mak PAGE 20

22 Example: SOAP response HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> </m:getstockpriceresponse> </soap:body> </soap:envelope> R.H. Mak PAGE 21

23 Example: SOAP response HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> </m:getstockpriceresponse> </soap:body> </soap:envelope> Taken from R.H. Mak PAGE 22

24 Web service description Defines the service the interface (functionality) the location and the communication protocols used URI, HTTP, SOAP,,XML, machine readable format WSDL Is stored in a repository and made available through a directory service UDDI for Web services Facilitates the development of clients and servers Through automatic generation of stubs stubs for RPC R.H. Mak PAGE 23

25 Web-service model R.H. Mak PAGE 24

26 WSDL: document structure <definitions> The abstract part of the service description <types> definition of types... </types> The target namespace: complex data structures specified using XML <message> definition of a message... </message> <porttype> <operation> definition of a operation... </operation> </porttype>.. R.H. Mak PAGE 25 Messages associated with operations Containing parameter list or result list The service interface for each operation its messages and their types (in, out) are listed

27 WSDL: document structure (cntd) The concrete part of the service description.. <binding> definition of a binding... </binding> <service> definition of a service... </service> The protocol used Message format Data representation How the service is exposed Endpoint Binding </definitions> R.H. Mak PAGE 26

28 WSDL example: message and porttype element <message name="gettermrequest"> <part name="term" type="xs:string"/> </message> <message name="gettermresponse"> <part name="value" type="xs:string"/> </message> <porttype name="glossaryterms"> <operation name="getterm"> <input message="gettermrequest"/> <output message="gettermresponse"/> </operation> </porttype> R.H. Mak PAGE 27

29 WSDL example: binding element <binding name="hello_binding" type="tns:hello_porttype"> <soap:binding style="rpc transport=" <operation name="sayhello"> <soap:operation soapaction="sayhello"/> <input> <soap:body encodingstyle= namespace="urn:examples:helloservice" use="encoded /> </input> <output> <soap:body /> </output> </operation> </binding> R.H. Mak PAGE 28

30 WSDL example: service element <service name="hello_service"> <documentation>wsdl File for HelloService </documentation> <port binding="tns:hello_binding" name="hello_port"> <soap:address location=" </port> </service> R.H. Mak PAGE 29

31 WSDL message exchange patterns Name Messages sent by Client Server Delivery Fault message In-Out Request Reply may replace Reply In-Only Request no fault message Robust In-Only Out-In Request guaranteed may be sent Reply Request may replace Reply Out-Only Request no fault message Robust Out-Only Request guaranteed may send fault Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012 R.H. Mak PAGE 30

32 WADL Web Application Description language Suitable to describe ReSTful Web services Definition and examples on following slides taken from Not a formal W3C standard This document does not mention ReST, but refers to HTTP-based applications that provide programmatic access to their internal data A similar description language is the Atom Publishing Protocol more dedicated, however, to a specific application domain R.H. Mak PAGE 31

33 WADL: document structure <application> <grammars> definitions of data formats [optional] </grammars> <resources base= > specifies the base URI defines a list of resources <resource> definition of an individual resource </resource> </resources> </application> R.H. Mak PAGE 32

34 WADL example: resources element <resources base=" <resource path="widgets"> <resource path="reports/stock"> <param name="instockonly" style="matrix" 5 type="xsd:boolean"/>... </resource> <resource path="{widgetid}"> </resource> </resource> <resource path="accounts/{accountid}">... </resource> </resources> R.H. Mak PAGE 33

35 WADL example: resources element The <resources> element on the previous slide describes A resource identified by a static URI: A resource identified by a static URI: A resource identified by a matrix URI: Multiple resources identified by generative URIs: where widgetid is replaced at runtime with the value of a runtime parameter called widgetid. Multiple resources identified by generative URIs: where R.H. Mak PAGE 34

36 RESTful query using HTTP GET <resources base=" <resource path="{widgetid}"> <param name="customerid" style="query"/> <method name="get"> <request> <param name="verbose" style="query" type="xsd:boolean"/> </request> <response>... </response> </method> </resource> </resources> R.H. Mak PAGE 35 global for all methods of this resource local to the GET method correspondence parameter value widgetid customerid cust134 Verbose true

37 Example: query to determine the response mediatype <method name="get"> <request> <param name="format" style="query"> <option value="xml" mediatype="application/xml"/> <option value="json" mediatype="application/json"/> </param>... </request> <response> <representation mediatype="application/xml"/> <representation mediatype="application/json"/> </response> </method> R.H. Mak PAGE 36

38 Agenda Introduction Web services technologies Orchestration Replication R.H. Mak PAGE 37

39 Orchestration and choreography Orchestration Pertains to lifecycle management of a (service-oriented) application Requires active party (the orchestrator) to control that lifecycle Instantiation, binding, activation, monitoring, (re)-configuration, Implement policies Choreography Pattern of service interaction resulting from a set of rules (or the set of rules itself Occurs spontaneously, between services themselves only the rules are provided For a discussion see: R.H. Mak PAGE 38

40 Example: FLUENT framework Host 3 Device manager Resource manager Orchestrator 2 Orchestrator 1 Component Repository Device manager Device manager Host 2 Component 4 Component 5 Component 2 Component 1 Component 3 Host 1 Example taken from: R.H. Mak, Resource-aware Life Cycle Models for Service-oriented Application managed by a component Framework R.H. Mak PAGE 39

41 Exampe: FLUENT Life Cycle [deploy] [redeploy] [otherwise] install components (2) (Re-)Design (Re-)Deployment Operation allocate hosts assign modes reserve resources [success] [all installed] (1) (2) instantiate components [non-feasible] (3) [stop] [redesign] bind interfaces (4) [new design] [redesign] failure redesign operate [recompose] compose application [recompose] (1) [stop] [partial] allocate component types (2) [total] [reallocate] recover error [operate] activate components Adapt QoS deactivate affected components (1) [all activated] [otherwise] define reconfiguration strategies define location constraints (3) define resource constraints deactivate affected components [non fatal] [fatal] execute [control cmd] [error] [other error] [resource conflict] renegotiate resource reservations determine Recovery Mechanism [RM 1 applies] [RM 1or 2 applies] [otherwise] [finish] [otherwise] [RM 3 applies] deallocate affected components failure deploy failure redesign redeploy R.H. Mak PAGE 40

42 Example: Service oriented virtual community R.H. Mak PAGE 41

43 Example: Service oriented virtual community Example taken from: Shudong Chen, J.J. Lukkien, A service-oriented virtual community overlay network for secure external service orchestration R.H. Mak PAGE 42

44 Agenda Introduction Web services technologies Orchestration Replication R.H. Mak PAGE 43

45 Server clusters R.H. Mak PAGE 44

46 Server clusters (TCP-hand-offf) Web server uses IP-spoofing Selection of webserver by FE based on server load, not on content of the request R.H. Mak PAGE 45

47 Server clusters R.H. Mak PAGE 46

48 Client-side caching / proxy servers Origin server R.H. Mak PAGE 47

49 Squirrel webcache Local caches in web browsers of clients in a single LAN are used to implement a distributed LAN-based webserver proxy. Can handle corporate networks from ,000 nodes or more. Alternative for (a cluster of) web-proxy servers Uses a peer-to-peer architecture (overlay) on the LAN Built on top of Pastry, but any P2P routing overlay will do. Inserts a squirrel proxy between the browser and the local web cache. Uses HTTP conditional GET Scales horizontally and automatically As the number of browsers increases so does the cache capacity, whereas cache response time stays almost constant. No administrative effort required. R.H. Mak PAGE 48

50 Home-store scheme Sitaram lyer, Antony Rowstron, and Peter Druschel, Squirrel: A decentralized peer-to-peer web cache R.H. Mak PAGE 49

51 Directory scheme R.H. Mak PAGE 50