Web Services
Need for web services


JEE provides a component based approach to
development of n-tier applications
Limitations

Primarily designed for Java


Not web centric distribution


Does not directly address inter-language integration
Uses Java specific mechanisms for inter-component
integration
Not supported by all major vendors (i.e. Microsoft)
2
Web Services

Two approaches

‘SOAP’ Web Services: The original and most often meant by
term Web Services



In this module, web services = ‘SOAP’ web services
‘RESTful’ Web Services: Increasing popular due to simplicity of
approach
REST versus SOAP is a subject of a continuing ‘religious
war’

Caution: Need to check terminology being used when referring
to Web Services
3
Web Services: Definitions

W3C: “A software system designed to support interoperable
machine-to-machine interaction over a network.”


While W3C does refer to both SOAP and REST based web services,
most of their definitions relate to SOAP based web services
SOAP Web Service definitions


A Web service is a collection of functions that are packaged as a
single entity and published to the network for use by other programs.
Web Service standards form a platform-independent, open framework
for describing services, discovering businesses, and integrating
business services.
4
SOAP based Web Services in 1
slide

A distributed architecture


Platform neutral


Does not include component model
Access through platform specific development kits
Based on internet standards

XML, http etc
5
eXtensible Markup Language

A common data format derived from SGML


Language independent, hierarchical and self-describing
Uses tag-based structure similar to HTML to define XML
documents
<?xml version="1.0" encoding="ISO-8859-1" ?>
<bankaccount type=“Current”>
<name>John Smith</name>
<address>
<line 1>1 Grafton Street </line1>
<line 2>Dublin 2, Ireland </line2>
</address>
</bankaccount>


Supports arbitrarily complex data formats
Schema (defined in xsd files) can be used to define document
formats

Fragment defining a BankAccount as a type of financial record
<xsd:element name="purchaseOrder" type="PurchaseOrderType"/>
6
eXtensible Markup Language

Independent of IT infrastructure


Separates the what from the how
Many industry based schema standards have been developed
 For example, Financial Services:



ISO15022 (SWIFT, FIX, FpML)
XBRL (business reporting)
Any XML based infrastructure can handle multiple and
evolving schema standards without excessive cost



Due to changes in business relationships
Due to regulatory changes (e.g. Basil II)
Due to evolution of the schemas themselves
7
The Web Services architecture

UDDI
Registry
2. Request contract information
3. Retrieve WSDL definition
Service
Consumer
WSDL
WSDL


Web Services define
 Service provider: “server” supporting the
interface
 Service consumer: “client” making
requests
Web Services is based on three standards
Simple Object Access Protocol (SOAP)


4. Exchange SOAP messages
Service
Provider
Universal Directory Discovery Interface
(UDDI)


defines the registry of interface definitions
Web Service Definition Language (WSDL)

1. Register contract information
defines the communication mechanism
defines the actual interfaces
8
Web Services Model
Consumer-Side
invokes
Client
code
return
results
Network
connect to remote
service
Provider Side
SOAP runtime
library
invoke
Stub
Server-Side
code
return
results
return
results
Stub is auto-generated from the WSDL during development
The server side received the call (invocation) through the SOAP runtime
9
library
SOAP- Simple Object Access
Protocol

XML based protocol for
exchange of information




Used with XML Schema
Normally HTTP-based


Uses Request/Response
SOAP
Envelope
Header
Entries
Header
Body
Two different modes



Encoding rules for datatype
instances
Convention for representing
RPC invocations
SOAP1.1 Message
Structure
RPC
Document
SOAP with Attachments
allow arbitrary data to be
packaged.
Fault
Element
10
SOAP Example: Request

Sample SOAP Message embedded in an HTTP Request
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 1024
SOAPAction: "http://example.org/2001/06/quotes"
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
<env:Body>
<m:GetLastTradePrice
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://example.org/2001/06/quotes">
<symbol>IBM</symbol>
</m:GetLastTradePrice>
</env:Body>
</env:Envelope>
11
SOAP Example: Response

SOAP message sent by the StockQuote service in the
corresponding HTTP response to the request
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: 512
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
<env:Body>
<m:GetLastTradePriceResponse
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://example.org/2001/06/quotes">
<Price>97.5</Price>
</m:GetLastTradePriceResponse>
</env:Body>
</env:Envelope>
12
UDDI
• Universal Description, Discovery and Integration
• Platform-independent, open framework for describing services,
discovering businesses, and integrating business services.
• A DNS-like model implementation of the directory
• Originally intended to support global registries
• Created during the .com bubble.
• Includes White, Green and Yellow Pages for search purposes
• Now primarily inside organisations if at all
13
Web Service Description Language
(WSDL)

Interface definition language in XML




Conceptually, no different from Enterprise Java Bean or Common
Gateway Interface
Based on XML Schema
Can appear to be very verbose
An interface description is a contract between the server
developers and the client developers


WSDL describes the web service
Similar to Java method signatures
14
Interoperability Challenges

Interoperability remains the chief challenge of web services



Web Services Interoperability (WS-I) focus on creating to
Interoperability


Complex and imprecise standard
Tools generating SOAP, WSDL, UDDI, etc. need to be
interoperable
WS-I Basic Profile 1.0 defines an interoperable web services
platform
Current version is WS-I v2.0
15
Web Services: Another approach to
distributed computing




Builds on the legacy of CORBA, J2EE etc
It is not a new component model, programming
model or programming language.
UDDI/WSDL/SOAP provide another distributed
computing technology
Standards developing for the Quality of Services
functionality
 E.g. WS-Security, WS-ReliableMessaging etc
Quality Of Service
Discovery
Description
Messaging
Transport
16
Web Services Strengths versus JEE



Interoperability
 Based on open standards, utilizes existing infrastructure
 Can be accessed from any programming language/model
Ubiquity
 Communicates through XML/HTTP – Any system that supports
these standards, supports Web Services
 Support from all major software vendors (IBM and Microsoft)
Low barrier to entry
 Concepts easy to understand, easy to implement
 Toolkits allow COM, JEE, and CORBA components to be
exposed as Web Services
17
RESTful Web Services

REpresentational State Transfer


Architecture inherent in all web based system since
1994, not explicitly described as an architecture until
later
An architecture - not a set of standard


Web Services is both an architecture and a set of standards
Goal: To leverage web based standards to
allow inter-application communication as simply
as possible

Matches the ‘standard’ web interaction model
18
The standard Web architecture
Response
(HTML doc)
HTTP GET request
Response
(HTML doc)
HTTP POST
PO
(HTML)
URL to submitted PO
URL 1
Parts
List
HTTP response
URL 2
HTTP response
Web Server
HTTP GET request
Part
Data
URL 3
PO
HTTP response
Copyright © [2005]. Roger L. Costello, Timothy D. Kehoe.
The RESTful architecture
Response
(XML doc)
HTTP GET request
Response
(XML doc)
HTTP POST
PO
(XML)
URL to submitted PO
URL 1
Parts
List
HTTP response
URL 2
HTTP response
Web Server
HTTP GET request
Part
Data
URL 3
PO
HTTP response
Copyright © [2005]. Roger L. Costello, Timothy D. Kehoe.
REST architecture

Uses HTTP operations:





Typically exchanges XML documents


GET = "give me some info" (Retrieve)
POST = "here's some update info" (Update)
PUT = "here's some new info" (Create)
DELETE = "delete some info" (Delete)
But supports a wide range of other internet media types
Example of client side REST request: GET
/shoppingcart/5873

Server must be able to correctly interpret the client request as
there is no explicitly defined equivalent to an interface definition
21
REST Architecture

Servers are stateless and messages can be interpreted
without examining history


There is no such thing as a “service”.


Messages are self-contained
There are just resources which are accessed through URI
 URI = generalisation of URL
Clients navigate through a series of steps towards a goal
by following hypertext links (GET) and submitting
representations (POST).
22
REST – strong versus weak

Pure REST should use ‘pure’ URI only


Many REST implementations also allow parameter
passing


E.g. GET /shoppingcart/5873
E.g. GET /shoppingcart/5873?sessionID=123
Allowing parameter passing makes REST a lot more
usable but blurs the architectural principle of
statelessness
23
Google API

http://code.google.com/apis/language/translat
e/v2/using_rest.html
24
RESTful Web Services in 1
slide

A distributed architecture



Platform neutral


No standard for implementation
No formalisation of interface
Access through platform specific development kits
Based on internet standards

XML, http etc
25
REST versus web services
REST Strengths





No toolkit or infrastructure
Independent of programming
language, platform or
component model
Easy to learn
Easy to get simple systems
working quickly
Used by cloud providers to
access servers
REST weaknesses


No standardisation on use of
URI
No standardisation response
document format


Yahoo uses XML, Google uses
JSON (JavaScript)
Less structured approach
makes it harder to build
complex interactions
26