Il framework offerto dai Web Services

Attualmente uno dei problemi più sentiti per garantire l'interoperabilità in campo GIS è quello di individuare le informazioni geografiche disponibili: volendo usare un'analogia nel descrivere le attuali e consuete modalità di accesso alle informazioni geografiche, potremmo dire che siamo al livello in cui, parecchi anni fa, all'inizio dell'utilizzo di Internet, un utente per raggiungere e leggere un documento su un determinato server Internet doveva conoscere l'indirizzo IP del server stesso, il protocollo di accesso (http, ftp, ecc ...), il formato del documento e l'appropriato "viewer" per poter leggere quel formato.

Ad oggi sono stati fatti enormi passi in avanti: è sufficiente aprire un browser, accedere all'indirizzo di un qualsiasi motore di ricerca, inserire una qualche stringa significativa come stringa di ricerca e visualizzare un determinato documento in formato pdf.

Attualmente, le modalità tecnologiche offerte dai web services, che si presentano come un nuovo framework e insieme di standards per l'elaborazione, stanno per permettere lo stesso livello di integrazione nella realtà, sinora proprietaria, dei GIS.

Il concetto di web services presuppone una rete di nodi distribuiti che possono includere dispositivi eterogenei di natura e complessità diversa (servers, workstations, client desktop, dispositivi leggeri quali telefoni cellulari, palmari, ecc ..). Gli standards dei web services forniscono il collante che permette a tali dispositivi di interagire, formando un "unico elaborativo" che può essere acceduto da qualunque altro dispositivo sulla rete stessa.

Una definizione tecnica del concetto di web service è la seguente: "una risorsa software indirizzabile mediante un URL che esegue funzioni e fornisce risposte". Il web service è una incapsulazione di software, magari esistente, in una forma comune che permetta ai servizi che esso esegue di essere visibili e accessibili da altre applicazioni software. Un web service può a sua volta richiedere servizi ad altri web services, e può attendere di ricevere risultati o risposte.

Rispetto ad altre tecnologie di integrazione i web services presentano un vantaggio: infatti sono stati progettati per interoperare in una modalità "loosely-coupled", per cui possono richiedere un particolare tipo di servizi attraverso Internet e attendere le risposte.

Un web service può essere individuato e usato da altri webservices, application, agenti o in generale clients. I web services possono essere combinati o concatenati per creare nuovi servizi: ad esempio, una organizzazione potrebbe richiedere, come parte del proprio portale, una location map, che potrebbe essere distribuita come web service da un map publisher che a sua volta potrebbe ottenere i dati spaziali da un terzo web service distribuito da un'agenzia o distributore di dati. Ognuno di questi providers potrebbe essere cambiato con un altro in qualunque istante.

Nel nuovo, e sempre più competitivo, mercato della "mobile communication" si aprono interessanti prospettive per cui servizi quali "Trova il più vicino ristorante" potrebbero essere offerti concatenando diversi web services quali quelli che forniscono POI (Point Of Interest), reti di trasporto integrate, calcolo percorsi, map rendering e conversione da testo a voce, ecc ... in modo che prevalga l'operatore che riesca ad ottenere il miglior mix tra questi servici offerti singolarmente da operatori specializzati.

Gli standards utilizzati nei web services sono una serie di protocolli che supportano delle sofisticate comunicazioni tra i vari nodi della rete, permettendo comunicazioni più "intelligenti" e dei processi computazionali collaborativi tra i vari nodi della rete, costruiti secondo un'architettura che sia "web services compliant".

Tali standards sono ad esempio XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), UDDI (Universal Description Discovery and Integration).

E' importante osservare che i web services non sono solo legati ad Internet ed al mondo web, bensì rappresentano un nuova e potente architettura per tutti i tipi di architettura distribuita.

Nel framework offerto dai web services i nodi della rete hanno tre possibili ruoli: client, servizio e broker (intermediario). Un client è un qualunque dispositivo che accede a funzioni (servizi), offerte da uno o più nodi della rete. Esempi classici di client sono le applicazioni attive su computer desktop, i browser, i dispositivi portatili, ecc ... Un processo client invia una richiesta ad un servizio e ne elabora la risposta. Un servizio è un processo elaborativo che resta in attesa di richieste, risponde ad ogni richiesta e ritorna un insieme di risultati al processo client chiamante. Un broker (intermediario), è essenzialmente un servizio che, basandosi su dei metadati, è in grado di indirizzare le chiamate dei clienti verso i processi "servizio" registrati per soddisfare le richieste: utilizzando il broker quindi un qualunque client può ricercare attraverso i metadati i servizi appropriati.

Un web service è "pubblicato" sulla rete, localmente ad una organizzazione o esternamente ad essa, fornendo un documento che ne descrive le funzionalità e le modalità operative. Il documento è creato in formato XML, utilizzando un particolare tipo o schema. Il web service è descritto usando il Web Services Definition Language (WSDL): è importante evidenziare che il WSDL è in un formato leggibile da una "macchina" e quindi le caratteristiche (capabilities), del servizio possono essere esplorate da altri web services. Nel caso di un web service geografico un documento WSDL potrebbe descrivere un servizio che, date le coordinate di un punto restituisce l'estratto Urbanistico del PRGC di un comune.

Per rendere la rete informata dell'esistenza di questo web service, il documento WSDL è pubblicato in un sito di "pagine gialle" conosciuto come Universal Discovery, Description and Integration o UDDI registry. Uno sviluppatore di web services, o direttamente un web service, può quindi fare uso dell'UDDI per individuare i servizi d'interesse.

Il nodo UDDI può quindi essere inteso come un metadata server di servizi registrati: effettuando delle ricerche su tali metadati i diversi client possono identificare i servizi di interesse.

La comunicazione tra web services è ottenuta inviando messaggi XML "wrappati" in un container interoperabile per permettere ai messaggi di attraversare reti diverse ed essere utilizzati su sistemi e architetture applicative diverse. Il meccanismo di wrapping è conosciuto come SOAP (Simple Object Access Protocol), ed è meglio inteso come un contenitore che aiuta a tenere i contenuti del messaggio sicuri.

Tale protocollo è sostanzialmente un'interfaccia API XML alle funzioni fornite da un web service: ogni web service "pubblica" le proprie SOAP API utilizzando il meccanismo WSDL citato in precedenza.

Con queste modalità si è in grado di garantire l'interoperabilità, in quanto ogni componente software comunica con altre componenti software attraverso dei protocolli standard SOAP e XML: questo significa che "rivestendo" (wrapping), un'applicazione di un'opportuna API SOAP questa può comunicare con altre componenti software.

Da questo quadro della situazione s'intuisce che i servizi offerti da un web services possono essere di diversa natura, da servizi "semplici" in cui il task richiesto dal client è soddisfatto da un solo web services sino a servizi "complessi" in cui l'intero task richiesto dal client è soddisfatto dalla composizione di diversi servizi che interagiscono tra loro comunicando secondo di protocolli citati in precedenza (service chaining).

In quest'ultimo caso si possono presentare diversi scenari:

User - Defined Chaining

In questo caso è l’utente che controlla e definisce l’ordine d’esecuzione dei singoli servizi componenti, come illustrato nella figura seguente:

Aggregate Services

In questo caso il servizio appare come un "singolo" servizio. Le concatenazioni e il coordinamento con i servizi componenti sono gestiti all’interno del servizio aggregato, e risultano completamente trasparenti all’utente finale del servizio, che non ha consapevolezza del fatto che il servizio che sta utilizzando è in realtà un servizio che aggrega componenti diverse come illustrato nella figura seguente:

Workflow - Managed Chaining

In questo caso l’esecuzione della concatenazione dei servizi componenti è gestita da un servizio di workflow. L’utente selezionerà un servizio "concatenazione di servizi" dal catalogo e il servizio di workflow lo realizzerà. In questo caso ovviamente all’utente finale del servizio, ha consapevolezza del fatto che il servizio che sta utilizzando è in realtà un servizio che aggrega componenti diverse come illustrato nella figura seguente:

Visti i diversi livelli di complessità è presumibile ipotizzare un primo sviluppo di web services "semplici", e in seguito servizi via via sempre più complessi ed articolati secondo gli schemi logici precedentemente illustrati. Occorre infatti considerare che, se da un lato vi possono essere esigenze e requisiti utenti che porterebbero sin da ora verso l’utilizzo di servizi "complessi", dall’altro, per realizzarli correttamente e per permetterne una gestione adeguata, è necessario realizzare tools che permettano di:

• Costruire e personalizzare service chaining da utilizzare sia da parte dei realizzatori di web services sia da parte degli utenti finali che possano in questo modo comporre direttamente di servizi complessi di cui necessitino partendo dai servizi di base offerti dai cataloghi di web services
• Ricercare i servizi migliori basandosi su caratteristiche diverse quali campo d’applicabilità del servizio e sua copertura, performance, stabilità affidabilità, qualità e aggiornamento dell’informazione (di particolare interesse questi ultimi parametri se si penda a GIS web services), prezzo, ecc ...