Sdílet prostřednictvím

BizTalk Server 2006 nebo WF? Výběr správného nástroje pracovního postupu pro váš projekt

  • Článek

Kent Brown

twentysix New York (www.26ny.com)

listopad 2007

Revize února 2008

Platí pro:

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

Shrnutí: Tento článek obsahuje pokyny pro výběr mezi Microsoft BizTalk Server 2006 a Windows Workflow Foundation v různých scénářích pracovních postupů integrace aplikací a podnikových prostředí. (16 vytištěných stránek)

Obsah

Úvod

Proces výběru správného nástroje pracovního postupu

Běžné scénáře pracovních postupů

Vše je v hostiteli

Workflow-Technology Doporučení

Future-Proofing

Závěr

Dodatek

Poděkování

Další informace

Úvod

Pracovní postup je všudypřítomný v každodenních obchodních procesech, takže běžnou potřebou je najít programovací nástroje, které přímo podporují vytváření řešení pracovních postupů. Microsoft BizTalk Server 2006 a Windows Workflow Foundation (WF) jsou dva primární nástroje od Microsoftu pro programovací řešení pracovních postupů. Vzhledem k jejich zjevnému překrývání má však mnoho architektů a vývojářů potíže s rozhodováním, která technologie pracovního postupu dává smysl pro jejich účely.

To platí zejména s ohledem na skutečnost, že WF byl v budoucnu jasně označen jako upřednostňovaná technologie pracovních postupů, zatímco BizTalk Server 2006 je stále prémiovým serverem pro podnikovou integraci. Dokud BizTalk Server orchestrace plně nepodporuje WF, musí se architekti a vývojáři pečlivě rozhodnout, do které technologie investovat.

Jednou z výzev při výběru správné technologie pro implementaci pracovního postupu je, že pracovní postup může znamenat mnoho věcí, mezi které patří:

  • Tok obrazovek uživatelského rozhraní, se kterými uživatel interaguje, aby dokončil úlohu.
  • Tok obchodní logiky v rámci aplikace nebo služby
  • Interakce několika lidských bytostí za účelem dokončení obchodního procesu
  • Koordinace více výměn zpráv mezi systémy pro zpracování obchodní transakce.
  • Koordinace kroků pro extrakci, transformaci a načítání dat (ETL) do databáze

I když je spektrum scénářů pracovních postupů široké, je užitečné je seskupit do čtyř širokých kategorií: Pracovní postup pro člověka, Pracovní postup aplikace, Pracovní postup podnikové integrace a pracovní postup Integrace Dat.

Ze čtyř hlavních kategorií pracovních postupů jsou pracovní postup aplikace a pracovní postup podnikové integrace dvě oblasti, ve kterých je pro lidi nejobtížnější zvolit technologii. Scénáře lidských pracovních postupů a Integrace Dat pracovních postupů jsou z hlediska výběru nástrojů poměrně jednoduché. Pracovní postup pro člověka vyžaduje uživatelské rozhraní a je často zaměřený na dokumenty, takže microsoft Office SharePoint Server 2007 je doporučenou platformou pro vytváření řešení lidských pracovních postupů. Microsoft SQL Server Integration Services (SSIS) je doporučený nástroj pro Integrace Dat scénáře.

Tento článek obsahuje pokyny pro výběr mezi BizTalk Server 2006 a WF ve scénářích pracovních postupů aplikací a pracovních postupů podnikové integrace.

Modul orchestrace BizTalk Server

Modul orchestrace BizTalk Server byl vždy jednou z atraktivních funkcí BizTalk Server. Když byl zaveden, byl to nejlepší nástroj, který byl od Microsoftu k dispozici pro provádění programování zaměřeného na pracovní postupy. BizTalk Server orchestrace poskytuje vizuální programovací prostředí pro vývoj komponent pro řízení složitých vícekrokových toků zpráv k dokončení konkrétní obchodní transakce.

Artefakty kódu orchestrace BizTalk Server se velmi podobají diagramům aktivit vývojového diagramu nebo UML (Unified Modeling Language), které může obchodní analytik vytvořit k dokumentaci obchodního procesu. Tyto artefakty pak lze zkompilovat a spouštět v modulu runtime orchestration-engine, který poskytuje služby, jako jsou dlouhotrvající transakce a kompenzace, stálost, odolnost proti chybám a zotavení po havárii, které jsou zásadní pro vytváření systémů, které automatizují klíčové obchodní transakce.

Základ pracovního postupu pro budoucnost

Existují sice různé kategorie scénářů pracovního postupu, ale z programovacího hlediska existuje dostatek společných scénářů, aby bylo vhodné pokusit se vytvořit společnou architekturu pro vývoj pracovních postupů. Modul orchestrace v BizTalk Server je výkonný, ale nikdy nebyl navržen tak, aby se používal mimo BizTalk Server. Proto není možné efektivně přeučovat BizTalk Server orchestraci pro ostatní kategorie pracovních postupů.

WF, která je vydána v rozhraní Microsoft .NET Framework 3.0, zavádí vizuální programovací model zaměřený na pracovní postupy do rozhraní .NET Framework, který je navržen tak, aby byl dostatečně obecný a rozšiřitelný, aby ho bylo možné v budoucnu použít ve všech scénářích souvisejících s pracovními postupy na platformě Windows. Tým, který vytvořil WF, dokázal přijmout nejlepší koncepty BizTalk Server orchestračního modulu, zvážit požadavky na širší sféru scénářů pracovních postupů a navrhnout architekturu, která je dostatečně flexibilní, aby je všechny podporovala.

Jako důkaz flexibility WF používá Microsoft Office SharePoint Server 2007 k implementaci řešení pracovních postupů pro člověka. Záměrem je, aby dodavatelé BPM třetích stran také vytvářeli svá řešení na základě WF, namísto vytváření vlastních vlastních modulů pracovních postupů. již tak učinilo několik dodavatelů. Jednotliví vývojáři mohou také použít WF k implementaci vlastního pracovního postupu aplikace v aplikacích .NET Framework. Plán je také pro budoucí verzi BizTalk Server implementovat modul orchestrace ve WF pro implementaci řešení pracovních postupů podnikové integrace.

Obrázek 1: Použití správného nástroje pracovního postupu: BizTalk Server 2006 vs. WF

Proces výběru správného nástroje pracovního postupu

Naší metodou poskytování pokynů, které vám pomůžou rozhodnout, který nástroj pracovního postupu bude vyhovovat vašemu projektu, bude definovat nejběžnější scénáře pracovního postupu, abyste mohli určit scénář nebo kombinaci scénářů, které nejlépe vyhovují vašemu projektu. Pak poskytneme konkrétní pokyny pro každý scénář, který nástroj (BizTalk Server 2006 nebo WF) je nejvhodnější a proč. Kromě toho použijeme model Optimalizace infrastruktury aplikační platformy (APIO) – model pro hodnocení vyspělosti aplikační platformy a možností vývoje v organizaci – k poskytování pokynů pro konkrétní organizaci ve scénářích, ve kterých lze oba nástroje efektivně používat. Nakonec se podíváme na plán pro BizTalk Server 2006 a WF, abyste mohli učinit nejlepší rozhodnutí pro budoucí testování aplikací, které dnes vytváříte.

Běžné scénáře pracovních postupů

I po omezeném rozsahu na kategorie pracovních postupů integrace aplikací a podnikových aplikací stále existuje široká škála scénářů pracovních postupů, které je potřeba zvážit. Jak ukazuje obrázek 2, na jedné straně spektra jsou scénáře, ve kterých je WF jasně správnou volbou. Příkladem je schopnost pracovního postupu v rámci produktu nezávislého dodavatele softwaru ( ISV), kde licenční náklady a složitost nasazení BizTalk Server 2006 by byly neúnosné. V tomto scénáři se jako isV zajímáte o výrobu komerčního softwaru a dodatečné programovací úsilí, které je potřeba k hostování WF bez licenčních poplatků, je přiměřenou investicí.

Obrázek 2. Integrace a kontinuum pracovních postupů

Na druhé straně spektra jsou řešení podnikové integrace, která jsou postavena v rámci podnikového IT oddělení, kde je jasně BizTalk Server 2006 správnou volbou. V tomto scénáři se chcete zaměřit na vytváření obchodních hodnot, místo investic do budování "instalatérství", aby vaše řešení bylo škálovatelné, spolehlivé a spravovatelné. Takže licenční náklady BizTalk Server 2006 stojí za to, protože poskytuje.

Většina projektů spadá někam mezi tyto dva konce spektra. Následuje několik běžných scénářů, ve kterých požadavky určují řešení pracovního postupu:

  • Kontroler stránek uživatelského rozhraní – běžným požadavkem ve složitých aplikacích je vynucování navigace na obrazovce uživatelského rozhraní podle obchodních pravidel konkrétního implementovaného případu použití. Nejjednodušším příkladem je průvodce, který uživatele provede předepisovací sadou obrazovek k provedení úkolu. Často se jedná o složitější graf možností navigace na obrazovce, který je založený na akcích uživatele a stavu dat.
    Model MVC (Model-view-controller) je klasická technika pro vytažení této navigační logiky ze samotných formulářů, aby byly jednodušší a opakovaně použitelné v různých případech použití. Kontroler ve vzoru MVC je ve skutečnosti pracovní postup nebo stavový počítač; Proto je přirozené hledat nástroj pracovního postupu při implementaci těchto typů aplikací.
  • Dlouhotrvající obchodní logika – Pokud je k dokončení obchodní transakce potřeba mnoho kroků, může se uživatel muset zastavit uprostřed procesu nebo počkat na akce od jiných uživatelů nebo systémů, než bude pokračovat. Možnost dočasného pozastavení (neboli "hibernace") procesu a jeho následného restartování na základě externích událostí je pro myšlenku pracovního postupu zásadní. Bez modulu pracovních postupů jsou vývojáři nuceni ručně navrhovat a kódovat mechanismy pro ukládání stavu nedokončeného procesu a odvolávání tohoto stavu při pokračování procesu. Díky dobře navrženému modulu pracovních postupů se tato funkce podporuje nativně bez další práce pro vývojáře.
  • Dynamicky aktualizovatelný tok procesu – i když se zdá, že je možné nejprve kodifikovat obchodní procesy do dobře definovaných sekvenčních kroků, lidé často musí upravit tok uprostřed toku tak, aby zohlednil reálné situace. V procesu schvalování výdajů může být výchozím schvalovatelem vedoucí zaměstnance, který sestavu výdajů odeslal. Nadřízený se však může rozhodnout delegovat úkol na sekretáře (například proto, že manažer má namířeno hrát golf) nebo eskalovat schválení nadřízenému (například proto, že si manažer není jistý zásadami pro konkrétní výdaje). Umožnit uživateli aktualizovat tok je často jednodušší než se snažit předem předvídat každou možnou permutaci toku.
  • Abstrakce pravidel z obchodní logiky: V tomto scénáři je vaším cílem oddělit obchodní pravidla od ostatních obchodních logik. Dobrým příkladem jsou pravidla ověřování formulářů. V programu Žádost o hypotéku může formulář Žádost o půjčku obsahovat jednu sadu pravidel ověření pole předtím, než uživatel může stisknutím tlačítka Odeslat odeslat žádost o půjčku. Pokud úvěrový úředník použije stejný formulář ke kontrole a schválení půjčky, jsou vyžadována další ověřovací pravidla, protože je v jiné fázi procesu.
    Implementace ověřovacích pravidel odděleně od formuláře usnadňuje opakované použití formuláře v různých scénářích a vynucování příslušných ověřovacích pravidel jednoduše vyhodnocením vhodné sady pravidel pro daný scénář.
  • Agregátor webových služeb – aplikace často musí agregovat data z několika různých webových služeb. V mnoha situacích může a měla by být samotná logika agregace extrahována z aplikace a zpřístupněna jako služba sama o sobě, kterou lze znovu použít z jiných aplikací. Tyto služby se často nazývají složené webové služby a jsou důležitým prvkem vyspělé architektury orientované na služby. Scénář agregátoru webové služby je obvykle synchronní a krátkodobě spuštěný.
  • Dlouhotrvající obchodní proces – Scénář Dlouhotrvající obchodní proces se v tomto článku používá k určení serverových procesů, které integrují více aplikací dohromady, zatímco obchodní logika se používá pro logiku v rámci jedné aplikace. Požadavky na tyto serverové dlouhotrvající obchodní procesy na vícevláknové, asynchronní chování, trvalost stavu procesu, korelaci zpráv s instancemi zpracování, škálovatelnost, spolehlivost, integritu transakcí atd. jsou mnohem vyšší než požadavky na obchodní logiku v rámci aplikace.
  • Proces B2B (Business to Business) – scénář procesu B2B je v podstatě stejný jako scénář dlouhotrvajícího obchodního procesu s tím rozdílem, že první scénář je kromě interních aplikací mezi organizacemi. Požadavky na zabezpečení jsou proto prvořadé. Kromě toho máte ještě menší kontrolu nad konkrétním datovým formátem a přenosem protokolu, protože je může diktovat váš obchodní partner; Proto potřebujete možnost podporovat širokou škálu formátů a protokolů a podporovat konfiguraci konkrétních výměn pro velký počet partnerů.
  • Abstrakce pravidel z obchodního procesu – Podobně jako ve scénáři Abstrakce pravidel z obchodní logiky platí tento scénář, pokud chcete oddělit obchodní pravidla od hlavního kódu ve scénáři Dlouhotrvající obchodní proces a scénář procesu B2B. Tento scénář vyžaduje vyšší úroveň výkonu a škálovatelnosti. Pravděpodobně bude také vyžadovat nástroje, které umožní neprogramátorům zobrazit a upravit pravidla.
  • Úložiště podnikových pravidel – V tomto scénáři je cílem vytvořit centrální úložiště sdílených pravidel, které lze vyvolat ze všech aplikací v podniku. To zajišťuje konzistenci ve všech aplikacích v organizaci pro použití důležitých obchodních pravidel. Podobně jako ve scénáři Abstrakce pravidel z obchodního procesu vyžaduje tento scénář vysokou škálovatelnost a nástroje, které umožňují neprogramovacím uživatelům zobrazit a upravit pravidla. Kromě toho tento scénář vyžaduje, aby úložiště pravidel bylo schopné existovat jako vlastní entita v podniku, s vlastním hostitelským mechanismem, který je oddělený od modulu pracovních postupů, a s komponentami nebo rozhraními API pro spouštění pravidel z různých aplikací.
  • Enterprise Service Bus (ESB) / Message Broker – mnoho organizací chce standardizovanou komunikační infrastrukturu pro všechny služby. Dvě nejběžnější topologie pro tuto infrastrukturu jsou ESB a Zprostředkovatel zpráv. Běžně se očekávají funkce této infrastruktury pro publikování a přihlášení k odběru zasílání zpráv a směrování na základě témat.

Model optimalizace infrastruktury aplikační platformy

V některých scénářích pracovních postupů BizTalk Server 2006 i WF uspokojivě splňují technické požadavky. U těchto scénářů je potřeba zvolit správnou technologii pracovního postupu odpovídající řešení potřebám konkrétní organizace. Pro účely vytváření doporučení, která se vztahují na vaši konkrétní organizaci, použijeme model Optimalizace infrastruktury aplikační platformy (APIO), jak je znázorněno na obrázku 3.

Obrázek 3: Model Optimalizace infrastruktury aplikační platformy (APIO)

Model APIO je technika pro profilaci vyspělosti organizace s ohledem na její aplikační infrastrukturu, architekturu a vývojové postupy. Cílem tohoto modelu je poskytnout organizacím plán pro optimalizaci jejich flexibility při poskytování IT řešení, která budou vyhovovat potřebám firmy.

Model APIO používá následující čtyři profily vyspělosti organizace:

  • Základní – organizace zacházejí se softwarem jako s náklady. Mají z velké části silonové aplikace s malou integrací nebo opětovným použitím. Aplikace, které mají, můžou být na různých platformách. Nemají konzistentní standardy pro infrastrukturu nebo techniky vývoje; nemají konzistentní architektonickou vizi.
  • Standardizované – organizace stále zacházejí se softwarem jako s náklady, ale podnikly kroky ke zlepšení efektivity. Mají architektonickou vizi a snaží se zvážit příležitosti pro opakované použití. Začali integrovat některé aplikace, ale většinou se jedná o integrace typu point-to-point.
  • Pokročilé – organizace nakládají se softwarem jako s aktivátorem pro firmy. Mají specializované architekty a jasnou architektonickou vizi. Mají mnoho služeb a dosahují vysoké úrovně opakovaného použití. Všechny základní obchodní procesy jsou automatizované a monitorované. Používají centralizovanou, zabalenou integrační platformu.
  • Dynamická – organizace považují software za strategické aktivum. Mají velmi vyspělé SOA ve vizi a implementaci. Mají jasné procesy dynamické správy verzí a opětovného nasazování služeb. Může se rychle přizpůsobit změnám obchodních požadavků a rychle se integrovat s novými obchodními partnery.

Není to jen to, kde jste, ale kam jdete.

V modelu APIO je do jisté míry implicitní představa, že každá organizace by se snažila přejít k dynamickému profilu. Ve skutečnosti to závisí na povaze podnikání a na filozofii řízení v oblasti technologií. Některé firmy můžou být zcela spokojené s tím, že zůstanou v základním nebo standardizovaném profilu.

Měli byste zvážit aktuální profil a také krátkodobé a dlouhodobé cíle, přičemž nejbližší cíl je nejdůležitější. Organizace v základním profilu, s touhou být v dynamickém profilu nakonec, se může moudře rozhodnout, že se zpočátku zaměří na přístup do standardizovaného profilu; Proto by rozhodnutí o technologiích měla být většinou v souladu se standardizovaným profilem.

Obecně platí, že BizTalk Server 2006 bude lépe vyhovovat organizacím, které jsou (nebo mají krátkodobý cíl být) v rozšířeném nebo dynamickém profilu. Organizace v základním profilu, která je v tomto profilu relativně spokojená, nemusí mít ani strategickou motivaci k přijetí BizTalk Server 2006, ani schopnosti efektivně využívat, takže by pravděpodobně nechtěla investovat. Pokud se však organizace v profilu Basic rozhodla přejít k rozšířenému profilu agresivně, přijetí BizTalk Server 2006 může být strategickým krokem v daném směru.

Cílem zavedení modelu APIO do diskuze je, že dobrá představa o současných a cílových profilech APIO organizace pomůže při rozhodování mezi WF a BizTalk Server 2006, kdy by technická situace mohla být dobře podporována některou z technologií. Dvě různé organizace můžou dělat různá rozhodnutí – každá z nich zvolí správnou volbu pro svůj profil organizace.

Vše je v hostiteli

Jedním z nejdůležitějších aspektů, které je potřeba vzít v úvahu při výběru mezi BizTalk Server 2006 a WF, jsou požadavky na hostování pro vaše pracovní postupy. Na rozdíl od BizTalk Server 2006 WF neposkytuje hostování "předem k dispozici". Musíte implementovat hostitele, který vytvoří proces Systému Windows a spustí modul runtime pracovního postupu, ve kterém se budou vaše pracovní postupy spouštět.

Aby bylo možné vytvořit architekturu, která může realisticky podporovat celé spektrum scénářů pracovních postupů, WF abstrahuje základní chování, které prostředí, jako je BizTalk Server 2006, aby různí hostitelé mohli poskytovat specifické požadované chování pro tyto služby.

Základní služby, které hostitel pracovního postupu WF poskytuje, jsou následující:

  • Služba plánování – Vytvoří a spravuje vlákna, která modul runtime používá ke spouštění instancí pracovního postupu.
  • Commit Work Batch service – spravuje transakce, které modul runtime používá pro databázové operace.
  • Služba trvalosti – zpracovává trvalost instance pracovního postupu, když ji k tomu modul runtime nasměruje. Tato služba je volitelná. Pokud není k dispozici, instance pracovního postupu nebudou trvalé a musí běžet v paměti po celou dobu své životnosti.
  • Sledovací služba – umožňuje zaznamenávat události sledování v rámci pracovních postupů. Tato služba je volitelná.

Co je potřeba k vytvoření hostitele pracovního postupu

V závislosti na scénáři pracovního postupu a službách, které musíte svým pracovním postupům poskytnout, může být sestavení hostitele WF triviální nebo zakázané. Pro scénáře, ve kterých je pracovní postup v kontextu aplikace, je hostování WF poměrně jednoduché. Samotná aplikace funguje jako hostitel procesu a existují standardní implementace základních služeb, které je možné nakonfigurovat s minimálním úsilím.

Nezbytná sofistikovanost hostitele ale výrazně přeskočí, když se dostanete do vysoce škálovatelných serverových scénářů. Tabulka 1 obsahuje seznam služeb prádelny, které mohou být potřeba – většina z nich je poskytována v BizTalk Server 2006.

Tabulka 1. Hostitelské služby

  • Konfigurace škálování na více instancí
  • Vyrovnávání zatížení
  • Převzetí služeb při selhání
  • Throttling
  • Správa vláken
  • Správa paměti
  • Izolace služby
  • Konfigurace výjimek
  • Správa neúspěšných zpráv
  • Sledování zpráv
  • Archivace a vymazání
  • Identita a zosobnění
  • Model nasazení s více prostředími
  • Monitorování stavu
  • Využití / sledování výkonu
  • Správa stavu složeného procesu
  • Skriptování
  • Zotavení po havárii
  • Dodržování legislativní předpisů
  • Správa konfigurace

V čem vlastně jste?

Pokud máte za úkol vytvořit konkrétní aplikaci s přísnými termíny, pravděpodobně nechcete, aby váš tým rozptyloval nutnost vytvořit komplexního hostitele, když by se měl zaměřit na implementaci potřebné obchodní logiky. V tomto případě BizTalk Server 2006 stojí za to, abyste si místo pokusu o vytvoření robustního hostitele pracovního postupu koupili. Pokud jste součástí centrálního architektonického týmu velké společnosti, můžete se rozhodnout investovat do vytvoření hostitele, který by se dal použít v celé organizaci. I tak by se toto úsilí nemělo brát na lehkou váhu.

Workflow-Technology Doporučení

Scénáře v rámci aplikace: WF

Pro všechny scénáře, které jsou obsaženy v aplikaci, včetně kontroleru stránky uživatelského rozhraní, dlouhotrvající obchodní logiky, dynamicky aktualizovatelného toku procesu, webové služby Composition a abstrakce pravidel z obchodní logiky, je WF správnou volbou technologie pracovního postupu.

Ve většině scénářů zaměřených na aplikace vyžaduje model použití synchronní interakci s nízkou latencí mezi aplikací a pracovním postupem, což není síla BizTalk Server 2006. BizTalk Server 2006 by z důvodů výkonu nebyl vhodný pro tyto scénáře; BizTalk Server orchestrace běží na vyhrazených serverech BizTalk a jejich vyvolání z klientské aplikace vyžaduje odezvu v síti. Kromě toho návrh BizTalk Server 2006 zachování každé zprávy do databáze MessageBox z důvodu stálosti přináší další latenci, která nemusí být přijatelná v kontextu interaktivního uživatelského rozhraní, pokud musí být pracovní postup volána synchronně.

WF je pro tyto scénáře vhodnější; splňuje požadavky pracovního postupu a je jednodušší a levnější než BizTalk Server 2006. Funkce zasílání zpráv BizTalk Server 2006 – například Mapování a Adaptéry – nejsou v těchto scénářích potřeba. Požadavky na hostitelské služby jsou skromné, takže hostování modulu runtime WF v aplikaci nevyžaduje příliš velké množství práce.

Pro většinu Business-Process scénářů: BizTalk Server 2006

Pro většinu scénářů, které zahrnují serverové obchodní procesy, je správnou volbou BizTalk Server 2006. Patří mezi ně proces B2B, abstrakce pravidel z obchodního procesu, úložiště pravidel organizace a služba Enterprise Service Bus (ESB)/Message Broker.

Tyto scénáře vyžadují vysokou škálovatelnost. Vyžadují také možnost zobrazit spuštěné procesy a zastavit a restartovat je. Nakonec vyžadují podporu horizontálního navýšení kapacity na více serverů. V těchto scénářích jsou pokročilé hostitelské funkce BizTalk Server 2006 vyžadovány a stojí za to investovat.

Basic Standardizované Pokročilý Dynamická

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Obrázek 4. Scénář dlouhotrvajícího obchodního procesu

BizTalk Server 2006 bude obecně nejlepší platformou pro scénář dlouhotrvajícího obchodního procesu. Tyto procesy mají tendenci být asynchronní, dlouhotrvající a stavové. Tyto procesy jsou pro organizaci často klíčové; proto vyžadují vysokou dostupnost, viditelnost, zabezpečení a možnosti správy. Topologie skupiny nebo "farmy" BizTalk Server 2006 umožňuje spravovat pole serverů za účelem zajištění škálovatelnosti a redundance.

Mechanismus trvalosti BizTalk Server 2006 pro ukládání stavu procesu má integrované robustní zabezpečení, které chrání soukromí trvalého stavu, což může být důležité z regulačních důvodů. Monitorování obchodních aktivit (BAM) BizTalk Server 2006 poskytuje bezpečný přehled o běžících procesech na úrovni firmy. Tyto scénáře navíc často vyžadují podporu heterogenních formátů zpráv a přenosových protokolů, včetně starších systémů.

Z těchto důvodů bude BizTalk Server 2006 obvykle nejlepší volbou pro organizace, které cílí na standardizované, pokročilé a dynamické profily. Tyto organizace obvykle považují scénář dlouhotrvajícího obchodního procesu za velmi důležitý pro firmu a velmi běžný v rámci podniku; proto si kupují BizTalk Server 2006, aby pro ně vytvořili standardizovanou platformu.

WF ale může být lepší volbou pro organizace, které jsou v základním profilu APIO. Tyto organizace obecně nemají zájem investovat do vytváření standardizované aplikační platformy. Místo toho se snaží minimalizovat náklady a licenční a hardwarové náklady BizTalk Server 2006 můžou být neúnosné. Výjimkou těchto pokynů je, když existují požadavky na vysokou škálovatelnost, monitorování a podporu pro širokou škálu formátů zpráv a přenosových protokolů. V tomto případě, i když se organizace zdráhá investovat do své aplikační platformy, náklady na vytvoření funkcí hostování a zasílání zpráv od začátku by pravděpodobně překročily náklady BizTalk Server 2006.

Basic Standardizované Pokročilý Dynamická

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Obrázek 5. Scénář agregátoru webové služby

Jak BizTalk Server orchestrace, tak pracovní postupy WF mají silnou podporu pro externí webové služby z pracovního postupu a pro zveřejnění pracovního postupu jako webové služby. Proto se při sestavování řešení Agregátoru webových služeb, stejně jako u dlouhotrvajících řešení obchodních procesů, volba určuje profil organizace a požadavky na hostování.

Pokud agregující webová služba pouze agreguje jiné webové služby, schopnost BizTalk Server 2006 podporovat heterogenní formáty zpráv a přenosové protokoly přidává malou hodnotu. Pokud by však služba měla agregovat také data ze starších prostředí, která nejsou vystavena jako webové služby, BizTalk Server 2006 by přidanou hodnotu.

Vzhledem k tomu, že vzorem použití jsou rychlá synchronní volání požadavků a odpovědí, není odolnost zpráv poskytovaná BizTalk Server 2006 obvykle důležitá. Ve skutečnosti je latence, která je zavedena trvalost MessageBox ve skutečnosti je odpovědnost. Hlavní hodnotou, kterou BizTalk Server 2006 pro tento scénář poskytuje, je schopnost spravovat nasazení na mnoha serverech a monitorovat spuštěné instance. Funkce BAM BizTalk Server 2006 může být užitečná také pro monitorování, že jsou splněny smlouvy o úrovni služeb (SLA).

Z těchto důvodů je WF velmi dobrou volbou pro implementaci agregátorů webových služeb, zejména v organizacích v základních a standardizovaných profilech. Příklad, ve kterém může být BizTalk Server 2006 výhodný, je ten, ve kterém musíte spravovat velký počet koncových bodů pro různé klientské organizace. Konkrétně to řeší konfigurace portu pro příjem a umístění příjmu BizTalk Server 2006. V tomto případě můžou být důležité i certifikáty a může být užitečná podpora BizTalk Server 2006 pro konfiguraci a správu certifikátů a jejich použití při šifrování nebo dešifrování.

Future-Proofing

Chcete mít jistotu, že investice do nákladů na licencování softwaru, do učení se technologií pracovních postupů a do vytváření konkrétních komponent pracovního postupu vám v budoucnu poskytnou tu nejvyšší možnou hodnotu. Kromě výběru správného pracovního postupu pro váš konkrétní pracovní scénář a organizaci musíte také vzít v úvahu plány produktů pro BizTalk Server 2006 a WF. Na to není jednoduchá odpověď. Následující komentáře nedělají silný argument pro volbu některé z technologií; místo toho jsou to datové body, které vám pomůžou při rozhodování.

Co BizTalk Server 2006 R2 přidává

BizTalk Server 2006 R2 přidává dvě funkce, které můžou ovlivnit vaši volbu platformy pracovního postupu: adaptéry WCF a zachytávače BAM pro WCF a WF.

Adaptéry WCF

Pokud váš tým přijal Windows Communication Foundation (WCF) jako standardní technologii pro implementaci služeb při vytváření soa, skutečnost, že BizTalk Server 2006 nemá podporu WCF, ji mohla diskvalifikovat jako platformu pro vytváření a hostování složených webových služeb. To vás mohlo nasměrovat k WF, i když BizTalk Server 2006 jinak skvěle odpovídal vašim scénářům a profilu APIO.

Se zavedením skvělé integrace WCF v BizTalk Server 2006 R2 už to naštěstí není problém. BizTalk Server 2006 má nyní silnou integraci s WCF a je to vynikající platforma pro vytváření složených služeb z podrobnějších služeb a vystavení těchto složených služeb jako služeb WCF.

BAM Interceptor pro WF

Druhou relevantní funkcí BizTalk Server 2006 R2 je zavedení zachytávače BAM pro WF. Pokud je monitorování obchodních aktivit důležitou funkcí vašeho řešení, možná jste byli nuceni používat BizTalk Server 2006 – jen proto, abyste využili BAM –, kdy WF jinak lépe vyhovovala vašemu scénáři. Pomocí zachytávacího nástroje BAM pro WF si můžete zvolit WF, pokud je to správná technologie pracovního postupu pro váš projekt, a přesto využít BAM jako řešení pro monitorování podnikových obchodních aktivit.

BAM je funkce BizTalk Server 2006, která poskytuje architekturu pro zachytávání událostí a dat z BizTalk Server orchestrací a toků zpráv a jejich prezentaci na portálu, aby podnikový uživatel měl ucelený přehled o obchodním procesu. Důležitým aspektem fungování BAM pro aplikace BizTalk Server 2006 je, že monitorování BAM lze nakonfigurovat (neboli instrumentovat) po nasazení aplikace BizTalk Server 2006, aniž by bylo nutné měnit artefakty kódu BizTalk Server 2006.

BAM je navržen jako celopodnikové řešení pro monitorování obchodních aktivit; Aplikace, které nejsou BizTalk Server 2006, proto mohou do BAM zasílat události a data. Rozhraní API k tomu však vyžadují, aby se v externích aplikacích napsalo poměrně dost kódu. Zachytávač BAM WF v BizTalk Server 2006 R2 umožňuje jednodušeji a bez nutnosti úprav kódu instrumentovat pracovní postupy WF pro BAM. Pomocí zachytávače BAM můžete sledovat své obchodní procesy bez opětovného zkompilování řešení WF nebo WCF. integrace se provádí prostřednictvím konfiguračního souboru.

BizTalk Server 2006 Extensions for WF SDK

Rozšíření BizTalk Server 2006 pro sadu WF SDK byla oznámena a demoována na TechEdu 2007. Tato sada SDK poskytuje jednoduchý mechanismus pro hostování pracovních postupů WF v BizTalk Server 2006. Tento nástroj je určený pro vývojáře .NET, kteří dnes vytvářejí pracovní postupy WF a hledají snadný způsob, jak dosáhnout robustního a škálovatelného hostování těchto pracovních postupů.

Sada SDK poskytuje dvě vlastní aktivity WF – aktivitu btsReceive a aktivitu btsSend – které lze použít v rámci pracovního postupu WF pro příjem a odesílání zpráv prostřednictvím BizTalk Server 2006. Jako vývojář definujete WCF DataContracts pro příchozí a odchozí zprávy a ServiceContract k definování vzoru výměny zpráv. V rámci pracovního postupu WF jsou aktivity btsReceive a btsSend nakonfigurované tak, aby používaly definovanou službu ServiceContract, jak je znázorněno na obrázku 6.

Obrázek 6 Aktivity btsReceive a btsSend pro použití v definovaném ServiceContract

Po dokončení a kompilaci pracovního postupu WF klikněte pravým tlačítkem myši na projekt pracovního postupu a vyberte Generovat orchestraci, aby se automaticky vygenerovala orchestrace obálky (viz Obrázek 7), která zahájí pracovní postup WF a směruje zprávy BizTalk Server 2006 do i z něj.

Automaticky generovaná orchestrace obálky obsahuje schémata pro zprávy definované v ServiceContract. Obsahuje také BizTalk Server obrazce orchestrace a kód pro příjem zprávy BizTalk Server 2006, vytvoření a spuštění instance pracovního postupu, předávání příchozích zpráv do instance pracovního postupu, příjem odchozích zpráv a jejich přeposílání zpět do modulu zasílání zpráv BizTalk Server 2006. K dokončení hostování pracovního postupu WF stačí zkompilovat a nasadit orchestraci obálky a vytvořit vazbu pomocí normálního mechanismu BizTalk Server 2006.

Obrázek 7. Automatické generování orchestrace obálky

Kromě využití robustního a škálovatelného mechanismu hostování BizTalk Server 2006 pro pracovní postupy WF vám BizTalk Server 2006 Extensions for WF SDK umožňuje využít infrastrukturu zasílání zpráv BizTalk Server 2006. Proto můžete využít mnoho dostupných adaptérů pro získávání zpráv do a z BizTalk Server 2006, stejně jako zpracování kanálu, včetně funkcí mapování.

I když jsou rozšíření BizTalk Server 2006 pro sadu WF SDK jak je výkonná, měla by se používat jako nástroj, který vývojářům WF umožní nasazovat své pracovní postupy nad BizTalk Server 2006, a ne jako náhrada orchestrací ve scénářích, ve kterých jsme identifikovali BizTalk Server 2006 jako správný nástroj. Existují některé obrazce WF, které nefungují, když jsou zabaleny v orchestraci. Důvodem je to, že hostování pracovních postupů WF v BizTalk Server 2006 pomocí rozšíření BizTalk Server 2006 pro sadu WF SDK neposkytuje stejné chování hostování jako nativní orchestrace. Sada SDK obsahuje seznam nejčastějších dotazů (zahrnutý v úvodní příručce), který tyto rozdíly popisuje.

Závěr

BizTalk Server 2006 a Windows Workflow Foundation jsou primární nástroje od Microsoftu pro implementaci řešení pracovních postupů v kategoriích Pracovní postup integrace aplikací a podnikových prostředí. Abyste mohli zvolit, která z těchto scénářů je pro váš projekt nejvhodnější, musíte nejprve určit, na které scénáře pracovního postupu cílíte.

Dále použijte tabulku na obrázku 8 a podívejte se na doporučenou technologii pracovního postupu pro váš scénář. Pro pracovní postup v rámci aplikace doporučujeme WF. Pro většinu serverových scénářů obchodních procesů a B2B doporučujeme BizTalk Server 2006.

Obrázek 8. Technologie pracovních postupů specifických pro konkrétní scénáře

Pro scénáře dlouhotrvajícího obchodního procesu i agregátoru webové služby je možné použít obě technologie afektivním způsobem. V těchto scénářích byste měli vyhodnotit aktuální a krátkodobý cílový profil rozhraní APIO vaší organizace. Organizace, které se nacházejí v rozšířených nebo dynamických profilech nebo k těmto profilům, by měly pro tyto scénáře používat BizTalk Server 2006. Organizace v profilech Basic a Standard můžou pro tyto scénáře efektivně používat WF.

Nakonec byste měli zvážit data vydání a požadovanou životnost vašeho řešení vzhledem k roadmapě produktu pro BizTalk Server 2006 a WF. Pomocí této architektury a pokynů v tomto článku byste měli být schopni zvolit správný pracovní postup pro váš projekt.

Dodatek

Rozptylování mylných představ o BizTalk Server 2006 vs. WF

Následuje několik běžných mylných představ týkajících se WF a BizTalk Server 2006 a vysvětlujících argumentů, které používáme k jejich rozptýlení:

  • WF je náhrada za BizTalk Server 2006.Ne. Vzhledem k tomu, že WF je "nejnovější a nejlepší" nabídka od Microsoftu pro programovací pracovní postupy, mnozí, kteří nejsou obeznámeni s BizTalk Server 2006, zpočátku předpokládají, že byl zastaralý s vydáním WF. Jednoduchou odpovědí, jak tento dojem napravit, je, že WF je nízkoúrovňová vývojářská architektura pro vytváření všech druhů pracovních postupů, zatímco BizTalk Server 2006 je plnohodnotný serverový produkt s pokročilými funkcemi pro konkrétní kategorii scénářů pracovních postupů: Podniková integrace. (Viz Obrázek 1.)
    WF poskytuje pouze malou podmnožinu této funkce: pracovní postup a obchodní pravidla. I když WF může být jednodušším a cenově výhodnějším řešením pro scénáře, které nevyžadují všechny ostatní funkce, které BizTalk Server 2006 poskytuje, v žádném případě nenahrazuje BizTalk Server 2006 pro základní scénáře podnikové integrace, které BizTalk Server 2006 byly navrženy pro podporu.
  • BizTalk Server odchází.Ne. Podobným mylným představou je dojem, že vzhledem k tomu, že WF byla vydána jako nástroj pracovního postupu budoucnosti a BizTalk Server ještě nebyla přepsána tak, aby používala WF, Microsoft už neinvestuje do BizTalk Server a nakonec ho nahradí novým produktem založeným na WF. Tak to prostě není. BizTalk Server je velmi úspěšný produkt a oblast podnikové integrace, na kterou cílí, je i nadále oblastí, kterou microsoft chce podporovat.
  • Musíte zvolit BizTalk Server 2006 přes rozhraní .NET Framework.Ne. Pro vývojáře .NET, kteří nejsou obeznámeni s BizTalk Server 2006, může být lákavé zvolit WF před BizTalk Server 2006, jen na základě toho, že by raději přešli na "čistou" .NET. To však ve skutečnosti není užitečné kritérium; BizTalk Server 2006 je postaven na rozhraní .NET Framework.
    Ve skutečnosti BizTalk Server 2006 představuje více než 2 miliony řádků kódu .NET, které lze použít ve vašem řešení, což vám ušetří čas, potíže a náklady na vývoj jeho funkcí od začátku. Kromě toho se samotné programování BizTalk Server 2006 provádí uvnitř sady Microsoft Visual Studio .NET a komponenty se kompilují a nasazují jako sestavení .NET. Kromě toho nejvýznamnější projekty BizTalk Server 2006 kombinují komponenty BizTalk Server 2006 s vlastními komponentami .NET, takže vývoj BizTalk Server 2006 by se měl považovat za specializovaný vývoj .NET místo toho, co je cizí nebo odlišné.
    Skutečnou otázkou je, jestli funkce BizTalk Server 2006 poskytují dostatečnou hodnotu pro konkrétní scénář pracovního postupu, aby odůvodnila náklady na licencování. Nechcete používat saně k zavěšení obrázků; Ani nechcete použít tesařské kladivo k drcení velkých kamenů.
  • Vyhrává nejvíce funkcí.Špatná volba. Mohli bychom vytvořit matici funkcí, která porovnává podrobné funkce WF s funkcemi BizTalk Server 2006. Toto porovnání by však nebylo příliš užitečné; BizTalk Server 2006 má tak velký počet funkcí, které jsou zaměřeny speciálně na prostor podnikové integrace. Pokud to není váš cílový scénář, budou porovnání funkcí bezvýznamné. BizTalk Server 2006 by pravděpodobně vyhrála, pokud jde o počet zaškrtávacích políček funkce. Toto je ale porovnání jablek s pomeranči, pokud tyto funkce nesouvisejí se scénářem pracovního postupu, na který cílíte.

Poděkování

Rád bych poděkoval Paulu Andrewovi a Krisi Horrocksovi a všem, kteří si tento článek prostudovali.

Další informace

O autorovi

Kent Brown je ředitelem a senior architektem organizace Enterprise Integration Practice ve společnosti Twentysix New York, konzultačního partnera Microsoft Gold Certified v New Yorku. Od svého vzniku v roce 2000 byl nadšený z BizTalk Server a posledních sedm let se u produktu podílel na evangelistu. Kent je členem týmu microsoft BizTalk Virtual Technical Specialist a také MVP microsoft Connected Systems Developer. Je zakladatelem a vedoucím skupiny NYC Connected Systems Users Group (http://www.NYCCSUG.org).