BizTalk Server 2006 o WF? Scelta dello strumento flusso di lavoro appropriato per il progetto

Kent Brown

ventisix New York (www.26ny.com)

Novembre 2007

Revisione febbraio 2008

Si applica a:

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

riepilogo : Questo articolo fornisce indicazioni per la scelta tra Microsoft BizTalk Server 2006 e Windows Workflow Foundation in un'ampia gamma di scenari di flussi di lavoro di applicazione ed integrazione aziendale. (16 pagine stampate)

Contenuto

Introduzione

Processo per la scelta dello strumento flusso di lavoro corretto

Scenari comuni del flusso di lavoro

È tutto nell'host

raccomandazioni Workflow-Technology

Future-Proofing

Conclusione

Appendice

Riconoscimenti

Altre informazioni

Introduzione

Il flusso di lavoro è diffuso nei processi aziendali di tutti i giorni, in modo che una necessità comune stia trovando strumenti di programmazione che supportano direttamente la creazione di soluzioni del flusso di lavoro. Microsoft BizTalk Server 2006 e Windows Workflow Foundation (WF) sono i due strumenti principali di Microsoft per la programmazione delle soluzioni flusso di lavoro. Tuttavia, a causa della sovrapposizione apparente tra loro, molti architetti e sviluppatori hanno difficoltà a decidere quale tecnologia del flusso di lavoro ha senso per i loro scopi.

Ciò è particolarmente vero dato che WF è stato chiaramente identificato come la tecnologia di flusso di lavoro preferita in futuro, mentre BizTalk Server 2006 è ancora il prodotto server Premium per l'integrazione aziendale. Fino a quando l'orchestrazione di BizTalk Server non supporta completamente WF, architetti e sviluppatori devono scegliere con attenzione la tecnologia da investire.

Una delle sfide nella scelta della tecnologia giusta per l'implementazione del flusso di lavoro è che il flusso di lavoro può significare molte cose, tra cui:

• Flusso di schermate dell'interfaccia utente con cui un utente interagisce per completare un'attività.
• Flusso della logica di business all'interno di un'applicazione o di un servizio.
• Interazione di diversi esseri umani per completare un processo aziendale.
• Coordinamento di più scambi di messaggi tra sistemi per elaborare una transazione aziendale.
• Coordinamento dei passaggi per estrarre, trasformare e caricare dati (ETL) in un database.

Sebbene lo spettro degli scenari del flusso di lavoro sia ampio, è utile raggrupparli in quattro categorie generali: flusso di lavoro umano, flusso di lavoro dell'applicazione, flusso di lavoro di integrazione aziendalee flusso di lavoro di integrazione dei dati.

Tra le quattro principali categorie di flussi di lavoro, il flusso di lavoro delle applicazioni e il flusso di lavoro enterprise sono le due aree in cui le persone trovano più difficile scegliere una tecnologia. Gli scenari flusso di lavoro umano e flusso di lavoro di integrazione dei dati sono piuttosto semplici, dal punto di vista della selezione degli strumenti. Il flusso di lavoro umano richiede un'interfaccia utente ed è spesso incentrato sui documenti, in modo che Microsoft Office SharePoint Server 2007 sia la piattaforma consigliata per la creazione di soluzioni Human Workflow. Microsoft SQL Server Integration Services (SSIS) è lo strumento consigliato per gli scenari di integrazione dei dati.

Questo articolo fornisce indicazioni per la scelta tra BizTalk Server 2006 e WF negli scenari flusso di lavoro applicazioni ed Enterprise Integration Workflow.

Motore di orchestrazione di BizTalk Server

Il motore di orchestrazione di BizTalk Server è sempre stata una delle funzionalità interessanti di BizTalk Server. Quando è stato introdotto, è stato lo strumento migliore disponibile da Microsoft per l'esecuzione di programmazione incentrata sul flusso di lavoro. L'orchestrazione di BizTalk Server offre un ambiente di programmazione visiva per lo sviluppo di componenti per controllare flussi di messaggi complessi e a più passaggi per completare una determinata transazione aziendale.

Gli artefatti del codice di orchestrazione di BizTalk Server sono simili ai diagrammi di attività UML (FlowChart o Unified Modeling Language) che un business analyst potrebbe produrre per documentare un processo aziendale. Questi artefatti possono quindi essere compilati ed eseguiti nel runtime del motore di orchestrazione, che fornisce servizi come transazioni a esecuzione prolungata e compensazione, durabilità, tolleranza di errore e ripristino di emergenza, fondamentali per la creazione di sistemi che automatizzano le transazioni aziendali cruciali.

Una base di flusso di lavoro per il futuro

Anche se esistono categorie distinte di scenari di flusso di lavoro, tra gli scenari è sufficiente una quantità sufficiente, dal punto di vista della programmazione, per provare a stabilire un framework comune per lo sviluppo del flusso di lavoro. Il motore di orchestrazione in BizTalk Server è potente, ma non è mai stato progettato per essere usato all'esterno di BizTalk Server; non è quindi possibile riutilizzare l'orchestrazione di BizTalk Server in modo efficace per le altre categorie di flussi di lavoro.

WF, rilasciato in Microsoft .NET Framework 3.0, introduce un modello di programmazione visuale incentrato sul flusso di lavoro per .NET Framework progettato per essere sufficientemente generale ed estendibile da usare in tutti gli scenari correlati al flusso di lavoro nella piattaforma Windows in futuro. Il team che ha prodotto WF è riuscito a prendere i concetti migliori del motore di orchestrazione di BizTalk Server, prendere in considerazione i requisiti per l'area di autenticazione più ampia degli scenari del flusso di lavoro e progettare un framework sufficientemente flessibile da supportarli tutti.

Come prova della flessibilità di WF, Microsoft Office SharePoint Server 2007 lo usa per implementare soluzioni Human Workflow. L'intento è che i fornitori BPM di terze parti creino anche le proprie soluzioni su WF, invece di creare motori di flusso di lavoro proprietari; diversi fornitori lo hanno già fatto. I singoli sviluppatori possono anche usare WF per implementare un flusso di lavoro dell'applicazione personalizzato nelle applicazioni .NET Framework. Il piano prevede anche una versione futura di BizTalk Server per implementare il motore di orchestrazione in WF per l'implementazione di soluzioni Enterprise Integration Workflow.

Figura 1. Uso dello strumento del flusso di lavoro corretto: BizTalk Server 2006 e WF

Processo per la scelta dello strumento flusso di lavoro corretto

Il metodo per fornire indicazioni utili per decidere quale strumento del flusso di lavoro si adatta al progetto sarà delineare gli scenari di flusso di lavoro più comuni, in modo da poter determinare lo scenario o la combinazione di scenari più adatti al progetto. Verranno quindi fornite indicazioni specifiche per ogni scenario, ad esempio BizTalk Server 2006 o WF, più adatto e perché. Inoltre, si userà il modello di ottimizzazione dell'infrastruttura (APIO) application platform, un modello per valutare la maturità delle funzionalità di sviluppo e della piattaforma dell'applicazione di un'organizzazione, per fornire indicazioni specifiche dell'organizzazione negli scenari in cui entrambi gli strumenti possono essere usati in modo efficace. Infine, si esaminerà la roadmap per BizTalk Server 2006 e WF, in modo da poter prendere le decisioni migliori per le applicazioni a prova futura che si stanno creando oggi.

Scenari comuni del flusso di lavoro

Anche dopo aver limitato l'ambito alle categorie application e enterprise integration del flusso di lavoro, esiste ancora una vasta gamma di scenari di flusso di lavoro da considerare. Come illustrato nella figura 2, su un lato dello spettro si trovano scenari in cui WF rappresenta chiaramente la scelta giusta. Un esempio di questa funzionalità è la funzionalità del flusso di lavoro all'interno di un prodotto isv (Independent Software Vendor), in cui i costi di licenza e la complessità della distribuzione di BizTalk Server 2006 sarebbero proibitivi. In questo scenario, come ISV, si è nell'azienda di fare software commerciale e l'impegno di programmazione aggiuntivo necessario per ospitare WF royalty-free è un investimento ragionevole.

Figura 2. Integrazione e continuità del flusso di lavoro

Dall'altra parte dello spettro sono le soluzioni Enterprise Integration create all'interno di un reparto IT aziendale, dove chiaramente BizTalk Server 2006 è la scelta giusta. In questo scenario si vuole concentrarsi sulla produzione di valore aziendale, invece di investire nella creazione del "plumbing" per rendere la soluzione scalabile, affidabile e gestibile; quindi, il costo delle licenze di BizTalk Server 2006 vale la pena, a causa di ciò che fornisce.

La maggior parte dei progetti rientra tra queste due estremità dello spettro. Di seguito sono riportati alcuni scenari comuni in cui i requisiti determinano una soluzione del flusso di lavoro:

• ui Page Controller: un requisito comune nelle applicazioni complesse consiste nell'applicare lo spostamento dello schermo dell'interfaccia utente in base alle regole business del caso d'uso specifico implementato. L'esempio più semplice è una procedura guidata che illustra l'utente attraverso un set prestabilito di schermate per eseguire un'attività. Spesso, si tratta di un grafico più complesso delle possibilità di spostamento dello schermo basate sulle azioni dell'utente e sullo stato dei dati.
  Il modello Model-view-controller (MVC) è la tecnica classica per estrarre questa logica di spostamento dalle forme stesse, in modo che siano più semplici e riutilizzabili in diversi casi d'uso. Il controller nel modello MVC è davvero un flusso di lavoro o una macchina a stati; quindi, è naturale cercare uno strumento del flusso di lavoro nell'implementazione di questi tipi di applicazioni.
• logica di business a esecuzione prolungata: quando sono necessari molti passaggi per completare una transazione aziendale, l'utente potrebbe dover arrestarsi durante il processo o attendere azioni da altri utenti o sistemi prima di continuare. La possibilità di sospendere temporaneamente (o "ibernare") un processo e quindi riavviarlo, in base a eventi esterni, è fondamentale per l'idea del flusso di lavoro. Senza un motore di flusso di lavoro, gli sviluppatori sono costretti a progettare e scrivere manualmente i meccanismi per archiviare lo stato di un processo incompleto e ricordare tale stato quando il processo viene continuato. Con un motore di flusso di lavoro ben progettato, questa funzionalità è supportata in modo nativo senza ulteriori operazioni per gli sviluppatori.
• flusso di processo aggiornabile in modo dinamico- Sebbene sembri possibile codificare i processi aziendali in passaggi sequenziali ben definiti, gli esseri umani spesso devono modificare il flusso midstream in modo da tenere conto delle situazioni reali. In un processo di approvazione delle spese, il responsabile del dipendente che ha inviato la nota spese potrebbe essere il responsabile approvazione predefinito. Tuttavia, il manager potrebbe decidere di delegare l'attività a un segretario (ad esempio, perché il manager è diretto a giocare a golf) o inoltrare l'approvazione a un superiore (ad esempio, perché il manager non è sicuro del criterio per una determinata spesa). Consentire all'utente di aggiornare il flusso è spesso più semplice rispetto al tentativo di prevedere ogni possibile permutazione del flusso in anticipo.
• astrazione delle regole dalla logica di business: in questo scenario l'obiettivo è separare le regole business da altre regole di business. Un buon esempio è costituito da regole di convalida del modulo. In un programma di richiesta ipotecaria, il modulo richiesta di prestito potrebbe avere un set di regole di convalida del campo prima che l'utente possa premere il pulsante Invia per inviare una richiesta di prestito. Se lo stesso modulo viene utilizzato dal responsabile del prestito per esaminare e approvare il prestito, sono necessarie regole di convalida aggiuntive, perché si trova in una fase diversa del processo.
  L'implementazione delle regole di convalida separatamente dal modulo semplifica il riutilizzo del modulo in scenari diversi e l'applicazione delle regole di convalida appropriate semplicemente valutando il set appropriato di regole per tale scenario.
• aggregator del servizio Web: le applicazioni spesso devono aggregare dati da diversi servizi Web. In molte situazioni, la logica di aggregazione stessa può e deve essere estratta dall'applicazione ed esposta come servizio nel proprio diritto che può essere riutilizzata da altre applicazioni. Questi servizi vengono spesso chiamati servizi Web compositie sono un elemento importante di un'architettura orientata ai servizi matura. Lo scenario dell'aggregatore di servizi Web è in genere sincrono e in esecuzione breve.
• processo aziendale a esecuzione prolungata: lo scenario del processo aziendale a esecuzione prolungata viene usato in questo articolo per designare processi basati su server che integrano più applicazioni insieme, mentre logica di business viene usato per la logica all'interno di una singola applicazione. I requisiti per questi processi aziendali a esecuzione prolungata basati su server per il multithreading, il comportamento asincrono, la persistenza dello stato del processo, la correlazione dei messaggi a istanze di elaborazione, scalabilità, affidabilità, integrità transazionale e così via, sono molto più elevati rispetto alla logica di business all'interno di un'applicazione.
• processo business-to-business (B2B): lo scenario del processo B2B è essenzialmente lo stesso dello scenario del processo aziendale a esecuzione prolungata, ad eccezione del fatto che il primo è tra le organizzazioni oltre alle applicazioni interne. I requisiti di sicurezza, pertanto, sono fondamentali. Inoltre, si ha ancora meno controllo sul formato dati e il protocollo di trasporto specifici, in quanto questi potrebbero essere dettati dal partner commerciale; Quindi, è necessaria la possibilità di supportare un'ampia gamma di formati e protocolli e supportare la configurazione degli interscambi specifici per un numero elevato di partner.
• astrazione delle regole dal processo aziendale: analogamente all'astrazione delle regole dallo scenario della logica di business, questo scenario si applica quando si desidera separare le regole business dal codice principale nello scenario del processo aziendale a esecuzione prolungata e nello scenario del processo B2B. Questo scenario richiede un livello superiore di prestazioni e scalabilità. Inoltre, probabilmente richiederà strumenti per consentire ai non programmatori di visualizzare e modificare le regole.
• repository di regole dell'organizzazione: in questo scenario, l'obiettivo è creare un repository centrale di regole condivise che può essere richiamato da tutte le applicazioni dell'organizzazione. Ciò garantisce la coerenza tra tutte le applicazioni di un'organizzazione per l'applicazione di regole business importanti. Analogamente all'astrazione delle regole dallo scenario del processo aziendale, questo scenario richiede scalabilità elevata e strumenti per consentire ai non programmatori di visualizzare e modificare le regole. Inoltre, questo scenario richiede che il repository delle regole sia in grado di essere esistente come propria entità nell'organizzazione, con il proprio meccanismo di hosting separato dal motore del flusso di lavoro e con componenti o API per l'esecuzione delle regole da varie applicazioni.
• Enterprise Service Bus (ESB)/Message Broker: molte organizzazioni vogliono un'infrastruttura di comunicazione standardizzata per tutti i servizi. Le due topologie più comuni per questa infrastruttura sono ESB e Message Broker. La messaggistica di pubblicazione/sottoscrizione e il routing di base degli argomenti sono in genere funzionalità previste di questa infrastruttura.

Modello di ottimizzazione dell'infrastruttura della piattaforma applicativa

In alcuni scenari del flusso di lavoro, sia BizTalk Server 2006 che WF soddisfano in modo soddisfacente i requisiti tecnici. Per questi scenari, la scelta corretta della tecnologia del flusso di lavoro richiede la corrispondenza della soluzione alle esigenze dell'organizzazione specifica. Ai fini di fornire raccomandazioni applicabili a una determinata organizzazione, si userà il modello di ottimizzazione dell'infrastruttura della piattaforma applicativa (APIO), come illustrato nella figura 3.

Figura 3. Modello apiO (Application Platform Infrastructure Optimization)

Il modello APIO è una tecnica per la profilatura della maturità di un'organizzazione in relazione all'infrastruttura, all'architettura e alle procedure di sviluppo dell'applicazione. L'obiettivo di questo modello è offrire alle organizzazioni una roadmap per ottimizzare la propria agilità nel fornire soluzioni IT per soddisfare le esigenze dell'azienda.

Il modello APIO usa i quattro profili seguenti della maturità di un'organizzazione:

• basic: le organizzazioni considerano il software come un costo. Hanno applicazioni in gran parte silo con poca integrazione o riutilizzo. Le applicazioni che hanno potrebbero trovarsi in un'ampia gamma di piattaforme. Non hanno standard coerenti per le tecniche di infrastruttura o sviluppo; non hanno una visione architetturale coerente.
• standardizzato : le organizzazioni considerano ancora il software come un costo, ma hanno adottato misure per migliorare l'efficienza. Hanno una visione dell'architettura e cercano di prendere in considerazione le opportunità di riutilizzo. Hanno iniziato a integrare alcune applicazioni, ma sono principalmente integrazioni da punto a punto.
• advanced: le organizzazioni considerano il software come abilitatore aziendale. Hanno architetti dedicati e una visione architetturale chiara. Hanno molti servizi e ottengono un elevato livello di riutilizzo. Tutti i processi aziendali principali vengono automatizzati e monitorati. Usano una piattaforma di integrazione centralizzata e in pacchetto.
• dinamici : le organizzazioni considerano il software come asset strategico. Hanno un SOA molto maturo nella visione e nell'implementazione. Hanno processi chiari per il controllo delle versioni e la ridistribuzione dinamica dei servizi. Può adattarsi rapidamente ai cambiamenti dei requisiti aziendali e può integrarsi rapidamente con nuovi partner commerciali.

Non è solo dove sei, ma dove stai andando

Un po' implicito nel modello APIO è il concetto che ogni organizzazione aspira a passare al profilo dinamico. In realtà, dipende dalla natura dell'azienda e dalla filosofia della gestione per quanto riguarda la tecnologia. Alcune aziende potrebbero essere completamente soddisfatte di rimanere nel profilo Basic o Standardizzato.

È consigliabile considerare il profilo attuale, nonché gli obiettivi a breve termine e a lungo termine, con l'obiettivo a breve termine più importante. Un'organizzazione nel profilo Basic, con il desiderio di trovarsi nel profilo dinamico alla fine, potrebbe scegliere con saggezza di concentrarsi inizialmente su come entrare nel profilo standardizzato; quindi, le sue decisioni tecnologico dovrebbero essere principalmente coerenti con il profilo standardizzato.

In generale, BizTalk Server 2006 sarà una soluzione migliore per le organizzazioni che sono, o hanno un obiettivo a breve termine, nel profilo Avanzato o Dinamico. Un'organizzazione nel profilo Basic relativamente soddisfatta in questo profilo potrebbe non avere né la motivazione strategica di adottare BizTalk Server 2006 né le funzionalità per sfruttarlo in modo efficace; quindi, probabilmente non vorrebbero fare l'investimento. Tuttavia, se un'organizzazione nel profilo Basic ha deciso di passare al profilo Avanzato in modo aggressivo, l'adozione di BizTalk Server 2006 potrebbe essere un passo strategico in tale direzione.

Il punto di introdurre il modello APIO nella discussione è che avere una buona idea dei profili APIO correnti e mirati dell'organizzazione aiuterà a decidere tra WF e BizTalk Server 2006, quando lo scenario tecnico potrebbe essere ben supportato da entrambe le tecnologie. Due organizzazioni diverse potrebbero fare scelte diverse, ognuna delle quali fa la scelta giusta per il proprio profilo aziendale.

È tutto nell'host

Uno degli aspetti più importanti da considerare quando si sceglie tra BizTalk Server 2006 e WF è i requisiti di hosting per i flussi di lavoro. A differenza di BizTalk Server 2006, WF non fornisce l'hosting "out-of-the-box"; è necessario implementare un host che stabilisce il processo di Windows e avvia il motore di runtime del flusso di lavoro in cui verranno eseguiti i flussi di lavoro.

Per creare un framework in grado di supportare lo spettro completo degli scenari del flusso di lavoro in modo realistico, WF astrae i comportamenti principali forniti da un ambiente come BizTalk Server 2006, in modo che vari host possano fornire il comportamento desiderato specifico per questi servizi.

I servizi di base forniti da un host del flusso di lavoro WF sono i seguenti:

• Servizio di pianificazione: crea e gestisce i thread usati dal motore di runtime per eseguire le istanze del flusso di lavoro.
• commit del servizio Batch di lavoro: gestisce le transazioni usate dal motore di runtime per le operazioni del database.
• servizio di persistenza: gestisce la persistenza dell'istanza del flusso di lavoro quando viene indirizzata a tale operazione dal motore di runtime. Questo servizio è facoltativo. Se non viene specificato, le istanze del flusso di lavoro non verranno mantenute e devono essere eseguite in memoria per tutta la durata.
• servizio di rilevamento: consente di registrare gli eventi di rilevamento all'interno dei flussi di lavoro. Questo servizio è facoltativo.

Cosa serve per creare un host del flusso di lavoro

A seconda dello scenario del flusso di lavoro e dei servizi che è necessario fornire ai flussi di lavoro, la creazione di un host WF potrebbe essere semplice o proibitiva. Per gli scenari in cui il flusso di lavoro si trova nel contesto di un'applicazione, l'hosting di WF è piuttosto semplice. L'applicazione stessa funge da host del processo e sono disponibili implementazioni standard dei servizi di base che possono essere configurate con un minimo sforzo.

Tuttavia, la complessità necessaria dell'host passa notevolmente quando si entra in scenari altamente scalabili e basati su server. La tabella 1 mostra un elenco di servizi host che potrebbero essere necessari, la maggior parte dei quali è disponibile in BizTalk Server 2006.

Tabella 1. Servizi host

Che affari sei in, comunque?

Se si ha l'incarico di creare un'applicazione specifica con scadenze rigorose, è probabile che il team non debba distrarsi dalla necessità di creare un host complesso quando deve essere incentrato sull'implementazione della logica di business necessaria. In questo caso, BizTalk Server 2006 vale la pena investire da acquistare, invece di tentare di compilare, un host di flusso di lavoro affidabile. Se si fa parte del team di architettura centrale di una grande azienda, è possibile scegliere di investire nella creazione di un host che può essere usato nell'organizzazione. Anche così, questo sforzo non dovrebbe essere preso alla luce.

raccomandazioni Workflow-Technology

Per gli scenari all'interno di un'applicazione: WF

Per tutti gli scenari contenuti all'interno di un'applicazione, tra cui controller di pagina dell'interfaccia utente, logica di business a esecuzione prolungata, flusso di processo aggiornabile dinamicamente, composizione del servizio Web e astrazione delle regole dalla logica di business, WF è la scelta giusta per la tecnologia del flusso di lavoro.

Nella maggior parte degli scenari incentrati sulle applicazioni, il modello di utilizzo richiede un'interazione sincrona a bassa latenza tra l'applicazione e il flusso di lavoro, che non è la forza di BizTalk Server 2006. BizTalk Server 2006 non sarebbe adatto a questi scenari, per motivi di prestazioni; Le orchestrazioni di BizTalk Server vengono eseguite in server BizTalk dedicati e richiamarle da un'applicazione client richiede un round trip attraverso la rete. Inoltre, la progettazione di BizTalk Server 2006 di rendere persistente ogni messaggio nel database MessageBox per la durabilità introduce una latenza aggiuntiva, che potrebbe non essere accettabile nel contesto di un'interfaccia utente interattiva, se il flusso di lavoro deve essere chiamato in modo sincrono.

WF è una soluzione migliore per questi scenari; soddisfa i requisiti del flusso di lavoro ed è più semplice e conveniente rispetto a BizTalk Server 2006. Le funzionalità di messaggistica di BizTalk Server 2006, ad esempio mapping e adapter, non sono necessarie in questi scenari. I requisiti per i servizi di hosting sono modesti, in modo che l'hosting del runtime WF all'interno dell'applicazione non richieda una quantità di lavoro proibitiva.

Per la maggior parte degli scenari di Business-Process: BizTalk Server 2006

Per la maggior parte degli scenari che coinvolgono processi aziendali basati su server, BizTalk Server 2006 è la scelta giusta. Questi includono processo B2B, astrazione delle regole dal processo aziendale, repository di regole aziendali e bus di servizio aziendale (ESB)/Message Broker.

Questi scenari richiedono scalabilità elevata. Inoltre, richiedono la possibilità di visualizzare i processi in esecuzione e di arrestarli e riavviarli. Infine, richiedono il supporto per l'aumento del numero di istanze in più server. In questi scenari, sono necessarie le funzionalità di hosting avanzate di BizTalk Server 2006 e vale la pena investire.

Figura 4. Scenario di processo aziendale a esecuzione prolungata

BizTalk Server 2006 è in genere la piattaforma migliore per lo scenario di processo aziendale a esecuzione prolungata. Questi processi tendono a essere asincroni, a esecuzione prolungata e con stato. Questi processi sono spesso cruciali per l'organizzazione; pertanto richiedono disponibilità elevata, visibilità, sicurezza e gestibilità. La topologia di gruppo o "farm" di BizTalk Server 2006 consente di gestire una matrice di server per garantire scalabilità e ridondanza.

Il meccanismo di persistenza di BizTalk Server 2006 per l'archiviazione dello stato del processo ha una sicurezza affidabile integrata per proteggere la privacy dello stato persistente, che potrebbe essere importante per motivi normativi. Il monitoraggio delle attività aziendali (BAM) di BizTalk Server 2006 offre visibilità a livello aziendale appropriato sui processi in esecuzione in modo sicuro. Infine, questi scenari richiedono spesso il supporto per formati di messaggi eterogenei e protocolli di trasporto, inclusi i sistemi legacy.

Per questi motivi, BizTalk Server 2006 è in genere la scelta migliore per le organizzazioni destinate ai profili standard, avanzati e dinamici. Queste organizzazioni in genere considerano lo scenario del processo aziendale a esecuzione prolungata molto importante per l'azienda e molto comune all'interno dell'azienda; quindi acquistano BizTalk Server 2006 in modo specifico per stabilire una piattaforma standardizzata per loro.

Tuttavia, WF potrebbe essere una scelta migliore per le organizzazioni che si trovano nel profilo APIO di base. Queste organizzazioni in genere non vogliono investire nella creazione di una piattaforma applicativa standardizzata. Al contrario, stanno cercando di ridurre al minimo i costi e i costi di licenza e hardware di BizTalk Server 2006 potrebbero essere proibitivi. L'eccezione a questa guida è quando sono previsti requisiti per scalabilità elevata, monitoraggio e supporto per un'ampia gamma di formati di messaggi e protocolli di trasporto. In questo caso, anche se l'organizzazione è riluttante a investire nella propria piattaforma applicativa, il costo della creazione delle funzionalità di hosting e messaggistica da zero probabilmente supererebbe i costi di BizTalk Server 2006.

Figura 5. Scenario dell'aggregatore di servizi Web

Sia le orchestrazioni di BizTalk Server che i flussi di lavoro di WF hanno un forte supporto per i servizi Web che utilizzano esternamente da un flusso di lavoro e per esporre il flusso di lavoro come servizio Web. Pertanto, per la compilazione di soluzioni Di aggregatore di servizi Web, proprio come per le soluzioni di processo aziendale a esecuzione prolungata, la scelta è determinata dal profilo aziendale e dai requisiti di hosting.

Se il servizio Web di aggregazione è solo per aggregare altri servizi Web, la possibilità di BizTalk Server 2006 di supportare formati di messaggi eterogenei e protocolli di trasporto aggiunge poco valore. Tuttavia, se il servizio deve anche aggregare i dati da ambienti legacy non esposti come servizi Web, BizTalk Server 2006 aggiungerà valore.

Poiché il modello di utilizzo è rapido e sincrono, le chiamate di richiesta/risposta sincrone, la durabilità dei messaggi fornita da BizTalk Server 2006 in genere non è importante. Infatti, la latenza introdotta dalla persistenza al MessageBox è effettivamente una responsabilità. Il valore principale fornito da BizTalk Server 2006 per questo scenario è la possibilità di gestire la distribuzione in molti server e di monitorare le istanze in esecuzione. La funzionalità BAM di BizTalk Server 2006 può essere utile anche per il monitoraggio dei contratti di servizio soddisfatti.

Per questi motivi, WF è una scelta molto valida per l'implementazione di aggregatori di servizi Web, in particolare nelle organizzazioni nei profili Basic e Standardizzati. Un esempio in cui BizTalk Server 2006 può essere vantaggioso è uno dei quali è necessario gestire un numero elevato di endpoint per organizzazioni client diverse. La configurazione della porta di ricezione e del percorso di ricezione di BizTalk Server 2006 gestisce in modo specifico questa operazione. In questo caso, anche i certificati potrebbero essere importanti e il supporto di BizTalk Server 2006 per configurare e gestire i certificati e applicarli alla crittografia/decrittografia potrebbe essere utile.

Future-Proofing

Si vuole assicurarsi che gli investimenti in costi di licenza software, nell'apprendimento di una tecnologia del flusso di lavoro e nella creazione di componenti del flusso di lavoro specifici, forniscano il valore più possibile in futuro. Oltre a scegliere il flusso di lavoro appropriato per lo scenario e l'organizzazione del flusso di lavoro specifici, è necessario prendere in considerazione anche le mappe stradali del prodotto per BizTalk Server 2006 e WF. Non c'è una risposta semplice per questo. I commenti che seguono non fanno un argomento forte per scegliere una delle due tecnologie; sono invece punti dati per facilitare la decisione.

Elementi aggiunti da BizTalk Server 2006 R2

BizTalk Server 2006 R2 aggiunge due funzionalità che potrebbero influire sulla piattaforma del flusso di lavoro scelta: gli adapter WCF e gli intercettori BAM per WCF e WF.

Adapter WCF

Se il team ha adottato Windows Communication Foundation (WCF) come tecnologia standard per l'implementazione di servizi nella compilazione di SOA, il fatto che BizTalk Server 2006 non disponesse del supporto WCF potrebbe non essere stato qualificato come piattaforma per la compilazione e l'hosting di servizi Web compositi. Questo potrebbe aver spinto l'utente verso WF, anche se BizTalk Server 2006 era in caso contrario una corrispondenza ottimale per gli scenari e il profilo APIO.

Fortunatamente, con l'introduzione di un'ottima integrazione WCF in BizTalk Server 2006 R2, questo non è più un problema. BizTalk Server 2006 offre ora una forte integrazione con WCF ed è una piattaforma eccellente per la creazione di servizi compositi da servizi più granulari e l'esposizione di questi servizi compositi come servizi WCF.

Intercettore BAM per WF

La seconda funzionalità pertinente di BizTalk Server 2006 R2 è l'introduzione dell'intercettore BAM per WF. Se il monitoraggio delle attività aziendali è una funzionalità importante della soluzione, è possibile che sia stato effettuato il push verso l'uso di BizTalk Server 2006, solo per sfruttare i vantaggi di BAM, quando WF era altrimenti più adatto allo scenario in uso. Con l'intercettore BAM per WF, è possibile scegliere WF se è la tecnologia del flusso di lavoro appropriata per il progetto e continuare a usare BAM come soluzione di monitoraggio delle attività aziendali aziendali.

BAM è una funzionalità di BizTalk Server 2006 che fornisce un framework per l'acquisizione di eventi e dati da orchestrazioni e flussi di messaggi di BizTalk Server e la presentazione dei dati in un portale per fornire all'utente aziendale visibilità end-to-end sul processo aziendale. Un aspetto potente del funzionamento di BAM per le applicazioni BizTalk Server 2006 è che il monitoraggio BAM può essere configurato (o "instrumentato") dopo la distribuzione di un'applicazione BizTalk Server 2006, senza richiedere modifiche agli artefatti di codice bizTalk Server 2006.

BAM è progettato come soluzione di monitoraggio delle attività aziendali a livello aziendale; pertanto, è possibile che le applicazioni non BizTalk Server 2006 feed di eventi e dati in BAM. Tuttavia, le API per questa operazione richiedono la scrittura di un po' di codice nelle applicazioni esterne. L'intercettore BAM WF in BizTalk Server 2006 R2 offre la possibilità di instrumentare i flussi di lavoro di WF per BAM in modo più semplice e senza richiedere modifiche al codice. Usando gli intercettori BAM, è possibile tenere traccia dei processi aziendali senza ricompilare la soluzione WF o WCF; l'integrazione viene eseguita tramite un file di configurazione.

Estensioni di BizTalk Server 2006 per WF SDK

Le estensioni di BizTalk Server 2006 per WF SDK sono state annunciate e abbassate di livello a TechEd 2007. Questo SDK offre un meccanismo semplice per l'hosting di flussi di lavoro WF in BizTalk Server 2006. Questo strumento è destinato agli sviluppatori .NET che creano flussi di lavoro WF oggi e cercano un modo semplice per ottenere un hosting affidabile e scalabile di tali flussi di lavoro.

L'SDK fornisce due attività WF personalizzate, un'attività btsReceive e un'attività btsSend, che possono essere usate all'interno di un flusso di lavoro WF per la ricezione e l'invio di messaggi tramite BizTalk Server 2006. Gli sviluppatori definiscono wcf DataContracts per i messaggi in ingresso e in uscita e un ServiceContract per definire il modello di scambio di messaggi. All'interno del flusso di lavoro di WF, le attività btsReceive e btsSend sono configurate per l'uso dell'ServiceContract, come illustrato nella figura 6.

Figura 6. Attività btsReceive e btsSend per l'uso in ServiceContract definito

Dopo aver completato e compilato il flusso di lavoro WF, fare clic con il pulsante destro del mouse sul progetto del flusso di lavoro e selezionare Genera orchestrazione per generare automaticamente un'orchestrazione wrapper (vedere figura 7) che avvierà il flusso di lavoro WF e instradare i messaggi di BizTalk Server 2006 sia da che verso di esso.

L'orchestrazione wrapper generata automaticamente contiene schemi per i messaggi definiti nel ServiceContract. Contiene inoltre le forme di orchestrazione e il codice di orchestrazione di BizTalk Server per la ricezione di un messaggio bizTalk Server 2006, la creazione e l'avvio dell'istanza del flusso di lavoro, il passaggio di messaggi in ingresso nell'istanza del flusso di lavoro, la ricezione dei messaggi in uscita e l'inoltro al motore di messaggistica di BizTalk Server 2006. Per completare l'hosting del flusso di lavoro di WF, è sufficiente compilare e distribuire l'orchestrazione wrapper e associarla usando il normale meccanismo bizTalk Server 2006.

Figura 7. Generazione automatica di un'orchestrazione wrapper

Oltre a sfruttare i vantaggi del meccanismo di hosting affidabile e scalabile dei flussi di lavoro di BizTalk Server 2006 per WF, le estensioni bizTalk Server 2006 per WF SDK consentono di sfruttare l'infrastruttura di messaggistica bizTalk Server 2006. È quindi possibile sfruttare i numerosi adapter disponibili per l'inserimento e l'uscita dei messaggi da BizTalk Server 2006, nonché l'elaborazione della pipeline, incluse le funzionalità di mapping.

Quanto è potente, le estensioni di BizTalk Server 2006 per WF SDK devono essere usate come strumento per consentire agli sviluppatori WF di distribuire i propri flussi di lavoro oltre a BizTalk Server 2006, non come sostituzione delle orchestrazioni negli scenari in cui è stato identificato BizTalk Server 2006 come strumento appropriato. Esistono alcune forme WF che non funzionano quando vengono racchiuse in un'orchestrazione. Questo perché l'hosting dei flussi di lavoro di WF all'interno di BizTalk Server 2006 tramite le estensioni di BizTalk Server 2006 per WF SDK non fornirà lo stesso comportamento di hosting delle orchestrazioni native. L'SDK include un elenco di domande frequenti (incluso nella Guida introduttiva) che descrive queste differenze.

Conclusione

BizTalk Server 2006 e Windows Workflow Foundation sono gli strumenti principali di Microsoft per implementare soluzioni flusso di lavoro nelle categorie Application and Enterprise Integration Workflow. Per scegliere quale sia la scelta più adatta al progetto, è prima necessario identificare quali scenari del flusso di lavoro sono destinati.

Usare quindi la tabella nella figura 8 per visualizzare la tecnologia del flusso di lavoro consigliata per lo scenario. Per il flusso di lavoro all'interno di un'applicazione, è consigliabile usare WF. Per la maggior parte dei processi aziendali basati su server e scenari B2B, è consigliabile BizTalk Server 2006.

Figura 8. Tecnologie del flusso di lavoro specifiche dello scenario

Sia per il processo aziendale a esecuzione prolungata che per gli scenari di aggregatore di servizi Web, entrambe le tecnologie possono essere applicate in modo influenzato. Per questi scenari, è consigliabile valutare il profilo APIO di destinazione corrente e a breve termine dell'organizzazione. Le organizzazioni che si trovano o si spostano verso i profili avanzati o dinamici devono usare BizTalk Server 2006 per questi scenari. Le organizzazioni nei profili Basic e Standard possono usare WF in modo efficace per questi scenari.

Infine, è necessario prendere in considerazione le date di rilascio e la durata desiderata della soluzione, in relazione alla roadmap del prodotto per BizTalk Server 2006 e WF. Usando questo framework e le indicazioni contenute in questo articolo, è necessario essere in grado di scegliere il flusso di lavoro appropriato per il progetto.

Appendice

Dispelling Misconceptions About BizTalk Server 2006 vs. WF

Di seguito sono riportati alcuni errori comuni relativi a WF e BizTalk Server 2006 e gli argomenti chiari che vengono usati per dissiparli:

• WF è la sostituzione di BizTalk Server 2006.No. Poiché WF è l'offerta "più recente e più grande" di Microsoft per i flussi di lavoro di programmazione, molti che non hanno familiarità con BizTalk Server 2006 inizialmente presuppongono che sia stato reso obsoleto con il rilascio di WF. La risposta semplice a correggere questa impressione è che WF è un framework di sviluppo di basso livello per la creazione di tutti i tipi di flussi di lavoro, mentre BizTalk Server 2006 è un prodotto server completo con funzionalità avanzate per una categoria specifica di scenari di flusso di lavoro: Enterprise Integration. Vedere la figura 1.
  WF fornisce solo un piccolo subset di questa funzionalità: Flusso di lavoro e regole business. Anche se WF potrebbe essere una soluzione più semplice e conveniente per scenari che non richiedono tutte le altre funzionalità fornite da BizTalk Server 2006, in nessun modo sostituisce BizTalk Server 2006 per gli scenari di integrazione aziendale principali progettati per il supporto di BizTalk Server 2006.
• BizTalk Server sta per andare via.No. Un malconcepimento simile è l'impressione che poiché WF è stato rilasciato come strumento del flusso di lavoro del futuro e BizTalk Server non è ancora stato riscritto per usare WF, Microsoft non investe più in BizTalk Server e alla fine lo sostituirà con un nuovo prodotto basato su WF. Questo non è solo il caso; BizTalk Server è stato un prodotto di grande successo e l'area Enterprise Integration che ha come obiettivo continua a essere un'area che Microsoft si impegna a supportare.
• è necessario scegliere BizTalk Server 2006 su .NET Framework.No. Potrebbe essere allettante per gli sviluppatori .NET che non hanno familiarità con BizTalk Server 2006 scegliere WF su BizTalk Server 2006, proprio sulla base del fatto che preferirebbero usare .NET "puro". Tuttavia, questo non è davvero un criterio utile; BizTalk Server 2006 è basato su .NET Framework.
  BizTalk Server 2006 rappresenta infatti oltre 2 milioni di righe di codice .NET che possono essere applicate alla soluzione, risparmiando tempo, problemi e costi di sviluppo delle funzionalità da zero. Inoltre, la programmazione di BizTalk Server 2006 viene eseguita all'interno di Microsoft Visual Studio .NET e i componenti vengono compilati e distribuiti come assembly .NET. Inoltre, i progetti BizTalk Server 2006 più significativi combinano componenti bizTalk Server 2006 con componenti .NET personalizzati; Pertanto, lo sviluppo di BizTalk Server 2006 deve essere considerato uno sviluppo .NET specializzato, invece di qualcosa che è esterno o diverso.
  La domanda reale è se le funzionalità di BizTalk Server 2006 forniscono un valore sufficiente per lo scenario del flusso di lavoro specifico per giustificare i costi di licenza. Non vuoi usare uno sledgehammer per appendere immagini; né si desidera utilizzare il martello di un carpentiere per schiacciare grandi rocce.
• La maggior parte delle funzionalità vince.Una scelta scadente. è possibile inserire una matrice di funzionalità che confronta le funzionalità granulari di WF con quelle di BizTalk Server 2006. Tuttavia, questo confronto non sarebbe molto utile; BizTalk Server 2006 dispone di un numero così elevato di funzionalità destinate specificamente allo spazio Enterprise Integration. In caso contrario, i confronti delle funzionalità non saranno significativi. BizTalk Server 2006 avrebbe probabilmente vinto, in termini di numero di caselle di controllo delle funzionalità; Tuttavia, si tratta di un confronto tra apples e arancioni, se tali funzionalità non sono correlate allo scenario del flusso di lavoro di destinazione.

Riconoscimenti

Vorrei ringraziare Paul Andrew e Kris Horrocks, e tutti coloro che hanno letto questo articolo.

Altre informazioni

• "Estensioni BizTalk Server 2006 R2 per Windows Workflow Foundation SDK V1": https://www.microsoft.com/downloads/details.aspx?FamilyID=b701c00f-cdc1-4edb-a975-b9412263ec6e& displaylang=en
• Blog di Paul Andrew (fornisce una panoramica dell'SDK): https://blogs.msdn.com/pandrew/archive/2007/11/01/just-released-biztalk-server-2006-extensions-for-windows-workflow-foundation-sdk.aspx
• Forum MSDN per WF (in cui è possibile discutere l'SDK): https://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=122& SiteID=1

Informazioni sull'autore

Kent Brown è il direttore e senior architetto della Enterprise Integration Practice a ventisix New York, un partner di consulenza Microsoft Gold Certified a New York City. È stato entusiasta di BizTalk Server sin dalla sua nascita nel 2000 e ha svolto un ruolo evangelico intorno al prodotto negli ultimi sette anni. Kent è membro del team microsoft BizTalk Virtual Technical Specialist, nonché di microsoft Connected Systems Developer MVP. È il fondatore e leader del gruppo NYC Connected Systems Users Group (http://www.NYCCSUG.org).