web services

WEB SERVICES
1
word wide web
(www)
•
In the past years the www had a very large success basically
for two reasons:
- Simplicity
- Ubiquity
•
.
•
•
For a service provider is simple to contact a great number
of users.
For a user is simple to access a service everywhere it is
located.
However, www is strongly oriented to the interaction
among users and systems.
2
Interaction among distributed computing
applications
• The evolution of the internet and web utilization made
necessary the demand of interactions among applications in
different scenarios:
– A program of business management must be able to
integrate the local informations with those made available
on Internet by suppliers, banks or public administrations.
– An application used by estate agents must access real time
informations caming from wordwide finantial markets.
– The library management system can look for a book either
in the local catalog or in those of a larger library
management system (University, local goverment,…)
3
Web limitations
• The web model is not suitable to the management of the
interactions among applications.
• It is based on a very simple model:
- the user, using a browser, sends a URL to a server.
- the web server returns a HTML page that is graphically
displayed by the browser.
• In a interaction between two applications this scheme presents
two critical aspects:
– The URL are a very simple tool in order to express complex
and articulated requests.
– HTML is a language basically used to describe how documents
may be displayed.
4
URL (Uniform Resource Locator)
Every resource accessible over the web has a URL that
identifies the location of the resource
( a file if the resource is a document or a program if the
resource is a program that will produce the document) and
describes how to access it.
The URL provides the name of a protocol to be used to access
the resource, an address (which can be a domain name or an IP
address) of a machine where the resource is located and a
hierarchical description of the location of the resource on the
machine (directory path)
5
A new model
• In order to overcome the previously described difficulties a
new model has been developped: web services.
• An evolutive approach has been choosen:
- HTTP as application protocol in order to reuse the previous
infrastructure and to maintain the interaction model
simplicity.
- XML as a tool able to better describe the foundamental
elements of the interaction, the request and the response.
6
web service definition
“A WS is a software application described by a URI whose
public interfaces and relative bindings are defined and
described in XML. Its definition may be used by different
software applications.
These applications can interact with the WS following the
directives present in the service definition, using XML
messages and internet transport protocols. “
(“Web Services Architecture”
http://www.w3c.org/TR/2002/WD-ws-arch-20021114)
7
• web services work on assumption that the functionality
made available by a company will be exposed as a service.
• In middleware terms, a service is a procedure, method, or
object vith a stable, published interface that can be invoked
by clients.
• The invocation, and this very important, is made by a
program. Thus, requesting and executing a service involves
a program calling another program.
• Web services assume that services are loosely coupled,
since in general they are defined, developed and managed
by different companies
8
• The interface hides the implementation details of the service
(hardware, software, programming language).
•A web service corrisponds to a specific action or to a set of
actions.
•It may be used by oneself or with other web services to
implement a complex transaction.
9
A web service is defined as:
a standardized way of integrating Web-based applications using
XML, SOAP, WSDL and UDDI open standards over an Internet
backbone:
XML is used to tag the data, SOAP is used to transfer the data,
WSDL is used for describing the service available,
UDDI is used for listing what services are available.
10
Web Services – Technologies
• SOAP – Simple Object Access Protocol – Provides a standard
packaging structure for transporting XML documents over a
variety of standard Internet technologies, including HTTP.
• WSDL – Web Services Definition Language – XML thechnology
that describes the interface of a web service in a standardized
way. WDSL standardizes how input and output parameters can
be represented and the function’s structure. WDSL allow
disparate clients to automatically understand how to interact
with a web service.
• UDDI – Universal Description, Discovery and Integration – UDDI
provides a wordwide registry of web services. UDDI is used to
discover available web services by searching for names,
identifiers, categories.
11
Not every service available through the web is a web
service.
Examples: bookstores, restaurants or travel agencies. They all
provide services. In some cases a customer might even to
obtain such services through the web servers of the company.
This is not what web services are about. A web service is a
software application with a published stable programming
interface , not a set of web pages.
12
Integration problem
Each part (customer,supplier,warehouse) exposes its internal
operations as web services, which therefore acts as entry points
to the local information systems.
The interactions between companies occur in peer-to-peer
fashion and take place through standardized protocols.
Web services and their technology are being developed with
one specific use in mind: that of being entry points to the
local information systems.
The primary use of web services is that of exposing the
functionalty performed by internal systems and making it
discoverable and accessible through the web in a controlled
manner
13
The Web Services Model Service
Description
Service
Producer
Service
WSDL,UDDI
Service
Registry
Find
WSDL,UDDI
Service
Consumer
Service
Description
14
Roles in a web services
architecture
Service producer.
It is the service owner. From the architectural point of view it
represents the node containinig the service.
Service consumer
It is the application which is calling the service . A service
consumer may be a browser or an application (ex., another web
service)
Service register
It is a register which contains the descriptions of the services
published because the request of a producer and requested by the
service consumers.
15
Operations in a web services
architecture
•Publish
To be accessible a service description must be published allowing a
service consumer to find.
•Find
The find operation may happens in two different phases: during the
design of the service to look for the interface descrition, at run time
to implement the binding of the request service.
•Bind
It is the operation by which the service is localized
16
• The service consumer links up to a UDDI register (internet or
intranet)
• It looks up (by cathegories, providers, ecc…) the requested
service (example: web service providing stock rates)
• It finds the service description ( its functional aspects, the
address of the server containing the service, how it is possible
to call it)
• It connects himself to the provider server and utilizes the
service.
• The service consumer is a software application
The web services are web applications that
provide services to others web applications
17
18
•The client queries a UDDI registry for the service either by
name, category, identifier. Once located, the client obtains
information about the corresponding WSDL document.
•The WSDL document contains information about how to
contact the web service and the format of request messages in
XML schema.
•The client creates a SOAP message in accordance with the
XML schema found in WSDL and sends a request to the host
(where the service is).
19
Web Services have Two Types of Use
• Reusable application-components.
There are applications needed very often. So why make these
over and over again?
Web services can offer application-components like: currency
conversion, weather reports, or even language translation as
services.
• Connect existing software.
Web services can help to solve the interoperability problem
by giving different applications a way to link their data.
With Web services you can exchange data between different
applications and different platforms.
20
• Bank Currency Exchange service (Euro/dollar exchange.) Our
application can utilize the service without worrying about the
rates in force at the time of the operation.
• With a simple connection to the currency exchange service,
it’s possible to known the operations made available and how
it is possible to use them.
• This characteristic of web services is particularly usefull if you
consider that the services can be found by using the UDDI
directory service ,available on the web, where it is possible to
register and look for web services.
21
UDDI
• UDDI rougly represents the equivalent of an on line book
phone that enable the finding of web services
• UDDI offers 3 services whose names are typical of the
telephony word.
– White pages: finding a service by name
– Yellow pages: finding a service by category
– Green Pages: give technical informations on the services
provided by a particular company.
• A UDDI service provider (IBM, Microsoft, SAP ecc.) manages
an register called UBR (UDDI Business Registry) that is
accessible for publishing and finding the web services
22
•
•
•
•
WDSL
Trough WSDL the public interface of a web service (based on
XML) can be described
A WSDL document contains, relatively to the described web
service, informations on:
What can be utilized (the “operations” provided by the
service);
How it can be utilized (the communication protocol to access
the service, the input, output messages format and the
relative types of data).
Where the service is located (the service endpoint, that is the
service address –URI format- that makes available the web
service ).
The web service operations and messages are described in an
abstract way , that is not bound to a particular network
protocol and to a particular format.
23
The WSDL Document Structure
A WSDL document describes a web service using these major
elements:
Element
<types>
<message>
<portType>
<binding>
Description
A container for data type definitions
used by the web service
A typed definition of the data being
communicated
A set of operations supported by one
or more endpoints
A protocol and data format
specification for a particular port type
24
The <portType> element is the most important WSDL element.
•
It describes a web service, the operations that can be performed, and the
messages that are involved.
The <portType> element can be compared to a function library (or a
module, or a class) in a traditional programming language.
•
WSDL Messages
The <message> element defines the data elements of an operation.
Each message can consist of one or more parts. The parts can be
compared to the parameters of a function call in a traditional
programming language.
•
WSDL Types
The <types> element defines the data types that are used by the web
service. For maximum platform neutrality, WSDL uses XML syntax to
define data types.
•
WSDL Bindings
The <binding> element defines the data format and protocol for each port
type.
25
The main structure of a WSDL document looks like this:
<definitions>
<types>
data type definitions........
</types>
<message>
definition of the data being communicated....
</message>
<portType>
set of operations......
</portType>
<binding>
protocol and data format specification....
</binding>
</definitions>
A WSDL document can also contain other elements, like extension elements,
and a service element that makes it possible to group together the
definitions of several web services in one single WSDL document.
26
Example
<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>
27
• In this example the <portType> element defines
"glossaryTerms" as the name of a port, and "getTerm" as the
name of an operation.
• The "getTerm" operation has an input message called
"getTermRequest" and an output message called
"getTermResponse".
• The <message> elements define the parts of each message
and the associated data types.
Compared to traditional programming, glossaryTerms is a
function library, "getTerm" is a function with
"getTermRequest" as the input parameter, and
getTermResponse as the return parameter.
28
WSDL binding and service
<binding type="glossaryTerms" name="b1">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation>
<soap:operation soapAction="http://example.com/getTerm"/>
<input><soap:body use="literal"/></input>
<output><soap:body use="literal"/></output>
</operation>
</binding>
29
• The binding element has two attributes - name and type.
• The name attribute defines the name of the binding, and the
type attribute points to the port for the binding, in this case
the "glossaryTerms" port.
• The soap:binding element has two attributes - style and
transport.
• The style attribute can be "rpc" or "document". In this case
we use document. The transport attribute defines the SOAP
protocol to use. In this case we use HTTP.
• The operation element defines each operation that the
portType exposes.
• For each operation the corresponding SOAP action has to be
defined. You must also specify how the input and output are
encoded. In this case we use "literal".
30
The last part of the document describes the service and its web address.
<service name=“getTermService">
<port name=“glossary service“
binding="tns:StockQuoteBinding">
<soap:address location="http://www.glossary service.com"/>
</port>
</service>
31
SOAP Building Blocks
A SOAP message is an ordinary XML document containing
the following elements:
• An Envelope element that identifies the XML document as a SOAP
message
• A Header element that contains header information
• A Body element that contains call and response information
• A Fault element containing errors and status information
All the elements above are declared in the default namespace for the
SOAP envelope:
http://www.w3.org/2001/12/soap-envelope
and the default namespace for SOAP encoding and data types is:
http://www.w3.org/2001/12/soap-encoding
32
Skeleton SOAP Message
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soapencoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
33
<? xml version="1.0"?>
• This line with special symbols and attributes is what is
referred to as the XML declaration. It simply states what
version of XML you are using and the type of encoding you
are using.
The SOAP Envelope Element
• The SOAP Envelope element is the root element of a SOAP
message. This element defines the XML document as a SOAP
message.
The SOAP Header Element
• The optional SOAP Header element contains applicationspecific information (like authentication, payment, etc) about
the SOAP message.
34
The SOAP Body Element
The required SOAP Body element contains the actual SOAP messages intended
for the ultimate endpoint of the message.
Example:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
35
A SOAP response could look something like this:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
36
• XML Namespaces provide a method to avoid element name
conflicts.
• In XML, element names are defined by the developer. This
often results in a conflict when trying to mix XML documents
from different XML applications.
• Name conflicts in XML can easily be avoided using a name
prefix.
• When using prefixes in XML, a so-called namespace for the
prefix must be defined.
• The namespace is defined by the xmlns attribute in the start
tag of an element.
• The namespace declaration has the following syntax.
xmlns:prefix="URI".
37
Web Services: summary
• Web services are autonomous applications, modular and self
describing that can be published, retrieved and called.
• Allow to implement interactions among applications
inInternet.
• A web service is constituded by three elements:
– A mechanism of pubblication and research :UDDI
– A mechanism of description: WSDL
– A mechanism of calling: SOAP
38
• WSDL
WSDL stands for Web services description language
WSDL is a XML-based language for describing Web services
Wsdl is a W3C recomandation
• SOAP
Soap stands for Simple Object Access Protocol
Soap is an XML based protocol for accessing web services
Soap is a W3C recomandation
• UDDI
UDDI stands for Universal Description, Discovery and Integration
UDDI is a directory service where companies can search for Web
services
UDDI described in XML
39
UDDI communicates via SOAP
Principali motivi per utilizzare o sviluppare web
services
• I web services permettono l’interoperabilità tra diverse
applicazioni software e su diverse piattaforme H/S
• Utilizzano un formato dei dati di tipo testuale, quindi più
comprensibile e più facile da usare per gli sviluppatori
• Normalmente essendo basati sul protocollo HTTP, non
richiedono modifiche alle regole di sisicurezza utilizzate come
filtro dai firewall (porta 80)
• Sono semplici da utilizzare e possono essere combinati l’uno
con l’altro (indipendentemente da chi li fornisce e da dove
vengono resi disponibili) per formare servizi integrati e
complessi.
• Permettono di riutilizzare applicazioni già sviluppate
40
• Fintanochè l’interfaccia rimane costante le modifiche
effettuate ai servizi rimangono trasparenti
• I servizi web sono in grado di pubblicare le loro funzioni e di
scambiare dati con il resto del mondo
• Tutte le informazioni vengono scambiate attraverso protocolli
aperti
41
Problemi
• I web services presentano performance drasticamente
inferiori rispetto ad altri metodi di comunicazione disponibili
in rete. Questo svantaggio è legato alla natura stessa dei
servizi web. Essendo basati su XML ogni trasferimento di dati
richiede l’inserimento di un notevole numero di dati
supplementari (i tag XML) indispensabili per la descrizione
della operazione. Inoltre tutti i dati inviati richiedono di
essere prima codificati e poi decodificati ai capi della
connessione. Queste due caratteristiche dei web service li
rendono poco adatti a flussi di dati intensi o dove la velocità
dell’applicazione rappresenti un fattore critico.
42
• E’ necessario disporre di un’applicazione terza che gestisca le
richieste HTTP oppure è necessario includerla direttamente
nel codice del nostro programma qualora si desideri la sua
totale indipendenza. Va detto comunque che generalmente il
codice che implementa un web service viene fatto eseguire da
un Web server (es.Apache) tramite CGI (per es. con Pyton) o
tramite appositi moduli (es. PHP) Eseguendo il codice del web
service attraverso un server web la gestione di HTTP è
immediatamente assicurata.
43

Download Report