Enterprise service bus| GreenVulcano 4 un ESB open source leggero e potente

GreenVulcano 4, l'ultima evoluzione del nostro enterprise service bus open source pensato per  andare oltre il tradizionale approccio su architettura SOA interpretando in modo innovativo l' enterprise application integration (EAI) per rispondere alle esigenze odierne di elevata flessibilità  ma con la robustezza e l’affidabilità dei sistemi tradizionali.

1. Velocità, in tutte le fasi del ciclo di vita, dallo sviluppo al provisioning sino alle operations, per rispondere nel migliore dei modi alle mutevoli esigenze del mercato;
2. Economicità, limitando i costi di infrastruttura, grazie alla possibilità di essere utilizzato sia su cloud on demand che su commodity hardware, abbattendo così anche i notevoli costi di licenza software;
3. Flessibilità, modularità e polimorfismo, che garantiscano la capacità di coprire esigenze che ancora non sono nate e non riusciamo a prevedere, mutando la sua stessa struttura senza una progettazione da zero.

Enterprise service bus| cos'è

Intrinsecamente, l’enterprise service bus è un meccanismo, in cui è sempre prevista un'interfaccia bidirezionale dai sistemi connessi. Ciò significa che tutti i sistemi di origine e di destinazione devono essere connessi all' ESB e che le applicazioni stesse comunicano attraverso l’invio di messaggi sul bus.

Un enterprise service bus è dunque un bus sul quale viaggiano messaggi tra entità integrate tra loro.
Non bisogna però pensare al BUS ad una struttura meramente di intermediazione in quanto è possibile modificare i messaggi intervenendo nella logica del software.

ESB GreenVulcano: un caso d’uso

Per capire meglio la forza di un ESB, andiamo ad analizzarne una sua implementazione.
Supponiamo di avere un modello di business secondo il quale, una serie di negozi che operano in conto vendita, vengono riforniti periodicamente da un unico magazzino, il tutto rispettando la seguente logica:

1. All’arrivo della merce in ogni negozio il sistema ERP deve essere aggiornato
2. La cassiera che effettua la vendita del singolo capo di abbigliamento,  invia tramite l’App l’informazione al sistema ERP. Lo stato del capo viene aggiornato in “venduto”.
3. La cassiera o il responsabile delle Vendite invia tramite l’App l’eventuale reso del capo che un cliente gli ha restituito, per l’emissione di una Nota di Credito
4. Un batch notturno emette fattura per ogni negozio sul venduto giornaliero
5. Il sistema di Pagamento invia a Banca Sella la richiesta di SDD (Sepa Direct Debit). Fattura in stato “in pagamento”. A messaggio di avvenuta riscossione del pagamento da parte della Banca la fattura viene settata come “saldata”.

Come si può vedere ci sono diversi sistemi e componenti che cooperano tra loro in una realtà che possiamo definire di integration platform: il sistema ERP, i web service esposti dalla banca, l’applicativo che aggiorna il sistema ERP per ogni vendita di un capo, l’inserimento dei dati che avviene tramite lettura  NFC dei vari capi etc...Tutti questi possono infatti adoperare protocolli e linguaggi di programmazione differenti.
L’enterprise service bus mette in comunicazione le diverse applicazioni con cui si interfacciano.

Se ogni servizio dovesse avere un’interfaccia di comunicazione per ogni altro servizio, quante interfacce dovremmo creare?!
Ecco dunque che ogni sistema dovrebbe avere un’unica interfaccia verso l’ ESB.

Scalabilità di un ESB

Immaginate l’esempio precedente, in un contesto senza ESB: se ogni componente deve poter interagire con tutti gli altri componenti, non servirebbero più 16 interfacce ma bensi 56!

Ogni modifica su un componente potrebbe comportare la modifica di tutte le interfacce di quei componenti con cui interagisce: potete immaginare il tempo che necessita ogni aggiornamento.
L’utilizzo di un ESB rappresenta dunque la scelta vincente, in quanto possiamo ben intuire come un architettura di questo genere possa essere scalare in termini di componenti, consentendone un numero molto elevato.

Enterprise service bus architecture

L’architettura SOA (Service Oriented Architecture) utilizzata da Greenvulcano, come suggerisce l’acronimo stesso , è un architettura basata sui servizi: su un livello infatti abbiamo le richieste di servizi e su di un altro livello si hanno i servizi veri e propri richiamati e connessi per mezzo di un BUS. Le specifiche OSGI implementate in Greenvulcano permettono dunque lo sviluppo di una piattaforma a componenti.Tali componenti o applicazioni, disponibili sotto forma di bundle per la distribuzione , possono essere installati, avviati, arrestati, aggiornati e disinstallati da remoto senza richiedere il riavvio dell’ ESB che viene deploiato sul container Karaf.
I servizi o componenti all’interno di greenvulcano, possono essere o fortemente disaccoppiati, si pensi al caso in cui  una funzionalità può essere associata ad un singolo servizio, oppure possiamo avere un workflow di servizi (cioè più servizi eseguiti in maniera sequenziale). L’enterprise service bus integra ed orchestra tutto questo.

Enterprise service bus|caratteristiche

Qui di seguito verranno descritte le principali caratteristiche di Greenvulcano

• Esecuzione sul container karaf per una maggiore leggerezza: ciò consente inoltre di  caricare nuove configurazioni e feature a caldo senza dover ricaricare e deployare per intero l’applicazione.
• Integrazione tra diverse applicazioni aventi differenti tecnologie come JMS,Web Services, JDBC, HTTP ed altro
• Un ambiente visuale di sviluppo (developer studio): ciò consente di sviluppare in maniera semplice ed intuitiva alcuniservizi oppure un workflow di più servizi concatenati.Vedi il nostro tutorial e scopri quanto è semplice creare un  event-driven  push notification.

• Una dashboard di monitoring che permette di fare un deploy dei servizi
• Alta affidabilità, sicurezza e scalabilità
• Uso di java 8 e OSGI 6