SOA, BizTalk ha il suo ESB

Di Paolo De Nictolis

Con il rilascio della versione di novembre 2007 della ESB Guidance, frutto del gruppo di progetto "Patterns & Practices" guidato da Marty Wasznicky oltre che del lavoro collaborativo svolto sul codice sorgente tramite il CodePlex, le caratteristiche BPM (Business Process Management) di BizTalk Server 2006 R2 si arricchiscono di capacità di gestione delle SOA (Service-Oriented Architectures), dando al prodotto di integrazione applicativa Microsoft le caratteristiche di un ESB (Enterprise Service Bus) in grado di gestire servizi aziendali data-driven, lascamente connessi, geograficamente distribuiti e on-demand.

Assieme al supporto nativo per EDI (Electronic Data Interchange), AS/2 ed RFID (tanto importante quest’ultimo da essere stato fornito come server separato, con due cartelle dedicate, per le piattaforme x86 ed x64, nel disco di installazione, oltre ad un’apposita voce nella splash screen di setup), oltre che per Windows Vista, Office 2007 e tecnologie .NET 3.0 come Windows Workflow Foundation e Windows Communication Foundation, l’apertura verso il mondo delle SOA contribuisce a fare della R2 di BizTalk Server 2006 un centro di integrazione dell’informazione aziendale che risponda alle crescenti sfide in tema di gestione dell’informazione, in un panorama che si presenta sempre più mutevole e suddiviso su un numero crescente di mercati e sedi.

Nelle prossime pagine cominceremo col chiarire i concetti di SOA ed ESB, buzzword molto attuali del mondo IT il cui significato non è però sempre ben individuato, per poi illustrare cosa offre l’ESB Guidance e mostrarne qualche esempio d’uso.

Una breve panoramica su SOA ed ESB
ESB Guidance: cosa comprende
Installazione
Scenari ed esempi d’uso: Itinerary e UDDI Service
Amministrazione con l’ESB Management Portal
Conclusioni

Quand’è che possiamo parlare di SOA? L’idea di una architettura orientata ai servizi ha dato luogo a molti fraintendimenti, generando situazioni limite come quelle di vendor che hanno apposto un marchio SOA-ready a prodotti che facevano uso delle tecnologie Web Services, sicuramente pervadenti in quest’ambito, ma assolutamente non identificabili con una Service-Oriented Architecture, che prescinde persino dall’uso dei Web Services. In effetti, le architetture orientate ai servizi rispondono a domande di cooperazione applicativa in ambienti distribuiti ed eterogenei pressanti da parte del mondo IT, che hanno generato in passato fiorenti linee di prodotto (spesso afferenti al cappello dell’EAI, o Enterprise Application Integration) che non hanno però mai risolto veramente il problema; ma proprio perché quest’esigenza è così fortemente sentita, il mercato ha risposto rapidamente con una serie di prodotti, prima che i fondamenti stessi di questa disciplina venissero formalizzati.

Il punto di vista di Microsoft in materia è espresso in maniera concisa nel documento “Learn about Service Oriented Architecture”, mentre per chi vuole approfondire sull’argomento è stato edito un intero numero dell’Architecture Journal, oltre a due testi liberamente scaricabili in formato .pdf (puoi scaricare qui il primo e il secondo testo). Una buona fonte è anche il bel testo “Pro WCF: Practical Microsoft SOA Implementation”.

In risposta all’esigenza di integrare applicazioni, mantenendo però tempi rapidi di realizzazione, il paradigma SOA prevede la realizzazione di processi di business lascamente accoppiati per lo scambio di informazioni. Le tecnologie Web Services si sposano naturalmente con questo paradigma, anche grazie al loro uso ormai pervasivo come wrapper di servizi esposti da applicazioni legacy; l’approccio SOA prescinde però completamente dalla tecnologia utilizzata, e manterrebbe tutta la sua utilità se invece di scambiare informazioni sotto forma di buste SOAP su protocollo HTTP utilizzassimo file in formati EDI che viaggiassero su reti proprietarie. Le SOA, in ultima analisi, sono un fattore abilitante per la creazione delle cosiddette composite applications, né è da trascurare l’impulso che possono dare alla crescente necessità del software-come-servizio.

Dagli obiettivi che si vogliono conseguire attraverso la creazione di una SOA discendono naturalmente quelli che la prassi vuole ne siano le componenti più caratterizzanti. Un’architettura in grado di scambiare informazioni fra i servizi esposti dalle varie applicazioni aziendali, che spesso assommano a varie migliaia, avrà bisogno di un registro con facility di ricerca di tali servizi (anche qui, lo standard UDDI fornisce una naturale, ma non esclusiva, risposta); di un engine per l’attivazione e il coordinamento dei servizi o, nel gergo SOA, per la loro orchestration; e di un business rules engine onde far sì che l’interazione dei servizi obbedisca a policy predefinite. Altre componenti, quali il motore di provisioning dei servizi, la gestione degli alert e delle eccezioni, il monitor di sistema che spesso assume la forma di un data warehouse, sono anch’essi strumentali alla complessità di gestione ed alla fornitura di risorse on-demand.

Ugualmente, la definizione di Enterprise Service Bus (ESB) richiede qualche precisazione. Nel corso dei primi anni di diffusione, nonostante si stia parlando di un artefatto tecnologico invece che di un paradigma architetturale, sono state coniate varie definizioni: c’è chi ha posto l’accento sulle interfacce verso i sistemi da far colloquiare, chi sul disaccoppiamento degli applicativi; c’è chi l’ha definito come un middleware di integrazione che supporta sia protocolli MOM (Message-Oriented Middleware) che Web Services; chi, con una definizione più completa, ha preso in considerazione l'integrazione della messaggistica, dei Web Services, della trasformazione dei dati e del routing intelligente (per quanto molto spesso l’ESB abbia finito per essere la soluzione di routing proprietaria del vendor di turno, corredata da qualche modulo applicativo); fino alla provocatoria affermazione di chi voleva che l’ESB fosse l’insieme del middleware di messaggistica e dei broker e server di integrazione della propria linea di prodotto.

Un (bel) tentativo di arrivare ad una definizione comune è il testo “Enterprise Service Bus” di David A. Chappell, lo stesso autore di “Introducing BizTalk Server 2006 R2”; una concisa definizione la fornisce anche Microsoft. Detta definizione comprende il brokering, la trasformazione e la validazione dei messaggi, la funzione di adaptation fra differenti applicazioni, e l'orchestrazione dei servizi. Microsoft altresì vede anch'essa l'ESB come il cuore di un'infrastruttura Service-Oriented che comprende, inoltre, un registro e la gestione dei servizi, e un framework trasversale per la sicurezza.

In buona sostanza, un ESB gestisce lo scambio di informazioni fra applicazioni come scambio di messaggi, effettuando ricezione, elaborazione e consegna degli stessi, sulla base di metadati associati al messaggio che definiscono l’insieme di operazioni da effettuare sul messaggio. Il modello di scambio dei messaggi per l’ESB Microsoft deriva naturalmente dal MOM (Message-Oriented Middleware) disponibile in BizTalk Server 2006 R2 (Figura 1). I servizi di routing del messaggio sono forniti dal componente adapter, laddove eventuali elaborazioni sono compito delle pipeline e dei componenti di data mapping.

Una buona introduzione a questi componenti è il white paper di Chappell precedentemente citato. È il caso, comunque, di ricordare che a partire dalla versione 2006 R2, gli adapter vengono implementati come WCF channels e che è disponibile, allo stato di TAP (Technology Adoption Program), un BizTalk Adapter Pack che comprende gli adapter basati su WCF per SAP, Siebel e Oracle. Questo prodotto è stato creato utilizzando il WCF LOB Adapter SDK, un framework generico per la creazione di adapter per applicazioni Line-of-Business; in effetti, gli adapter creati con questo framework possono essere usati da qualsiasi applicazione .NET, senza che sia necessario (per quanto consigliato) installare BizTalk Server.

Dovendo conoscere solo l’insieme di operazioni che è possibile applicare, un ESB favorisce l’accoppiamento lasco fra applicazioni; inoltre, i suoi componenti possono essere deployati in maniera incrementale, favorendo l’adozione di questo strumento in step successivi. Poiché un ESB effettua sostanzialmente un deposito/prelievo di messaggi in uno store, costituisce a tutti gli effetti un’implementazione del pattern State Machine.

Figura 1: il modello di scambio dei messaggi usato dal MOM (Message-Oriented Middleware) di BizTalk Server 2006 R2.

La storia pubblica dell’ESB Guidance parte dal dicembre del 2006, con una presentazione video che illustrava un'implementazione reale su sistemi IBM di Kaiser Permanente, un operatore statunitense nel settore sanitario. In quest’implementazione la comunicazione fra provider e consumer di servizi è basata, naturalmente, su HTTP/SOAP e su Windows Communication Foundation, ma anche su JMS, tramite uno stub JAX-RPC, l'API di WebSphere MQ e l'IBM Message Service Client for .NET, meglio noto come XMS.NET. Vediamo all’opera un esempio di registro dei servizi basato su UDDI, e un sistema di monitoraggio degli SLA (Service Level Agreements) che si integra sia con Microsoft Operations Manager che con la piattaforma Tivoli di IBM.

Alla prima virtual machine con Windows Server 2003, una serie di linee-guida architetturali, un ESB Core Engine e un framework di provisioning per BizTalk 2006, hanno fatto seguito le CTP sottoposte al vaglio della comunità sul CodePlex. Se, dopo aver installato la CTP di novembre 2007 della ESB Guidance, diamo un’occhiata alla cartella di installazione, oltre alla documentazione ed al codice sorgente troveremo due categorie di file. La prima è quella degli assembly nella cartella bin, corredati dagli eseguibili per il deployment di regole di business e per la pubblicazione UDDI, che avviene tramite servizi WCF. La seconda è quella degli installer MSI per l’ESB Core Engine, la gestione delle eccezioni e la messaggistica JMS a scopo di integrazione, corredati dal setup di un’applicazione di esempio, Global Bank, che mostra l’uso del servizio di trasformazione dei messaggi. Sono presenti due famiglie di installer; quelli che terminano con _NOBINDING non effettuano il deployment dei file di binding fra porte logiche e fisiche di BizTalk.

Scendendo nel dettaglio, i servizi ed i componenti della ESB Guidance attuale possono essere raggruppati in sette categorie:

• Web services: vengono utilizzati per esporre i servizi interni dell’ESB

• Itinerary services: raccolgono gli agenti per la trasformazione e la consegna dei messaggi

• Itinerary on-ramps: ricevono i messaggi esterni utilizzando SOAP o WCF

• On-ramps: ricevono i messaggi esterni utilizzando una gamma di formati e trasporti che comprende http, JMS, WMQ, FTP, XML e flat file

• Off-ramps: implementano le porte per l’invio di messaggi, in tutti i formati e trasporti elencati nelle due categorie precedenti

• Exception Management Framework: è una delle novità di questa CTP e comprende il Web Service per la gestione delle eccezioni, l’API di gestione delle medesime, ed i componenti di pre-processing delle eccezioni, prima che siano inviate all’ESB Management Portal

• ESB Management Portal: un’altra novità di questa CTP, fornisce il provisioning dei servizi da registro, la mediazione delle eccezioni, i servizi di alerting e quelli di analisi, sfruttando naturalmente gli Analysis Services di SQL Server.

Molti di questi componenti e servizi sfruttano naturalmente le feature di BizTalk Server 2006 R2 come gli engine di Orchestration, Transformation e Business Rules, o il database Message Box (su quest’ultimo si veda anche la Figura 1). La Figura 2 mostra l’organizzazione dei componenti ESB Guidance nelle categorie su elencate, e la loro interazione con BizTalk 2006 R2.

Figura 2: i componenti della ESB Guidance e la loro interazione con BizTalk Server 2006 R2.

Altre novità della CTP di Novembre 2007 comprendono due nuovi Web Services Itinerary e Resolver, con i relativi esempi d’uso; un’implementazione del pattern Scatter/Gather e il logging centralizzato degli eventi. Sono stati incorporati anche due prodotti di terze parti: AmberPoint Embedded Nano Agent for BizTalk Server e SOA Software Management Point for BizTalk Server.

Entrambi i prodotti costituiscono delle estensioni a BizTalk che forniscono delle consolle di gestione dei servizi BizTalk, basate sul concetto di porta (ricevente o trasmittente di messaggi) tipico delle SOA e ben noto agli utenti di Windows Communication Foundation. AmberPoint e SOA Software sono solo due nomi nella vasta rete di partner che garantisce il supporto a questa soluzione; per chi volesse approfondire l’uso di queste due soluzioni, la sezione SOA Governance Integration della documentazione costituisce un ottimo riferimento.

In primo luogo dovremo naturalmente effettuare il setup di BizTalk Server 2006 R2, su Windows Server 2003 SP2, che dovrà includere BAM (Business Activity Monitoring; Figura 3), e .NET Framework 3.0. Occorrerà inoltre installare SQL Server 2005 SP2 con gli Analysis ed Integration Services, o SQL Server 2000 SP3 con DTS. Fra i componenti di Windows, è necessario installare UDDI. SharePoint Server per le attività portale e Infopath (versione 2003 o 2007) per il rendering delle eccezioni generate dall’Exception Management Framework sono due prodotti opzionali, ma ne consiglio l’uso.

Figura 3: il setup di BizTalk Server 2006 R2 dovrà includere i componenti BAM opzionali.

Sul fronte degli strumenti di sviluppo, dovremo installare Visual Studio 2005 SP1, tenendo conto che utilizzeremo C#, e C++ se dovremo personalizzare i componenti della pipeline JMS. Ove si prevedano attività di sviluppo di componenti per BizTalk Server 2006 R2 (nella stragrande maggioranza delle installazioni, a dire il vero), è opportuno installare prima Visual Studio 2005 e poi BizTalk, onde evitare di dover lanciare una seconda volta il wizard di setup per installare gli add-on e l’SDK per Visual Studio 2005 (Figura 4).

Figura 4: I tool ed i Progetti aggiunti a Visual Studio 2005 dal setup di BizTalk Server 2006 R2.

Alcuni degli esempi mostrano l’interazione con IBM MQSeries e richiedono l’installazione di BizTalk MQSeries Adapter oltre ad una serie di componenti terze parti. Una volta effettuata l’installazione di questi prodotti sulla macchina da utilizzare, dovremo procedere ad installare, prima l’Enterprise Library 3.1 e poi l’ESB Guidance. All’installazione dell’ESB Guidance è dedicato un intero capitolo della documentazione in formato CHM disponibile sul CodePlex.

Dopo aver effettuato il semplice setup dell’installer .msi, la prima cosa che dobbiamo fare è portarci nella cartella di installazione (di default C:\Program Files\Microsoft ESB Guidance 1.0 – November 2007), copiarne il file ESBSource.zip, ed estrarne il contenuto in una sottocartella; se vogliamo seguire gli esempi della documentazione, ci converrà posizionare i sorgenti contenuti nel file ZIP all’interno di C:\Projects\Microsoft.Practices.ESB. Dovremmo a questo punto avere due cartelle Keys e Source: la seconda contiene, sotto forma di soluzione Visual Studio 2005, i sorgenti necessari per compilare la ESB Guidance se decidiamo di non avvalerci dei binari creati dall’installer; la prima, una semplice Strong Name Key per la firma degli assembly generati.

I sorgenti comprendono, in particolare, i componenti core, la gestione delle eccezioni, il framework di interoperabilità con JMS, gli esempi, i servizi (disponibili sia come tradizionali Web Services che come servizi WCF) e le utility per la gestione di sorgenti COM di eventi, il deployment di business rules e la pubblicazione UDDI. Fra gli esempi spiccano la risoluzione dinamica dei percorsi, il nuovo servizio Resolver e l’implementazione del pattern Scatter/Gather, gli unici tre la cui complessità di gestione rende opportuno l’uso del BRE (Business Rule Engine) di BizTalk Server 2006 R2, oltre al portale di gestione, all’interoperabilità tramite JMS, alla gestione delle eccezioni ed ai servizi di trasformazione ed UDDI, senza contare il nuovo Itinerary.

Per chi decida di compilare l’ESB Guidance da essi, la documentazione fornisce dettagliate istruzioni sul come configurare i relativi progetti di Visual Studio 2005 in modo che il deployment punti al database BizTalkMgmtDb, oltre che su come creare e configurare il database per la gestione delle eccezioni, sugli utenti e application pool di IIS da creare, e sulla configurazione del server UDDI. Per chi voglia utilizzare gli installer .msi, invece, l’operazione si riduce ad usare l’ utility di deployment di BizTalk, BTSTask.exe, sul package Microsoft.Practices.ESB.CORE.msi, ed msiexec.exe sullo stesso package per registrare gli assembly nella GAC, per poi far ripartire i servizi di BizTalk. Questa operazione installerà gli assembly, le componenti pipeline e le classi helper della ESB Guidance (Figura 5); gran parte di essi li ritroveremo anche fra le Resources di All Artifacts .

Figura 5: BTSTask.exe installa l'ESB Guidance come applicazione di BizTalk Server 2006 R2.

Grazie al deployer di BizTalk ci ritroveremo con una cartella C:\Program Files\Generated by BizTalk\Microsoft.Practices.ESB, all’interno della quale troveremo due script: il batch .cmd serve a deployare (tramite, manco a dirlo, le tre utility citate in precedenza fra i sorgenti) il vocabolario delle regole di business per BRE (Figura 6), l’Event Log Source ed i modelli BAM dell’ESB Guidance (Figura 7), mentre con lo script VBS configureremo le directory virtuali di IIS necessarie (Figura 8). Fra le due operazioni, nella sottocartella SQL della cartella testè generata da BTSTask troveremo uno script SQL EsbExceptionDb_CREATE.sql con cui creeremo il database delle eccezioni.

Prima dell’esecuzione del .cmd di post-configurazione, occorre assicurarsi che i servizi NS$BAMAlerts e MSSQL$UDDI siano in esecuzione, e che SQLAgent$UDDI sia pronto a partire su richiesta. Dalla consolle di amministrazione di IIS, assicurarsi inoltre che l’utente di accesso ai servizi UDDI abbia sufficienti privilegi (dalle Proprietà dell’application pool MSUDDIAppPool) e impostare ASP.NET 2.0 per la relativa directory virtuale. Infine, dare un valore opportuno al timeout di registrazione dei servizi ed assicurarsi che gli Application Settings relativi all’UDDI Publisher puntino all’URL corretto nel file Microsoft.Practices.ESB.UDDIPublisher.exe.config nella cartella C:\Program Files\Generated by BizTalk\Microsoft.Practices.ESB\UDDI.

Figura 6: i vocabolari dell'ESB Guidance per il Business Rule Engine di BizTalk Server 2006 R2.

Figura 7: i modelli BAM (Business Activity Monitoring) dell'ESB Guidance.

Figura 8: i servizi Web dell'ESB Guidance; si notino in particolare i servizi WCF. La figura evidenzia anche gli Application Pool di IIS creati da BizTalk Server 2006 R2 e dall'ESB Guidance.

Dobbiamo a questo punto modificare sia il file di configurazione di BizTalk che il machine.config, onde far sì che la ESB Guidance possa usare i propri Resolver e Adapter Provider Framework per risolvere dinamicamente gli endpoint della comunicazione, effettuare trasformazioni sui messaggi ed impostare le proprietà degli adapter di uscita. Le impostazioni necessarie sono contenute nel file Microsoft.Practices.ESB.Context.PipelineComponents.config, che deve essere referenziato nel file di configurazione BTSNTSvc.exe.config nella root di installazione di BizTalk; tale file, in buona sostanza, contiene i riferimenti agli assembly usati per Resolver ed Adapter. Le modifiche a BTSNTSvc.exe.config aggiungono, in buona sostanza, una sezione di configurazione XLANG/s, l’implementazione Microsoft delle specifiche BPEL4WS, che imposta un nuovo isolated application domain con una serie di parametri disponibili a tutti gli assembly Microsoft.Practices.ESB.*. Il file di configurazione di BizTalk finale sarà simile al seguente:

<?xml version="1.0" ?>
<configuration>
    <configSections>
 <section name="xlangs"
 type="Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, 
Microsoft.XLANGs.BizTalk.CrossProcess" />
    </configSections>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="BizTalk Assemblies;Developer Tools;Tracking;Tracking\interop" />
        </assemblyBinding>
    </runtime>
    
    <system.runtime.remoting>
    
        <channelSinkProviders>
            <serverProviders>
<provider id="sspi" 
type="Microsoft.BizTalk.XLANGs.BTXEngine.SecurityServerChannel
SinkProvider,Microsoft.XLANGs.BizTalk.Engine" securityPackage="ntlm" authenticationLevel="packetPrivacy" />
            </serverProviders>
        </channelSinkProviders>
    
        <application>
            <channels>
                <channel ref="tcp" port="0" name="">
                <serverProviders>
                    <provider ref="sspi" />
                        <formatter ref="binary" typeFilterLevel="Full"/>
                    </serverProviders>
                </channel>
            </channels>
        </application>
    </system.runtime.remoting>
    <xlangs>
      <Configuration>
        <AppDomains AssembliesPerDomain="10">
          <DefaultSpec SecondsIdleBeforeShutdown="1200"
                       SecondsEmptyBeforeShutdown="1800"/>
          <AppDomainSpecs>
            <AppDomainSpec Name="Microsoft.Practices.ESB">
              <BaseSetup>
                <ConfigurationFile>
C:\Program Files\Generated By 
BizTalk\Microsoft.Practices.ESB\Config\Microsoft.Practices.ESB.PipelineComponents.config
                </ConfigurationFile>
              </BaseSetup>
            </AppDomainSpec>
          </AppDomainSpecs>
          <PatternAssignmentRules>
            <PatternAssignmentRule
                    AssemblyNamePattern="Microsoft.Practices.ESB.*"
                    AppDomainName="Microsoft.Practices.ESB" />
          </PatternAssignmentRules>
        </AppDomains>
      </Configuration>
    </xlangs>    
</configuration>

Naturalmente, occorrerà modificare anche il machine.config perchè sia aware degli assembly specificati nel file Microsoft.Practices.ESB.Context.PipelineComponents.config.

Come dovrebbe risultare evidente dalla creazione del database EsbExceptionDb, installando la soluzione core viene installato automaticamente anche l’Exception Management Framework; tuttavia, questo è installabile anche a parte, con procedura del tutto analoga a quella già vista (installazione del package di deployment di BizTalk con BTSTask, registrazione degli assembly nella GAC, creazione del relativo database in SQL Server 2005). Con la stessa procedura possiamo installare anche le componenti di interoperabilità JMS/WMQ con IBM MQSeries comprese nella Guidance.

A questo punto possiamo provvedere ad installare l’ ESB Management Portal, un sito SharePoint per l’amministrazione di applicazioni, servizi e componenti dell’ESB Guidance, che inoltre mostra eccezioni ed alert. E’, in effetti, l’unico componente per il quale è richiesta l’installazione della Enterprise Library 3.1; occorrerà inoltre scaricare ed installare la versione 5.5 o superiore dei controlli Dundas Chart for ASP.NET. Si presti attenzione ad usare la versione Enterprise: con quella Professional non sarà possibile effettuare la build del portale per via dei riferimenti al metodo Dundas.Charting.WebControl.DataManipulator.Group().

La prima cosa da fare è creare il database EsbAdmin tramite l’apposito script SQL disponibile fra i sorgenti dell’esempio Management Portal; ugualmente, andrà creata tramite l’IIS Manager la virtual directory necessaria, aggiungendola all’application pool creato durante l’installazione delle componenti core. Occorrerà a questo punto effettuare la build della soluzione C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.Portal da Visual Studio, dopo aver naturalmente modificato le ConnectionStrings e gli altri parametri del web.config descritti nella sezione Check Portal Configuration Settings dell’Help. In alternativa, nella cartella C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal è presente uno script BuildESBManagementProjects.cmd che effettua automaticamente la build del portale (Figura 9), compresi i servizi di alerting e pubblicazione UDDI, e crea la relativa virtual directory in IIS.

Figura 9: il portale di gestione dell'ESB Guidance, una delle novità della CTP di novembre. La sezione di reportistica sfrutta i controlli Dundas Chart for ASP.NET.

E’ quantomeno interessante dare un’occhiata ai servizi Web referenziati dall’ESB Portal (Figura 10), in particolare all’Itinerary che si occupa dei dettagli del routing (compresa la gestione asincrona e l’autenticazione, come potrete constatare dal codice di Reference.cs) e al BizTalkOperationsService i cui metodi gestiscono l’interazione con BizTalk.

Figura 10: i servizi Web per l'interazione fra l'ESB Management Portal e l'infrastruttura ESB costruita su BizTalk Server 2006 R2.

Se avete effettuato la build tramite lo script BuildESBManagementProjects.cmd vi ritroverete già a disposizione gli installer per i servizi di alerting delle eccezioni ed UDDI (Figura 11). Lanciate in esecuzione nell’ordine i due file setup.exe, avendo cura di fornire quando richieste le credenziali di un utente del gruppo BizTalk Application Users nella forma dominio\utente (l’applicazione restituirà un errore utente inesistente). Dopo l’installazione, potremo usare l’ESB Management Portal per cambiare le impostazioni dei due servizi, rispettivamente tramite le voci Admin/Fault Settings (Figura 12) ed Admin/Registry Settings (Figura 13), e farli partire dallo snap-in Services degli Administrative Tools (Figura 14). Si tenga presente che l’accesso alla voce Admin del portale richiede che l’utente che accede allo stesso sia membro del gruppo BizTalk Server Administrators.

Figura 11: la build della soluzione associata all'ESB Management Portal crea anche gli installer per i servizi di alerting delle eccezioni e pubblicazione UDDI.

Figura 12: Le opzioni di configurazione dell'ESB Management Portal per il servizio di alerting delle eccezioni...

Figura 13: ...e per quello di pubblicazione UDDI degli endpoint di comunicazione.

Figura 14: i due servizi in esecuzione nello snap-in degli Administrative Tools.

Entrambi i servizi operano in maniera del tutto indipendente da BizTalk, ovvero possono essere installati su una macchina sulla quale BizTalk non è presente. Il servizio di alerting usa le sottoscrizioni di SQL Server 2005 Notification Services per informare l’utente, ad intervalli prestabiliti, delle eccezioni verificatesi nell’applicativo ESB. L’UDDI Publishing Service recupera, tramite un moniker UDDI, le porte di invio e ricezione dei messaggi dalla tabella EndPoints del database ESBAdmin, e se la proprietà AutoPublish è abilitata, invoca automaticamente i servizi Web del server UDDI per pubblicarli; in caso contrario, invia una notifica e-mail all’amministratore del server UDDI, con le istruzioni per la pubblicazione tramite l’ESB Management Portal.

A questo punto, creiamo due condivisioni con accesso Read al gruppo Everyone per le due cartelle che ospitano i template di InfoPath per mostrare all’utente le informazioni sulle eccezioni (Figura 15). Opzionalmente, possiamo configurare IIS per usare SSL per l’accesso sicuro ai Web Services dell’ESB Guidance, seguendo le istruzioni nella sezione Configure Secure Web Service Connections della documentazione, prima di procedere all’installazione degli esempi dell’applicazione GlobalBank.ESB, che andrà primariamente creata (Figura 16) con il consueto comando:

BTSTask.exe ImportApp -Package:"C:\Program Files\Microsoft ESB Guidance 1.0
 - November 2007\GlobalBank.ESB.Policies.msi" /ApplicationName:GlobalBank.ESB

Con questa operazione, oltre a creare l’applicazione, installeremo anche le relative policy ed i vocabolari di BRE (Figura 17). All’inizio, a parte questi elementi, GlobalBank.ESB è un’applicazione vuota, alla quale vanno aggiunti gli assembly degli esempi. Le procedure di installazione per ognuno di essi si trovano nella sezione Microsoft ESB Guidance Sample Applications della documentazione; esse seguono un pattern comune: modifica dei file di configurazione; build e deployment della soluzione di Visual Studio 2005, creazione delle relative virtual directory di IIS, e di un installer .msi per BizTalk, tramite appositi script; registrazione dell’applicazione in BizTalk e degli assembly rispettivamente con BTSTask ed msiexec. Al termine dell’installazione di ogni esempio, e prima delle eventuali prove, è opportuno far ripartire il servizio di BizTalk Server.

Figura 15: le cartelle che ospitano le form di InfoPath usate per il rendering delle eccezioni devono essere rese accessibili in lettura al gruppo Everyone.

Figura 16: l'applicazione di esempio GlobalBank.ESB...

Figura 17: ...e le relative policy per il Business Rule Engine (BRE) di BizTalk Server 2006 R2.

Una volta terminate tutte le installazioni, possiamo far partire le due applicazioni Microsoft.Practices.ESB e GlobalBank.ESB dalla BizTalk Administration Consolle. La sequenza è quella tipica delle applicazioni di BizTalk: avvio delle sottoscrizioni alle porte di destinazione dei messaggi; deployment delle policy; aggiornamento delle Orchestration; avvio delle istanze sugli host. Opzionalmente, potremo usare i componenti pipeline dalla Toolbox di Visual Studio, seguendo le istruzioni dettagliate alla voce Install the Pipeline Components into the Visual Studio 2005 Toolbox della documentazione.

Come già ricordato, un ESB è, nella sua essenza, un broker con accoppiamento lasco di messaggi; è opportuno, dunque, capire anzitutto come avviene il flusso degli stessi nell’ESB Guidance. Il ciclo di vita tipico è il seguente:

1. un servizio genera un messaggio, e lo invia all’ESB Guidance

2. un servizio Web di tipo Itinerary On-Ramp (vedi Figura 2) lo riceve su una delle proprie porte (Figura 18)

3. una pipeline imposta le proprietà di contesto del messaggio, usando i valori delle proprietà del componente o, più propriamente, i metadati contenuti nell’header SOAP

4. l’ESB Guidance deposita il messaggio nel database MessageBox di BizTalk (di default, BizTalkMsgBoxDb)

5. un subscriber (che può essere un’orchestration di BizTalk o una porta di invio implementata da un componente Off-Ramp dell’ESB Guidance) preleva il messaggio dalla MessageBox, sulla base dei metadati di contesto.

Figura 18: le porte di ricezione dell'applicazione GlobalBank.ESB, fra le quali distinguiamo quelle dei servizi Itinerary On-Ramp.

In alternativa, invece di provenire da un servizio esterno, un componente di una Orchestration di BizTalk può creare un messaggio, popolare i metadati con le proprietà ESB di contesto, e inviarlo tramite una porta interna (direct-bound) alla MessageBox.

È importante comprendere il ruolo svolto dai servizi Itinerary: l’header SOAP coi metadati del messaggio contiene sia le trasformazioni da eseguire sul messaggio, che le informazioni per risolvere la sua destinazione, oltre a come recuperare tutti i passi intermedi: ad es., una lookup UDDI, WS-MetadataExchange o Business Rule Engine. Invocando un servizio Itinerary, un client può specificare le trasformazioni da eseguire sul messaggio, il loro ordine di esecuzione, e la strategia di invio ad ogni passo, senza dover richiedere a un amministratore di sistema di dover cablare da qualche parte i dettagli di routine e le porte di invio.

Quando un servizio Itinerary riceve un messaggio, estrae gli header relativi a trasformazioni e routing, li valida, e popola una proprietà di contesto del messaggio. Le pipeline e le orchestration di BizTalk (Figura 19) potranno a questo punto prelevare tutte le informazioni necessarie per effettuare trasformazioni sul messaggio, per poi inoltrarlo alla successiva destinazione. L’elenco delle proprietà impostate da un servizio Itinerary è contenuto nel file C:\Projects\Microsoft.Practices.ESB\Source\Core\Source\ESB.Itinerary.Schemas\System-Properties.xsd e comprende, oltre come ricordato ai servizi da invocare ad ogni step, il nome del servizio, il suo stato (Pending, Complete o Active), il tipo di step corrente (Messaging o Orchestration; vedi oltre) e se il messaggio è di tipo one-way, o a richiesta/risposta.

Figura 19: le pipeline definite per l'applicazione GlobalBank.ESB.

Le trasformazioni e il routing, per ogni step, vengono effettuate da un altro servizio Itinerary o da una Orchestration di BizTalk, in dipendenza dal valore della proprietà ServiceType. Nel primo caso, spetta al servizio Itinerary stesso modificare il contesto del messaggio ed inoltrarlo allo step successivo, tramite le funzionalità publish-subscribe di BizTalk. Al fine di dimostrare questo processo, l’ESB Guidance contiene un’applicazione WinForm di test, nella cartella C:\Projects\Microsoft.Practices.ESB\Source\Samples\Itinerary\Source\ESB.Itinerary.Test, che può operare sui tredici itinerari definiti, sotto forma di file XML, nella cartella C:\Projects\Microsoft.Practices.ESB\Source\Samples\Itinerary\Itineraries. È necessario installare l’esempio Itinerary, che a sua volta richiede l’installazione degli esempi Revolver e DynamicResolution.

Non potrete effettuare l’installazione dell’esempio DynamicResolution, che come tutti gli esempi richiede la build dei sorgenti per creare l’installer .msi da deployare con BTSTask, se non avrete installato Visual Studio 2005 SP1, oltre all’SDK ed agli add-in di BizTalk: oltre a policy e vocabolari di BRE, e ad una serie di 17 binding dinamici sotto forma di file XML usati per gli esempi, il progetto consiste sostanzialmente di due Web Services (presi anch’essi dall’SDK di BizTalk 2006 R2) che simulano l’invio di un ordine sotto forma di messaggio, e da un insieme di pipeline, schema e trasformazioni tramite Mapper di BizTalk.

Prima di poter effettuare qualunque test, è necessario importare manualmente il file che contiene i binding dinamici delle porte di invio (C:\Projects\Microsoft.Practices.ESB\Source\Samples\Itinerary\Install\Binding\GlobalBank.ESB.Itinerary_Bindings.xml se si è effettuata la compilazione dai sorgenti, la versione FromRelease se avete usato gli installer .msi) dall’apposita voce di menu contestuale dell’applicazione GlobalBank.ESB nella BizTalk Administration Console.

A questo punto, dalla cartella \bin\Debug della cartella che contiene la WinForm di test, basta lanciare in esecuzione l’applicazione ESB.Itinerary.Test.exe, cliccare sul pulsante Load Itinerary e scegliere uno degli itinerari nella cartella \Source\Samples\Itinerary\Itineraries . Possiamo scegliere se la comunicazione è ad una o due vie, se usare WCF al posto di SOAP, ed i resolver definiti per l’ESB Guidance (Figura 20) che effettuino la lookup della destinazione, come ricordato precedentemente. Carichiamo un messaggio (ne viene fornito uno di esempio, NAOrderDoc.xml, nell’applicazione di test) con la file dialog della voce Load Message , e clicchiamo su Submit Request per simulare la trasmissione del messaggio (Figura 21).

Figura 20: i Resolver dell'ESB Guidance sono in grado di effettuare la ricerca dinamica di una destinazione per un messaggio, sulla base di metadati di contesto definiti nell'header SOAP.

Figura 21: l'applicazione WinForm per il test dell'elaborazione e routing di messaggi con un servizio Itinerary.

L’applicazione WinForms di esempio crea un insieme di header SOAP a partire dagli itinerari caricati tramite Load Itinerary , li appone al messaggio caricato da disco e li invia all’ESB Guidance tramite un servizio Itinerary On-Ramp. Se l’ESB genera una risposta, l’applicazione la mostra nell’apposita textbox. Prendiamo in considerazione, a titolo di esempio, l’itinerario TwoWay-OrchTransform-OrchRoutingGroup-OrchTwoWayCustom.xml, disponibile nella soluzione Itinerary. La prima sezione dell’itinerario specifica l’invocazione di tre servizi: l’ Orchestration Microsoft.Practices.ESB.Services.Transform per modificare il formato del messaggio tramite una policy BRE; l’ Orchestration Microsoft.Practices.ESB.Services.Routing per inoltrare il messaggio ad una serie di destinatari definiti in maniera dinamica; e un’ Orchestration ad hoc (Figura 22) per restituire all’applicazione di test una copia della risposta. Ovviamente, il codice XML per l’invocazione dei servizi rispecchia fedelmente la Request() del servizio Web ProcessItinerary associato alla Response() dei servizi Itinerary (Figura 23). La sezione How the Itinerary On-Ramp Sample Works della documentazione illustra in dettaglio non solo il processing XML ma anche il codice C# della ESB Guidance che lo effettua.

Figura 22: una Orchestration custom permette alla WinForm di test del servizio Itinerary di ricevere la risposta di ogni destinatario di un messaggio.

Figura 23: la request/response SOAP del servizio ProcessItinerary, alla base della creazione di un itinerario configurabile XML per l'ESB Guidance.

Un altro esempio che vale la pena vedere in azione è l’UDDI Service, che usa un’applicazione WinForm per eseguire i metodi del servizio Web UDDI dell’ESB Guidance (Figura 24) onde gestire il registro dei servizi, e mostrare i risultati. L’applicazione supporta tutti gli scenari di cui alla Figura 24, fra cui la pubblicazione delle informazioni su un servizio (Figura 25) ed il suo salvataggio nel registro (Figura 26); si faccia riferimento alla documentazione per tutti gli altri scenari.

Figura 24: i metodi del servizio UDDI dell'ESB Guidance per la gestione del registro dei servizi.

Figura 25: l'applicazione WinForm per la gestione del registro dei servizi. Pubblicazione delle informazioni su un servizio...

Figura 26: ...e salvataggio nel registro UDDI.

Un’applicazione di configurazione, build ed uso assai semplice è, infine, il client WinForm di test per il servizio ESB.BizTalkOperationsServices, che permette di ottenere una serie di informazioni sull’installazione di BizTalk in uso (Figura 27).

Figura 27: il client del servizio ESB.BizTalkOperationsServices permette di ottenere una serie di informazioni sull'istanza di BizTalk in uso.

L’ESB Management Portal, del quale ho già mostrato l’installazione e configurazione, è stato pensato come un sito di esempio delle possibilità di estensione dell’ESB Guidance e dell’uso di metriche di processo, sul modello del BAM Portal già fornito con BizTalk. Tuttavia, esso offre anche apprezzabili capacità di gestione grafica del framework per le eccezioni, del registro UDDI e di allarmi e notifiche, queste ultime basate su sottoscrizioni.

Vale dunque la pena esaminare le possibilità offerte in ognuna di queste aree. In primo luogo, per usufruire delle capacità di reportistica, dobbiamo scegliere quali applicazioni monitorare (vedi Figura 9) e su quale periodo dalla Home Page. Questa è anche l’unica personalizzazione che è possibile effettuare in questa release dalla scheda My Settings. Dalla scheda Faults possiamo recuperare, ed esportare in Excel, le failure delle applicazioni monitorate, filtrate secondo una serie di criteri che comprendono il periodo di osservazione, la categoria e la gravità (Figura 28).

Figura 28: la scheda Faults dell'ESB Management Portal, dalla quale possiamo interrogare il database delle failure delle applicazioni monitorate.

La scheda Faults offre anche funzionalità di visualizzazione dei dettagli degli errori e dei messaggi che li hanno generati (Figura 29), oltre alla possibilità di editare i messaggi e reinviarli alla destinazione (Figura 30), visualizzando in Admin / Manage Audit Log il risultato di questa operazione (Figura 31).

Figura 29: tramite la scheda Faults possiamo visualizzare i dettagli degli errori, e dei messaggi che li hanno generati.

Figura 30: è possibile, altresì, editare i messaggi ed inoltrarli ad una destinazione...

Figura 31: ...visualizzando in Admin / Manage Audit Log il risultato dell'operazione.

Ove si verifichi un errore, è possibile ricevere un avviso (grazie ai Notification Services di SQL Server 2005) impostandolo dall’omonima scheda Alerts del portale. La creazione di un avviso richiede in primo luogo di specificare le condizioni di allarme (Figura 32), per poi aggiungere una sottoscrizione che specifichi l’indirizzo e-mail al quale mandare l’avviso, oltre ai periodi in cui l’invio è effettivo o meno (Figura 33). Questo creerà un elenco di allarmi e sottoscrizioni nella pagina Alerts del portale (Figura 34) dal quale è possibile modificare entrambi ed aggiungere sottoscrizioni, oltre che esportare l’elenco in Excel (Figura 35). Due cose sono da notare: la prima è che, una volta che si è aggiunta una sottoscrizione, scompare il pulsante di cancellazione del relativo alert sotto la colonna Action, che ricomparirà solo rimuovendo tutte le sottoscrizioni; la seconda è che in questa versione dell’ESB Guidance le condizioni per la notifica di un alert possono essere specificate solo in AND, non in OR. Dalla voce Admin / Fault Settings potremo ora impostare i parametri di audit, della coda di allarme e dell’invio via e-mail delle notifiche, come già mostrato in Figura 12, mentre Admin / Manage Alerts è sostanzialmente una diversa vista sulle azioni che è possibile effettuare nella scheda Alerts (Figura 36).

Figura 32: la creazione di un allarme a seguito del verificarsi di un insieme di condizioni, in questa versione purtroppo solo in AND...

Figura 33: ...e la successiva aggiunta di una sottoscrizione all'allarme.

Figura 34: la pagina Alerts dell'ESB Management Portal, con la gestione degli allarmi e delle relative sottoscrizioni.

Figura 35: le informazioni della schermata precedente, esportate in Excel per ulteriori analisi.

Figura 36: la voce Admin / Manage Alerts è sostanzialmente un duplicato della scheda Alerts.

Alla voce Administration with the Microsoft ESB Guidance la documentazione illustra altresì le funzionalità di reportistica ed analisi degli errori grazie ai controlli Dundas ed i servizi di pubblicazione UDDI, sostanzialmente un’interfaccia (Figura 37) differente da quella vista nella sezione dedicata agli esempi d’uso, ma per gli stessi servizi dell’ESB, che è possibile inoltre gestire dalla BizTalk Administration Console.

Figura 37: l'interfaccia verso il registro UDDI dell'ESB offerta dalla voce Registry / New Registry Entry dell'ESB Management Portal.

Dal registro dei servizi al routing intelligente e dinamico dei messaggi, passando per la composizione e l’orchestrazione dei servizi, all’ESB Guidance non manca davvero nulla per poter essere definita un Enterprise Service Bus, per quanto si tratti di un progetto ancora non definitivo che sicuramente riserverà qualche bella sorpresa. Dalle prove che ho effettuato era improponibile trarre qualche conclusione circa le caratteristiche non-funzionali; tuttavia, è da considerare come l’ESB Guidance sia sostanzialmente un set di componenti riusabili ospitati all’interno di un’applicazione standard di BizTalk Server 2006 R2, col supporto di una serie di servizi WS-* e WCF risiedenti su IIS 6.0, e che interagiscono con repository di SQL Server 2005.

Trattandosi di un’architettura di servizi lascamente accoppiati, priva per definizione stessa di ESB di nodi di elaborazione centrale che possano costituire dei colli di bottiglia, è perciò ragionevole supporre che essa erediti per così dire le caratteristiche di scalabilità e affidabilità dei prodotti citati (si vedano, per esempio, BizTalk Server 2006: Scalability Case Study Using the SOAP Adapter in BizTalk Server 2006, Web Server Scalability (IIS 6.0) e Technical Overview of SQL Server).

La versione finale vedrà sicuramente qualche miglioramento nella pacchettizzazione e nelle procedure di installazione, ad oggi piuttosto laboriose. Ma, da queste prime release non è difficile immaginare un prodotto che nel giro di una o due versioni entrerà a far parte del core di BizTalk.