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
Figura 1: Web Services
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.
Figura 2 - Invocazione di un CORBA Servant
Nel caso CORBA sulla rete avviene uno scambio di pacchetti
di protocollo IIOP in formato binario.
Figura 3 - Comunicazione CORBA: pacchetti
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.
Figura 4 - Comunicazione client e WS
Sulla rete avviene uno scambio di pacchetti XML (su
HTTP in questo esempio).
Figura 5 - Comunicazione client e WS
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 che segue 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
Figura 6 - Confronto Ws & CORBA
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 7 - Specifiche di base
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.
Figura 8 - Specifiche di prima generazione
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.
Figura 9: Binding & Encoding
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.
Bibliografia
[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/
|