Web Service SOAP, WSDL e LOA38

Dopo aver pubblicato il precedente articolo sui servizi REST (consultabile qui: Web Service REST e LOA38 e prerequisito per capire questo), è doveroso dare una spiegazione ed un’infarinatura anche sulla possibilità di effettuare delle richieste SOAP.

Cosa è SOAP e principali differenze da REST.

SOAP (Simple Object Access Protocol) è un vero e proprio protocollo, a differenza dei REST  che sono solamente un’architettura, il quale adotta delle regole ben precise con uno schema molto rigido, basato sull’XML.
Lo scambio di dati avviene tramite degli “endpoint” che funzionano in relazione ad un “contratto” sulla modalità di scambio dati e di comunicazione. Tutta la gestione delle risposte avviene (così come anche lo scambio di dati)  tramite XML. Questo potocollo è considerato più sicuro rispetto ai REST perchè implementa nativamente dei moduli di sicurezza ed indirizzamento (come ad esempio WS-Security e WS-Addressing).
Questo fa sì che esso non si appoggi completamente al protocollo HTTP, ma lo utilizzi solamente per lo scambio dei messaggi.

Inoltre i Web Service basati su SOAP prevedono lo standard WSDL, Web Service Description Language, utilizzato per definire l’interfaccia di un servizio. Questa è un’ulteriore evidenza del tentativo di adattare al Web l’approccio di interoperabilità basato su chiamate remote. Difatti il WSDL non è altro che un IDL (Interface Description Language) per un componente software.

NB: È opportuno evidenziare che SOAP definisce soltanto la struttura dei messaggi non il loro contenuto.I tag per descrivere una richiesta di elaborazione o un risultato vengono definiti in uno schema specifico ed utilizzati all’interno della struttura SOAP sfruttando il meccanismo dei namespace.

WSDL (Web Service Description Language)

Come già accennato precedentemente, per effettuare una chiamata ad un server SOAP è necessario conoscere esattamente in anticipo tutto quello che si andrà ad utilizzare.
Può venire utile quindi avere a disposizione un agglomeratore di informazioni riguardanti il WebService e le funzioni richiamabili, o detto in maniera tecnica, un’interfaccia.

Questo compito viene affidato al WSDL che come già spiegato precedentemente, incorpora in un documento XML le funzioni ed i parametri messi a disposizione dal WebService facendo così da interfaccia fra il client e il servizio che si vuol interrogare. Più precisamente in esso sono contenuti principalmente informazioni riguardanti:

• le operazioni disponibili del servizio;
• il protocollo di comunicazione da utilizzare per fruire del servizio;
• gli endpoint di ogni funzione;
• il formato dei messaggi accettati come input;
• il formato dei messaggi restituiti come output;
• i messaggi di output.

Avendo a disposizione queste indicazioni, è ipotizzabile pensare che un software client potrà “leggere” il documento WSDL relativo al WebService di cui si intende fruire e successivamente comporre messaggi SOAP per avanzare richieste e/o semplici interrogazioni.

Entrando un pò più nello specifico lo scheletro di un file WSDL prevede la dichiarazione di questi campi:

SOAP con LOA38 e K11

Come si è già potuto provare nei servizi REST, anche per i servizi SOAP il procedimento di richiesta è il medesimo già visto; vengono utilizzati anche in questo caso i servizi offerti dal costruttore LOA38 e testati attraverso la £K11.
Vedremo ora quindi una spiegazione rapida (per il procedimento dettagliato si rimanda quindi all’articolo Web Service REST e LOA38) per poter effettuare una chiamata SOAP.

Il primo passo da effettuare è quello di o ricercare un Server SOAP a cui poter mandare richieste, oppure come spiegato nel paragarafo precedente munirsi di un file WSDL e utilizzare SOAPUI come Server Mock.

Successivamente sarà necessario creare uno script SCP_SET/LOA38_xx,  (sostituendo xx con qualcosa di sensato!) dove inseriremo le informazioni riguardanti l’end point dove collegarsi. Nel caso di un server il problema non si pone, basterà infatti inserire il nome (o indirizzo IP) del server, mentre nel caso si usasse un servizio mokkato, sarà necessario assicurarsi di non aver problemi di networking fra il provider e il pc su cui “gira” il mockService. Lo script potebbe essere simile al seguente:

Sucessivamente, dopo aver raggiunto la scheda del LOA38 (con SCH LOA38), e dopo aver scelto dal tree di sinistra lo script appena creato ed aver avviato il test con la K11, sarà necessario inserire le variabili ed il loro valore. Si ricorda che, dato che il payload della K11 non supporta più di 255 caratteri, sarà necessario inserire il nostro XML della richiesta SOAP in un file .xml e posizionarlo in una cartella posizionata da qualche parte sull’IFS dell’AS. Il path (assoluto) più il nome del file andranno a  comporre la stringa da dover inserire nel campo “Percorso IFS” che indicheranno alla K11 di dove andare a prendere il payload di richiesta.

Fatto questo basterà compilare le variabili ed il loro valore (nel caso non avessimo inserito il default value) nei campi sottostanti in base a come erano state settate all’interno del file SCP_SET.

Ora basterà lanciare il tutto con il pulsante di conferma ed attendere la risposta che viene riportata qui sotto come esempio potrebbe essere simile a questa:

SOAPUI  e WebService Mockup

SOAPUI (https://www.soapui.org/), che altro non è  uno dei più famosi tool di test per WebService.

Come possiamo però testare delle chiamate che andremo ad effettuare non avendo a disposizione un server che espone servizi? Per fare ciò viene in nostro soccorso

Attenzione!  In questo caso lo useremo per creare un finto webservice a partire da un WSLD, solo ai fini di questo articolo. Nel mondo reale questa cosa serve solo se non ci viene dato un webservice di test mentre sviluppiamo!

L’unico prerequisito sarà quindi procurarci un file WSDL per poter creare una request e di simulare una risposta da parte del programma di test.

Per prima cosa allora avviamo il programma e tramite

 File -> New SOAP Project 

(oppure tramite la pressione dei tasti rapidi  ) creiamo un nuovo progetto.
Si presenterà ora una schermata che domanderà di inserire il nome al progetto e il path del file WSDL. Dopo aver cliccato sul pulsante di conferma ci troveremo dinnanzi alla richiesta XML

Per creare ora un servizio “mokkato” (ovvero finto) che risponda a questa request (anche in modo cablato), clicchiamo con il tasto destro del mouse sul progetto “Test_SOAP_WS” nel menu laterale di sinistra e dalla lista delle operazioni possibili scegliamo “Generate SOAP Mock Service”.

Dopo aver dato un nome al servizio si presenterà nel menu laterale l’istanza del MockupService mentre a destra ne comparirà la finestra vera e propria corrispondente, che darà la possibilità all’utente di decidere le configurazioni di collegamento (tramite l’ingranaggio posto superiormente) o di avviare direttamente il servizio (tramite il tasto start) che andrà ad emulare un Soap-Server in attesa sulla porta impostata precedentemente.

Dopo aver avviato il servizio, è possibile (nel caso non si abbiano delle Response già configurate)  far gestire al SOAPUI le Response in base alle Request che vengono effettuate. Si tratta di Response che ovviamente non dispongono di “intelligenza” e tantomeno di attributi e/o valori reali, ma è possibile così testare che data una richiesta, venga generata una risposta.

Per fare ciò è necessario recarsi sul menu di sinistra e cliccare con il tasto destro del mouse sulla voce di una “request” e dalle operazioni possibili scegliere “Add to MockService”. Dopo aver scelto a quale MockService agganciare questa response e aver dato conferma, sarà ora possibile effettuare una chiamata.

Volendo però effettuare tutto in locale, bisognerà inserire nella barra di navigazione o la parola “localhost“ o ancor meglio l’hostname del pc in uso, che nel mio caso è “XPSkioda” e la porta su cui sta girando il MockService, che nell’esempio è la 8080. A questo punto sarà possibile cliccando sul triangolino verde (Submit) effettuare la chiamata e visualizzare la risposta. Da notare inoltre che avremo traccia che il tutto sarà andato a buon fine leggendo il log di avvenuta risposta sul MockService in cui verrà assegnato un timestamp a transazione eseguita.

E’ inoltre possibile modificare a piacimento la risposta in modo tale da personalizzare il più possibile il tipo di risposta.