Lezione 8: Introduzione ai Web Service
13 likes5,414 views
Il documento presenta un'introduzione ai web service, evidenziando i limiti dei middleware tradizionali nella comunicazione tra applicazioni di diverse organizzazioni e la transizione dalle web application ai web service. Descrive vari protocolli e architetture come SOAP, WSDL e REST, illustrando come questi standard consentano l'interoperabilità e la modularità in contesti aziendali. Infine, discute i principi della service oriented architecture (SOA) e i suoi vantaggi e svantaggi nella progettazione software.
Lezione 8: Introduzione ai Web Service
- 1. Lezione 8: Introduzione ai Web Service Corso di Programmazione in Rete Laurea Magistrale in Ing. Informatica Università degli Studi di Salerno 1
- 2. Outline ✦ Limiti dei middleware tradizionali ✦ Dalle web application ai web service ✦ Protocolli e standard ✦ Service Oriented Architecture 2
- 3. 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
- 4. 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
- 5. 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
- 6. 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
- 7. 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
- 8. 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
- 9. 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
- 10. 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
- 11. 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
- 12. 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
- 13. 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
- 14. 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
- 15. Protocolli e standard ✦ I protocolli per i web service usano tre architetture diverse: • RPC oriented • Message oriented • REpresentational State Transfer (REST) 15
- 16. 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
- 17. 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
- 18. 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
- 19. 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
- 20. 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
- 21. 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
- 22. 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
- 23. 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
- 24. 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
- 25. 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
- 26. 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
- 27. 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
- 28. 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
- 29. 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
- 30. 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
- 31. 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
- 32. 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
- 33. 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
- 34. 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
- 35. 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
- 36. 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
- 37. 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
- 38. 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
- 39. 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
- 40. 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
- 41. 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