Tutti gli standard attuali per creare i servizi Web

I Web service sono applicazioni Internet modulari che eseguono compiti specifici e conformi a definiti formati tecnici. Un Web service può essere un’informazione in tempo reale sulla qualità di un ristorante a un processo completo per la prenotazione di un biglietto aereo. Il formato tecnico modulare dei servizi Web, insomma, assicura che questi servizi saranno semplicemente mescolati e armonizzati per creare processi di business completi. Gli elementi oggetto dei servizi possono essere pubblicati dinamicamente, scoperti e aggregati in una gamma attraverso Internet.
In questo modo, possono essere creati più facilmente prodotti innovativi, processi di business e catene del valore. I Web service possono essere distribuiti a ogni tipo di dispositivo (telefoni cellulari, Pda, computer e così via) e possono essere anche trasformati dalle applicazioni esistenti.

Le origini della specie Xml
La storia dei Web service inizia con la creazione di un curioso ibrido chiamato Xml-Rpc. L’Xml (eXtensible markup language) è nato nel 1996 con lo scopo di consentire l’estensione dell’Html (Hypertext markup language). L’Xml è ciò che si definisce un meta linguaggio, ovvero uno strumento che consente di definire i linguaggi di segnatura, perciò deve disporre di un alto livello di flessibilità. Oggi esistono centinaia di dialetti derivati dall’Xml a partire dall’electronic business Xml (ebXml) per arrivare al Weather observation markup format (Womf).
L’Xml mostra un’interessante proprietà: può essere letto sia dall’uomo sia dai programmi. Questo suggerisce una possibile soluzione verso l’incompatibilità degli standard attuali come il Remote procedure cCall (Rpc), il Component object model (Com) e il Remote method innovation (Rmi). L’Rpc lavora soprattutto con il C e il C++ mentre l’Rmi è limitato a Java. Il Com può essere usato da diversi linguaggi, ma è supportato solo da Windows. Corba (Common object request broker architetture) opera con diversi linguaggi e con tutte le principali piattaforme, ma è ampiamente percepito come impopolare in quanto Microsoft ha mostrato verso di esso una certa indifferenza e alcuni sviluppatori ritengono che sia troppo complicato.
All’inizio del ’98, Dave Winner di UserLand ebbe l’idea di creare quello che fu chiamato Xml-Rpc o Simple object access protocol (Soap). In seguito, fu deciso di chiamare Soap la versione di Microsoft, mentre Winner conservò il nome di Xml-Rp per la propria variante.
L’idea di base era quella di inviare i messaggi Xml su Http, il protocollo Web in grado di fornire un livello dove tutti i computer possono dialogare tra loro. Un pezzo di codice che può essere richiamato attraverso Soap o Xml-Rpc venne quindi chiamato Web service. Soap è un protocollo leggero per lo scambio di informazioni in un ambiente decentralizzato, tipicamente attraverso un’intranet o Internet, e gioca un ruolo simile a quello di Iiop (in Corba e J2Ee) o dell’Http (nei comuni Web browsing). Basato su Xml, Soap si compone di tre parti: un involucro che definisce un framework per descrivere cosa c’è in un messaggio o come processarlo; un set di regole codificate per esprimere istanze di tipi di dati definiti dalle applicazioni; una convenzione per rappresentare Rpc e le risposte.
L’attuale versione di Soap, la 1.1, è impiegata virtualmente in tutti i prodotti sul mercato. Il gruppo Xml Protocol (Xp) del W3C sta lavorando sulla release 1.2, che vedrà l’aggiornamento dell’involucro di Soap e degli schemi di codifica per consentire la conformità all’Xml Schema.
A fianco di Soap, uno standard che sta assumendo sempre più rilevanza è Uddi (Universal description, discovery and integration), che fu annunciato nel settembre del 2000 da Ariba, Ibm e Microsoft.
L’Uddi è stato la base dei progetti di e-commerce e dei marketplace online, poco prima che scoppiasse la bolla della new economy. Basato su Soap e Wsdl, Uddi permette ai provider di pubblicizzare i Web service che sono preparati a offrire. Equivalente dei name server nel mondo Corba e Java, Uddi opera su tre livelli separati: white page (informazioni sugli indirizzi), yellow page (categorie business), green page (dettagli tecnici su come deve essere condotta la transazione).

Directory private e pubbliche
Come i name server, le directory Uddi possono essere pubbliche o private, anche se questo fa una piccola differenza a livello tecnico.
Per quanto riguarda la sicurezza e la confidenzialità, è auspicabile che le directory Uddi private siano inaccessibili a chiunque non abbia un’autorizzazione.
D’altro canto, le directory pubbliche, necessitano di essere ben pubblicizzate e ampiamente accessibili. Devono, inoltre, essere robuste e scalabili, e possono incontrare pesanti carichi di lavoro.
Ibm, Microsoft e Sap mantengono directory Uddi pubbliche, conosciute come business registry. In pratica, si tratta della stessa directory, che le tre società hanno sincronizzato per essere sicure di fornire sempre esattamente la stessa informazione. Alcuni esperti ritengono che le directory Uddi possano, in futuro, offrire alle applicazioni lo stesso genere di servizio che offrono motori di ricerca “popolari” come Google e Hotbot.
Uddi 2.0 è stato pubblicato nel giugno 2001, mentre il registro pubblico è entrato in beta successivamente. In diciotto mesi, cinquemila aziende hanno fornito i loro contatti e indici a circa tremilacinquecento Web service. Uddi 2.0 rende più facile per i programmatori interrogare i registri Uddi e potenzia il supporto per il modeling di relazioni business. Allo stesso tempo, Hp e Sap si sono accordate con Ibm e Microsoft per agire come “co-host” di directory Uddi pubblicamente distribuite. Uddi 2.0 non è però sufficiente per supportare su ampia scala il trading elettronico. È per questo che Ibm e Microsoft stanno lavorando a una soluzione completa.
Uddi 3.0 è stato annunciato alla fine del luglio scorso, insieme con l’adozione di Uddi da parte di Oasis (Organization for Advancement of Structured Information Standards). La nuova versione estende il focus di Uddi 2.0 su piccoli registri federati, spesso inseriti all’interno del firewall, attraverso l’aggiunta di caratteristiche di interoperabilità è di replica, di maggiore sicurezza e di un ulteriore supporto per il Wsdl.
È importante per Oasis farsi carico della responsabilità di Uddi, in quanto è essenziale l’esistenza di una trading directory. Se lo desiderano, i programmatori possono operare da soli con Soap o Xml-Rpc, oppure possono avvalersi di Wsdl. Tuttavia, l’impiego di Uddi non può essere deciso dal singolo sviluppatore: si tratta di una scelta che occorre fare a livello corporate.

Integrazione Ldap
Un’interessante direzione futura dell’Uddi è l’integrazione con il Lightweight directory access protocol (Ldap). Bea, Novell e Sun hanno espresso l’intenzione di muoversi in questa direzione, che dovrebbe prevenire che l’Uddi venga trascurato in favore del più conosciuto e maturo Ldap.
Un altro standard già definito in ambito Web service è Wsdl (Web service description language), un linguaggio basato su Xml e annunciato congiuntamente da Microsoft e Ibm nel settembre 2000: esprime quello che un Web service può fare, dove vive e come può essere richiamato. Si tratta di un ruolo simile a quello dell’Interface Definition Language (Isl) in Corba e Com+.
Un contratto Wsdl è un documento Xml che definisce input e output di un Web service, inclusi gli Xml Schema richiesti per creare documenti. Ciascun file Wsdl fornisce una definizione astratta di Web service, di come il servizio si lega a una particolare implementazione di rete e a un appropriato formato di dati.

Wsdl, l’astrazione necessaria
Un documento Wsdl definisce i servizi come una raccolta di endpoint di rete (banalmente, porte). La definizione astratta di endpoint e messaggi è separata dal loro impiego concreto o dal collegamento al formato di dati: i messaggi sono una descrizione astratta dello scambio dei dati e i tipi “porta” sono collezioni astratte delle operazioni.
Le specifiche del formato di dati e del protocollo per un particolare tipo di endpoint costituiscono un binding riutilizzabile. L’endpoint è definito dall’associazione di indirizzi di rete con binding riutilizzabili; una raccolta di porte definisce un servizio.
Wsdl rappresenta un compromesso tra gli originali linguaggi di descrizione di Ibm e Microsoft Service description language (Sdl), Service contract language (Scl) e Nassl (Network accessibile service specification language). Insieme con Uddi e Ws-Inspection, Wsdl sovrasta anche Disco di Microsoft, l’originale tecnica .Net per scoprire i Web service.
W3C ha annunciato la bozza di Wsdl 1.2 lo scorso luglio. Gli obiettivi dell’iniziativa sono di riordinare le specifiche, eliminare la ridondanza e le caratteristiche non interoperabili e fornire un legame a Soap 1.2, Http e Multipurpose Internet mail extensions (Mine). Wsdl 1.2 è anche compatibile con Xml Schema e Xml Information Set. Tuttavia, come nel caso di Soap 1.2, i vendor sono piuttosto riluttanti a implementare Wsdl 1.2 fino a che non sarà completato definitivamente.
Con l’emergere di Wsdl, la scuola di pensiero che professa la necessità di avere un repository esterno ritiene di avere “inanellato una vittoria”. Nessun Web service standard è più stabilmente definito: Ibm, Microsoft e altri hanno affermato che Wsdl è e rimane il cuore dei Web service.
Gli sviluppatori, compresi quelli che hanno partecipato ai test di interoperabilità tra i Web service, hanno accentuato il fatto che Wsdl rende il loro lavoro più facile: invece di preoccuparsi del Soap di qualcun altro e infrangere le regole che stanno alle sue spalle, bisogna solo badare ai file Wsdl. Oppure, ancora meglio, usare uno dei numeri progressivi di tool automatici per generare codici direttamente da Wsdl, allo stesso modo in cui gli sviluppatori Corba generano il loro codice da Idl.
Esistono, comunque, ancora problemi importanti, a partire dall’incompatibilità di Wsdl con Xml Schema. È però vero che ancora pochi hanno realmente compreso sia Wsdl sia Uddi. Come risultato, entrambe le specifiche tendono a sovrapporsi.
Accanto agli standard già definiti, in campo Web service c’è anche una serie di proposte ancora in fase di valutazione. Tra questi troviamo Ws-Inspection, risultato di un altro sforzo cooperativo tra Ibm e Microsoft. Si tratta di un formato Xml che può essere usato per determinare quali servizi sono disponibili su uno specifico sito Web e come possono essere richiamati. Un documento di Ws-Inspection fornisce un modo per aggregare referenze ai documenti di descrizione dei servizi scritti in un qualsiasi formato. Questo approccio è complementare a Uddi, che migliora i servizi in una directory centrale, non preoccupandosi da dove vengono forniti se non in una fase successiva, e a Wsdl, che propone dettagli su come richiamare servizi specifici.
Il prefisso Ws segnala forte e chiaro che si tratta di una specifica dello stack Microsoft Gxa. Ibm e Microsoft hanno raggiunto un compromesso tra le loro rispettive specifiche in-house Ads e Disco. Hanno quindi annunciato il loro standard nel settembre 2001, ma al momento Ws-Inspection non è stato sottoposto all’attenzione del W3C, né dell’Oasis o a qualsiasi altro gruppo di certificazione. Ibm, Microsoft e VeriSign, poi, hanno annunciato Ws-Security nell’aprile 2002 in una roadmap intitolata “Security in a Web service world”.

Si lavora sulla sicurezza
Ws-Security, che definisce un set di estensioni Soap standard e di meccanismi per lo scambio di sicurezza e messaggi firmati, è un ampio framework nel quale possono essere inserite altre specifiche di sicurezza. È compatibile con gli schemi allo stato dell’arte, come Kerberos e Pki (Public key infrastructure) e il lavoro corrente del W3C/Ieff che include Xml Segnature e Xml Encryption. Sempre nello scorso aprile, sono state definite sei conseguenti specifiche: Ws-Policy, Ws-Trust, Ws-Privacy, Ws-Conversation, Ws-Federation e Ws-Authorization.
Nel luglio di quest’anno l’Oasis ha deciso di ospitare gli ulteriori sviluppi di Ws-Security, istituendo un comitato tecnico dove Ibm e Microsoft hanno il medesimo livello di importanza. Presumibilmente, saranno ospitati all’interno di Ws-Security alcuni standard di sicurezza emergenti come Saml (Security assertion markup language) e Xkms (Xml key management specification).
Ws-Coordination è l’ultima serie di standard di fatto annunciati in agosto da Bea, Ibm e Microsoft.
Ws-Coordination, Ws-Transaction e Bpel4ws sono stati lanciati nello stesso momento e, a parte l’ultimo, gli altri due vengono spesso usati insieme. Ws-Coordination fornisce un framework espandibile per i protocolli usati per coordinare le azioni di applicazioni distribuite, incluse quelle che necessitano di raggiungere un consistente accordo sul risultato di transazioni distribuite. Il servizio di coordinazione consiste nell’attivazione (che crea il contesto per il coordinamento di ogni attività da inviare alle applicazioni), nella registrazione (che permette all’applicazione di coordinare i protocolli) e in un insieme servizi di protocollo per ciascun tipo di coordinazione supportata. La specifica raccomanda che l’implementazione dei processi di business faccia uso di Ws-Security per assicurare che i messaggi non siano modificati o falsificati.
Ws-Transaction è stato progettato per essere usato in unione con altre parti di Gxa, come Ws-Coordination, Ws-Security e Ws-Transaction. Rimane però il difficile problema della durata delle transazioni Web. Nei processi distribuiti, tali transazioni vengono convenzionalmente definite da quattro proprietà, dette familiarmente Acid (Atomicity, consistency, isolation, durability).
L’Atomiticity, se positiva, rende possibili tutte le operazioni, se negativa non si può avere alcuna transazione. Consistency: l’applicazione ha ottenuto la validazione delle transazioni, mentre con l’Isolation, gli effetti delle operazioni non vengono condivise al di fuori della transazione fino a quando non è completata con successo. Durability, infine, significa che una volta che una transazione è completata con successo, i cambiamenti apportati falliscono.
Nelle tradizionali applicazioni di database, nessuna transazione richiede più di pochi secondi. Le transazioni Web possono essere più lunghe e non sempre necessitano di avere proprietà Acid complete. A queste ultime si applica Ws-Transation alle altre Ws-Coordination.

Il problema transazioni
Più precisamente, Ws-Transaction definisce due tipi di transazioni: una atomica, che impiega attività coordinate che hanno breve durata e sono eseguite in un dominio limitato sicuro (che corrisponde alle transazioni convenzionali distribuite), e una business, che viene usata per coordinare le attività lunghe che tendono a bloccare la sorgente di dati fino alla fine del task. In tal caso, le azioni sono immediatamente applicate e permanenti. Le attività business permettono ai processi e ai sistemi workflow di interoperare attraverso confini sicuri e differenti implementazioni dei vendor. Universalmente riconosciuto come uno dei peggiori acronimi mai definiti, Bpel4ws (Business process excution language for web service) combina il linguaggio di Microsoft con quello di Ibm, in questo caso BizTalk Xlang con Web service flow language (Wsfl): alla fine il risultato punta più alla completezza che non comprensibilità.
Gli altri standard concorrenti sono Web Service choreography language (Wsci), il preferito da Bea, Sap e Sun; Xml processing description language (Xpdl), definito dal Workflow management coalition; Business process specification schema (Bpss), parte di ebXml di Oasis.
Ibm e Microsoft hanno fatto un lungo passo in avanti con Bpel4ws, realizzando, di fatto, un “super-standard”, che vanta credenziali molto forti. È stato, però, osservato che Xlang e Wsfl sono stati distillati da BizTalk e WebSphere Mq e che possono non essere sufficientemente aperti e astratti.
Wsci (Web service choreography interface) è l’ultima aggiunta. Collocandosi approssimativamente nella stessa posizione di Bpel4ws, punta a descrivere come un unico Web service possa essere usato quale parte di uno più ampio nei processi di business in corso. Viene definito come un’estensione di Wsdl 1.1. Wsci è stato sottoposto al W3C, anche con il supporto di Iona, Oracle e SeeBeyond. Il W3C ha dichiarato che Wsci si collega ai Web service e alla Semantic Web Activity e lo ha portato all’attenzione del competente working group. Il Wsci è un’ulteriore riprova che per diventare standard è necessario essere sottoposti al W3C e non fare solo affidamento sul prestigio dei promotori. È interessante poi notare come Bea sia l’unica a supportare sia Bpel4ws, sia Wsci.