Distributed systems

Lecture Seven:
Web Services

2016 Computer Science

Introduction
 A web service provides a service interface enabling
clients to interact with servers in a more general
way than web browsers do
 Clients access the operations in the interface of a
web service by means of requests and replies
formatted in XML and usually transmitted over HTTP
 Users require a secure means for creating, storing
and modifying documents and exchanging them
over the Internet
 The secure channels of TLS do not provide all of the
necessary requirements
 XML security is intended to breach this gap
 Web services provide an infrastructure for
Introduction
 They provide a basis whereby a client program in one
organization may interact with a server in another organization
without human supervision
 External data representation and marshalling of messages
exchanged between clients and web services is done in XML.
 he SOAP (Simple Object Access Protocol) specifies the rules for
using XML to package messages, for example to support a
request-reply protocol
 Web Services
 One of the dominant paradigms for programming distributed systems
 Enables business to business integration. (Suppose one organization
uses CORBA and another uses .NET) No problem!
 Enables service oriented architecture (SOA).
 Adopted by the grid computing community.
 May exist internally to an organization or externally (in the cloud).
Introduction
 What are Web Services?
 Web Services began life when Bill Gates introduced
BizTalk in 1999.
 BizTalk was later renamed .NET.
 The idea: “to provide the technologies to allow
software in different places, written in different
languages and resident on different platforms to
connect and interoperate.” From “Programming the
World Wide” by Sebesta
 Two approaches
 SOAP Based (WS-*) Web Services
 REST style web services
Web Services: SOAP based Web services

 SOAP Style Web Services

 Provide service interfaces
 Communicate using request and reply
messages made of SOAP or some other
XML document
Web Services: SOAP based Web services

 Have an Interface Definition Language

(IDL) called WSDL (Web Service
Definition Language)
 May be looked up in a web service UDDI
registry
 UDDI (Universal Directory and Discovery
Service)
 Are language independent
 May be synchronous or asynchronous
Web Services: SOAP based Web services
Web Services: SOAP based Web services

 Communication Patterns
 In general, web services use either a synchronous
request-reply pattern of communication with their
clients or they communicate by asynchronous
messages.
 To allow for a variety of patterns, SOAP is based on
the packaging of single one-way messages.
 SOAP is used to hold RPC style parameters or
entire documents.
 Originally, SOAP was based on HTTP, but the
current version may be used over different
transport protocols (SMTP, TCP, UDP, or HTTP)
 Web Services: SOAP based Web services

 Service References
 URI’s – Uniform Resource Identifiers
 URL’s – Uniform Resource Locator URI’s that include
location information
 resources pointed to by URL’s are hard to move

 URN’s – Uniform Resource Name

URI’s that include no location information

 A URN lookup service may be used to determine a URL

from a URN
 URL’s are the most frequently used form of URI
Web Services: SOAP based Web services

 Web Service Composition (Mashups)

 What concerns are not shown? This is an important
list: Transactions, Security (privacy, identification,
authentication, authorization), Reliability,
Orchestration tooling, Interoperability through
Standards, RPC or Messaging, Service Level
agreements
Web Services: SOAP based Web services

SOAP (Simple Object Access Protocol)

defines a scheme for using XML to represent the contents
of request and reply messages as well as a scheme for the
communication of documents
 The SOAP specification states:
 How XML is to be used to represent the contents of
individual messages
 How a pair of single messages can be combined to
produce a request-reply pattern
 The rules as to how the recipients of messages should
process the XML elements that they contain
 How HTTP and SMTP should be used to communicate
SOAP messages
 A SOAP message is carried in an “envelope”
Inside the envelope there is an optional header and a body
Web Services: SOAP based Web services

 Message headers can be used for establishing the necessary

context for a service or for keeping a log or audit of operations
 The message body carries an XML document for a particular
web service
 The XML elements envelope, header and body, together with
other attributes and elements of SOAP messages are defined
as a scheme in the SOAP XML namespace
Web Services: SOAP based Web services

 A transport protocol is required to send a SOAP

document to its destination
 Other transports may be used
 WS-Addressing may be used to include destination and
source
 Thus, different protocols might be used over different

parts of the route of a message

WS-ReliableMessaging: Reliable communication
 SOAP’s usual protocol – TCP
 TCP does not guarantee message delivery in certain
situations
 timeout waiting for acknowledgement – declares the connection is
broken – the actual delivery of the information becomes unknown
Web Services: SOAP based Web services

 Oasis (a global consortium that works on the development,

agreement and adoption of e-business and web service
standards) has made a recommendation called
 WS-Reliable Messaging [[Link]]
allows a SOAP message to be delivered at-least-once, at-most-once
or exactly-once ( – different from that in RPC number of times
server executes a remote procedure)
 At-least-once: The message is delivered at least once, but an error is
reported if it cannot be delivered
 At-most-once: The message is delivered at most once, but without any
error report if it cannot be delivered
 Exactly-once: The message is delivered exactly once, but an error is
reported if it cannot be delivered
– Ordering of messages is also provided in combination with any of the
above:
 In-order: Messages will be delivered to the destination in the order in which
they were sent by a particular sender
Web Services: SOAP based Web services

Servlet container
 The service implementation is run as a servlet inside a servlet
container whose role is to load, initialize and execute servlets
 The servlet container includes a dispatcher and skeletons
 when a request arrives, the dispatcher maps it to a particular skeleton,
which translates it into Java and passes on the request to the appropriate
method in the servlet
 That method carries out the request and produces a reply, which the
skeleton translates back into a SOAP reply
 The URL of a service consists of a concatenation of the URL of the servlet
container and the service category and name
 e.g, [Link]
 Tomcat [[Link]] is a commonly used servlet container The
client program
 may use static proxies (generated at compile time, example below),
dynamic proxies or dynamic invocation interface
Web Services: SOAP based Web services

The client program

 • may use static proxies (generated at compile time, example below), dynamic
proxies or dynamic invocation interface
 Dynamic proxies: dynamic proxy class is created at runtime from the
information in the service description and the interface of the service
 • avoids the need for involving an implementation-specific name for the proxy
class
 Dynamic invocation interface: allows a client to call a remote procedure,
even if its signature or the name of the service is unknown until runtime
 the client does not require a proxy. Instead, it has to use a series of operations to
set the name of the server operation, the return value and each of the
parameters before making the procedure call
Service descriptions
 The primary means of describing a web service is by using WSDL (the Web
Services Description Language)
 XML Schema may be used to describe the input and output parameters
 WSDL describes the operations and makes use of XML Schema to describe an
exchange of messages
Web Services: SOAP based Web services

 A Service Description (WSDL document) is an IDL

(interface definition language) + it contains
information on how and where the service may
be accessed
 It contains an abstract part and a concrete part
 The abstract part is most like a traditional interface
 The concrete part tells us how and where to access the
service
 A binding is a choice of protocols
 A service holds an endpoint address
Web Services: SOAP based Web services

 Client or server side code may be generated automatically from the

WSDL
 A WSDL document may be accessed directly or indirectly through a
registry like UDDI (Universal Directory and Discovery Service)
 A message exchange is called an operation
 Related operations are grouped into interfaces
 A binding specifies concrete details about what goes on the wire
 WSDL is an Interface Definition Language (IDL)
 WSDL
 Describes the contract between applications
 Can be automatically generated from a collection of Java or C# classes
 Can be read by utilities that generate client side proxy code or server side
 skeletons
Web Services: SOAP based Web services

WS Directory Service
 Universal Description, Discovery and

Integration service (UDDI)

Web Services: SOAP based Web services

XML security
 Signing and encrypting
Web Services: SOAP based Web services

Coordination of web services

 Web services choreography
Requirements:
 hierarchical and recursive composition of choreographies
 the ability to add new instances of an existing service and new services
 concurrent paths, alternative paths and the ability to repeat a section of
a choreography
 variable timeouts – for example, different periods for holding
reservations
 exceptions, for example, to deal with messages arriving out of sequence
and user actions such as cancellations
 asynchronous interactions (callbacks)
 reference passing, for example, to allow a car hire company to consult a
bank for a credit check on behalf of a user
 marking of the boundaries of the separate transactions that take place, for
example, to allow for recovery
 the ability to include human-readable documentation
Web Services: SOAP based Web services

Applications of web services

 Service-oriented architectures (SOA)
 The Grid
 Cloud computing
Web Services: SOAP based Web services
Web Services: REST based Web
services
What is REST ?

REST is a term coined by Roy Fielding to describe

an architecture style of networked systems. REST is
an acronym standing for Representational State
Transfer.
Web Services: REST based Web services
Rest – An architectural Style

Elements
 Components – Proxy , gateway etc
 Connectors – client , server etc
 Data – resource , representation etc

REST
 Ignores component implementation details.
 Focus on roles of components, their interactions and their
interpretation of data elements.
Web Services: REST based Web services
Rest – An architectural Style

 Resource
 URI-Uniform Resource
Identifier (or URL)

 Web Page (HTML

Page)
Web Services: REST based Web services
Rest – An architectural Style

"Representational State Transfer is intended to evoke an

image of how a well-designed Web application behaves: a
network of web pages (a virtual state-machine), where the
user progresses through an application by selecting links
(state transitions), resulting in the next page (representing
the next state of the application) being transferred to the
user and rendered for their use."
Roy Fielding.
Web Services: REST based Web services
Rest – An architectural Style

REST - An Architectural Style of Networked System

 Underlying Architectural model of the world wide web.

 Guiding framework for Web protocol standards.

REST based web services

 Online shopping
 Search services
 Dictionary services
Web Services: REST based Web services
Rest – An architectural Style
REST way of Implementing the web services
 Service – Get parts list

The web service makes available a URL to a parts list resource

Client uses : [Link]

Document Client receives :

<?xml version="1.0"?>
<p:Parts xmlns:p="[Link] xmlns:xlink="[Link]
<Part id="00345" xlink:href="[Link]
<Part id="00346" xlink:href="[Link]
<Part id="00347" xlink:href="[Link]
<Part id="00348" xlink:href="[Link]
</p:Parts>
 Service – Get detailed part data

The web service makes available a URL to each part resource.

Client uses : [Link]

Document Client receives :

<?xml version="1.0"?>
<p:Part xmlns:p="[Link] xmlns:xlink="[Link]
<Part-ID>00345</Part-ID>
<Name>Widget-A</Name>
<Description>This part is used within the frap assembly</Description>
<Specification xlink:href="[Link] <UnitCost
currency="USD">0.10</UnitCost>
<Quantity>10</Quantity>
</p:Part>
 Service – Submit purchase order (PO)

The web service makes

available a URL to submit a PO. 1)The client creates a PO instance
document ([Link])

2)Submits the [Link](HTTP POST

3)PO service reponds with a URL

to the submitted PO.
Characteristics of a REST based network

 Client-Server: a pull-based interaction style(Client request

data from servers as and when needed).
 Stateless: each request from client to server must contain all
the information necessary to understand the request, and
cannot take advantage of any stored context on the server.
 Cache: to improve network efficiency, responses must be
capable of being labeled as cacheable or non-cacheable.
 Uniform interface: all resources are accessed with a generic
interface (e.g., HTTP GET, POST, PUT, DELETE).
 Named resources - the system is comprised of resources
which are named using a URL.
 Interconnected resource representations - the representations
of the resources are interconnected using URLs, thereby
enabling a client to progress from one state to another.
 Principles of REST web service design

1. Identify all the conceptual entities that we wish to expose as services.

(Examples we saw include resources such as : parts list, detailed part data,
purchase order)
2. Create a URL to each resource.
3. Categorize our resources according to whether clients can just receive a
representation of the resource (using an HTTP GET), or whether clients can
modify (add to) the resource using HTTP POST, PUT, and/or DELETE).
4. All resources accessible via HTTP GET should be side-effect free. That is, the
resource should just return a representation of the resource. Invoking the
resource should not result in modifying the resource.
5. Put hyperlinks within resource representations to enable clients to drill down
for more information, and/or to obtain related information.
6. Design to reveal data gradually. Don't reveal everything in a single response
document. Provide hyperlinks to obtain more details.
7. Specify the format of response data using a schema (DTD, W3C Schema,
RelaxNG, or Schematron). For those services that require a POST or PUT to
it, also provide a schema to specify the format of the response.
8. Describe how our services are to be invoked using either a WSDL document,
or simply an HTML document.