A Quick Introduction To Web Services: Antonio Brogi and Sara Corfini

A quick introduction to Web Services
Antonio Brogi and Sara Corfini
Department of Computer Science

University of Pisa, Italy
A. Brogi and S. Corfini Web Services - 1

What are Web services?
Yet another distributed computing technology
(CORBA,RMI,EJB, …)
An example
Service request:
Get weather information Server
for ZIP code 56127
Client Web Service

Service response:
Cloudy
This is not publishing something on a web site

Web sites for humans, Web services for software
What makes Web services “special”?
They are platform- and language- independent
e.g., client: C++/Windows – Web service: Java/Linux
Most Web services use HTTP for trasmitting
messages
They are adequate for loosely coupled systems
client might have no prior knowledge of Web services
Disadvantages
Overhead
Lack of versatility (very basic forms of service
interactions)

A typical Web service invocation
Server A
(1) Where can I find a “weather service”?
Discovery
Service
(2) There is a “weather service” at

Client Server B, here is its WSDL interface
(instruction manual)
(3) SOAP request:

Get weather information
for ZIP code 56127 Server B
(4) SOAP response: Cloudy
Web
Service

Web service architecture
Discovery, aggregation,
Processes choreography, …
WSDL
Description (self-describing services)
SOAP (the most popular

Invocation invocation protocol)
HTTP (The most popular

Transport transport protocol)

Web services addressing
How exactly are Web services addressed?
URIs (Uniform Resource Identifiers)
An example
http://webservices.mysite.com/weather/it/WeatherService
If you type a Web service URI into your browser…

you probably get an error message
You usually need to give the URI to a program
URI as a command-line argument

Web services
www.xmethods.net
www.salescentral.com
www.ibm.com/websphere
www.hp.com/go/webservices
www.microsoft.com/net
otn.oracle.com/webservices
www.sun.com/sunone
www.xmlbus.com
…

Web services’ definitions
Many (informal) definitions
“A standardized way of integrating Web-based applications using the
XML, SOAP, WSDL and UDDI open standards over an Internet
protocol backbone.
XML is used to tag the data, SOAP is used to transfer the data,
WSDL is used for describing the services available, UDDI is used for
listing what services are available.”
[www.webopedia.com]
“A software application identified by a URI, whose interfaces and

bindings are capable of being defined, described and discovered by
XML artefacts. A Web service supports direct interactions with
other software agents, using XML-based messages exchanged via
Internet-based protocols.”
[W3C consortium]

Main architectural components
service provider service requester
application object application object

(provider) (service client)
SOAP-based SOAP-based
middleware middleware
SOAP messages
(to interact)
SOAP messages SOAP messages

(to publish service description) (to look for services)
SOAP-based
middleware
service descriptions
UDDI registry
Goal of middleware
ease the interaction between applications across
heterogeneous computing platforms, offering
programming abstractions that hide complexity
example: Remote Procedure Call (RPC)
RPC
RPC hides communication details
behind a procedure call and TCP
bridges heterogenous platforms
IP
example scenario
a company that has its customer data, inventory data
and purchasing order from customers stored in three
different applications
how to integrate them? Use Web services!
Service-oriented Computing
Evolution of programming:
structured programming (Algol,Fortran,C…)
object-oriented programming (SmallTalk,Java,C#…)
component-oriented programming (CORBA,COM,.NET…)
… and …
Service-oriented Computing
notion of service as the basic element for developing
next generation heterogeneous distributed applications
strong industrial and academic interest
many examples of available (Web) services

Web services technology: Ingredients
XML: A common syntax for all specifications
SOAP: A protocol to allow “sites” to communicate
WSDL: An interface definition language to

describe services
UDDI: A name and service directory to publish

and to locate services

XML

XML for Web Services
XML (eXtensible Markup XML vs. HTML
Language) XML tags are case sensitive
text-based markup language (HTML tags are not)
data are identified using tags XML tags relate to the meaning
• Ex. <message>Hello of the enclosed text (HTML
World</message> tags tell how to display the
system-independent way of text)
representing data XML is extensible, you can
current standard technology write your own tags (in HTML
only predefined tags)

for interoperability is XML, all
WS technologies based on XML XML documents must be well-
XML document usually stored in formed
a (text) .xml file • You can define class of valid
documents (e.g., XML Schema)
<message>
<to>studs@cli.di.unipi.it</to>
<from>brogi@di.unipi.it</from>
<subject>XML class</subject>
<text>
What is XML?
</text>
</message>
Features of XML
Why is XML important?
Plain text - not binary format
• files can be created and edited with anything from standard text
editors to visual development environments
• easy to debug, can store any amount of data (scalability)
Data identification
• XML describes the kind of each data
• data are easy to search, extract, process, use
“Stylability”
• XML is inherently style free, but you can use different stylesheets to
produce output in postscript, PDF or other formats (even not
invented yet!)
What makes XML portable?
XML documents are written in text format
• which is readable by both human beings (more or less :) and text-
editing software
A schema gives XML data its portability
• a parser uses schemas to understand the structure of valid
documents (and to validate documents)

SOAP

SOAP: Simple Object Access Protocol
SOAP provides
a standardised (XML) message structure
a processing model that describes how service(s)

should process messages
a mechanism to bind SOAP messages to different
transport protocols
[a way to attach non-XML encoded information to
SOAP messages]

Structure of a SOAP Message
Every message has a
sender, a final receiver
SOAP envelope
and intermediaries
SOAP header Header [optional]:
additional blocks of info
header block
for intermediate
processing (eg, QoS:
security, reliability,…)
SOAP body Body [mandatory]: payload
for ultimate receiver
body block
document literal (eg,
purchase order, confirm.#)
RPC (eg, proc name+params,
results)

Processing a SOAP Message
Message header blocks specify “roles”
role determines how SOAP nodes should process
message
Roles
None: block should not be processed (but might be
read) by any node receiving the message
Next: every node receiving the message can process it
UltimateReceiver: block solely intended for
recipient of message
MustUnderstand flag
node playing role indicated by block must process it,
otherwise further processing stops and fault is
generated
Example of SOAP Message
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" >
<env:Header>
<t:transactionID
xmlns:t="http://intermediary.example.com/procurement"
env:role="http://www.w3.org/2002/06/soap-envelope/role/next"
env:mustUnderstand="true" >
57539
</t:transactionID>
</env:Header>
<env:Body>
<m:orderGoods
env:encodingStyle="http://www.w3.org/2002/06/soap-encoding"
xmlns:m="http://example.com/procurement">
<m:productItem>
<name>ACME Softener</name>
</m:productItem>
<m:quantity>
35
</m:quantity>
</m:orderGoods>
</env:Body>
</env:Envelope>

Binding SOAP to Transport Protocols
defines how SOAP msg will be transported
through network
SOAP does not impose any transport protocol
typically associated with HTTP (others like SMTP)
specification of which protocol to use: binding
• example: SOAP over HTTP
– SOAP envelope sent within an HTTP request (GET, POST)
– eg, RPC request sent as part of HTTP POST request
has another implicit functionality: addressing
identification of ultimate receiver’s address is not part
of SOAP msg
SOAP msg included as part of HTTP request or SMTP
msg
• HTTP: URL of target resource describes the receiver
• SMTP: “to” address in e-mail header describes the receiver
RPC call using SOAP HTTP Post
over HTTP SOAP envelope
SOAP header
transactional
context
SOAP body
name of the
service requestor procedure service provider
input parameter 1
SOAP HTTP HTTP SOAP
engine engine input parameter 2 engine engine
client implementation HTTP Post service implementation

(other tiers) SOAP envelope
(other tiers)
SOAP header
transactional
context
SOAP body
return
parameter

WSDL

WSDL: Web Service Description Language
XML format for describing network services as a
set of endpoints operating on messages
WSDL 1.1 definitions consist of two parts:
abstract part (“what” the service does)
• <types> type definitions used to describe messages
• <messages> exchanged by service (one or more parts)
• <portType> defines the set of <operations> supported
one-way | request-response | solicit-response | notification
concrete part (“how” and “where” it does it)
• <binding> how to format messages to interact with service
– eg, SOAP binding (also HTTP, MIME)
• <service> where to find a service
– each <port> describes the address where a <portType> is
offered via a given binding
WSDL Service Specification
WSDL specification
abstract part
types
messages
port types
concrete part
bindings
services

<?xml version="1.0"?> WSDL Example
<definitions name="Procurement"
targetNamespace="http://example.com/procurement/definitions"
xmlns:tns="http://example.com/procurement/definitions"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
abstract
xmlns="http://schemas.xmlsoap.org/wsdl/" >
<message name="OrderMsg"> part

<part name="productName" type="xs:string"/>
<part name="quantity" type="xs:integer"/> messages
</message>
<portType name="procurementPortType">
<operation name="orderGoods">
<input message = "OrderMsg"/>
operation and
</operation> port type
</portType>
<binding name="ProcurementSoapBinding" type="tns:procurementPortType">

<soap:binding style="document" concrete
transport="http://schemas.xmlsoap.org/soap/http"/> part
<operation name="orderGoods">
<soap:operation soapAction="http://example.com/orderGoods"/>
<input>
<soap:body use="literal"/> binding
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="ProcurementService">
<port name="ProcurementPort" binding="tns:ProcurementSoapBinding"> port and
<soap:address location="http://example.com/procurement"/>
</port>
service
</service>
</definitions>
UDDI

Universal Description, Discovery and Integration
Goal: provide the specification to allow
(describing and) discovering services
dynamically selecting a service implementation at run-time
UDDI employs categorization
keyedReference indicates one categorization from a category
system (represented by a tModel)
• eg, key of tModel: uddi:uddi.org:ubr:categorization:iso3166
keyValue: “US-CA”
Main elements of UDDI data model
business Entity (“white pages” )
business Service (“yellow pages” )
bindingTemplate (“green pages” )
tModel
• generic container for any kind of spec. (eg, WSDL interface)

businessEntity tModel
tModel
name keytModel
key
key
contacts name
name
description name
description
description
description
identifiers overviewDoc
overviewDoc
categories overviewDoc
identifiers
identifiers
identifiers
categories
categories
categories
businessService
service key
name
description
categories
tModel
tModel
key
key
bindingTemplate name
binding key name
description Specs stored
description description
overviewDoc at the
address overviewDoc
identifiers provider’s
detailed info identifiers
categories site
references to tModels categories
A. Brogi and S. Corfini Stored in the UDDI registry Web Services - 29

Example of UDDI tModel
<tModel tModelKey=”uddi:uddi.org:v3_publication”>
<name>uddi-org:publication_v3</name>
<description>UDDI Publication API V3.0</description>
<overviewDoc>
<overviewURL useType=”wsdlInterface”>
http://uddi.org/wsdl/uddi_api_v3_binding.wsdl#UDDI_Publication_SoapBinding
overviewDoc </overviewURL>
(refer to WSDL </overviewDoc>
specs and to API
<overviewDoc>
<overviewURL useType=”text”>
specs) http://uddi.org/pubs/uddi_v3.htm#PubV3
</overviewURL>
</overviewDoc>
classification <categoryBag>
information
<keyedReference keyName=”uddi-org:types:wsdl”
keyValue="wsdlSpec"
(specifies that this tModelKey="uddi:uddi.org:categorization:types”/>
tModel is about <keyedReference keyName=”uddi-org:types:soap”
keyValue="soapSpec"
XML, WSDL, and tModelKey="uddi:uddi.org:categorization:types”/>
SOAP specs) <keyedReference keyName=”uddi-org:types:xml”
keyValue="xmlSpec"
tModelKey="uddi:uddi.org:categorization:types”/>
<keyedReference keyName=”uddi-org:types:specification”
keyValue="specification"
tModelKey="uddi:uddi.org:categorization:types”/>
</categoryBag>
</tModel>

UDDI Registry API
Three kinds of users
Service providers publishing services
Requesters looking for services
Other registries exchanging information
UDDI Inquiry API

• most important API for requesters
• operations to find registry entries satisfying search criteria & get
overview info
find_business, find_service, find_binding, find_tModel
• operations to get details about a specific entity
get_businessDetail, get_serviceDetail,…, get_tModelDetail
• used by
– UDDI browser tools to support developers
– clients at run-time for dynamic binding

How does this work in practice?
Web services programmers (usually) concetrate
on writing code in their favourite language
in same cases they write WSDL
SOAP always generated/interpreted automatically
(stubs)
Client 1 2 Server 3
Server stubs
Client stubs
Client Web Service

program implemenation
6 5 4

Web services: research themes

Some challenges …
Service discovery
How to discover the services we really need?
How to ensure that interaction will really work?
Service aggregation
How to compose/integrate/adapt existing services?
How to ensure that aggregation will really work?
Can we automate service discovery, aggregation,
invocation?

Some proposals …
Add semantics to service contracts
to provide machine-understandable descriptions of
services
current trend: concept ontologies (of service IOs)
Vehicle.owl
Vehicle
Car Bus
Sedan SUV Station Wagon

Some proposals …
Add behaviour information to service contracts
to express [part of] interaction protocol of services
to be able to prove behavioural properties (e.g., lock-
freedom)

Some questions …
Web services: “old wine in new bottles”?
Are ontologies really a good idea?
• How difficult to write queries/contracts?
• Will suitable supporting tools ease massive adoption?
• If ontologies will succeed, then different ontologies will be
used …
How about service behaviour?
• See what happens with components …
• Any “de facto” standard emerging?
– Companies use BPEL
– W3C promotes OWL-S/WS-CDL …

Some hyperlinks
XML http://www.w3.org/XML/
SOAP http://www.w3.org/TR/soap/
WSDL http://www.w3.org/TR/wsdl/
UDDI http://www.uddi.org/

A Quick Introduction To Web Services: Antonio Brogi and Sara Corfini

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Quick Introduction To Web Services: Antonio Brogi and Sara Corfini

Uploaded by

Copyright:

Available Formats

A quick introduction to Web Services

Antonio Brogi and Sara Corfini

Department of Computer Science

A. Brogi and S. Corfini Web Services - 1

Client Web Service

 This is not publishing something on a web site

A. Brogi and S. Corfini Web Services - 3

(2) There is a “weather service” at

(3) SOAP request:

A. Brogi and S. Corfini Web Services - 4

SOAP (the most popular

HTTP (The most popular

A. Brogi and S. Corfini Web Services - 5

 If you type a Web service URI into your browser…

A. Brogi and S. Corfini Web Services - 6

A. Brogi and S. Corfini Web Services - 7

“A software application identified by a URI, whose interfaces and

A. Brogi and S. Corfini Web Services - 8

application object application object

SOAP messages SOAP messages

A. Brogi and S. Corfini Web Services - 11

 SOAP: A protocol to allow “sites” to communicate

 WSDL: An interface definition language to

 UDDI: A name and service directory to publish

A. Brogi and S. Corfini Web Services - 12

A. Brogi and S. Corfini Web Services - 13

A. Brogi and S. Corfini Web Services - 15

A. Brogi and S. Corfini Web Services - 16

 a processing model that describes how service(s)

A. Brogi and S. Corfini Web Services - 17

A. Brogi and S. Corfini Web Services - 18

A. Brogi and S. Corfini Web Services - 20

client implementation HTTP Post service implementation

A. Brogi and S. Corfini Web Services - 22

A. Brogi and S. Corfini Web Services - 23

A. Brogi and S. Corfini Web Services - 25

<message name="OrderMsg"> part

<binding name="ProcurementSoapBinding" type="tns:procurementPortType">

A. Brogi and S. Corfini Web Services - 27

A. Brogi and S. Corfini Web Services - 28

A. Brogi and S. Corfini Stored in the UDDI registry Web Services - 29

A. Brogi and S. Corfini Web Services - 30

 UDDI Inquiry API

A. Brogi and S. Corfini Web Services - 31

Client Web Service

A. Brogi and S. Corfini Web Services - 32

A. Brogi and S. Corfini Web Services - 33

A. Brogi and S. Corfini Web Services - 34

Sedan SUV Station Wagon

A. Brogi and S. Corfini Web Services - 35

A. Brogi and S. Corfini Web Services - 36

A. Brogi and S. Corfini Web Services - 37

A. Brogi and S. Corfini Web Services - 38

You might also like

This is not publishing something on a web site

If you type a Web service URI into your browser…

SOAP: A protocol to allow “sites” to communicate

WSDL: An interface definition language to

UDDI: A name and service directory to publish

a processing model that describes how service(s)

UDDI Inquiry API