SOAP nasce da specifiche che Microsoft pubblicò qualche anno fa. In seguito inziò la collaborazione con IBM che riteneva che il protocollo fosse troppo semplice per utilizzi reali e che portò alla stesura della versione 1.1. In seguito queste specifiche sono state sottoposte (con una nota dell’8 maggio del 2000) al consorzio W3C. Attualmente dunque SOAP non è una raccomandazione del W3C ma una proposta per la quale lo stesso consorzio formerà un gruppo di esperti che potranno confermare tutte o in parte le specifiche o anche cambiarle completamente.

Dunque, sebbene la versione 1.1 delle specifiche sia stabile da un annetto, è probabile che il protocollo evolva ulteriormente.

Abbiamo accennato come anche IBM (ma anche DevelopMentor, un grosso sostenitore dei WS) sia entrato nel gioco di SOAP. Con Microsoft condivide la visione dei Web Services, ossia di servizi a cui è possibile accedere tramite messaggi SOAP attraverso Internet. L’idea di web service si basa, oltre che su SOAP, anche su tecnologie complementari quali WSDL (Web services description language, http:/www.w3c.org/TR/wsdl) e su UDDI (Universal Description Discovery and Integration, http://www.uddi.org).

SOAP è dunque una parte, magari minimale, ma sicuramente importante, della visione Web Services di IBM e Microsoft. E SUN come si raffronta con i Web Services?
 
 
 

Gli sviluppi
Una recente feature sul sito http://java.sun.com relativa alla JavaOne di S.Francisco era intitolata “READY TO ROCK The 2001 JavaOneSM Conference Features the Technology Behind Web Services” (http://java.sun.com/features/2001/04/track1.html?frontpage-banner), con una immagine riportante la scritta “Web, services, and beyond”.

Le virgole in questo caso sono importanti, perché, anche leggendo l’articolo si desume che SUN non è ancora pronta a seguire l’esempio del grande fratello IBM nella corsa dei Web Services, forse dimostrando meno visione di IBM o forse mostrando di concedersi meno alla promozione dei Web Services basati su SOAP (forse per promuovere maggiormente la sua iniziativa, SUN ONE, anche’essa basata su Web Services, ma con caratteristiche e tecnologie a volte differenti).

Una sessione della JavaOne sarà intitolata “JavaServer Pages (JSP) Technology and XML” e si parlerà, tra le altre cose, di come leggere informazioni da servizi SOAP da una pagina JSP ed elaborarla con tecnologie quali XSLT ed XPath per fornire un contenuto XML. Il relatore di questa sessione è interno a SUN ed è chiaro qui come si cerchi di porre “davanti” a SOAP una tecnologia Java come JSP.

Questo approccio può essere visto da due punti di vista: dal punto di vista marketing e dal punto di vista tecnico. Nel primo caso si evince la paura di SUN di perdere terreno nel “controllo” dell’evoluzione dei protocolli del web e di dover quindi ricadere in una situazione in cui Microsoft controlla le API, trend che si andava invertendo con l’affermazione della piattaforma Java.
Con l’approccio proposto, la tecnologia client per servizi SOAP in ambito “applicazioni Web” è JSP, quindi Java, e SUN correttamente propone questo tipo di soluzione.
Ma anche dal punto di vista tecnico la soluzione è buona. Un messaggio SOAP di per se non è utilizzabile direttamente dall’utente finale e dunque uno strato di logica di presentazione basato su JSP, JavaBeans e trasformazioni XSLT ha molto senso anche perché queste tecnologie sono ad oggi molto mature e si fondono molto bene con SOAP.

Non sono previste però sessioni particolari su SOAP o sulla visione di Web Services. Forse perché in questo momento SUN spinge di più la visione “wireless” del web (è tra l’altro l’argomento della Java Conference 2001 italiana).

Nonostante questo esiste una proposta al Java Community Process “JSR-000109 Implementing Enterprise Web Services”, proposta da … IBM che sostanzialmente intende implementare nella piattaforma Java2 Enterprise Edition le tecnolgie SOAP, WSDL e UDDI. Questa si basa su un’altra proposta la “JSR-000101 Java APIs for XML based RPC” dove si intende sviluppare API sostanzialmente per supportare un RPC basato su XML (che protrebbe essere anche SOAP). Un modo questo per standardizzare l’accesso a questo protocollo, in modo similare a quanto fatto con JAXP dove si propone un modo standard per accedere ad un parser XML.

Quello che traspare, dunque, è che, se da un lato SUN non promuove a livello di marketing la tecnologia SOAP (per fare questo ci sono IBM e Microsoft, con la solita bravura), ma che al livello tecnico si stia già lavorando per integrare  SOAP ed i Web Services nella piattaforma Java.

In futuro dunque è presumibile che il protocollo di comunicazione (SOAP o XML-RPC o qualche altro protocollo od evoluzione) sia invisibile allo sviluppatore di applicazioni, come lo è attualmente IIOP o JRMP. Magari verrà implementato (o esteso) RMI su SOAP.

Una piccola nota su XML-RPC (http://www.xml-rpc.org): questo protocollo è un modo più semplice per effettuare RPC su XML ma forse meno famoso in quanto probabilmente il rivale SOAP ha ricevuto più attenzioni, sicuramente in quanto proposto da Microsoft ed IBM. Con API standard per l’accesso all’RPC, XML-RPC avrà la possibilità di tornare alla ribalta come una alternativa per il protocollo di messaggio.
 
 
 

La vera natura di SOAP
In attesa che SOAP divenga trasparente allo sviluppatore, e per conoscerlo meglio, cerchiamo di analizzare cosa è effettivamente SOAP, o meglio, che cosa definiscono esattamente le specifiche attuali (versione 1.1).

È d’obbligo un rimando alle specifiche di SOAP (http://www.w3c.org/TR/SOAP) per una lettura esaustiva ma speriamo qui di dare informazioni iniziali sufficienti per inquadrare la tecnologia.

Le specifiche SOAP sono idealmente composte di quattro elementi:
 

1. Modello di scambio di messaggi SOAP (Envelope, Headers, Body e Fault);
2. Encoding SOAP;
3. SOAP su HTTP;
4. SOAP per RPC.

La vera natura di SOAP è relativa al punto 1, questa è l’unica parte delle specifiche che è obbligatoria, per quanto riguarda l’encoding e l’utilizzo del protocollo HTTP, questi sono solo proposte ed infatti è possibile codificare in modi alternativi (XMI o XML letterale) ed utilizzare altri trasporti, quali SMTP.
Le specifiche per l’RPC sono una applicazione particolare del protocollo SOAP che comunque è presente nelle specifiche in quanto faceva parte degli obiettivi del protocollo e che può essere sostituita da altri RPC basati su SOAP.
 
 
 

Modello di scambio di messaggi
Il modello di scambio dei messaggi è fondamentalmente di tipo fire&forget, ossia a semplice invio da un punto ad un altro ma le specifiche indicano che questo può essere combinato in pattern come ad esempio un request/response, implementando dunque una sorta di RPC.
In questa fase entrano in gioco la Envelope, le Header ed il Body che dovranno essere controllati dal punto ricevente (il server SOAP o “elaboratore SOAP) ed identificati.
 
 
 

Encoding SOAP
L’ encoding di SOAP è strettamente legato alle specifiche XML Schema. L’encoding consente di specificare dati semplici e complessi, come quelli strutturati e gli array. Un encoding più semplice è l’XML letterale dove le informazioni sono codificate in XML puro e semplice.
 
 
 

SOAP su HTTP
La veicolazione di messaggi SOAP su HTTP è molto semplice in quanto si fa uso principalmente delle operazioni di POST e si riutilizza la semantica di HTTP per i codici di stato (quali ad esempio 200, 500). In caso di errore un server SOAP/HTTP ritorna un codice 500.
 
 
 

SOAP per RPC
Remote Procedure Call consente di invocare un metodo su un oggetto remoto (in modo similare ad RMI), le specifiche SOAP richiedono che venga identificato l’oggetto da chiamare (tramite il suo URI), il nome del metodo (eventualmente anche la firma) ed i parametri di chiamata. Opzionalmente è possibile passare informazioni di header.
Le specifiche consigliano di utilizzare l’encoding SOAP per codificare queste informazioni, ma il suo uso non è obbligatorio. Nell’area RPC sembra che le specifiche lascino una certa variabilità all’implementazione.
 
 
 

Conclusioni
La parte più corposa delle specifiche SOAP sono relative all’encoding SOAP, infatti il modello di scambio messaggi, il binding con HTTP e le specifiche per RPC sono abbastanza semplici.

Questa è sicuramente una cosa positiva, in quanto le implementazioni costano meno, ma hanno lo svantaggio di non fornire supporto a funzioni utili (quali la garbage collection distribuita o la sicurezza) che possono limitare il raggio d’azione di questa tecnologia.
 
 
 

Riferimenti
[1] Specifiche WSDL - http:/www.w3c.org/TR/wsdl
[2] Specifiche UDDI - http://www.uddi.org
[3] READY TO ROCK The 2001 JavaOneSM Conference Features the Technology Behind Web Services” - http://java.sun.com/features/2001/04/track1.html
[4] Specifiche SOAP – http://www.w3c.org/TR/SOAP
[5] Andrea Giovannini - SOAP e Java Integrazione di applicazioni con Java e il nuovo protocollo SOAP - http://www.mokabyte.it/2001/01/soap.htm