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

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-thenelse, 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 (codeseparation). 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 runtime 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 WScoordination 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 kontraktu je definováno, jakým způsobem bude služba 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 zařazujeme operační charakteristiky (znaková sada, transportní protokol, logování apod.) Politika bývá vyjádřena ve formě SLA. Koncept SOA počítá se dvěma typy rolí: poskytovatel (provider) a spotřebitel (consumer). Poskytovatel 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). Způsobem vytvoření a užití můžeme služby třídit podle: Synchronnosti o Synchronní o Asynchronní o Konverzační Kompozice o Jednoduché o Složené Orchestrace o Sériové o Paralelní Webové služby (Web Services - WS) 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í. Aby 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 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 spotřebitelům Integrovat aplikace volnou vazbou (loose coupling), která odstraňuje problémy s novými verzemi jednotlivých aplikací, konflikty verzí (známé DLL Hell v COM), 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 komunikovat s ostatními Řídit architekturu z hlediska funkcionality, nákladů a pod. Webové služby jsou využívány v dvou základních kontextech: Zpřístupnění funkcionality starých aplikací a integrace aplikací Vystavení nové funkcionality spotřebitelům - ať již na internetu nebo v podnikové aplikační architektuře Pro webové služby jsou podstatné tři protokoly: UDDI WSDL SOAP Jej ich vztah popisuje následující obrázek: 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 webovou službu jakým způsobem je možné se službou 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 XML a může fungovat nad různými transportní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). Tyto zá kladní protokoly jsou velice jednoduché, dalo by se říci až minimalistické. Právě díky své jednoduchosti se stali webové služby tak populární, protože na všichni hlavní dodavatelé byli 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 Proces je soubor aktivit, které transformují vstupy (input) na určitý výstup (output). Proces tedy definuje, JAK musí být něco vykonáno. Proces bývá vyvolán vnějším podnětem. V 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 nejsou identické, protože služba definuje CO se bude dělat a proces určuje JAK se to bude dělat. Služby musí být tedy přirazeny nikoli procesům, ale biznis 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 Služba navázaná na proces Jednoduchá definice služby Jednodušší model Rychlejší implementace 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 Nevýhody 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 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 mezipodnikový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