Le origini

In questo articolo vorrei per un momento lasciare da parte il codice ed affrontare invece la storia di SOAP e le sue possibilità di evoluzione cercando di capire come questo protocollo entri a far parte del mondo Java.

SOAP nasce da specifiche che Microsoft pubblicò qualche anno fa. In seguito iniziò 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 Web Services, 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 e UDDI.

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 java.sun.com relativa alla JavaOne di San Francisco era intitolata READY TO ROCK The 2001 JavaOneSM Conference Features the Technology Behind Web Services, 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, anch’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 sé 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, che è 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 Java 2 Enterprise Edition le tecnologie 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 potrebbe 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, dall’altro 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: 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 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:

• Modello di scambio di messaggi SOAP, con Envelope, Headers, Body e Fault.
• Encoding SOAP.
• SOAP su HTTP.
• SOAP per RPC.

La vera natura di SOAP è relativa al primo punto, 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, per esempio 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-and-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 e 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`