I Web Services sono componenti software che interagiscono dinamicamente con tutti gli altri usando una tecnologia standard aperta basata su XML, che rende possibile la comunicazione fra sistemi e li rende di fatto unici nel loro modo di lavorare.
I Web Services consentono la connessione fra sistemi per le funzioni di business di ogni giorno (es: ordini, fatture, pagamenti, ecc.). Queste funzioni di business si possono utilizzare come blocchi per costruire qualsiasi cosa; un’applicazione può essere costituita da differenti Web Services assemblati dinamicamente da diverse fonti nel Web.
I Web Services sono componenti riusabili, permettendo una drastica riduzione del costo totale di sviluppo di un’applicazione. Rappresentano, inoltre, delle interfacce standard fra le applicazioni, rendendo obsoleta la loro connessione attraverso rigide soluzioni punto-a-punto.
Tuttavia, come ogni tecnologia che offre una grande flessibilità, i Web Services aggiungono complessità e richiedono un approccio architetturale.
Un Enterprise Service Bus (ESB) è essenzialmente un’applicazione middleware (ne abbiamo parlato approfonditamente in questo articolo), il cui ruolo è quello di garantire l’interoperabilità tra i diversi protocolli di comunicazione. In altre parole, è un’infrastruttura software che opera da strato intermedio e che fornisce servizi di supporto ad architetture SOA complesse. Semplifica l’integrazione e il riutilizzo dei servizi, permettendo di raggiungere livelli di affidabilità, robustezza, sicurezza, gestione e flessibilità di comunicazione tra i servizi.
Un ESB permette di collegare servizi implementati in tecnologie differenti in modo semplice, fungendo da mediatore tra i diversi, e spesso incompatibili, protocolli e prodotti middleware.
MULE ESB
Mule ESB è il tool di sviluppo di MuleSoft che userò negli esempi a seguire. La stessa azienda mette a disposizione anche un editor gratuito, Anypoint Studio, basato su Eclipse che offre due strumenti per creare applicazioni:
- un editor visuale, che permette il drag-and-drop dei principali componenti
- un editor XML
Qualsiasi modifica effettuata in un editor si riflette anche nell’altro.
I passi per la creazione di un’applicazione standard possono essere così riassunti:
FLOWS
Un flusso (flow) è un meccanismo semplice ma molto flessibile che permette l’orchestrazione di servizi utilizzando le capacità dei messaggi che ivi vi circolano.
Un messaggio che entra in un flusso può essere:
- Convalidato
- Arricchito
- Trasformato in un nuovo formato
- Elaborato da una custom-coded business logic
- Collegato ad un database
- Valutato per determinare quale tipo di risposta restituire a chi ha inviato il messaggio originale
Gli elementi che possono comporre un flow sono:
- Connectors – I connettori forniscono un mezzo di comunicazione verso servizi SaaS e applicazioni on-premises
- Scopes – Forniscono elaborazioni avanzate come invocazioni asincrone, polling, flussi
- Components – Consentono di migliorare un flusso collegando funzionalità come il logging, display di output, flussi figli e, tra le altre cose, scrivere logica di business riutilizzabile con il proprio linguaggio di scripting a scelta.
- Transformers – Modificano l’header o il payload del messaggio che viene elaborato nel flusso.
- Filters – Singolarmente o in combinazione, determinano se un messaggio può procedere attraverso un flusso.
- Flow controls – Specificano come i messaggi vengono instradati tra i vari Message Processors all’interno di un flow. Possono anche elaborare i messaggi (per esempio aggregare, dividere o riordinare) prima di inoltrarli ad altri message processor.
- Error Handlings – Specificano varie procedure di gestione delle eccezioni.
QUALCHE ESEMPIO PRATICO
Di seguito vediamo alcuni semplici esempi di utilizzo:
- un semplice “Hello World”,
- l’interrogazione di un database relazionale,
- l’elaborazione di un messaggio utilizzando una classe Java,
- l’utilizzo di un servizio REST esterno.
ESEMPIO 1: HELLO WORLD!
Come primo esempio alteriamo il payload di un messaggio dopo esserci messi in ascolto alla porta 8081, in locale, al path /hello.
Per prima cosa creiamo un elemento di tipo HTTP Listener config nella sezione Global Elements che si metterà in ascolto alla porta 8081 del nostro localhost.
Il flow sarà dunque composto da un Listener (HTTP) che utilizza il connettore appena creato e intercetterà il path /hello. Utilizzando il componente Set Payload impostiamo il messaggio che verrà poi visualizzato nel browser.
Questo è il risultato:
ESEMPIO 2: CONNESSIONE A UN DATABASE
Ora effettuiamo un’interrogazione verso un database relazionale. Creiamo dunque un nuovo elemento globale Database Config, che sarà configurata come segue.
Creiamo un flusso con un Listener (HTTP) in ascolto al path /getallcustomers, di seguito inseriamo un elemento Database > Select che contiene la query e che utilizza l’elemento globale precedentemente creato per la connessione al database. Il browser visualizzerà il risultato della query in formato JSON utilizzando un Transform Message (vedi sotto).
Il risultato che si ottiene è il seguente:
ESEMPIO 3: UTILIZZO DI COMPONENTI JAVA
In questo esempio vogliamo ottenere un numero random, creato da un metodo scritto in una classe Java, con possibilità di passare o meno il range entro il quale si desidera il numero.
Creiamo dunque un flusso che:
- Si metta in ascolto al path /generate-random-number
- Con un componente Choice controlla se son presenti i parametri min e max
a) Se trova min e max, allora mediante il connettore Java > Invoke static chiama il metedo generateNumber(Double, Double) della classe GenerateNumberTransformer che genera un numero random all’interno del range passato
b) In assenza di parametri, mediante il connettore Java > Invoke static chiama il metedo generateNumber() della classe GenerateNumberTransformer che genera un numero random - Restituisce il risultato ottenuto in formato JSON
Il flusso sarà dunque così composto:
ESEMPIO 4: REST API
Come ultimo caso chiamiamo un servizio esterno che fornisce previsioni meteo:
http://api.openweathermap.org/data/2.5/weather?
dove la chiamata GET ha bisogno di due parametri: q = il nome della città e appid = il token di registrazione.
Dunque al path /weather noi passeremo il nome della città:
http://127.0.0.1:8081/weather?city=Venezia
per avere in questo caso le previsioni di Venezia.
Per connetterci al servizio meteo creiamo un HTTP Request configuration tra i Global Elements che configuriamo come indicato sotto.
Nel flusso abbiamo quindi un elemento HTTP Listener con path /weather; con un elemento Set Variable ci salviamo il nome della città che recuperiamo tra i parametri della chiamata http; con un elemento Request (HTTP), che utilizza il connettore globale creato in precedenza, effettuiamo la chiamata al servizio impostando i parametri richiesti.
In caso di esito positivo della chiamata al servizio verrà visualizzato il JSON con i dati meteo della località richiesta. In caso di risposta KO del servizio, il flusso prevede la possibilità di gestione delle eccezioni: distinguiamo dunque l’errore 404 – Not Found da un generico errore riportando due diversi messaggi di errore, impostando opportunamente i messaggi nel payload.
Nell’immagine sotto il risultato che si ottiene.
Se si simulano due casi di KO invece si ottiene:
Con questo esempio ho concluso la carrellata di possibili applicazioni.
Al prossimo appuntamento!
TI È PIACIUTO QUESTO ARTICOLO? LEGGI ANCHE:
Enterprice Service Bus: tutto quello che devi sapere
Realtà virtuale: realizzare mondi virtuali con Unity
Htcap: lo scanner delle applicazioni web di We Are Segment
