Architetture, ESB or Not ESB

Esiste molta confusione sul ruolo che un Enterprise Service Bus ha all'interno di un contesto di integrazione e su quando usarlo per ottenere effettivi benefici.

ESB

Storicamente parlando, un ESB rappresenta l'ultimo anello evolutivo di quelle che negli anni '90 erano note come soluzioni di Enterprise Application Integration, basate sulla coppia Adapter/Connector e orchestrati da un message Broker.
L'evoluzione in chiave Web Services, prima, e in chiave SOA, dopo, ha aperto nuovi scenari di integrazione rafforzando il ruolo degli obiettivi di Business e trasformando la tecnologia abilitativa in una utility più che nel focus dell'analisi e della relativa soluzione.
In generale, l'utilizzo di un EBS è consigliabile solo laddove è strettamente necessario e dove i vantaggi sono immediatamente identificabili: non utilizzatelo solo per poter dire di averlo fatto (Resume-Driven Development) o perché ipotizzate che in futuro potrebbe tornare utile. In entrambi i casi esponente l'(Intentional) Architecture ad una complessità non motivata, rendendone il Design poco coerente con il problema che la soluzione andrà a risolvere.
Ricordiamoci sempre che: "simple is better", quanto più l'Architettura è (relativamente) semplice, tanto più il sistema potrà contare su un alta efficacia ed efficienza.
Da un punto di vista architetturale, sono due i macro contesti principali in cui adottare un ESB:

  • Integrazione di asset aziendali, al fine di supportare le nuove esigenze di Business;
  • Soddisfacimento di alcuni particolari requisiti non funzionali, primi tra tutti il disaccoppiamento tra i Servizi e l'aumento dell'affidabilità dell'intero sistema.

In realtà il caso più utile è proprio il primo, perché i requisiti non funzionali spesso sono coperti in modi diversi, e, con quanto detto scolpito nella memoria, cerchiamo di vedere alcune linee guida che possono risultare utili per capire se utilizzare o meno un ESB:

  • Il numero di applicazioni enterprise da integrare è maggiore, o al limite uguale, a 3? Se le applicazioni sono 2 è preferibile un'integrazione point-to-point, realizzabile senza timore di andare incontro a fenomeni di spaghetti-coding. Anche nel caso in cui si hanno più applicazioni da integrare è sempre possibile spostare il problema con una logica bottom-up e integrarle in sottosistemi omogenei;
  • Siete assolutamente sicuri che in futuro il sistema dovrà supportare l'integrazione di ulteriori applicazioni? Se la risposta è no, allora è meglio non usare un ESB: You'll Never Need It (YNNI);
  • Avete bisogno di utilizzare diversi protocolli di comunicazione? Se usate solo HTTP/SOAP o MOM (Message Oriented Middleware), non otterrete alcun beneficio dalle funzionalità cross-protocol messaging tipiche degli ESB;
  • Avete necessità del supporto di un content-based routing o di aggregare i messaggi prima che essi siano consegnati al consumer? Molte applicazioni non sanno che farsene di queste funzionalità;
  • Avete davvero necessità della scalabilità offerta da un ESB? Attenzione a non sovra stimare questo requisito funzionale, portandolo al limite, laddove è raggiungibile anche con soluzioni più semplici (es: Service Clustering & Caching).

In sintesi non utilizzate un ESB se:

  • da esclusivamente risalto al vostro curriculum;
  • non avete oggi bisogno delle sue funzionalità, ma pensate esista una remota possibilità di sfruttarle in futuro;
  • non avete valutato soluzione alternative più semplici.

Se l'architettura in cui pensate di inserire un ESB è riconducibile al seguente schema (90% dei casi):

high-level-esb

not use ESB

allora, quasi sicuramente, un ESB è assolutamente una complessità architetturale eliminabile. Al contrario, se la vostra architettura somiglia più a quella della figura seguente:

To-ESB

use ESB

un ESB può essere la soluzione giusta per realizzare il vostro sistema.

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme