WEB SERVICES
1
Definizione del W3C
"Un servizio web è un'interfaccia che descrive una
collezione di operazioni, accessibili attraverso una
rete mediante messaggistica XML".


sistema software progettato per supportare
l'interoperabilità tra diversi elaboratori su di una
medesima rete
offre un'interfaccia software tramite la quale altri sistemi
possono interagire con il Web Service stesso.
L'interfaccia descrive le operazioni alle quali si accede
tramite appositi messaggi trasportati tramite il protocollo
HTTP e formattati secondo lo standard XML.
2
A cosa servono i WS?
Garantire a dispositivi di natura differente
pieno accesso a tipologie di dati
eterogenei.
 Quando due entità si mettono d'accordo
per scambiarsi una serie di informazioni e
per astrarre il procedimento, si affidano ad
un sistema in grado di garantire una
manutenibilità ed una durata della
soluzione il più lunga possibile.

3
Struttura Internet
Client
Server
richiesta dati
risposta
4
Schema generale dei WS
Principalmente un web service espone
all'esterno una serie di funzionalità,
attraverso un server.
 Un listener è un particolare programma
che si mette in ascolto delle richieste che
provengono da eventuali client ed
ovviamente, cerca di rispondere nel modo
migliore.

5
Struttura WebService
Server consumer
Server Provider
service request
service response
6
Componenti dei WS
A differenza di ciò che avviene con la
normale navigazione attraverso un browser,
nei Web Services gli attori non sono utente
e server, ma due server.
7
Esempio1 : Weak Integration on the
Application Web
8
Esempio1 : Improved Integration on the
Service Web
9
Utilità
I
Web Services possono essere utilizzati:
nelle applicazioni B2B per interfacciare diversi
partner commerciali,
nelle applicazioni B2C per fornire servizi
all'utente finale.
Es:
un servizio che fornisce le quotazioni di borsa
un servizio di traduzione da una lingua ad un'altra
Struttura dei Web Services
Si possono distinguere varie componenti:
(Universal Definition and Discovery Interface)
registro che permette la pubblicazione e la
successiva ricerca dei servizi.
(Web Services Definition Language) strumento per
la definizione dei servizi, definiscono le interfacce
e le modalità di colloquio
.
(Simple Object Access Protocol) protocollo a basso
livello per la comunicazione di messaggi XML
Protocolli di trasporto nativi di Internet
(http, ftp, altro)
Ciclo di vita di un servizio
PRODUTTORE
3
1
CHIAMA
PUBBLICA
CONSUMATORE
2
CERCA
REGISTRO
13
14
15
16
SOA System
I WS si basano sulla Service Oriented Architecture
(SOA). I tre componenti prncipali sono:
1. Service Provider ,rende disponibile il servizio e
pubblica il contratto che ne descrive
l’interfaccia(tramite il broker).
2. Service Requestor o Consumer,effettua le
queries al service broker e questo cerca il
servizio compatibile.
3. Service Registry o Broker,da info al consumer
su quale servizio utilizzare e dove trovarlo.
17
L’architettura concettuale SOA con
SOAP, WSDL, and UDDI
18
Esempi SOA System




Java RMI7: Java Remote Method Invocation
CORBA8: The Object Management Group
Common Object Request Broker Architecture
DCE9: The Open Group Distributed Computing
Environment
DCOM10: Microsoft Distributed Component
Object Model
19
Componenti Funzionali SOA
TRASPORTO:rappresenta il formato e il
protocollo per comunicare con il servizio
 DESCRIZIONE:rappresenta il linguaggio
per descrivere un servizio, ne specifica il
contratto(operazioni e parametri) e
fornisce info relative al ‘bind’del servizio
 SCOPERTA:descrive il meccanismo per
registrare e ricercare un servizio.

20
WS Technologies
I Web Services comunicano perché adottano
lo stesso linguaggio: XML.
Questo descrive le interfacce dei WS e
decodifica i loro messaggi.
Ma XML da solo non assicura comunicazioni
semplici,le applicazioni necessitano perciò
di formati standard e protocolli che
permettono loro di interpretare
appropriatamente XML
21
Trasporto – SOAP 1

È un paradigma di scambio di messaggi
stateless e unidirezionale

il msg passa, tramite una trasmissione
one-way, dal Soap sender al Soap
receiver sono spesso del tipo
richiesta/risposta(un’applicazione può
essere o solo sender o solo receiver).
22
Trasporto - SOAP 2
Si utilizza il protocollo SOAP(Simple Object Access Protocol ) che definisce
tutti gli standard per le comunicazioni nei WS:
 Formato dati

Wire Format, è un documento XML chiamato ’busta’ che contiene un
Soap Header (user, pass),un mandatario e un Soap Body(msg originale
in Xml).

Protocollo di trasporto (di solito Soap utilizza HTTP ma ci sono anche
altri come Https, Smpt,Pop3, Imap, Java Messaging Services, Blocks
Extensible Exchange Protocol )

Info aggiuntive di diverso tipo
23
A SOAP request
<soap:Envelope xmlns:soap="...">
<soap:Header>
<m:reservation .......> </m:reservation>
<n:passenger.... ..>
</n:passenger>
<!-- extensible headers -->
</soap:Header>
<soap:Body>
<p:departure....> </p:departure>
<p:return....>
</p:return>
<!-- payload -->
</soap:Body>
</soap:Envelope>
24
Descrizione - WSDL
WSDL (Web Services Description Language ) si preoccupa
di definire un meccanismo standard per descrivere un
WS:
 Interfaccia astratta. Si descrivono le funzionalità (what)
e il tipo di servizio offerto.
 Binding concreto. Si descrive come (how) si realizza il
collegamento dell’interfaccia con i protocolli concreti
 Implementazione. Si descrive il dove (where) cioè
tramite quale porta si realizza il binding. Ciascuna porta
specifica il punto di accesso del servizio.
25
Organizzazione di un documento
WSDL
In dettaglio:







Types -- contenitore per i tipi di dati usati nei msg scambiati con il
servizio
Message – una definizione dei dati che devono essere comunicati
Port type – un insieme di operazioni offerte dal servizio
Operation – descrizione astratta di un’azione supportata da un
servizio
Binding – protocollo completo e specifica del formato dei dati per
un particolare port type
Port – porta di accesso, un servizio può avere anche più porte
ciascuna con un nome e un protocollo di binding.
Service – descrive dove il WS risiede attraverso uno specifico
indirizzo URL .
26
Esempio: layout di un documento
Wsdl
27
Scoperta – UDDI 1
La funzione di scoperta si realizza tramite UDDI (Universal Description,
Discovery and Integration ) che offre un meccanismo standard per
registrare e ricercare i WS:
 Tipo di servizio: si definisce il servizio e si assegna a questo un
identificatore unico chiamato tModel. Un tModel punta a una specifica che
definisce una risorsa. Oltre al servizio si definisce un’interfaccia astratta.
Pagine bianche

Service providers registra i businesses e tutti i servizi che offrono. Tramite
il costrutto Template fornisce info sul binding e sul punto di accesso.
Pagine verdi

Categorizzazione: si usa una varietà di categorie per classificare le entità in
base alla localizzazione geografica, al codice prodotto ecc.
Pagine gialle
28
Scoperta – UDDI 2



Ricerca. I service consumer possono ricercare il servizio
effettuando queries al registro Uddi, questa ricerca può avvenire
tramite tipo di servizio o service provides. Nel caso di una intranet,il
broker può cercare prima i service provider interni e poi altri broker
su Internet se tali servizi non esistono localmente.
Binding : il collegamento tra client e servizio può avvenire sia in
fase di compilazione che di runtime.
Statico: La ricerca di un service viene effettuata una volta sola
e se ne memorizza il risultato. Quindi la localizzazione dei
servizi si conosce prima di iniziare l’esecuzione del programma
e si tratta di indirizzi assoluti.
Dinamico: la ricerca viene effettuata in fase di runtime e di
solito perché è stata modificata la posizione del servizio.
Scoperta dinamica. Siccome Uddi è esso stesso un WS,
un’applicazione può fare richieste al servizio, trovare
dinamicamente il servizio, localizzare il suo punto di accesso,
recuperare il Wsdl e collegarsi ad esso tutto in runtime.
29
Sommario di una struttura
funzionale WSA
30
Riassumendo



XML Web service è un software service esposto
sul Web tramite SOAP, descritto con un file
WSDL è registrato in UDDI
Quando un provider vuole rendere il servizio
disponibile ai consumers, descrive il servizio
utilizzando WSDL e lo registra in un UDDI
registry.
Quando un consumer vuole usare il servizio,
chiede al registro UDDI di trovare quello che
meglio risponde alle sue necessità. Ottiene il
punto di accesso e la descrizione WSDL con la
quale costruisce i msg SOAP e comunica con il
servizio.
31
WSA (Web Services Architecture)
Invocation mechanism


Inizialmente non era stato definito uno specifico
meccanismo di invocazione dei servizi ma soltanto i protocolli
di comunicazione. Le specifiche di come le applicazioni
interagiscono con Soap e Wsdl sono state lasciate, e quindi
realizzate, dalle application community ( Microsoft, Java).
Questi meccanismi permettono alle applicazioni di analizzare e
trattare messaggi Xml ma soprattutto di costruire,
semplicemente e direttamente, il msg Xml, di inserirlo in una
busta Soap e scambiarlo.
32
WSA Invocation mechanism
• XML-RPC: una chiamata di procedura remota(RPC) è una
richiesta all’applicazione server da un’altra locazione per
realizzare operazioni e restituire informazioni.
• XML-RPC è un semplice protocollo che permette al software
di girare in ambienti diversi per realizzare chiamate di
procedure remote in internet e stabilire una vasta gamma di
connessioni tra i computer.
• XML-RPC usa due standards: XML per codificare i messaggi,
e HTTP per trasportarli.Un msg XML-RPC propriamente
formattato è una richiesta HTTP POST il cui body è in XML.
Il server remoto specificato esegue la chiamata e restituisce i
dati richiesti in formato XML.
33
WSA Invocation mechanism




JWSDL(Java Api for Wsdl) Toolkit usato per costruire , testare e
implementare applicazioni Xml, WS e applicazioni Web con le più
recenti tecnologie e implementazioni standard. Offre un Api per
creare,controllare e manipolare documenti Wsdl.
JAXM(Java Api for Xml Messagging) offre un’ interfaccia per
costruire un messaggio. Determina la struttura di un msg Soap e
costruisce dinamicamente l’envelope, l’header e il body Soap.
L’applicazione client semplicemente aggiunge l’Xml payload al msg.
SAAJ(Soap with attachments Api) offre un’interfaccia Soap.
L’applicazione client può usare Saaj per costruire manualmente,
processare e inviare un msg Soap in rete dalla piattaforma Java.
JAXR(Java Api for Xml Registries) è un Api che può esser usata per
accedere a una varietà di registri Xml, incluso quelli UDDI. Essendo
un registro generico Api, il modello dei dati Jaxr è diverso dal
modello dei dati Uddi.
34
Implementazione di una WSA
Per la costruzione e l’implementazione dei WS è
possibile utilizzare:
 Le tecnologie basate su XML viste prima oppure
 le cosiddette Web Service Platform.
Il vantaggio nell’utilizzo di una piattaforma
gli sviluppatori non devono preoccuparsi
della costruzione e dell’implementazione dei
messaggi Soap. Scrivono il codice che
implementa il sevizio e a tutto il resto
provvede la piattaforma.
35
WS Platform
Generalmente è formata da:

Strumenti di sviluppo , utilizzati per creare WS,
descrizioni Wsdl, per generare client proxies
(usati per mandare msg al servizio) e per
registrare e cercare nel registro Uddi.

Server runtime analizza tutti i msg Soap e
offre un container runtime per WS.

Strumenti di gestione permettono di effettuare
tutte le operazioni necessarie
all’amministrazione dei WS
36
Esempio1: HP Web Services Platform 2.0
HP Web Services Platform 2.0
include:
 HP-SOAP 2.0 - SOAP server and XML document
pipeline-processing framework; features XML Digital
Signature security capabilities
 HP Service Composer - graphical tool for creating and
mapping WSDL interfaces; features automatic
deployment to HP-AS 8.0
 HP Registry Composer - graphical tool for registering and
discovering Web services in UDDI registries via UDDI4J
Java API
 Useful trail map tutorials, documentation, and use case
examples to expedite the Web services learning process
37
WS e la rete



I Web service hanno guadagnato consensi perchè, come
protocollo di trasporto, possono utilizzare HTTP "over" TCP
sulla porta 80; tale porta è, normalmente, una delle poche (se
non l'unica) lasciata "aperta" dai sistemi firewall al traffico di
entrata ed uscita dall'esterno verso i sistemi aziendali.
Su tale porta transita il traffico HTTP dei web browser: ciò
consente l'utilizzo dei Web Service senza modifiche sulle
configurazioni di sicurezza dell'azienda (un aspetto che se da
un lato è positivo solleva preoccupazioni concernenti la
sicurezza).
Un‘altra ragione che ha favorito l'adozione ed il proliferare dei
Web Service è la mancanza, prima dello sviluppo di SOAP, di
interfacce realmente funzionali per l'utilizzo di funzionalità
distribuite in rete: EDI, RPC, ed altri tipi di API (Application
Programming Interface), anche se più facili da utilizzare, erano
e rimangono meno conosciute rispetto all'architettura dei Web
38
Service