WF 4 o BizTalk 2010?

Question

Ho una domanda - BizTalk o WF? E lasciatemi chiarire che realizzo le tecnologie analoghe dietro i primi tre artefatti e mi rendo conto che potrei costruirli, ma non trovo che siano integrati nella WF e quindi sto cercando di capire perché ne utilizzerei uno tecnologia sull'altro.

1. Trasformazioni
2. Associazioni
3. Porti/adattatori
4. BizTalk futuri

Trasformazioni

E 'molto bello che BizTalk supporta in modo nativo, con i progettisti avanzate per l'avvio, la capacità di produrre schemi e mappe. Inoltre, mi piace il fatto che tutto venga trasformato perché non devo preoccuparmi del mio punto di integrazione all'interno del mio flusso di lavoro perché è sempre in un formato coerente che mitiga i miei rischi mentre le mie integrazioni mutano - devo solo refactoring gli schemi e le mappe .

Al contrario, con WF, non ho quel built-in di lusso quindi mi manca qualcosa o BizTalk ha un +1 qui?

Associazioni

Attacchi sono un altro pezzo completamente incapsulato di funzionalità in BizTalk. Posso letteralmente impostare il mio flusso di lavoro per avere qualsiasi legame che desidero a causa del suddetto artefatto, il che significa che durante il test potrei legarmi a un file system e durante la produzione potrei associarmi a un servizio.

Al contrario, con WF, non ho quel built-in di lusso quindi mi manca qualcosa o BizTalk ha un +2 qui?

port/adattatori

Questo è probabilmente il più grande manufatto che esiste in BizTalk - IMHO. La quantità di sforzi necessari per astrarre le connessioni fisiche in numerose implementazioni concrete, specialmente in un'organizzazione molto ampia in cui alcune di quelle concrete raggiungono un file system rudimentale rispetto a SOAP/REST e in roba simile a un mainframe e MSMQ IBM. Gli adattatori fisici delle porte di BizTalk, che eseguono automaticamente i dati grezzi attraverso le trasformazioni prima di inviare il flusso di lavoro al messaggio, sono abbastanza semplici ed eleganti.

Al contrario, con WF, non ho quel built-in di lusso quindi mi manca qualcosa o BizTalk ha un +3 qui?

BizTalk Future

Infine, vorrei ricordare che dalla mia ricerca lo stesso team di persone che hanno costruito BizTalk sta costruendo WF - che è grande! Inoltre, la visione a lungo termine di Microsoft è questa nuova parola d'ordine "server di integrazione" ed è effettivamente una vasta gamma di framework liberamente accoppiati che forniscono ciò che BizTalk fa oggi. E questo sforzo ha molto senso per me a causa dello sforzo di Azure - che sono sicuro di contribuire a questo. Tuttavia, ho bisogno di implementare una soluzione oggi che funzionerà tra 15 anni, ma ho anche bisogno di capire quali pezzi dovrò usare per metterlo insieme se utilizzo il WF su BizTalk. Per favore forniscimi le tue esperienze.

Answer 1

(Disclaimer: la mia esperienza WF è limitata a WF3.0, quindi potrei essere dietro sviluppi recenti della WF)

BizTalk è più adatto ai flussi di lavoro inter-sistema, inter-dipartimentale e interaziendale di Business Process (BPEL) - vale a dire preoccupazioni aziendali. IMO WF è stato finora posizionato più verso il sistema interno o le preoccupazioni delle applicazioni. Ma ci sono indubbiamente aree sempre più grigie in quanto sembra che entrambi stiano convergendo verso Azure + Appfabric.

Sembra che stai guardando WF per l'integrazione?

Trasformazioni - senza dubbio una buona cosa in BizTalk - dato che è possibile mappare visivamente o direttamente in XSLT, è possibile trasformare rapidamente formati di messaggio sui porti o orchestrazioni, e lasciare la tecnologia fisico utilizzato come un ripensamento - si vale a dire può implementare il tuo design a livello logico e non essere "impantanato" in nessuna tecnologia specifica (MQ, WCF, SQL, FTP ecc.).

Un avvertimento: la gestione degli schemi può diventare piuttosto un problema: ogni messaggio ha uno schema, che richiede un unico XMLNS # Root su tutte le app su BizTalk. E puoi essere "agnostico" e utilizzare schemi canonici per i tuoi flussi interni: sono necessarie quindi buone regole di denominazione, configurazione e gestione. La gestione dello schema diventa particolarmente onerosa se si abbina BizTalk a molti servizi WCF/WebService - ci sarà uno schema di richiesta e risposta per ciascun servizio consumato (è possibile condividere schemi comuni se si utilizza MessageContract).

Attacchi - avete praticamente capito. Inoltre, se si utilizzano collegamenti diretti (message box), è possibile scegliere di avere più destinazioni di ricezione in arrivo o inviare destinazioni semplicemente aggiungendo una nuova porta con i filtri appropriati. Questa capacità di pubblicazione secondaria costituisce la base del toolkit ESB per Bizalk. Anche i binding per diversi ambienti (Dev, UAT, Prod etc) sono gestiti in modo corretto.

Adattatori - concordato: passare da un file a MQ Series è semplice come cambiare la configurazione della porta. BizTalk funziona molto bene con MSMQ e IBM MQ.

Inoltre, non sottovalutare la quantità di sforzi per amministrare e mantenere una soluzione EAI/BP: l'integrazione di solito è di importanza cruciale per un'azienda e gli errori di tracciamento ed evita i tempi di fermo sono essenziali. BizTalk ha i seguenti vantaggi operativi:

• gestione operativa - Tracking/tracciabilità, gestione di messaggi sospesi, pacchetti di integrazione SCOM, ecc capacità/Failover
• Scalabilità/Clustering, tentativi di adattamento, la limitazione automatica, ecc
• Monitoraggio e Eventing - BAM

IMO le grandi 'lati negativi' a BizTalk sono:

• Costo
• Tempo di accelerazione per diventare esperti nello sviluppo (BTS ha i suoi capricci, ad es.zombie e che definiscono le definizioni BAM in file XLS e XML)
• Tempo rampa di accelerazione per i professionisti della rete/amministratore per ottenere qualificato per la gestione operativa

Linea di fondo: se si sta facendo l'integrazione tra 2 o 3 applicazioni con un piccolo il numero di messaggi non critici passa quindi a una rotta proprietaria o WF, ma se si sta esaminando una soluzione a livello aziendale, un motore EAI/BPEL come BizTalk sarebbe la soluzione da seguire.

Answer 2

Ottimo post e risposta.

Le persone che iniziano a vedere i clienti considerano WF per i progetti di integrazione ora che WF Manager è disponibile? In precedenza id mai vista davvero nessuno considera WF + WCF per qualcosa di diverso dalle aree di piccole dimensioni o di nicchia a causa della mancanza di un ambiente di hosting maturo. Le persone stanno iniziando a vedere quel cambiamento nel mondo reale?

Posso anche aggiungere il mio punto di vista sugli accenamenti degli stuart. Non sono d'accordo al 100% con i suoi commenti.

• Costo

costo è neanche tanto di un problema come ha usato essere. BizTalk su Azure può modificare questa situazione per te in modo da poter ottenere l'installazione con un modello di pagamento as you go. Mentre c'è ancora un costo di licenza (è solo al mese) quando si considera la gamma di tipi di soluzione si può costruire il suo rapporto qualità-prezzo non male. Penso che le persone spesso faticano a quantificare il costo di una soluzione di costruzione personalizzata e assumono semplicemente perché biztalk ha una licenza che deve essere più costosa. Quando le persone discutono sul costo di BizTalk, spesso chiedo perché dovrebbero usare Sharepoint per collaborare quando possono semplicemente usare una cartella condivisa e l'e-mail. Penso che il costo sia relativo, per alcune aziende può essere più di quello che otterresti se avessi solo un paio di processi di integrazione, ma per altri potrebbe essere un grande investimento.

• rampa su/Dev

Sono d'accordo BizTalk è una competenza specialistica set, ma la sua non è poi così diverso da uno sviluppatore su qualsiasi altra piattaforma. A volte un'azienda vuole mettere uno sviluppatore .net senza esperienza su sharepoint o dynamics CRM e poi si chiede perché facciano degli errori, non è necessario essere un genuis per risolverlo. Ci sono alcune grandi risorse là fuori per aiutarti a diventare uno sviluppatore biztalk, soprattutto rispetto ad alcuni prodotti della concorrenza, id vederlo come un punto di forza su WF secondo me. Il rischio principale per lo sviluppo di BizTalk è che puoi facilmente farlo davvero male se non sai cosa stai facendo. Questo è un errore comune nel settore, ma ho visto questo fatto con altre implementazioni della piattaforma molte volte

(Nota su "WF come concorrente" vedo WF come un concorrente su un sottoinsieme di ciò che BizTalk fa, ma a lungo termine Penso che si completano a vicenda in una situazione troppo)

• Rampa/Amministratore

Questo non è realmente qualcosa di diverso ad ogni nuovo prodotto si sarebbe introducendo, la vostra azienda avrebbe bisogno di lavorare con il tuo professionista IT per metterli in condizione di supportare e mantenere il prodotto che hai mai utilizzato. La sua non è la cosa più facile da ottenere un buon amministratore di BizTalk, ma ci sono molte risorse là fuori per addestrare le persone e ci sono partner disponibili in questo spazio se si desidera esternalizzarlo.

Mentre WF è un prodotto più semplice Im non sono così sicuro che il lato dell'implementazione di questo da un punto di vista amministrativo sarebbe molto più semplice. Hai ancora bisogno di un server SQL da qualche parte che si esibirà davvero bene. La strumentazione WF per gli amministratori è molto meno matura e non penso che lo spazio di supporto per l'amministrazione della WF sia maturo.

Si potrebbe desiderare di checkout il libro di sotto del quale ha un capitolo (7 credo) su uno scenario in cui essi consideravano BizTalk o WF + AppFabric, alcuni punti di discussione interessanti

http://www.packtpub.com/applied-architecture-patterns-microsoft-platform/book#chapter_7