Introduction
Web Services and Services are different things.
Services provide some functionality
Web Services are used to connect Services
Web Services became wrongly equated with some of the
technologies used to implement then (WSDL / SOAP / XML /
…)
Two different approaches:
WS-* Standards
REST style
WS-*
WS-* basic standards
UDDI (where a service is)
WSDL (what a service does)
SOAP (communicate with the service)
More standards:
WS-PolicyAssertions
WS-Security
WS-Trust
WS-SecureConversation
…
WS-*
UDDI
Universal Description, Discovery and Integration
Provides an infrastructure for a Web Services-
based software environment for both publicly
available services and services only exposed
internally within an organization
UDDI registry is intended to as a search engine of
Web Services described using WSDL .
UDDI – Information Types
White pages:
Company contact information and description
Allows others to discover your web service based upon your business
identification.
Yellow pages:
Define categories for Web Services offered
Allows others to discover your web service based upon its categorization
Green pages:
technical information that describes the behaviors and supported
functions of a web service hosted by your business.
Includes pointers to the grouping information of web services and where
the web services are located.
WSDL
Stands for Web Services Description
Language
Document written in XML.
Specifies the location of the service and the
operations (or methods) the service
exposes.
WSDL
WDSL Document Root
$ # '$"#"& ,
( # $$!# #( # ! "'#
#"& $""&
++
#"&
$ #
WSDL - Abstract Definitions
Types: Machine- and language-independent type definitions.
(##$"
(#
Messages: Contains function parameters (inputs separate
from outputs) or document descriptions.
## $"
$ !"$%"
!"$ * ! $)! (##$"
!"$ # %#$)! (#
##
## $"
$ !"$%"#! #
!"$ #% $$)! (# $
##
WSDL - Abstract Definitions
Operations: describe methods signatures (operation name, input
parameters, output parameters).
!"$
$ !"$%"!" $""" * !
# %#
!%$ ## '# #$"
$ !"$%"
%$!%$ ## '# #$"
$ !"$%"#! #
!"$
PortTypes: Collection of all operations exposed by the service
! "$)! $" ! "$
!"$
$ !"$%"!" $""" * !
# %#
!%$ ## '# #$"
$ !"$%"
%$!%$
## '# #$"
$ !"$%"#! #
!"$
$" !"$ #' % "
! "$)!
WSDL - Concrete Descriptions
Bindings: Specifies binding(s) of each operation in the PortTypes
section.
$" ! $)! '# #$" ! "$
# ! #$) "!$" #! "$ $$!# #( # ! "# !$$!
!"$
$ !"$%"
# ! !"$
# ! $ $$!$ !%" "$ $"
$ !"$%"
!%$
# ! ) %#
#! $$!$ !%" " ## $) $$!# #(
# ! "# !
!%$
%$!%$
# ! ) %# #! $$!$ !%" " ##,
$) $$!# #( # ! "# !
%$!%$
!"$
WSDL - Concrete Descriptions
Services: Specifies port address(es) of each binding.
! "$ $" ! "$, '# #$" !
# !"## $ $$! #$'$"#"& #!
! "$
SOAP
Once stood for Simple Object Access Protocol.
From version 1.2 lost its meaning.
SOAP provides the envelope for sending Web
Services messages over the Internet.
SOAP commonly uses HTTP, but other protocols
such as Simple Mail Transfer Protocol (SMTP) may
by used.
SOAP can be used to exchange complete
documents or to call a remote procedure.
SOAP - Envelope
The SOAP envelope can contain:
An optional header providing information
on authentication, encoding of data, or
how a recipient of a SOAP message
should process the message.
The body that contains the message.
These messages can be defined using
the WSDL specification.
Optional Fault element that provides
information about errors that occurred while
processing the message
Soap Example
POST /InStock HTTP/1.1 HTTP/1.1 200 OK
Host: www.example.org Content-Type: application/soap+xml;
charset=utf-8
Content-Type: application/soap+xml;
charset=utf-8 Content-Length: nnn
Content-Length: nnn
<?xml version="1.0"?> <?xml version="1.0"?>
<soap:Envelope <soap:Envelope
xmlns:soap="http://www.w3.org/20 xmlns:soap="http://www.w3.org/2001
01/12/soap-envelope" … > /12/soap-envelope" …>
<soap:Body <soap:Body
xmlns:m="http://www.example.org/ xmlns:m="http://www.example.org/st
stock"> ock">
<m:GetStockPrice> <m:GetStockPriceResponse>
<m:StockName>IBM</m:Sto <m:Price>34.5</m:Price>
ckName> </m:GetStockPriceResponse>
</m:GetStockPrice> </soap:Body>
</soap:Body>
</soap:Envelope>
</soap:Envelope>
Example
Tools: Apache AXIS (v2)
Apache Axis is an Open Source SOAP server and client(from
ws.apache.org)
Axis helps to speed up development when using on WS-*
usage by generation code for both producer and consumer
sides.
One good functionality is that Axis can quickly expose a class
as web service
Resources:
Axis 1.x: http://ws.apache.org/axis/
Axis 2: http://ws.apache.org/axis2/
Actually look at the all of the content in http://ws.apache.org
The REST Approach
REpresentational State Transfer
First described in 2000 by Roy Fielding
Is a style of software architecture
Is NOT a set of standards.
Applications or architectures are sometimes
referred to as RESTful or REST-style applications
or architectures.
RESTfull Characteristics
Stateless client-server architecture
Web services are viewed as resources and can be
identified by their URLs.
Every resource is uniquely addressable using a
uniform and minimal set of commands (typically
using HTTP commands of GET, POST, PUT, or
DELETE over the Internet)
Each resource return a representation
RESTful Characteristics
While REST is not a standard, it does use
standards:
HTTP
URL
XML/HTML/GIF/JPEG/etc (Resource
Representations)
text/xml, text/html, image/gif, image/jpeg, etc
(MIME Types)
Resource Oriented Architecture
Appeared as a response to the SOA standard from REST
supporters
Guidelines to implement a RESTful style architecture
Each resource knows how to Represent, make a transition from
states and self-destruct (Resource definition)
Each Resource is unambiguously accessed by a unique URI
(Addressability)
Requests to Resources have all necessary information
(Statelessness)
Resources should link to other dependent resource in their
representation (Connectedness)
REST Example
The Boeing defines access to a resource (a
747):
http://www.boeing.com/aircraft/747
Using a GET command this resource
returns a representation of its state:
Boing747.html
This state can represent access to other
dependent resource (ex: links)
REST Example
POST /register/user/09723 HTTP/1.0 200 OK
Accept: */* Content-Type: text/xml
Connection: close Connection: close
Content-Type: text/xml
Content-Length: 618 <?xml version="1.0"
Pragma: no-cache encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF- <response>
8"?> <success>true</success>
<request>
<name>xtpo</name> </request>
<address>here</address>
...
</request>
Google Data API
Uses REST style APIs
Resources are representation is based on the
Atom 1.0 and RSS 2.0 syndication formats.
Example of a retrieving Google Calendar events for
a user
GET http://www.google.com/calendar/feeds/userID/private-
magicCookie/full
WS-* and Rest
Advantages of WS-*
Easy to consume - sometimes
Rigid - type checking, adheres to a contract
Development tools
Advantages of REST style
Lightweight
Results are less verbose, hence more human readable
Easy to build - no toolkits required
WS-* and Rest
A WS-* based design may be appropriate when:
A formal contract is needed for a service (WSDL).
Complex need to be handled in a standardized way.
Requirements for asynchronous service invocation are
present.
WS-* and Rest
A RESTfull design may be appropriate when:
Completely stateless web services are needed.
Limited bandwidth between service consumer and
provider. Mobile Device communication is an excellent
example.
Both service consumer and provider have mutual
understanding of the context and content being passed.
Front-end technologies like as AJAX are being used.
Exercise
WS-*
Use UDDI to find the WSDL for one service.
Create a simple java client to invoke the service
REST
Create an account in the del.icio.us service
Create a client to read REST APIs from del.icio.us
API details: http://www.peej.co.uk/articles/restfully-delicious.html
