I Web Services si basano su un insieme di specifiche evolutesi in momenti diversi: analizziamo le specifiche di base e di prima generazione.

I Web Services si basano su un insieme di specifiche evolutesi in momenti diversi.
Ci occuperemo di descrivere lo stato di avanzamento e il consenso di mercato di queste specifiche che possono essere categorizzate come segue: 1. specifiche di base: definiscono le tecnologie abilitanti ai Web Services, 2. specifiche di prima generazione: definiscono gli standard per la comunicazione di base. 3. specifiche di seconda generazione: definiscono gli standard per aspetti enterprise del servizio (sicurezza, controllo transazionale).
In questo articolo analizzeremo le specifiche di base e di prima generazione. Nell‘insieme le specifiche si completano a vicenda creando un framework di specifiche che può essere implementato in maniera incrementale e modulare.

Web Services: cosa sono

Un Web Service è un servizio di business riutilizzabile che può essere richiamato attraverso tecnologie internet e che dialoga in XML.
La rappresentazione dei dati nei Web Services avviene mediante il linguaggio XML e per questo sono definiti “language-netural”.
Come protocollo di comunicazione i WS non utilizzano protocolli proprietari bensì i protocolli standard Internet (es: HTTP) e per questo sono definiti “platform-netural”.
Gli attori coinvolti in un Web Service sono:

• Service Provider

• Service Registry

• Service Client

L‘analogia con la classica programmazione distribuita è quindi forte, basti pensare a CORBA e alle operazioni che un client deve effettuare per potere comunicare con un CORBA Servant.
Il client deve “cercare” il servizio (il Corba Servant) pubblicato nel Naming Sever per poi utilizzarlo.

Nel caso CORBA sulla rete avviene uno scambio di pacchetti di protocollo IIOP in formato binario.

Per quanto riguarda l‘invocazione di un Web Service bisogna effettuare operazione analoghe.
Il modello prevede che il client “cerchi” il servizio (il Web Service) pubblicato nell‘UDDI Server per poi utilizzarlo.

Sulla rete avviene uno scambio di pacchetti XML (su HTTP in questo esempio).

Abbiamo visto che i Web Services implementano un sistema di elaborazione distribuita in cui si distinguono gli ingredienti classici:

• definizione di un servizio mediante un linguaggio di interfaccia

• pubblicazione di un servizio su un registri pubblico

• protocollo di comunicazione utilizzato per l‘invocazione dei servizi

Sul piano architetturale dunque non sono nulla di nuovo e possono essere paragonati ad altri sistemi di elaborazioni distribuita. Nella tabella di figura 6 sono messi a confronto i sistemi di elaborazione distribuita che oggi vanno per la maggiore.

Questa tabella può essere utile per effettuare alcune riflessioni. Dovrebbe risultare evidente che non c‘è un sistema migliore di altri, ma che a seconda dei requisiti dell‘applicazione che si deve sviluppare possiamo trovare che i sistemi mostrati sono più o meno adatti. Ad esempio se la nostra applicazione è sviluppata tutta su piattaforma Microsoft probabilmente .NET Remoting è la scelta migliore.
Un‘altra cosa che emerge dalla tabella è che CORBA e i Web Services hanno in comune una grande attenzione alla standardizzazione e all‘interoperabilità . Si può affermare che CORBA come sistema di elaborazione distribuita non ha attenuto grandi risultati sul fronte interoperabilità , infatti anche nelle ultime versioni molto spesso ORB di vendor differenti faticano a comunicare. Nell‘immagine che segue si riepiloga un confronto fra la tecnologia Web Services e CORBA da cui si può dedurre che i due sistemi sono tecnologicamente equivalenti

I riflettori ora sono puntati sui Web Services, anche se è ancora presto per potere dire se questa volta si raggiungerà  l‘obiettivo. Si può affermare che però questa volta alcuni vendor più importanti (in particolare ci si riferisce a Micorsoft e IBM che in passato avevano abbastanza “snobbato” CORBA) sembrano allineati e decisi nell‘impegno di supportare i Web Services.
poiché come già  detto i Web Services sono basati su specifiche per capire a che punto siamo sia nella maturazione di queste specifiche sia nell‘accettazione da parte dei vendor conviene affrontarle un po‘ più in dettaglio.

Specifiche di base

Queste specifiche definiscono il mondo XML, e dunque sono alla base di qualunque tecnologia basata su XML, Web Services inclusi (figura 8).

In generale queste specifiche sono ben consolidate perché più vecchie di un paio d‘anni rispetto a quelle sui Web Services e sono accettate dai Vendor. Il supporto dei vendor su XML, XSD e XSL è pressochà© completo con un ampia varietà  di scelta anche nel mondo open source [WS-APACHE]. Per quanto riguarda Xpath e XQuery che sono più recenti non sempre il supporto è completo. Per avere un esempio di funzionamento di queste tecnologie e anche di altre legate a XML si consiglia di scaricare la versione di prova di XMLSpy [XMLSPY].

Specifiche di prima generazione

Le specifiche di prima generazione definiscono il sistema di elaborazione distribuita dei Web Services. Esse prendono in considerazione i meccanismi base della comunicazione, quindi come già  detto la definizione, la pubblicazione, e il protocollo di comunicazione.
Queste specifiche (sebbene possano ancora evolvere) sono generalmente accettate dai maggiori player di mercato.

Abbiamo visto nell‘introduzione come queste tre tecnologie cooperino per andare a formare la piattaforma di elaborazione distribuita dei web services.

Conviene ora approfondire un aspetto delle specifiche dei Web Services: in alcuni casi tendono ad essere piuttosto lasche e a lasciare spazio per gli usi più disparati.
Se da un lato questo è senz‘altro un fatto positivo in quanto aumenta il numero degli use case in cui ha senso applicare i Web Services, dall‘altro può generare confusione negli utenti e anche qualche errore nelle implementazioni delle librerie e dei prodotti.
Prendiamo ad esempio il formato in cui i dati viaggiano nel SOAP envelope (vedere [SOAP]).
Esso è determinato sostanzialmente da due parametri:

• Il Binding style che può valere rpc (Remto Procedure Call) o doc (document)

• L‘Encondig style che può valere enc (encoded) o lit (literal)

Il binding style è il modo in cui sono descritte le operazioni e i parametri durante una chiamata ad un Web Service. Il binding style rpc è adatto a descrivere Web Services come se fossero procedure remote (da cui rpc). Il binding style document invece è adatto a descrivere i Web Services come “consumatori” di documenti. Nella pratica le due modalità  si distinguono per il fatto che nel caso rpc ogni parametro è wrappato da tag che lo descrivono. Nel caso document invece viene passato il documento senza modifiche.
L‘encoding style specifica come sono scritti i dati che fanno parte delle richiesta e della risposta del Web Service.
Lo stile encoded prescrive che i dati devono essere descritti come tipi XSD con alcune eccezioni come specificato nel paragrafo 5 della specifica SOAP 1.1.
Lo stile literal prescrive che i dati devono essere descritti mediante un documento XSD.
In pratica lo stile encoded è stato previsto nel caso in cui si abbia la necessità  di serializzare uno o più grafi di oggetti da un lato e deserializzarli dall‘altro magari in un altro linguaggio. Quindi lo stile encoded fissa a priori il modo in cui i dati primitivi e gli array e i riferimenti devono essere resi in XML, per i tipi complessi, che saranno specifici dell‘applicazione, si ricorre a XSD.
Lo stile literal invece non fa alcuna supposizione sul modo in cui i dati sono serializzati e deserializzati, anzi potrebbe darsi il caso in cui i due endpoint processino un documento XML senza serializzarlo e deserializzarlo in oggetti. L‘unica cosa che si richiede è che il documento XML sia descritto mediante XSD.
Se vogliamo serializzare e deserializzare i dati e vogliamo usare l‘encodig style literal le due applicazioni che comunicano dovranno mettersi d‘accordo sulla semantica di questa operazione.
Dunque abbiamo quattro possibili combinazioni. Proviamo a riassumerle:

• rpc/enc: Web Service visto come procedura remota con serializzazione e deserializzazione standard (di fatto è una formalizzazione XML di una chiamata ad un procedura remota).

• rpc/lit: Web Service visto come procedura remota con serializzazione proprietaria.

• doc/enc: Web Service visto come servizio document oriented, ma in cui la serializzazione e deserializzazione dei parametri segue l‘encoding standard. Di fatto non usato.

• doc/lit: Web Service visto come servizio document oriented in cui la serializzazione e deserializzazione dei dati avviene in maniera proprietaria.

Storicamente Microsoft ha implementato i propri prodotti prediligendo lo combinazione doc/lit, mentre SUN (e di conseguenze lo standard di riferimento Java) ha prediletto la combinazione rpc/enc (nelle prime versioni il document/literal non era supportato).
Questo chiaramente ha generato una interoperabilità  molto limitata dei prodotti infatti ad esempio per i Web Services .NET prevede di utilizzare il “document” style con parametri literals, il default per Axis è costituito dall‘accoppiata RPC/encoded.

Di default ogni implementazione di WS utilizza la propria convenzione di modalità  d‘invocazione e di codifica.
Per permettere l‘interoperabilità  tra Web Services bisogna “allineare” entrambi i “side” alla stessa modalità  di comunicazione.

WS-I

Come visto le specifiche degli standard di base lasciano aperti alcuni gradi di libertà  ed i player di mercato hanno interpretato in maniera differente queste zone grigie creando in alcuni casi prodotti non interoperabili.
Per venire incontro a questi problemi si è costituito il comitati WS-I (Web Services Interoperability).
Il WS-I basic profile (vedere [WSI-BP]) è composto da un set di specifiche (che devono essere supportate) e relative precisazioni, creato al fine di avere prodotti interoperabili.
In pratica se due vendor affermano di essere WS-I basic profile compliant possiamo essere sicuri che i prodotti saranno interoperabili. Il basic profile contempla gli standard di base (ad eccezione della gestione degli attachment).
In futuro saranno pubblicati altri profili.
Per quanto riguarda la questione rpc/enc vs. doc/lit il comitato WS-I ha decretato l‘uso di doc/lit, dando sostanzialmente fiducia a Microsoft. Quindi quando si diceva che i web services di Microsoft sono meglio di quelli di java forse c‘era un fondo di verità . Ora anche java supporta lo stile doc/lit, anche se le API JAXP-RPC rimangono ahimè fortemente orientate all‘uso rpc/enc.
In queste scelte certamente ci sono forti pressioni politiche da cui risulta evidente che Microsoft è in grado di influenzare gli standard dei Web Services più di SUN.

Conclusioni

In questo articolo abbiamo effettuato un breve confronto tra i Web Services e le tradizionali tecnologie distribuite introducendo le specifiche base e di prima generazione dei Web Services. Da questo primo articolo possiamo trarre alcune iniziali considerazioni.
I Web Services, ad oggi, hanno in parte “vinto” la gara dell‘interoperabilità  perché hanno trascinato o sono stati trascinati dai maggiori player di mercato (vedere [MQ_WSE] ), contrariamente a quanto accadde per CORBA che in fondo si poneva gli stessi obiettivi. E hanno in parte “fallito” perché comunque c‘è bisogno del WS-I per normare l‘interoperabilità .
Nel prossimo articolo ci dedicheremo alle specifiche di seconda generazione.

Riferimenti

[XML]
http://www.w3.org/XML/

[XSD]
http://www.w3.org/XML/Schema

[XSL/XSLT]
http://www.w3.org/Style/XSL/

[XQUERY]
http://www.w3.org/XML/Query

[XPATH]
http://www.w3.org/TR/xpath

[SOAP]
www.w3.org/TR/SOAP

[UDDI]
www.uddi.org

[WSDL]
www.w3c.org/TR/wsdl

[WS-I]
WS-I Specifications
http://www.ws-i.org

[WSI-BP]
Basic Profile Version 1.0
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html

[MQ_WSE]
Magic Quadrant for Web-Services-Enabled
http://mediaproducts.gartner.com/gc/webletter/microsoft4_enterprise/article23/article23.html

[.NET_WSI_BP]
.NET Pattern & Practices How to Apply the Basic Profile
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsvcinter/html/wsi-bp_chapter3.asp

[XMLSPY]
http://www.altova.com/