Successo del Web Interazione fra applicazioni Limiti del web

Successo del Web
•
WEB SERVICES
•
•
•
Negli anni passati il Web ha avuto un enorme
successo principalmente per due motivi:
– Semplicità:
– Ubiquità
Per un fornitore di servizi è semplice raggiungere un
numero molto elevato di utenti.
Per un utente è semplice accedere ad un servizio
ovunque esso si trovi
Si tratta però di un sistema fortemente orientato
all’interazione tra utenti e sistemi
Interazione fra applicazioni
Limiti del web
• L’evoluzione dell’utilizzo di Internet e del Web ha fatto
emergere l’esigenza di interazioni fra applicazioni in
diversi contesti:
– Un programma di gestione aziendale deve poter
integrare le informazioni locali con quelle messe a
disposizione su Internet dai fornitori, dalle banche o
dall’amministrazione pubblica
– Un’applicazione per agenti mobiliari deve poter
attingere in tempo reale a informazioni provenienti dai
mercati finanziari di tutto il mondo e organizzarle in un
quadro coerente
– Il sistema di gestione di una biblioteca ha la necessità
di cercare un libro sia nel catalogo locale che in
quello di un sistema bibliotecario più vasto (Comune,
Provincia, Università…)
• Purtroppo il modello del web non è adatto all’interazione
fra applicazioni
• Si basa su modello molto semplice:
– L’utente, usando un browser, trasmette un URL,
digitandolo direttamente oppure cliccando su un link
– Il web server restituisce una pagina HTML che viene
resa graficamente dal browser
• In un colloquio fra applicazioni questo schema presenta
due elementi critici:
– Gli URL sono uno strumento troppo rudimentale per
esprimere richieste complesse e articolate
– L’HTML è in qualche modo un ibrido tra un linguaggio
per descrivere il contenuto informativo e un
linguaggio per descrivere la presentazione. Non c’è
una separazione netta fra forma e contenuto.
1
XML e SOAP
Un nuovo modello
• Queste considerazioni hanno portato alla definizione di
un nuovo modello in grado di superare queste
limitazioni: i web services.
• Si è scelto un approccio di tipo evolutivo:
– Continuare ad utilizzare HTTP come protocollo di
trasporto delle informazioni, in modo da riutilizzare
l’infrastruttura già esistente e conservare la
semplicità del modello di interazione
– Trovare uno strumento più adeguato per descrivere
gli elementi del colloquio: la richiesta e la risposta.
• Per quanto riguarda questo secondo aspetto la scelta è
caduta su XML
7
• XML è conosciuto soprattutto come linguaggio per la
descrizione di documenti
• In realtà è adatto a descrivere qualunque contenuto
informativo, anche molto complesso e articolato
• Può quindi essere utilizzato per esprimere sia le richieste
che le risposte, in un modello di interazione come quello
che abbiamo appena delineato
• E’ stato definito un protocollo chiamato SOAP - basato
su HTTP e XML - che definisce un modo semplice ed
efficace per creare interazioni fra applicazioni e sistemi
attraverso Internet
• SOAP è un protocollo di invocazione remota: permette di
richiedere ad un’applicazione remota di svolgere una
determinata azione e di restituire dei risultati
Introduzione
Cos’è un web service?
“Un WS è un’applicazione software identificata da un URI,
le cui interfacce pubbliche e relativi binding sono definiti e
descritti in XML. La sua definizione può essere trovata da
altre applicazioni software.
Questi ultimi possono poi interagire con il WS seguendo le
direttive presenti nella definizione del servizio, usando
messaggi XML trasportati da protocolli internet.”
(“Web Services Architecture”
http://www.w3c.org/TR/2002/WD-ws-arch-20021114)
• Interazione tra applicazioni web
• Modello di interazione tra applicazioni basato su
standard esistenti o emergenti:
- HTTP (Hypertext Transfer Protocol)
- XML (Extensible Markup Language)
- SOAP (Single Object Access Protocol)
- WSDL (Web Services Description Language)
- UDDI (Universal Description Discovery and Integration)
2
Definizione di web services
• Un web service è un’interfaccia che descrive un insieme
di operazioni accessibili sulla rete tramite messaggi
standardizzati XML.
• Un Web service è descritto usando una notazione XML
formale standard (service description).
L’interfaccia nasconde i dettagli di implementazione del
servizio (hardware, software, linguaggio di
programmazione).
Un web service corrisponde ad una specifica azione o ad
un insieme di azioni.
Può essere usato da solo o con altri web services per
realizzare una transazione complessa.
• La service description contiene tutte le informazioni
necessarie per l’interazione con il servizio: il formato dei
messaggi (relativi alle operazioni), il protocollo di
trasporto e la localizzazione del servizio.
The Web Services Model Service
Producer
WSDL,UDDI
Service
Registry
Service
Description
Service
nd
Bi
Pu
bl
ish
Service
Description
Find
WSDL,UDDI
Service
Consumer
Ruoli in una architettura web services
Service producer.
E’ il proprieterio del servizio. Da un punto di vista
architetturale, rappresenta il nodo che contiene il servizio.
Service consumer
E’ l’applicazione che sta cercando, chiamando o iniziando
un’interazione con un servizio. Un service consumer può
essere un browser o un’applicazione (es., un altro web
service)
Service register
Registro che contiene le descrizioni di servizi pubblicate su
richiesta dei service producer e ricercate dai service
consumer.
3
Web Services – Come funziona?
Operazioni in una architettura web services
•Publish
Per essere accessibile una descrizione di un servizio deve
essere pubblicata in modo che il service consumer la possa
ritrovare.
•Find
L’operazione di find può avvenire in due fasi distinte per il
consumer: a tempo di progetto del programma per ricercare
la descrizione dell’interfaccia, a run time per effettuare il
binding del servizio richiesto.
•Bind
L’interazione con un servizio ha luogo usando le informazioni
di binding nella descrizione del servizio per localizzare e
chiamare il servizio
• Il service consumer si collega ad un registro UDDI (internet o
intranet)
• Ricerca (per categorie, per fornitore, ecc…) il servizio che gli
interessa (esempio: web services che fornisca le quotazioni di
mercato)
• Trova la descrizione del servizio (funzionalità, dove collegarsi,
come invocarlo)
• Si collega al server del fornitore del servizio ed usufruisce del
servizio
• il service consumer è un’applicazione software
I web services sono applicazioni web che
forniscono servizi ad altre applicazioni web
SOAP: un esempio
Web Services – Tecnologie
• SOAP – Simple Object Access Protocol – Protocollo per lo
scambio di informazioni in un architettura distribuita e
decentralizzata . E’ un protocollo di invocazione remota:
permette di richiedere ad un’applicazione remota di svolgere
una determinata azione e di restituire dei risultati. Basato su
XML
• WSDL – Web Services Definition Language – Standard utilizzato
per la descrizione di un web service; fornisce cosa un servizio
può fare (richieste, risposte e parametri) dove risiede e come
chiamarlo.Basato su XML
• UDDI – Universal Description, Discovery and Integration –
Standard utilizzato per la pubblicazione di servizi in rete
•
•
•
Vediamo un semplice esempio: un’applicazione finanziaria (client)
che colloquia con un servizio che fornisce in tempo reale le
quotazioni di borsa.
L’elemento più semplice di questa interazione è la richiesta
dell’ultima quotazione di una determinata azione.
Vediamo lo schema del colloquio:
– L’applicazione client costruisce una richiesta in XML usando la
sintassi definita da SOAP
– L’applicazione client trasmette la richiesta ad un server Web
usando HTTP
– Il server riceve ed interpreta la richiesta trasformandola in un
comando che viene passato ad un’applicazione residente sul
server
– L’applicazione sul server riceve il comando e ricava dal proprio
database l’informazione richiesta
– L’applicazione sul server crea una risposta, sempre in formato
XML con sintassi SOAP e la restituisce al server web
– Il server web la restituisce all’applicazione client sotto forma di
risposta HTTP.
4
SOA
RUOLI dei partecipanti
(Service Oriented Architecture)
Provider
• SOA è uno strumento per ottenere un “composite
computing model” utilizzando “web services technology
stack”, ossia SOAP, WSDL, UDDI.
• Un web service è costituito da due parti:
servizio: rappresenta l’implementazione di un web
service, di dimensioni e complessità qualsiasi,
ospitato da un nodo ed utilizzabile da applicazioni
che operano su altri nodi.
descrizione del servizio: rappresenta l’interfaccia
del servizio descritta in XML. La descrizione
comprende i tipi di dati utilizzati, le operazioni, la
modalità di binding , l’indirizzo di rete (URL) del
nodo.
Registro
Proprietario del servizio. Il servizio ha:
- una descrizione XML
- una implementazione concreta che incapsula il
suo comportamento.
Si accede al servizio tramite SOAP e HTTP (o SMTP).
Il servizio può implementare un protocollo di
richiesta/risposta (RPC), oppure ricevere messaggi e fornire
risposte in modo asincrono
Richiedente
•Contiene:
- nome, descrizione e localizzazione del servizio
- informazioni necessarie per fare uso del servizio
•Può essere una persona che usa un browser
•Un’applicazione (es. un altro web service)
•Si può accedere a queste informazioni in fase di sviluppo
di una applicazione oppure run time.
•La struttura del Registro consente di ricercare prima se
esiste un certo tipo di servizio; in caso affermativo di
trovare la sua interfaccia.
5
Web Services – SOAP
Interazioni dei partecipanti
Pubblicazione.
È quasi sempre di tipo dinamico utilizzando il protocollo
UDDI (Universal Description, Discovery and Integration).
Il richiedente fa una richiesta (SOAP request), il server ascolta su
una porta, accetta la richiesta, esegue il servizio (service) ed invia
il risultato al richiedente (SOAP response)
Prospettiva futura:applicazioni ricercano dinamicamente i
servizi di cui hanno bisogno da compagnie non conosciute
senza la necessità dell’intervento umano.
Tecnologie utilizzate: SOAP, WSDL, UDDI : tutte basate
su XML.
SOAP request
Service
Client
Server
SOAP response
Web Services – Esempio di richiesta SOAP
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Web Services – Esempio di risposta SOAP
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
6
WSDL
• Per poter utilizzare un servizio è necessario conoscerne
le caratteristiche
• Il protocollo WDSL (Web Services Definition Language),
basato sempre su XML, svolge proprio questa funzione
• WDSL dice:
– Cosa un servizio può fare (richieste, risposte e
parametri)
– Dove risiede
– Come invocarlo
• Vediamo il documento WSDL che descrive il servizio a
cui abbiamo acceduto nell’esempio di poco fa
WSDL: messaggi e operazioni
•
WSDL: descrizione dei tipi
•
La prima parte di uno schema WSDL descrive i tipi.
<types>
<schema>
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
•
Il binding è il collegamento tra un tipo di operazione (type), un nome
di operazione (name) e l’azione da eseguire (soapAction):
WDSL: binding e servizio
<binding name="StockQuoteSoapBinding“
type="tns:StockQuotePortType">
<soap:binding>
<operation name="GetLastTradePrice“>
<soap:operation soapAction=“…"/>
<input>…</input>
<output>…</output>
</operation>
</binding>
Troviamo quindi la descrizione dei messaggi:
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
•
E la descrizione delle operazioni: ogni operazione è costituita da un
messaggio di richiesta e uno di risposta:
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
•
L’ultima parte del documento descrive il servizio e l’indirizzo web da
utilizzare per accedervi:
<service name="StockQuoteService">
<port name="StockQuotePort“
binding="tns:StockQuoteBinding">
<soap:address
location="http://www.stockquote.com"/>
</port>
</service>
7
UDDI
•
•
•
•
•
In un mondo popolato da servizi Web nasce la necessità di rintracciarli
A questo scopo è stato sviluppato uno standard, denominato UDDI
(Universal Description, Discovery e Integration System)
UDDI rappresenta in qualche modo l’equivalente di un “elenco telefonico”
online, che permette di rintracciare i web services
Infatti UDDI offre 3 servizi i cui nomi si ispirano al mondo della telefonia:
– White pages: permette di trovare un servizio per nome
– Yellow pages: permette di trovare un servizio per categoria
– Green Pages: fornisce informazioni tecniche sui servizi offerti da una
determinata azienda
Un fornitore di servizi UDDI (IBM, Microsoft, SAP ecc.) gestisce un registro
elettronico denominato UBR (UDDI Business Registry) che è accessibile sia
per pubblicare che per rintracciare i web services
Web Services: riepilogo
• Che cosa sono quindi in sintesi i web services:
Sono applicazioni autonome, modulari, autodescrittive,
che possono essere pubblicate, rintracciate e invocate
attraverso il web.
• Permettono di realizzare interazioni fra sistemi attraverso
Internet e consentono di integrare funzioni applicative
distribuite.
• Un web service è costituito da 3 elementi:
– Un meccanismo per la pubblicazione e la
rintracciabilità: UDDI
– Un meccanismo di descrizione: WSDL
– Un meccanismo di invocazione: SOAP
Web services e oggetti distribuiti
•
•
•
•
•
I web services possono essere considerati come una nuova forma di
RMI dove:
– SOAP ha il ruolo di protocollo di trasporto applicativo (come
IIOP)
– WSDL ha il ruolo di IDL
Esistono strumenti (vedi Axis per Java), in grado di creare lo
scheletro dei client e dei server sulla base di WSDL
Il vantaggio fondamentale rispetto a CORBA/IIOP è la possibilità di
passare attraverso i firewall
I web services estendono a internet il mondo degli oggetti distribuiti,
nati in ambito di rete locale
Sono più flessibili e realizzano un accoppiamento molto più blando
fra client e server
8