Lezione 8: Introduzione ai
Web Service
Corso di Programmazione in Rete
Laurea Magistrale in Ing. Informatica
Università degli Studi di Salerno
1

Outline
✦ Limiti dei middleware tradizionali
✦ Dalle web application ai web service
✦ Protocolli e standard
✦ Service Oriented Architecture
2

Limiti dei middleware tradizionali
✦ I middleware tradizionali funzionano
egregiamente quando le diverse
applicazioni che devono comunicare tra
loro sono sviluppate dalla stessa
organizzazione/azienda
✦ Nei sistemi informativi aziendali però
spesso nasce l’esigenza di far comunicare
applicazioni sviluppate da organizzazioni/
aziende diverse
3

Limiti dei middleware tradizionali
✦ Esempi
• commercio elettronico Business-to-Business (B2B)
(es. automazione degli ordini ai fornitori)
• fornitura di servizi in forma elettronica (es.
verifica e gestione pagamenti con carta di credito)
• interoperabilità tra i sistemi informativi di aziende
che effettuano una fusione
4

Limiti dei middleware tradizionali
✦ Problema: alcuni middleware impongono
una limitazione sul sistema operativo/
architettura hardware da utilizzare
• Esempio: DCOM/COM+ di Microsoft, disponibile
solo per sistemi operativi della famiglia Windows
5

Limiti dei middleware tradizionali
✦ Problema: alcuni middleware per ottenere
l’indipendenza da sistema operativo e
hardware impongono una limitazione sul
linguaggio di programmazione da
utilizzare
• Esempio: RMI è indipendente dal sistema
operativo, ma è utilizzabile solo da Java e dai
(pochi) linguaggi che producono codice JVM
6

Limiti dei middleware tradizionali
✦ Problema: alcuni middleware per ottenere
l’indipendenza da sistema operativo dal
linguaggio diventano estremamente
complessi e introducono dipendenze dal
vendor della specifica implementazione
• Esempio: CORBA è un middleware indipendente
dal linguaggio e dalla piattaforma hardware/
software, ma è significativamente più complesso
di RMI e spesso ci sono problemi di compatibilità
tra le implementazioni di vendor diversi
7

Limiti dei middleware tradizionali
✦ Anche quando per la comunicazione tra
due aziende si riesce a trovare un
middleware comune, se un’azienda deve
comunicare con n altre aziende potrebbe
essere necessario usare n middleware
diversi
8

Dalle web application ai web service
✦ Il problema dell’interoperabilità è invece
“ragionevolmente” risolto per le
applicazioni Business-to-Consumer (B2C)
• le applicazioni B2C sono realizzate come
applicazioni web
• esistono degli standard consolidati per protocolli e
formati (HTTP, HTML, CSS)
• gli sviluppatori possono realizzare le applicazioni
usando qualunque piattaforma/linguaggio, e con
le opportune precauzioni ottenere la compatibilità
con tutti i client più diffusi
9

Dalle web application ai web service
✦ Perché non sfruttare la standardizzazione
offerta dalle web application per la
comunicazione tra applicazioni?
• tecnologia matura
• tecnologia familiare alla maggior parte degli
sviluppatori (a differenza dei middleware)
10

Dalle web application ai web service
✦ Sin dagli anni ’90 diversi sviluppatori
hanno cominciato a esplorare la
possibilità di far utilizzare una web
application da un altro programma con
tecniche “ad hoc” (Web scraping)
• il client “simula” il comportamento di un web
browser per inviare una richiesta all’applicazione
web
• il client estrae le informazioni a cui è interessato
dalla pagina HTML ottenuta come risposta
11

Dalle web application ai web service
✦ Vantaggi
• automazione dell’uso di una web application
✦ Problemi
• le pagine HTML contengono sia le informazioni
che la logica di presentazione delle stesse, e non
è banale separare le prime dalla seconda
• spesso le pagine HTML di un’applicazione web
vengono cambiate; mentre il cambiamento non
crea problemi a un utilizzatore umano, può
rendere non funzionante un applicativo che attua
il web scraping
12

Dalle web application ai web service
✦ Per superare questi problemi è nata l’idea
di applicazioni web specificamente
progettate per essere usate da altre
applicazioni anziché da esseri umani
• i protocolli di comunicazione rimangono gli stessi
• le informazioni non sono più scambiate in HTML,
ma devono essere in un formato più semplice da
analizzare per un programma
• nasce quindi l’esigenza di nuovi standard
✦ Un’applicazione di questo tipo diventa un
Web Service
13

Dalle web application ai web service
✦ Definizione di Web Service
• un software che supporta un’interazione
“machine-to-machine” attraverso la rete, usando
protocolli che garantiscano l’interoperabilità
• quasi sempre si fa riferimento al protocollo HTTP
(o HTTPS), anche se non è una condizione
necessaria
14

Protocolli e standard
✦ I protocolli per i web service usano tre
architetture diverse:
• RPC oriented
• Message oriented
• REpresentational State Transfer (REST)
15

Architettura RPC oriented
✦ Basata sul concetto di Remote Procedure
Call (RPC) dei middleware tradizionali
• il client invia al server una richiesta usando
l’operazione POST del protocollo HTTP
(normalmente usata per l’invio dei form)
• l’URL è generalmente fissa e associata all’intera
applicazione server
• la richiesta contiene il nome della “procedura
remota” da invocare e i parametri
• il server invia il risultato al client come risposta
HTTP
16

XML-RPC
✦ Il primo protocollo specificamente
sviluppato per i web service è stato
XML-RPC
• creato da UserLand Software e Microsoft nel 1998
• non è mai diventato uno standard “de iure”, il che
ne ha limitato la diffusione in contesti aziendali
• molto semplice da implementare sulla base di
tecnologie esistenti, per cui è usato spesso in
progetti amatoriali, e sono disponibili
implementazioni open source per tutte le
principali piattaforme
17
• progenitore di tutti sistemi RPC oriented

XML-RPC
✦ La richiesta e la risposta sono formulate
in linguaggio XML
• sfrutta la disponibilità di parser XML su tutte le
principali piattaforme
• è semplice generare XML con le tecnologie
normalmente usate per generare HTML
✦ Definisce regole univoche per la codifica
dei principali tipi di dato (es. interi, reali,
stringhe, array, strutture)
18

XML-RPC
✦ Problemi
• non definisce meccanismi per gestire tipi di dato
diversi da quelli predefiniti
• non supporta direttamente funzionalità avanzate
come autenticazione, gestione delle transazioni
ecc.
• non c’è una definizione formale dell’interfaccia
delle procedure remote; eventuali errori o
incongruenze vengono scoperti solo a tempo di
esecuzione
19

SOAP
✦ Simple Object Access Protocol (SOAP),
definito da Microsoft nel 1998 per ovviare
ai limiti di XML-RPC
• basato su XML
• accettato come standard dal consorzio W3C
• supportato dai principali ambienti di sviluppo
• lo standard separa il formato dei messaggi dal
modo in cui sono veicolati attraverso un protocollo
già esistente; SOAP può usare protocolli diversi da
HTTP, come SMTP
20

SOAP
✦ Più complesso di XML-RPC...
• è meno semplice da implementare, per questo il
numero di implementazioni open source è minore
✦ ... ma anche più versatile
• consente di estendere l’insieme dei tipi da usare
come parametri e valori di ritorno
• consente di estendere il protocollo stesso per
aggiungere funzionalità come la sicurezza o la
gestione delle transazioni senza perdere
l’interoperabilità
21

WSDL
✦ Inizialmente anche per SOAP valeva il
problema della mancanza di una
definizione formale dell’interfaccia del
server
✦ Nel 2000, IBM introduce Web Service
Description Language (WSDL), un
linguaggio per definire le interfacce di WS
basati su SOAP
• basato su XML
• accettato come standard dal W3C (versione 2.0)
22

WSDL
✦ Un documento WSDL contiene una
specifica “machine-readable” di:
• punti di accesso ai web service
• protocolli utilizzati
• operazioni disponibili, con i rispettivi parametri e
valori di ritorno
• tipi non predefiniti usati dalle operazioni
23

WSDL
✦ In teoria, un documento WSDL dovrebbe
essere in un formato leggibile e
modificabile da un essere umano
✦ In pratica, il formato è piuttosto
complesso, per cui i file WSDL devono
essere generati da appositi tool o librerie
• in alcuni ambienti il WSDL viene generato
automaticamente dalla definizione della classe del
server che implementa il Web Service
24

WSDL
✦ I principali ambienti di sviluppo offrono
tool che ricavano automaticamente da un
file WSDL le classi che realizzano la
comunicazione dal lato client
✦ Tipicamente il WSDL è disponibile on-line
sul sito che ospita il web service
• usato a tempo di esecuzione per verificare che
non ci siano state modifiche dell’interfaccia server
• usato in linguaggi dinamici per creare a tempo di
esecuzione le classi che rappresentano la
comunicazione lato client
25

SOAP+WSDL
✦ La combinazione SOAP+WSDL consente
(grazie al supporto dei principali ambienti
di sviluppo) di realizzare web service con
uno sforzo di programmazione contenuto,
sia dal lato server che dal lato client
✦ L’interoperabilità è garantita dall’uso di
protocolli e formati standardizzati
✦ Perciò la maggior parte dei progetti
commerciali usa questa soluzione
26

UDDI
✦ Per aumentare l’interoperabilità è stato
introdotto il servizio Universal Description
Discovery and Integration (UDDI)
• è un web service basato su SOAP+WSDL
• realizza un repository di descrizioni WSDL con
funzioni di pubblicazione e ricerca di web service
in base a una serie di metadati (es. costo, qualità
del servizio ecc.)
27

UDDI
✦ Lo standard UDDI inizialmente ipotizzava
lo sviluppo di un Universal Business
Registry pubblico che consentisse una
ricerca globale dei web service
✦ Attualmente l’idea di un UBS è stata
abbandonata, e i servizi UDDI sono usati
principalmente in ambito intranet come
repository centralizzato di WSDL
• in questo caso il vantaggio è una maggiore
indipendenza del client dall’indirizzo del server
28

Architetture Message oriented
✦ SOAP e WSDL non vincolano i web
service al protocollo HTTP ma consentono
di utilizzare altri protocolli come
“trasporto”
✦ Con HTTP la comunicazione è sincrona
• il client attende la risposta alla sua richiesta prima
di procedere
✦ Usando altri protocolli (come SMTP) è
possibile una comunicazione asincrona
29

Architetture Message oriented
✦ In un’architettura di servizi “Message
oriented” (detta anche “Document
oriented”) le diverse applicazioni si
scambiano messaggi unidirezionali
• il focus è sul messaggio più che sull’operazione
• se una richiesta genera una risposta, questa è
inviata con un messaggio indipendente dal
messaggio di richiesta
• il servizio non è tenuto a elaborare i messaggi che
riceve in ordine di ricezione
• è sfumata la distinzione tra client e server;
l’architettura diventa peer-to-peer
30

Architetture Message oriented
✦ Vantaggi
• disaccoppiamento anche temporale tra client e
server: se il server non è momentaneamente
disponibile il messaggio può essere mantenuto in
una coda
• maggiore flessibilità nella distribuzione (es.
smistamento “intelligente” dei messaggi tra più
server)
• maggiore flessibilità nell’ordine delle operazioni
(es. priorità diverse per i messaggi)
31

Architetture Message oriented
✦ Svantaggi
• difficile da usare se l’operazione ha
intrinsecamente una logica sincrona (es.
interazione con l’utente)
• dal punto di vista dello sviluppatore si perde
l’analogia tra l’accesso all’applicazione remota e
l’invocazione di un sottoprogramma
• è necessario che il layer di trasporto dei messaggi
sia “affidabile”, dal momento che il mittente non
ha una risposta attraverso cui verificare se
l’operazione è andata a buon fine
32

Architetture REST
✦ Nelle architetture RPC oriented
• si usa una sola URL associata all’intera
applicazione e una sola operazione di HTTP
(POST)
• i dati inviati e ricevuti hanno un formato
complesso, che cerca di uniformare tutte le
possibili esigenze (presenti e future)
✦ Nel web tradizionale
• un sito usa URL distinte per diverse parti del suo
contenuto
• ogni URL può corrispondere un formato diverso, e
il formato può essere negoziato tra client e server
33

Architetture REST
✦ A partire dal 2000 alcuni sviluppatori
hanno cominciato a contestare
l’architettura RPC, in quanto poco
allineata alla filosofia del web
• complessa da realizzare senza supporto di
ambienti di sviluppo specifici
• problemi con alcune tecnologie web come web
proxy, cache etc.
34

Architetture REST
✦ In alternativa è stata proposto uno stile
architetturale denominato
REpresentational State Transfer (REST)
• ogni “elemento di informazione” dell’applicazione
ha una sua URL
• si usano le operazioni standard di HTTP (GET, PUT,
POST, DELETE) per leggere, modificare,
aggiungere o cancellare informazioni
• si usano i meccanismi standard di HTTP per la
negoziazione del formato con cui le informazioni
vengono scambiate
35

Architetture REST
✦ Vantaggi
• maggiore semplicità di implementazione
• spesso migliore utilizzo della banda grazie alla
possibilità di usare formati più compatti di SOAP
• interazione corretta con tutte le tecnologie web
(es. motori di ricerca, proxy, cache)
36

Architetture REST
✦ Alcune importanti aziende hanno adottato
REST per i propri web service (es.
Google, Amazon, Twitter, tutti i principali
blog)
✦ I servizi REST non sono però supportati
dagli ambienti di sviluppo basati su WSDL
• WSDL 2.0 include il supporto per i servizi REST
• però la maggior parte dei tool è ancora basata su
WSDL 1.1
37

Service Oriented Architecture
✦ WS vs middleware tradizionali
• i middleware tradizionali sono più efficienti
• i middleware tradizionali sono più semplici da
usare se l’applicazione è sotto il controllo di
un’unica organizzazione/azienda
• i web service garantiscono maggiore
interoperabilità
• i web service in questo momento sono “di moda”
38

Service Oriented Architecture
✦ Oltre che per risolvere i problemi di
comunicazione “al confine” tra due
organizzazioni/aziende, i WS possono
essere usati anche per rendere più
modulare il software all’interno di una
singola organizzazione/azienda
✦ Si parla in tal caso di Service Oriented
Architecture (SOA)
‣ NOTA: alcuni usano impropriamente il termine SOA solo
per architetture basate su servizi Message oriented, o
come sinonimo di Message oriented
39

Service Oriented Architecture
✦ Principi della Service Oriented
Architecture:
• il sistema è decomposto in un insieme di servizi
che comunicano via rete
• i servizi sono fortemente indipendenti tra loro
(loose coupling)
• i servizi sono interoperabili e componibili per
realizzare gli obiettivi del sistema
40

Service Oriented Architecture
✦ Un approccio SOA rende più modulare e
manutenibile il software
• si adatta bene ad aziende di grandi dimensioni,
specialmente se con una struttura interna
articolata e complessa
✦ Tuttavia una suddivisione troppo spinta
può portare degli inconvenienti
• ridondanza delle informazioni
• overhead sulle prestazioni
✦ Perciò è importante individuare la giusta
granularità di decomposizione
41