I SERVIZI WEB

I servizi web

La nascita dei servizi web

La nascita dell’informatica, la scienza dei calcolatori, ha causato una rivoluzione tecnologica di importanza epocale nella storia dell’umanità. A partire dalla metà del secolo scorso, quando furono costruiti i primi calcolatori elettronici, l’informatica ha infatti vissuto un rapidissimo e costante sviluppo che ha portato a una presenza pervasiva di applicazioni in tutti i settori delle società. L’impressionante espansione delle reti di calcolatori, e in particolare di Internet, ha permesso una diffusione capillare dell’uso di applicazioni di rete, come la posta elettronica o la navigazione del web, fra centinaia di milioni di utenti nel nostro pianeta. All’inizio di questo nuovo secolo, siamo ormai abituati alla presenza costante delle applicazioni informatiche in tutti i momenti della giornata, dal lavoro all’informazione e all’intrattenimento. Nuove applicazioni, considerate soltanto futuribili nel secolo scorso, sono ormai realtà, come la televisione digitale on demand, la telefonia VoIP (Voice over Internet Protocol), la domotica o la telemedicina.

Per cercare di capire meglio gli aspetti fondamentali degli sviluppi (passati, presenti e futuri) dell’informatica, è utile ricordare la distinzione tra i concetti di hardware e di software. Storicamente, il termine hardware veniva utilizzato per indicare le parti metalliche di artefatti realizzati in legno. Nell’accezione moderna, il termine viene adoperato per indicare in generale articoli di ferramenta (negli Stati Uniti i negozi di ferramenta vengono infatti denominati proprio hardware stores). In ambito informatico, il termine viene usato per riferirsi a tutti i componenti fisici – ovvero tangibili – di un calcolatore (circuiti, tastiere, monitor, cavi e così via), in contrapposizione con i componenti intangibili (programmi, applicazioni, sistemi operativi) che costituiscono il software presente all’interno di un calcolatore.

Lo sviluppo impetuoso delle applicazioni informatiche è stato determinato dalle importantissime evoluzioni avvenute in entrambi i settori, hardware e software, dell’informatica. L’integrazione su vasta scala dei circuiti elettronici (VLSI, Very Large Scale Integration) ha portato alla realizzazione di chip di dimensioni estremamente ridotte, contenenti milioni di transistor, e di calcolatori palmari (della dimensio­ne del palmo di una mano) più potenti dei primi calcolatori elettronici (che occupavano interi edifici). Gli enormi passi in avanti nel settore telematico hanno inoltre permesso la realizzazione e la diffusione di reti fisiche ad altissima velocità, la cui integrazione permette la trasmissione quasi istantanea di grandi quantità di informazioni da un lato all’altro del pianeta. Gli impressionanti sviluppi dell’hardware non avrebbero tuttavia permesso la realizzazione delle odierne applicazioni informatiche se non fossero stati accompagnati da sviluppi altrettanto importanti nel settore del software. La costante evoluzione dei linguaggi di programmazione e delle metodologie di produzione del software ha infatti reso possibile lo sviluppo di applicazioni informatiche affidabili, efficienti e facilmente utilizzabili anche da utenti non esperti.

Uno degli aspetti cruciali, alla radice del successo della produzione sia dell’hardware sia del software, è l’idea di realizzare componenti sofisticati combinando in maniera opportuna parti più semplici già esistenti. Come accennato, l’integrazione su vasta scala di componenti elettronici standardizzati ha rappresentato il leitmotiv dell’inarrestabile evoluzione dell’hardware nell’informatica. In maniera analoga, l’evoluzione dei linguaggi di programmazione ha cercato di rendere sempre più facile lo sviluppo di applicazioni complesse mediante la combinazione opportuna di software più semplici già esistenti.

Un intero settore dell’informatica, la cosiddetta ingegneria del software, si è dedicato negli ultimi decenni alla definizione di metodologie e di tecniche che permettessero uno sviluppo disciplinato delle applicazioni, basato sull’integrazione di componenti software. L’idea è, in sostanza, quella di progettare ogni applicazione decomponendone logica e funzionalità in parti più piccole, ciascuna delle quali offerta da un software già esistente, e specificando quindi, in modo opportuno, soltanto l’interazione necessaria tra tutti i componenti. Un tale sviluppo modulare del software ha introdotto enormi vantaggi nella produzione, permettendo la riusabilità di componenti già sviluppati (e sperimentati) e, di conseguenza, riducendo in maniera drastica tempi e costi della produzione di nuove applicazioni, così come della loro successiva manutenzione.

La pratica ormai consolidata di sviluppare applicazioni informatiche combinando in maniera opportuna componenti software esistenti è destinata a potenziarsi ulteriormente, e con molteplici risvolti cui accenneremo in seguito, grazie alla recente nascita dei cosiddetti servizi web. In prima approssimazione, un servizio web è un componente software individuabile e utilizzabile sulla rete – mediante standard di pubblico dominio – da altri componenti software. Già da questa prima definizione informale, è facile intuire il profondo impatto che la diffusione dei servizi web, iniziata agli albori di questo nuovo secolo, è destinata ad avere sui futuri sviluppi delle applicazioni informatiche. La possibilità che vengano costruite applicazioni, mediante l’integrazione di vari servizi presenti in luoghi diversi e offerti da diversi soggetti, apre nuovi orizzonti allo sviluppo del software e, al tempo stesso, introduce una serie di importanti sfide che spaziano dalla tecnologia a nuovi modelli economici di business.

Siti e servizi web

Come abbiamo già accennato, un servizio web può essere considerato approssimativamente come un componente software utilizzabile da altri componenti software attraverso la rete.

Vale la pena sottolineare subito una differenza im­portante fra siti web e servizi web. Un sito web è un insieme di documenti (detti anche pagine web) organizzati in una struttura a ipertesto e accessibili in rete con appositi programmi (browsers). Ogni sito web ha un indirizzo associato (URL, Uniform Resource Locator), che permette di accedere ai documenti in esso contenuti. Per esempio, inserendo in un browser l’indirizzo www.treccani.it, possiamo visualizzare i contenuti della pagina principale del sito web dell’Istituto della Enciclopedia Italiana. Un’importante differenza tra siti e servizi web è che, mentre i primi offrono informazioni (nella forma di testo, immagini o suoni) destinate agli utenti, i secondi offrono, invece, operazioni ad altri componenti software.

Utilizziamo un semplice esempio per illustrare la differenza tra i due concetti. Consideriamo il sito web di un albergo che permette ai clienti di verificare la disponibilità di camere per certe date e di effettuare la prenotazione per il periodo desiderato. L’utente potrà quindi utilizzare il proprio browser per effettuare le varie operazioni, inserendo i dati necessari (giorno di arrivo e di partenza, numero di camere ed, eventualmente, informazioni personali come nominativo, numero di carta di credito e così via). Per es., il sito web presenterà inizialmente una finestra del tipo di quella riportata nella figura 1A. Le stesse operazioni possono essere offerte anche da un servizio web, presentate però in un formato machine-understandable, ossia comprensibile da altri calcolatori, con una sintassi come quella riportata nella figura 1B.

Pur nella sua estrema semplicità, l’esempio ci permette di apprezzare già la netta differenza tra il modo con cui un utente interagisce con un sito web e il linguaggio utilizzato da un software per interagire con un servizio web. Nella figura 1B possiamo infatti notare come vengano specificati molti dettagli sintattici dell’operazione: il nome (VerificaDisponibilita), i tre parametri che l’operazione deve ricevere in ingresso (DataDiArrivo, DataDiPartenza e NumeroDiCamere), così come anche il parametro che l’operazione restituirà (Risultato) al termine della sua esecuzione.

Inoltre, non è diverso soltanto il modo in cui siti web e servizi web presentano le operazioni eseguibili dagli utilizzatori, ma è differente anche il modo in cui questi ultimi possono richiedere l’esecuzione di tali operazioni. Gli utenti dei siti web usano infatti tipicamente un programma browser che permette loro, mediante un’interfaccia grafica utilizzando mouse e tastiera, di inserire dati e selezionare l’operazione da eseguire. I clienti dei servizi web non utilizzano, invece, alcuna interfaccia grafica, e la comunicazione avviene mediante messaggi con cui gli utenti chiedono specificamente l’esecuzione di operazioni e ricevono quindi il risultato di tale esecuzione.

Come approfondiremo meglio in seguito, la facilità con cui i servizi web possono essere utilizzati da altri componenti software ha aperto nuovi orizzonti per lo sviluppo di applicazioni informatiche, semplificandone enormemente la realizzazione mediante l’integrazione di servizi diversi, disponibili in parti diverse del pianeta, sviluppati e offerti da soggetti differenti.

Uno degli esempi più semplici adoperati per illustrare i vantaggi dell’utilizzo e dell’integrazione dei servizi web è la realizzazione di un’applicazione che permetta a un utente di organizzare le sue vacanze. Da qualche anno, è possibile servirsi del web per programmare autonomamente le vacanze acquistando, per es., i biglietti sul sito di una compagnia aerea e prenotando il soggiorno sul sito di un albergo, dopo aver esaminato differenti offerte di voli e di soggiorni descritte in altri siti. La disponibilità di servizi web che permettono ad altri componenti software di acquistare voli e prenotare soggiorni ha consentito la realizzazione di servizi innovativi, ottenuti integrando quelli di base.

Per es., è facile a questo punto immaginare come possa essere creato un software che riesca a prenotare il soggiorno più economico disponibile in certe date. Intuitivamente, tale software potrà richiedere disponibilità e prezzi a un insieme di servizi web di alberghi diversi, per poi confrontare i risultati ricevuti e selezionare l’offerta migliore. In maniera analoga, è ovviamente possibile ottenere un software che prenoti la combinazione di voli più economica per una certa destinazione nel periodo desiderato.

È evidente quindi come la facilità con cui possono essere utilizzati servizi web diversi permette la realizzazione di applicazioni che compongono tali servizi, offrendo un valore aggiunto rispetto a essi. Continuando il nostro esempio, possiamo quindi facilmente ottenere un’applicazione in grado di prenotare il soggiorno e i voli più economici in certe date e magari anche, per es., un autonoleggio o spettacoli teatrali offerti da altri servizi web.

Naturalmente, l’applicazione realizzata potrà essere a sua volta presentata come servizio web (per permetterne l’utilizzo da parte di altre applicazioni) e anche su un sito web (per consentirne l’utilizzo da parte degli utenti).

Standard utilizzati

Fino a questo punto, la nostra introduzione ai servizi web è stata orientata a tentare di chiarire la principale differenza tra siti web e servizi web, e a cercare di evidenziare le potenzialità offerte da questi ultimi, in termini di nuove applicazioni informatiche che possono essere realizzate. Cerchiamo adesso di capire un po’ più da vicino quali sono le problematiche presenti nella creazione dei servizi web, accennando per ciascuna di esse alle soluzioni attualmente impiegate.

Una delle proprietà più importanti dei servizi web è quella di permettere l’interoperabilità con applicazioni software già esistenti. In altri termini, oltre a sviluppare nuovi servizi, è possibile rendere disponibili, come servizi web, applicazioni software già esistenti. Per es., nello scenario applicativo discusso nel paragrafo precedente, i sistemi di prenotazione di voli offerti dalle diverse compagnie aeree sono stati realizzati in generale prima dell’avvento dei servizi web. Una delle ragioni della crescente diffusione dei servizi web è proprio la possibilità offerta ai fornitori di servizi di rendere disponibili in rete le loro applicazioni senza doverle modificare, ma presentandole semplicemente come servizi web.

Questa possibilità è, chiaramente, una delle ragioni principali della diffusione dei servizi, in quanto estremamente vantaggiosa dal punto di vista dei costi di realizzazione e di manutenzione del software. Per offrire tale possibilità, la tecnologia dei servizi web, ovviamente, deve permettere di superare le differenze esistenti tra sistemi sviluppati in Paesi diversi, in momenti diversi, con linguaggi di programmazione diversi. La soluzione seguita dai servizi web per superare l’eterogeneità delle applicazioni esistenti, permettendo la loro interoperabilità, è quella di adottare standard di pubblico dominio per la comunicazione.

Il primo di questi standard è il protocollo SOAP (Simple Object Access Protocol), che definisce il formato dei messaggi che i servizi web sono in grado di ricevere e inviare. Senza addentrarci nei dettagli della descrizione di tale protocollo, ci limitiamo a osservare che ogni messaggio SOAP (detto anche envelope, ossia «busta») è strutturato in due parti: un’intestazione opzionale (header) e il corpo (body) vero e proprio del messaggio. Per es., la figura 2 illustra il contenuto di un messaggio SOAP, destinato a un servizio di prenotazione alberghiera, che offre un’operazione del tipo di quella schematizzata nella figura 1B.

Se proviamo a leggere tale messaggio, incontriamo una certa difficoltà nel decifrare le informazioni rilevanti in esso contenute. Il motivo di ciò è che i messaggi SOAP sono, a loro volta, codificati adoperando il linguaggio XML (eXtensible Markup Language) utilizzato per annotare un qualunque file di testo identificando mediante etichette (tags) i dati in esso contenuti. Per es., le etichette e delimitano l’inizio e la fine dell’intero messaggio (busta), così come le etichette e delimitano il corpo vero e proprio del messaggio. In modo analogo, le altre etichette impiegate permettono di identificare le altre parti contenute nel corpo del messaggio (nell’esempio, nome dell’operazione richiesta, data di arrivo e di partenza e numero di camere).

Il linguaggio XML è utilizzato dai calcolatori per annotare file di testo, e non sorprende quindi che un essere umano incontri una certa difficoltà nel leggere un file XML. Il vantaggio principale offerto da XML è la portabilità, ossia una rappresentazione di dati indipendente dalle caratteristiche (hardware e software) dei calcolatori utilizzati. In altri termini, due calcolatori con caratteristiche del tutto diverse, che, per es., utilizzano sistemi operativi diversi e programmi differenti per generare file, possono scambiarsi file di testo XML senza incontrare alcuna difficoltà nell’individuare e interpretare i dati ricevuti. Proprio grazie alla sua portabilità, XML è lo standard adottato per codificare la sintassi di tutti gli standard che vengono adoperati dai servizi web.

Riconsideriamo, adesso, il messaggio SOAP riportato nella figura 2. Possiamo notare che il corpo di tale messaggio, al netto delle annotazioni XML in esso presenti, menziona l’operazione VerificaDisponibilita e contiene un valore per ciascuno dei parametri di tale operazione, DataDiArrivo, DataDiPartenza e NumeroDiCamere. Sapendo che il messaggio è destinato a un servizio di prenotazione alberghiera che offre un’operazione del tipo di quella schematizzata nella figura 1B, siamo quindi in grado di interpretare il messaggio come una richiesta tesa a verificare la disponibilità di una camera per le notti del 22 e 23 maggio 2009.

È importante ricordare che il destinatario di un messaggio SOAP, come quello riportato nella figura 2, è un servizio web. Sappiamo che i calcolatori sono efficientissimi esecutori di istruzioni (in grado di eseguirne addirittura milioni al secondo), ma non brillano, nel fare ciò, in flessibilità. Infatti, se un’istruzione non è definita in modo assolutamente corretto dal punto di vista sintattico, il calcolatore non è spesso in grado di interpretarla, e quindi di eseguirla, correttamente. Se, per es., il servizio web precedentemente menzionato ricevesse un messaggio contenente una richiesta di eseguire l’operazione Disponibilita oppure VerificaDisp, anziché VerificaDisponibilita, risponderebbe che non è in grado di eseguire tale operazione.

È chiaro quindi che, affinché un servizio web possa essere utilizzato da altri calcolatori, questi dovranno poter conoscere tutti i dettagli sintattici necessari (nomi delle operazioni, nomi dei parametri di ogni operazione e così via) prima di poterlo invocare inviando opportuni messaggi. Dato che, come più volte sottolineato, servizi web diversi vengono realizzati da persone diverse, in Paesi diversi e in momenti diversi, è quindi assolutamente necessario utilizzare un linguaggio comune, e comprensibile dai calcolatori, con cui poter descrivere le funzionalità di un servizio.

Per la descrizione delle funzionalità dei servizi web viene utilizzato il linguaggio standard, di pubblico dominio, WSDL (Web Service Description Language). Senza addentrarci nei dettagli della sintassi di tale linguaggio (definita anch’essa utilizzando XML), possiamo affermare che WSDL permette di spiegare sia in maniera astratta cosa fa un servizio sia in maniera più concreta come e dove lo fa. In particolare, un’interfaccia WSDL definisce esattamente i tipi di messaggi che il servizio è in grado di ricevere (ovvero le operazioni che è in grado di eseguire).

Riassumendo, ogni servizio web utilizza lo standard WSDL per descrivere le funzionalità che offre, e lo standard SOAP per ricevere e inviare messaggi. Un software che desideri inviare un messaggio SOAP a un servizio per richiedere l’esecuzione di una certa operazione, dovrà prima conoscere la descrizione WSDL di tale servizio. Considerando che i servizi sono sparsi sulla rete e che, in generale, chi desidera avvalersi di un servizio sa che tipo di servizio vuole utilizzare ma non sa dove trovarlo, com’è possibile localizzare un servizio web disponibile in rete?

Lo standard di pubblico dominio usato per descrivere le caratteristiche dei servizi web e per individuare tali servizi web è UDDI (Universal Description, Discovery and Integration). Tralasciando i particolari del protocollo, possiamo dire che UDDI utilizza diversi meccanismi per suddividere i servizi in elenchi organizzati sia in base ai fornitori sia in base al tipo di servizio, e permette l’accesso a descrizioni dettagliate dei servizi (comprese le interfacce WSDL dei servizi).

L’individuazione dei servizi web è quindi resa possibile dall’esistenza di calcolatori che svolgono il ruolo di veri e propri registri UDDI. Ognuno di questi registri interagisce sia con i fornitori di servizi (che lo contattano per pubblicare una descrizione di ciò che of­frono), sia con i clienti alla ricerca di un servizio (che lo contattano per cercarne uno con determinate caratteristiche), sia con altri registri UDDI (con i quali scambia informazioni di vario tipo, per es. per diffondere la pubblicazione di un nuovo servizio).

A questo punto, possiamo avere una visione d’insieme della tipica sequenza ‘pubblica-cerca-utilizza’ dei servizi web. Dapprima, un fornitore del servizio contatta un registro UDDI per pubblicare la descrizione di quello che intende offrire; successivamente, un cliente contatta il registro UDDI per cercare informazioni su un tipo di servizio che vorrebbe utilizzare; infine il cliente, una volta ottenute le informazioni necessarie per contattare il servizio, inizia a interagire direttamente con tale servizio.

Alcune limitazioni attuali

Vale la pena osservare che, sebbene la disponibilità di registri UDDI permetta l’individuazione di servizi mediante ricerche per parole chiave, è attualmente necessario un intervento umano per analizzare i risultati di tale ricerca.

La descrizione delle funzionalità di un servizio, riportata in un’interfaccia WSDL, è infatti meramente sintattica, e non consente di automatizzare il processo di comprensione di cosa effettivamente siano le operazioni offerte. Se, per es., consideriamo la descrizione dell’operazione VerificaDisponibilita illustrata nella figura 1B, possiamo renderci facilmente conto che per una reale comprensione di tale descrizione è implicitamente richiesto di conoscere la lingua italiana.

La funzione illustrata nella figura 1B è inoltre, a prima vista, molto simile a quella descritta dall’interfaccia WSDL riportata nella figura 3A. Notiamo infatti che il nome dell’operazione è apparentemente lo stesso (VerificaDisponibilita), anche se questa volta in inglese (CheckAvailability), così come il nome del primo parametro (DataDiArrivo e CheckInDate). Il secondo parametro (N_Rooms) indica il numero di stanze desiderate, e sembra corrispondere al terzo parametro della funzione descritta nella figura 1B (NumeroDiCamere). Infine il terzo parametro (N_Nights) indica il numero di notti desiderate, e sembra codificare sostanzialmente la stessa informazione espressa (anche se in modo diverso) dal secondo parametro della funzione della figura 1B (DataDiPartenza).

Sulla base delle precedenti considerazioni, po­tremmo quindi pensare di richiedere a entrambi i servizi, con messaggi leggermente diversi, l’esecuzione dell’operazione di verifica della disponibilità di camere in un certo periodo, per es., per le notti del 22 e 23 maggio 2009. Nel caso dell’operazione descritta nella figura 1B, abbiamo già visto che dovremmo inviare la richiesta con il messaggio SOAP schematizzato nella figura 2. Nel caso dell’operazione descritta nella figura 3A, potremmo invece inoltrare la richiesta con il messaggio SOAP schematizzato nella figura 3B.

Osserviamo però che, se da un lato i messaggi descritti nelle figure 2 e 3B saranno sicuramente interpretati come richieste valide dai servizi descritti rispettivamente nelle figure 1B e 3A, dall’altro, guardando soltanto la descrizione dell’operazione riportata nella figura 3A non abbiamo, in realtà, la garanzia assoluta che stiamo richiedendo l’esecuzione della stessa operazione. La descrizione dell’operazione della figura 3A menziona, infatti, la verifica di disponibilità di rooms e, per quanto ne sappiamo, potrebbe riferirsi alla disponibilità di rimesse per auto, di studi di registrazione o di sale per la meditazione da affittare per la notte, anziché alla disponibilità di camere d’albergo. La descrizione di cosa siano in pratica le operazioni offerte da un servizio dev’essere quindi ricercata nel resto della documentazione che descrive un servizio, scritta nel cosiddetto linguaggio naturale (tipicamente l’inglese), la cui analisi non può essere (almeno attualmente) completamente automatizzata, e richiede pertanto un intervento umano.

Per riuscire ad automatizzare la fase di ricerca di un servizio, è stato proposto di arricchire le descrizioni dei servizi web con informazioni di tipo semantico, ossia di significato, e non solo di tipo sintattico come finora avvenuto. Intuitivamente, l’idea è quella di descrivere operazioni e dati utilizzando concetti appartenenti a ontologie (intese come insiemi di relazioni tra concetti) ben definite. In questo modo, la ricerca di un servizio potrebbe essere completamente automatizzata, sfruttando le informazioni semantiche disponibili per restituire risultati accurati, senza la necessità di un intervento umano. Tuttavia, sebbene molte ricerche siano state orientate allo studio di questi servizi web semantici, la loro adozione nel mondo della produzione software non è ancora avvenuta. La futura disponibilità di strumenti che facilitino l’annotazione semantica dei servizi potrà certamente contribuire allo sviluppo di questo settore, anche se una vera diffusione di servizi web semantici potrà avvenire solo quando i vantaggi offerti da queste tecnologie diventeranno di chiaro interesse per il mercato.

Abbiamo fin qui discusso dell’attuale impossibilità di automatizzare completamente la ricerca di servizi web, dovuta alla natura meramente sintattica delle descrizioni machine-understandable WSDL dei servizi. Un’altra importante attuale limitazione dei servizi web è l’incapacità di garantire formalmente a priori che l’interazione con un servizio web funzionerà veramente, ossia che lo scambio di messaggi non rimarrà bloccato in qualche momento. La ragione di questa difficoltà è di nuovo la natura meramente sintattica delle attuali presentazioni machine-understandable dei servizi, le quali descrivono i messaggi che un servizio è in grado di ricevere ma non l’ordine con il quale il servizio si aspetta di riceverli. Per es., supponiamo che il servizio di prenotazione alberghiera che offre l’operazione VerificaDisponibilita, descritta nella figura 1B, intenda offrire tale operazione solo ai clienti a cui abbia precedentemente accordato l’accesso al servizio, per es., attraverso un’altra operazione Login con la quale è possibile inviare il numero di una tessera soci. In questo caso, il servizio potrebbe aspettarsi di ricevere, come primo messaggio, una richiesta di tipo Login e non essere quindi in grado di ricevere una richiesta di tipo VerificaDisponibilita, generando così una situazione di blocco nello scambio di messaggi con il cliente.

La mancanza di una rappresentazione machine-understandable dell’ordine (detto anche comportamento del servizio) con cui un servizio è in grado di ricevere i vari messaggi impedisce quindi di garantire a priori che l’interazione con quel servizio non porterà a una situazione di stallo. Sebbene questa considerazione possa sembrare per certi versi sconcertante, è giusto ricordare che essa si utilizza in generale con il complesso delle applicazioni informatiche, e non solo con i servizi web. Per es., anche per i tradizionali sistemi informatici basati sull’integrazione di componenti software non è possibile garantire a priori che le interazioni tra i componenti non causeranno una situazione di stallo nell’applicazione. La soluzione comunemente adottata è quella di sottoporre ogni applicazione a più fasi di collaudo (testing), riuscendo così a verificarne sperimentalmente il corretto funzionamento in un numero arbitrariamente alto di casi tipici d’uso.

Vale la pena, tuttavia, di osservare che i più recenti sviluppi nel settore dei servizi web, stimolati dall’impellente necessità di ingegnerizzare la realizzazione di composizioni e aggregazioni di servizi esistenti, hanno dato nuovo risalto alla definizione del comportamento interattivo dei servizi.

La composizione di servizi web

Come già sottolineato, la possibilità di comporre facilmente servizi esistenti, disponibili in parti diverse del pianeta, sviluppati e offerti da soggetti diversi, è sicuramente l’aspetto più innovativo e significativo introdotto dai servizi web.

Il linguaggio WSBPEL (Web Services Business Process Execution Language) si è affermato, negli ultimi anni, come lo standard per la definizione di composizioni (dette anche orchestrazioni) di servizi web. WSBPEL è stato progettato per permettere di definire processi aziendali (business processes) componendo servizi web. I processi aziendali giocano, infatti, un ruolo fondamentale sia nell’integrazione di servizi all’interno della stessa azienda (enterprise application integration) sia nell’interazione con servizi di partner esterni (business-to-business integration). Molto informalmente, un processo aziendale definisce un insieme di attività interrelate che contribuiscono al raggiungimento di un certo obiettivo.

Un processo WSBPEL permette di definire un processo aziendale mediante un workflow (flusso di lavoro) di attività, alcune delle quali possono essere svolte da altri servizi web. Anziché addentrarci nei dettagli di WSBPEL, vediamo uno degli esempi più comunemente adoperati per illustrare l’utilizzo di tale linguaggio.

Consideriamo la realizzazione di un semplice servizio di concessione di prestiti, a cui i clienti possano inviare le loro richieste indicando l’ammontare del prestito richiesto, oltre ovviamente ai loro dati personali. Il servizio deve decidere se accordare o meno il prestito in base all’ammontare richiesto e al fattore di rischio associato al cliente. In particolare, richieste inferiori a 10.000 euro di clienti ritenuti a basso rischio possono essere approvate automaticamente, mentre richieste di importi superiori, o di clienti ritenuti non a basso rischio, devono invece essere analizzate più approfonditamente. Per realizzare il servizio si utilizzano le funzionalità offerte da altri due servizi. Nel primo caso si utilizza un servizio di valutazione del rischio per ottenere velocemente una stima di quello associato al cliente; nel secondo caso si ricorre a un servizio completo di concessione di prestiti (che po­trebbe eventualmente richiedere l’intervento diretto di un esperto di prestiti) per determinare se concedere o meno il prestito. Il business process appena descritto può essere direttamente specificato in WSBPEL.

Pur senza conoscere i dettagli del linguaggio, possiamo vedere che il workflow specificato stabilisce che, come prima attività, il servizio dovrà ricevere (receive) una richiesta dal cliente. Quindi, nel caso in cui l’ammontare (amount) della richiesta ricevuta è inferiore a 10.000 euro, verrà invocato (invoke) un servizio loan assessor, in caso contrario verrà invocato un servizio loan approver. Nel primo caso, se la risposta ottenuta sarà che il cliente è a basso rischio (low risk), si accorderà il prestito, preparando (assign) e inviando (reply) la risposta al cliente; altrimenti si invocherà (invoke) il servizio loan approver e si inoltrerà (reply) direttamente al cliente il risultato ricevuto.

Osserviamo come, pur nella sua semplicità, il workflow dell’esempio evidenzi alcune caratteristiche importanti del linguaggio WSBPEL, quali la possibilità di specificare in modo molto semplice alternative diverse nei flussi e interazioni con altri servizi web. A questo proposito, vale la pena menzionare che WSBPEL consente di specificare interazioni con tipi di servizi, la­sciando che i fornitori dei servizi specificati possano essere scelti anche a tempo di esecuzione. Un processo WSBPEL viene, a sua volta, presentato all’esterno come un servizio web e fornito della sua interfaccia WSDL, in modo da poter essere utilizzato da altri servizi.

Uno dei vantaggi che ha determinato l’affermazione di WSBPEL come standard, è quello di offrire un modello di programmazione a due livelli, che permette una netta separazione di competenze e responsabilità. Da un lato, gli esperti di processi aziendali possono specificare il workflow desiderato ad alto livello (in termini di attività di base, interne o esterne, utilizzando una rappresentazione visivamente intuitiva), dall’altro lato, agli esperti informatici è lasciato il compito di implementare i dettagli necessari per permettere l’esecuzione del processo WSBPEL corrispondente. Questa separazione risulta di fondamentale importanza poiché consente agli esperti di processi aziendali di specificare il workflow desiderato senza dover possedere conoscenze informatiche approfondite e, nello stesso tempo, delega agli esperti informatici soltanto la realizzazione del workflow specificato e non la sua progettazione.

Conclusioni

La discussione generale di alcune delle più importanti tecnologie relative ai servizi web e del loro ruolo nello sviluppo di nuove applicazioni informatiche, ha evidenziato come la possibilità di costruire nuovi servizi, integrandoli con quelli già esistenti, ha aperto nuove importanti sfide non solo nel settore dello sviluppo del software ma anche in quello economico. La definizione di nuovi tipi di contratti di servizio, che riescano a regolare i vari aspetti dell’utilizzo dei servizi web (modalità, costi, garanzie, compensazioni ecc.), è forse solo il primo passo di un nuovo cammino verso quella che alcuni definiscono l’economia del futuro basata sui servizi.

Webgrafia

Per maggiori informazioni su protocolli, linguaggi e standard descritti nel saggio, si vedano i siti sotto elencati:

SOAP: http://www.w3.org/standards/techs/soap#w3c_all.

UDDI: http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm.

WSBPEL: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html.

WSDL: http://www.w3.org/standards/techs/wsdl#w3c_all.

XML: http://www.w3.org/standards/xml/.

Tutte le pagine web s’intendono visitate per l’ultima volta il 22 luglio 2010.