Come prevedevo, Microsoft non è rimasta fuori a lungo dal mercato delle SOA, rilasciando in particolare una soluzione ESB (Enterprise Service Bus) che punta tutto sul middleware di integrazione della Microsoft, ovvero il potente BizTalk Server 2006. Sul sito MSDN per architetti è scaricabile una presentazione video, creata con Producer per PowerPoint e dal non trascurabile peso di 45 MB, che illustra un'implementazione reale, attuata integrando i sistemi IBM di Kaiser Permanente, un operatore statunitense del settore sanitario.

Per cominciare, viene fatto notare come abbiamo, ad oggi, differenti definizioni su cosa sia un ESB (Enterprise Service Bus): se Fiorano pone l'accento sulle interfacce, il Burton Group lo definisce un middleware di integrazione che supporta sia protocolli MOM (Microsoft Operations Manager) che Web Services; una definizione più completa ci viene da Sonic Software, che prende in considerazione l'integrazione della messaggistica, dei Web Services, della trasformazione dei dati e del routing intelligente (è da considerare come il broker proprietario costituisca uno dei differenziali dell'offerta Sonic Software); il Gartner Group considera in particolare l'aspetto del disaccoppiamento; fino ad arrivare alla provocatoria affermazione di Bob Sutor dell'IBM: Se avete WebSphere MQ, e gli altri broker e server di integrazione di IBM WebSphere, avete un ESB (Enterprise Service Bus).

La definizione di un ESB (Enterprise Service Bus) che dà la Microsoft comprende il brokering, la trasformazione e la validazione dei messaggi, la funzione di adaptation fra differenti applicazioni, e l'orchestrazione dei servizi. La casa di Redmond vede anch'essa l'ESB (Enterprise Service Bus) come il cuore di un'infrastruttura Service-Oriented che comprende, altresì, un registro e la gestione dei servizi, ed un framework trasversale per la sicurezza. La comunicazione fra provider e consumer di servizi è basata, naturalmente, su HTTP/SOAP e su Windows Communication Foundation, ma anche su JMS (Java Message Service), tramite uno stub JAX-RPC, l'API di WebSphere MQ e l'IBM Message Service Client for .NET, meglio noto come XMS.NET. Vediamo un esempio di registro dei servizi basato su UDDI, ed un sistema di monitoraggio degli SLA (Service Level Agreements), che si integra con MOM (Microsoft Operations Manager) e con la famiglia IBM Tivoli.

Nel variegato panorama dei competitor (che comprende, fra gli altri, Sonic Software, Sun Microsystems, Oracle, IBM, IONA, Cape Clear, Fiorano, TIBCO Software, BEA) la Microsoft ha annunciato la ESB Guidance for Partners, pensata come una serie di linee-guida architetturali, un ESB Core Engine ed un framework di provisioning per BizTalk Server 2006. Vediamo, in particolare, le tre principali funzioni di intermediazione fornite dall'ESB Core Engine, ovvero la trasformazione dinamica ed il routing dei messaggi e la gestione delle eccezioni, che si integra con le prime due. I due meccanismi principali di trasformazione dei messaggi comprendono l'uso nativo di agenti, e l'invocazione di Web Services. Il routing prevede una serie di componenti riutilizzabili per poter allocare a runtime gli estremi (endpoint) della comunicazione, e si occupa di gestire la traduzione fra differenti protocolli. La gestione delle eccezioni, infine, è basata su un meccanismo publish/subscribe di messaggi, per il quale sono fornite famiglie di handler generici.

Dopo qualche accenno alla gestione del flusso di controllo, si passa al cuore della presentazione, ovvero la demo dell'ESB Core Engine, che dura un quarto d'ora circa. L'ESB viene gestito tramite un client WinForms, che implementa una serie di Use Case; la prima ed importante scheda del client è il Message Generator tramite il quale vengono gestiti il Processing, la Transformation, il Routing e l'Endpoint Configuration dei messaggi; ogni voce è implementata tramite un'apposita classe nel namespace Microsoft.BizTalk.ESB. Le altre tre schede forniscono altrettanti servizi: il Resolver, la Transformation e la Fault Recovery. I messaggi di risposta vengono caricati direttamente dall'XML, ma alcuni di essi vengono visualizzati dallo standard output grazie a DebugView, mentre il registro dei servizi può essere consultato da un comune browser tramite UDDI, usato dal Resolver Service. Il Transformation Service è in grado di trasformare un messaggio fornito in input XML alla WinForm tramite un Mapper standard di BizTalk Server 2006, implementato anch'esso sotto Microsoft.BizTalk.ESB. Viene poi generata un'eccezione, persistita in un file XML. Infine, viene fatto vedere il portale di management dell'ESB, implementato come un sito SharePoint, che beneficia delle capacità di reporting di questo prodotto. E' quantomeno divertente la parte in cui non è possibile aprire un messaggio XML con InfoPath, a causa di un errore di validazione nello schema XSD.

Nelle parti finali della presentazione viene (brevemente) discusso come estendere l'engine di base per implementare i servizi di orchestration e provisioning dei servizi; si tratta di operazioni ben documentate, ma che richiedono uno sviluppo custom, come quello effettuato per Kaiser Permanente. Si parla anche, sempre di passaggio, dell'architettura clusterizzata e del sistema per la raccolta delle metriche di servizio, che sono stati implementati usufruendo delle caratteristiche standard di BizTalk Server 2006. Per chi volesse cominciare a sperimentare è disponibile, su richiesta, un Developer SDK che comprende una Developer's Guide, una virtual machine con l'ESB Core Engine ed applicazioni di esempio.