SOA Architecture ed Enterprise Service Bus

Come funziona l’architettura SOA- Service Oriented Architecture

La SOA Architecture è un’architettura software basata sul principio del riutilizzo dei componenti grazie all’uso di servizi web, risultando quindi un’architettura distribuita di componenti isolati che consente l’interoperabilità dei sistemi. Proprio per queste sue caratteristiche viene spesso definita e utilizzata in opposizione alle architetture monolitiche, centralizzate in una singola unità e rilasciate in un singolo pacchetto.

L’architettura centralizzata presenta infatti diversi svantaggi che le architetture distribuite sono state chiamate a superare: innanzitutto, questo tipo di architettura è costituita da un’unica unità atomica che racchiude in sé tutti i componenti necessari al suo funzionamento: l’interfaccia Client-side, l’applicazione Server-side e il Database. Questo tipo di struttura richiede quindi un unico rilascio e l’impossibilità di intervenire “a caldo”.

È chiaro come la rigidità di questa architettura sia in netto contrasto con la dinamicità dei processi di sviluppo odierno e con le esigenze business sempre più mutevoli delle aziende. Proprio per superare questa rigidità, si è cercato una soluzione più distribuita, in grado di fornire ampio spazio di manovra ai team di sviluppo, sia lato integrazione degli applicativi che in termini di velocità di evoluzione dei sistemi software.

Se infatti la SOA si pone come tassello tecnologico fondamentale per favorire l’integrazione software, è altrettanto vero che sono le architetture a microservizi che superano nettamente il concetto di monolite. L’architettura a microservizi e la SOA Architecture sono entrambe incentrate sui servizi e sono entrambe architetture distribuite, ma differiscono sotto alcuni aspetti: il principale è che la SOA si avvale di un Enterprise Service Bus per gestire l’orchestrazione tra applicativi tramite servizi ed API di comunicazione, mentre i microservizi utilizzano protocolli più leggeri e spesso open source, ad esempio http/REST.

SCARICA IL WHITE PAPER SULLA SYSTEM INTEGRATION

Altro aspetto derimente è che in un’architettura a microservizi, i servizi sono tanti e di piccole dimensioni con una modularizzazione e separation of concerns più marcata, mentre nell’architettura SOA sono inferiori numericamente, ma più complessi. Inoltre, nel caso dei microservizi, ogni servizio dispone di un proprio database, mentre nel caso della SOA tendenzialmente lo storage è unico.

SOA ESB Architecture: l’utilizzo del middleware di integrazione

La SOA Architecture rappresenta in particolare il superamento dell’integrazione point to point degli applicativi: con questo tipo di integrazione, infatti, gli applicativi sono connessi uno ad uno, andando a creare una fitta rete di integrazioni e aumentando così la dipendenza del parco applicativo e la complessità dell’infrastruttura. Inoltre, l’intervento su un singolo applicativo, la sua sostituzione o una sua disfunzione temporanea, comporta impatti sulla fitta rete di integrazioni e quindi un serio problema operativo.

Con la SOA si superano questi limiti grazie all’utilizzo di un middleware, un Enterprise Service Bus (ESB), in grado di eseguire un’integrazione orizzontale. Grazie a questo tipo di integrazione, infatti, gli applicativi sono disaccoppiati e connessi grazie a un unico punto rappresentato dall’ESB che orchestra lo scambio di informazioni tra i diversi software, adeguandone il formato.

Tra i Service Bus migliori in commercio, Omnia Group ha scelto Mulesoft Anypoint Platform, un software di integrazione e Api management. Grazie all’implementazione di Mulesoft è possibile integrare l’intero parco applicativo e anche software esterni all’organizzazione tramite ESB.

L’Enterprise Service Bus si pone al centro del sistema di integrazione, veicolando le informazioni provenienti dagli applicativi verso i software di destinazione, anche se scritti in linguaggi di programmazione diversi: l’ESB quindi, oltre a veicolare i dati, ha la funzione di traduttore delle informazioni e fornisce dati puntuali e integri. I dati non vengono mai persi grazie a un sistema di persistenza e recovery che si attiva in caso di momentanea indisponibilità dell’applicativo destinatario: una volta tornato in funzione, le informazioni vengono inviate e ricevute correttamente, senza alcuna perdita di dati.
In una SOA Architecture, Mulesoft si presenta come l’ESB ideale per razionalizzare gli asset aziendali, centralizzare le logiche ed agevolare la comunicazione tra i reparti interni ed esterni all’azienda: è infatti possibile connettere il parco applicativo ai software utilizzati dai partner, fornitori e clienti, velocizzando così lo scambio di informazioni e riducendo il rischio di una condivisione manuale.

SCARICA IL WHITE PAPER SULLA SYSTEM INTEGRATION

Oltre al ruolo dell’ESB, Mulesoft fornisce il servizio di management delle API: le Application Programming Interface sono gestite direttamente sulla piattaforma e possono essere controllate, securizzate e monitorate, ed in caso di malfunzionamenti è possibile intervenire tempestivamente grazie al sistema di alert fornito da Mulesoft.

Utilizzando un ESB come Mulesoft, tutti i vantaggi della SOA Architecture sono garantiti:

• Time to market più veloce: la razionalizzazione degli asset aziendali promossa dell’ESB e la disponibilità di funzionalità di integrazione già pronte su Anypoint Exchange permettono di sviluppare rapidamente nuovi processi;
• Maggiore scalabilità proprio grazie ad un’architettura flessibile a servizi ed all’approccio API led connectivity;
• Nessun vincolo in termini di adozione di protocolli, tecnologie o formati dato;
• Manutenzione applicativa più semplice e meno costosa grazie ad un’infrastruttura di integrazione centralizzata e senza dipendenze;
• Pieno controllo dell’infrastruttura e delle sue performance grazie agli strumenti di monitoring;
• Governance dei servizi personalizzabile e centralizzata, gestendo le autorizzazioni e la sicurezza delle API direttamente sulla piattaforma ESB.