Security & Architecture : EDA

Cosa intendiamo per Infrastruttura Applicativa

mfontana — Tue, 22 Apr 2008 10:20:00 GMT

L’ Infrastruttura applicativa può essere vista come l’estensione dell’infrastruttura sistemistica capace di offrire servizi ad un insieme controllato di applicazioni.

Questa infrastruttura è un insieme di componenti e servizi che consentono alle applicazioni di comunicare con altrettanti servizi (sia locali che remoti).
L’ Infrastruttura applicativa si occupa qindi di fornire delle funzionalità di base ed avanzate che siano trasversali alle applicazioni oltre ad un insieme di regole sulla modalità di comunicazione che deve essere utilizzata da e per ciascun servizio, rendendo questi dettagli trasparenti alle applicazioni:

I servizi di base sono ad esempio Autenticazione, Autorizzazione, Identity Flow, Logging, Instrumentation, Discovery, ecc.. mentre i servizi avanzati (o di runtime) possono essere : Mail, Fax, Extarnal Services, ecc..

L’utilizzo dei servizi consente di realizzare un sistema secondo i canoni Services Oriented Architecture (SOA) rendendo omogenei e interoperabili i servizi esposti dall’enterprise. SOA sfrutta gli standard di mercato come XML/SOAP e WS-* come definizione delle caratteristiche a cui i servizi esposti aderiscono per consentire comunicazioni sicure, scalabili, reliable, interoperabili, …

Le specifiche WS-*, però, definiscono solo le caratteristiche a cui i WS devono sottostare, lasciando l’implementazione libera. In ambito Enterprise tale libertà introduce la necessità di realizzare un’infrastruttura (o framework) che implementi i servizi base di WS-* mettendoli a disposizione dei WS in modo semplice e trasparente. Rendere i servizi sviluppati indipendenti da quelli base è inoltre garanzia di evoluzione: l’infrastruttura di base è in grado di evolvere seguendo i nuovi standard senza richiedere la modifica dei servizi sviluppati. La presenza di un framework, quindi, consente di poter realizzare una parte fondamentale della SOA disaccoppiando le applicazioni di business dalle caratteristiche d'infrastruttura creando un sistema omogeneo, aderente agli standard, facile da manutenere e da evolvere.

L’ Infrastruttura applicativa dovrà inoltre consentire l’implementazione di differenti Message Exchange Pattern (MEP) attraverso tipologie di contratti differenti come ad esempio :

Request/Reply
OneWay
Duplex

L’ Infrastruttura applicativa fornisce quindi dei servizi a valore aggiunto utilizzabili per tutti i servizi definiti all’interno ed all’esterno dell' Enterprise (sia servizi di basso livello sia servizi di business veri e propri), consentendo al programmatore applicativo di concentrarsi sulla logica della funzionalità specifica senza preoccuparsi della parte infrastrutturale. Inoltre consente di separare gli aspetti di gestione e configurazione dal codice di ciascuna funzionalità, permettendo a chi gestisce l’applicazione di modificare le caratteristiche infrastrutturali senza ricompilare l’applicazione. All’interno dei servizi di base l’ Infrastruttura applicativa è in grado di fornire anche le seguenti funzionalità a valore aggiunto:

Trasporto di informazioni di contesto indipendenti dai singoli servizi.
Caching dei dati restituiti dai servizi
Monitoraggio della comunicazione (tracing, performance counters)
Indipendenza dei chiamanti dalla locazione fisica dei servizi (indirizzamento dinamico)
Gestione centralizzata delle policies ed autoconfigurazione degli endpoint

prossiamanente vediamo come progettare e realizzare una infrastruttura applicativa con .NET

--Mario

Parte l'iniziativa italiana MSDN Talks

mfontana — Mon, 31 Mar 2008 11:25:00 GMT

3..2..1..Pronti via...Parte ufficialmente: MSDN Talks !! Sull'onda dei feedback delle prime interviste estendiamo lo scope anche ai numerosi esperti presenti all'interno di Microsoft italia (e non solo) al fine di condividere esperienze e passioni maturate durante la realizzazioni di progetti reali. Per l'occasione abbiamo anche un LOGO disegnato dal nostro creativo di fiducia :-)

Non solo tecnologia quindi, ma anche best practices e consigli pratici frutto di mesi di lavoro sul campo... Queste interviste, come avrete modo di constatare sono molto "naturali" ovvero non ci sono prove di registrazione o backstage particolari :-) (nel bene e nel male). L'idea è semplicemente quella di condividere le "chiacchierate" che spesso facciamo nelle varie riunioni interne oppure, perchè no, alla macchina del caffè... (infatti non vi nascondo che un nome proposto ai video era Microsoft Cafè... ma era troppo simile ad una nota trasmissione di cui io sono un fan sfegatato :-)

Iniziamo l'avventura con un'intervista ad Alessandro Huber, CTO di Microsoft Services, il quale ci parla del ruolo di CTO, del modo di approcciare i progetti da parte di Microsoft Consulting e soprattutto dell'esperienza e le sfide incontrate durante i lunghi mesi di lavoro che hanno portato alla creazione di uno dei maggiori progetti in italia : CFF (Connected Financial Foundation) per soluzioni bancarie che Microsoft Corporation sta trasformando in una solution da distribuire su tutti i mercati world-wide.

Vista anche la parte introduttiva dei servizi questo video dura un po' di più (circa una mezzoretta) di quello che sarà la durata media dei video MSDN Talks (10-20 minuti). I video di MSDN Talks saranno di due tipi : architetturali e di sviluppo. I primi, come quello presentato oggi, parleranno di esperienze nel disegno di soluzioni complesse mentre quelli relaviti allo sviluppo daranno la voce ai senior developers che hanno implementato e portato in produzione le soluzioni.

Alla linea "classica" di MSDN Talks si aggiungerà anche la versione "LIVE" dove verranno intervistate persone riconosciute particolarmente esperte di tecnologie Microsoft durante i vari eventi in giro per l'italia (e non solo).

Non mi resta che augurarvi buona visione...

Il progetto CFF

Il CFF permette di realizzare una serie di moduli funzionali a livello infrastrutturale che consentano di realizzare una piattaforma finanziaria a livello enterprise e che al contempo contenga l’approccio architetturale service-oriented in modo da rendere flessibile e semplice ogni tipo di integrazione.

Il CFF è quindi un’infrastruttura applicativa modulare con le seguenti caratteristiche :

Piattaforma per la realizzazione di Smart Client e Web Client.
Piattaforma Multicanale a supporto dei diversi devices che potranno essere utilizzati oggi e in futuro.
Infrastruttura Modulare basata su SOA
Contenitore delle diverse applicazioni con condivisione del contesto
Supporto di servizi applicativi quali: transazioni, messaging, deployment e aggregazione di servizi.
Autenticazione, Autorizzazione e sicurezza in generale.
Ambiente per l’Orchestrazione dei processi di business.
Servizi di integrazione tecnologici ed applicativi.
Supporto all’analisi dei processi di business: Business Activity Monitoring.
Supporto per la realizzazione di applicazioni instrumentate, gestite e affidabili.
Metodologie basate su MSF (Microsoft Solutions Framework) implementato via Team System.
Sicurezza e affidabilità verificate durante tutto il ciclo di sviluppo della soluzione.

Alcuni link informativi sul CFF

http://www.key4biz.it/News/2007/06/01/Tecnologie/Finanza_e_IT_Microsoft_Italia_presenta_la_nuova_stategia_e_la_piattaforma_modulare_CFF.html

http://www.cwi.it/showPage.php?template=articoli&id=17739

--Mario

PS: un saluto particolare a Sandro che per anni ha avuto la pazienza di essere il mio capo e che da quando non lo è più è tornato ad essere sereno :-) :-) :-)

Una overview di Software Plus Services per architetti

mfontana — Fri, 15 Feb 2008 16:38:02 GMT

Stavo per pubblicare questo post quando mi sono accorto che Pietro e Giuseppe hanno scritto un post su S+S dove si chiedevano se l'equazione lineare S+S = 2S fosse vera!

Bene, proverò che l'equazione riportata è palesemente falsa :-) dimostrando al contrario il vero risultato, ovvero : S+S = 4S. Vediamo perchè :-)

Innanzitutto con Software Plus Services parliamo di una evoluzione nel modo di sviluppare, deliverare, gestire ed interagire con il software nei prossimi 5-10 anni. Una evoluzione che è già iniziata da alcuni anni ma che oggi si può declinare con precisione. Una evoluzione appunto, non una rivoluzione che coinvolge il mondo Consumer fino a quello Enterprise! Una domanda che spesso mi viene fatta quando presento questo argomento è se oggi sia già possibile sviluppare in modalità Software Plus Service. La risposta è sicuramente SI. Scopo dei mie prossimi post sull’argomento sarà proprio affrontare la questione soprattutto in ambito progettazione e sviluppo di soluzioni Software Plus Services oggi.

Prima di addentrarci nel pieno della discussione vediamo quali sono i principali fattori che hanno permesso questa evoluzione:

Connettività: la sempre crescente velocità di connessione verso internet non solo dei PC ma anche di qualsiasi device anche mobili.
Data Storage: disponibilità di storage sempre più capienti a prezzi abbordabili. Data storage sia dei PC/devices sia del massive data, ovvero lo spazio disponibile in rete.
Potenza computazionale: il costante aumentare della capacità computazionali dei PC e dei device in generale (es: PDA, smartphone, ecc…)

Questi sono i principali key drivers che hanno permesso e permetteranno nel futuro la nascita di una nuova generazione di software capace di fornire alle persone un nuovo livello di esperienza, interattività ed integrazione tra le persone, i device e le informazioni. Una evoluzione che mette al centro le persone e la loro collaborazione durante le attività lavorative e quelle “personali”. Questo nuovo modo di interagire con la tecnologia viene chiamata anche Digital LifeStyle ovvero come il nostro stile di vita si relaziona alla tecnologia in tutti i momenti della giornata.
Prima di spaventiamoci J… facciamo un esempio: 10 anni fa la posta elettronica era un mezzo di comunicazione usato prevalentemente nel mondo del lavoro tramite PC. Le persone che comunicavano tra loro, con le famiglie, con gli amici via email erano una piccola minoranza. Fino a 5 anni fa era difficile che la posta fosse usata anche quando le persone erano fuori ufficio, in viaggio. Con lo stesso device oggi si può gestire la posta dell’ufficio e quelle personali, condividere contatti e molto altro. Fino a 2-3 anni fa era difficile che questo tipo di “connessione” potesse comprendere anche la condivisione di fotografie e filmati, non solo tra telefonini ma anche su internet. Oggi con Windows Mobile 6 ed i servizi Live ad esempio è veramente banale fare una fotografia o un filmato con il cellulare o il PDA e inviare il contenuto digitale nella photo gallery all’interno del proprio blog!! In pochi minuti “tutto il mondo” può vedere le foto delle mie vacanze J. Stessa storia per l’ IM (Instant Messaging) sia pubblico (es: Messenger) sia inter-aziendale (es : Communicator) e tutte le esperienze di condivisione di informazioni e contenuti che questi strumenti mettono a disposizione sia dal PC che dai cellulari. Con gli esempi potremmo andare avanti veramente tanto. Se analizziamo questo trend solo dal punto di vista della user experience allora in realtà scopriamo che ha già un nome : Web 2.0.

Software Plus Services è molto di più! Indica COME trasformare questa user experience in sensazioni sempre nuove fornendo la libertà di essere sempre aggiornati solo sugli aspetti che ci interessano gestendo e condividendo i propri dati con amici e colleghi abbattendo le barriere e gli ostacoli tecnologici.

Volendo fare un distinguo tra privati ed aziende possiamo sintetizzare :

Per gli utenti privati significa semplificare l’uso dei propri digitial tools. Questo permette una innovazione in termini di esperienza nella propria digital lifestyle che cambierà radicalmente il modo in cui le persone accedono e scambiano informazioni.
Per le aziende S+S offre la possibilità di migliorare l’efficienza e diminuire i costi offrendo nuove opzioni in cui le applicazioni possono essere deliverate e integrate tra loro.

Come detto Software Plus Services è un argomento molto vasto che spazia un po’ in tutti i settori. Nei miei post mi concentrerò soprattutto sugli impatti e sulle prospettive future per le aziende.

Per capire al meglio i principi architetturali che sorreggono l'acronimo S+S (Software Plus Services) partiamo da un concetto "di base : il servizio. Purtroppo il termine in questi anni ha subito (e sta subendo ancora) un overloading sempre maggiore e questo a mio avviso è alla base di molta confusione nelle architetture. Si parla di Service Orientation, di SOA, EDA, SaaS, Web 2.0… Tutti acronimi, architetture che hanno come minimo comune denominatore il servizio ma con accezioni e spesso filosofie ben diverse:

SOA e EDA: principi architetturali che permettono di disegnare e sviluppare soluzioni componibili e usufruibili.
SaaS : architettura orientata al delivery di servizi dove in scenari internet significa spostare le attività di operations dall'enterprise all'hoster. In questo contesto parliamo di architetture single/multi-tenancy.
Web 2.0: non è tanto l'aspetto tecnologico ma la user-experience rispetto alle informazioni. L'utente non è più passivo alle informazioni ma decide ed "assembla" parti per formarsi il proprio mondo (il famoso mash-up). I più fantasiosi lo hanno chiamato addirittura il rinascimento del Web. Anche in questo contesto troviamo i concetti di assemblare funzionalità che guarda caso sono erogate da... servizi.

Questi sono 3 differenti aree dell'innovazione dei servizi. Microsoft chiama l'integrazione di questi mondi Software Plus Services o più semplicemente S+S ovvero l'unione del software locale su qualsiasi device con quello dei servizi indipendentemente dalla loro declinazione. S+S può essere considerato come un continuum tra le soluzioni software e i servizi di oggi e del futuro.

Partendo dai key drivers precedenti possiamo sintetizzare il concetto di Software Plus Services in questo modo:

S+S = PCs + Devices + Software On-Premise (enterprise) + SaaS (online)

abbiamo quindi l'integrazione di 4 Scenari... ovvero :

S + S = 4Scenari
C.V.D. :-)

Stiamo quindi parlando di convergenza tra persone, devices, informazioni e performance/sicurezza. Una convergenza che permette alle persone di accedere ai propri dati (personali o aziendali) sia quando si trovano all’interno dell’azienda, in viaggio o in vacanza, online oppure offline. Le aziende hanno quindi la possibilità di raggiungere un livello di flessibilità e libertà scegliendo quale sia il modello più adatto alle proprie esigenze : on-premise (in casa), on line oppure un mix potendo nel futuro modificare questa integrazione tra servizi. Questa libertà può essere tale solo tramite una piattaforma applicativa la quale grazie ai principi di application composition sia in grado di integrare servizi interni all'azienda con servizi esterni erogandoli in modo naturale verso un presentation che sarà sempre più articolato. Non una rivoluzione ma una evoluzione... appunto :-)

Vediamo come questa integrazione stia già avvenendo:

Desktop : Sempre di più l'utente del PC utilizza anche devices come smartphone o PDA interagendo con servizi live e in alcuni casi con servizi intranet.
Enterprise : anche nell'Enterprise c'è una certa integrazione con dispositivi mobili. Oggi l'integrazione con i servizi live è più orientata alla user-experience rispetto al middle-tier (area di forte espansione nei prossimi anni). Gli utenti saranno sempre più abituati a scenari Web 2.0 dove sono al centro delle informazioni e ai meccanismi di aggregazione delle informazioni stesse. Nel tempo richiederanno lo stesso tipo di experience anche all'interno dell'azienda. Infatti stiamo assistendo ad una prima integrazione tra il mondo strutturato tipico dei processi di business server side con il mondo destrutturato tipico del modo di lavorare delle persone. Maggiori info qui.
Online : sempre più servizi (gratis e a pagamento) supportano la richiesta sempre maggiore di user-experience legata al Web 2.0. Gli utenti si stanno evolvendo! Siamo agli inizi della così detta Consumerization ovvero le aziende iniziano ad appoggiarsi su servizi on-line piuttosto che applicazioni on-premise (installate e gestite in casa).
Devices : sempre più piccoli e potenti. Danno il meglio quando tramite la banda larga si possono integrare con i servizi on-line. I servizi sono accedibili sia dai PC che dai device anche se in quest'area il lavoro di integrazione è ancora molto grande!

Tassonomia dei servizi

Possiamo suddividere i servizi in tre famiglie a seconda delle proprie caratteristiche:

Building Blocks Services : I building block services sono dei servizi consumabili principalmente da sviluppatori. Servizi che richiedono una certa competenza tecnica per essere integrati in un sistema funzionale. Ad esempio BizTalk Services, Silverlight Streaming services. Li potremmo chiamare le API del futuro ?? :-)
Attached Services : Questi servizi sono pensati come "appendice", estensioni ad altri servizi. Presi da se hanno poco valore e forse significato. Esempi di Attached Services sono : Forefront Services (come descritto prima) , Windows Live OneCare, gli stessi XBOX Lives Services che estendono le funzionalità dei giochi.
Finished Services : come dice il nome, servizi che . Esempi : Office Live Small Business, Dynamics Live CRM, Office SharePoint Online ecc...

Microsoft Branding

La tassonomia dei servizi non va confusa con i due brand che troverete sempre più presente in casa Microsoft : Live e Online. Questa suddivisione è puramente marketing, di posizionamento! I servizi Live hanno come target il mondo consumer, piccolissime realtà commerciali e virtual workgroups ed offrono funzionalità di Entertainment, comunicazione e produttività individuale. I servizi Online invece sono pensati per il mondo Business dove è richiesta una certa flessibilità, SLA e che spesso hanno già una propria infrastruttura IT.

Integrazione e libertà di scelta

Se dovessi riassumere il concetto di S+S con uno slogan non avrei dubbi : Integrazione e Libertà di scelta per il futuro.
Vediamo perché. Integrazione per i i 4 scenari appena elencati. C'è molta innovazione all'interno di ognuno di queste 4 aree. Molti dei problemi che l'intera industria dell' IT cercherà di risolvere nei prossimi 5-10 anni riguarderà proprio l'integrazione di questi mondi. Per libertà invece intendo la possibilità di scegliere quali servizi utilizzare ma soprattutto in che modalità. Questo significa che dal privato, alla piccola azienda, alla enterprise si avrà la libertà di scegliere chi gestirà i servizi dall'hardware dei server fino alle operations (la gestione).

L'esempio più immediato è rappresentato da Exchange Server 2007, un software già sviluppato in modalità S+S. Partiamo dalla funzionalità: l'utente può scegliere di integrarsi ai servizi di Exchange con uno o tutti i canali :Outlook, OWA, Outlook mobile oppure tramite il nuovo Voice Access. Exchange stesso può essere "installato in casa" ovvero on-premise oppure appoggiandosi ad un provider (hosted) a seconda delle proprie necessità tra cui, non ultimi, gli skill di gestione ed i costi di manutenzione. Infine ad Exchange possono essere integrati dei servizi ad-hoc come ad esempio ForeFront per la sicurezza e il filtering indipendentemente dal modello di deployment scelto...

Questo cosa significa? Significa aver sviluppato un software (in questo esempio Exchange) che può essere deployato come applicazione e come servizio. Inoltre tale software è capace di integrarsi a sua volta con servizi aggiuntivi (interni o esterni) erogandoli in modo naturale verso il presentation.
Alcuni servizi possono essere : Exchange online, Sharepoint online, Exchange hosted services...

Un altro esempio di prodotto che nel tempo si è trasformato abbracciando la filosofia di S+S è Office. Infatti rispetto alle prime versioni dove Office era un semplice prodotto di produttività individuale negli anni si è arricchito in un primo momento con servizi server-side come ad esempio Sharepoint, Exchange Office Communication Server. Successivamente si è integrato con i servizi Live come Office Live, Office Live Meeting,... Infatti, parlare di Office System oggi significa parlare di una soluzione capace di integrare software client multicanale, servizi server e servizi on-line. S+S appunto :-)

"Prospettive"

Software Plus Services può essere analizzato anche da quattro prospettive diverse a seconda dell'area di focalizzazione della propria azienda. Ovviamente non sono esclusive nel senso che una realtà potrebbe coprire anche più di una. L'area di Build ha come target principali le società di software (ISV). In questo contesto dobbiamo focalizzarci ad esempio sugli aspetti di progettazione single-multi tenancy, problemi di scaliabilità e best practices per l'isolamento dei servizi.Con Run si intendono gli Hoster dove abbiamo troviamo best practices sul service delivery e gestione della scalabilità. Consume si rivolge prevalentemente all'Enterprise e all'integrazione con architetture SOA/EDA con client ricchi multi device e servizi esterni. Infine, Monetize è rivolto prevalentemente a reference patterns per creare nuovi modi di erogare servizi e creare un ecosistema S+S integrato.

Approfondimenti su questi quattro temi li potete trovare qui, sul nuovo sito MSDN dedicato alle architetture S+S.

Oltre ai patterns che vengono pubblicati periodicamente su Patterns & Practices vediamo come Microsoft supporta questi 4 scenari da un punto di vista tecnologico.

Build

.NET 2.0/3.0/3.5
Visual Studio
Silverlight
PopFly
Guidance
Cloud Services

IIS7
Windows Server 2008
System Center
SQL Server
Silverlight Streaming

Consume

Integrazione

Biztalk Server
Internet Service Bus

Composition

Office Business Applications (OBA)

Monetize

AD Center
Software Protection
Licensing Services

Nei prossimi post vedremo come si progettano soluzioni S+S ed analizzeremo anche alcune soluzioni già realizzate.

--Mario

Due chiacchiere su SOA e EDA...

mfontana — Thu, 14 Feb 2008 00:17:06 GMT

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