Microsoft BizTalk Server 2004 – princip technologie

13. listopadu 2004

•

Microsoft jakožto světový softwarový leader má na trhu celou řadu produktů, určených pro vývoj rozsáhlých aplikací postavených na bázi vlastních produktů. Tento gigant si ale dobře uvědomuje, že není možné budovat uzavřený svět sám pro sebe, nýbrž je třeba spolupracovat s konkurenčními systémy v budování společných rozsáhlých enterprise řešení. MS BizTalk Server je ten, kdo má kýženou kooperaci dirigovat snadno a efektivně. Neváhejte a vstupte do světa vizuálního programování.

Tímto článkem začíná krátká série o novém aplikačním serveru Microsoftu. Většinu informací uvedených zde lze vyčíst také z propagačních materiálů, nepovažujte však prosím tento seriál za nějaké promotion, budu se snažit jednotlivé části popsat jednoduše a technicky tak, jak je vidím já, a bez zbytečných superlativů. Berte tento text jako výpověď člověka, který k BizTalku přišel jako slepý k houslím.

K čemu slouží MS BizTalk Server?

Je to vlastně vývojový nástroj určený k integraci skupiny aplikací v jeden funkční celek. BizTalk nám umožní jednoduše a rychle vyvinout vrstvu, pomocí které slepíme různé systémy dohromady. Vždy se jedná o informace, které musí proudit mezi jednotlivými systémy tak, jak vyžaduje konkrétní aplikace. V nejjednodušším případě jedna strana informaci vyšle, BizTalk ji zachytí, zpracovává, transformuje, a dle svého uvážení ji může poslat (či neposlat) do koncového systému. Cílem je rychlý a snadný vývoj transakčních aplikací se škálovatelným výkonem a s nízkým rizikem zavlečení chyb. Důležitou roli hraje vizualizace celého návrhu, není to suché psaní kódu, je to prostě „klikačka“.

Na jakých technologiích je BizTalk postaven?

Aby mohl být nějaký softwarový produkt úspěšný, měl by být postaven na kvalitních a moderních technologiích. BizTalk není zrovna novým produktem, ovšem od předchozích verzí prodělal značný vývoj a hlavně díky plnému přechodu pod .NET platformu získal novou tvář. Představme si jednotlivé technologie, na kterých je postaven:

XML (eXtensible Markup Language): Tuto zkratku jistě čtenářům Intervalu nemusím příliš objasňovat, pouze připomínám, že se jedná o moderní a oblíbený strukturovaný formát dat vycházející z SGML, dobře čitelný pro počítač i pro člověka, a použitelný prakticky na všech myslitelných platformách. S XML v současnosti umí pracovat velké procento aplikací, které potřebují nějakým způsobem komunikovat s jinými aplikacemi, a do ostatních se podpora XML opožděně doplňuje. Každá aplikace má svou vlastní implementaci XML, v podstatě vlastní značkovací jazyk, ale konvertovat data mezi těmito jazyky lze snadno pomocí XSL transformací. Díky těmto vlastnostem se XML dočkalo značného rozšíření, a právě proto je i v BizTalku základním výchozím formátem.
.NET: Další technologie, která představuje hybnou sílu dnešního programování. Jejím cílem je snadný vývoj robustních aplikací na různých platformách a v různých jazycích, se snadnou integrací s jinými aplikacemi. V podstatě je to alternativa Microsoftu pro Javu a související technologie, cílová platforma se prakticky omezuje na Windows/Intel (nebýt projektu Mono) a Windows CE na mobilních zařízeních. Nejpoužívanějším jazykem je C#, který opět silně připomíná Javu. Důležitým prvkem je FCL (.NET Framework Class Library), což je rozsáhlá knihovna obsahující velké množství užitečných funkcionalit. Technologie .NET má mnoho dalších dobrých vlastností, které zde již nebudu rozebírat, podstatné je to, že .NET je pro Microsoft velmi významný produkt, a Microsoft jej jistě bude nadále prosazovat všude, kde to bude možné. Aplikace v BizTalku jsou vlastně .NET knihovnami (assembly), takže veškeré vlastnosti .NET aplikací platí i pro ně.
Visual Studio .NET: Visual Studio je již poměrně dlouho IDE nástrojem určeným pro vývoj Windows aplikací. VS.NET je samozřejmě jeho vylepšená obdoba zaměřená na .NET aplikace. Pomocí něj lze vyvíjet okenní aplikace (Windows Forms), konzolové aplikace, webové aplikace (ASP.NET), webové služby, typové knihovny a další. Nyní lze v tomto prostředí vyvíjet i BizTalk aplikace pomocí nových vizuálních nástrojů, jak uvidíte později.
Microsoft SQL Server: Jde o oblíbený databázový server na platformě Microsoft. BizTalk jej využívá pro uložení informací o svých aplikacích, stavu rozpracovaných transakcí a loguje do něj jejich průběh.

Architektura jádra BizTalk Serveru

Velmi zjednodušeně lze architekturu serveru popsat následujícím diagramem:

Architektura jádra BizTalk Serveru

Následuje vysvětlení jednotlivých entit diagramu a dalších pojmů, které tvoří abecedu a malou násobilku každého BizTalk vývojáře:

Obchodní proces: Všechny prvky a technologie BizTalku jsou pouze nástroje, které mají sloužit ke splnění určitého cíle, a tím je realizace obchodního procesu, tedy nějaké úlohy, jejímž jádrem je zpracování dat. Do obchodního procesu se zapojují jak jednotlivé subsystémy, tak samotný BizTalk, který může mít roli tlumočníka, nebo také může řídit průběh celého procesu. V dalších článcích budeme pod tímto pojmem většinou chápat tu část úlohy, kterou zpracovává BizTalk.
Hostitel: Lze jej v podstatě považovat za instanci BizTalk serveru. Je to vlastně Windows proces, běžící na některém počítači. Může na něm být umístěna celá aplikace, nebo jen některé její vybrané části. Díky podpoře spolupráce několika hostitelů mají BizTalk aplikace snadno škálovatelný výkon a umožňují redundanci, tedy vysokou stabilitu celého řešení. Rozložení aplikace mezi hostitele je uloženo ve společné konfigurační databázi.
Zpráva (message): Jak jsem již naznačil výše, každá zpráva je vlastně tvořena daty v XML formátu. Zpráva odpovídá nějakému definovanému schématu, takže její struktura je předem dána.
Schéma: Schéma zpráv v BizTalku vychází ze standardu XSD a k jejich navrhování slouží vizuální návrhář, který do schématu zahrnuje i některé informace specifické pro BizTalk.
Orchestrace: Každý obchodní proces je vlastně realizován orchestracemi. Ty jsou samozřejmě opět navrhovány vizuálně a trochu připomínají vývojové diagramy s tím rozdílem, že v BizTalku návrh nedisponuje pouze svou vizuálností, ale také funkčností. Samotnou orchestraci lze přirovnat ke třídě v OOP a při jejím spuštění vzniká instance orchestrace. Spustit orchestraci lze buď aktivací jejího vstupního portu, nebo spuštěním z jiné orchestrace.
Modul (shape): Orchestrace se skládá z jednotlivých funkčních modulů, přičemž každý vykonává jinou činnost. Obvykle je na začátku přijímací modul, pak mohou následovat různé transformace, smyčky či rozhodování, a výsledek je exportován přes odesílací modul. Některé moduly mohou běh orchestrace pozastavit, přičemž BizTalk čeká na dokončení nějaké synchronní operace, nebo třeba i na lidský zásah – rozhodnutí odpovědného pracovníka.
Transformace (mapování) zpráv: Různé typy zpráv (schémata) mohou být na sebe mapovány pomocí takzvaného BizTalk Mapperu, který umožňuje definovat souvislost mezi jednotlivými položkami ve schématu. Jde opět o vizuální návrhář integrovaný do VS.NET. Složitější vztahy mezi prvky lze definovat pomocí takzvaných functoidů. Koncepce této transformace vychází ze standardu XSLT.
Úložiště zpráv (MessageBox): V jednu chvíli může být rozpracováno velké množství instancí orchestrací. Každá taková instance může obsahovat také několik instancí zpráv. Aby nemusela tato data čekat v paměti na nějaký dlouho trvající synchronní proces, jsou zprávy ukládány do databázového úložiště, které se nazývá MessageBox. Tomuto odložení se říká dehydratace a opačnému procesu samozřejmě hydratace.
Adaptér: BizTalk je schopen data přijímat i odesílat mnoha různými cestami, například přes webové služby, HTTP, souborový systém, e-mail, message queuing a další, a to právě díky adaptérům. Pokud vám adaptéry v BizTalku nestačí, lze doplnit i vlastní, vyvinuté v rámci takzvaného Adapter Frameworku.
Kanály (pipeline): Data, která putují z (nebo do) adaptéru je často třeba ještě nějak upravit, zašifrovat, zkomprimovat nebo třeba zkontrolovat (validovat) a k tomu slouží přijímací a odesílací kanály (receive pipeline, send pipeline). Do těchto pipeline vkládáme potřebné komponenty a konfigurujeme je. Ve vstupním kanále může také některá komponenta určit odesilatele zprávy, a pokud se to podaří, poběží následně spuštěná orchestrace v kontextu jeho uživatelského účtu. V opačném případě je zpráva považována za anonymní.
Přijímací a odesílací port (receive location, send port): Pokud například chceme, aby BizTalk reagoval na soubory, které zapisujeme do nějakého adresáře, umístíme do orchestrace modul pro příjem zprávy a propojíme ho s přijímacím portem, který pro tento účel vytvoříme. Port musí mít vybrán adaptér, který chceme použít (například FILE), přesnou identifikaci cíle (například který adresář chceme hlídat) a kanál, přes který data potečou. Porty přiřazené k dané orchestraci lze později dle potřeby překonfigurovat, zakázat a podobně.
Korelace: Odeslání a přijetí zprávy je v BizTalku oddělený proces. Někdy je však třeba odeslat požadavek, počkat na odpověď a teprve pak pokračovat. BizTalk v takovém případě musí umět rozpoznat vazbu mezi požadavkem a odpovědí na něj, aby se nestalo, že by si přicházející data popletl. V případě HTTP adaptéru to není žádný problém, protože tento problém je řešen již na úrovni samotného protokolu a jeho implementace v operačním systému. Proto může být port s HTTP adaptérem takzvaně self-correlating a obsahovat operaci odeslání a přijetí zprávy zároveň. Pro jiné adaptéry však musíme definovat korelaci, která určuje, jak se rozpozná vztah mezi odchozí a příchozí zprávou.
Subskripce: Jak bylo ukázáno u korelací, rozhodování o budoucnosti nové zprávy na nějakém vstupním portu není zrovna jednoduché. Každá zpráva, která do BizTalku přichází, může být pokyn ke spuštění orchestrace (je nutné vybrat konkrétní orchestraci), ale může také znamenat pokračování v již spuštěné orchestraci (a je nutné vybrat její konkrétní instanci). Proto BizTalk obsahuje mechanismus nazývaný předplacení (subscription). Díky němu si mohou orchestrace definovat sadu pravidel, podle kterých se budou vybírat zprávy, které bude orchestrace zpracovávat. Takto si může objednat dokonce i přímo některý výstupní port, takže zpráva může BizTalkem protéci i bez spouštění nějaké orchestrace.
Transakce: Tento pojem je známý spíše z databázových systémů. Transakce spojuje několik operací do jediného celku, který se buď podaří nebo nepodaří. Pokud během provádění dojde k chybě, dojde buď k navrácení systému do původního stavu, nebo se chyba nějakým způsobem vykompenzuje. Jiným řešením je uspání (suspend) běžícího procesu, aby mohla být konfliktní situace vyřešena později zvenčí. Transakce obchodních procesů mohou být buď atomické, kdy se všechny potřebné instance udržují v paměti, nebo dlouhodobé, během kterých může BizTalk použité objekty dočasně uklidit do MessageBoxu.
Obchodní pravidlo (Business rule): Business Rule Engine umožňuje pro orchestraci definovat obchodní pravidla, která budou hlídat parametry zpráv a další veličiny, na jejichž základě bude orchestrace rozhodovat o svém dalším postupu. Obchodní pravidla lze měnit i nad spuštěnou aplikací, přičemž změny mají okamžitou platnost a navíc je jejich tvorba navržena tak, aby jim rozuměl a mohl je definovat i obchodní analytik, který programovat neumí.

Vývojové prostředí ve Visual Studiu .NET

Na následujícím obrázku si můžete prohlédnout vývojové prostředí BizTalku integrované do Visual Studia .NET, které je zde zmenšeno na poměrně kompaktní velikost. Je v něm otevřena velmi jednoduchá orchestrace. Vývojové prostředí budeme podrobně zkoumat v dalších článcích.

Vývojové prostředí ve Visual Studiu .NET (plná velikost, cca 16 kB)

Nové technologie a nástroje

Nyní máme představu o jádře Microsoft BizTalk serveru, ovšem síla tohoto produktu tkví také ve velkém množství dalších technologií a nástrojů.

Enterprise Single Sign-On: Protože BizTalk je systém k propojení systémů v heterogenním prostředí, je třeba řešit i propojenost uživatelských účtů. Když uživatel vznese požadavek prostřednictvím některého systému a BizTalk jej předává dále, měl by s požadavkem cestovat i uživatelský kontext žadatele. Přihlašování přes SSO umožňuje v případě potřeby vyhledat pro konkrétní účet přihlašovací údaje do ne-Windows aplikace z SSO serveru, kde jsou tyto informace bezpečně uloženy. SSO servery a související nástroje mohou být využity i mimo BizTalk aplikace.
HAT (Health and Activity Tracking): Prakticky všechny operace v Microsoft Biztalk Serveru mohou být logovány a HAT je nástroj, pomocí kterého lze nasbírané informace zpracovávat, ať pro obchodní účely, nebo pro optimalizaci výkonu. Rovněž umožňuje orchestraci zastavit a zkoumat její stav a další průběh.
Tracking Profile Editor: Tento nástroj umožňuje definovat v orchestracích místa, ve kterých se budou sbírat data pro sledování a analýzu průběhu obchodních procesů.
BAM (Business Activity Monitoring Framework): Mechanismus BAM umožňuje snadno sledovat průběh obchodních procesů dle nasbíraných dat. Pomocí BAM Activity wizardu lze snadno definovat sledovanou aktivitu a posléze na ni definovat pohled pomocí BAM View wizardu. Výsledky jsou pak zobrazeny v Excelu. Tyto služby při své činnosti využívají (mimo jiné) Analysis Services a SharePoint services.
TPM (Trading Partner Management): Jde o databázi, do které se ukládají informace o organizacích, které má BizTalk propojovat. Jde o podrobnosti o dohodách mezi nimi a hlavně o technické detaily, jako je způsob propojení, přenosové protokoly a podobně. Každá dohoda může obsahovat dodatky.
Business Process Configuration: Každá orchestrace může mít definovány parametry, které mohou být snadno nastavitelné tak, jak je vyžadováno, a mohou se lišit v různých kontextech, například pro různé obchodní partnery. Konkrétní hodnoty pro různé partnery lze nastavovat pomocí rozhraní TPM, a to v dodatcích dohod. Každý dodatek náleží právě jedné orchestraci.
Business Process Provisioning: Někdy nastává situace, kdy se do jednoho enterprise řešení velké organizace musí zapojit velké množství organizací, které na svých BizTalk serverech implementují dílčí části celého řešení. Nadřazená organizace jim může tyto jejich části zaslat ve formě takzvaného SEED package, tedy balíčků dat a aplikací, potřebných .NET komponent, BAM aktivit a dalších objektů. Business Process Provisioning umožňuje tyto balíčky snadno vytvářet.
Human Workflow Services: Často je třeba, aby do obchodního procesu vstoupil člověk, aby například „ručně“ schválil objednávku a podobně. Člověk je také obvykle ten, kdo je na úplném počátku obchodního procesu. Vazbu mezi klientskou aplikací a BizTalk serverem poskytuje HWS, který tyto funkce zpřístupňuje přes webové služby a také z aplikací Office, jako jsou Word, Excel, Outlook nebo InfoPath. To je možné hlavně díky novým rysům těchto aplikací, které nyní mohou zobrazovat formuláře a vyvolávat akce při jejich odeslání. Například žádost o schválení objednávky se zobrazí odpovědnému pracovníkovi v Outlooku a přímo ve zprávě bude formulář, umožňující o dalším zpracování rozhodnout okamžitě jediným kliknutím. Rapidně se pak může zvyšovat efektivita celého obchodního procesu.

Co bude dál?

Šedá je teorie, zelený strom života. Tu šedou část máme za sebou, bylo to možná trochu nezáživné, ale podle mě nutné, abychom si uvědomili, před čím vlastně stojíme. V dalším článku se podíváme na způsob vytváření aplikací trochu praktičtěji – ukážeme si prvky BizTalku přímo v prostředí Visual Studia .NET a naučíme se s nimi pracovat. Tentokrát bude k dispozici poněkud více obrázků, takže čtení bude možná o něco zábavnější.