BPEL (biznesa procesu izpildes valoda) ir kļuvusi par vienu no vissvarīgākajām SOA (uz pakalpojumiem orientētās arhitektūras) tehnoloģijām un ļauj ērti un elastīgi salikt pakalpojumus biznesa procesos. BPEL ir īpaši svarīgs, jo ar to tiek ieviesta jauna koncepcija lietojumprogrammu izstrādē - programmēšana kopumā. Šī koncepcija ļauj mums ātri izstrādāt procesus, nosakot pakalpojumu izsaukšanas secību. Tādā veidā lietojumprogrammas (un informācijas sistēmas) kļūst elastīgākas un var labāk pielāgoties izmaiņām biznesa procesos.
Biznesa procesiem parasti ir dinamisks raksturs. Lai uzlabotu visa uzņēmuma atsaucību, uzņēmumiem ir jāuzlabo un jāpārveido, jārīkojas veikli, jāoptimizē un jāpielāgo procesi. Katra biznesa procesa izmaiņa un uzlabojums ir jāatspoguļo lietojumprogrammās, kas tām sniedz atbalstu. Lai arī šo prasību var neizklausīties ļoti grūti izpildīt, reālā situācija mums parāda atšķirīgu ainu. Lietojumprogrammu maiņa un modificēšana bieži ir grūts darbs, kas prasa laiku. Tāpēc lietojumprogrammas nevar uzreiz reaģēt uz izmaiņām biznesa procesos - drīzāk tām nepieciešams zināms laiks, lai ieviestu, pārbaudītu un izvietotu modifikācijas.
Galvenais SOA solījums ir padarīt informācijas sistēmas elastīgākas un pielāgojamākas izmaiņām un labāk saskaņotas ar biznesa procesiem. Šajā rakstā es parādīju, kāpēc BPEL ir tik svarīgs, un parādīju, kā attīstīt BPEL procesu.
Uz pakalpojumu orientēta pieeja
SOA pieejai efektīvai biznesa procesu automatizēšanai ir nepieciešami:
- Standartizēts veids, kā atklāt un piekļūt lietojumprogrammu kā pakalpojumu funkcionalitātei
- Uzņēmuma autobusu infrastruktūra saziņai un pakalpojumu pārvaldībai, ieskaitot ziņojumu pārtveršanu, maršrutēšanu, pārveidošanu utt.
- Specializēta valoda lietojumam pakļauto funkcionalitāšu komponēšanai biznesa procesos
Pirmo prasību izpilda jaunākā izplatītā arhitektūra - tīmekļa pakalpojumi. Otro prasību izpilda ESB (uzņēmuma pakalpojumu kopne), kas nodrošina centralizētu, deklaratīvu un labi koordinētu pakalpojumu un to sakaru pārvaldību. Trešo prasību - pakalpojumu sastāvu procesos - izpilda BPEL - vispārpieņemtā specializētā valoda biznesa procesu definēšanai un izpildei.
Biznesa process, kā to redz BPEL, ir koordinētu pakalpojumu izsaukumu un saistīto darbību kopums, kas rada rezultātu vai nu vienā organizācijā, vai vairākās organizācijās. Piemēram, biznesa process biznesa ceļojumu plānošanai izmantos vairākus pakalpojumus. Pārāk vienkāršotā scenārijā biznesa process prasīs, lai mēs norādītu darbinieka vārdu, galamērķi, datumus un citu ceļojuma informāciju. Tad process izsauks tīmekļa pakalpojumu, lai pārbaudītu darbinieka statusu. Pamatojoties uz darbinieka statusu, tā izvēlēsies atbilstošo ceļojuma klasi. Tad tā izmantos vairāku aviokompāniju (piemēram, American Airlines, Delta Airlines utt.) Tīmekļa pakalpojumus, lai pārbaudītu aviobiļešu cenu un nopirktu cenu ar viszemāko cenu.
Klientiem BPEL process atklās tā funkcionalitāti tāpat kā jebkuru citu tīmekļa pakalpojumu. No klienta viedokļa tas izskatīsies tieši tāpat kā jebkurš cits tīmekļa pakalpojums. Tas ir svarīgi un noderīgi, jo tas ļauj mums apkopot pakalpojumus vienkāršos procesos, vienkāršus procesus sarežģītākos procesos utt. Tas arī nozīmē, ka katrs BPEL process tiks aprakstīts ar WSDL (Web Services Description Language) aprakstu.
Pamatjēdzieni
BPEL ir uz XML balstīta valoda. BPEL process sastāv no posmiem. Katru soli sauc par darbību. BPEL atbalsta primitīvas un strukturālas darbības. Primitīvās darbības ir pamata konstrukcijas un tiek izmantotas kopīgiem uzdevumiem, piemēram, tiem, kas uzskaitīti zemāk:
- Tīmekļa pakalpojumu izsaukšana, izmantošana
- Gaida pieprasījumu, izmantojot
- Manipulējot ar datu mainīgajiem lielumiem, izmantojot
- Norādot kļūdas un izņēmumus, izmantojot
utt.
Pēc tam mēs varam apvienot šīs darbības sarežģītākos algoritmos, kas norāda biznesa procesa darbības. Lai apvienotu primitīvas darbības, BPEL atbalsta vairākas struktūras darbības. Vissvarīgākie ir:
- Secība (
), lai noteiktu darbību kopumu, kas tiks izsaukti sakārtotā secībā - Plūsma (
), lai noteiktu darbību kopumu, kas tiks izmantots paralēli - Lietu pārslēgšanas konstrukcija (
) filiāļu ieviešanai - Kamēr (
) cilpu noteikšanai utt.
Kā redzēsim, BPEL neatšķiras no programmēšanas valodām, piemēram, Java. Bet mēs redzēsim, ka BPEL atšķiras no Java un atbalsta biznesa procesu īpašības. BPEL nodrošina arī kļūdu un kompensāciju apstrādātājus, notikumu apstrādātājus un korelācijas kopas. Tas nodrošina līdzekļus sarežģītu paralēlu plūsmu izteikšanai. Tas arī ļauj salīdzinoši viegli izsaukt asinhronas darbības un gaidīt atzvanīšanu.
BPEL procesiem nepieciešama izpildlaika vide - BPEL serveris, kas mums ļauj labi kontrolēt to izpildi. Parasti BPEL serveri nodrošina kontroli pār izpildāmajiem un pabeigtajiem procesa gadījumiem. Tie atbalsta ilgstošus procesus un var dehidrēt procesa stāvokli, lai ietaupītu resursus. Daži serveri nodrošina procesa darbību kontroli un ļauj tos uzraudzīt. Visbeidzot, izmantojot BPEL serveri, visi mūsu procesi tiek izvietoti centralizēti, kas vienkāršo apkopi. Tas viss padara BPEL serveri par vēlamo vidi procesu darbināšanai un pārvaldīšanai.
Pareiza BPEL servera izvēle var būt diezgan sarežģīta, jo ir vairākas izvēles iespējas. Daži no populārākajiem BPEL serveriem, kuru pamatā ir Java EE (Sun jaunais nosaukums J2EE), ir Oracle BPEL procesu pārvaldnieks, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration un AquaLogic. Pieejami arī vismaz četri atvērtā koda BPEL serveri: ActiveBPEL Engine, FiveSight PXE, bexee un Apache Agila.
Procesa piemērs
Tagad aplūkosim iepriekš aprakstīto BPEL procesa piemēru uzņēmējdarbības ceļojumiem. Mēs izstrādāsim asinhronu procesu, kas izmantos sinhrono zvanu, lai pārbaudītu darbinieka ceļojuma statusu, un divus asinhronus zvanus, lai iegūtu lidmašīnas biļešu cenas. Zemāk redzamais attēls parāda mūsu procesa vispārējo struktūru. Kreisajā pusē mēs redzam klientu, kurš izsauc procesu. Process vispirms izsauc darbinieka ceļojuma statusa tīmekļa pakalpojumu. Tad tas vienlaikus un asinhroni izsauc abu aviosabiedrību tīmekļa pakalpojumus. Tas nozīmē, ka procesā būs jāīsteno atzvanīšanas operācija (un ostas tips), caur kuru aviosabiedrības atgriezīs lidojuma biļetes apstiprinājumu. Visbeidzot, process klientam atdod labāko aviobiļešu piedāvājumu. Šajā piemērā, lai saglabātu vienkāršību, mēs neieviesīsim nekādu kļūdu apstrādi, kas ir izšķiroša reālās situācijas scenārijos.
Tagad uzrakstīsim BPEL kodu. Mēs sākam ar procesa deklarāciju - saknes elementu, kur mēs definējam procesa nosaukumu un nosaukumvietas:
Tālāk mums ir jādefinē partneru saites. Partneru saites definē dažādas puses, kas mijiedarbojas ar BPEL procesu. Tas ietver visus tīmekļa pakalpojumus, kas tiks izsaukti, un procesa klientu. Katrā partnera saitē ir norādīti ne vairāk kā divi atribūti: myRole kas norāda paša biznesa procesa lomu un partnerRole kas norāda uz partnera lomu. Šajā piemērā mēs definējam četras partneru saites:
Lai saglabātu ziņojumus un tos pārformatētu un pārveidotu, mums ir nepieciešami mainīgie. Parasti mēs izmantojam mainīgo katram ziņojumam, kas tiek nosūtīts tīmekļa pakalpojumiem un saņemts no tiem. Mūsu piemērā mums būs nepieciešami daži mainīgie. Katram mainīgajam mums jānorāda veids. Mēs varam izmantot WSDL ziņojumu tipu, vienkāršu XML shēmas tipu vai XML shēmas elementu. Šajā piemērā visiem mainīgajiem izmantojam WSDL ziņojumu veidus:
Tagad mēs esam gatavi uzrakstīt galveno procesa tekstu. Tajā ir tikai viena augstākā līmeņa darbība. Parasti tas ir kas ļauj mums noteikt vairākas darbības, kas tiks veiktas secīgi. Secības ietvaros mēs vispirms norādām ievades ziņojumu, kas sāk uzņēmējdarbības procesu. Mēs to darām ar konstruēt, kas gaida atbilstošo ziņojumu. Mūsu gadījumā tas ir TravelRequest ziņu. Ietvaros konstrukciju, mēs tieši nenorādām ziņojumu. Drīzāk mēs norādām partnera saiti, porta tipu, operācijas nosaukumu un pēc izvēles mainīgo, kas satur saņemto ziņojumu sekojošām operācijām. Mēs saistām ziņojumu saņemšanu ar klienta partneri un gaidām TravelApproval operācija, kas jāizsauc ostas tipam TravelApprovalPT. Saņemto ziņojumu mēs glabājam TravelRequest mainīgais:
Tālāk mums jāizsauc Employee Travel Status Web pakalpojums. Pirms tam mums jāsagatavo ievads šim tīmekļa pakalpojumam. Šādu ziņojumu mēs varam izveidot, nokopējot klienta nosūtītās ziņas daļu darbiniekam. Tagad mēs varam izmantot tīmekļa pakalpojumu Employee Travel Status. Mēs veicam sinhronu izsaukumu, kuram mēs izmantojam aktivitāte. Mēs izmantojam darbinieksTravelStatus partnera saiti un izsaukt EmployeeTravelStatus darbība uz EmployeeTravelStatusPT ostas tips. Mēs esam sagatavojuši ievades ziņojumu EmployeeTravelStatusRequest mainīgais. Tā kā tā ir sinhrona izsaukšana, zvans gaida atbildi un saglabā to EmployeeTravelStatusResponse mainīgais:
Nākamais solis ir izmantot abus aviokompānijas tīmekļa pakalpojumus. Atkal mēs vispirms sagatavojam nepieciešamo ievades ziņojumu (kas ir vienāds abiem tīmekļa pakalpojumiem). Mēs veiksim vienlaicīgas asinhronas invokācijas. Lai izteiktu vienlaicīgumu, BPEL nodrošina aktivitāte. Katra tīmekļa pakalpojuma izsaukšana sastāv no divām darbībām:
- The
aktivitāte tiek izmantota asinhronai izsaukšanai - The
aktivitāte tiek izmantota, lai gaidītu atzvanīšanu
Mēs izmantojam grupēt abas darbības. Abi izsaukumi atšķiras tikai no partnera saites nosaukuma. Mēs izmantojam AmericanAirlines par vienu un DeltaAirlines otram:
...
