Questi ultimi anni sono stati caratterizzati dalle nuove tendenze architetturali che hanno visto sulla cresta dell’onda il modello architetturale SOA.

SOA è un’architettura orientata ai servizi e si propone come metodologia per organizzare gli elementi delle applicazioni come servizi. La letteratura presenta però svariate definizioni e il modello di riferimento non è standard.

Per cui tutto ciò lascia spazio ai vendor che “propongono” i loro prodotti e le proposte dei vari fornitori sono dei modelli che non sempre rispecchiano dei principi architetturali corretti e pur dichiarando di implementare SOA, contraddicono regole di buona programmazione enterprise.

Molto spesso l’errore è quello di lasciarsi guidare e partire dalle tecnologie abilitanti una soluzione, senza invece partire dalla soluzione al problema, depurata dagli strumenti atti a realizzarla.

In questi anni abbiamo lavorato a un modello architetturale orientato ai servizi, applicato in seguito in ambito bancario, con le customizzazioni del caso.

Il modello architetturale è stato ideato partendo dall’assunto che i modelli applicativi tipici prevedono l’esistenza di un front-end (illustrato nella parte sinistra della figura sotto); da qui vogliamo poi integrare quello che fa parte del contesto SOA (data la necessità di esporre i sistemi come servizi) con tutto ciò che non fa parte di un contesto a servizio (illustrato nella parte destra della figura sotto).

Ecco i layer architetturali del mondo SOA:

• Integration: risolve il problema dell’eterogeneità delle tecnologie. E’ lo strato di confine tra il mondo soa e quello non soa, come tale riesce ad integrare le funzionalità dei sistemi esistenti come database o sistemi legacy. Tale layer presenterà una interfaccia che riesce ad interagire col mondo non-soa ed una seconda che interagisce col sistema di riferimento soa;
• Execution: gestisce la logica di business;
• Composite: orchestra i servizi di sistema ed espone le funzionalità business mediante dei processi orchestratori del flusso generale;
• Service: questo livello, ”realizza” le funzionalità business, per cui si vuole separare la realizzazione o implementazione da quello che è la presentazione del servizio. E’ una sorta di delega che espone il servizio business verso l’esterno. La sua utilità è legata anche alla possibilità di presentare un certo sotto-insieme dei servizi che si vogliono esporre in base ai diritti di chi accede al sistema.

Il modello descritto si è prestato a supportare casi reali di nostri clienti, soprattutto di ambito bancario.  Il contesto molto spesso è stato quello di effettuare la migrazione del loro prodotto o di parte di esso verso uno nuovo  che rispondesse ai principi SOA. Non sempre tutti i layer sono stati necessari, la loro introduzione o meno dipende dai contesti in cui si opera.

Il modello permette di rispondere agli obiettivi di integrazione e di facilitare il processo di sviluppo delle applicazioni SOA-oriented. Inoltre, vuol essere un’alternativa ai modelli proposti dai fornitori, sottolineando il fatto che non sempre è necessario utilizzare un ESB per fare SOA.