Due chiacchiere su SOA e EDA...

Service Oriented credo sia uno dei termini più blasonati e "overlodati" (scusate il riferimento Object Oriented, ma non è a caso) degli ultimi anni in ambito architetture applicative. L’architettura orientata ai servizi o service-oriented può essere considerata una derivazione del concetto object oriented presente nella letteratura dell'ingegneria del software visto con un 'ottica più di business che tecnologica. Infatti, questa architettura si basa sull'ipotesi che processi complessi possano essere ricondotti a componenti o unità di dimensioni limitate e compiute chiamati servizi. Questi servizi possono essere composti da un motore di composizione/orchestrazione per formare le applicazioni di business.

I tre elementi base presenti in una SOA sono :

Service Consumer : colui che utilizza i servizi. (a sua volta può essere un servizio o una applicazione).

Service Provider : colui che eroga il servizio (che è in ascolto di incoming messages).

Service Broker o Directory : registrazione dei servizi ed eroga funzionalità di ricerca.

tra questi attori sono possibili molte modalità di comunicazione chiamate anche Message Exchange Patterns (MEP)-

L’architettura a servizi SOA (Service Oriented Architecture) nasce con l’obiettivo di realizzare servizi, chiamati anche processi di business, disponibili a un qualsiasi richiedente o consumer. Il modello SOA consente una conversazione semplice basata sul paradigma consumer/provider tramite interfacce e protocolli standard e l’integrazione di servizi composti.

SOA è un paradigma che prevede lo sviluppo e l’impiego di servizi in accordo con i seguenti principi (o tenets):

• I boundary sono espliciti.
• I servizi sono autonomi.
• I servizi si scambiano schemi e contratti, non classi.
• La compatibilità tra servizi è stabilita via Policy.

L' architettura SOA non richiede la presenza di server centrali o funzioni amministrative centralizzate, ma consente la comunicazione fra trust diversi e fra entità indipendenti. I moduli e i protocolli non presuppongono la presenza di alcuna tecnologia di implementazione specifica presso l'endpoint applicativo. Inoltre, il paradigma SOA ha ridefinito anche il concetto di applicazione. Un’applicazione non è più semplicemente un’implementazione procedurale locale o distribuita ma al contrario una sequenza di messaggi orchestrati, dinamicamente instradati e trasformati.

L’obiettivo primario di un’Architettura Applicativa definita secondo il modello SOA deve essere quello di abilitare e gestire i processi di business. Infatti, tali processi svolgono un ruolo fondamentale nel determinare il valore effettivo di un'organizzazione. Processi di business ben strutturati consentono alle organizzazioni di creare del valore utilizzando in modo efficiente persone e prodotti. La piattaforma applicativa deve quindi integrare in modo efficace sistemi dipendenti e partner commerciali attraverso processi di business facilmente gestibili al fine di automatizzare e organizzare al meglio le interazioni. Inoltre deve essere garantita un’elevata flessibilità riducendo al minimo la necessità di intervento umano. Queste potenzialità derivano direttamente dalle caratteristiche peculiari di un’architettura SOA. Gli sviluppatori potranno continuare a lavorare nell'ambiente di sviluppo a loro familiare ed in aggiunta avranno l'opportunità di utilizzare servizi basati su standard per garantire maggiore protezione ed affidabilità nell'automazione dei processi di business interni ed esterni all'azienda.

Adottare un modello SOA significa creare un ecosistema infrastrutturale, capace di dare dei benefici a tutti i diversi livelli presenti nell’azienda.

La definizione di una nuova architettura è collegata principalmente alle seguenti macro esigenze strategiche:

• Migliorare la maintenance dei sistemi consolidando le tecnologie.
• Centralizzare le attività comuni a tutte le applicazioni.
• Interoperabilità tra diverse tecnologie in modo nativo.
• Facilitare la definizione e la realizzazione di nuovi processi produttivi.
• Aumentare la disponibilità dei servizi aziendali a tutta l’organizzazione.
• Permettere una migliore sinergia tra aree aziendali separate.
• Aumentare la semplicità d’uso da parte degli utenti.

The Big Picture

Nella definizione di una infrastruttura applicativa basata sui principi di SOA e di EDA è necessario definire un "ecosistema applicativo" che comprenda tutte queste macro aree:

ovvero:

Event Driven Architecture (EDA)

Negli ultimi anni, insieme all’architettura SOA, è emerso anche un secondo modello chiamato Event Driven Architecture (EDA).

EDA è un’architettura che permette ai servizi di reagire dinamicamente agli stimoli “esterni”. Questi stimoli possono essere generati da diverse fonti: sistemi, persone, processi di business oppure eventi di natura tecnica predeterminati o non previsti. Gartner fornisce una definizione precisa di evento:

• Evento Ordinario: gli eventi ordinari sono semplicemente qualche cosa che è accaduto.
• Evento Software: Un evento Software è la registrazione automatica di quanto accaduto. Gli eventi software sono oggetti, spesso codificati in forma di messaggi, che rappresentano un evento ordinario.

In EDA gli end-point sono fortemente slegati e gestisce le notifiche con modello PUSH.

Il routing in EDA riveste un aspetto molto importante:

Due tipi di message routing:

• Definito a design-time
  • client<->server
  • flow based (Biztalk, batch,...)
• Definito a run-time
  • content based.
  • eventi

Relazioni tra SOA e EDA

Come si può notare nella figura sottostante SOA e EDA possono coesistere ed hanno molti punti in comune, ma non sono la stessa cosa !!!

infatti possiamo riassumere la relazione in 4 casi:

anche in relazione alla scalabilità dei modelli disconnessi

Da un punto di vista pratico vorrei riassumere la realzione in questi termini:

• Riguardano differenti aspetti dello stesso problema (architettura applicativa).
• EDA è un componente “core” di un sistema (anche SOA) che descrive un particolare “message routing” tra i servizi.
• EDA trasforma il concetto di “loosely coupled”, definito in SOA, in “decoupled”
  • SOA: il producer e il consumer condividono il “Service contranct”
  • EDA : nessuna condivisione
• EDA da per scontato la presenza di un “message bus”. SOA NO !!!!!!!!! (so che alcuni di voi stanno storcendo il naso :-)
• SOA può contenere al suo interno un routing dinamico completamente “decoupled” (EDA).
• Le due architetture definiscono il messaggio in XML trasportato tramite SOAP.
• SOAP supporta gli “interaction patterns” sia per SOA che per EDA.

Tassonomia degli scenari Event Driven

Gartner inoltre suddivide la tassonomia degli scenari Event Driven in quattro categorie:

• Simple Event Driven Applications.
  • Gestione diretta, ogni sorgente contatta direttamente gli opportuni sink.
  • Nessuna ipotesi di accoppiamento sorgente-sink se non la comune comprensione del formato degli eventi(messaggi) scambiati.
• Brokers-Mediated Applications.
  • Viene implementato tramite un intermediario: il broker.
  • Il broker può effettuare content based routine dinamico dei messaggi.
  • Il broker può applicare regole applicative.
• BPM (Business Process Management) directed Applications
  • Gestione di processi long running contattando gli endpoint anche a seconda dei loro ruoli legati all’istanza della business activity stessa.
  • Può essere configurata in due modalità:
    • Broker
    • Può gestire messaggi che iniziano o terminano business activities.
• Complex Event processing Applications
  • Sistema di gestione centralizzato.
  • Filtra gli eventi instradandoli secondo regole anche complesse.
  • Può aggregare insiemi di eventi in messaggi di ordine superiore riconoscendo dei pattern codificati.

Concludendo l'architettura SOA e EDA sono complementari ed entrambe molto importanti per l’evoluzione nell’ambito IT.

Criteri di valutazione SOA

Microsoft per la valutazione di una Service Oriented Architecture utilizza un modello chiamato ESOMM (Enterprise Service Orientation Maturity Model).

Questo modello deriva dal SW-CMM (Capability Maturity Model for Software) di Watts Humphrey successivamente gestito dal Software Engineering Institute (SEI) della Carnegie Mellon University (CMU) di Pittsburgh (USA). SW-SMM rappresenta lo standard per la valutazione e il continuo miglioramento dei processi di sviluppo del software.

ESOMM applica lo standard definito da SW-CMM al modello SOA ed evidenzia gli aspetti di valutazione.

ESOMM si basa su quattro aree funzionali per l’azienda:

• Extensible : L’azienda deve essere in grado di aggregare i servizi e di estenderne il loro utilizzo
• Supportable : L’azienda deve poter gestire facilmente un incremento nell’uso dei servizi per garantire gli SLA definiti.
• Repeatable : L’azienda implementa,consuma e riutilizza i servizi in modo efficiente e consistente.
• Usable : L’azienda è in grado di scrivere e consumare servizi tramite protocolli standard senza fatica.

Queste quattro aree vengono valutate rispetto a tre fattori : Implementation, Consumption e Administration formando la seguente griglia:

Questa griglia deve essere di riferimento durante la definizione e l’implementazione di una architettura SOA in ambiente enterprise.

--Mario