Servizi e componenti
Un servizio Web è un componente software che svolge un determinato servizio. Può occuparsi di eseguire una determinata elaborazione oppure di scatenare processi complessi in una rete aziendale. Un esempio di semplice componente è quello che forniti due numeri ne restituisce la somma. Un caso più complesso è un servizio bancario per disporre il pagamento di bonifici. Un qualsiasi componente remoto che svolga una qualsivoglia funzione può essere considerato un servizio.
Questo aspetto fa emergere una certa similitudine con i componenti remoti nella classica programmazione distribuita. Tecnologie quali Java RMI, CORBA e DCOM sono standard che consentono l’implementazione di sistemi a più livelli. Possono essere dunque considerati anche questi servizi Web? La risposta è no, in quanto queste tecnologie utilizzano una comunicazione di filo (il protocollo a basso livello) binario e non XML.
Inoltre, queste tecnologie consentono ed incoraggiano una granularità applicativa minore rispetto ai servizi Web. Quest’ultimi sono pensati per esporre servizi più a “grana grossa” (coarse-grained), mentre le tecnologie di programmazione distribuita di cui sopra possono venir utilizzate per strutturare componenti più a “grana-fine” (fine-grained). In definitiva i servizi Web espongono poche e semplici funzioni ad alto livello, i componenti remoti possono esporre chiamate a basso livello legate all’implementazione del programma. In questo senso, l’astrazione dei servizi Web è maggiore.

Internet
I servizi Web dialogano ed operano attraverso protocolli utilizzati in Internet. Questa scelta è stata adottata per più motivazioni: per prima cosa, il successo di Internet ha decretato una diffusione enorme dei suoi standard, sia a livello di supporto del software e dell’hardware disponibile in azienda, sia nelle competenze e conoscienze tecniche degli operatori del settore.
Utilizzare i protocolli di Internet vuole dire riutilizzare le infrastrutture esistenti e dunque ridurre le problematiche di integrazione.
Sebbene si parli di protocolli Internet in generale, lo standard più affermato per veicolare il dialogo con i servizi Web è il protocollo HTTP. Come si vedrà, le specifiche tecniche del protocollo di comunicazione più affermato, SOAP, predilogono questo standard, anche se la porta è aperta anche ad SMTP ed FTP.
Il fatto di utilizzare Internet per la comunicazione apre anche la connettività potenziale ad una rete globale di possibili utilizzatori. Esporre un servizio Web su Internet equivale a proporne l’utilizzo a tutti quanti abbiano una connessione di rete, un enorme bacino di utenza per potenziali acquirenti di servizi.
Inoltre i protocolli Internet hanno il vantaggio di passare agevolmente attraverso i firewall. Uno degli elementi che ha sempre frenato l’adozione di tecnologie quali Java RMI e CORBA per la comunicazione tra diverse imprese ed in generale in Internet è la necessità di configurazioni particolari di firewall per consentire il passaggio delle comunicazioni basate su questi standard.
Sia il fornitore del servizio che il fruitore, avrebbero dovuto modificare la configurazione di questi dispositivi di sicurezza per garantire il passaggio dei dati di comunicazione. Questa necessità si trova però spesso in antitesi con le necessità di sicurezza delle aziende. I servizi Web, utilizzando protocolli già consentiti dai firewall non hanno questo tipo di problematica.
Inoltre, è bene notare che classiche tecnologie di programmazione distribuita, richiedono elementi infrastrutturali aggiuntivi con i relativi costi di acquisizione e manutenzione. CORBA, ad esempio, richiede un broker, un componente che si occupi di coordinare la comunicazione tra gli oggetti distribuiti.

XML
Per finire, i servizi Web comunicano le loro informazioni in XML, il che porta numerosi vantaggi ed anche qualche svantaggio.
Per prima cosa, XML ha il vantaggio di essere nato per consentire la comunicazione tra diverse piattaforme. Questo significa che un blocco XML prodotto da un programma Java su Solaris può essere letto da un programma C su Windows. Oppure da un palmare. Oppure da un programma COBOL su un Mainframe.
Lo standard XML risolve già, a livello di informazione, tutte quelle problematiche di integrazione con sistemi eterogenei. Non è necessario preoccuparsi di problematiche di encoding diversi, oppure della formattazione delle informazioni. Un blocco XML ha lo stesso contenuto su tutte le diverse piattaforme.
Inoltre, XML ha la particolarità di essere un protocollo testuale (e non binario, come quello utilizzato in RMI o CORBA) quindi facilmente leggibile dall’essere umano. Questo è un vantaggio in fase di debug dell’applicazione in quanto il valore dei singoli campi è immediatamente visibile ma ha lo svantaggio di richiedere più potenza di elaborazione rispetto a protocolli binari, più vicini alla macchina. Si consideri però che un minimo di astrazione è necessario anche per ottenere l’interoperabilità.
Per finire, come i protocolli Internet, anche XML sta ottenendo un’ottima accettazione da parte dell’industra informatica che si traduce nella disponibilità di strumenti di sviluppo e controllo e nella conoscenza della comunità.

Novità o evoluzione?
I servizi Web sono dunque la riproposizione in chiave moderna - o Internet/XML della vecchia programmazione distribuita? In gran parte la risposta è si. Non ci troviamo davanti a tecnologie rivoluzionarie ma piuttosto ad una evoluzione realizzata per ovviare alle problematiche che sono sorte con le classiche soluzioni di programmazione distribuita.
Una evoluzione che però non è partita, come spesso accade, dalla base già esistente in quanto, a parte i concetti astratti, non è stato mantenuto alcuno standard esistente. La motivazione è da ricercarsi anche in aspetti strategici: da una parte, il mondo proprietario di Microsoft ha sempre desiderato imporre DCOM come protocollo universale di comunicazione, ma purtroppo nella sua visione l’universalità di DCOM si sarebbe dovuta realizzare con la presenza del solo Windows su tutti i computer del mondo (anche sui mainframe?). Dall’altra parte CORBA, sviluppato da un consorzio come standard e non come prodotto, ha avuto una accettazione soprattutto nel mondo Unix, in contrapposizione con DCOM che ha avuto uno sviluppo maggiore sui sistemi Windows. Sebbene siano a disposizione prodotti per l’integrazione dei due mondi, le problematiche infrastrutturali hanno posto sempre un freno all’adozione di queste tecnologie.
Alcuni ritengono, inoltre ,che Microsoft fosse alla ricerca di qualche cosa di nuovo per promuovere .NET che, se avesse mantenuto il livello attuale di utilizzo di tecnologie proprietarie (DCOM) non avrebbe riscosso un grande successo con gli sviluppatori. Da qui la nascita di SOAP e dei servizi Web che comunque ha come risultante la possibilità di liberarsi dal vincolo di utilizzare DCOM per parlare con sistemi Microsoft.
Java, dal canto suo, ha sviluppato uno standard di programmazione distribuita proprietaria, invece che rivolgersi ai protocolli esistenti, frammentando ulteriormente il mercato. C’è comunque da riconoscere che RMI si è evoluto nel tempo supportando il protocollo di comunicazione IIOP di CORBA di fatto rendendo la piattaforma Java una ulteriore piattaforma abilitata a CORBA.
Si noterà, comunque, come molte tecnologie dei servizi Web riprendano concetti già sviluppati nelle classiche tecnologie per la programmazione distribuita, ad esempio in ambito dei registri di servizi Web.

Registri di servizi Web
Il tipico flusso di lavoro di un servizio Web non è però limitato al solo protocollo di trasporto XML/Internet accennato sopra. La visione completa coinvolge ulteriori componenti: i registri di servizi.
Questi elementi rispondono sostanzialmente alla domanda: “Come fanno i singoli potenziali utilizzatori di servizi Web a sapere quali e quanti servizi sono disponibili e come accedere a questi?”.
I registri di servizi non sono quindi altro che una sorta di pagine gialle elettroniche che catalogano, ordinano e rendono disponibili per ricerche, gli elenchi di servizi Web disponibili sul mercato. Inoltre, consentono di scaricare la documentazione tecnica dei servizi che consente agli utilizzatori di implementare i client che ne vogliono fare uso.
I registri sono per forza di cose entità a livello mondiale: il Web di fatto annulla i limiti delle nazioni e dei continenti consentendo, almeno al livello tecnico, l’interoperabilità tra entità anche enormenente distanti tra di loro.
Vista l’enorme potenziale quantità di informazione (si immagini un elenco dei più disparati servizi, forniti da società disseminate in tutto il mondo), è d’obbligo un meccanismo di ricerca fortemente basato sulla tassonomia, cioè sulla catalogazione precisa delle informazioni.
Ma le informazioni tecniche non sono le uniche presenti nei registri: anche informazioni puramente commerciali, come indirizzo, numero di telefono ed indirizzo e-mail possono essere pubblicate e successivamente estrapolate al fine di instaurare un contatto commerciale tra due parti.

Flusso di lavoro
La sequenza tipica delle operazioni nel mondo dei servizi Web prevede dunque una serie di passaggi che iniziano dal registro dei servizi e terminano con il protocollo di comunicazione.
In particolare, uno scenario abbastanza completo ed orientato all’integrazione B2B è il seguente (in seguito si vedranno esempi completi anche non indirizzati al B2B):

• la società A desidera fornire attraverso Internet un servizio, ricerca dunque nel registro la tipologia di servizio che vuole offrire. Se non esiste una tipologia conforme o se quelle trovate non dovessero soddisfarla, ne può creare una ad hoc;
• con lo schema che formalizza la definizione del servizio alla mano, il reparto IT prepara una implementazione del servizio;
• il servizio viene pubblicato sul registro in modo che possa essere trovato dai potenziali clienti;
• a questo punto la società B, in cerca proprio del servizio offerto dalla società A, decide di eseguire una ricerca nel registro dei servizi Web;
• il servizio viene trovato e con esso la sua descrizione formale;
• le due società si incontrano e stipulano un accordo di fornitura di servizi attraverso il Web firmando un contratto. Questa fase è gestita a livello umano ed in effetti non sembra plausibile pensare anche in un futuro più o meno prossimo che siano, anche per questo aspetto, le macchine ad occuparsene.
• il cliente integra il servizio Web all’interno del proprio sistema informativo;
• a regime, viene utilizzata una comunicazione XML attraverso Internet per far dialogare in modo automatico i processi delle due aziende.

Questo flusso operativo sposta (in parte) il modo di fare affari, tra le persone alle macchine, rendendo possibile la comunicazione diretta tra i sistemi informatici di due diverse aziende.

Alcuni esempi
Per capire meglio come funzionano e quali sono le potenzialità dei servizi Web, si vedrà ora qualche esempio sia nell’ambito B2B (Business to Business) e B2C (Business to Consumer) che all’interno delle quattro mura dell’azienda.

Business on-line
Un possibile scenario in ambito B2B potrebbe essere quello dove un’azienda ha la necessità di approvigionarsi di materie prime dai suoi fornitori. Si consideri ad esempio le ipotetiche aziende Tondini Riuniti S.p.A. e Costruzioni S.p.A.
La Tondini Riuniti è una società che vende tondini d’acciaio per l’edilizia e vuole aprire nuovi sbocchi al proprio business sul Web. In particolare vuole mettere a disposizione dei suoi potenziali clienti un modo per potersi approvigionare senza implicare i costi di una tipica gestione ordini/fatturazione. Il reparto IT della Tondini studia dunque un servizio Web che consente ai clienti di eseguire le ordinazioni del materiale su Internet. Per costruire il componente, si rivolge ad un registro di servizi Web e scarica la descrizione di servizio che più si adatta alla sua tipologia applicativa. A questo punto entra in gioco la Costruzioni S.p.A., che desidera instaurare un rapporto di affari che gli consenta di agevolare il più possibile le ordinazioni di tondini per l’edilizia in modo da minimizzare le giacenze di magazzino riducendo i costi di stoccaggio e massimizzando i profitti.
La Costruzioni ricerca su Internet un fornitore di tondini abilitato ai servizi Web e trova la Tondini Riuniti. Scarica la descrizione tecnica del servizio Web ed implementa un programma in grado di comunicare con il servizio.
A questo punto, integra il programma di accesso al servizio nel proprio sistema informativo, in modo da eseguire un riordino quando la giacenza di magazzino arriva a livello minimo definito.

Raccolta dati
Un altro scenario dove possono essere utilizzati i servizi Web, potrebbe essere nell’industria, ad esempio per la raccolta dati. La natura basata su messaggi dei servizi Web ne rende una possibile alternativa per l’implementazione di questo tipo di sistemi.
Si immagini un’applicazione in campo ambientale. Centrali di raccolta dati sulla qualità dell’aria poste in centri nevralgici della città potrebbe essere dotata di sensori collegati ad un micro-computer. Da qui, un’applicazione J2ME (Java2 Micro Edition) potrebbe, ad ogni intervallo di tempo prestabilito, ad esempio ogni ora, inviare i dati alla centrale. Le informazioni, codificate in XML, raggiungerebbero poi tramite una connessione Internet o tramite SMS, la centrale di raccolta dati. Qui, un unico servizio Web di raccolta delle informazioni, fungerebbe da concentratore, passando le informazioni al programma server che si occuperà di eseguire le elaborazioni statistiche necessarie ed a memorizzare le informazioni nel database centrale dell’applicazione.

Integrazione di sistemi
Un’ulteriore applicazione dei servizi Web, questa volta all’interno dell’azienda è il loro uso per problematiche di integrazione (EAI - Enterprise Application Integration). Tipicamente, l’infrastruttura IT che si è evoluta nel tempo, è composta da applicazioni distribuite su piattaforme eterogenee. Programmi COBOL su mainframe spesso costituiscono gli oggetti di business che la presentazione utente ed applicazioni di terze parti devono interfacciare. Spesso ci si scontra con la necessità di portare sul Web le applicazioni sviluppate su mainframe e le soluzioni di intergrazione con l’host che sono state applicate in passato sono molteplici. Tipicamente i prodotti commerciali di integrazione hanno sempre proposto un insieme di API proprietarie: con i servizi Web nasce l’opportunità di integrare il mainframe con standard non proprietari. E’ possibile dunque pensare all’integrazione dei programmi COBOL in XML su HTTP, magari utilizzando un gateway sul lato server. A questo punto, le applicazioni sono in grado di accedere ai programmi in modo agevole, magari passando attraverso un registro di servizi interno per l’individuazione del componente da richiamare.
Il disaccoppiamento che può realizzarsi utilizzando un XML indipendente dalla natura e conformazione dei componenti, può portare ad una maggiore facilità di reingegnerizzazione del lato mainframe, quando questa possa effettivamente diventare un’opzione. A questo punto lo sviluppatore dell’applicazione non è costretto ad imparare l’API di uno specifico prodotto di integrazione ma può rifarsi ad un più aperto insieme di specifiche.

Shopping palmare
In un mondo (ed un paese - il nostro) dove la diffusione dei telefoni cellulari ha raggiunto negli ultimi anni traguardi considerevoli, non è difficile immaginare la diffusione di dispositivi che siano la convergenza degli attuali telefonini e dei computer palmari. Questi dispositivi, anche se dotati di capacità di elaborazione e memoria limitati, possono offrire potenzialità enormi. Ad esempio, un utente potrebbe dedicarsi allo shopping stando comodamente seduto in treno.
Sullo schermo del suo palmare potrebbe accedere ad un catalogo di prodotti, riempire il suo carrello della spesa e poi ingaggiare un servizio Web per l’inoltro dell’ordine. La meccanica sarebbe molto simile a quanto ad oggi in essere nei siti Web di acquisto on-line ma la limitata disponibilità di spazio del palmare non consentirebbe l’accesso allo stesso sito Web utilizzato con un normale browser. Ecco che un programma apposito potrebbe essere più adeguato, anche se, in entrambi i casi, all’atto dell’ordine - con la necessità di accedere al sistema informativo aziendale - potrebbe ad ogni modo essere richiamato un servizio Web.

Agenzia viaggi virtuale
Un’ultimo scenario è una citazione di un caso d’uso di un prodotto di HP, sicuramente in anticipo sui tempi, chiamato eSpeak. Questa infrastruttura, concettualmente simile ai servizi Web, si spingeva ancora oltre, prospettando l’integrazione di una serie di servizi e lasciando al software un certo grado di libertà nella scelta dei componenti da integrare.
In questo scenario (trasposto per l’Italia), il signor Rossi desidera fare un viaggio in Sardegna per le vacanze estive. Si connette ad Internet e accede al sito web di un’agenzia di viaggi virtuale. Qui inserisce la data di partenza, quella di ritorno ed una serie di altre opzioni, come il numero di stelle dell’albergo o la cilindrata della macchina a noleggio che desidera trovare sul luogo.
A questo punto, il software di backend del sito Web, comincia ad eseguire una serie di richieste ai servizi Web di diversi fornitori. Interpella il registro dei servizi ed identifica le società che offrono traghetti per le isole o che affittano macchine in Sardegna. Contatta Sardinia Ferries e suoi concorrenti per verificare la disponibilità del traghetto ed il costo. Confronta i prezzi e sceglie il meno caro ma che risponda alle richieste di qualità del cliente. Verifica la disponibilità dell’albergo, che abbia le caratteristiche richieste e che abbia una stanza libera vista mare per due persone (il signor Rossi vuole fare una vacanza con la moglie). Il back-end del sito va avanti così fino a raccogliere tutte le informazioni necessarie per organizzare il viaggio. Una volta completato il lavoro, presenta al signor Rossi le possibili opzioni. A lui non rimane altro che sceglierne una e dare il numero di carta di credito per il pagamento.
Una volta ottenuti gli estremi, il servizio Web si occupa di formalizzare gli ordini a tutte le parti prenotando i vari beni o servizi richiesti. Ovviamente, nel fare questo, il servizio Web si occuperà, nel caso di eventuali errori, di applicare un rollback distribuito su tutte le parti interessate.
Scenario interessante ma riassumibile così: azzardato allora, impraticabile ancora ad oggi. In un futuro lontano probabile.

Ricerca delle informazioni
Un’altra applicazione dei servizi Web può essere quella relativa alla ricerca delle informazioni strutturate su Internet. Un’applicazione di ricerca potrebbe conoscere le interfacce XML di vari servizi quali la tracciabilità delle spedizioni tramite i corrieri (come UPS), oppure la visualizzazione di mappe anche per costruire percorsi. Oppure potrebbe collegarsi ad un servizio per conoscere in tempo reale la programmazione dei film nei cinema della città, o collegarsi ai servizi delle compagnie aeree per conoscere i voli disponibili per raggiungere un determinato luogo. Fantascienza? Realtà per gli utenti di Apple: la nuova versione del sistema operativo dei Macintosh, Mac OS X 10.2 dispone di uno strumento di ricerca così strutturato (figura 1)

Figura 1 – L’interfaccia utente di Sherlock

Il programma consente queste particolari ricerche strutturate che hanno la particolarità di non chiamare motori di ricerca tradizionali come Google, ma di accedere a servizi Web specifici per la distribuzione di quelle particolari informazioni.
Altri di questi scenari proposti sono concreti e magari sono stati già realizzati. Ad esempio, nel settore bancario, l’integrazione del mainframe tramite XML è una soluzione che è già stata adottata nel recente passato. Anche se alcune volte non sono stati utilizzati i protocolli affermati per i servizi Web ma è stata sviluppata una soluzione proprietaria, gli elementi di base dei servizi Web (Internet ed XML) sono stati utilizzati.
Altri scenari sono più futuribili: ad oggi i palmari wireless non sono sicuramente un fenomeno di massa che giustifica il costo per la creazione e la manutenzione di servizi Web a loro uso e consumo.
Altri scenari ancora sono molto futuribili: il caso dell’agenzia di viaggi è molto complesso ed oltre alla difficoltà di implementare una logica applicativa di orchestrazione così delicata sembrano maggiori le difficoltà di carattere organizzativo che nascono quando vengono coinvolte un così grande numero di interlocutori.
Ad ogni modo, queste sono le potenzialità, la cui realizzazione è più o meno vicina, che offrono i servizi Web.
Tutti gli scenari, comunque, sono tecnicamente realizzabili anche con strumenti tradizionali, anche se la loro effettiva implementazione può essere frenata dalle problematiche ad esse legate.

Java e servizi Web
Da più parti si sente accostare ai Web Services la piattaforma Java, con differenti buone ragioni.
Per prima cosa, la base dei Web Services è Internet ed XML. Queste due tecnologie si sposano molto bene con la piattaforma Java (gli statunitensi dicono che Java ha un “natural-fit”). Per quanto riguarda Internet, Java è nato per interagire con esso e sebbene abbia, per certi versi, “migrato”, dal client - con le Applet, al server, con la piattaforma J2EE (Java 2 Enterprise Edition) ha sempre mantenuto un forte legame con Internet e le sue tecnologie. Un package di base di Java, presente fin dalla versione 1.0 è java.net e dispone di classi per dialogare attraverso le socket e trattare con gli URL. Al di sopra di questo, Java ha poi sviluppato tutta una serie di tecnologie a più alto livello come JavaMail, per il supporto della posta Internet e dei protocolli relativi, le tecnologie server quali Servlet e JSP (Java Server Pages) per l’estensione dei Web Server, la tecnologia EJB (Enterprise JavaBeans) per portare le applicazioni enterprise su Internet.
Inoltre Java ha una forte convergenza con XML in quanto se il primo è considerato il linguaggio “portabile” (o almeno il più portabile ad oggi disponibile), il secondo consente le informazioni portabili. Java ed XML sono dunque il connubio che consente di rendere portabile tutta l’applicazione.
Da qualche parte si sente dire che XML da solo potrebbe essere la soluzione per realizzare applicazioni portabili, ma c’è da considerare che, sebbene l’informazione XML sia in effetti indipendente dalla piattaforma, tutte le volte che questa raggiunge un computer, ha la necessità di essere elaborata. Se il programma che la interpreta non è realizzato in Java, questo dovrà essere reimplementato su tutte le diverse piattaforme.
In secondo luogo è bene chiarire che le tecnologie alla base dei servizi Web non prevedono standard per la realizzazione della logica applicativa dei componenti, e probabilmente non la prevederranno neanche in futuro. Questo perché i servizi Web non sono altro che una “facciata” (facade) per componenti applicativi già esistenti.
Chiarito questo aspetto, appare ovvio che la piattaforma ad oggi più affermata per l’implementazione dei servizi di business su Internet, J2EE, sia una candidata eccellente all’implementazione dei servizi Web.
Implementare i servizi come componenti EJB, consente di sfruttare la piattaforma migliore per la realizzazione dei servizi sul server e permette poi la loro presentazione all’esterno come servizi Web.

Java Web Services Developer Pack
La SUN ha raccolto le proprie tecnologie a supporto dei servizi Web all’interno del JWSDP (Java Web Services Developer Pack). Questo insieme di tecnologie è un toolkit organico che ruota attorno ad una versione “personalizzata” di Tomcat. Precisamente, le tecnologie presenti all’interno del JWSDP sono:

• Java API for XML Messaging (JAXM);
• Soap with Attachments API for Java (SAAJ);
• Java API for XML Processing (JAXP);
• Java API for XML Registries (JAXR);
• Java API for XML-based RPC (JAX-RPC);
• JavaServer PagesTM Standard Tag Library (JSTL);
• Tomcat;
• Ant;
• strumenti di amministrazione, gestione e deploy delle Web Application;
• Registry Server UDDI.

Tramite questa distribuzione di SUN è possibile sperimentare e sviluppare con praticamente tutte le tecnologie di base dei servizi Web, come SOAP, WSDL ed UDDI.
Il software è scaricabile dall’indirizzo http://java.sun.com/webservices.

Non solo JWSDP
Altri strumenti degni di nota sono Apache Axis, l’implementazione open source del consorzio Apache nata dalle ceneri dell’implementazione di SOAP di IBM donata diverso tempo fa proprio al consorzio Apache. Il particolare interessante di Axis è il fatto che supporta lo standard in via di definizione JWS (Java Web Service) che consente di creare servizi Web senza codifica ma inserendo alcuni metatag (simili a quelli utilizzati in Javadoc) di definizione all’interno del codice che implementa il servizio.
Nella forma più semplice, è possibile creare una semplice classe Java, rinominarla con l’estensione .jws, copiarla sotto Tomcat per fare in modo che il runtime di Axis la riconosca e gli crei intorno un’infrastruttura dinamica che consente di esporre la classe come servizio Web.
Un altro strumento interessante è il Borland Web Services Developer Kit che non è altro che Axis con l’aggiunta di wizard visuali che semplificano molto l’approccio allo sviluppo dei servizi Web.
Axis è scaricabile all’indirizzo: http://xml.apache.org/axis/index.html, mentre il suo predecessore Apache SOAP è disponibile a: http://xml.apache.org/soap/index.html.