Introduzione a SOAP

Obiettivo di SOAP (Simple Object Access Protocol) è fornire agli sviluppatori una soluzione standard per creare applicazioni distribuite che possano utilizzare i web services, servizi remoti generalizzati in grado di svolgere i compiti più disparati.
La standardizzazione è d’obbligo in quanto le soluzioni proprietarie che permettono la distribuzione delle componenti di business logic applicativa, in particolar modo CORBA e DCOM, soffrono di una serie di difetti che ne limitano l’utilizzo ad ampio spettro.
Il primo difetto riguarda senza dubbio le caratteristiche di comunicazione che impongono alle soluzioni proprietarie di utilizzare porte tcp non standard per scambiarsi messaggi informativi, questo ha il triste effetto collaterale che nel momento in cui si cerca di uscire da una web-farm per utilizzare un servizio posizionato dall’altra parte di un firewall, difficilmente si troveranno aperte le porte tcp che CORBA o DCOM si aspettano di trovare.
SOAP risolve questo problema proponendo come standard di comunicazione l’utilizzo del protocollo HTTP, senza tuttavia precludere l’utilizzo di altri protocolli, a patto che possano trasportare testo.
Il secondo difetto riguarda il formato dei messaggi che le componenti di distribuzione dei protocolli sopra citati si scambiano per compiere il compito per cui sono stati sviluppati.
Tendenzialmente infatti, si tratta di dati in formato binario non codificato e questa è un’altra di quelle cose che i firewall non gradiscono e che spesso vietano.
SOAP risolve anche questo problema permettendo la serializzazione del messaggio attraverso l’uso di XML, uno standard anch’esso in piena evoluzione. XML infatti, essendo testo puro, non ha difficoltà di transito attraverso i firewall ed è compreso da qualsiasi sistema in grado di leggere testo. Come si può capire la distribuzione di una simile soluzione può essere davvero universale.
L’unione, quindi, di HTTP come protocollo di trasporto, di XML come strumento per il marshalling del messaggio da trasportare e di tutte le regole, anche piuttosto complesse, per garantire il passaggio di qualsiasi tipologia di messaggio tra client e servizio remoto, fornisce la specifica SOAP.
Una delle caratteristiche principali di SOAP, pertanto, è la possibilità di far comunicare tra loro sistemi eterogenei dal punto di vista dell’hardware, del sistema operativo e del linguaggio utilizzato per lo sviluppo. Essendo chiare le specifiche di comunicazione, infatti, è ragionevole pensare che un client ed un servizio remoto possano comunicare indipendentemente dalle loro caratteristiche hardware, software e legate al linguaggio utilizzato per produrli.
La perfezione però, purtroppo, è rara ed infatti SOAP paga le sue eccellenti doti di flessibilità con un abbassamento delle performance.
Questo tuttavia è legato per lo più alle scarse prestazioni degli strumenti attuali di parsificazione di codice XML. È ragionevole pensare quindi che questo difetto, almeno in parte, possa essere corretto con l’introduzione di componenti di parsificazione più efficienti.

SOAP pertanto è un protocollo applicativo, una specifica che descrive nei minimi dettagli come deve essere serializzato il payload, cioè il messaggio contenente la vera informazione che deve essere scambiata tra client e server.
Poiché si tratta fondamentalmente di chiamate di tipo RPC, il reale contenuto del payload non sarà altro che una chiamata ad una funzione elaborativa remota, cioè il servizio che stiamo cercando di utilizzare, unita ai suoi parametri.
D’altro canto, nel caso del messaggio di risposta, il contenuto del payload sarà il risultato dell’elaborazione remota oppure, al limite, una condizione di errore.

Una qualsiasi applicazione che debba essere sviluppata utilizzando SOAP come specifica per la distribuzione dei servizi, pertanto, dovrà implementarne internamente tutte le regole, oppure appoggiarsi ad API fornite da terzi che permettano di disaccoppiare la logica applicativa dalla logica comunicativa.
La prima soluzione è senza dubbio interessante ma ha l’effetto collaterale di essere molto costosa in quanto la specifica, come vedremo anche in articoli successivi, è in alcuni punti davvero complessa, inoltre l’evoluzione dello standard comporterebbe una manutenzione obbligatoria all’applicazione.
La seconda soluzione è lo standard di riferimento per qualsiasi progetto di sviluppo professionale e consiste in sviluppare in proprio oppure acquisire dei componenti che forniscano lo strato comunicativo esportando un’interfaccia il più possibile trasparente per l’utilizzatore, ovvero per lo sviluppatore che scrive il codice dell’applicazione.

Questa applicazione, pertanto, dovrà avere un’architettura di questo tipo:

Come si vede in questo schema la parte client dell’applicazione comunica con la parte server, cioè il servizio remoto che intende utilizzare, attraverso un oggetto intermedio che si occupa di tutti i dettagli legati alla comunicazione, in questo caso viene utilizzato HTTP, ed alla serializzazione e deserializzazione dei messaggi che devono andare dal client al server e viceversa.
Oggetti di questo tipo ne esistono molti e sono, ad esempio, Apache SOAP di XML Group, e Microsoft SOAP Toolkit.
Il primo è un’implementazione Java che fornisce un package, da usare lato client e lato server, da utilizzare nelle applicazioni scritte utilizzando Java e JSP.
Il secondo è un’implementazione che fornisce alcuni componenti Win32 da utilizzare come riferimenti per scrivere applicazioni utilizzando qualsiasi linguaggio in grado di supportare ActiveX DLL.
Come vedremo le caratteristiche di entrambe queste implementazioni sono molto interessanti e, per certi versi, complementari, nel senso che il pieno supporto della specifica SOAP è ancora lontano e la dimostrazione sta nel fatto che le applicazioni scritte utilizzando queste due implementazioni tra loro non si parlano.
In ogni caso si è sulla strada giusta per ottenere la tanto agognata “specifica trasversale” indipendente cioè dalle ragioni di mercato che spesso trasformano delle belle idee in carta da recupero e delle scatole vuote in “tecnologia innovativa”.
Questo con SOAP non può accadere dato l’interesse che tutta la comunità informatica mondiale sta riponendo nei confronti dei web services e dato che le implementazioni per tutti i linguaggi e per tutte le piattaforme vengono rilasciate a cadenze molto ravvicinate.

Dal prossimo articolo analizzeremo SOAP nel dettaglio dal punto di vista architetturale e anche da quello pratico costruendo insieme alcuni web services ed alcuni client.