CASE pro workflow - panrepa.orgpanrepa.org/CASE/CASE_pro_workflow06.pdf · Použití CASE/CABE pro...

Použití CASE/CABE pro řízení workflow ve firmě

Autoři:

Jakub Albrecht

Ondřej Čuka

Martin Navrkal

Tomáš Faran

Milan Kovařík

Miloš Maryška

David Mišurec

Tomáš Trávníček

Předmět:

IT_572

Datum:

14. prosince 2005

13. dubna 2006

Obsah Obsah.............................................................................................................................................2 Úvod...............................................................................................................................................4 Procesní vs. funkční řízení ............................................................................................................4 Technologie ...................................................................................................................................5

Windows Workflow Foundation...............................................................................................5 Úvod .......................................................................................................................................5 Microsoft ohlašuje Windows Workflow Foundation ...........................................................5 Vývojové paradigma ..............................................................................................................6 Windows WF a MVC vzor......................................................................................................9 Typy vývojářů.......................................................................................................................10 Možnosti Frameworku ........................................................................................................ 11 Vývojové prostředí............................................................................................................... 13 Závěr..................................................................................................................................... 15

Webové služby ......................................................................................................................... 16 Service oriented architecture .................................................................................................. 17 SOA - podrobněji ..................................................................................................................... 17

Služby na „business level“ ...................................................................................................18 Volná vazba ..........................................................................................................................18 Služba ................................................................................................................................... 19 Webové služby (Web Services - WS) ................................................................................. 20 Vztah procesu a služby ........................................................................................................22 Orchestrace a choreografie služeb a vztah k workflow.......................................................23 BPEL (Business Process Execution Language) ..................................................................27

Trendy......................................................................................................................................29 Etapy vývoje softwaru nejsou zřetelně odděleny................................................................29

Produkty ..................................................................................................................................... 30 Filenet P8 BPM....................................................................................................................... 30 SAP NetWeaver .......................................................................................................................32

Základní komponenty SAP NetWeaver ..............................................................................32 SAP Exchange Infrastructure (SAP XI) ..............................................................................34

BizTalk Server..........................................................................................................................36 Architektura BizTalk Serveru..............................................................................................37 Požadavky nutné k instalaci BizTalk Serveru .................................................................... 38 Nástroje BizTalk Serveru 2006 ...........................................................................................39 BizTalk Orchestration Services ...........................................................................................43

IBM WebSphere ..................................................................................................................... 48

2 / 64

Produkty IBM podporující SOA ......................................................................................... 49 WebSphere Business Modeler............................................................................................ 50

Sybase PowerDesigner ............................................................................................................ 51 Základní charakteristiky PowerDesigner............................................................................ 51 Business Process Architect..................................................................................................54

ORACLE BPEL Process Manager ...........................................................................................55 BPEL Designer.....................................................................................................................56 BPEL Console ......................................................................................................................56 Zabudované integrační služby.............................................................................................56 Workflow služby ..................................................................................................................56 BPEL Server .........................................................................................................................56

Microsoft Visio 2003...............................................................................................................57 SharePoint Portal Server 2003 ...............................................................................................62

Použité zdroje ............................................................................................................................. 64

3 / 64

Úvod Současná dynamická doba staví podniky do situace, kdy jsou pod tlakem stále nových zákaznických požadavků, netrpělivého očekávání akcionářů, domácí i zahraniční konkurence a neustále se rozvíjejících informačních a komunikačních technologií. Snaha získat v tomto prostředí stabilnější pozici vedla mnohé podniky k přechodu od neefektivního funkčního řízení k řízení procesnímu.

Procesní vs. funkční řízení Východiskem pro procesní řízení je zákaznická potřeba a její uspokojení produktem / službou. Každý produkt (výrobek nebo služba) vzniká určitým sledem činností tedy procesem. Pro každodenní chod procesů pak podnik potřebuje odpovídající zdroje. Schématicky je vše znázorněno na obrázku níže.

Obrázek 1: Schéma procesního řízení

Procesnímu řízení je přizpůsoben i nový způsob zobrazování organizačních vztahů pomocí procesního (postupového) diagramu zahrnujícího všechny potřebné činnosti, vazby mezi nimi, jejich souslednost a zodpovědné pracovníky. Tento způsob organizování také zahrnuje všechny pracovníky, kteří se na procesech podílejí. Snižuje se také potřeba řídící práce, protože pracovníci jsou organizováni mezi sebou a řešení řady situací je vyznačeno předem. Jsou stanoveny rozhodovací činnosti a pracovníci zodpovědní za jejich řešení. Řádná implementace procesního řízení pak může podniku přinést tyto výhody:

• zvýšení rychlosti řízení a zkrácení doby odezvy na požadavky zákazníka

• snížení potřeby řídící operativní práce

• zvýšení výkonnosti podniku

• možnost analyzování procesů a jejich zlepšování

• splnění základní části požadavků norem řízení jakosti ISO 9000:2000

• stanovení jednoznačné pravomoci a odpovědnosti

Procesní řízení se tak diametrálně odlišuje od řízení funkčního, které je vyjadřováno organizačním schématem. Organizování tímto funkčním způsobem řeší především otázku dělby práce v podniku, specializaci pracovníků a jejich kompetencí. Mimo to je v organizačním schématu vyjádřen vztah podřízenosti a nadřízenosti mezi jednotlivými pracovníky a organizačními jednotkami. Vzniká mnoho komunikačních a kompetenčních bariér v důsledku ohraničených organizačních jednotek.

Cílem podniku je samozřejmě všechny probíhající procesy provádět co možná nejefektivněji, s nejnižšími náklady a nejvyšším užitkem. Za tímto účelem je tedy nutné procesy měřit, monitorovat a na základě výsledků je pak modifikovat, optimalizovat. Právě tomuto má napomoci nasazení technologií a produktů, které budou popsány na stránkách níže.

Ještě dříve než se vrhneme na představení produktů, které slouží k návrhu a optimalizaci procesů a jejich následné integrace do aplikačního prostřední v rámci IS podniku, představíme krátce klíčové technologie.

4 / 64

Technologie Windows Workflow Foundation

Úvod Většina podniků se dnes orientuje na procesní způsob řízení své činnost. Existuje celá řádka různých typů procesů, některé jsou náročné na lidskou práci, některé jsou náročné na práci automatizovaných výpočetních systémů a třetím typem je kombinace předchozích dvou. Příkladem procesů jsou např. příchod faktury, uvedení nového výrobku nebo přijetí nového pracovníka atd. Ve většině případů business procesy vyžadují zásah mnoha entit a díky tomu mohou trvat velmi dlouho.

Dnešní standardní odpovědí na otázku jak automatizovat business procesy je vytvoření týmu vývojářů, kteří napíší adekvátní programový kód. Zatímco tento přístup dosud sloužil organizacím dobře, má řadu problémů. Abychom pochopili podstatu těchto problémů, je nejdříve nutné vysvětlit některé základní charakteristiky workflow.

Workflow je vlastně způsob jak dokumentovat aktivity zapojené do vytvoření jednotky výstupu práce. Typicky, práce „teče” skrz jednu nebo více aktivit během zpracování. Tyto aktivity mohou být vykonávány buď lidmi nebo počítači (automatizovanými systémy), mohou být stejně jednoduché jako je vytvoření posloupnosti stránek v internetové aplikaci ale stejně tak i složité jako neustále měněný systém pro řízení dokumentů nebo produktů, který musí být k dispozici mnoha lidem.

Protože mnoho workflow systémů musí umožnit a zahrnovat lidský element, může trvat velmi dlouhou dobu samotné dokončení běhu workflow, od několika hodin až po několik měsíců. Např. lidé zahrnutí v procesu nemusí být dostupní, nacházejí se mimo město, nebo jsou zaneprázdněni jinými úkoly. Z toho plyne jeden z hlavních požadavků na workflow systémy, tedy že workflow systémy se musí s touto skutečností vyrovnat a musí být schopny ukládat svůj stav během dlouhého období neaktivity. Navíc, procesy implementované čistě v programovacím jazyce jsou velmi těžko čitelné pro netechnicky orientované lidi a jejich změna vyžaduje hlubší porozumění kódu. Tyto a jiné faktory jsou cílem obecných workflow frameworků (jako např. Windows WF), které se zaměřují na to, aby vytváření, změna a řízení workflow byly jednodušší, aby uživatelům nabídly vizuálně orientované prostředí s obecným API rozhraním.

Základní tři vlastnosti workflow

• Dlouhotrvající a stavové chování

• Flexibilní kontrola toku

• Transparentnost

Microsoft ohlašuje Windows Workflow Foundation V září 2005 odhalil Microsoft na PDC (Professional Developer's Conference) Windows Workflow Foundation (Windows WF). Jako jeden z klíčových pilířů WinFX API, Windows WF poskytuje vývojářům obecný framework na kterém mohou budovat procesně řízené a na workflow postavené aplikace.

Tato technologie doplňuje .NET Framework skupinou workflow orientovaných komponent, které umožní vývojářům definovat, zkompilovat, spustit instanci, ladit a sledovat workflow. Windows WF spolu s Windows Presentation Foundation a Windows Communication Foundation tvoří nové, na .NET postavené, WinFX API.

5 / 64

Windows Workflow Foundation umožňuje programům, aby byly vyjádřeny jako deklarativní, dlouhotrvající procesy – workflow. Narozdíl od tradičních Microsoft .NET Framework programů, na workflow založené programy jsou typicky specifikovány v deklarativním Extensible Application Markup Language (XAML) dokumentu, který specifikuje strukturu programu v termínech doménově specifických aktivit. Tyto aktivity jsou pak implementovány v tradičních common language runtime (CLR) programovacích jazycích jako je C# nebo Visual Basic.

Windows WF poskytuje sadu obecně zaměřených aktivit, které pokrývají většinu tokových řídících prvků, uživatelům však ponechává volné ruce aby mohli tyto aktivity ignorovat a napsat si kompletně novou sadu aktivit, které jsou přesněji situovány dané doméně problémů. Obecněji lze říci, že workflow program bude používat aktivity poskytované Windows WF pro základní řízení toku a struktury programu a bude používat zákaznických, uživatelsky definovaných aktivit pro doménově specifickou funkcionalitu.

K podpoře na XAML založených přístupů kompozice při vytváření programů, programy založené na workflow budou také těžit z bohatší sady běhových služeb než tradiční CLR programy. Windows WF běhové prostředí může být hostováno v jakékoliv CLR aplikační doméně. Běhové prostředí umožňuje odstranění workflow z pamětí (technika zvaná passivation) a později jeho znovunahrání a znovuspuštění bez potřeby psát další programy pro řízení stavového managementu. Běhové prostředí workflow také poskytuje běžné prostředky pro zpracování chyb a kompenzování transakcí tak, že umožňuje buď automatické nebo vlastní zpracování undo mechanismu pro specifické prvky dlouhotrvajících workflow. A co víc, je možné těžit z řídících služeb, které umožňují inspekci stavu daného workflow programu skrze sledování událostí, sledování běhu programu nebo dotazováním se na stav workflow.

Vývojové paradigma Použitím workflow, které nabízí Windows Workflow Foundation mohou vývojáři zahrnout do jejich aplikací takové koncepty jako scheduling, task coordination a escalation. WF nabízí základní platformu na které mohou nezávislé softwarové společnosti budovat jejich procesně orientované aplikace. Zatímco MS Visual Studio není přímo vyžadováno pro vývoj WF workflow, nabízí některé opravdu užitečné nástroje jako Visual Designer, Visual Studio workflow šablony a nástroje pro visuální ladění aplikací, které usnadňují vývoj aplikací. WF workflow jsou vyvíjeny buď pomocí značkovacích jazyků – deklarativní zápis workflow –

6 / 64

Obrázek 2 Deklarativní zápis workflow

nebo programovány v jednom z .NET jazyků (C#, Visual Basic.NET),

Obrázek 3 Zápis workflow v kódu .NET jazyka

nebo kombinovaným způsobem za použití značkovacího jazyku a oddělením programového kódu.

7 / 64

Obrázek 4 Code-separation zápis workflow

Výstupem je balíček zvaný assembly, to jest zkompilovaná workflow knihovna, jež potřebuje pro svůj běh hostující aplikaci. Hostující aplikace se mohou lišit od konzolových aplikací (klasické exe soubory), služby Windows, HTTP moduly až po serverové aplikace jako SharePoint Services. Jiné produkty jako Microsoft BizTalk Server a Microsoft Dynamics AX plánují ve svých příštích verzích přejít na používání platformy WF.

Obrázek 5 BizTalk server a budoucí pozice Windows WF

8 / 64

WF workflow jsou složena z aktivit. Aktivity představují samostatné kousky funkcionality, které slouží ke stavbě specifických business aktivit. Aktivity můžeme rozdělit do dvou skupin:

• složené – používají se k vyjádření příkazů pro kontrolu běhu (např. while, for, if-then-else, case, atd.) a pro aktivity, které sdílejí stejné chování (sekvence, podmíněné skupiny aktivit, atd.). Tyto aktivity jsou také používány pro vytváření znovupoužitelných sub-procesů nebo sub-workflow.

• individuální – poskytují mechanismus jak zachytit jeden kousek práce, který musí být vykonán ve stejném kroku workflow.

Obecně mohou mít aktivity vlastnosti a výkonné části - metody. Metody jsou spouštěny buď synchronně nebo asynchronně, záleží na jejich definici. Aktivity tedy představují nejmenší stavební bloky dostupné vývojářům při rozšiřování workflow frameworku. Windows WF poskytuje základní knihovnu aktivit, které mohou vývojáři použít buď jako základ svých aplikací nebo pro vývoj nových aktivit. Knihovna představuje nejmenší sadu rozšiřitelných aktivit nutných pro tvorbu workflow.

Běhové prostředí workflow je zodpovědné za převzetí definic workflow a jejich instanciaci. Životní cyklus instance workflow je zcela řízen běhovým prostředím. To je tedy zodpovědné za vytváření, spouštění, threading, persistenci, sledování, řízení stavů, reakce na komunikační události, koordinování transakcí atd. Tyto funkce řízení jsou poskytovány běhovým prostředím skrze definované služby. Výchozí sadu služeb mohou aplikační programátoři nahradit vlastními službami. Použitím tohoto modelu mohou vývojáři zpřístupnit jejich existující hostující infrastrukturu workflow knihovně. Framework nabízí sadu out-of-box služeb, které umožňují vývojářům rychle začít používat prostředí aniž by byli obtěžováni psát složitý kód pro zajištění těchto služeb. Out-of-box služby jsou instancovány a registrovány přímo s běhovým prostředím .

Windows WF a MVC vzor Jednou z cest, jak lze využívat Windows WF v ASP.NET aplikacích je implementace tzv. Model-View-Controller (MVC) přístupu. Hlavní devízou MVC je důsledné oddělení prezentační logiky, aplikační logiky a toku aplikační logiky navzájem od sebe (code-separation).

Pro přiblížení toho přístupu v ASP.NET aplikacích si zkusme představit jednoduchý a klasický help desk systém s tickety. Business uživatel startuje workflow vyplněním ASP.NET web formuláře a kliknutím na odesílací tlačítko. Nato je serverem upozorněn zaměstnanec prostřednictvím Windows Forms aplikace o dostupnosti nového ticketu. Zaměstnanec help desku pak bude pracovat na problému a eventuálně problém uzavře. Kdyby byl tento workflow scénář vytvořen za pomocí Windows WF, veškerá procesní logika a tok by mohly být uloženy v samotném workflow, stranou od ASP.NET aplikace, která by tak nemusela vědět nic o samotné logice procesu.

Tento scénář poskytuje některé podpůrné důkazy pro tvrzení, že je dobré oddělit prezentační části od logiky. Protože proces vypořádání se s požadavky na help desk je vcelku běžný, kdyby byla logika implementována v C# nebo v ASP.NET kódu v několika různých .NET aplikacích, hrozil by vznik duplicit kódu v různých implementacích - v různých jazycích - stejného business procesu. Pokud se ale proces implementuje ve Windows WF, vývojáři aplikací, které vyžadují určitý proces, budou schopni měnit kroky procesu pouze na jednom místě – v samotném workflow – bez toho, aniž by se obávali změny logiky jejich aplikací. Duplikace kódu a nejednoznačnost místa, kde implementovat daný proces může být značně snížena s Windows WF.

Pokud vývojáři implementují MVC architekturu v ASP.NET použitím Windows WF, měli by se v co největší míře pokusit postavit jejich workflow pokud možno nezávisle na aplikacích, ve kterých bude hostováno. Takový přístup pomůže ponechat logiku oddělenou od prezentační

9 / 64

části a tím dojde i k zachování vysoké míry nezávislosti mezi jednotlivými kroky workflow např. toku stránek ve webové aplikaci.

Vývojář zkoušící Windows WF může být často v pokušení tvořit workflow jako sadu aktivit v určitém pořadí a poté vytvořit sadu ASP.NET web formulářů, které jdou z jedné stránky na druhou ve stejném pořadí jako aktivity jeho workflow. Naneštěstí, ačkoliv to vypadá vcelku logicky, je takový přístup kontraproduktivní, protože vyžaduje implementaci stejné logiky dvakrát. Pro správnou implementaci kroků workflow by webová stránka X neměla být závislá na znalosti zda po ní bude následovat stránka Y nebo stránka Z. Namísto toho, workflow (model) by měl říci ASP.NET (controller) co je dalším krokem, a ASP.NET by měl rozhodnout, kterou stránku (view) zobrazí. Takto každá stránka vyžaduje pouze velmi malou znalost celkového procesu, potřebuje pouze vědět jak provést jednu samostatnou a oddělenou aktivitu a veškerou starost o tom, jaká stránka bude následovat přenechá na workflow. Tato separace poskytuje vývojářům velkou míru flexibility co se týče pořadí stránek. Například, pokud se rozhodneme změnit sekvenci stránek, můžeme to udělat lehce změnou ve workflow bez změny jediné řádky kódu v ASP.NET aplikaci.

Typy vývojářů Windows WF rozlišuje tři základní typy vývojářů (viz. Obrázek 6).

• host developer

• activity developer

• workflow developer

Obrázek 6 Rozvrstvení vývojářů

Host developer je odpovědný za poskytnutí běhového prostředí, které používá workflow run-time komponenty ke spuštění workflow. Host aplikace potřebují stavět na stabilním komunikačním základu tak, aby umožnily existenci lokálních protokolů mezi host aplikací a workflow knihovnou. Dále, host vývojáři jsou odpovědní za registraci workflow služeb s workflow run-time a za registraci out-of-box služeb s workflow run-time, ačkoliv existují situace ve kterých out-of-box služby nevyhovují kladeným nárokům host aplikací. Služby poskytované host aplikacemi zakládají kvalitu sdílených služeb mezi workflow instancemi.

10 / 64

Z tohoto důvodu nabízí workflow framework mechanismus pro vytváření nových služeb skrze dědičnost.

Activity developer vytváří samostatné logické komponenty míněné pro použití workflow vývojáři a vytváří tak celé workflow knihovny. Aktivity se navrhují buď pro více host aplikací nebo se upravují pro specifického hosta. Tyto komponenty mohou být naprosto soběstačné (ekvivalent černé skříňky) nebo mohou umožňovat workflow vývojářům vytvářet vlastní řídící ovladače běhu workflow v prostředí s oddělením kódu. Aktivity uzpůsobené pro specifického hosta většinou využívají výhod plynoucích z lokálních komunikačních protokolů a služeb definovaných hostující aplikací.

Obrázek 7 Různé úrovně vývoje workflow knihoven

Workflow vývojáři spojují práci tvůrců aktivit a vývojářů host aplikací pro tvorbu workflow. Jejich práce spočívá ve využívání out-of-box knihoven aktivit a zákaznických knihoven aktivit pro tvorbu definic workflow. Hlavním nástrojem většiny vývojářů workflow jsou grafické nástroje pro tvorbu workflow grafů. Na druhou stranu, spektrum nástrojů sahá od neprogramátorských aplikací typu Microsoft FrontPage po kompletní programátorské vývojové prostředí typu Microsoft Visual Studio.

Možnosti Frameworku Podpora pro dlouhotrvající workflow je jednou z hlavních předností Microsoft Windows Workflow. WF poskytuje požadovanou infrastrukturu pro podporu spouštění dlouhotrvajících workflow. Tyto workflow závisí na persistenci, transakcích, sledování a zpracování na straně hosta, aby vykonaly požadované úkoly. Pokud je workflow v nečinnosti, čeká na informace od uživatelů nebo systémů, je automaticky uloženo a odstraněno z paměti – tím se značně ušetří drahocenné zdroje.

11 / 64

Persistence služba poskytuje výchozí služby stavového managementu pro Microsoft SQL Server (SqlStatePersistenceService třída). Pro tyto služby jsou dostupná schémata a ukládací procedury, které umožňují databázi služby existovat v jiné databázi. Důvod pro tyto služby je podpora pro přirozenou dlouhodobost workflow aplikací a a zároveň poskytnutí automatického stupně persistence pro workflow stavy.

Timer služby jsou také poskytovány pro podpůrný management časově orientovaných triggerů. Jsou dostupné i out-of-box časové služby, které rozšiřují Microsoft SQL Server databázi (SqlTimerSevice třída). Představme si scénář ve kterém je nutno eskalovat zprávu po uplyutí čtyř hodin bez reakce na zprávu a systém se vypne dříve než vypršel čas. Použitím persistentních timerů spolu s persistentními stavy dovoluje vývojáři aby se nestaral o ztrátu timerů a nemusel se starat o ruční spouštění událostí, když dojde k vypršení času.

Služby sledování poskytují výchozí mechanismus pro generování auditovacích údajů a nahrávání historických informací. Tyto informace mohou být uloženy v paměti nebo v trvalém uložišti. Out-of-box sledovací služby rozšiřují databázi MS SQL Server o manipulaci se sledovacími informacemi (SQLTrackingService). Informace o sledování obsahuje jméno aktivity, čas kdy byla spuštěna, a kdy byly spuštěny různé stavy aktivity. Dále mohou být definovány sledovací profily pro zachycení určité specifické množiny sledovaných jevů. Informace mohou být upraveny aby zachycovaly specifické změny statusu aktivit, změnu vlastnosti aktivit a dat instance workflow.

Obrázek 8 Schéma služeb Windows WF frameworku

12 / 64

Komunikace mezi workflow a jeho okolním prostředím se koná třemi různými způsoby (viz. Obrázek 9):

• pomocí parametrů

• pomocí příchozích událostí

• pomocí odchozího vyvolání metody Parametry poskytují mechanismus pro inicializaci instance workflow s informacemi z vnějšího workflow a pro přístup k datům poté, co workflow doběhlo. Příchozí události poskytují mechanismus pro předávání informací z hostující aplikace do instance workflow během jejího běhu, a to asynchronním způsobem. Příchozí události jsou pak zpracovávány pomocí front. Odchozí vyvolání metody poskytuje pro workflow mechanismus pro odesílaní dat z hostující aplikace. Hostující aplikace registruje službu, která je přístupná pro instance workflow za účelem spouštění metod na této službě. Skrze tento způsob volání, hostující aplikace získává přístup k informacím plynoucím z workflow, a to synchronním způsobem.

Obrázek 9 Schéma komunikace mezi workflow a jeho okolím

Vývojové prostředí Podívejme se na vývojové prostředí na Obrázek 10. Microsoft Visual Studio poskytuje sadu šablon projektů, které mohou být použity při vývoji workflow aplikací. Tyto projektové šablony nabízí grafického workflow návrháře, který může být eventuálně použit i v aplikacích mimo Visual Studio při tvorbě vlastního návrhového prostředí. Ve Visual Studio Workflow Designeru najdete workflow aktivity na panelu. Pak již stačí aktivity drag & drop přetáhnout na plochu a tvořit tak workflow. Jakmile je aktivita vybrána, je možno měnit její vlastnosti v property window. Aktivity mohou být kopírovány, vkládány, komentovány pro zlepšení vývojářských zkušeností. Komentované aktivity jsou viditelné v návrhovém prostředí, ale nejsou již spouštěny během vlastního běhu.

13 / 64

Obrázek 10 Vývojvé prostředí Visual Studio

Vývojáři mohou vytvářet aktivity ve Visual Studiu vytvořením Workflow Activity Library projektu. Podporováno šablonami Visual Studia, které dále umožňuje pomocí grafického prostředí definovat sub-workflow jako jednu složenou aktivitu. Aktivity jsou zkompilovány do knihoven aktivit, jakmile jsou jednou sestaveny, zobrazí se na panelu ve Visual Studiu spolu s výchozími knihovnami aktivit.

Knihovny Workflow mohou být laděny pomocí prostředí Visual Studia, jak je ukázáno na Obrázek 11. To umožňuje vývojářům určovat si breakpointy ve workflow aktivitách uvnitř Workflow Designeru. Jakmile je breakpoint dosažen uvnitř designeru, je vývojář schopen procházet (drill down) skrze oddělení kódu (code-separation). To je možné pouze pokud je s probíhající aktivitou asociováný programový kód, jinak se zobrazí pohled do Intermediate Language (IL). Grafické ladění workflow dovoluje vývojářům sledovat průběh toku ve workflow a data vstupující a ovlivňující běh workflow.

14 / 64

Obrázek 11 Visual Studio a jeho ladící možnosti

Jedna z dalších dobrých vlastnostní frameworku spočívá ve schopnosti zakomponovat workflow designera dovnitř vlastních WinForm aplikací. Komponenta si přečte workflow objekt, který je vytvořen pomocí Workflow Application Programming Interface (API). Tato schoponost zvyšuje produktivitu vývojářů zajimajících se o vytváření vlastních návrhových aplikací. Návrhová prostředí většinou směřují do prostředí systémových analytiků nebo do linie business uživatelů.

Závěr Microsoft Windows Workflow Foundation poskytuje framework pro vývoj workflow za použití .NET frameworku. Cílem Frameworku je zvýšit produktivitu vývojářů, kteří potřebují vytvářet a zapojovat sílu workflow, speciálně pak sémantiku dlouhotrvajících aplikací, právě do jejich aplikací. Charakteristiky dlouhotrvajících procesů znesnadňují vývojářům tvorbu takové infrastruktury, která by optimálním způsobem podporovala běh takovýchto komplexních procesů. Použitím WF jsou vývojáři vybaveni nástroji, které jim umožňují vytvářet komplexní aplikace pro podporu business procesů s podporou vlastnostní jako jsou transakce, souběžnost (concurrency), kompenzaci (compensation), sledování a komunikaci bez jakýchkoliv obav o jejich vedení. S WF, Microsoft zpřístupňuje workflow každému. :)

15 / 64

Webové služby Integrace aplikací v minulosti představovala tvrdý oříšek a ne vždy dosáhla očekávaných výsledků. Problémy byly zejména technického rázu – např. jak „skloubit“ 2 aplikace postavené na odlišných platformách. V současnosti však existuje mocný nástroj pro integraci na aplikační úrovni – webové služby. Za prosazením webových služeb stojí největší softwarové firmy světa jako je IBM, Microsoft a proto nelze pochybovat o jejich nasazení v budoucnu. Webové služby jsou souborem protokolů a standardů využívaných pro výměnu dat mezi aplikacemi nebo systémy. Komunikace těchto aplikací probíhá na základě zasílání přesně definovaných XML zpráv skrze protokol HTTP či jiný. Dopad této technologie je obrovský – program napsaný v Pythonu může využívat služeb jiné aplikace napsané v Javě a navíc skrze komunikační síť. Pro formát vyměňovaných zpráv se zprvu využívalo specifikace XML-RPC či JAX-RPC. V současné době je používán novější komunikační protokol SOAP (Simple Object Access Protocol), který zahrnuje mnohá zdokonalení např. v oblasti bezpečnosti či uživatelských datových typů. Ukázka XML zprávy protokolu SOAP je znázorněna níže.

Klient si podle rozhraní, definované prostřednictvím WSDL, si vyžádá produktu s ID 827635. Zpráva je zaslána protokolem HTTP, prostřednictvím metody POST na server.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductDetails xmlns="http://warehouse.example.com/ws"> <productID>827635</productID> </getProductDetails> </soap:Body> </soap:Envelope>

Server vrátí odpověď s detaily o produktu, která může vypadat následovně.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductDetailsResponse xmlns="http://warehouse.example.com/ws"> <getProductDetailsResult> <productName>Toptimate 3-Piece Set</productName> <productID>827635</productID> <description>3-Piece luggage set. Black Polyester.</description> <price>96.50</price> <inStock>true</inStock> </getProductDetailsResult> </getProductDetailsResponse> </soap:Body> </soap:Envelope>

V rámci webových služeb je nutno objasnit ještě některé další pojmy. UDDI (Universal Description Discovery and Integration) je označení pro registr webových služeb. V tomto registru jsou shromažďovány odkazy na webové služby a informace k jejich použití napsaných v jazyku WSDL (Web Services Description Language). Ten popisuje rozhraní webové služby (metody, parametry a výstupy).

Myšlenka webových služeb jde dále než jen integrovat aplikace v rámci IS podniku. Webové služby by v budoucnu mohly umožnit úzce propojit aplikace mezi jednotlivými podniky i státní správou a to vše dynamicky dle potřeby díky UDDI registrům. Schéma takové integrace je ukázáno na obrázku níže.

16 / 64

Obrázek 12 - Integrace webových služeb

Abychom však neuváděli jen samé výhody nasazení webových služeb – použití jazyka XML pro definici zpráv způsobuje slabší výkonnost v porovnání s ostatními integračními přístupy (např. použití protokolu SOAP je typicky až 10x časově náročnější než použití binárních protokolů CORBA či DCOM). Důvod je v „neúspornosti“ XML formátu a v pomalém parserování zpráv. V současnosti též ve specifikaci webových služeb chybí podpora transakcí.

Service oriented architecture V souvislosti s webovými technologiemi lze narazit i na další pojem – SOA. SOA představuje zcela nový přístup k vývoji software, nikoliv technologii samotnou. Koncept se opírá o tvorbu takové softwarové architektury, která se skládá z volně pospojovaných, nezávislých aplikačních služeb, a svou podstatou se snaží o dokonalejší naplnění uživatelských potřeb. Tento koncept však není vázán na konkrétní integrační technologii – kromě dominujících technologií lze tedy použít i standardy CORBA či DCOM.

Aplikační služba je tedy samostatná komponenta, která přijímá požadavky a vrací odezvy skrze definované rozhraní. Typicky je toto rozhraní tvořeno webovými službami, z čehož plyne technologická nezávislost služby a možnost rozptýlení služeb po síti. „Poskládání“ těchto služeb tak, aby implementovaly firemní proces, nazýváme orchestrací. Zorchestrované služby poté plní funkci aplikační logiky, která zpracovává data. Jazyky jako BPEL či WS-coordination jdou ještě dále, protože tvoří metody jak přímo popsat firemní workflow a na základě tohoto popisu umožňují služby efektivně zorchestrovat. Jazyk BPEL bude více představen níže. Na vývojáře tento koncept klade nové požadavky v podobě změny úhlu pohledu. Jde zejména o návrh takových služeb, které jsou dostatečně obecné, snadno znovu použitelné a pro koncového uživatele přínosné.

SOA - podrobněji SOA může být definována jako způsob návrhu a implementace podnikových aplikací vznikajících propojováním znovupoužitelných komponent (služeb) volnou vazbou (loose coupling) na „podnikové úrovni“ (business level). Tato definice zasluhuje určité vysvětlení.

17 / 64

Služby na „business level“ Překlad spojeni „business level“ jako podniková úroveň je nicneříkající a mírně zavádějící. Každopádně řeč je o granularitě služeb.

Nejlépe úroveň granularity vystihuje obrázek. Z jednotlivých komponent jsou vytvářené logické celky – služby odpovídající činnostem (funkcím) v rámci určitého procesu. Ze služeb je pak vytvářené workflow, které představuje podnikový proces. Například v procesu objednávky (který je určitým workflow) je jedna z činností označena jako zjištění bonity klienta – tuto činnost představuje služba která integruje zjištění informací o neuhrazených pohledávkách klienta, informací o kreditní historii a pod.

Volná vazba Principy volné vazby je možné vyjádřit negováním problémů pevné vazby:

• Minimální zásah do existujících aplikací – pokud je při implementaci vyžadován zásah do existujících aplikací, měl by být co nejmenší. Pokud je změna aplikace nezbytná, měly by veškeré změny být lokalizovány na jednom místě (změny „vedle“

18 / 64

aplikace, nikoliv „do“ aplikace). • Nezávislost a autonomie aplikací – každá aplikace by měla respektovat autonomii

ostatních aplikací. Komunikace mezi aplikacemi by měla probíhat způsobem, který nevyžaduje žádné znalosti interní funkce druhé aplikace. Nedostupnost jedné aplikace by měla mít minimální dopad na funkci celého systému, v ideálním případě by neměla zasáhnout žádnou jinou aplikaci (failure isolation), přičemž s touto nedostupností se a priori počítá.

• Bezpečnostní selhání či prolomení jedné aplikace neohrozí další (security isolation). Komunikace mezi aplikacemi by měla být natolik obecná, aby mohla zůstat zachována i při změně nebo náhradě některé z aplikací – v ideálním případě by se tato změna nebo náhrada neměla mimo dotyčnou aplikaci jakkoliv projevit.

• Škálovatelnost s počtem aplikací – přidání další aplikace do integračního prostředí by v ideálním případě mělo připomínat připojení dalšího spotřebiče do zásuvky. Složitost a nákladnost tohoto připojení by měla záviset pouze na složitosti a komplexnosti nové aplikace, nikoliv na existujících již integrovaných aplikacích. Jednotlivé aplikace je tak možné rozvíjet odděleně bez větších ohledů na zbytek prostředí.

• Dodržování standardů – aplikace by měly dodržovat existující standardy, které platí de facto a zároveň de iure, tzn. nejde o „standardy“ protlačované jednotlivými výrobci softwaru ani o standardy, které nikdy nepřekročí rámec zajímavého akademického cvičení. Dodržováním standardů se integrace zjednodušuje tím více, čím různorodější a heterogennější je stávající prostředí.

Služba „Služba (service) je autonomní část software, která implementuje logiku v podobě kódu, spravuje svůj stav, komunikuje prostřednictvím zpráv, je řízena politikou a je dostupná po síti“.

Dále popíšeme jednotlivá klíčová slova definice:

• Stav (State) – stavem se rozumí data, které služba spravuje a poskytuje navenek. Stav by měl být trvalý (tedy odolný proti vnějším vlivům) a konzistentní. Fyzicky se stavem rozumí nejčastěji data uložená v databázi, nejsou však vyloučené jiné formy uchovávání dat – XML dokumenty, jiné strukturované textové nebo binární soubory atd. Konzistence je pak dosahováno transakčním přístupem k zpracovávání dat.

• Zpráva (Message) – služba komunikuje se svým okolím prostřednictvím zpráv.

19 / 64

Komunikace může být jednosměrná nebo obousměrná. Protokol pro komunikaci a formát zprávy musí být jasně definovaný. Nejčastěji je používán formát XML a XML Schema pro svou jednoduchost a podporu napříč všemi platformami, dále se může jednat o formát EDI nebo o proprietární formát. To se však nedoporučuje. Služba kontroluje formát zpráv po obsahové i formální stránce. Implicitně nepředpokládá, že zprávy jsou správně formulovány. Tomuto principu se říká zdravá nedůvěra (healthy distrust). Po formální stránce tedy může být kontrolován formát zprávy (např. jestli je XML dokument „well-formed“ proti své XML Schema). Po věcné stránce je pak kontrolován správný počet argumentů volané vzdálené procedury (RPC). Protokol nejčastěji používaný pro komunikaci se jmenuje SOAP a budeme se jím zabývat v souvislosti s webovými službami. Kontrakt (Contract) – V kontra• ktu je definováno, jakým způsobem bude služba

• řazujeme

oncept SOA počítá se dvěma typy rolí: poskytovatel (provider) a spotřebitel (consumer).

působem vytvoření a užití můžeme služby třídit podle:

nní

• Kom ooduché

• Orchesé

í

Webové služby (Web Services - WS)

by byla zaručena skutečná platformní i jazyková nezávislost, pro jakýkoliv popis jakýchkoli dat je používán jazyk XML. WS pracují nad abstraktními modely, takže je možné dynamicky

komunikovat – tedy jakým způsobem bude nastavena bezpečnost, pomocí jakého protokolu bude služba komunikovat, jaký bude formát zpráv a pod. Pro popis kontraktu je využíván WSDL, který definuje, jaké operace jsou podporovány, jaké formáty zpráv jsou používány, jaký protokol je používán atd. Politika (Policy) – Každá služba je řízená určitou politikou. Mezi politiky zaoperační charakteristiky (znaková sada, transportní protokol, logování apod.) Politika bývá vyjádřena ve formě SLA.

KPoskytovatel určuje pravidla služby (tedy politiky). Spotřebitel pak na základě těchto pravidel službu vyvolá a „spotřebovává“ její funkčnost. V tomto vztahu může existovat prostředník, kterému poskytovatelé „nabízejí“ svoje rozhraní a spotřebitelé je u prostředníka vyhledávají a pak používají (jedná se o UDDI popsané níže).

Z

• Synchronnosti o Synchroo Asynchronní o Konverzační p zice o Jedno Složené

trace o Sériovo Paraleln

WS je technologie, která umožňuje aplikacím komunikovat nezávisle na programovacím jazyku a platformě. Je definován interface pro výměnu dat a zpráv prostřednictvím standardizovaných XML dokumentů. Používané protokoly jsou založeny na XML a popisují, jakým způsobem se data mezi službami vyměňují a formát těchto dat. Koncept webových služeb spojuje princip komponentního programování a internetových technologií. Komponentní programování je založeno na faktu, že aplikace využívá funkcionalitu komponenty bez toho aby znala implementační detaily. Komponenta pouze zveřejní svůj interface, který se nemění v průběhu životního cyklu komponenty. V případě webových služeb je interface zveřejněn v internetovém prostředí.

A

20 / 64

popisovat data, datové struktury a formáty – webové služby jsou „samo popisné“. To dává vývojářů mnohem větší možnosti. Webové služby zpravidla implementují určitou funkčnost. Z jednotlivých služeb je možné vytvářet další – kompozitní webové služby, vytvářet workflow a business procesy. Současně WS svým konceptem překonávají mentální bariéru mezi vývojáři a manažery, protože na pojmu služba se dokážou shodnout, lépe komunikovat a vyjádřit obsah (funkčnost) služby. Webové služby umožňují

• Komunikovat navzájem nezávisle na platformě a programovacím jazyku • Koncepčně rozvrhnout aplikační funkcionalitu do jednotlivých služeb a zpřístupnit ji

jednotlivých aplikací, konflikty verzí (známé „DLL Hell“ v COM),

• • vat s ostatními

a pod.

aplikací

ro we tné tři protokoly:

ej v pisuje následující obrázek:

„spotřebitelům“ • Integrovat aplikace „volnou vazbou“ (loose coupling), která odstraňuje problémy s

novými verzemi ochranu při pádu jedné ze služeb atd. Přizpůsobit existující aplikace novým požadavkům Poskytnou starým aplikacím komuniko

• Řídit architekturu z hlediska funkcionality, nákladů

Webové služby jsou využívány v dvou základních kontextech:

• Zpřístupnění funkcionality starých aplikací a integrace• Vystavení nové funkcionality „spotřebitelům“ - ať již na internetu nebo v podnikové

aplikační architektuře

P bové služby jsou podsta

• UDDI • WSDL • SOAP

J ich ztah po

• UDDI (Universal Description, Discovery and Integration) – představuje katalog dostupných webových služeb (obdoba Zlatých stránek). UDDI obsahuje jednak informace o názvech a adresách webových služeb (bílé stránky), dále pak informace a zatřídění podle poskytovaného obsahu (žluté stránky) a podporované protokoly a

21 / 64

formáty (zelené stránky). WSDL (Web Service Description Language) – Jak již název protokolu napovídá, WSDL popisuje webovo

• u službu – jakým způsobem je možné se službou

• ML a může fungovat nad různými

yto zá díky vé jednoduchosti se stali webové služby tak populární, protože na všichni hlavní dodavatelé

komunikovat, jaké metody je možné volat a jejich parametry, popis formátu dat a datových struktur. Tomuto popisu se v terminologii webových služeb říká kontrakt (mezi poskytovatelem a spotřebitelem služby). SOAP (Simple Object Access Protocol) je určen k výměně zpráv mezi webovými službami. Protokol je rovněž založen na Xtransportními protokoly, nejčastěji nad HTTP. Tímto protokolem je možné posílat jak strukturované dokumenty, tak vzdálená volání služeb (Remote Procedure Call).

kladní protokoly jsou velice jednoduché, dalo by se říci až minimalistické. PrávěTsbyli schopni se dohodnout na minimální množině funkcionality a současně jednoduchosti na implementaci. Na druhé straně mají tyto standardy zásadní nevýhodu: nepokrývají řadu oblastí, jakými jsou transakční zpracování či bezpečnost. Jednoduchost na implementaci. Proto vzniká postupem času řada nových standardů, které doplňují funkcionalitu SOAP, WSDL a UDDI a přidávají tolik potřebné vlastnosti. Různé oblasti a jejich návaznost na protokoly znázorňuje následující obrázek:

Vztah procesu a služby ré transformují vstupy (input) na určitý výstup (output). Proces ýt něco vykonáno. Proces bývá vyvolán vnějším podnětem.

ou identické, protože služba definuje CO se bude dělat a proces le

Proces je soubor aktivit, ktetedy definuje, JAK musí bV současnosti se vede vážná polemika o tom, jaká je vazba mezi službou a procesem. V zásadě existují dva pohledy na věc:

1. Procesy a služby jsou identické a tudíž jedna služba by měla pokrývat jeden proces 2. Procesy a služby nejs

určuje JAK se to bude dělat. Služby musí být tedy přirazeny nikoli procesům, abiznis funkcím

22 / 64

Je pravdou, že první koncept neodpovídá teoretickým definicím procesu a služeb. Na druhou stranu, tento rozpor v teoretické oblasti je vyvážen řadou výhod v praktické oblasti. Za prvé, je velice jednoduché vytvářet služby z již existujícího procesního modelu organizace. V případě, že firma má již vybudován svůj procesní model, je velice rychlé navrhnout novou informační architekturu založenou na službách a tím snížit náklady na analýzu a implementaci celého řešení. Uspořádáni Jedna-k-Jedné (One-to-One) mezi procesem a službou je navíc přehledné, čitelné a snadno pochopitelné pro představitele biznisu, kteří jsou odpovědní za definici a správné fungování procesů. Jakékoliv změny v procesu se jednoduše promítnou do změny služeb, protože mezi nimi existuje jasná, snadno dokumentovatelná vazba. Zásadním nedostatkem tohoto přístupu je, že se organizace vůbec nezamýšlí nad svým současným procesním modelem. SOA jako taková není pouze technologickou záležitostí, ale zasahuje do všech úrovní řízení firmy, od top managementu přes biznis uživatele až po IT oddělení. Prosté přemítnutí procesu na služby nedává tedy prostor ke zlepšení služeb či Business Process Reengineeringu a navíc existuje vysoká pravděpodobnost vnesení zásadních chyb do nové modelu služeb. Není brán ohled na celkový obraz organizace a celé SOA se změní pouze na změnu technologie, co může mít negativní dopad na návratnost investice (ROI).

Druhý způsob tvorby služeb respektuje teoretické definice, ale v tomto přístupu je obtížnější a tudíž riskantnější definovat nové služby. Mnohé definice musí být vytvořeny úplně od začátku počnouc všeobecnými funkcemi biznisu, jejich cíly a pokračujíc rozpadem na procesy a návaznost procesů v jednotlivých biznis funkcích. Tento přístup k návrhu SOA vyžaduje samozřejmě vyšší zainteresovanost manažerů na všech úrovních organizační struktury.

tabulka 1Porovnání výhod a nevýhod přístupů

Výhody Nevýhody

Služba navázaná na proces • Jednoduchá definice služby

• Jednodušší model • Rychlejší

implementace

• Redundance služeb • Vnášení chyb

z procesního modelu • Tvorba izolovaných

datových sil bez vzájemných vztahů

• Nezahrnuje strategickou úroveň společnosti

Služba navázaná na biznis funkci

• Odpovídá teoretickým definicím

• Strategický pohled na SOA

• Zainteresovanost top managementu

• Navzájem převázané služby bez redundance

• Synergické efekty

• Náročnější na zdroje (čas, finance)

• Komplikovanější a riskantnejší

Orchestrace a choreografie služeb a vztah k workflow Orchestrace (Orchestration) je návaznost jednotlivých služeb s doplňující logikou, která vytváří proces. Orchestrace nezahrnuje prezentaci dat. Pro orchestraci se v oblasti webových služeb nejčastěji využívá jazyk BPEL. Výsledkem orchestrace je broker, který administruje

23 / 64

(spouští a předává data) jednotlivým službám. Orchestrace se uplatňuje ve službách v rámci jedné organizace, není využívaná v mezi-firemních službách.

Choreografie (Choreography) definuje, jak navzájem rovnocenní partneři (peer to peer participants) koordinují své aktivity – výměnu zpráv a navigaci v průběhu vykonávání služby. Choreografie může existovat mezi dvěma nebo více účastníky a je využívaná v mezi-podnikových vztazích. Jedná se ovšem o formální popis interakce, technická implementace musí být realizována jinými technologiemi (např. BPEL). Jazykem pro choreografii je WS-CDL.

Choreografie Orchestrace

Oblast působnosti Uvnitř podniku Mezi podniky

Výstup Spustitelná komponenta – broker

Formální popis – metadata

Partneři Nerovnocenný broker, služby Rovnocenní partneři

Popisný jazyk BPEL WS-CDL

Pozornost bude dále soustředěna na WS-CDL, který byl standardizován pouze v listopadu 2005. Specifikace si klade za cíl formalizovaně popsat způsob spolupráce nezávislých účastníků bez ohledu na jejich běhovou platformu či programovací model. WS-CDL dokument představuje „globální“ kontrakt, který popisuje chování jednotlivých účastníků a jejich vzájemnou interakci. Na základě tohoto kontraktu si každý z účastníků z tohoto všeobecného popisu vytvoří vlastní interakční pravidla. Jak již bylo řečeno, WS-CDL je pouze formální popis vztahů a způsob technologické a technické realizace si určí každý účastník sám (užitím BPEL, Java apod.).

24 / 64

Tento způsob zápisu vztahů mezi jednotlivými účastníky přináší následující výhody:

• Znovupoužitelnost – tatáž choreografie může být použitelná pro různé účastníky existující v různých kontextech (průmyslové odvětví, společnost, oddělení) a s různým typem aplikačního software

• Spolupráce – choreografie popisuje jak mají jednotlivý účastníci spolupracovat a jakém sledu si mají vyměňovat zprávy. Tato spolupráce může existovat mezi libovolným množstvím účastníků

• Čitatelnost – tento formalizovaný popis je jednoduše čitelný jak pro člověka, tak pro strojového agenta

• Skládání – jednotlivé choreografie můžou být skládány do složitějších kompozic Specifikace WS-CDL představuje dva hlavní přínosy. Za prvé je to další úroveň metadat o informačním systému, která zvyšuje flexibilitu tohoto systému a tím snižuje náročnost úprav a integrace s jinými systémy. S tím úzce souvisí druhý přínos, který spočívá v oddělení definice vzájemné interakce od její implementace. Protože definice není „natvrdo“ zabudovaná v komponentě, je možné jednotlivou část kdykoliv nahradit. Nová komponenta poté pouze automaticky vygeneruje implementaci choreografie (např. pomocí BPEL). WS-CDL má definovány implementační můstky s XLANG, BPEL, BPML a dalšími procesními jazyky. Je však na všech těchto jazycích nezávislý.

25 / 64

Základní části WS-CDL:

• Účastník (participant) – definuje jednotlivé účastníky, např. kupec, prodejce • Kanál (channel) – definuje představuje místo, kde probíhá interakce účastníků,

např. prodejní kanál • Vztah (relationship) – k jakým vztahům může docházet mezi účastníky v kanálu,

např. objednávka, dodávka zboží, fakturace • Informace (information) – dokumenty, které si předávají účastníci, např. nákupní

objednávka, dodací list • Interakce (interaction) – postup, jakým dochází k tvorbě choreografie, např.

kupec zašle prodejci nákupní objednávku • Proměnné a výrazy (variables and expressions) – informace o stavu objektů

v choreografii a definované funkce nad nimi, např. stav objednávky a výpočet doby dodání

Element Značka

Účastník <participantType />

Kanál <channelType />

Vztah <relationShipType />

Informace <informationType />

Interakce <interaction />

Výměna zpráv <exchange />

Ukázka jednoduché interakce účastníků:

<interact name="inventoryCheck"

onChannel="inventory-channel"

operation="inventoryCredit"

initiateChoreography="true">

<participate

relationship="SellerInventoryBinding"

fromRole="Seller"

toRole="Inventory"/>

<align state="inventoryRequestDoc"

with-state="inventoryRequestDoc"/>

26 / 64

Choreografie a její popisný jazyk WS-CDL tedy definuje jakým způsobem si budou účastníci procesu předávat informace. Když porovnáme tuto skutečnost s definicí workflow („Workflow znamená automatizaci celého nebo části podnikového procesu, během kterého jsou dokumenty, informace nebo úkoly předávány od jednoho účastníka procesu k druhému podle sady procedurálních pravidel tak, aby se dosáhlo nebo přispělo k plnění celkových/globálních podnikových cílů“), musíme dojít ke konstatování, že choreografie je způsob definování workflow v rámci procesu. Toto workflow je pak realizováno výkonnými jazyky jako BPEL.

BPEL (Business Process Execution Language)

Pro realizaci konceptu SOA bylo třeba navrhnout způsob, jak jednotlivé webové služby, nabízející samostatnou funkcionalitu, sladit do procesů. V minulosti využívaly produkty BPM (Business Process Management) své vlastní speciální jazyky a odvozovací mechanismy pro zpracování i nástroje pro design. S rostoucím významem architektur orientovaných na služby vyvstal ale požadavek na sjednocení jazyků a ustavení všeobecně přijímaného standardu. To vedlo k vytvoření standardu s názvem Web Services Business Process Execution Language (BPEL). BPEL je výsledkem spojení zejména dvou jazyků pro popis workflow. Web Services Flow Language (WSFL) navrženého firmou IBM a jazyka XLANG od Microsoftu. Na základě spolupráce společností BEA Systems, IBM a Microsoft pak vznikl tedy společný standard BPEL, který je v současné době pod kontrolou Organizace pro pokrok ve standardizaci strukturovaných informací (OASIS). BPEL je podporován širokým spektrem subjektů, a proto se očekává jeho velké rozšíření, které by mělo podnítit přijetí technologií BPM a SOA.

Nyní se podívejme blíže, co tento standard přináší. BPEL (někdy rovněž označovaný jako BPEL4WS nebo WSBPEL) je jazyk pro popis procesů založený na bázi XML. Pomocí něj lze sladit existující webové služby do procesu, který se rovněž sám stává webovou službou. Proces slaďování se často označuje termínem orchestrace. Při orchestraci, která se používá obvykle v soukromých business procesech, přebírá centrální proces kontrolu nad využívanými webovými službami a koordinuje vykonávání různých operací. Využívaná webová služba tak ani „neví“, že je součástí procesu na vyšší úrovni. BPEL proces tak představuje abstraktní vrstvu, která agreguje samostatné webové služby do vyššího celku, který pak sám funguje jako webová služba.

Obrázek 13 – Orchestrace webových služeb

Je důležité zdůraznit, že BPEL umí jen komunikovat s webovými službami. Sladění webových služeb je vše, co dokáže. Není určen k integrování se zdroji, které neposkytují rozhraní pro webové služby.

Uvnitř firmy je BPEL používán pro definici procesů, které využívají dříve izolované systémy. Mezi organizacemi pak BPEL umožňuje snadnější a efektivnější integraci s obchodními partnery. BPEL stimuluje firmy ke kvalitní definici procesů, což vede k jejich optimalizaci a reengineeringu. Definice business procesů pomocí BPEL neovlivňuje stávající systémy, jen agreguje jejich funkcionalitu. BPEL je klíčová technologie v prostředích, kde je funkcionalita zajišťována pomocí webových služeb. S růstem využívání webových služeb tak poroste i význam standardu BPEL.

27 / 64

Pomocí BPEL lze specifikovat přesné pořadí využívaných webových služeb. Ty mohou být řazeny jak sekvenčně, tak paralelně. BPEL umožňuje rovněž vyjádřit základní řídící prvky jako je sekvence, cyklus či podmíněné větvení. Např. využití určité webové služby může záviset na hodnotě získané z předchozí webové služby apod. Komplexní BPEL proces lze tedy definovat stejně jako jakýkoliv algoritmus.

Průběh procesu pak v typickém případě vypadá tak, že na začátku nastane událost (proces přijme požadavek), která proces spustí. K tomu, aby proces získal požadované výstupy, využívá definovanou posloupnost webových služeb. Nakonec pak vrátí získaný výstup původnímu žadateli. Protože BPEL proces komunikuje s jinými webovými službami, závisí silně na WSDL popisu využívaných služeb.

BPEL umožňuje synchronní i asynchronní komunikaci se službami. Asynchronní služby jsou využívány obvykle pro dlouho trvající operace a synchronní pro operace, které vrátí výsledek v relativně krátkém čase. Pokud je v BPEL procesu využívána asynchronní webová služba, stává se proces jako celek rovněž asynchronním.

BPEL má samozřejmě i svá omezení. Mezi ně patří, že nelze do procesu zahrnout živé lidi. Toto omezení se snaží vyřešit firmy IBM a SAP. V srpnu 2005 přišly s rozšířením BPEL4People, které má umožnit zahrnout i činnosti vykonávané lidmi.

Jak již bylo zmíněno, BPEL je postaven na XML. Každý takový XML dokument obsahuje minimálně určení využívaných webových služeb, proměnné a sekvence činností. Kostra dokumentu vypadá následovně:

<process name="JménoProcesu" ... > <partnerLinks> <!—Deklarace využívaných služeb --> </partnerLinks> <variables> <!—Deklarace proměnných --> </variables> <sequence> <!—Definice samotného BPEL business procesu. --> </sequence> </process>

Základní činnosti, které lze použít pro konstrukci procesu jsou:

• <invoke> - využití jiné webové služby

• <receive> - čekání na zaslání zprávy od využívané služby (přijmutí požadavku)

• <reply> - generování odpovědi při synchronních operacích

• <assign> - manipulování s proměnnými

• <throw> - ošetření chyb a výjimek

• <wait> - čekání na uplynutí časového intervalu

• <terminate> - ukončení celého procesu

Pro zachycení struktury algoritmu pak lze využít:

• <sequence> - definuje posloupnost činností

• <flow> - definuje činnosti, které budou prováděny paralelně

• <switch> - case-switch konstrukt pro realizaci podmíněného větvení

28 / 64

• <while> - definuje cyklus

• <pick> - umožňuje definovat jednu nebo více alternativních cest

BPEL je jazyk, který je poměrně jednoduchý a přehledný. Díky tomu s ním mohou pracovat i lidé, kteří nemusí mít speciální technické znalostí. Samozřejmým trendem je využití moderních CASE nástrojů, které nabízejí přívětivé grafické uživatelské rozhraní, pomocí kterého lze jednoduše (systémem drag-and-drop) navrhovat BPEL procesy. Kód je pak automaticky generován nástrojem a BPEL server pak proces realizuje. To vede k tomu, že BPEL mohou efektivně používat analytici a návrháři procesů a ne pouze náruživí programátoři. Z výše uvedeného plyne, že BPEL umožňuje velice flexibilně reagovat na změny s minimálními náklady a bezpečně. Koncept SOA tak s využitím BPEL nabývá konkrétních rozměrů a stává se dobrým řešením pro dnešní dynamickou dobu. Vede ke konkurenční výhodě před firmami, které nebudou schopny tak rychle reagovat na potřeby změn.

Trendy Etapy vývoje softwaru nejsou zřetelně odděleny Už okamžikem, v němž si zákazník uvědomí, že potřebuje novou aplikaci, začíná práce vývojového týmu. Tato práce navíc velmi často nikdy neskončí, protože i po dodání kompletního produktu je nutné zajišťovat zákaznickou podporu a servis, opravovat případné chyby, přizpůsobovat aplikaci novým požadavkům na rostoucí množství dat, vyvíjet nové verze. Při tomto nikdy nekončícím cyklu musí vývojový tým provádět celou řadu činností, navíc je musí provádět s vědomím. že co zanedbá dnes, bude muset skoro jistě dříve či později napravit. Proto stojí za to realizovat všechny etapy vývojového cyklu s maximální pečlivostí, důsledností a snahou o správnost.

Pryč jsou doby vodopádového životního modelu softwaru. Při současném vývoji již neplatí, že jednotlivé fáze vývoje jsou od sebe zřetelně odděleny, jedna nastupuje až po úplném (a odsouhlaseném) ukončení předchozí. Požadavky trhu, konkurence, nutnost zkracovat termíny a dodávat co nejdříve – to vše nutí vývojáře zkrátit jednotlivé etapy vývoje, v extrémním případě je nejraději úplně spojit.

Tento trend se odráží kromě jiného v nástupech nových softwarově-inženýrských technik a postupů. Nejvýraznějším zástupcem je např. tzv. extrémní programování, které je založeno na maximálním zkrácení doby analýzy, na těsné interakci se zákazníkem a na paralelním běhu vývoje a analýzy. V žertu se říká, že dobrý extrémní programátor píše rovnou binární kód do souboru *.exe, úplní mistři v oboru pak dokonce komprimovaně do souborů *.zip.

Dalším důsledkem zmíněného trendu je integrace vývojových nástrojů. Vývojové nástroje, které nám usnadňují práci na jednotlivých etapách, mají mnoho společného a velmi často se překrývají. Důsledkem je skutečnost, že existuje velmi málo úzce specializovaných nástrojů, obvykle se jedná spíše o nejrůznější vývojová prostředí, jejich součástí je celá řada utilit, pomůcek a dílčích nástrojů podporujících (či umožňujících) jednotlivé činnosti.

29 / 64

Produkty Filenet P8 BPM Filenet P8 BPM je produkt, který je v nezávislých studiích vždy mezi nejsilnějšími. Původně dokumentačně orientovaný, dnes výrazně integrační. Celý balík dlouhodobě staví na platformě J2EE a představuje prakticky první workflow produkt. Od začátku určuje trendy v oblasti process management, což částečně vysvětluje skutečnost, že ne vždy plně respektuje standardy diktované autoritami. Filenet musí vznikající výzvy řešit dříve, než je definuje standard. Výsledkem je, že sice normy plně nedodržuje, ale na druhou stranu disponuje rozhraními, s jejichž pomocí se domluví se všemi významnými hráči na trhu.

Balík má rozsáhlé integrační možnosti a obsahuje i nástroj pro tvorbu ad-hoc procesů (viz snímek dole). Návrh procesů je realizován v okně webového prohlížeče s podporou javy. Balík však obsahuje i podporu COM/SOAP integračních možností a event-driven interakcí. P8 BPM samozřejmě nativně spolupracuje s ostatními produkty společnosti Panagon – Content Manager a Web Content Manager. Mezi další přednosti patří:

• Verze procesů a jejich jednoduchá administrace

• Sledování, analýza a simulace procesů

• Znovupoužitelné definice procesu

• Grafický design a modelování procesů

• 100% webově založený

• Drag and drop integrace webových služeb

Obrázek 14: Panagon Proces sDesigner

30 / 64

Tabulka 2 - Přehled produktu Filenet P8 BPM

Podpora BPEL Bez nativní podpory

Podpora dalších standardů J2EE, JSR 168, LDAP, SOAP, SSL, XML, WSDL

XML, WebDAV, WS, SMTP, http, BPEL

Podporované platformy

Aplikační servery:

• BEA Weblogic • IBM WebSphere • Sun Java System • Oracle • JBoss • Apache Tomcat

Databáze:

• IBM DB2 • Microsoft SQL Server • Oracle

Adresářové služby

• Microsoft Active Direktory • Novell • eDirectory • Sun Java Systém

Operační systémy

• Microsoft Windows • Sun Solária • IBM AIX • HP HP-UX • Red Hat Linux

Produkty FileNet

• Web content manager • Content Manager

HW a SW požadavky N/A

Cena enterprise configuration 125 000 USD až 420 000 USD

31 / 64

SAP NetWeaver SAP NetWeaver je aplikační a integrační platforma založená na otevřených standardech. Je technologickou základnou pro balík firemních aplikací mySAP Business Suite, pro kompozitní aplikace SAP xApps a pro jiná obecná nebo odvětvově orientovaná řešení společnosti SAP. SAP NetWeaver vytváří rovněž technologickou bázi nově navržené architektury společnosti SAP pojmenované Enterprise Services Architecture, která slouží jako předloha pro řešení založená na využití webových služeb.

SAP NetWeaver sjednocuje všechny integrační technologie do jediné platformy. Technologické komponenty nejsou dodávány samy o sobě, společnost SAP je dodává se širokým standardním obsahem, který významně zjednodušuje proces jejich uvedení do provozu. Platforma SAP NetWeaver je postavena na bázi otevřených standardů, plně spolupracuje s jinými běžně používanými technologickými platformami, jako jsou Java 2 Platform, Enterprise Edition (J2EE), Microsoft .NET a IBM WebSphere.

Obrázek 15 – Tři úrovně integrace v rámci platformy SAP NetWeaver: integrace pracovníků,

integrace informací, integrace procesů

Základní komponenty SAP NetWeaver SAP NetWeaver je univerzální technologickou platformou. Zahrnuje následující technologické komponenty:

• SAP Web Application Server – je vývojová a provozní platforma založená na otevřených standardech, která podporuje webové služby, vytváří provozní prostředí pro všechna řešení společnosti SAP a umožňuje vývoj s využitím klíčových technologií, jako jsou J2EE a ABAP. Na bázi SAP Web Application Server lze rychle vyvíjet a provozovat dynamické firemní aplikace podporující mezipodnikovou kooperaci.

• SAP Enterprise Portal – zahrnuje kompletní infrastrukturu podnikového portálu, nástroje pro řízení znalostí a aplikace pro podporu týmové spolupráce. Bezpečným způsobem zpřístupňuje zaměstnancům, partnerům, zákazníků a jiným komunitám v ekosystému společnosti klíčové informace a aplikace, pracuje s konceptem uživatelských rolí. Unifikace aplikací a informací v prostředí portálu umožňuje společnostem identifikovat a řešit problémy rychleji, efektivněji, s nižšími náklady a tím vytvářet měřitelné přínosy a strategické výhody. SAP Enterprise Portal zahrnuje

32 / 64

nástroje pro správu portálu, řízení znalostí a řízení spolupráce. Využívá aplikační server SAP Web Application Server.

• SAP Business Intelligence – usnadňuje identifikaci, integraci a analýzu obchodních dat pocházejících z různých zdrojů, transformuje data do informací, podporuje proaktivní jednání. Umožňuje provádět informovaná rozhodnutí a realizovat včas efektivní opatření vedoucí k úspěchu na trhu. Zahrnuje následující komponenty: SAP Business Information Warehouse, Business Explorer, standardní obsah pro SAP Business Intelligence, a SAP Enterprise Portal.

• SAP Exchange Infrastructure – obsahuje otevřené integrační technologie poskytující procesní integraci firemních aplikací jak od společnosti SAP, tak od jiných dodavatelů, integraci uvnitř i přes hranice společnosti. Obsahuje integrační broker a podporuje komplexní řízení obchodních procesů i v případech, kdy je proces podporován prostřednictvím více firemních aplikací. Využívá aplikační server SAP Web Application Server.

• SAP Mobile Infrastructure – umožňuje vývoj a provoz řešení pro pracovníky v terénu. Jedná se o univerzální, zabezpečenou platformu, která podporuje širokou škálu mobilních zařízení a umožňuje práci jak v režimu, kdy je zařízení připojené k centrálnímu systému, tak v režimu, kdy je zařízení odpojené. Podporuje vícekanálový přístup (RF technologie, mobilní GSM techonologie, hlasový vstup …), uživatel tak má k dispozici veškeré potřebné informace bez ohledu na místo, kde se nachází. Otevírá firemní aplikace mobilním uživatelům při využití existujících systémů a procesů a zároveň snižuje náklady na vlastnictví. Využívá aplikační server SAP Web Application Server.

• SAP Master Data Management – zajišťuje harmonizaci a konzistenci dat ve společnostech s heterogenním informačním systémem. Umožňuje ukládání, aktualizaci a konsolidaci kmenových dat, která jsou využívána nezávislými aplikacemi instalovanými v různých lokalitách. Rovněž zajišťuje konzistentní distribuci kmenových dat do všech aplikací a systémů IT infrastruktury. Společnosti mohou z existujících dat vytěžit maximum užitečných informací, významně zkvalitnit rozhodovací procesy, to vše při současné významné redukci nákladů na zajištění kvality dat. Díky využívání efektivních nástrojů pro zabezpečení konzistence dat v informačním systému dochází rovněž ke snížení nákladů na údržbu IT.

• SAP Composite Application Framework – je základem pro vývoj třídy moderních kompozitních podnikových aplikací. Využívá SAP NetWeaver pro zapouzdření funkcí již instalovaných aplikací a systémů do podoby komponent a služeb. Vytvořené komponenty a služby umožňuje popsat pomocí metadat a poskytuje nástroje pro jejich zakomponování a propojení do nově vytvářených kompozitních aplikací. Aplikační návrhář má rovněž k dispozici soubor nástrojů pro modelování objektů, služeb, procesů a uživatelského rozhraní, má možnost pracovat s předlohami. Kompozitní aplikace jsou vytvářeny konfigurací komponent a služeb, eliminována je potřeba programátorských prací.

• SAP NetWeaver Developer Studio – SAP NetWeaver Developer Studio je komponentou určenou pro podporu vývoje zákaznických aplikací. Nabízí vývojářům přístup k distribuovanému vývojovému a provoznímu prostředí, umožňuje vývoj podnikových aplikací v J2EE (Java 2 Platform, Standard Edition), Je charakteristické řadou vlastností, které usnadňují vývoj robustních podnikových aplikací - přístupem k repositáři, podporou centralizované definice datových typů, progresivní podporou v oblasti vývoje uživatelských rozhraní a podporou fázového vývoje (řízení verzí, transporty verzí a podobně). SAP NetWeaver Developer Studio zahrnuje editory a "čaroděje" umožňující rychle vytvářet typické komponenty aplikací vyvinutých v J2EE, jako jsou např. JSP stránky, servlety, session beans, entity beans a další.

33 / 64

SAP Exchange Infrastructure (SAP XI) V souvislosti s BPM je zřejmě nejdůležitější komponentou SAP Exchange Infrastructure (SAP XI). Jedná se o otevřenou integrační technologii, která poskytuje procesní integraci firemních aplikací (SAP i non-SAP) uvnitř podniku i za hranicemi společnosti. Obsahuje integrační broker a podporuje komplexní řízení obchodních procesů i v případech, kdy je proces podporovaný prostřednictvím více firemních aplikací. Využívá aplikační server SAP Web Application Server.

Komponenta SAP Exchange Infrastructure (SAP XI) vytváří základní prostředí pro integraci podnikových procesů. Umožňuje vzájemně propojovat systémy od různých dodavatelů (SAP i třetích stran), v různých verzích, vyvinutých v různých programovacích jazycích (Java, ABAP a dalších) a podobně. SAP Exchange Infrastructure je založena na otevřené architektuře, podporuje otevřené standardy (např. XML, Java apod.) a poskytuje klíčové služby, které jsou požadovány pro integraci procesů v prostředí složeném z nestejnorodých a komplexních systémů. Jedná se mj. o služby:

• návrh a modelování zpráv XML, transformace zpráv XML a integrace tzv. meziaplikačních procesů (tj. procesů, které jsou podporovány ze strany několika aplikací informačního systému),

• konfigurace pro řízení kolaborativních procesů (procesů spolupráce mezi obchodními partnery) a předávání zpráv,

• prostředí pro řízení zpracování zpráv a řízení meziaplikačních procesů,

• adaptérové platformy (Adapter Engine), umožňující zapojení adaptérů integrovaných aplikací.

Obrázek 16 – Nástroj Integration Builder

34 / 64

Obrázek 17 – Modelování procesu v prostředí komponenty SAP Exchange Infrastructure

Tabulka 3 - Přehled produktu SAP NetWeaver

Podpora BPEL nativní

Podpora dalších standardů J2EE, JSR 168, WSRP UDDI, SOAP, XML, XSLT, XML Encryption, digitální podpisy, LDAP, SAML

Podporované platformy Spolupráce:

• Lotus Domino, Lotus Sametime

Informace:

• Microsoft Content Management Server

• SQL Server Analysis Services

• Microsoft Office, Microsoft Exchange Server

Procesy:

• IBM WebSphere Business Integrator

•

Aplikační platformy:

• Visual Studio.NET

• SAP .NET Connector

• SAP Java Connector

HW a SW požadavky N/A

Cena N/A

35 / 64

BizTalk Server Cílem software firmy Microsoft s názvem BizTalk Server (v několika verzích – poslední verze BizTalk Server 2006) je snadná integrace interních podnikových aplikací, bezpečné spojení s obchodními partnery přes internet a automatizaci komplexních obchodních procesů realizovaných organizacemi. Můžeme říci, že cílem tvůrců je umožnit řešit co největší škálu problémů integrace a to jak uvnitř organizace, tak vně do sítě internet. Tohoto je dosaženo prostřednictvím podpory mnoha přenosových protokolů a formátů. Díky tomuto umožňuje BizTalk Server využít investice do stávajících aplikací a díky technologiím založeným na jazyku XML je začlenit do nových technologií elektronického obchodování.

Již od verze BizTalk Server 2000 je možné využívat vyspělé nástroje určené ke zvyšování produktivity, jež umožňující podnikovým administrátorům IT, vývojářům a analytikům pracovat ve společném prostředí. Novější verze BizTalk Serveru– BizTalk Server 2002, 2004 a 2006 – dále pokračuje rozšiřování podpory funkcí dostupných v předchozí verzi, ale navíc přináší další vylepšení stávajících služeb a funkcionality. Rozšíření funkcionality se dotýká i oblastí spjatých se správou a administrací BizTalk Serveru – především v oblasti monitorování a zavádění, kde jsou využívány služby poskytované produkty Microsoft Operations Manager a Microsoft Application Center.

BizTalk Server využívá čtyři základních SQL Server databáze jako datového úložiště pro data a informace týkající se realizovaných transakcí, správy systému a předávaných dokumentů. Sice text, který jste právě přečetli hodně vypovídá, ale i přesto zdůrazníme, že BizTalk server v sobě integruje funkcionalitu pro podporu mnoha oblastí spjatých s integrací aplikací a přenosu dat v rámci organizace, mimo organizaci a s podporou řízení kompletních distribuovaných obchodních procesů. BizTalk může pro nás vytvářet přínos v těchto oblastech:

1. Podpora Enterprise Application Integration (EAI) a Business-to-Business elektronického obchodování. BizTalk Server integruje technologie, které nám umožňují rychle a efektivně realizovat řešení v oblasti EAI (Enterprise Application Integration) a B2B (Business-to-Business) integrace aplikací. Napomoci nám v tom může řada integrovaných nástrojů a nativní podpora jazyka XML pro výměnu dat a podpora mnoha dalších formátů typu EDI (electronic data interchange), EDIFACT, „flat“ soubor apod. Transport dokumentů mezi jednotlivými aplikacemi nebo organizacemi je umožněn podporou transportních protokolů typu HTTP, HTTPS, SMTP komponent typu Message Queuing, Množství adaptérů, které jsou v systému BizTalk implementovány vytváří prostředí snadnou integraci produktů a technologií jak v rámci organizace, tak mezi organizacemi a obchodními partnery navzájem.

2. Podpora návrhu, vytváření a provádění dynamických distribuovaných obchodních procesů. Snahou všech podniků by mělo být rychle reagovat na požadavky zákazníků a na hrozby od konkurence. Snaží se proto maximalizovat rychlost implementace a úprav. Velkou výhodu BizTalk Serveru spatřujeme v poskytování vizuálního a vývojového prostředí pro návrh a vytváření dynamických distribuovaných procesů. Toto vizuální prostředí umožňuje analytikům navrhnout průběh procesu a vývojářům takto navržené procesy integrovat pomocí technologických přístupů s aplikacemi. Obchodní transakce, probíhající mezi jednotlivými aplikacemi a obchodními partnery, jsou plně automaticky řízeny takto navrženými procesy. Technologie pokročilé instrumentace obchodního procesu (Business Process Orchestration) v produktech BizTalk Server tak umožňují rychle definovat, navrhovat a nasazovat automatizované obchodní procesy přemosťující programy, technologie, platformy a obchodní partnery.

3. Bezpečnost, spolehlivost a dostupnost poskytovaných služeb. BizTalk Server využívá bezpečnostních prvků operačního systému Windows 2003 pro zajištění bezpečné komunikace a výměny dat mezi obchodními partnery v prostředí internetu. BizTalk Server podporuje PKI (Public Key Infrastructure) infrastrukturu, využití digitálních certifikátů, elektronického podpisu, šifrování, S/MIME a další

36 / 64

bezpečnostní produkty třetích stran. Ve spolupráci s dalšími produkty Microsoft Operation Manager a Microsoft Application Center je zajištěna dostatečná škálovatelnost BizTalk Serveru dle potřeb integračních projektů až do dimenze serverových farem. Součástí je také sada nástrojů a služeb zajišťuje odesílání, přijímání, ukládání dokumentů do fronty ke zpracování synchronním nebo asynchronním způsobem a vytváření a přenos potvrzenek o doručení předávaných dokumentů. BizTalk Server pak umožňuje efektivní a spolehlivé sledování a monitorování výměny dokumentů.

4. Založeno na standardech. BizTalk Server obsahuje a využívá mnoha celosvětově využívaných standardů. Jedná se především o standard XML (eXtensible Markup Language), XSLT (XSL Transformation), SOAP (Simple Object Access Protocol) a dalších průmyslových standardů.

Architektura BizTalk Serveru Architektura BizTalk nám nabízí velké množství nástrojů, služeb a široké technologické možnosti pro vytváření EAI a B2B integračních řešení. Jednotlivé komponenty architektury jsou uvedeny na následujícím schématu.

37 / 64

Jak je ve výše uvedeném schématu architektury BizTalk Serveru vidět, můžeme produkt sám o obě rozdělit do několika logických jednotek. Každá z takto definovaných oblastí je využívána pro jiné účely a může být jinak zaměřena. Síla produktu BizTalk Server je pak ve společném využití těchto jednotlivých komponent a dalších prvků, které tento produkt uživatelům nabízí.

Požadavky nutné k instalaci BizTalk Serveru Technické požadavky

Minimálními požadavky pro instalaci produktu je dostupnost stroje s procesorem Intel Pentium 300 nebo podobným, 128 MB RAM, minimálně 6 GB volného diskového prostoru, CD-ROM/DVD (v závislosti na typu instalačních médií) mechaniku a síťový adaptér. Toto je však minimální nutná konfigurace pro systém BizTalk Server ve verzi, jehož architektura je uvedena na výše vykresleném obrázku. Tuto konfiguraci můžeme použít k menším pokusným příkladům, ale není možné předpokládat, že by jej bylo možné použít pro nasazení v produkčním prostředí.

Softwarové požadavky

Pro úspěšnou realizaci instalace produktu BizTalk Server je nutné nejprve provést instalaci některých dalších softwarových komponent, které jsou nezbytné pro správné fungování BizTalk Serveru. Sem patří vhodný operační systém – Windows ve verzi Server, atd. Přesné požadavky pro jednotlivé verze BizTalk Serveru je možné dohledat v příslušných dokumentacích nebo na www stránkách firmy Microsoft. Pro verzi 2006 jsou požadavky následující:

1. Windows Server 2003 – Za upozornění stojí, že BizTalk Server 2006 využívá prvků IIS 6.0, MSMQ (Microsoft Message Queuing) a infrastruktury PKI, které jsou dostupné již s verzemi serverového operačního systému Windows 2000 a vyšší a jejich součást je naprosto samozřejmá u Windows Server 2003.

2. SQL Server 2000 - BizTalk Server využívá datových zdrojů jako úložiště dat potřebných jak pro správu systému, tak dat, které jsou mezi jednotlivými aplikacemi nebo organizacemi vyměňovány.

3. Visio 200X - Vývojové nástroje BizTalk Severu 2006 zaměřené na návrh a vytváření distribuovaných procesů jsou založeny na prostředí aplikace Microsoft Visio 200X. Tento nástroj využívá jak uživatelského prostředí této aplikace, tak enginu běžícího na pozadí.

Databáze BizTalk Server

Výše jsem psali, že systém BizTalk využívá čtyři základní databáze, které jsou nezbytné pro zajištění funkcionality BizTalk Serveru. Nyní je zkusíme popsat trochu detailněji.V rámci instalačního procesu volíme jednotlivé komponenty, které budou instalovány. Pokud se rozhodneme o instalaci BizTalk Messaging Services i BizTalk Orchestration Services (obojí bude popsáno v dalších částech dokumentu), jsou během instalačního procesu vytvořeny čtyři databáze:

• tři z těchto databází jsou vytvořeny pro potřeby Messaging Services: a. �BizTalk Messaging databáze (InterchangeBTM) b. �Tracking databáze (InterchangeDTA) c. �Shared Queue databáze (InterchangeSQ)

• jedna pro potřeby Orchestration Services: a. �Orchestration Persistence databáze (XLANG)

38 / 64

BizTalk Messaging databáze

Obsahem této databáze jsou informace o konfiguraci BizTalk Serveru a rovněš informace, které jsou vytvářeny pomocí nástroje BizTalk Messaging Manager. Příkladem mohou být metadata popisující konfigurace vytvořených Messaging Object jako jsou kanály, messaging porty a organizace. Dle dostupné dokumentace můžeme říci, že se jedná o nejdůležitější databázi, a proto je doporučeno velmi dobře zvážit jakékoliv přesouvání této databáze z jednoho databázového serveru na druhý.

Tracking databáze

Tato databáze je využívána pro ukládání informací napomáhajících sledování a monitorování dokumentů vyměňovaných mezi aplikacemi nebo obchodními partnery.V databázi jsou ukládány celé instance vyměňovaných dokumentů.

Shared Queue databáze

Smyslem této databáze je sloužit jako sdílená databáze pro ukládání informací o průběhu zpracování dokumentů, které jsou předmětem výměny mezi aplikacemi a obchodními partnery. Tato databáze je využívána pro všechny BizTalk Servery v rámci jedné BizTalk Server skupiny. V případě, že tedy dojde k výpadku jednoho z BizTalk Serverů, druhý BizTalk Server může dále pokračovat ve zpracování dokumentu.

Orchestration Persistence databáze (XLANG)

Tato databáze je základní databází pro BizTalk Orchestration Services a pro BizTalk Orchestration Designer. V databázi jsou ukládány informace o stavu procesů, tedy například procesech, které byly dehydratovány.

Nástroje BizTalk Serveru 2006 BizTalk Server přináší nástroje, které nám umožňují konfigurovat a spravovat messaging a orchestration services, zajišťovat administraci BizTalk Serveru, sledovat a monitorovat posílané dokumenty, vytvářet XML schéma a transformační mapy jednoho formátu dokumentu do druhého. Některé z nástrojů využívají integrace s dalšími aplikacemi a společně tak poskytují vizuální vývojové prostředí určené pro návrh, vytváření a realizaci komplexních dynamických procesů. Tyto nástroje jsou využívány jak administrátory IT, tak vývojáři a analytiky organizace.

BizTalk Editor

BizTalk Editor je jedním ze dvou základních XML nástrojů integrovaných v rámci BizTalk Serveru, které slouží k vytváření XML specifikací a transformačních map.

BizTalk Mapper

Druhým XML nástrojem integrovaným v rámci BizTalk Serveru je BizTalk Mapper. Jedná se o nástroj sloužící k vytváření transformačních map založených na standardu XSLT (XSL Transformation). Tyto transformační mapy slouží k transformaci dat (dokumentů) z jednoho formátu do jiného formátu nebo k transformaci z jedné struktury dokumentu do jiné struktury dokumentu.

BizTalk Orchestration Designer

BizTalk Orchestration Designer je nástroj pro návrh a implementaci dynamických procesů, které mohou řídit proces výměny dokumentů mezi aplikacemi a obchodními partnery.

Jedná se o jeden z nejsilnějších nástrojů, které jsou součástí BizTalk Serveru a který v sobě spojuje prostředí pro návrh procesů spolu s prostředím pro technologickou implementaci těchto procesů. Tento nástroj umožňuje vytvářet XLANG Schedule, ve kterých definované procesy probíhají. Velkou výhodou BizTalk Serveru a především pak jeho části Orchestration Services je podpora dlouhotrvající procesů.

Vlastní prostředí BizTalk Orchestration Designeru je založeno na produktu Microsoft Visio.

39 / 64

BizTalk Messaging Manager

Tento nástroj slouží pro správu a konfiguraci objektů jedné z klíčových komponent BizTalk Serveru – BizTalk Messaging Services. Nástroj sám o sobě je webová aplikace vytvořená pomocí

technologie ASP a provozovaná v rámci webového serveru IIS 6.0. Jeho pomocí můžeme přes grafické uživatelské rozhraní přistupovat a konfigurovat jednotlivé objekty Messaging Services, kterými jsou například:

• Messaging Port (port) • Channel (kanál) • Organization (organizace) • Distribution List (distribuční seznam) • Document Definition (specifikace dokumentů) • Envelopes (obálky)

BizTalk Server Administration

BizTak Server Administration je nástroj, založený na standardní MMC (Microsoft Management Console) konzoli. Nástroj umožňuje spravovat jak samotný BizTalk Sever, tak skupiny BizTalk Serverů, BizTalk Server fronty a Receive Function. Součástí nástroje je i integrovaný „Prohlížeč událostí“ Event Viewer, pro snadnější řešení neočekávaných stavů a problémů s produktem BizTalk Server.

BizTalk Document Tracking

Jedná se o nástroj založený na webovém rozhraní, který je úzce spjat s BizTalk Tracking databází, nazývanou také Data Tracking Activity (DTA) databáze. Již víme, že tato databáze patří mezi databáze BizTalk Serveru, které jsou velmi často využívány a u nichž lze předpokládat rapidní nárůst velikosti spravovaných dat. Tato databáze je dále sdílena v rámci skupiny BizTalk Serverů. Ukládání dat do tracking databáze není samozřejmostí.

Ukládání jak obecných, tak specifických údajů o zpracovávaných a vyměňovaných dokumentech musíme definovat v průběhu vytváření BizTalk Server Groups nebo v průběhu vytváření BizTalk Messaging objektů.

Tento nástroj nám poskytuje grafické uživatelské rozhraní pro vytváření dotazů nad DTA databází a zobrazování výsledků těchto dotazů.

SEED Wizard

Jedná se o nástroj, jehož cílem je usnadnit realizaci integrace nás s našimi obchodními partnery. Nástroj nám a našim obchodním partnerům, kteří využívají BizTalk Server, umožňuje celkem jednoduše vytvořit, otestovat a zrealizovat nezbytná nastavení a infrastrukturu pro vzájemnou integraci. Pomocí tohoto průvodce, vytvoříme speciální balíček – SEED Package, jenž obsahuje jméno organizace, která balíček vytváří, testovací a produkční URL odkaz pro předání dokumentu ke zpracování BizTalk Serverem naší organizace a ukázkovou specifikaci a XML instanci některého obchodního dokumentu.

40 / 64

Služby BizTalk Serveru

Pokud bychom měli shrnout, co je cílem BizTalk Messaging Services, mohli bychom k tomuto využít následující schéma znázorňující jejich architekturu. Na obrázku můžeme vidět, že Messaging Services se skládají z následujících komponent:

• Receive function • Custom Preprocesors – zajišťuje zpracování dokumentů ještě před tím, než jsou

předány ke zpracování BizTalk Serveru. Aplikují se v rámci konfigurace Receive Function.

• Transportní protokoly • Konfigurovatelné objekty Messaging Services • Parsers and Serializers – překlad dokumentů na vstupu z nativní formy do XML �a

dokumentů na výstupu do nativní formy z XML • Podpora spolehlivého doručení dokumentů – Reliable Messaging • Podpora bezpečné výměny dokumentů

Smyslem Messaging Services je převzít dokument, předávaný zdrojovou aplikací nebo organizací k dalšímu zpracování, zajistit jeho správné zpracování a předat zpracovaný dokument cílové aplikaci nebo obchodnímu partnerovi.

Během tohoto procesu je prováděna sadu úkolů, které využívají komponent o kterých jsme psali výše a které zahrnují překlad dokumentů z jejich nativního formátu do formátu XML (který je nutný pro zpracování BizTalk Serverem), ověření správnosti a všech náležitostí přijímaného dokumentu proti definované specifikaci (schéma) dokumentu, transformaci dokumentu z jednoho formátu (struktury) do jiné, překlad dokumentů na výstupu z formátu XML do formátu požadovaného cílovou aplikací a zajistit transport tohoto dokumentu cílové aplikaci nebo organizaci.

41 / 64

Receive Function

Jedná se o grafické rozhraní umožňující provést postoupení dokumentu ke zpracování BizTalk Serveru. Dokumenty mohou být ke zpracování BizTalk Serverem postoupeny v zásadě dvěma způsoby:

1. Prvním způsobem je programátorský způsob využití metod Submit a SubmitSyn, které náleží do Interchange rozhraní. Tento způsob je využíván především u aplikací podporujících COM rozhraní. V závislosti na zvolené metodě dochází k postoupení dokumentu buď synchronním nebo asynchronním způsobem.

2. Druhý způsob představují Receive Functions, tedy předpřipravené grafické uživatelské rozhraní, které je dostupné v rámci nástroje BizTalk Administration. Využití Receive Function je výhodné například v případě, kdy integrovaná aplikace nepodporuje COM rozhraní. BizTalk Server zahrnuje tři typy Receive Functions:

• �File • �Message Queuing

42 / 64

• �HTTP V případě, že využijeme Receive Functions, jsou dokumenty ke zpracování předávány vždy asynchronním způsobem. Pokud tedy námi vytvářené řešení vyžaduje synchronní způsob komunikace, musíme využít metody SubmitSync. Vzhledem k tomu, co jsme nyní napsali je jasné, že Receive Functions nelze pro tyto účely využít.

Transport Services

BizTalk Server podporuje velké množství transportních protokolů a služeb pro přenos dokumentů mezi aplikacemi nebo přes internet mezi organizacemi. Mezi nejčastěji využívané transportní služby patří:

• HTTP • HTTPS • SMTP • Message Queuing • File • AIC (Application Integration Component)

BizTalk Orchestration Services Podíváme-li se na oblast Enterprise Application Integration a B2B integrace pozorněji, zjistíme, že vlastní integrace probíhá ve dvou základních rovinách. První rovinou je infrastruktura na komunikační úrovní, která zajišťuje efektivní výměnu obchodních dokumentů mezi jednotlivými obchodními jednotkami a aplikacemi. Tato infrastruktura musí odrážet nejenom vlastní výměnu dokumentů, ale také oblasti ověření správnosti dokumentů, transformaci mezi jednotlivými formáty, transformaci schémat dokumentů a spolehlivou a hlavně bezpečnou možnost doručení dokumentů. Tuto integrační rovinu,dle dostupné literatury, pokrývají BizTalk Server Messaging Services. Silná a dobře zajištěná komunikační infrastruktura sama o sobě však není při realizaci integračních řešení dostatečná. Každý obchodní dokument, který je předáván mezi jednotlivými aplikacemi nebo obchodními partnery, je součástí nějakého komplexního obchodního procesu. V oblasti návrhu a řízení komplexních procesů v procesu EAI nebo B2B integrace můžeme spatřovat právě onu druhou zmiňovanou rovinu integračních řešení. Na jedné straně tedy vidíme potřebu, ba dokonce nutnost, jednotlivé obchodní procesy řídit, na straně druhé je však pravdou, že není jednoduché obchodní procesy popsat a implementovat jednoznačným způsobem.

Automatizované obchodní procesy jsou často implementovány za pomocí vytváření proprietárních řešení, jež jsou často založeny na komponentovém přístupu a dalším využití programování pro spojení celého řešení do jednoho fungujícího bloku, který reprezentuje vlastní proces. Tento přístup však přináší některé nevýhody:

• Řešení založená na proprietárních aplikacích a kódu jsou často neflexibilní, především pak při nutnosti aplikaci nebo kód změnit.

• Obchodní procesy, a především ty obchodní procesy, které se týkají obchodních partnerů za hranicemi organizace, mohou být realizovány několik dní, týdnů, měsíců. Realizace takové aplikace podporující dlouhotrvající procesy je časově náročná a vyžaduje velké množství programování.

• Proprietární kód využívaný pro automatizaci procesů je tradičně velmi problematický a časově náročný.

BizTalk Orchestration Services poskytují nástroje a služby pro vytváření a implementaci procesů. Návrh procesů a jejich implementace

Při návrhu, vytváření a implementaci obchodních procesů BizTalk Server Orchestration Services poskytují vizuální návrhové prostředí, které slouží jak pro návrh procesů, tak pro technologickou implementaci těchto procesů.

43 / 64

Sledování a řízení stavu procesů

V rámci systému můžeme předpokládat, že dochází k realizace několika desítek, stovek nebo tisíců transakcí – instancí obchodních procesů. Často pak potřebujeme zjistit, v jakém stavu se právě proces nachází, případně potřebujeme řešit nenadálý problém.

Pomocí nástrojů BizTalk Serveru dokážeme sledovat stav jednotlivých instancí procesů, včetně jejich stavů a monitorovat tak aktuální stav. Pro účely sledování a řízení stavu procesů se využívá nástrojů XLANG Event Monitor a BizTalk Document Tracking.

Podpora dlouhotrvajících obchodních transakcí

Jednotlivé obchodní transakce, které jsou realizovány mezi obchodními partnery nebo aplikacemi, nejsou standardně realizovány v jednom okamžiku a mohou trvat až několik

dní či týdnů. BizTalk Server Orchestration Services umožňují efektivně tyto „dlouhotrvající“ transakce vytvářet a řídit. Vlastnosti transakcí je možné popsat pomocí známé zkratky ACID

• Atomicity - Transakce je jakási jednotka práce. Transakce jsou vždy realizovány jako celek. Nelze realizovat pouze část.

• Consistency - Data, jež jsou předmětem transakce, byla konzistentní před její realizací a musí být konzistentní i po realizaci této transakce.

• Isolation - Realizace jedné transakce je oddělena od realizace druhé transakce. Jedna transakce nesmí modifikovat nebo měnit data, která jsou modifikována jinou transakcí.

• Durability - Trvanlivost a odolnost transakcí. Z těchto vlastností transakce můžeme odvodit, probíhají obecně v jednom okamžiku a vlastní realizaci transakce lze vyjádřit „buď všechno nebo nic“.

Pokud si však vzpomeneme, co bylo napsáno před několika řádky, tak na obchodních transakcích realizovaných v prostředí BizTalk Serveru, vidíme, že jejich realizace a dokončení je často závislé na odezvě obchodního partnera nebo aplikace na druhé straně. Takovýchto transakcí pak můžeme mít tisíce a pokud by všechny využívaly systémových prostředků v jeden okamžik, bylo by to výkonově pro náš systém velmi náročné.

Orchestration Services provádějí sledování všech realizovaných transakcí a v případě, že transakce setrvává v nečinnosti více než definovaný časový interval (např. 200 vteřin), dojde k operaci zvané rehydratation – tj. transakce je zmrazena ve stávajícím stavu a je uložena do databáze (Orchestration Persistent Database). V okamžiku, kdy transakce pokračuje např. obchodní partner odpověděl, je provedena dehydratation – tj. transakce je rozmrazena (obnovena z databáze) a pokračuje ve využívání systémových prostředků pro realizaci dalšího kroku.

Optimalizace výkonu, vysoká dostupnost, škálovatelnost

Stejně jako u jiných informačních systémů je možné i u BizTalk Serveru provádět škálování tj. zvyšování výkonu systému dvěma základními způsoby. Prvním je škálování nahoru tzv. scale up. Tento způsob spočívá v posilování HW konfigurace jednoho serveru tak, že zvyšujeme objem operační paměti, přidáváme procesory případně měníme jednotlivé HW komponenty za výkonnější. Druhým způsobem je škálování přes více serverů tzv. scale out. Tento způsob spočívá v rozkládání zátěže na více serverů, přičemž služby a transakce, které byly realizovány jedním serverem jsou nyní realizovány několika servery. Tento druhý způsob je nejčastěji využíván pro optimalizaci výkonu BizTalk Serveru.

Doplnění základních pojmů a koncepce

V dokumentaci k BizTalk Serveru se často objevuje pojem „Integrační broker“ (jako celek uveden na následujícím obrázku). Pro něj platí, že má škálovatelnou architekturu pro

44 / 64

zpracování procházejících zpráv. Toto uspořádání zajišťuje tři základní funkce – přijetí zprávy, uložení zprávy do trvalého úložiště a doručení zprávy.

Message box

Message box je relační databází SQL serveru, která je používána jako trvalé úložiště všech zpráv procházejících systémem. V případě požadavku na extrémně vysokou škálovatelnost je možné mít více oddělených databází message box (což je výhodné pro zkrácení doby odezvy atp.). Použití relační databáze pro uložení stavu zpráv a procesů je velmi výhodné, neboť může plně využít samozřejmé vlastnosti databázového stroje – vysokou stabilitu a výkon, možnost transakčních operací nad daty, robustní zálohování a obnovu, technologie pro vysokou dostupnost (clustering), auditing a řadu dalších funkcí.

Adaptér

Integrační broker komunikuje s integrovanými aplikacemi či službami prostřednictvím tzv. adaptérů. Adaptér je prvek spojující integrační broker s integrovanými aplikacemi.

Adaptéry lze rozdělit do tří skupin:

• Aplikační adaptéry (vertikální) – spojují integrační broker s vybranou konkrétní aplikací (např. SAP, Siebel, PeopleSoft, Nision, Great Plains). Pokud aplikace implementuje nestandardní rozhraní (např. SAP rozhraní BAPI), potom adaptér obsahuje technické prostředky pro komunikaci s aplikací.

• Technologické adaptéry (horizontální) – spojují integrační broker s okolím prostřednictvím technologie nezávislé na konkrétní aplikaci (např. webové služby, souborový systém, SMTP, TCP/IP, LU 6.2, MQSeries, FTP). Tyto adaptéry jsou

45 / 64

zpravidla jednodušší a tudíž vyžadují větší konfigurační úsilí na straně brokeru i integrované aplikace.

• Datové adaptéry – jsou na pomezí mezi aplikačními a technologickými adaptéry. Umožňují integračnímu brokeru komunikovat přímo s databází (např. MS SQL, Oracle, DB2). Tyto adaptéry umožňují pohodlný způsob přístupu k datům v operačních databázích, vhodné jsou například pro udržování informací o stavu integrovaných procesů, workflow mimo aplikace apod.

Pipeline

Pro přijetí a odeslání se využívá koncepce tzv. proudového zpracování zprávy pomocí tzv. pipeline. Pipeline slouží ke zpracování přijaté zprávy před jejím uložením do message boxu anebo před odesláním po vyjmutí správy z message boxu (pracuje tedy na obou stranách message boxu, je-li to třeba). Je složena z posloupnosti jednotlivých etap ve zpracování zprávy (stage) jako je např. dekódování, dešifrování či kontrola digitálního podpisu. V každé etapě je možné zařadit žádnou, jednu nebo více komponent prodanou etapu. Zpráva pak prochází postupně těmito komponentami, přičemž každá komponenta může zprávu modifikovat (např. dešifrovací komponenta), vyvolat chybu (např. komponenta kontrolující správnost příchozí zprávy) nebo zapisovat do kontextu zprávy vlastnosti pro účely jejich pozdějšího vyhledávání nebo dalšího směrování.

Receive port

Port pro přijetí zprávy (receive port) slouží pro převzetí zprávy integračním brokerem. Jde o řekněme logickou adresu, přes kterou jsou zprávy doručovány. Tato logická (virtuální) adresa slouží vyšším vrstvám integračního brokeru ke kategorizaci zpráv a k řízení jejich dalšího zpracování. Porty pro přijetí mohou být dvojího druhu – bez odpovědi na přijatou zprávu (one-way) nebo s odpovědí (request-response), přičemž adaptér nemusí nutně podporovat oba způsoby.

Receive location

Řekli jsme, že port pro doručení je pouhou logickou adresou pro doručení. Skutečná zpráva musí být doručena nějakým konkrétním fyzickým způsobem prostřednictvím určitého konkrétního adaptéru na tzv. receive location. Dle dostupné literatury jsou třemi nejdůležitějšími vlastnostmi každého receive location použitý adaptér, adresa závislá na zvoleném adaptéru (např. pro FILE adaptér je adresou cesta ke složce, která je monitorována) a pipeline použitá pro zpracování přijaté zprávy.

Send port

Send port neboli port pro odeslání slouží pro doručení zprávy cílové službě nebo příjemci. Port plní i zde funkci logické adresy a jeho hlavními vlastnostmi jsou pipeline pro zpracování odesílané zprávy, primární transport a někdy též sekundární (náhradní) transport. Transport je pak definován především použitým adaptérem, adresou pro doručení a parametry pro opakování případného neúspěšného přenosu. Obdobně jako porty pro přijetí, i porty pro odeslání mohou být dvojího druhu – s čekáním na odpověď (solicit-response) anebo bez odpovědi (one-way), daný adaptér opět nemusí podporovat oba způsoby.

V literatuře je uváděn i další způsob dělení portů a to na porty statické a dynamické. Zatímco statické porty doručí zprávu vždy na předdefinovanou adresu, dynamické porty nemají pevně stanovenou cílovou adresu. Adresa je totiž přiřazena až při zpracování zprávy.

Dostupné adaptéry a technologie

Adaptéry lze dále rozdělit podle jejich původu a dostupnosti. Aplikační adaptéry buď dodává výrobce aplikace (např. Siebel) nebo firma specializovaná na výrobu adaptérů (pure play adapter vendor, např. iWay) a v případě SAPu nabízí komerční adaptér též Microsoft. Technologické a datové adaptéry jsou zpravidla dodávány specializovanými firmami,

46 / 64

Microsoft nabízí ke stažení adaptér pro IBM MQSeries a osm technologických adaptérů najdete přímo „v krabici“ BizTalku

V BizTalk jsou například následující adaptéry:

• SOAP adaptér • MSMQT adaptér. • FILE • HTTP. • SMTP. • FTP • SQL adaptér • EDI

Enterprise Single Sign-On

Jedním z problémů, které vzniká při integraci v různorodém prostředí je často existence mnoha různých přihlašovacích systémů a bezpečnostních domén. Není výjimkou, že uživatel má až desítky jmen a hesel do různých interních systémů, přičemž tato situace je velkou zátěží pro administrátory, uživatele i rozpočet IT oddělení. Naproti tomu v ideálním stavu by uživatel měl mít pouze jedno jediné primární jméno a heslo, které by bylo klíčem ke všem interním systémům, ale změna interních systémů za účelem používání jiných autentizačních schémat je bohužel většinou utopií.

V této situaci je částečným řešením technologie Enterprise Single Sign-on (ESSO). Jde o důmyslné kryptografické řešení, jehož základem je databáze sekundárních přihlašovacích informací zašifrovaných symetrickou šifrou (tzv. master secret), takže v případě zcizení databáze jsou přihlašovací informace v ní uložené relativně bezcenné. V této databázi jsou definovány tzv. přidružené aplikace (affiliate application) a pro tyto aplikace je pak jednotlivému účtu nebo skupině uživatelů z domény uloženo šifrované jméno a heslo.

Graficky je tato problematika vykreslena na následujícím obrázku.

47 / 64

Postup použití ESSO v BizTalku. Na počátku je zpráva doručena adaptéru autentizovaným způsobem. Podporuje-li adaptér ESSO, požádá SSO server o vydání takzvaného tiketu pro SSO. Tento tiket je přiložen ke zprávě jako jedna z jeho vlastností, takže je uložen do message boxu a provází zprávu po celou dobu jejího zpracování. Pokud je při odesílání použit adaptér podporující se zapnutou podporou a nastavenou hodnotou přidružené aplikace, předloží SSO serveru tiket přidaný ke zprávě a na jeho základě získá příslušné namapované přihlašovací informace pro cílovou aplikaci. Tyto informace pak odesílající adaptér použije pro komunikaci s cílovou aplikací.

Tento mechanismus samozřejmě předpokládá určitou důvěru v kvalitu a prověřenost používaných adaptérů, která by ovšem v provozním prostředí měla být samozřejmostí.

IBM WebSphere Rodina produktů IBM WebSphere představuje základní infrastrukturní software pro e-business. Umožňuje realizovat libovolný typ internetového řešení, jako jsou intranetové a internetové aplikace, portálová a e-commerce řešení, multikanálová řešení pro zařízení typu mobilních telefonů a PDA, B2B řešení a mnoho dalšího. Jedná se o ideální platformou pro podniky, které chtějí provozovat úspěšný e-business.

Mezi hlavní výhody IBM WebSphere patří otevřenost – je založena na Javě (J2EE), XML a WebServices, modularita – možnost skládat komplexní řešení z jednotlivých IBM produktů, škálovatelnost a cenová dostupnost – produkty WebSphere jsou dostupné v různých edicích a pro všechny zákaznické segmenty. Jedním z nejdůležitějších rysů rodiny IBM WebSphere je, že se jedná o multiplatformní řešení, které je možno provozovat na platformách Linux, Windows, UNIX, iSeries a zSeries.

48 / 64

S ohledem na zaměření práce jsem se rozhodl zaměřit se především na následující nástroje z široké produktové rodiny IBM WebSphere:

• WebSphere Application Server – přední aplikační platforma založená na technologiích J2EE (Java 2 Enterprise Edition) a webových služeb (Web Services). Představuje kvalitní řešení pro provozování dynamických podnikových řešení pro e-business "on demand". Plně podporuje Software Development Kit for Java Technology Edition (SDK 1.4) – klient i server, což umožňuje podnikům vytvářet sofistikovanější e-business aplikace založené na technologii Java v kratším čase a s nižšími náklady. WebSphere Application Server poskytuje podporu třetí generace pro standardy webových služeb, a podniky tak mohou dosáhnout vyššího stupně integrace s klíčovými obchodními partnery, dodavateli a zákazníky. Komponenta Advanced Performance Advisors pomáhá nastavit klíčové parametry WebSphere Application Serveru, a umožňuje tak dosahovat maximálního výkonu.

• WebSphere Extended Deployment – přináší doplňky k WebSphere Application Server Network Deployment, který poskytuje vysoce dynamické a výkonné prostředí pro Websphere aplikace. Tyto doplňky Vám pomohou s optimalizací a využíváním vašich aplikací, a tak zvýšit jakost Vámi nabízených služeb.

• WebSphere MQ Workflow – softwarový nástroj pro správu obchodních procesů (BPM – Business Process Management) podniku umožňující podnikům plně kontrolovat stávající podnikové procesy a zajišťovat jejich integritu. Umožňuje vysokou míru automatizace obchodních procesů, čímž podniky získávají schopnost flexibilněji a agilněji reagovat na změnu tržních podmínek. Websphere MQ Workflow umožňuje podnikům zahrnout aplikační systémy a uživatele do řízeného prostředí obchodních procesů implementovaného jako součást hodnotového řešení integrace celopodnikových aplikací (EAI – Enterprise Application Integration), B2B řešení a řešení pro správu obchodních procesů.

• WebSphere Business Integration Modeler – nástroj pro návrh a testování složitých podnikových procesů. Poskytuje vrcholovému managementu přehled o důležitých událostech a aktivitách a umožňuje mu flexibilně reagovat na změny tržních podmínek. Klíčové podnikové procesy jsou uchovávány na jediném místě, čímž je zajištěna jejich aktuálnost a konzistence. Díky jednoduchému grafickému rozhraní umožňuje nástroj WebSphere Business Integration Modeler snadno navrhovat nové a upravovat již existující podnikové procesy. Možnosti simulace různých podnikových scénářů pomáhají odhalit chyby a možné problémy dříve, než dojde k implementaci procesu.

• WebSphere Business Integration Server – na otevřených standardech založená integrační platforma příští generace umožňující podnikům snadno integrovat existující IT zdroje, čímž pomáhá maximalizovat návratnost podnikových investic do IT. Umožňuje snadno vytvářet znovupoužitelné Java aplikace nebo aplikace typu webových služeb (Web Services). WebSphere Business Integration Server Foundation pomáhá zvýšit efektivitu vývoje aplikací při současné minimalizaci nákladů na vývoj, implementaci a administraci IT systému.

Produkty IBM podporující SOA Pro modelování architektur SOA nabízí IBM snadno použitelný nástroj WebSphere Business Modeler, který umožňuje modelovat a navrhovat procesní tok před samotným nasazením a doplňuje modelovací funkce nástroje Rational Software Architect.

Pro vytváření a implementaci podnikových procesů postavených na architektuře SOA oznamuje IBM vývojový nástroj WebSphere Integration Developer, který je postaven na nástroji Eclipse. WebSphere Integration Developer umožňuje vývojářům složených aplikací zobrazovat existující informační technologie jako služby, které lze snadno propojovat do

49 / 64

ucelených podnikových procesů. IBM také uvolnilo novou verzi nástroje Rational Application Developer, který pomůže při sestavování architektur orientovaných na služby.

Na pomoc se zaváděním architektur SOA oznamuje IBM produkt WebSphere Enterprise Service Bus (ESB). WebSphere ESB dále posiluje současné možnosti IBM ESB v oblasti propojení a integrace webových aplikací a služeb. Pro vyspělou funkčnost ESB uvádí IBM novou verzi nástroje WebSphere Message Broker, který zajišťuje univerzální konektivitu a transformaci dat pro aplikace bez ohledu na to, jestli vyhovují standardům.

Další novinkou pro implementace SOA je WebSphere Process Server, software založený na otevřených standardech a na technologii WebSphere ESB, který pomáhá zjednodušit integraci podnikových procesů mezi lidmi, systémy, zákazníky a obchodními partnery. WebSphere Process Server zkracuje dobu, snižuje náklady a odstraňuje rizika spojená s integračními projekty, neboť zjednodušuje pohyb informací mezi aplikacemi na základě podnikových pravidel.

Pro správu architektur SOA také IBM oznamuje vylepšení produktu WebSphere Business Monitor. Nový software pomáhá monitorovat výkonnost podnikových procesů a sledovat klíčové výkonnostní ukazatele. Tivoli později v tomto měsíci oznámí nový řídící software pro složené aplikace, který bude zákazníkům pomáhat spravovat a zajišťovat výkon a dostupnost řešení založených na architektuře SOA.

WebSphere Business Modeler Produktové nástroje WebSphere Business Modeler pomáhají organizacím plně vizualizovat, pochopit a zdokumentovat jejich business procesy. Značných přínosů může být dosaženo pomocí kolaborativní funkcionality, kdy tým expertů na danou problematiku napomáhá jasnějšímu definování business modelů a odstranění neefektivností. Lze modelovat business procesy, pro neustálou optimalizaci je následně rozvíjet, monitorovat a volit akce podle KPI, poplachů a triggerů. Business procesy se tak stávají blíže spojené se strategickými cíly společnosti.

Jedná se o nástroj pro vizuální návrh, testování a simulaci složitých podnikových procesů. Poskytuje vrcholovému managementu přehled o důležitých událostech a aktivitách a umožňuje mu flexibilně reagovat na změny tržních podmínek. Klíčové podnikové procesy jsou uchovávány na jediném místě, čímž je zajištěna jejich aktuálnost a konzistence. Díky jednoduchému grafickému rozhraní umožňuje nástroj WebSphere Business Integration Modeler snadno navrhovat nové a upravovat již existující podnikové procesy. Možnosti simulace různých podnikových scénářů pomáhají odhalit chyby a možné problémy dříve, než dojdek implementaci procesu.

WebSphere Business Integration Modeler pomáhá:

• rychle upravovat existující nebo navrhovat nové procesy v závislosti na změně potřeb podniku

• jasně a přehledně definovat obchodní procesy a zjednodušit jejich sdílení

• optimalizovat obchodní procesy a zvyšovat efektivitu předávání informací uvnitř podniku

• integrovat procesy, informace a aplikace

Nástroj je poskytován ve čtyřech variantách:

• Basic – méně finančně náročná edice poskytující základní modelovací funkce pro zachycení dat podnikových oddělení a jednotlivců, pokud nevyžadují veškeré schopnosti edice WebSphere Business Modeler Advanced.

• Advanced – překlenuje mezeru mezi business linií a IT, poskytuje robustní funkčnost procesního modelování, podnikového modelování, modelování

50 / 64

esenciálních dat a artefaktů, organizačního modelování, modelování zdrojů, časové přímky a modelování lokací či analýzy business procesů.

• Publishing Server – poskytuje schopnost publikovat modely business procesů Portlet-based serverům, kde několik expertů na danou problematiku může současně sledovat a posuzovat informace pomocí běžného internetového prohlížeče.

• Monitor – monitoruje business procesy v reálném čase, poskytuje visuální obraz jejich stavu a společně s poplachy a upozorněními klíčovým uživatelům umožňuje neustálé zlepšování business procesů.

Sybase PowerDesigner PowerDesigner je CASE nástroj, který komplexně pokrývající všechny aspekty rozvoje podniku. Obsahuje nástroje pro obchodně orientovanou procesní analýzu, která umožní identifikovat klíčová místa a funkce podniku jako takového a nabízí také plně integrované prostředí pro datovou a objektovou analýzu informačních systémů. Přitom plně podporuje zavedené přístupy a metodologie jako je Unified Modeling Language (UML) nebo dvouúrovňový návrh databáze.

PowerDesigner je nástrojem pro návrh informačních systémů protože umožňuje v rámci jediného prostředí identifikovat důležité obchodní aktivity podniku a zachytit jejich odraz v aplikacích a databázích pomocí datových a objektových modelů. Obchodní analytik tak může navrhnout efektivnější fungování podniku v modelu podnikových procesů a předat takto specifikované zadání do IT oddělení k vytvoření informačních systémů podporujících tyto nové procesy v podniku. Při návrhu požadovaných aplikací může datový analytik tak vytvářet entity v datovém modelu a sledovat jejich závislost na objektech a třídách v navrhované aplikaci získaných z objektového modelu systému. Hladká spolupráce při návrhu datové a aplikační stránky systému v rámci jediného CASE nástroje s jednotným uživatelským prostředím se pak odrazí v rychlém a bezproblémovém vývoji.

Základní charakteristiky PowerDesigner

Modelování podnikových procesů Model podnikových procesů poskytuje efektivní nástroj pro analýzu fungování podniku, který není zatížen odkazem informačních technologií. Model podnikových procesů je v PowerDesigneru zaměřen na obchodní analytiky a manažery. Tedy na pracovníky, kteří se velmi dobře orientují v problematice daného podniku, ale slovník programátorů je jim cizí. PowerDesigner nabízí manažerům a obchodním analytikům snadno uchopitelné prostředí, ve kterém mohou jednoduše modelovat lepší fungování podniku případně i zdokumentovat stávající stav. Model podnikových procesů lze pak použít pro tvorbu vnitropodnikových předpisů a norem nebo přímo jako zadání pro vývojáře aplikací. Navíc lze tento procesní model použít pro konfiguraci produktů pro vnitropodnikovou integraci aplikací (EAI) a pro systémy pro automatickou komunikaci s obchodními partnery (B2B).

Datové modelování PowerDesigner těží za své bohaté tradice nejefektivnějšího nástroje pro návrh databází. Tvorba databázových schémat je založena na plnohodnotné koncepci dvouúrovňového návrhu schématu databáze. PowerDesigner umožňuje pomocí konceptuálního datového modelu (CDM) návrh abstraktních datových struktur (Entit) a vztahů mezi nimi v ER diagramech - to vše pomocí osvědčených metod. Konceptuální datový model tak představuje platformově nezávislé datové schéma projektovaného systému které je oproštěno od všech implementačních úprav. Datový analytik se tak může soustředit přímo na vlastní obchodní data systému a nikoliv na způsob jejich uložení v konkrétním databázovém serveru. Fyzický datový model (PDM) tvoří v PowerDesigneru druhou složkou datového modelování. Fyzický datový model je na rozdíl od konceptuálního modelu již určen pro konkrétní

51 / 64

databázový server, kterých PowerDesigner podporuje více jak 35. Právě v tomto modelu má datový analytik možnost navrhovat indexy, provádět denormalizaci či specifikovat další speciální nastavení pro cílovou databázovou platformu. PowerDesigner tak umožňuje optimalizovat výsledné databázové schéma konkrétní databázi a přitom zajisti aby výsledná aplikace podporovala více databázových platforem. PowerDesigner umožňuje snadný přechod mezi obecným, platformově nezávislým, konceptuálním modelem a fyzickým datovým modelem optimalizovaným pro konkrétní databázi. Při generování fyzického modelu provede PowerDesigner překlady datových typů, M:N relací, klíčů a dalších součástí modelu do jejich ekvivalentů v cílové databázové platformě. PowerDesigner také podporuje zpětnou konsolidaci fyzického do konceptuálního datového modelu a umožňuje jednoduše porovnávat jednotlivé modely mezi sebou a tak udržovat a vyvíjet aplikace podporující více databázových serverů. Posledním doplňkem datového modelování v PowerDesigneru je podpora datových skladů. Všechny edice PowerDesigneru umožňují v rámci fyzického datového modelu vytvářet i multidimenzionální datové modely a pracovat s hvězdicovými a vločkovými schématy. PowerDesigner také umožňuje provádět mapování mezi zdrojovými a cílovými databázovými objekty a tak vytvářet dokumentaci pro nasazení a konfiguraci nástrojů pro extrakci, transformaci a plnění datových skladů.

Objektové modelování Podpora objektového modelování v PowerDesigneru je založena na osvědčené metodologii Unified Modeling Languge (UML). Diagramy uživatelských scénářů (Use Case) dostupné v rámci objektového modelu systému umožňují specifikovat požadované chování aplikace na nejvyšší úrovni abstrakce. Pomocí sekvenčních diagramů a diagramů aktivit pak aplikační analytik může identifikovat obchodní objekty v aplikaci a funkce, které mají vykonávat. Výsledkem těchto diagramů je sada tříd včetně identifikace jejich atributů a metod. Jádrem objektového modelu v PowerDesigneru je samotný diagram tříd. V tomto diagramu lze definovat závislosti a další vztahy mezi jednotlivými třídami obdobně jako v případě konceptuálního nebo fyzického datového modelu. PowerDesigner samozřejmě umožňuje synchronizaci tohoto klíčového diagramu objektového modelu systému s datovými modely a tak udržovat konzistenci mezi datovou a aplikační stránkou vyvíjeného systému. Diagram tříd je tedy obdobou fyzického datového modelu pro aplikační stránku systému a stejně jako fyzický datový model umožňuje diagram tříd generování zdrojového kódu a zpětnou analýzu aplikací (hierarchií objektů, analýzu jejich funkcí a atributů) pro celou řadu objektových platforem jako jsou prostředí PowerBuilder, Java, C++, C#, XML, WSDL, CORBA nebo VisualBasic.

Java 2 Enterprise Edition PowerDesigner přináší novou dimenzi do vývoje distribuovaných Java aplikací podle normy Java 2 Enterprise Edition. Díky těsné vazbě mezi datovým a objektovým modelem umožňuje PowerDesigner specifikovat i objektově relační mapování - vazbu mezi tabulkami ve fyzickém datovém modelu a třídami v diagramu tříd v objektovém modelu. Toto objektově relační mapování lze následně využít pro automatickou konfiguraci kontejnerem řízené perzistence (Container Managed Persistence, CMP) Entity Enterprise Java Bean komponent v J2EE 1.3 kompatibilních aplikačních serverech. Vedle kontejnerové perzistence umožňuje PowerDesigner také modelovat Enterprise Java Bean komponenty jako takové. PowerDesigner dokáže korektně vytvořit všechny součásti EJB komponenty - od home, remote a local rozhraní, přes bean třídu až k deployment deskriptorům - a obsahuje mechanismy pro udržení konzistence výchozího modelu tříd a dalších objektových diagramů s diagramem komponent.

Porovnávání modelů Jádro návrhu informačního systému v PowerDesigneru spočívá v konceptuálním a fyzickém datovém modelu a diagramu tříd z objektového modelu aplikace. PowerDesigner zajišťuje

52 / 64

konzistenci všech součástí vyvíjené aplikace (modelů) pomocí pokročilé možnosti porovnávání a slučování jednotlivých modelů. Možnost porovnat datový a objektový model mezi sebou dává analytikům do ruky silný nástroj, pomocí kterého mohou identifikovat provedené změny v jedné součásti vyvíjeného systému, například v datovém modelu, a implementovat je odpovídajícím způsobem do modelu objektového. Tím PowerDesigner zajistí aby navrhovaná aplikace odpovídala své databázi.

Generování a zpětná analýza aplikací a databází V rámci fyzického datového modelu a diagramu tříd v objektovém modelu umožňuje PowerDesigner generování základů navrhované aplikace. Z fyzického datového modelu lze získat Data Definition Language (DDL) skripty pro vytvoření všech tabulek, pohledů, indexů, uživatelských datových typů, triggerů a dalších součástí schéma databáze navrhovaného systému. A to vždy přesně podle možností cílového databázového serveru kterých PowerDesigner podporuje více jak 35 nejrůznějších verzí všech rozšířených dodavatelů. Obdobně i objektový model, respektive jeho diagram tříd - PowerDesigner podporuje generování zdrojového kódu pro mnoho objektově orientovaných vývojových prostředí včetně jazyka Java, PowerBuilder, C++, C#, VisualBasic nebo komponentového modelu CORBA (IDL soubory). PowerDesigner také umožňuje vytvářet i schéma a definice XML dokumentů k danému objektovému modelu a tak umožnit hladké zapojení navrhované aplikace do eCommerce systémů.

Vedle samotného generování databázových skriptů a zdrojového kódu aplikace dokáže PowerDesigner provádět i zpětnou analýzu (reverse engeneering) databází a aplikací.PowerDesigner se může připojit pomocí ODBC rozhraní na existující databázi nebo přečíst její DDL skripty a vytvořit odpovídající fyzický datový model - včetně tabulek, indexů, referenční integrity a dalších součástí databázového schéma. Tuto vlastnost PowerDesigneru spolu s možností generování dokumentace a porovnáváním modelů obzvláště ocení databázoví administrátoři protože v PowerDesigneru naleznou nedocenitelný nástroj pro sledování a dokumentaci změn ve spravované databázi.

Kvalitní dokumentace - základ úspěchu Jedním z kritických faktorů úspěchu vývoje aplikace je schopnost udržet informace o navrhovaném systému nejen v podobě prostého výpisu zdrojového kódu, ale i v podobě poznámek a anotací k jednotlivým objektům, entitám či vazbám. PowerDesigner poskytuje široké dokumentační možnosti pro zachycení informací o projektu na libovolné úrovni podrobnosti - od databázových nastavení až po informace o jednotlivých atributech třídy v objektovém modelu. Pokročilý dokumentační generátor PowerDesigneru umožňuje sestavovat z předpřipravených součástí jako je seznam tabulek nebo detailní popis relace dokumentové šablony pro různé varianty generovaných reportů. Vývojový tým tak může udržovat obecné šablony k různým účelům - programátorskou dokumentaci pro vývojový tým, databázovou dokumentaci pro administrátora databázového serveru, dokumentaci aplikačních rozhraní jako přílohu manuálů a další typy reportů. Generování dokumentace pomocí takto vytvořených šablon udrží jednotný vzhled a obsah v dokumentaci všech projektů vývojového týmu a následně se odrazí i v jeho vyšší efektivitě.

Repository - podpora týmové práce Pří vývoji rozsáhlejšího informačního systému obvykle pracuje na jeho návrhu celý tým analytiků. Pro koordinaci a zvýšení efektivity jejich práce slouží v PowerDesigneru modul MetaWorks který slouží jako společné úložiště (repository) modelů projektu pro všechny členy vývojového týmu. MetaWorks umožňuje vedoucímu projektu přiřazovat jednotlivým členům vývojového týmu přístupová práva k jednotlivým modelům - součástem projektu - uloženým v PowerDesigner repository v SQL databázi. Pro potřeby repository je k produktu PowerDesigner přiložena omezená licence databáze Adaptive Server Anywhere a lze použít libovolnou databázi s ODBC rozhraním.

53 / 64

Vedle řízení přístupu k jednotlivým součástem projektu plní PowerDesigner repository ještě důležitou funkci verzování modelů. Repository automaticky sleduje vývoj každého jednotlivého modelu v čase a uchovává jeho předchozí varianty. V okamžiku kdy dojde například k objevení nové chyby v současné verzi aplikace, lze porovnat její model s modelem dřívější, bezchybné aplikace a tak identifikovat příčiny zjištěné chyby. Verzování modelů, které v PowerDesigneru umožňuje i větvení vývoje, má v sobě zakomponován také mechanismus zamykání jednotlivých částí modelu se kterými pracují ostatní členové vývojového týmu a tak zabraňuje situaci, kdy s jedním modelem navrhované aplikace pracují dva analytici, kteří si navzájem přepisují svoji práci.

Business Process Architect PowerDesigner Business Process Architect umožňuje obchodním (ne-IT) analytikům zachytit procesy v organizaci a předat je IT oddělení k jejich IT analýze a převedení do vyvíjených systémů. Vedle zajištění shody obchodního zadání s vyvíjenou aplikací lze Business Process Architect použít také k popisu obecných procesů v podniku, jejich optimalizaci a pro podporu business process reengineeringu.

Umožňuje tvorbu nových datových objektů a informačních toků mezi podnikovými procesy. Lze propojit procesní model s konceptuálním datovým modelem a objektově orientovaným modelem. Pomocí průvodce mohou být data importována a exportována mezi jednotlivými modely. Umožňuje vytvářet CRUD matrice, popisující vztahy mezi procesy a zdroji. CRUD zabezpečují všechny operace, které procesy provádějí se zdroji. To umožňuje sledovat, jak procesy se zdroji pracují, a pomáhá udržet kontrolu reálnosti modelu. Organizační jednotky jsou znázorňovány v diagramech jako swimlines. To umožňuje graficky reprezentovat vztahy mezi objekty BPM a organizačními jednotkami.

Tabulka 4 - Přehled produktu Sybase PowerDesigner

Podpora BPEL ne

Podpora dalších standardů UML, J2EE, .NET, XML, Web Services,

Podporované platformy Operační systém: • Windows

Databáze: • Sybase • Microsoft • Informix • Oracle • IBM

HW a SW požadavky Windows® 95/98, NT 4.0 or 2000 Pentium® CPU 32MB RAM SVGA monitor mechanika CD-ROM 60MB volného místa na disku

Cena PowerDesigner 11.0 Physical Architekt – 33 763 Kč bez DPH

54 / 64

ORACLE BPEL Process Manager Oracle se snaží prosadit na poli BPM pomocí nástroje BPEL Process Manager. Akvizicí společnosti Collaxa, která byla průkopníkem v oblasti SOA a BPM tak Oracle získal potřebné know-how. Oracle BPEL Process Manager (dále BPEL-PM) je nástroj, pomocí kterého lze navrhovat, provozovat, monitorovat a analyzovat procesy na bázi standardu pro oblast podnikových procesů – BPEL. BPEL-PM je nativní implementací BPEL standardu, který nabízí grafický editor pro práci s BPEL procesy a škálovatelné, vysoce dostupné provozní prostředí. Toto prostředí umožňuje mimo jiné ucelený monitoring jednotlivých procesů, jejich vyhodnocování a případný debuging. Nativní podpora BPEL je velmi přínosná, protože vzhledem k tomu že BPEL je všeobecně uznávaný standard, tak pomocí BPEL-PM lze navrhovat přenosné a na jiných platformách použitelné procesy.

BPEL-PM běží na řadě aplikačních serverů firmy Oracle, ale není na ně vázán; nabízí podporu libovolného J2EE aplikačního serveru včetně JBoss a WebSphere. Podporuje rovněž pokročilé BPEL funkce jako je asynchronní předávání zpráv a kompenzaci transakcí (ošetření chyb a výjimek). BPEL-PM také umožňuje tzv. dehydrataci procesu, v případě dlouhotrvající transakce, uložením do persistentního úložiště a následnou rehydrataci procesu po dokončení takové transakce. Díky JCA (Java Connector Architecture) adaptérům rovněž umožňuje rozšiřování svého záběru i nad rámec samotného sladění webových služeb.

BPEL Process Manager nabízí mnoho možností. Základní části tohoto řešení jsou BPEL designer, BPEL Console, zabudované integrační služby, služby workflow a BPEL server. BPEL designer nabízí intuitivní grafické uživatelské rozhraní pro návrh procesů. Jak již byl zmíněno BPEL-PM má nativní podporu standardu BPEL, takže vytvořené procesy jsou stoprocentně přenosné. BPEL Console poskytuje web rozhraní pro řízení, administraci a monitorování procesů nasazených na BPEL serveru. Umožňuje sledovat i historii proběhlých procesů. BPEL-PM dodává i mnoho integračních služeb. Zajímavá je i možnost zahrnutí lidského workflow, managementu úkolů atd. BPEL server pak představuje prostředí pro vykonávání navržených BPEL procesů. Následující přehled shrnuje základní charakteristiky řešení:

Obrázek 18: BPEL Process Manager

55 / 64

BPEL Designer • nativní podpora BPEL • jednoduché modelování procesů

pomocí drag-and-drop • UDDI a WSIL browser • automatické mapování • integrované adaptéry a workflow

průvodci • jednoduché vytvoření a nasazení

procesu

BPEL Console • visuální monitorování procesu • audit • BPEL debbuger • administrace procesu za běhu • vylaďování výkonnosti

Zabudované integrační služby • email a messaging • JCA 1.5 konektivita • adaptéry • databázový adapter • XSLT a XQUERY • …

Workflow služby • zadávání úkolů a směrování • vícenásobné workflow scénáře • seznam úkolů a upozornění

BPEL Server • synchronní a asynchronní

zprávy • dehydratace • řízení chyb a výjimek • správa verzí • silná podpora XML

dokumentů • vysoký výkon

56 / 64

Tabulka 5 - Přehled produktu ORACLE BPEL Process Manager

Podpora BPEL nativní

Podpora dalších standardů XML, XQuery, XPath, WS, SOAP, WSDL, JCA, JMS, SMTP, HTTP

Podporované platformy

Aplikační servery: • Oracle AS • JBoss • BEAWebLogic • IBM WebSphere

Databáze: • Oracle DB • Oracle Lite • MS SQL

HW a SW požadavky Internet Explorer 6.0 nebo vyšší JDK 1.4.1 nebo novější Windows 2000 nebo XP, 384 MB RAM 600 MB místa na disku

Cena 40 000 USD

Microsoft Visio 2003 Visio 2003 je aplikace pro tvorbu diagramů, s níž můžete vytvářet obchodní a technické diagramy, ve kterých jsou dokumentovány a uspořádány složité plány, procesy a systémy. Diagramy vytvořené v aplikaci Visio 2003 umožňují jasně, stručně a efektivně vizuálně vytvářet, spravovat a předávat informace tak, jak by to pouze s využitím textu a čísel nebylo možné. Pomocí přímé synchronizace diagramů se zdroji dat automatizuje aplikace Visio 2003 vizualizaci dat. Poskytuje tak aktuální diagramy a navíc lze mechanismy aktualizace přizpůsobit potřebám každé organizace.

Tato aplikace je k dispozici ve verzích Standard a Professional a obsahuje nové typy diagramů, galerií a šablon spolu s běžnými typy diagramů, jež podporují základní systémy kontroly kvality, standardy Six Sigma, ISO 9000 a TQM. Snádná dokumentace a analýza obchodních procesů, umožní zákazníkům lépe porozumět provozu organizace a následně zvýšit její efektivitu.

Aplikace Visio 2003 je součástí řešení Microsoft Office System. Díky tomu bude možné nové funkce dynamicky propojovat při využítí formátu XML. Tím se z dokumentů aplikace Visio stávají inteligentní klienti, které bude možné integrovat s aplikacemi určenými pro konkrétní činnost podnikání a využít je ke sledování obchodních dat v reálném čase.

"Nové funkce a vylepšení vytvářejí z aplikace Microsoft Office Visio 2003 komplexní a pro podnikové zákazníky nepostradatelný nástroj při vytváření diagramů," řekl Tomáš Koška, ředitel skupiny Information Worker ve společnosti Microsoft Česká Republika. "S aplikací Visio 2003 získávají zákazníci nástroj, který jim umožňuje názorně projít, pochopit a zlepšit obchodní procesy, v konečném důsledku zvýšit produktivitu i efektivitu a lépe reagovat na konkurenční nabídky nebo na nové obchodní příležitosti."

57 / 64

Získání další obchodní hodnoty pro společnost

Organizace mohou přicházet o své zisky a ztrácet obchodní příležitosti z důvodu neefektivních obchodních procesů nebo obtížnému porozumění provozu organizace v rámci hlavní činnosti. Správa obchodních procesů umožňuje společnostem snížit náklady a zvýšit efektivitu, protože zajišťuje přehlednou dokumentaci aktuálních procesů, jež jsou později vyhodnoceny a v případě potřeby vylepšeny.

První krok správy obchodních procesů představuje grafická identifikace obchodních procesů a analýza dat, podle nichž mohou manažeři a zaměstnanci určit, ve kterých oblastech je možné zvýšit efektivitu. V aplikaci Visio 2003 jsou pro tento rozhodující krok k dispozici nové diagramy obchodních procesů, šablony a nástroje, jako například konceptuální grafy, stromové struktury pro rozhodování, vývojové diagramy, schémata procesů a procedur, časová schémata a schémata činností. Pomocí všech uvedených funkcí mohou zákazníci vytvořit osnovu obchodních procesů a dokumentovat a zároveň obvyklým způsobem graficky znázornit obchodní činnosti za účelem analýzy a popisu komplexních systémů.

"Automatizace a tok dat obchodních procesů vyžaduje v konečné fázi zapojení mnoha složek organizace, chcete-li zajistit slibovaný výsledek," uvedla Sandra Rogers, ředitelka výzkumu webových služeb a softwaru pro integraci společnosti IDC. "Aplikace Visio představuje produkt vyvinutý pro vytváření vztahů mezi informacemi a modelování workflow v převážně grafickém kontextu. V této podobě by měla oslovovat členy týmu definujícího obchodní procesy, kteří jsou více orientováni na obchodní činnosti."

Snadné pochopení koncepcí, procesů a vztahů

S aplikací Visio můžete snadno vytvářet obchodní a technické diagramy, které vám pomohou při vytváření, organizování nebo lepším pochopení složitých plánů, procesů a systémů. Diagramy můžete snadno sestavovat přetahováním předem definovaných symbolů Microsoft SmartShapes. Pro účely vytváření obchodních a technických diagramů můžete používat nástroje, které byly přímo navrženy pro jednotlivé profesionální disciplíny. Z existujících dat lze generovat běžné typy diagramů. K dispozici je také kontextová nápověda a šablony pro konkrétní úkoly, které jsou pravidelně aktualizovány z webu.

Integrace s Windows Server Systém

Při vývoji aplikace Visio 2003 se společnost Microsoft zaměřila na dvě různé oblasti: vytvoření aplikace schopné integrace s podnikovými systémy a návrat k základnímu účelu aplikace jako nástroje určeného zejména pro vytváření diagramů. Výsledkem je sada výkonnějších a flexibilnějších nástrojů aplikace Visio, která přináší nové možnosti využití diagramů aplikace.

Kromě toho, že aplikace využívá formát XML a webové služby založené na formátu XML, lze ji navíc zcela integrovat s ostatními aplikacemi sady Microsoft Office a s aplikacemi systému Windows Server System™, včetně systému Windows Server™ 2003 s produkty Windows® SharePoint™1, Microsoft BizTalk® Server a Microsoft SQL Server™.

Specifické podnikové potřeby můžete řešit začleněním aplikace Visio do výkonného softwaru připojeného k platformě Microsoft .NET. Ovládací prvky aplikace Visio pro kreslení je možné vkládat do obchodních aplikací, které jsou založeny na softwaru připojeném k platformě .NET nebo na operačním systému Microsoft Windows.

1 SharePoint přibližuje následující kapitola

58 / 64

Nová řešení zefektivňují vytváření diagramů databází a softwaru a rozšiřují podporu vývojářských nástrojů společnosti Microsoft. Je možné provádět zpětnou analýzu existujících aplikací a navrhovat nové aplikace.

Lze ji přitom integrovat do původního systému jako rozšiřitelnou platformu pro vývoj s novými funkcemi určenými k vytváření řešení inteligentního klienta, pomocí nichž je možné z uvedených systémů získávat informace v reálném čase.

Společnost Microsoft nabízí za účelem podpory uvedených funkcí několik prostředků, které jsou určeny podnikovým vývojářům a obchodním partnerům. Jedná se například o ovládací prvky ActiveX®, sadu pro vývojáře softwaru a nový nástroj pro vývojáře Shape Studio, který usnadňuje vývojářské procesy při vytváření obrazců s vysokou úrovní kvality. Tímto způsobem mohou být inteligentní klienti upraveni tak, aby vyhovovali téměř všem potřebám podnikání.

K předávání plánů, informací a systémů můžete využít grafické znázornění - Integrovaná podpora počítačů Tablet PC umožňuje procházet, upravovat a komentovat diagramy, i když nejste u pracovního stolu. Pomocí digitálního pera můžete vkládat do diagramů komentáře, formátovat, měnit velikost nebo otáčet prvky diagramů a připojovat k nim položky zadané digitálním perem. Záznamy zadané pomocí digitálního pera můžete převést na základní geometrii nebo text. Diagramy z aplikace Visio můžete publikovat do pracovního prostoru na portálovém serveru Microsoft SharePoint™, můžete je také exportovat pomocí formátu SVG (Scalable Vector Graphics) nebo aktualizované funkce Uložit jako webovou stránku.

Rozdíl verzí

V současné době existují tři základní verze programu Visio 2003 – Standard, Professional a Enterprise Architect.

Aplikace Visio Standard umožňuje uživatelům vytvářet diagramy související s podnikovými procesy, například vývojové diagramy, organizační diagramy a plány projektů. Aplikace Visio Professional spojuje tvary a řešení aplikace Visio Standard s tvary a řešeními umožňujícími technickým odborníkům vytvářet technické diagramy pro oblast IT, webové diagramy a diagramy pro vývoj a inženýrství. Aplikace Visio for Enterprise Architect obsahuje znaky obou dvou předešlých verzí, ale navíc připojuje dokonalejší modelovací nástroje s vazbou na databáze. Tato verze je dostupná pouze jako část programu Visual Studio 2005.

Vytváření diagramů softwarových aplikací

Pomocí celé řady typů diagramů založených na jazyce UML (Unified Modeling Language) a jiných obecných metodologií můžete vytvářet diagramy softwarových projektů. Zpětnou analýzou projektů vývojového prostředí Microsoft Visual Studio® můžete dokonce vytvářet diagramy tříd jazyka UML.

59 / 64

Vytváření diagramů schémat databází

Pro navrhované schéma databáze můžete vytvářet diagramy vztahů jednotlivých entit. Chcete-li vytvářet diagramy schémat existujících systémů, můžete provést zpětnou analýzu běžných databází typu klient-server, včetně databází SQL Server, IBM, Oracle a dalších.

60 / 64

Vytváření business diagramů Visio podporuje využití vizualizace procesů k vyjádření workflow, plánování a spravování vztahů napříč oddělením v organizaci. Plánování, design, implementace a komunikace výsledků business procesů spolu s dokumentací zahrnují SAP, ISO a Six Sigma.

Takto lze vytvářet událostmi řízené procesní diagramy (EPC – event-driven process), rozbory pomocí stromu poruch (fault tree analysis), základní i náročnější diagramy toků (DFD), sufitní diagramy a workflow diagramy.

Obrázek: Business Process, EPC diagram

Vytváření podrobných map webových serverů

Pomocí průvodce pro vytváření map webových serverů můžete vytvářet mapy existujících serverů sítí Internet a intranet a odstraňovat problémy s těmito servery. Můžete pracovat s tvary zastupujícími stránky ve formátu HTML, aplety v jazyce Java, multimédia, obrázky a další prvky na serverech.

61 / 64

Tabulka: Přehled produktu Visio 2003

Podpora BPEL ano

Podpora dalších standardů

UML, XML, .NET, Web Services, ODX

Podporované platformy Exchange Server MS SQL, IBM, Oracle Visual Studio .NET BizTalk Server Windows Server

HW a SW požadavky Microsoft Windows® 2000, kde je nainstalovaný Service Pack 3 (SP3), Windows XP, nebo novější verze

Pentium 233 MHz CPU

128MB RAM

SVGA monitor

Mechanika CD-ROM nebo DVD

160 MB volného místa na disku

Ostatní Některé funkcionality potřebují mít nainstalován Microsoft Windows SharePoint Service

Cena Visio 2003 Standard od 5 900 Kč

Visio 2003 Professional cca 14 000 Kč

Visio for Enterprise Architect je součástí VS Studia 2005

SharePoint Portal Server 2003 SharePoint Portal Server 2003 umožňuje organizacím vyvinout inteligentní portál, který bezproblémově propojuje uživatele, týmy a znalosti, takže uživatelé mohou využívat důležité informace v rámci podnikových procesů, které jim umožní pracovat efektivněji. SharePoint Portal Server 2003 poskytuje podnikové řešení pro organizace, které integruje informace z různých systémů do jednoho řešení prostřednictvím jednotného přihlášení a integrace s podnikovými aplikacemi s flexibilními možnostmi zavedení a nástroji pro správu. Portál usnadňuje spolupráci koncových uživatelů pomocí funkcí slučování, uspořádání a vyhledávání osob, týmů a informací. Uživatelé mohou rychle vyhledat důležité informace pomocí vlastního nastavení a individuálního přizpůsobení obsahu a rozložení portálu a také díky zaměření na cílovou skupinu uživatelů. Organizace mohou zaměřit informace, programy a aktualizace na skupiny uživatelů na základě jejich role v organizaci, členství v týmu, zájmů, skupiny zabezpečení nebo libovolných jiných kritérií členství, která lze definovat.

SharePoint Portal Server 2003 používá weby služby Microsoft Windows® SharePoint Services 2003 k vytváření stránek portálu pro osoby, informace a organizace. Portál také rozšiřuje funkce webů služby SharePoint Services o nástroje pro uspořádání a správu a umožňuje týmům publikovat informace na jejich webech pro celou organizaci.

SharePoint Portal Server 2003 byl navržen se zamýšlenými cíli - zajištění funkčnosti informací, propojení osob a prostředí za účelem spolupráce a dosažení vyšší produktivity díky zaměření a přizpůsobení informací.

62 / 64

Zajištění funkčnosti informací

SharePoint Portal Server 2003 poskytuje jeden přístupový bod k mnoha systémům, například k programům systému Microsoft Office System, programům pro řízení podniku a správu projektů a k existujícím obchodním aplikacím, včetně programů jiných výrobců a programů specifických pro jednotlivá odvětví. Portál, vytvořený na škálovatelné, vysoce distribuované architektuře, poskytuje flexibilní nástroje pro zavedení, vývoj a správu, které umožňují rozšiřování portálu podle potřeb organizace. Tyto funkce integrace umožňují pomocí informací využívat zdroje ve vaší společnosti. Uživatelé mohou extrahovat a opakovaně používat aktuální a důležité informace ze systémů a sestav a rychle vyhledávat dokumenty, projekty a doporučené postupy v rámci celé společnosti a získávat k nim přístup. Portál zahrnuje technologii vyhledávání vyvinutou pracovišti Microsoft Research, která umožňuje vyhledávání sdílených souborů, webových serverů, veřejných složek serveru Microsoft Exchange Server, programu Lotus Notes a předdefinovaných webů služby Windows SharePoint Services. Navíc můžete uspořádat dokumenty a informace podle tématu a přecházet na související obsah. Výstrahy upozorňující na přidání nových informací nebo změny existujících informací umožňují lepší využívání dat.

Propojení osob a prostředí za účelem spolupráce

SharePoint Portal Server 2003 poskytuje výkonné prostředí pro týmovou spolupráci, které organizacím umožňuje slučovat, uspořádat, vyhledávat a spravovat weby služby SharePoint v rámci organizace. Weby služby SharePoint vytvořené pro týmy, dokumenty a schůzky lze také rozšířit na zákazníky a partnery a zvýšit tak rozsah a efektivitu stávajících metod spolupráce. Portál dále usnadňuje spolupráci koncových uživatelů tím, že umožňuje spolupráci jednotlivců, týmů, podnikových jednotek a organizací na dokumentech a obsahu. Správa verzí dokumentů, proces schvalování, funkce rezervace a vrácení se změnami a profilování a publikování dokumentů umožňují snadnou spolupráci na dokumentech, projektech a úkolech. Portál navíc umožňuje uživatelům pracujícím s informacemi snadno vyhledávat a využívat osoby, týmy a existující doporučené postupy, aniž by bylo nutné v jednotlivých projektech znovu získávat potřebné informace a vytvářet postupy.

Dosažení vyšší produktivity díky zaměření a přizpůsobení informací

SharePoint Portal Server 2003 umožňuje oddělením IT a uživatelům přizpůsobit a individuálně nastavit způsob práce s portálem. Důležitý obsah, například obchodní programy a aplikace sady Office, webové služby, příspěvky, údaje o prodeji a další údaje o společnosti, je na portál dodáván prostřednictvím webových částí. Webové části mohou oddělení IT stáhnout ze serveru společnosti Microsoft nebo oborových partnerů. Lze je také vyvinout pomocí programu Microsoft Visual Studio® .NET. Oprávnění uživatelé mohou webové části přidávat k portálům organizace nebo oddělení z galerií webových součástí, aniž by potřebovali zkušenosti s vývojem webových prvků. Oddělení IT mohou navíc uzamknout konkrétní webové části nebo oblasti stránek, aby mohly organizace distribuovat důležité informace prostřednictvím portálu všem zaměstnancům. Uživatelé mají k dispozici také osobní stránky portálu nazvané My Site (Osobní web), na nichž mohou uspořádat informace, programy a weby služby SharePoint, ke kterým získávají přístup v průběhu dne.

SW a HW požadavky (server)

PC Intel pentium III – 700 MHz

512 MB RAM

575 MB volného místa na disku

Nainstalován jeden z následujících serverů: Microsoft Windows Server 2003 (Standard, Enterprise, Datacenter nebo Web Edition) a aktuální Service Pack.

63 / 64

Použité zdroje [1] Oracle: http://www.oracle.com [2] Hood, S.: BPEL standardizuje správu procesů. 2005

http://archiv.cw.cz/cwarchiv.nsf/clanky/CCF018504A4384A4C125707B005C6D1C?OpenDocument [3] Borck, J. R.: BPEL se rychle dostává do popředí BPI. 2004

http://archiv.cw.cz/cwarchiv.nsf/clanky/422BAA51DBA2241DC1256F8C003D262F?OpenDocument [4] Michelson, B.: BPEL Primer. 2005

http://elementallinks.typepad.com/bmichelson/2005/09/view_bpel_proce.html [5] Finkelstein, C.: The Enterprise:Business Process Management Languages, Part 1:

BPEL. 2005 http://www.dmreview.com/article_sub.cfm?articleId=1018124

[6] Computerworld: Explainer: BPEL http://www.computerworld.com.au/index.php/id;743565394;relcomp;1

[7] Peterson, D.: Power To The BPEL: A Technology For Web Services. 2003 http://www.bcr.com/bcrmag/2003/06/p54.php

[8] Bradley, R.: BPEL - Integration's White Knight or White Elephant? 2005 http://81.29.72.192/index.php/ws/content/view/full/51693

[9] IT SYSTEMS: Integrace firemních procesů (BPEL, SOA, EDA) http://www.itsys.cz/solutionsAction.do?type=show&comeId=7

[10] Holubec, J.: BPEL, jazyk který rozumí procesům. 2005, IT SYSTEMS [11] Trask | Application Integration

http://www.trask.cz [12] SystemOnLine

http://www.systemonline.cz/index.php?sec=casopis&id_clanek=1772 [13] Databázový svět

http://www.dbsvet.cz/view.php?cisloclanku=2002061705 [14] SAP

http://www.sap.com [15] IBM

http://www.ibm.com [16] Sybase

http://www.sybase.cz [17] Hewlett-Packard

http://www.hp.cz/services/snews/05_jaro/clanky.php?p=7 [18] Computerworld

http://www.computerworld.cz/cw.nsf/software/6F1939902036A952C125707D00626D8D [19] Microsoft: http://www.microsoft.com/cze/presspass/MSG/20030604_news4.asp [20] Microsoft: http://www.microsoft.com/cze/office/visio/overview.mspx [21] Microsoft: http://www.microsoft.com/cze/office/officexp/visio/evaluation/techtour/page4.asp [22] Microsoft: http://microsoft.mironet.cz/ms-visio-std-2003-win32-czech-cd+dp43877/ [23] Microsoft:

http://www.pcworld.cz/pcw.nsf/069b11ec6da3c04cc1256b04004e3f3c/f7e958d46289df25c1256fa10047aed8?OpenDocument&Highlight=0,Visio

[24] Microsoft: http://www.microsoft.com/office/visio/prodinfo/editions.mspx [25] Microsoft: http://www.microsoft.com/cze/office/sharepoint/default.mspx [26] Microsoft: http://www.microsoft.com/office/sharepoint/prodinfo/sysreq.mspx [27] Microsoft: http://msdn.microsoft.com/windowsvista/building/workflow/default.aspx [28] The Official Microsoft Windows Workflow Site: http://www.windowsworkflow.net

64 / 64

Date post:	26-Jun-2020
Category:	Documents
Upload:	others
View:	13 times
Download:	0 times

CASE pro workflow - panrepa.orgpanrepa.org/CASE/CASE_pro_workflow06.pdf · Použití CASE/CABE pro...

Documents