Integrare chiamate a Web Service SOAP all’interno di applicazioni web può portare una serie di complicazioni se non si utilizza il giusto approccio al problema. In questo articolo descriverò una serie di accorgimenti e di best practice per risolvere al meglio il problema.
Lo scopo del post non è illustrare cosa sia SOAP ne mostrare esempi base di utilizzo di un servizio in particolare ma di descrivere quali sono gli strumenti e l’approccio migliore all’integrazione di un WS all’interno di un’applicazione web. Le considerazioni fatte in questo articolo sono best practice generiche e non legate all’utilizzo di framework particolari.
Tutte le considerazioni fatte si basano sul fatto che disponiate di un server php5 con estensione SOAP abilitata. In mancaza dell’estenzione SOAP avete la possibilità di usare alcune librerie alternative più o meno funzionali che vi permetteranno comunque di accedere a Web Service SOAP, anche se non in maniera efficiente dell’implementazione nativa di PHP. Credo che le più comunemente usate siano:
- NuSoap
- PEAR::SOAP (ultima release del 2008 e ancora marcata come beta !!)
Entrambe le librerie non sono propriamente nuovissime, ma se non avete di meglio che ci potete fare ?
Best Practice
Alcune cose sono fondamentali quandi si integra un servizio SOAP o, in generale, un servizio esterno in un’applicazione web:
- Una corretta mappatura delle classi coinvolte nello scambio di dati
- Un buon livello di astrazione dal Web Service
Implementare una corretta mappatura delle classi
Semplificando al massimo tutto quello che ci sta dietro, SOAP dovrebbe permettere di passare “oggetti” attraverso chiamate http. Il lavoro che dovrebbe fare il client è quello di interpretare i messaggi xml in arrivo dal server e fornire alla nostra applicazione la risposta sotto forma di oggetti. A definire quali sono le classi coinvolte in questo dialogo ci pensa solitamente il file WSDL (web service description language).
E’ molto utile replicare, all’interno dell’applicazione, la struttura di classi prevista dal servizio. La presenza di un WSDL (non obbligatorio ma comunissimo nei servizi SOAP) e l’utilizzo di alcune librerie come wsdl2php permette di generare queste classi autoamaticamente.
wsdl2php produrrà tutto il codice necessario ad accedere al servizio. La libreria è forse un pò grezza (non permette ad esempio di mappare in qualche modo le classi per evitare conflitti con altre esistenti nella nostra app) ma fa il suo lavoro in maniera onesta.
Tra le altre cose il codice generato diventa una forma di documentazione del servizio molto più pratica e comoda del WSDL stesso.
Ottenere il giusto livello di astrazione
A questo punto abbiamo tutto il necessario per integrare le chiamate SOAP all’interno della nostra applicazione:
- una serie di classi che descrivono i dati necessari alla comunicazione con il servizio
- una classe client sottoclasse di SoapClient che descrive il servizio stesso (con un metodo per ogni api)
Nonostante l’utilizzo del client generato da wsdl2php all’interno dell’applicazione sia possibile (in fondo essendo una sottoclasse di SoapClient è personalizzabile secondo necessità) l’approccio più corretto è probabilmente quello di prevedere un oggetto wrapper che si occupi di:
- dialogare con l’applicazione
- dialogare con il client
in pratica che lavori tra applicazione e client in modo che le due componenti non entrino mai in contatto diretto. Questa separazione porta ad alcuni vantaggi tra cui:
- la testabilità del codice
- l’ indipendenza dell’applicazione dal Web Service in uso
Nel prossimo articolo posterò alcuni esempi pratici di integrazione.
Leave Your Response