BPEL (Language Process Execution Language) je postal ena najpomembnejših tehnologij SOA (storitveno usmerjena arhitektura) in omogoča enostavno in prilagodljivo sestavo storitev v poslovne procese. BPEL je še posebej pomemben, ker v razvoj aplikacij uvaja nov koncept - splošno programiranje. Ta koncept nam omogoča hiter razvoj procesov, tako da določimo vrstni red, v katerem se bodo klicale storitve. Na ta način aplikacije (in informacijski sistemi) postanejo bolj prilagodljive in se lahko bolje prilagodijo spremembam v poslovnih procesih.
Poslovni procesi so običajno dinamične narave. Podjetja morajo izboljšati in spremeniti, delovati gibčno, optimizirati in prilagoditi procese, da izboljšajo odzivnost celotnega podjetja. Vsaka sprememba in izboljšanje poslovnega procesa se mora odražati v aplikacijah, ki jim zagotavljajo podporo. Čeprav se ta zahteva morda ne zdi težko izpolniti, nam dejanske razmere kažejo drugačno sliko. Spreminjanje in spreminjanje aplikacij je pogosto težko delo, ki zahteva čas. Zato se aplikacije ne morejo takoj odzvati na spremembe v poslovnih procesih - rabijo nekaj časa za izvedbo, preizkušanje in uvajanje sprememb.
Glavna obljuba SOA je, da bodo informacijski sistemi bolj prilagodljivi in prilagodljivi spremembam ter bolj usklajeni s poslovnimi procesi. V tem članku pokažem, zakaj je BPEL tako pomemben, in predstavim, kako razviti postopek BPEL.
Storitveno usmerjen pristop
Pristop SOA za učinkovito avtomatizacijo poslovnih procesov zahteva:
- Standardiziran način za razkrivanje in dostop do funkcionalnosti aplikacij kot storitev
- Infrastruktura podjetniškega vodila za komunikacijo in upravljanje storitev, vključno s prestrezanjem, usmerjanjem, preoblikovanjem sporočil itd.
- Specializiran jezik za sestavo izpostavljenih funkcionalnosti aplikacij v poslovne procese
Prvo zahtevo izpolnjuje najnovejša porazdeljena arhitektura - spletne storitve. Drugo zahtevo izpolnjuje ESB (Enterprise Service Bus), ki zagotavlja podporo za centralizirano, deklarativno in dobro usklajeno upravljanje storitev in njihovih komunikacij. Tretjo zahtevo, sestavo storitev v procese, izpolnjuje BPEL, splošno sprejet specializiran jezik za opredelitev in izvajanje poslovnih procesov.
Kot vidi BPEL, poslovni proces predstavlja zbirko usklajenih klicev storitev in z njimi povezanih dejavnosti, ki dajejo rezultat bodisi znotraj ene organizacije bodisi v več njih. Na primer, poslovni postopek za načrtovanje poslovnih potovanj bo zahteval več storitev. V poenostavljenem scenariju bo poslovni proces zahteval, da določimo ime zaposlenega, kraj, datume in druge podrobnosti potovanja. Nato bo postopek poklical spletno storitev za preverjanje statusa zaposlenega. Glede na status zaposlenega bo izbral ustrezen potovalni razred. Nato bo poklical spletne storitve več letalskih družb (kot so American Airlines, Delta Airlines itd.), Da preveri ceno letalskih vozovnic in kupi tisto z najnižjo ceno.
Za stranke bo postopek BPEL izpostavil svojo funkcionalnost na enak način kot katera koli druga spletna storitev. Z vidika stranke bo videti popolnoma enako kot katera koli druga spletna storitev. To je pomembno in koristno, saj nam omogoča, da storitve sestavimo v enostavne procese, enostavne procese v bolj zapletene procese itd. To pomeni tudi, da bo vsak postopek BPEL opisan z opisom WSDL (jezik za opis spletnih storitev).
Osnovni koncepti
BPEL je jezik, ki temelji na XML. Postopek BPEL je sestavljen iz korakov. Vsak korak se imenuje aktivnost. BPEL podpira primitivne in strukturne dejavnosti. Primitivne dejavnosti predstavljajo osnovne konstrukcije in se uporabljajo za skupne naloge, kot so spodaj navedene:
- Priklic spletnih storitev, uporaba
- Čakanje na zahtevo z uporabo
- Manipuliranje s podatkovnimi spremenljivkami z uporabo
- Označevanje napak in izjem, uporaba
itd.
Nato lahko te dejavnosti združimo v bolj zapletene algoritme, ki določajo korake poslovnega procesa. Za združitev primitivnih dejavnosti BPEL podpira več strukturnih dejavnosti. Najpomembnejši so:
- Zaporedje (
) za določanje nabora dejavnosti, ki se bodo uporabljale v urejenem zaporedju - Pretok (
) za določanje nabora dejavnosti, ki se bodo vzporedno uporabljale - Konstrukcija primera-preklop (
) za izvajanje podružnic - Medtem (
) za definiranje zank itd.
Kot bomo videli, se BPEL ne razlikuje toliko od programskih jezikov, kot je Java. Videli pa bomo, da se BPEL razlikuje od Jave in podpira značilnosti poslovnih procesov. BPEL ponuja tudi obdelovalce napak in odškodnin, obdelovalce dogodkov in korelacijske nize. Zagotavlja sredstva za izražanje zapletenih vzporednih tokov. Olajša tudi klicanje asinhronih operacij in čakanje na povratne klice.
BPEL procesi zahtevajo izvajalno okolje - strežnik BPEL, ki nam daje dober nadzor nad njihovim izvajanjem. Običajno strežniki BPEL omogočajo nadzor nad primerki procesa, ki se izvajajo, in nad tistimi, ki so se končali. Podpirajo dolgotrajne procese in lahko dehidrirajo stanje procesa, da prihranijo vire. Nekateri strežniki omogočajo nadzor nad procesnimi aktivnostmi in omogočajo njihovo spremljanje. Na koncu se s pomočjo strežnika BPEL vsi naši procesi uvedejo centralno, kar poenostavi vzdrževanje. Vse to naredi strežnik BPEL prednostno okolje za izvajanje in upravljanje procesov.
Izbira pravega strežnika BPEL pa je lahko precej težka, saj obstaja več možnosti. Nekateri najbolj priljubljeni strežniki BPEL, ki temeljijo na Javi EE (novo ime Sun za J2EE), vključujejo Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration in AquaLogic. Na voljo so tudi vsaj štirje odprtokodni strežniki BPEL: ActiveBPEL Engine, FiveSight PXE, bexee in Apache Agila.
Primer postopka
Oglejmo si zdaj primer postopka BPEL za poslovna potovanja, ki smo ga opisali zgoraj. Razvili bomo asinhroni postopek, ki bo s sinhronim klicem preveril stanje potovanja zaposlenih in dva asinhrona klica za pridobitev cen letalskih vozovnic. Spodnja slika prikazuje splošno strukturo našega procesa. Na levi strani vidimo stranko, ki prikliče postopek. Postopek najprej pokliče spletno storitev stanja potovanja zaposlenega. Nato sočasno in asinhrono prikliče spletne storitve obeh letalskih prevoznikov. To pomeni, da bo moral postopek izvajati operacijo povratnega klica (in vrsto pristanišča), prek katere bodo letalske družbe vrnile potrditev letalske karte. Nazadnje postopek stranki vrne najboljšo ponudbo letalskih vozovnic. V tem primeru za ohranjanje enostavnosti ne bomo izvajali nobenega odpravljanja napak, kar je v resničnih scenarijih ključnega pomena.
Naj zdaj napišemo kodo BPEL. Začnemo z deklaracijo procesa - korenskim elementom, kjer določimo ime procesa in imenske prostore:
Nato moramo definirati partnerske povezave. Partnerske povezave opredeljujejo različne strani, ki sodelujejo s postopkom BPEL. Sem spadajo vse spletne storitve, ki bodo poklicane, in odjemalec postopka. Vsaka partnerska povezava določa do dva atributa: myRole ki kaže na vlogo samega poslovnega procesa in partnerRole to kaže na vlogo partnerja. V našem primeru definiramo štiri partnerske povezave:
Za shranjevanje sporočil ter njihovo preoblikovanje in preoblikovanje potrebujemo spremenljivke. Običajno uporabimo spremenljivko za vsako sporočilo, poslano spletnim storitvam in prejeto od njih. V našem primeru bomo potrebovali nekaj spremenljivk. Za vsako spremenljivko moramo določiti vrsto. Uporabimo lahko vrsto sporočila WSDL, preprost tip sheme XML ali element sheme XML. V našem primeru uporabljamo vrste sporočil WSDL za vse spremenljivke:
Zdaj smo pripravljeni napisati glavno telo procesa. Vsebuje le eno dejavnost na najvišji ravni. Običajno je to ki nam omogoča, da določimo več dejavnosti, ki se bodo izvajale zaporedno. V zaporedju najprej določimo vhodno sporočilo, ki zažene poslovni proces. To počnemo z konstrukt, ki čaka na ujemajoče se sporočilo. V našem primeru je to TravelRequest sporočilo. Znotraj konstrukt, sporočila ne določimo neposredno. Namesto tega določimo partnersko povezavo, vrsto vrat, ime operacije in po želji spremenljivko, ki vsebuje prejeto sporočilo za nadaljnje operacije. Sprejem sporočil povežemo s partnerjem stranko in počakamo na Odobritev potovanja operacija, ki jo je treba priklicati za vrsto vrat TravelApprovalPT. Prejeto sporočilo shranimo v TravelRequest spremenljivka:
Nato moramo priklicati spletno storitev Employee Travel Status. Pred tem moramo pripraviti prispevek za to spletno storitev. Takšno sporočilo lahko sestavimo tako, da kopiramo zaposleni del sporočila, ki ga je poslala stranka. Zdaj lahko pokličemo spletno storitev Status zaposlenega na potovanju. Naredimo sinhroni klic, za katerega uporabljamo dejavnosti. Uporabljamo workerTravelStatus partnerska povezava in prikličete EmployeeTravelStatus operacija na EmployeeTravelStatusPT tip pristanišča. Pripravili smo vhodno sporočilo v EmployeeTravelStatusRequest spremenljivka. Ker gre za sinhroni klic, klic počaka na odgovor in ga shrani v EmployeeTravelStatusResponse spremenljivka:
Naslednji korak je priklic obeh letalskih spletnih storitev. Spet najprej pripravimo zahtevano vhodno sporočilo (ki je enako za obe spletni storitvi). Opravljali bomo sočasne asinhrone klice. Za izražanje sočasnosti BPEL ponuja dejavnosti. Priklic posamezne spletne storitve bo sestavljen iz dveh korakov:
- The
dejavnost se uporablja za asinhroni klic - The
dejavnost se uporablja za čakanje na povratni klic
Uporabljamo združiti obe dejavnosti. Oba klica se razlikujeta samo v imenu partnerske povezave. Uporabljamo AmericanAirlines za enega in DeltaAirlines za drugo:
...
