L‘Enterprise Service Bus di GreenVulcano continua ad evolversi e questa volta lo fa partendo dal nome: GAIA, un termine antico per un software ultra-moderno. E un pensiero va ad Asimov e al suo pianeta “Gaia”: come il nostro ESB, un ecosistema integrato, in perfetto equilibrio e in continua comunicazione tra le sue parti.

BRAND

  • NAMING

Il naming GAIA nasce dalla volontà e dal tentativo di individuare un nome che, coniugando unicità e semplicità, fosse coerente con la classicità e l’anima Made in Italy dei prodotti GreenVulcano. 

In fase di brainstorming, il nostro SVP & CoFounder Gianfranco Iannello ci ha parlato dei racconti di Asimov, nei quali Gaia è un pianeta dotato di un ecosistema in perfetto equilibrio: “Su Gaia ogni elemento ha una propria consapevolezza che lo rende autonomo e allo stesso tempo in continuo collegamento con le altre componenti”.

Questo continuo contatto consente di appianare, in favore dell’intera collettività, i contrasti che talvolta nascono tra gli elementi.

Il termine GAIA è anche sinonimo di Gea, la Terra, un sistema unificato. In questo senso, la capacità dell’ESB di GreenVulcano di porsi in perfetta simbiosi e sincronia unica con chiunque entri in suo contatto offre l’immagine di un organismo unico, compatto e coeso, nonostante le connessioni e le relazioni interne.

L’equilibrio e l’armonia dell’ecosistema inteso nella sua integrità (Gea), sono quindi il risultato dell’integrazione, favorita da GAIA, di sistemi autonomi in contrasto (di linguaggio di programmazione o protocolli).

  • ACRONIMO

Il naming GAIA ha un ulteriore significato, che abbiamo individuato nell’acronimo con l’obiettivo di “raccontare” il prodotto, aggiungendo informazioni rispetto al percepito del naming stesso, mantenendo, dove possibile, una continuità con il passato: GreenVulcano Advanced Integration Architecture.

Si è posta l’attenzione sul termine “Integration”, competenza forte e core del prodotto. Abbiamo definito l’integrazione “Advanced” per suggerire un upgrade rispetto al passato ed enfatizzare uno standard qualitativo superiore rispetto alla media del mercato. Il termine “Architecture” è stato, invece, usato per esprimere l’idea che il prodotto sia solo la base per un sistema IT aziendale complesso, la spina dorsale dell’infrastruttura.

  • LOGO 

Una volta trovato l’accordo tra le anime tecniche e quelle commerciali dell’azienda sul racconto da trasmettere, ci siamo focalizzati sulla realizzazione del logo, con una mission ben chiara: realizzare un logo originale, semplice e riconoscibile, che fosse allo stesso tempo coerente con la l’identità aziendale e in armonia con le feature del prodotto.

La forma sferica, chiaro rimando al pianeta Gea-Gaia, vuole suggerire l’“universalità” dell’integrazione e la capacità di GAIA di integrare e orchestrare la comunicazione con qualsiasi componente esterno.

Ne consegue un flusso di dati ed informazioni estremamente fluido. Le numerose connessioni rappresentate all’interno della sfera, unita alla scelta di una font a caratteri arrotondati, enfatizzano questo concetto. 

Il colore rosso è un visibile richiamo cromatico, soprattutto per i partner di lunga data, alla triade di colori che caratterizza il logo di GreenVulcano. I colori di questa triade sono associati singolarmente ad un prodotto.

BREVE STORIA DEL NOSTRO ESB: GAIA IERI, OGGI E DOMANI

Il concetto di Enterprise Service Bus nasce e si sviluppa a cavallo del nuovo millennio, come risposta alle esigenze degli utenti di avere accesso immediato a tutte le funzioni, che possono essere fornite da applicazioni e servizi, all’interno o all’esterno dell’azienda.

  • DALLA VERSIONE 1.0 ALLA 2.0 

I primi software ESB di GreenVulcano poggiavano le basi sui concetti e i modelli descritti da Gregor Hohpe e Bobby Woolf nel saggio “Enterprise Integration Patterns”, considerato una pietra miliare e un punto di riferimento per la progettazione di soluzioni di integrazione.

Erano caratterizzate da una forte centralizzazione del sistema; un’architettura monolitica, sviluppata e distribuita come una singola entità, utilizzabile solo in locale, che comportava necessariamente un’installazione pesante. Inoltre l’unico modo di poter scalare un’applicazione monolitica era quello di replicare l’intera applicazione con conseguente aumento di costi e risorse necessarie. 

  • 3.0

L’avvento del cloud computing e dell’architettura orientata ai servizi (SOA) ha reso necessario lo sviluppo di una versione più evoluta e funzionale alle nuove modalità di integrazione.

GreenVulcano ESB 3.0 è un software, basato su Java, con un’architettura multi-layer altamente personalizzabile, creato appositamente per supportare architettura SOA complesse.  Questa versione nasce per rispondere alle esigenze di scomposizione delle applicazioni monolitiche in una serie di servizi distinti capaci di dialogare fra loro in rete.

  • GAIA

Le dinamiche di mercato e l’evoluzione dei processi di integrazione che hanno determinato lo sviluppo della versione ESB 4.0, denominata GAIA, vengono descritte direttamente attraverso le parole del nostro Senior Developer Rocco Lagrotteria: La necessità di ulteriore granularità e flessibilità operativa ha dato vita all’approccio basato sui microservizi. Tale modello offre maggior scalabilità e personalizzazione, consentendo di “spacchettare” le applicazioni complesse in componenti più piccoli e mirati. In questo senso, GAIA si basa su una struttura modulare che permette di supportare l’architettura a microservizi.

Ciò significa che è possibile installare esclusivamente i moduli necessari al funzionamento del singolo caso d’uso

DIREZIONE FUTURA

Il nostro CTO Mario Stefanutti ci ha invece parlato della possibile direzione futura del software. Di fatti, parallelamente all’evoluzione architetturale, “Dal punto di vista del linguaggio, Java 11 ha sostituito la precedente versione basata su Java 8 ed in un futuro prossimo è presumibile che, al fine di migliorare le prestazione e offrire maggiore funzionalità, GraalVM subentrerà all’attuale piattaforma Java. Le sfide relative all’integrazione delle applicazioni sono rimaste sostanzialmente le stesse, ma il modo in cui le risolviamo è cambiato. In futuro, per migliorare la fruibilità dei servizi, le comunicazioni canale/consumatore, in GAIA, avverranno sempre più tramite API e andremo verso lo sviluppo di software cloud native con Docker e Kubernetes al fine di garantire una massive scalability dei microservizi.

Consapevoli delle sfide che il mercato futuro ci riserverà e forti delle esperienze passate, siamo pronti oggi, arricchiti nel nome e nelle funzionalità, ad offrirvi la miglior soluzione ai problemi di integrazione.Contattaci per scoprire tutti i vantaggi e i benefici che GAIA può apportare alla tua azienda.

Al giorno d’oggi i clienti dispongono di una vastissima gamma di strumenti informatici. Questa grande varietà di sistemi, incrementata dal continuo sviluppo di software sempre più innovativi, rende estremamente difficoltoso il processo di sincronizzazione di dati provenienti da applicazioni diverse fra loro.

SYSTEM INTEGRATION

In questa ottica è assolutamente opportuno lavorare all’integrazione dei sistemi. La system integration permette a vari sistemi IT e applicazioni software di funzionare come una struttura unificata, coordinata e cooperante.

Tale integrazione porta diversi vantaggi sia al cliente che all’impresa: un flusso di informazioni migliorato, un aumento della qualità del prodotto e delle prestazioni complessive dell’azienda. Insieme, questi benefici consentono anche di ridurre i costi e migliorare l’efficienza aziendale.

INTEGRAZIONE POINT-TO-POINT

Nel tentativo di ripercorrere progressivamente, in termini concettuali e pratici, il processo evolutivo della system integration, la prima tappa di questo percorso, in ordine cronologico, coincide con il modello conosciuto come point-to-point.

È un’integrazione che vede coinvolti solamente due sistemi. Trattandosi quindi di un’integrazione piuttosto snella non garantisce grande efficacia se applicata in un modello aziendale articolato.

STAR INTEGRATION

La Star Integration è la naturale evoluzione del modello precedente: ogni sistema è integrato con gli altri attraverso connessioni point-to-point.

 Le criticità dell’integrazione precedente non sono risolte, portando al risultato, all’aumentare degli elementi coinvolti, di un’integrazione sempre più caotica. Non a caso questa tipologia di integrazione viene definita anche “spaghetti integration”.


VERTICAL INTEGRATION

Il modello che, parzialmente, risolve le problematiche delle due precedenti integrazioni è la vertical integration. Nell’integrazione verticale i sistemi vengono messi in comunicazione in base alla loro funzionalità, creando entità chiamate silos. Nel caso in cui si dovesse inserire una nuova funzionalità  sarà però necessario creare un nuovo silo. Questa strategia può essere adatta ad aziende con infrastrutture verticali complesse.

ENTERPRISE SERVICE BUS (ESB)

L’integrazione che forse meglio esprime realmente il concetto di System integration è l’integrazione orizzontale, in cui un layer viene utilizzato come interfaccia comune tra tutte le altre componenti. Questo layer altro non è che un’architettura ESB. Il termine Enterprise Service Bus è stato coniato da Gartner nel 2002.

In ogni realtà aziendale esistono una pluralità di sistemi e servizi, ciascuno con la sua utilità. Ma se ogni servizio dovesse essere integrato di volta in volta con tutti i nuovi servizi utilizzati in azienda, quante integrazioni dovremmo creare? E il relativo costo sarebbe sostenibile dall’azienda?

Un software ESB offre l’enorme vantaggio di fornire un’integrazione unica verso ogni sistema. L’ESB è in grado di integrare al suo interno sistemi eterogenei, connettendo tra loro tecnologie composite e fornendo costantemente servizi di coordinamento, sicurezza di accesso, messaggistica, routing intelligente e fungendo da dorsale del computer attraverso il quale tutti i servizi software e le componenti delle applicazioni possono viaggiare.

MODALITÀ D’INSTALLAZIONE DI ESB

L’ESB è installabile attraverso tre differenti modalità

  1. on-premise
  2. cloud
  3. hybrid-cloud.

ON-PREMISE

La soluzione on-premise garantisce un controllo esclusivo su sistemi e dati e una gestione interna di dati sensibili e core. È una soluzione da preferire nel caso in cui la gestione diretta dei dati sia fondamentale per policy aziendali e nel caso in cui sia necessario che l’organizzazione venga localizzata geograficamente.

CLOUD

La soluzione cloud assicura scalabilità, affidabilità e soprattutto l’erogazione del servizio in tempi rapidi. Infatti con l’accesso in mobilità è possibile connettersi ai dati in qualsiasi momento, attraverso qualsiasi device. Per quanto riguarda la sicurezza del sistema, i dati e le reti vengono protetti con servizi presidiati sempre da backup oltre che da appositi protocolli di sicurezza a tutela dell’integrità e riservatezza dei dati.

HYBRID-CLOUD

Tuttavia la memorizzazione dei dati sensibili nel cloud è spesso motivo di preoccupazione per le aziende. Un’ottima soluzione a queste difficoltà è offerta dall’integrazione hybrid; i dati sensibili rimangono in sede, mentre i dati non-sensibili possono rimanere nel cloud, offrendo alle aziende l’opportunità di segregare e tracciare i movimenti. Sono le aziende quindi a decidere quali dati archiviare nel cloud e quali in locale.

ESB: AN OLD NEW INTEGRATION

Nonostante questa distinzione, è necessario precisare che originariamente l’ESB trovava applicazione solo in locale. La naturale conseguenza, incrementata dall’ impellente necessità di integrare applicazioni e dati on-premise con applicazioni e dati cloud, è stata l’identificazione dell’ESB come un software superato che dovesse lasciare il passo a soluzioni iPaaS (Integration Platform as a Service). Tuttavia un buon software è programmato per rispondere alle necessità di aggiornamento e rinnovamento e così si è arrivati allo sviluppo di software, come l’ESB open source GreenVulcano, estremamente leggeri che supportano le API e piattaforme di integrazione che si collegano ai sistemi legacy. 

Lo sviluppo di software che valicano l’approccio tradizionale dell’architettura SOA, interpretando in modo innovativo l’integrazione delle applicazioni aziendali (EAI), ha dato nuova linfa vitale ad un software erroneamente definito obsoleto.

L’ESB (2.0) è in grado di soddisfare le esigenze odierne di elevata flessibilità, mantenendo comunque l’affidabilità dei sistemi tradizionali. In quest’ottica, il futuro dell’ESB sembra essere positivamente roseo. 

ASK US FOR MORE INFORMATION!

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