Programovanie

BPEL: Zloženie služby pre SOA

BPEL (Business Process Execution Language) sa stal jednou z najdôležitejších technológií SOA (architektúra orientovaná na služby) a umožňuje ľahké a flexibilné zloženie služieb do obchodných procesov. BPEL je obzvlášť dôležitý, pretože zavádza do vývoja aplikácií nový koncept - programovanie vo veľkom. Táto koncepcia nám umožňuje rýchlo rozvíjať procesy definovaním poradia, v ktorom budú služby vyvolané. Týmto spôsobom sa aplikácie (a informačné systémy) stávajú pružnejšími a môžu sa lepšie prispôsobiť zmenám v podnikových procesoch.

Obchodné procesy majú zvyčajne dynamický charakter. Spoločnosti musia vylepšovať a upravovať, konať svižne, optimalizovať a prispôsobovať procesy, aby zlepšili reakčnú schopnosť celej spoločnosti. Každá zmena a vylepšenie obchodného procesu sa musí odraziť v aplikáciách, ktoré ich poskytujú podporu. Aj keď táto požiadavka nemusí znieť veľmi ťažko, situácia v reálnom svete nám ukazuje iný obraz. Zmena a úprava aplikácií je často náročná práca, ktorá si vyžaduje čas. Aplikácie preto nemôžu okamžite reagovať na zmeny v obchodných procesoch - skôr si vyžadujú určitý čas na implementáciu, testovanie a nasadenie úprav.

Hlavným prísľubom SOA je zvýšenie flexibility a prispôsobenia informačných systémov zmenám a lepšie zosúladenie s obchodnými procesmi. V tomto článku ukážem, prečo je BPEL taký dôležitý, a ukážem, ako vyvinúť proces BPEL.

Prístup zameraný na služby

Prístup SOA k efektívnej automatizácii obchodných procesov vyžaduje:

  • Štandardizovaný spôsob vystavenia a prístupu k funkčnosti aplikácií ako služieb
  • Infraštruktúra podnikovej zbernice na komunikáciu a správu služieb vrátane odpočúvania správ, smerovania, transformácie atď.
  • Špecializovaný jazyk pre zloženie exponovaných funkcií aplikácií do obchodných procesov

Prvú požiadavku spĺňa najnovšia distribuovaná architektúra - webové služby. Druhú požiadavku spĺňa ESB (podniková zbernica služieb), ktorá poskytuje podporu pre centralizované, deklaratívne a dobre koordinované riadenie služieb a ich komunikácií. Tretiu požiadavku, zloženie služieb do procesov, spĺňa BPEL, bežne akceptovaný špecializovaný jazyk pre definovanie a vykonávanie obchodných procesov.

Obchodný proces, ako ho vidí BPEL, je súborom koordinovaných vyvolaní služieb a súvisiacich aktivít, ktoré vedú k výsledku, a to buď v rámci jednej organizácie, alebo vo viacerých organizáciách. Napríklad obchodný proces plánovania obchodných ciest vyvolá niekoľko služieb. V príliš zjednodušenom scenári bude obchodný proces vyžadovať, aby sme špecifikovali meno zamestnanca, cieľ, dátumy a ďalšie cestovné podrobnosti. Potom proces vyvolá webovú službu na kontrolu stavu zamestnanca. Na základe stavu zamestnanca vyberie príslušnú cestovnú triedu. Potom vyvolá webové služby niekoľkých leteckých spoločností (napríklad American Airlines, Delta Airlines atď.), Aby skontrolovali cenu letenky a kúpili spoločnosť s najnižšou cenou.

Pre klientov proces BPEL odhalí svoju funkcionalitu rovnakým spôsobom ako akákoľvek iná webová služba. Z pohľadu klienta bude vyzerať presne ako každá iná webová služba. To je dôležité a užitočné, pretože nám umožňuje skladať služby do jednoduchých procesov, jednoduché procesy do zložitejších procesov atď. To tiež znamená, že každý proces BPEL bude popísaný s popisom WSDL (Web Services Description Language).

Základné koncepty

BPEL je jazyk založený na XML. Proces BPEL pozostáva z krokov. Každý krok sa nazýva aktivita. BPEL podporuje primitívne a štruktúrne aktivity. Primitívne aktivity predstavujú základné konštrukty a používajú sa na bežné úlohy, ako sú napríklad tie, ktoré sú uvedené nižšie:

  • Vyvolávanie webových služieb pomocou
  • Čakanie na požiadavku pomocou
  • Manipulácia s dátovými premennými pomocou
  • Indikácia porúch a výnimiek pomocou , atď.

Tieto činnosti potom môžeme spojiť do zložitejších algoritmov, ktoré určujú kroky obchodného procesu. Ak chcete kombinovať primitívne aktivity, BPEL podporuje niekoľko aktivít štruktúry. Najdôležitejšie sú:

  • Postupnosť () na definovanie súboru aktivít, ktoré sa vyvolajú v usporiadanom poradí
  • Prietok () na definovanie súboru aktivít, ktoré sa budú vyvolávať paralelne
  • Konštrukt prepínača prípadov () na implementáciu pobočiek
  • Zatiaľ čo () na definovanie slučiek atď.

Ako uvidíme, BPEL sa až tak nelíši od programovacích jazykov, ako je Java. Uvidíme ale, že BPEL sa líši od Javy a podporuje charakteristiky obchodných procesov. BPEL tiež poskytuje obslužné rutiny chýb a kompenzácií, obslužné rutiny udalostí a sady korelácií. Poskytuje prostriedky na vyjadrenie zložitých paralelných tokov. Pomerne tiež uľahčuje volanie asynchrónnych operácií a čakanie na spätné volania.

Procesy BPEL vyžadujú runtime prostredie - server BPEL, ktorý nám dáva dobrú kontrolu nad ich vykonávaním. Servery BPEL zvyčajne poskytujú kontrolu nad inštanciami procesu, ktoré sa vykonávajú, a nad tými, ktoré sa skončili. Podporujú dlhotrvajúce procesy a môžu dehydratovať stav procesu, aby šetrili zdroje. Niektoré servery poskytujú kontrolu nad činnosťami procesu a umožňujú ich monitorovanie. Nakoniec, pomocou servera BPEL sú všetky naše procesy nasadené centrálne, čo zjednodušuje údržbu. To všetko robí zo servera BPEL preferované prostredie pre beh a správu procesov.

Výber správneho servera BPEL však môže byť dosť ťažký, pretože existuje niekoľko možností. Medzi najobľúbenejšie servery BPEL založené na prostredí Java EE (nový názov spoločnosti Sun pre J2EE) patria Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration a AquaLogic. K dispozícii sú tiež najmenej štyri servery open source BPEL: ActiveBPEL Engine, FiveSight PXE, bexee a Apache Agila.

Príklad procesu

Pozrime sa teraz na príklad procesu BPEL pre obchodné cesty, ktorý sme opísali vyššie. Vyvinieme asynchrónny proces, ktorý pomocou synchrónneho volania skontroluje stav cesty zamestnanca a dva asynchrónne volania na získanie cien leteniek. Obrázok nižšie ukazuje celkovú štruktúru nášho procesu. Na ľavej strane vidíme klienta, ktorý proces vyvoláva. Tento proces najskôr zavolá webovú službu o stave cesty zamestnanca. Potom vyvolá webové služby oboch leteckých spoločností súčasne a asynchrónne. To znamená, že v procese bude musieť byť implementovaná operácia spätného volania (a typu prístavu), prostredníctvom ktorej letecké spoločnosti vrátia potvrdenie letenky. Nakoniec tento proces vráti klientovi najlepšiu ponuku leteniek. V tomto príklade nebudeme kvôli zachovaniu jednoduchosti implementovať žiadnu manipuláciu s chybami, ktorá je v scenároch z reálneho sveta zásadná.

Poďme teraz napísať kód BPEL. Začíname deklaráciou procesu - koreňovým prvkom, kde definujeme názov procesu a menné priestory:

Ďalej musíme definovať partnerské odkazy. Partnerské odkazy definujú rôzne strany, ktoré interagujú s procesom BPEL. Patria sem všetky webové služby, ktoré sa vyvolajú, a klient procesu. Každý partnerský odkaz určuje až dva atribúty: myRole ktorá naznačuje úlohu samotného obchodného procesu a partnerRole to naznačuje úlohu partnera. V našom príklade definujeme štyri partnerské odkazy:

Na ukladanie správ a na ich preformátovanie a transformáciu potrebujeme premenné. Zvyčajne používame premennú pre každú správu odoslanú do webových služieb a prijatú od nich. V našom príklade budeme potrebovať niekoľko premenných. Pre každú premennú musíme určiť typ. Môžeme použiť typ správy WSDL, jednoduchý typ schémy XML alebo prvok schémy XML. V našom príklade používame typy správ WSDL pre všetky premenné:

Teraz sme pripravení napísať hlavné telo procesu. Obsahuje iba jednu aktivitu na najvyššej úrovni. Spravidla ide o ktorý nám umožňuje definovať niekoľko aktivít, ktoré sa budú vykonávať postupne. V rámci postupnosti najskôr zadáme vstupnú správu, ktorá spustí obchodný proces. Robíme to pomocou konštrukt, ktorý čaká na zodpovedajúcu správu. V našom prípade ide o TravelRequest správa. V rámci konštrukt, správu neurčujeme priamo. Namiesto toho zadáme partnerský odkaz, typ portu, názov operácie a voliteľne premennú, ktorá obsahuje prijatú správu pre následné operácie. Prepojíme príjem správ s partnerom klienta a čakáme na TravelApproval operácia, ktorá sa má vyvolať na type portu TravelApprovalPT. Prijatú správu ukladáme do TravelRequest premenná:

Ďalej musíme vyvolať webovú službu Employee Travel Status Web. Predtým si musíme pripraviť vstup pre túto webovú službu. Takúto správu môžeme zostaviť tak, že skopírujeme zamestnaneckú časť správy, ktorú klient poslal. Teraz môžeme vyvolať webovú službu Employee Travel Status Web. Vykonávame synchrónne vyvolanie, na ktoré používame činnosť. Používame employeeTravelStatus partnerský odkaz a vyvolať EmployeeTravelStatus prevádzka na EmployeeTravelStatusPT typ portu. Pripravili sme vstupnú správu v EmployeeTravelStatusRequest premenná. Pretože sa jedná o synchrónne vyvolanie, hovor čaká na odpoveď a uloží ju do EmployeeTravelStatusResponse premenná:

Ďalším krokom je vyvolanie oboch webových služieb leteckých spoločností. Opäť najskôr pripravíme požadovanú vstupnú správu (ktorá je pre obe webové služby rovnaká). Budeme robiť súbežné asynchrónne vyvolania. Na vyjadrenie súbežnosti spoločnosť BPEL poskytuje činnosť. Vyvolanie každej webovej služby bude pozostávať z dvoch krokov:

  1. The aktivita sa používa na asynchrónne vyvolanie
  2. The aktivita slúži na čakanie na spätné volanie

Používame na zoskupenie oboch aktivít. Tieto dve vyvolania sa líšia iba v názve odkazu partnera. Používame AmericanAirlines pre jedného a DeltaAirlines pre druhého:

...

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