BPEL: Sastav usluge za SOA

BPEL (Language Process Execution Language) postao je jedna od najvažnijih tehnologija SOA-e (arhitektura orijentirana na usluge) i omogućuje lako i fleksibilno sastavljanje usluga u poslovnim procesima. BPEL je posebno važan jer u razvoj programa uvodi novi koncept - programiranje u velikoj. Ovaj koncept omogućuje nam brzi razvoj procesa definiranjem redoslijeda pozivanja na usluge. Na taj način, aplikacije (i informacijski sustavi) postaju fleksibilnije i mogu se bolje prilagoditi promjenama u poslovnim procesima.

Poslovni procesi su obično dinamične prirode. Tvrtke moraju poboljšati i modificirati, djelovati agilno, optimizirati i prilagoditi procese kako bi poboljšale reakciju cijele tvrtke. Svaka promjena i poboljšanje poslovnog procesa mora se odraziti na aplikacije koje im pružaju podršku. Iako ovaj zahtjev možda neće zvučati vrlo teško ispuniti, stvarna situacija pokazuje nam drugačiju sliku. Promjena i izmjena aplikacija često je težak posao koji zahtijeva vrijeme. Stoga aplikacije ne mogu trenutno reagirati na promjene u poslovnim procesima - već im treba određeno vrijeme za implementaciju, testiranje i primjenu modifikacija.

Učiniti informacijske sustave fleksibilnijima i prilagodljivijima promjenama te ih bolje uskladiti s poslovnim procesima glavno je obećanje SOA-e. U ovom članku pokazujem zašto je BPEL toliko važan i demonstriram kako razviti BPEL postupak.

Uslužno orijentirani pristup

SOA pristup za učinkovitu automatizaciju poslovnih procesa zahtijeva:

  • Standardizirani način za izlaganje i pristup funkcijama aplikacija kao usluga
  • Infrastruktura sabirnice poduzeća za komunikaciju i upravljanje uslugama, uključujući presretanje poruka, usmjeravanje, transformaciju itd.
  • Specijalizirani jezik za sastavljanje izloženih funkcionalnosti aplikacija u poslovne procese

Prvi zahtjev ispunjava najnovija distribuirana arhitektura - web usluge. Drugi zahtjev ispunjava ESB (poslovna sabirnica usluga), koji pruža podršku za centralizirano, deklarativno i dobro koordinirano upravljanje uslugama i njihovim komunikacijama. Treći zahtjev, sastav usluga u procese, ispunjava BPEL, općenito prihvaćeni specijalizirani jezik za definiranje i izvršavanje poslovnih procesa.

Poslovni proces, kako vidi BPEL, skup je koordiniranih poziva na usluge i s njima povezanih aktivnosti koje donose rezultat, bilo unutar jedne organizacije ili u više njih. Na primjer, poslovni proces za planiranje poslovnih putovanja pozvat će nekoliko usluga. U pretjerano pojednostavljenom scenariju, poslovni proces tražit će od nas da odredimo ime zaposlenika, odredište, datume i ostale detalje putovanja. Tada će postupak pozvati web uslugu za provjeru statusa zaposlenika. Na temelju statusa zaposlenika odabrat će odgovarajuću putnu klasu. Tada će se pozvati na web usluge nekoliko zrakoplovnih kompanija (poput American Airlinesa, Delta Airlinesa itd.) Kako bi provjerili cijenu avionskih karata i kupili onu s najnižom cijenom.

Za klijente će BPEL postupak izložiti svoju funkcionalnost na isti način kao i bilo koja druga web usluga. Iz perspektive klijenta izgledat će točno kao bilo koja druga web usluga. To je važno i korisno, jer nam omogućuje da usluge složimo u jednostavne procese, jednostavne procese u složenije procese itd. To također znači da će svaki BPEL postupak biti opisan WSDL-om (jezikom opisa web usluga).

Temeljni koncepti

BPEL je jezik zasnovan na XML-u. BPEL postupak sastoji se od koraka. Svaki se korak naziva aktivnost. BPEL podržava primitivne i strukturne aktivnosti. Primitivne aktivnosti predstavljaju osnovne konstrukcije i koriste se za uobičajene zadatke, poput onih dolje navedenih:

  • Pozivanje web usluga, korištenje
  • Čekajući zahtjev, koristeći
  • Manipuliranje varijablama podataka, pomoću
  • Ukazivanje na greške i iznimke, korištenje itd.

Tada te aktivnosti možemo kombinirati u složenije algoritme koji određuju korake poslovnog procesa. Da bi kombinirao primitivne aktivnosti, BPEL podržava nekoliko strukturnih aktivnosti. Najvažnije su:

  • Slijed ( ) za definiranje skupa aktivnosti koje će se pozivati ​​u poredanom slijedu
  • Tok ( ) za definiranje skupa aktivnosti koji će se paralelno pozivati
  • Konstrukcija slučaja-sklopke ( ) za implementaciju grana
  • While ( ) za definiranje petlji itd.

Kao što ćemo vidjeti, BPEL se ne razlikuje toliko od programskih jezika, kao što je Java. Ali vidjet ćemo da se BPEL razlikuje od Jave i podržava karakteristike poslovnih procesa. BPEL također nudi rukovatelje pogreškama i kompenzacijama, rukovatelje događajima i skupove korelacije. Pruža sredstva za izražavanje složenih paralelnih tokova. Također olakšava pozivanje asinkronih operacija i čekanje povratnih poziva.

BPEL procesi zahtijevaju runtime okruženje - BPEL poslužitelj, koji nam daje dobru kontrolu nad njihovim izvršavanjem. Uobičajeno, BPEL poslužitelji pružaju kontrolu nad instancama procesa koje se izvršavaju i onima koje su završile. Podržavaju dugotrajne procese i mogu dehidrirati stanje procesa radi uštede resursa. Neki poslužitelji pružaju kontrolu nad procesnim aktivnostima i omogućuju njihovo nadgledanje. Konačno, pomoću BPEL poslužitelja svi su naši procesi raspoređeni centralno, što pojednostavljuje održavanje. Sve to čini BPEL poslužitelj preferiranim okruženjem za izvođenje i upravljanje procesima.

Odabir pravog BPEL poslužitelja može biti prilično težak, jer postoji nekoliko izbora. Neki od najpopularnijih BPEL poslužitelja koji se temelje na Javi EE (novo Sunčevo ime za J2EE) uključuju Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration i AquaLogic. Dostupna su i najmanje četiri BPEL poslužitelja otvorenog koda: ActiveBPEL Engine, FiveSight PXE, bexee i Apache Agila.

Primjer postupka

Pogledajmo sada primjer BPEL postupka za poslovna putovanja koji smo gore opisali. Razvit ćemo asinkroni postupak koji će koristiti sinkroni poziv za provjeru statusa putovanja zaposlenika i dva asinkrona poziva za utvrđivanje cijena avionskih karata. Donja slika prikazuje ukupnu strukturu našeg procesa. S lijeve strane vidimo klijenta koji poziva postupak. Proces prvo poziva web uslugu statusa putovanja zaposlenika. Tada se istovremeno i asinkrono poziva na web usluge obje zrakoplovne tvrtke. To znači da će postupak morati implementirati operaciju povratnog poziva (i vrstu luke), putem koje će zrakoplovne tvrtke vratiti potvrdu o letačkoj karti. Konačno, postupak klijentu vraća najbolju ponudu zrakoplovnih karata. U ovom primjeru, radi održavanja jednostavnosti, nećemo primijeniti nikakvo rješavanje kvarova,što je presudno u stvarnim scenarijima.

Napišimo sada BPEL kod. Počinjemo s deklaracijom procesa - korijenskim elementom, gdje definiramo ime procesa i prostore imena:

Dalje, moramo definirati partnerske veze. Partnerske veze definiraju različite strane koje komuniciraju s BPEL postupkom. To uključuje sve web usluge na koje će se pozivati ​​i klijenta postupka. Svaka partnerska veza navodi do dva atributa: myRolekoji ukazuje na ulogu samog poslovnog procesa i partnerRolekoji ukazuje na ulogu partnera. U našem primjeru definiramo četiri partnerske veze:

Da bismo pohranili poruke i preoblikovali ih i transformirali, trebamo varijable. Obično koristimo varijablu za svaku poruku poslanu na web usluge i primljenu od njih. U našem primjeru trebat će nam nekoliko varijabli. Za svaku varijablu moramo odrediti vrstu. Možemo koristiti tip poruke WSDL, jednostavan tip XML sheme ili element XML sheme. U našem primjeru koristimo WSDL vrste poruka za sve varijable:

Sada smo spremni napisati glavno tijelo procesa. Sadrži samo jednu aktivnost na najvišoj razini. Obično je to ono što nam omogućuje da definiramo nekoliko aktivnosti koje će se obavljati uzastopno. Unutar slijeda prvo odredimo ulaznu poruku koja započinje poslovni proces. To radimo s konstruktom, koja čeka odgovarajuću poruku. U našem slučaju, ovo je TravelRequestporuka. Unutar konstrukcije ne određujemo poruku izravno. Umjesto toga, specificiramo partnersku vezu, vrstu porta, naziv operacije i, prema želji, varijablu koja sadrži primljenu poruku za posljedične operacije. Prijem poruke povezujemo s klijentskim partnerom i čekamo da se TravelApprovaloperacija pozove na tipu porta TravelApprovalPT. Primljenu poruku pohranjujemo uTravelRequest varijabla:

Dalje, moramo se pozvati na web-uslugu statusa zaposlenika. Prije toga moramo pripremiti ulaz za ovu web uslugu. Takvu poruku možemo konstruirati kopiranjem dijela poruke zaposlenika koji je klijent poslao. Sada se možemo pozvati na web-uslugu statusa zaposlenika. Sinkronizirano se pozivamo, za što koristimo aktivnost. Koristimo employeeTravelStatuspartnersku vezu i pozivamo se na EmployeeTravelStatusoperaciju na EmployeeTravelStatusPTtipu porta. Pripremili smo ulaznu poruku u EmployeeTravelStatusRequestvarijabli. Budući da se radi o sinkronom pozivu, poziv čeka odgovor i pohranjuje ga u EmployeeTravelStatusResponsevarijablu:

Sljedeći je korak pozivanje obje web usluge zrakoplovnog prijevoznika. Opet, prvo pripremamo potrebnu ulaznu poruku (koja je jednaka za obje web usluge). Izvršit ćemo istodobne asinkrone pozive. Da bi izrazio istodobnost, BPEL pruža aktivnost. Pozivanje svake web usluge sastojat će se od dva koraka:

  1. Aktivnost se koristi za asinkroni prizivanje
  2. Aktivnost se koristi čekati za povratni poziv

Obično grupiramo obje aktivnosti. Dva poziva se razlikuju samo u nazivu partnerske veze. AmericanAirlinesZa jedno i DeltaAirlinesza drugo koristimo :

...