Programování

BPEL: Složení služby pro SOA

BPEL (Business Process Execution Language) se stal jednou z nejdůležitějších technologií SOA (architektura orientovaná na služby) a umožňuje snadné a flexibilní složení služeb do podnikových procesů. BPEL je obzvláště důležitý, protože zavádí nový koncept do vývoje aplikací - programování ve velkém. Tento koncept nám umožňuje rychle vyvíjet procesy definováním pořadí, ve kterém budou služby vyvolány. Tímto způsobem se aplikace (a informační systémy) stávají pružnějšími a mohou se lépe přizpůsobit změnám v podnikových procesech.

Obchodní procesy jsou obvykle dynamické povahy. Společnosti musí vylepšovat a upravovat, jednat svižně, optimalizovat a přizpůsobovat procesy, aby zlepšily odezvu celé společnosti. Každá změna a vylepšení obchodního procesu se musí promítnout do aplikací, které jim poskytují podporu. Ačkoli tento požadavek nemusí znít příliš obtížně, situace v reálném světě nám ukazuje jiný obrázek. Změna a úprava aplikací je často obtížná práce, která vyžaduje čas. Aplikace proto nemohou okamžitě reagovat na změny v obchodních procesech - spíše vyžadují určitý čas na implementaci, testování a nasazení úprav.

Zvyšování flexibility a přizpůsobení informačních systémů změnám a lepší sladění s obchodními procesy je hlavním příslibem SOA. V tomto článku ukážu, proč je BPEL tak důležitý, a ukážu, jak vyvinout proces BPEL.

Přístup orientovaný na služby

Přístup SOA pro efektivní automatizaci obchodních procesů vyžaduje:

  • Standardizovaný způsob vystavení a přístupu k funkcím aplikací jako služeb
  • Infrastruktura podnikové sběrnice pro komunikaci a správu služeb, včetně odposlechu zpráv, směrování, transformace atd.
  • Specializovaný jazyk pro složení exponovaných funkcí aplikací do obchodních procesů

První požadavek splňuje nejnovější distribuovaná architektura - webové služby. Druhý požadavek splňuje ESB (podniková sběrnice služeb), která poskytuje podporu pro centralizovanou, deklarativní a dobře koordinovanou správu služeb a jejich komunikace. Třetí požadavek, složení služeb do procesů, splňuje BPEL, běžně přijímaný specializovaný jazyk pro definování a provádění obchodních procesů.

Obchodní proces, jak jej vidí společnost BPEL, je souborem koordinovaných vyvolání služeb a souvisejících aktivit, které vedou k výsledku, a to buď v rámci jedné organizace, nebo v několika organizacích. Například obchodní proces pro plánování obchodních cest vyvolá několik služeb. V příliš zjednodušeném scénáři bude obchodní proces vyžadovat, abychom uvedli jméno zaměstnance, cíl, data a další cestovní údaje. Poté proces vyvolá webovou službu ke kontrole stavu zaměstnance. Na základě stavu zaměstnance vybere příslušnou cestovní třídu. Poté vyvolá webové služby několika leteckých společností (například American Airlines, Delta Airlines atd.), Aby zkontrolovaly cenu letenky a koupily tu s nejnižší cenou.

Pro klienty vystaví proces BPEL svou funkčnost stejným způsobem jako jakoukoli jinou webovou službu. Z pohledu klienta to bude vypadat přesně jako každá jiná webová služba. To je důležité a užitečné, protože nám to umožňuje skládat služby do jednoduchých procesů, jednoduché procesy do složitějších procesů atd. To také znamená, že každý proces BPEL bude popsán s popisem WSDL (Web Services Description Language).

Základní koncepty

BPEL je jazyk založený na XML. Proces BPEL se skládá z kroků. Každý krok se nazývá aktivita. BPEL podporuje primitivní a strukturní aktivity. Primitivní aktivity představují základní konstrukce a používají se pro běžné úkoly, jako jsou ty uvedené níže:

  • Vyvolání webových služeb pomocí
  • Čekání na požadavek pomocí
  • Manipulace s datovými proměnnými pomocí
  • Indikace poruch a výjimek pomocí , atd.

Tyto aktivity pak můžeme kombinovat do složitějších algoritmů, které určují kroky obchodního procesu. Chcete-li kombinovat primitivní aktivity, podporuje BPEL několik aktivit struktury. Nejdůležitější jsou:

  • Sekvence () pro definování sady aktivit, které budou vyvolány v seřazeném pořadí
  • Průtok () pro definování sady aktivit, které budou vyvolány paralelně
  • Konstrukce case-switch () pro implementaci poboček
  • Zatímco () pro definování smyček atd.

Jak uvidíme, BPEL se neliší od programovacích jazyků, jako je Java. Uvidíme ale, že BPEL se liší od Javy a podporuje charakteristiky obchodních procesů. BPEL také poskytuje obslužné rutiny poruch a kompenzací, obslužné rutiny událostí a korelační sady. Poskytuje prostředky k vyjádření složitých paralelních toků. Díky tomu je také relativně snadné volat asynchronní operace a čekat na zpětná volání.

Procesy BPEL vyžadují běhové prostředí - server BPEL, který nám dává dobrou kontrolu nad jejich spuštěním. Servery BPEL obvykle poskytují kontrolu nad instancemi procesů, které jsou prováděny, a těmi, které jsou hotové. Podporují dlouhotrvající procesy a mohou dehydratovat stav procesu, aby šetřily prostředky. Některé servery poskytují kontrolu nad procesními aktivitami a umožňují jejich monitorování. A konečně, pomocí serveru BPEL jsou všechny naše procesy nasazeny centrálně, což zjednodušuje údržbu. Díky tomu je server BPEL preferovaným prostředím pro běh a správu procesů.

Výběr správného serveru BPEL však může být docela obtížný, protože existuje několik možností. Mezi nejoblíbenější servery BPEL založené na prostředí Java EE (nový název společnosti Sun pro J2EE) patří Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration a AquaLogic. K dispozici jsou také minimálně čtyři servery open source BPEL: ActiveBPEL Engine, FiveSight PXE, bexee a Apache Agila.

Příklad procesu

Podívejme se nyní na příklad procesu BPEL pro obchodní cesty, který jsme popsali výše. Vyvineme asynchronní proces, který pomocí synchronního volání zkontroluje stav cestování zaměstnance a dva asynchronní volání k získání cen letenek. Obrázek níže ukazuje celkovou strukturu našeho procesu. Vlevo vidíme klienta, který proces vyvolá. Tento proces nejprve zavolá webovou službu o stavu cestování zaměstnance. Poté vyvolá webové služby obou leteckých společností souběžně a asynchronně. To znamená, že proces bude muset implementovat operaci zpětného volání (a typ přístavu), prostřednictvím které letecké společnosti vrátí potvrzení letenky. Nakonec proces vrátí klientovi nejlepší nabídku letenek. V tomto příkladu nebudeme kvůli zachování jednoduchosti implementovat žádné zpracování chyb, což je zásadní ve scénářích reálného světa.

Nyní napíšeme kód BPEL. Začneme deklarací procesu - kořenovým prvkem, kde definujeme název procesu a obory názvů:

Dále musíme definovat partnerské odkazy. Partnerské odkazy definují různé strany, které interagují s procesem BPEL. To zahrnuje všechny webové služby, které budou vyvolány, a klient procesu. Každý partnerský odkaz určuje až dva atributy: moje role to naznačuje roli samotného obchodního procesu a role partnera to naznačuje roli partnera. V našem příkladu definujeme čtyři partnerské odkazy:

K ukládání zpráv a jejich přeformátování a transformaci potřebujeme proměnné. Obvykle používáme proměnnou pro každou zprávu odeslanou do webových služeb a přijatou od nich. V našem příkladu budeme potřebovat několik proměnných. Pro každou proměnnou musíme určit typ. Můžeme použít typ zprávy WSDL, jednoduchý typ schématu XML nebo prvek schématu XML. V našem příkladu používáme typy zpráv WSDL pro všechny proměnné:

Nyní jsme připraveni napsat hlavní tělo procesu. Obsahuje pouze jednu aktivitu nejvyšší úrovně. Obvykle se jedná o což nám umožňuje definovat několik aktivit, které se budou provádět postupně. V rámci posloupnosti nejprve zadáme vstupní zprávu, která spouští obchodní proces. Děláme to s konstrukce, která čeká na odpovídající zprávu. V našem případě se jedná o TravelRequest zpráva. V rámci konstrukt, nezadáváme zprávu přímo. Místo toho zadáme partnerský odkaz, typ portu, název operace a volitelně proměnnou, která obsahuje přijatou zprávu pro následné operace. Propojíme příjem zpráv s partnerem klienta a počkáme na TravelApproval operace, která má být vyvolána na typu portu TravelApprovalPT. Přijatou zprávu ukládáme do TravelRequest proměnná:

Dále musíme vyvolat webovou službu Stav cestování zaměstnanců. Před tím musíme připravit vstup pro tuto webovou službu. Můžeme vytvořit takovou zprávu zkopírováním zaměstnanecké části zprávy, kterou klient poslal. Nyní můžeme vyvolat webovou službu Stav cestování zaměstnanců. Provádíme synchronní vyvolání, pro které používáme aktivita. Používáme employeeTravelStatus partnerský odkaz a vyvolat EmployeeTravelStatus provoz na EmployeeTravelStatusPT typ portu. Připravili jsme vstupní zprávu v EmployeeTravelStatusRequest proměnná. Protože se jedná o synchronní vyvolání, volání čeká na odpověď a uloží ji do EmployeeTravelStatusResponse proměnná:

Dalším krokem je vyvolání obou webových služeb leteckých společností. Opět nejprve připravíme požadovanou vstupní zprávu (která je pro obě webové služby stejná). Provedeme souběžná asynchronní vyvolání. Pro vyjádření souběžnosti poskytuje BPEL aktivita. Vyvolání každé webové služby bude sestávat ze dvou kroků:

  1. The aktivita se používá pro asynchronní vyvolání
  2. The aktivita slouží k čekání na zpětné volání

Používáme seskupit obě aktivity. Dvě vyvolání se liší pouze v názvu partnerského odkazu. Používáme Americké aerolinky pro jednoho a DeltaAirlines pro druhou:

...

$config[zx-auto] not found$config[zx-overlay] not found