Security & Architecture : SOA

Microsoft, Apache… un ossimoro??

mfontana — Sun, 07 Jun 2009 11:06:00 GMT

Innanzitutto prima di generare uno sciopone a qualcuno vi prego di notare la punteggiatura nel titolo di questo post !!! Microsoft VIRGOLA Apache e non Microsoft Apache :-) Nessuna paura quindi , non abbiamo acquistato Apache !!!! Però c’è da dire che questa notizia, come architetto, mi ha reso proprio contento. Alzi la mano (tanto vi vedo) chi di voi si è trovato almeno una volta nella situazione di far parlare del codice .NET con quello JAVA e/o PHP o viceversa? E tenga su la mano chi ha incontrato qualche “piccolissima” difficoltà nella configurazione e settaggi vari nei rispettivi ambienti !!!! Nessuno ?? ok allora questo post non fa per voi :-)

Diciamo che c’è stato un evento epocale… Microsoft partecipa alla keynote della conferenza JavaOne!! Infatti durante la conferenza JavaOne Steven Martin - Senior Director, Developer Platform Product Management – e Aisling MacRunnels - Sun Vice President- hanno annunciato durante la keynote che Sun parteciperà attivamente al progetto open-source Stonehenge inizialmente creato da Microsoft, WS02, University of Moratuwa, Progress Software, Red Hat e Eviware. In particolare Sun si occuperà della realizzazione Java/Metro della soluzione StockTrader.

Microsoft (anche se molti non lo sanno) ha partecipato e sta partecipando a molti progetti open source ma questa è la prima volta che Microsoft partecipa come code contributor in un progetto Apache!!

Lo scopo di questo progetto è nobile : realizzare in concreto degli scenari di interoperabilità e di best practices tra applicazioni e web services sviluppati su stack tecnologici diveri. Come dissi in questo mio post “non basta avere delle specifiche standardizzate per realizzare veramente degli scenari di interoperabilità” (sintetizzato) !!! I motivi sono molteplici : non tutti i vendor implementano le medesime specifiche anche se standardizzate, non sempre è chiaro come configurare i vari ambienti e prodotti, spesso ci sono delle piccole differenze in termini di serializzazione, encoding che se non gestite possono rendere difficile la realizzazione del progetto…

Per questo motivo il progetto Stonehenge realizza delle applicazioni di esempio basate su stack Java, .NET, PHP ma anche Python e Ruby in grado di interoperare utilizzando un set comune di specifiche standard definte dal W3C e OASIS. Stiamo parlando in prevalenza di comunicazioni basate sugli standard WS-*. I vari sorgenti li potete trovare nel repository di stocktrader :

--Mario

Ci vediamo a ROMA??

mfontana — Fri, 06 Feb 2009 20:41:04 GMT

Il 16-17-18 Marzo a ROMA si tiene la prima edizione della conferenza BASTA! Italia. La più prestigiosa conferenza sullo sviluppo .NET tedesca sbarca in Italia !!

Il 17 mattina terrò una sessione dal titolo : Make your old applications SOA-aware with Web Services API. From Windows XP/2003 to Windows 7/2008 R2.dove parlerò della nuova architettura per i Web Services presenti nelle prossime versioni del sistema operativo Windows 7 e Windows Server 2008 R2. Sarà una sessione di livelllo 400 (Expert) per dare un po’ di internals e capire come queste API unmanged possono essere utilizzate in architetture SOA e in particolare con servizi WCF/Asmx . Per dare un po’ di background sull’argomento nei prossimi giorni pubblicherò una serie di link introduttivi. Farò comunque i primi 10 min della presentazione una overview di massima.

L’abstract:

Con Windows 7 e Windows Server 2008 R2 il sistema operativo si arricchisce di nuove API native (WWSAPI – Windows Web Services API) che permettono di estendere le applicazioni unmanaged verso le architetture a servizi.Analizzeremo le ragioni di queste nuove API, l’architettura, le possibilità di interoperabilità con il mondo .NET e Java, e i principali standard WS-* di riferimento implementati.Tramite varie demo scorreremo i principali scenari di utilizzo evidenziandone i pro e i contro.

--Mario

Application Architecture Guidance V2.0

mfontana — Wed, 01 Oct 2008 18:09:01 GMT

Il 25 Settembre è stato pubblicato il progetto della versione 2.0 della Application Architecture Guidance da parte del gruppo Patterns & Practices. Attualmente il progetto è in divenire (anzi diciamo che siamo ancora nelle fasi iniziail) ma sfogliando la struttura del (futuro) documento si capisce che sarà di grande interesse per gli architetti. Il documento parte dall'esperienza maturata in questi ultimi anni nella realizzazione di soluzioni applicative enterprise nelle più disparate architetture applicative partendo dal client/Server, al Component-Based Architecture , Data Centered , Distributed Architecture ,Layered Architecture, SOA fino ai nuovi paradigmi S+S /SaaS/ PaaS.

Questa è la megamappa dalla guidance :

con particolare enfasi su:

Autenticazione e autorizzazione.
Caching e gestione dello stato.
Communication
Composition
Concorrenza e transazioni
Configuration Management
Coupling e Cohesion (ovvero come suddividere in layer le applicazioni e come gestire il raggruppamento dei componenti/servizi :-))
Data Access
Exception Management
Logging e Instrumentation
User Experience
Validazione
Workflow

Queste sono le architetture prese in considerazioni:

Mobile

RIA

Rich Client

Service

Web Applications

Quando?

--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 :-) :-) :-)

Autenticazione nelle comunicazioni : sicurezza a livello di canale

mfontana — Sat, 29 Mar 2008 14:34:00 GMT

Quando ci troviamo a progettare la forma di autenticazione nelle architetture Service-Oriented dobbiamo considerare vari aspetti relativi allo scenario.

L’identificazione dell’utente che sta compiendo una determinata operazione è alla base di ogni sistema di sicurezza.

Indipendente dal modello di autenticazione utilizzato, il processo di riconoscimento dell’utente prevede la definizione di un protocollo di autenticazione end to end tra i vari (spesso due, ma non è detto) attori della comunicazione a livello di sistema o applicativo per garantire il riconoscimento dell’utente. Il protocollo di autenticazione definisce, quindi, le modalità con le quali il servizio riconosce il chiamante.

Una comunicazione tra due servizi (end to end) costituisce l’elemento base della classica catena di chiamate a cascata tipiche degli scenari complessi. Una volta stabilite le modalità di autenticazione, il processo di riconoscimento dell’utente deve implementare un ben determinato modello di autenticazione per consentire al servizio chiamato di ottenere il corretto contesto di sicurezza (security context) del chiamante, indipendentemente dal flusso di chiamate e dalla posizione del servizio all’interno della catena di chiamate stesse. Al servizio chiamato a sua volta può utilizzare nel modo corretto le informazioni messe a disposizione dal modello utilizzato per realizzare le politiche di sicurezza necessarie.

Le modalità di autenticazione, come detto, definiscono il protocollo con cui il chiamante fornisce al servizio le informazioni di sicurezza per il riconoscimento dell’utente. La scelta della modalità di autenticazione da utilizzare è condizionata da vari fattori: tipo di applicazioni, modalità di colloqui tra chiamante e servizio, piattaforma utilizzata,….Le modalità di autenticazione offrono caratteristiche diverse dipendenti dal livello a cui vengono implementate. In generale esistono tre grandi famiglie di modalità di autenticazione:

a livello di canale di comunicazione.
a livello applicativo.
a livello di messaggio (anche di infrastruttura applicativa).

Sicurezza a livello di canale

La modalità basata sulla sicurezza a livello di canale di comunicazione utilizza il canale di trasporto tra i due end point della comunicazione, per lo scambio delle informazioni necessarie al riconoscimento dell’utente.

Figura 1: modelli di autenticazione a livello di canale di comunicazione

Il protocollo di autenticazione utilizzato in questo caso è strettamente dipendente sia dal canale di comunicazione utilizzato che dalla sicurezza supportata dalla piattaforma.

L’autenticazione è, quindi, trasparente alle applicazioni e configurata a livello di sistema in moda da consentire al chiamante e servizio di instaurare il corretto protocollo per lo scambio delle informazioni.

I vantaggi di questa modalità sono essenzialmente nella semplicità di utilizzo (da parte delle applicazioni) e nella sicurezza offerta, definita dallo stesso canale di comunicazione utilizzato.

Di contro, però la sicurezza di canale, avendo come unica granularità applicabile l’intero messaggio, è molto rigida e non consente di applicare politiche di sicurezza su singole porzioni di messaggio.

Quando usarla

La modalità di autenticazione a livello di canale (trasporto) è semplice e generalmente adeguata in scenari dove i meccanismi di trasporto e i partner della comunicazione sono fortemente controllati.

I maggiori vincoli sono:

basando tutto a livello di trasporto, l’autenticazione è fortemente dipendente dalla piattaforma utilizzata e dai servizi di sicurezza forniti da questa,
l’autenticazione non dipende dalla tipologia di messaggio/richiesta effettuata, non entra nel merito del formato, dei dati e non distingue singole porzioni di messaggio,
l’autenticazione è applicata agli end point della comunicazione senza la possibilità (se non supportata dai meccanismi di sicurezza della piattaforma utilizzata) di fluire in una catena di richieste e tra intermediari.

Nel prossimo post analizzeremo l'autenticazione a livello applicativo....

--Mario

Video della conferenza : SOA & Business Process

mfontana — Thu, 27 Mar 2008 10:00:29 GMT

Si è da poco conclusa la Microsoft 2007 SOA & Business Process Conference.

qui potete trovare alcuni video veramente interessanti per gli architetti registrati direttamente dalla conferenza. Ho elencato alcuni video in ordine di (mia) preferenza :-)

Keynote: Welcome and Introduction: Changing the World with Microsoft SOA

SOA Governance and the Microsoft Ecosystem

Service Lifecycle Management: Addressing the Challenges of the Provider/Consumer Relationship

Using Visual Studio Team System to Deliver the Right Services at the Right Time

Enabling the Agile Enterprise: Building a Common Roadmap for Business and IT with a SOA Maturity Model (SOAMM)

Web Services Monitoring using Microsoft Systems Center Operations Manager 2007

How to Turn and Upgrade into SOA

People Ready Processes: Enabling Mainstream Adoption of BPM

Integrating the Enterprise - Best Practices in Enterprise BizTalk Server and HIS Server Implementations

Building HIPAA Solutions with BizTalk Server2006 R2

Visio as Business Process Analysis Tool

Microsoft Dynamics CRM: SOA Platform for Building Custom Business Applications

Web Service Software Factory: Modeling Edition

mfontana — Sun, 02 Mar 2008 15:30:27 GMT

E' uscita da poco la versione per Visual Studio 2008 della Service Factory con relativi link agli Hands-on Labs.

Questa service factory è un insieme di risorse per architetti e developers per realizzare soluzioni a servizi seguendo una serie di design patterns e architectural best practices ben definiti. La soluzione comprende principalmente della documentazione con relativo codice sorgente e tre DSL (Domain Specific Language) per la modellazione della soluzione : Service Contract Model, Data Contract Model, ed l' Host Model.

L'architettura della software factory è completamente estendibile ed adattabile alle proprie esigenze di progetto. Personalmente quando ero in Microsoft Consulting le ho usate spesso, magari anche solo come riferimento e aiuto nell'impostazione di alcune parti di progetto. Rappresentano comunque materiale importantissimo per chiunque debba progettare delle soluzioni di classe Enterprise.

Dietro le quinte la Service Factory utilizza le estensioni del GAX/GAT e del DSL Toolkit oltre a varie tecniche per il model validation e il code generation.Nella figura sottostante è rappresentata la dipendenza delle varie tecnologie utilizzate nella Service Factory

</Mario>

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