Introduzione ad Architetture Orientate ai Servizi e Web Service

Università degli Studi di Roma “Tor Vergata”
Facoltà di Ingegneria
Introduzione ad Architetture Orientate ai
Servizi e Web Service
Corso di Sistemi Distribuiti
Valeria Cardellini
Anno accademico 2009/10
Service Oriented Architecture
• Service Oriented Architecture (SOA): paradigma
architetturale per la progettazione di sistemi sw
• Tre entità che interagiscono tra loro
– Service requestor: richiede l’esecuzione di un servizio
– Service provider: implementa il servizio e lo rende disponibile
– Service registry: offre un servizio di pubblicazione e di ricerca
di servizi disponibili
Il servizio è
pubblicato in
una directory
di servizi
Il requestor
cerca i dettagli
sul servizio in
una directory di
servizi
SD - Valeria Cardellini, A.A. 2009/10
Il requestor si collega al
provider ed invoca il servizio,
interagendo con esso
1
SOA e Web service
• SOA è l’architettura di riferimento per i Web service
• Ma SOA è una filosofia progettuale indipendente da
una specifica tecnologia
– Ad es. anziché con i Web service, può essere implementata
in Java, C# o JEE
SD - Valeria Cardellini, A.A. 2009/10
2
Definizione di Web service
• Definizione tratta dal tutorial introduttivo dell’IBM
“Web Services - The Web's next revolution”
– Si focalizza sull’integrazione dei Web service in Internet e
sulle interazioni con i sistemi sw in essa operanti
Web services are a new breed of Web application.
They are self-contained, self-describing, modular
applications that can be published, located, and invoked
across the Web.
Web services perform functions that can be anything from
simple requests to complicated business processes.
A sample Web service might provide stock quotes or
process credit card transactions.
Once a Web service is deployed, other applications (and
other Web services) can discover and invoke the deployed
service.
SD - Valeria Cardellini, A.A. 2009/10
3
Definizione di Web service (2)
• Definizione fornita del W3C
http://www.w3.org/TR/ws-arch/
– Si focalizza sulla definizione del contesto tecnologico nel
quale operano i Web service e sugli standard da utilizzare
A Web service is a software system designed to support
interoperable machine-to-machine interaction over a
network.
It has an interface described in a machine-processable
format (specifically WSDL).
Other systems interact with the Web service in a manner
prescribed by its description using SOAP messages,
typically conveyed using HTTP with an XML serialization
in conjunction with other Web-related standards.
SD - Valeria Cardellini, A.A. 2009/10
4
Un Web service può essere…
• Un business task auto-contenuto
– Ad es. un servizio di preliveo o di deposito fondi
• Un business process
– Ad es. l’acquisto automatico di prodotti per l’ufficio
• Un’applicazione
– Ad es. un programma per la gestione degli stock di
magazzino
• Una risorsa accessibile come servizio
– Ad es. l’accesso ad un DB contenente gli archivi di un
ospedale
SD - Valeria Cardellini, A.A. 2009/10
5
Caratteristiche dei Web service
• Rappresentano una soluzione per permettere
l’interazione e l’interoperabilità tra applicazioni in
ambito Web
– Integrazione B2B
• Si basano sull’idea di fornire un linguaggio ed una
piattaforma interoperabile, comune a sistemi differenti
• Sono una combinazione di diversi standard tecnologici,
di tipo aperto (XML, HTTP, SOAP, …) che permettono
a chiunque di utilizzarli
• Sono accessibili mediante un’interfaccia standard
• Permettono a sistemi eterogenei di lavorare insieme
per realizzare il service oriented computing (SOC)
– Programmazione con componenti distribuite sul Web
SD - Valeria Cardellini, A.A. 2009/10
6
Web service
• Componente software indipendente dalla piattaforma e
dall’implementazione che può essere:
– Descritto usando un linguaggio di descrizione del servizio
– Pubblicato in un registro di servizi
– Scoperto mediante un meccanismo standard (a runtime o a
tempo di progetto)
– Invocato su rete mediante un’API
– Composto con altri servizi
SD - Valeria Cardellini, A.A. 2009/10
7
Web service (2)
• Componente software indipendente dalla piattaforma e
dall’implementazione che può essere:
– Descritto usando un linguaggio di descrizione del servizio
– Pubblicato in un registro di servizi
– Scoperto mediante un meccanismo standard (a runtime o a tempo
di progetto)
– Invocato su rete mediante un’API
– Composto con altri servizi
Un client non può dire quale linguaggio, sistema
operativo o tipo di computer è stato usato
Non possono essere inviati o ricevuti dati binari (ma ci
sono eccezioni)
<name>Character data
</name><cost>123.45</cost>
<response>Character data
</response>
SD - Valeria Cardellini, A.A. 2009/10
8
Web service (3)
• Componente software indipendente dalla piattaforma e
dall’implementazione che può essere:
– Descritto usando un linguaggio di descrizione del servizio
– Pubblicato in un registro di servizi
– Scoperto mediante un meccanismo standard (a runtime o a tempo
di progetto)
– Invocato su rete mediante un’API
– Composto con altri servizi
Un Web service deve descrivere se stesso: quali tipi di
richieste può soddisfare, quali sono gli argomenti,
quale è il trasporto
What information do you
need?
2 arguments:
(1) Item name (2) Quantity
SD - Valeria Cardellini, A.A. 2009/10
9
Web service (4)
• Componente software indipendente dalla piattaforma e
dall’implementazione che può essere:
– Descritto usando un linguaggio di descrizione del servizio
– Pubblicato in un registro di servizi
– Scoperto mediante un meccanismo standard (a runtime o a tempo
di progetto)
– Invocato su rete mediante un’API
– Composto con altri servizi
Un Web service deve indicare ad un registro di servizi
dove è localizzato
Here I am
Where is a service that I can use
to find airline flight schedules?
SD - Valeria Cardellini, A.A. 2009/10
10
Web service (5)
• Componente software indipendente dalla piattaforma e
dall’implementazione che può essere:
– Descritto usando un linguaggio di descrizione del servizio
– Pubblicato in un registro di servizi
– Scoperto mediante un meccanismo standard (a runtime o a tempo
di progetto)
– Invocato su rete mediante un’API
– Composto con altri servizi
Un potenziale client deve trovare il Web service in un
registro di servizi
Here I am
Where is a service that I can use
to find airline flight schedules?
SD - Valeria Cardellini, A.A. 2009/10
11
Web service (6)
• Componente software indipendente dalla piattaforma e
dall’implementazione che può essere:
– Descritto usando un linguaggio di descrizione del servizio
– Pubblicato in un registro di servizi
– Scoperto mediante un meccanismo standard (a runtime o a tempo
di progetto)
– Invocato su rete mediante un’API
– Composto con altri servizi
Gli argomenti ed i tipi di dato restituiti devono essere noti
API nota
<name>Character data
</name><cost>123.45</cost>
<response>Character data
</response>
SD - Valeria Cardellini, A.A. 2009/10
12
Web service (7)
• Componente software indipendente dalla piattaforma e
dall’implementazione che può essere:
– Descritto usando un linguaggio di descrizione del servizio
– Pubblicato in un registro di servizi
– Scoperto mediante un meccanismo standard (a runtime o a tempo
di progetto)
– Invocato su rete mediante un’API
– Composto con altri servizi
Il servizio può a sua volta essere un client di
un altro servizio
<name>Character data
</name><cost>123.45</cost>
<response>Character data
</response>
SD - Valeria Cardellini, A.A. 2009/10
13
Classificazione dei servizi
• Servizi semplici e servizi composti
– Servizi semplici: supportano semplici operazioni
richiesta/risposta
– Servizi composti: implementano una qualche forma di
coordinazione tra operazioni in ingresso ed uscita
– Possono anche essere stateless o stateful
• Servizi sincroni e servizi asincroni
– Servizi sincroni: modello di comunicazione sincrono (RPCstyle)
– Servizi asincroni: modello di comunicazione asincrono
(message-driven o document-style)
SD - Valeria Cardellini, A.A. 2009/10
14
Pila protocollare dei Web service
• Aspetti funzionali
– Protocollo di trasporto: invio e ricezione di richieste e risposte
tra service requestor e service provider
– Protocollo di comunicazione: scambio di messaggi basato su
XML
– Descrizione del servizio: interfaccia funzionale del servizio
– Business process: composizione dei servizi
– Scoperta dei servizi: definizione dei service registry
SD - Valeria Cardellini, A.A. 2009/10
15
Standard per i Web service
• Il service provider costruisce e definisce il servizio
usando WSDL
Web Services Description Language (WSDL)
http://www.w3.org/TR/wsdl.html
http://www.w3.org/TR/wsdl20-primer/
• Il service provider registra il servizio mediante UDDI
Universal Description Discovery and Integration (UDDI)
http://www.uddi.org/
• Il service requestor trova il servizio cercando in un
registro UDDI
• Il service requestor si collega al Web service fornito
dal service requestor ed invoca le sue operazioni
mediante SOAP
Simple Object Access Protocol (SOAP)
http://www.w3.org/TR/soap12-part0/
SD - Valeria Cardellini, A.A. 2009/10
16
Stack tecnologico dei Web service
SD - Valeria Cardellini, A.A. 2009/10
17
XML e Web service
• I Web service si basano sul linguaggio XML perché
indipendente da linguaggi, applicazioni e piattaforme
specifiche
• XML garantisce
–
–
–
–
Ricchezza espressiva
Estendibilità
Portabilità
Facilità di comprensione
• Gli schemi XML possono essere validati da entrambe
le parti che comunicano
SD - Valeria Cardellini, A.A. 2009/10
18
Simple Object Access Protocol
• Simple Object Access Protocol (SOAP)
• Protocollo di comunicazione tra Web service basato
su XML per scambiare dati, invocare metodi remoti e
codificarne gli esiti usando un protocollo applicativo
sottostante (HTTP, SMTP, FTP, …), detto protocollo
di “trasporto”
– XML permette di scambiare strutture dati anche complesse
nel payload del messaggio SOAP
– Serializzazione dei dati in XML
• Protocollo leggero, robusto e flessibile
• Indipendente dalla piattaforma e dal linguaggio di
programmazione
SD - Valeria Cardellini, A.A. 2009/10
19
Motivazioni per SOAP
• Molte applicazioni distribuite comunicano usando RPC
tra oggetti distribuiti (ad esempio, DCOM e CORBA)
• HTTP non è progettato per questi oggetti
– Non è facile adattare ad Internet le chiamate RPC
• Esistono anche problemi di sicurezza per RPC
– La maggior parte dei firewall e dei proxy server sono impostati
per bloccare questo tipo di traffico
• Perché SOAP usa HTTP?
– Ampio supporto di HTTP nel Web
– HTTP è un protocollo applicativo firewall-friendly
SD - Valeria Cardellini, A.A. 2009/10
20
Obiettivi di SOAP
• Aumentare l’interoperabilità rispetto a soluzioni
proprietarie
– Ottenibile grazie all’uso di XML e HTTP
• Permettere una facile manutenibilità ed
aggiornamento
– Il formato del payload in XML può essere esteso facilmente
• Eliminare le limitazioni dovute alle politiche di
sicurezza
– L’uso di HTTP e messaggi testuali permette di utilizzare
proxy Web
– Controllo degli header HTTP da parte di firewall
SD - Valeria Cardellini, A.A. 2009/10
21
Limitazioni di SOAP
• Non è ottimale a livello di prestazioni
– I dati sono serializzati in XML
– La deserializzazione richiede di usare un parser XML per
estrarre i dati dal payload
• La comunicazione supportata da SOAP è asincrona
e senza persistenza dello stato
– Come HTTP, SOAP non è in grado di mantenere
nativamente informazioni di stato fra una connessione e
l’altra
• WS-Security definisce come implementare scambi
sicuri con SOAP
SD - Valeria Cardellini, A.A. 2009/10
22
Cosa definisce SOAP
• Specifica della SOAP envelope (busta)
– Definisce il modo di incapsulare i dati da scambiare fra host
– In caso di errore definisce il formato del messaggio di fault
• Regole di codifica dei dati
– Definisce la codifica con cui sono scambiati i dati (es. numeri
float)
– Vengono utilizzate le definizioni di XML schema
• Convenzioni per definire una Remote Procedure Call
– Definisce come specificare il nome della procedura da
chiamare, passare i parametri e ricevere la risposta (valore di
ritorno)
SD - Valeria Cardellini, A.A. 2009/10
23
Struttura del messaggio SOAP
• SOAP envelope
– Identifica il documento XML
come messaggio SOAP
SOAP Message
HTTP Headers
• SOAP header (opzionale)
– Contiene informazioni
aggiuntive per il
processamento del
messaggio da parte di
intermediari posti tra service
requestor e provider
• SOAP body
– Contenuto vero e proprio del
messaggio
– Contiene chiamate o risposte
SOAP Envelope
SOAP Header
SOAP Body
Payload Document(s)
SOAP Fault
• SOAP fault
– Contiene informazioni su
eventuali errori occorsi
durante il processamento
SD - Valeria Cardellini, A.A. 2009/10
24
Struttura del messaggio SOAP (2)
SOAP Message
HTTP Headers
SOAP Envelope
Il messaggio SOAP
Header HTTP standard più header
HTTP specifici per SOAP
<Envelope> Info globali
SOAP Header
<Header> Tag per racchiudere gli header
SOAP Body
<Body> contiene SOAP
Message Name & Data
Payload Document(s)
XML Encoded SOAP
Message Name & Data
SOAP Fault
SD - Valeria Cardellini, A.A. 2009/10
25
Struttura del messaggio SOAP (3)
<?xml version=“1.0” encoding=“UTF-8”>
<env:Envelope
xmlns:env=“http://www.w3.org/2003/05/soapenvelope”>
<env:Header> <!-- optional -->
<!-- Content of header goes here -->
</env:Header>
<env:Body>
<!– Payload or Fault element goes here -->
</env:Body>
</env:Envelope>
SD - Valeria Cardellini, A.A. 2009/10
26
Esempio richiesta SOAP su HTTP
• Esempio: messaggio di richiesta di prenotazione di un
biglietto aereo
• Tratto da http://www.w3.org/TR/soap12-part0/
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
Vedi lucido successivo
SD - Valeria Cardellini, A.A. 2009/10
Header
Headerdella
dellarichiesta
richiestaHTTP
HTTP
(utilizza
il
metodo
POST)
(utilizza il metodo POST)
Envelope
Envelopedella
dellarichiesta
richiestaSOAP
SOAP
27
Envelope
Header
Body
SD - Valeria Cardellini, A.A. 2009/10
28
Esempio risposta SOAP su HTTP
Header
Headerdella
dellarisposta
rispostaHTTP
HTTP
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soapenvelope" >
<env:Header>
...
...
</env:Header>
<env:Body>
...
...
</env:Body>
</env:Envelope>
Envelope
Envelopedella
dellarisposta
rispostaSOAP
SOAP
(contiene
il
valore
(contiene il valoredi
diritorno)
ritorno)
SD - Valeria Cardellini, A.A. 2009/10
29
Descrizione dei servizi
• Una volta che il Web service è attivo, come fanno i
service requestor a sapere come richiedere il servizio?
– SOAP non basta: specifica solo la struttura del messaggio
• Per garantire l’interoperabilità fra sistemi eterogenei
occorre un meccanismo che permetta a requestor e
provider di capire l’esatta struttura ed il tipo di dati dei
messaggi
– Occorre dire al requestor quale tipo di messaggio XML può
inserire nel body del messaggio SOAP
• Web Services Description Language (WSDL) è un
IDL basato su XML e consente di descrivere un
servizio in modo strutturato
• Un documento WSDL fornisce la descrizione
funzionale del servizio (la sua interfaccia), specificando
il formato dei messaggi di richiesta e di risposta
SD - Valeria Cardellini, A.A. 2009/10
30
Web Service Description Language
• Un documento WSDL è un tipo di documento XML
contenente informazioni sul Web service riguardanti
– La semantica dell’interfaccia
– Dettagli amministrativi per la chiamata del Web service
• Quando un service requestor vuole usare un Web
service
– Individua il servizio (ad es. tramite UDDI)
– Richiede il file WSDL
– Analizza il file WSDL per determinare
• La locazione del servizio
• Le chiamate dei metodi ed i parametri
• Come accedere ai metodi
– Crea una richiesta SOAP
– Invia la richiesta SOAP al servizio
SD - Valeria Cardellini, A.A. 2009/10
31
Cosa descrive WSDL?
• Le operazioni fornite dal servizio
• Dettagli sui formati dei dati e sui protocolli necessari
per accedere al servizio
– XML Schema
• Dettagli sulla locazione del servizio
– Variano a secondo del protocollo di trasporto usato
– Ad es.: URL, indirizzo di e-mail, …
SD - Valeria Cardellini, A.A. 2009/10
32
Architettura di WSDL
• WSDL descrive un Web service, definendo i messaggi
che possono essere scambiati tra requestor e provider
• I messaggi sono descritti prima in modo astratto; in
seguito vengono aggiunte informazioni pratiche sui
protocolli di trasporto ed i formati dei messaggi
• Un messaggio consiste in una collezione di elementi
tipati
• Uno scambio di messaggi è definito una operation
• Una collezione di operation è definita una interface
• Ogni service è l’implementazione di una interface e
include tutti i dettagli concreti necessari per la
comunicazione
SD - Valeria Cardellini, A.A. 2009/10
33
Descrizione di un servizio
• Un documento WSDL (versione 2.0) è composto da 2
parti:
– Interfaccia astratta
– Endpoint concreto
• Interfaccia astratta (o definizione dell’interfaccia del
servizio)
– Descrive la struttura dell’interfaccia generale del servizio;
contiene tutte le operazioni supportate dal servizio, i parametri
delle operazioni ed i tipi di dato
– Generalizzabile, flessibile e facilmente estendibile
– Elementi WSDL: <types>, <interface>, <operation>,
<input>, <output>, <outfault>
• Endpoint concreto (o implementazione del servizio)
– Contiene i dettagli dell’interazione tra requestor e provider,
dipendenti anche dal protocollo di accesso al servizio
– Elementi WSDL: <binding>, <endpoint>, <service>
SD - Valeria Cardellini, A.A. 2009/10
34
WSDL: interfaccia astratta
• <types>
– Per definire i tipi di dato usati all’interno del documento
– Definito usando XML Schema come type system
• <interface>
– E’ sostanzialmente l’interfaccia del servizio stesso
– Di solito uno per documento WSDL
– Composto da un insieme di elementi <operation> e
<message>
• <operation>
– Specifica i nomi delle operazioni, i messaggi di input, output
o fault
– Vengono specificati i messaggi scambiati durante
l’operazione
• <input>, <output>, <outfault>
– Definizione astratta e tipata dei messaggi scambiati tra
requestor e provider, contenente i parametri di richiesta e di
risposta
– Il messaggio può essere di input, output o fault (<input>,
<output>, <outfault>)
SD - Valeria Cardellini, A.A. 2009/10
35
WSDL: endpoint concreto
• <binding>
– Fornisce i dettagli per lo scambio di informazioni tra
requestor e provider relativamente alle operazioni contenute
nella <interface>
– Specifica il protocollo di trasporto, lo stile di binding SOAP
(RPC-style o document-style), lo stile di enconding
• <service>
– Definisce l’implementazione concreta del servizio, fornendo
un nome che lo identifica univocamente ed un insieme di
endpoint
• <endpoint>
– Specifica l’indirizzo di rete del servizio (tipicamente l’URL)
SD - Valeria Cardellini, A.A. 2009/10
36
Esempio WSDL
• Esempio: Web service per la prenotazione presso
l’hotel GreatH
– Servizio che offre due operazioni, una delle quali è
CheckAvailability
– Messaggio di richiesta checkAvailability (data di
check-in, data di check-out, tipo di camera)
– Messaggio di risposta checkAvailabilityResponse
oppure messaggio di fault invalidDataFault
• Tratto da http://www.w3.org/TR/soap12-part0/
SD - Valeria Cardellini, A.A. 2009/10
37
Esempio WSDL: interfaccia astratta
l
SD - Valeria Cardellini, A.A. 2009/10
38
Esempio WSDL: interfaccia astratta (2)
Svc”
”/>
/>
SD - Valeria Cardellini, A.A. 2009/10
39
Esempio WSDL: interfaccia astratta (3)
SD - Valeria Cardellini, A.A. 2009/10
40
Esempio WSDL: endpoint concreto
HTTP”>
/>
n”>
SD - Valeria Cardellini, A.A. 2009/10
41
Universal Description Discovery Integration
• Universal Description, Discovery, Integration
(UDDI) è un servizio di directory basato su XML che
permette ai service provider di rendere pubblica la
presenza dei Web service offerti ed ai service
requestor di localizzare i Web service
– Senza UDDI, due applicazioni possono comunicare solo se
già si conoscono, conoscono i servizi offerti e la loro
localizzazione
• UDDI è un servizio globale condiviso tra server
differenti sparsi in tutto il mondo, anche se non
organizzati secondo una struttura gerarchica
– I diversi server possono condividere i dati mediante un
protocollo di replicazione
• UDDI si basa su SOAP per la trasmissione dei
messaggi
SD - Valeria Cardellini, A.A. 2009/10
42
Interazione con UDDI
• UDDI definisce API standard per la pubblicazione o
la scoperta delle informazioni nei service directory
• Due azioni principali
requestor
– Registrazione da parte del provider
– Scoperta da parte del requestor
find
UDDI
publish
provider
• La sicurezza di UDDI è un aspetto importante
– Problema: un concorrente potrebbe cancellare il servizio
pubblicato da un altro provider
– Soluzione: autenticazione dei provider
– Ogni server mantiene traccia dei provider e di cosa hanno
pubblicato
– Solo chi ha pubblicato un servizio è autorizzato a modificarlo
o cancellarlo
SD - Valeria Cardellini, A.A. 2009/10
43
Composizione di servizi
• Composizione: implementare un servizio Web la cui
logica richiede l’invocazione di operazioni offerte da
altri servizi Web
– Si ottiene un nuovo servizio a valore aggiunto componendo le
funzionalità di servizi già esistenti
• Col crescere del numero dei servizi, nasce la
necessità di avere tecnologie per la composizione dei
servizi che ricordano quelle dei sistemi di workflow
– L’obiettivo è combinare più servizi al fine di realizzare attività
complesse che coinvolgono diversi partner aziendali
• Necessità di infrastrutture apposite per supportare gli
sviluppatori (Web Service Composition Middleware)
• Due approcci per la composizione dei servizi:
coreografia e orchestrazione
SD - Valeria Cardellini, A.A. 2009/10
44
Orchestrazione
• Coordinatore centralizzato (broker) che controlla i Web
service coinvolti e coordina l’esecuzione delle differenti
operazioni
• I singoli servizi non sanno di prendere parte ad un
business process a livello di astrazione più elevato
• Solo il coordinatore conosce gli obiettivi della
composizione e gestisce l’ordine e la logica delle
invocazioni dei servizi, nonché il relativo passaggio dei
dati
• Linguaggio BPEL (Business Process Execution
Language) come linguaggio standard de facto
Web service 1
1: Receive
Orchestrazione
(coordinatore)
5: Reply
Web service 3
SD - Valeria Cardellini, A.A. 2009/10
2: Invoke
3: Invoke
Web service 2
.
.
4…n: Invoke.
Web service n
45
Coreografia
• Collaborazione tra entità di pari livello
• Ogni servizio coinvolto nella composizione sa quando
eseguire le operazioni e con quali servizi interagire
• Tutti i partecipanti alla coreografia sono consapevoli
della logica del business process, delle operazioni da
eseguire e dei messaggi da scambiare
5: Invoke
Web service 1
1: Invoke
Web service 2
Web service 4
3: Reply
4: Invoke
2: Invoke
Web service 3
SD - Valeria Cardellini, A.A. 2009/10
46
Nella prossima lezione
• Esercitazione tenuta da Stefano Iannucci su:
– Creazione e gestione di Web service
– Orchestrazione di Web service con BPEL
• Portare, se possibile, portatile con già installati:
– IDE NetBeans 6.7.1
– Application server GlassFish 2.1.1
– OpenESB
• Disponibili in un unico pacchetto su:
https://open-esb.dev.java.net/Downloads.html
– Selezionare Full Install
SD - Valeria Cardellini, A.A. 2009/10
47