BPEL (Business Process Execution Language) har blitt en av de viktigste teknologiene i SOA (serviceorientert arkitektur) og muliggjør enkel og fleksibel sammensetning av tjenester i forretningsprosesser. BPEL er spesielt viktig fordi det introduserer et nytt konsept i applikasjonsutvikling - programmering-i-det-store. Dette konseptet gjør det mulig for oss å utvikle prosesser raskt ved å definere rekkefølgen tjenestene skal påberopes. På denne måten blir applikasjoner (og informasjonssystemer) mer fleksible og kan bedre tilpasse seg endringene i forretningsprosesser.
Forretningsprosesser er vanligvis av dynamisk karakter. Bedrifter må forbedre og modifisere, handle på en smidig måte, optimalisere og tilpasse prosesser for å forbedre responsen til hele selskapet. Hver endring og forbedring i en forretningsprosess må gjenspeiles i applikasjoner som gir støtte for dem. Selv om dette kravet kanskje ikke høres veldig vanskelig ut, viser den virkelige situasjonen oss et annet bilde. Å endre og endre applikasjoner er ofte en vanskelig jobb, som krever tid. Derfor kan applikasjoner ikke reagere øyeblikkelig på endringer i forretningsprosesser, men det tar litt tid å implementere, teste og distribuere endringene.
Å gjøre informasjonssystemer mer fleksible og tilpasse seg endringer og bedre tilpasset forretningsprosesser er SOAs største løfte. I denne artikkelen viser jeg hvorfor BPEL er så viktig og demonstrerer hvordan man kan utvikle en BPEL-prosess.
Serviceorientert tilnærming
SOA-tilnærmingen for effektiv automatisering av forretningsprosesser krever:
- Standardisert måte å avsløre og få tilgang til funksjonaliteten til applikasjoner som tjenester
- Bussbussinfrastruktur for kommunikasjon og administrasjon av tjenester, inkludert avlytting av meldinger, ruting, transformasjon, etc.
- Spesialisert språk for sammensetning av eksponerte funksjoner til applikasjoner i forretningsprosesser
Det første kravet oppfylles av den nyeste distribuerte arkitekturen - webtjenester. Det andre kravet oppfylles av ESB (enterprise service bus), som gir støtte for sentralisert, deklarativ og godt koordinert administrasjon av tjenester og deres kommunikasjon. Det tredje kravet, sammensetning av tjenester i prosesser, oppfylles av BPEL, det allment aksepterte spesialspråket for definisjon og utføring av forretningsprosesser.
En forretningsprosess, sett av BPEL, er en samling av koordinerte tjenesteanrop og relaterte aktiviteter som gir et resultat, enten i en enkelt organisasjon eller på tvers av flere. For eksempel vil en forretningsprosess for planlegging av forretningsreiser påkalle flere tjenester. I et forenklet scenario vil forretningsprosessen kreve at vi spesifiserer ansattens navn, destinasjon, datoer og andre reiseopplysninger. Deretter vil prosessen påkalle en webtjeneste for å kontrollere ansattes status. Basert på ansattes status, vil den velge riktig reiseklasse. Da vil den påkalle webtjenester til flere flyselskaper (som American Airlines, Delta Airlines, etc.) for å sjekke flybillettprisen og kjøpe den med lavest pris.
For klientene vil BPEL-prosessen avsløre funksjonaliteten på samme måte som andre webtjenester. Fra klientperspektivet vil det se ut som alle andre webtjenester. Dette er viktig og nyttig, ettersom det lar oss komponere tjenester i enkle prosesser, enkle prosesser i mer komplekse prosesser, og så videre. Dette betyr også at hver BPEL-prosess vil bli beskrevet med en WSDL-beskrivelse (Web Services Description Language).
Kjernekonsepter
BPEL er et XML-basert språk. En BPEL-prosess består av trinn. Hvert trinn kalles en aktivitet. BPEL støtter primitive aktiviteter og strukturaktiviteter. Primitive aktiviteter representerer grunnleggende konstruksjoner og brukes til vanlige oppgaver, for eksempel de som er oppført nedenfor:
- Påkalle webtjenester ved hjelp av
- Venter på forespørselen ved hjelp av
- Manipulere datavariabler ved hjelp av
- Angir feil og unntak ved bruk av
, etc.
Vi kan deretter kombinere disse aktivitetene i mer komplekse algoritmer som spesifiserer trinnene i en forretningsprosess. For å kombinere primitive aktiviteter støtter BPEL flere strukturaktiviteter. De viktigste er:
- Sekvens (
) for å definere et sett med aktiviteter som vil bli påkalt i en ordnet sekvens - Flyt (
) for å definere et sett med aktiviteter som vil påberopes parallelt - Case-switch-konstruksjon (
) for implementering av filialer - Samtidig som (
) for å definere løkker osv.
Som vi vil se, er BPEL ikke så forskjellig fra programmeringsspråk, som Java. Men vi vil se at BPEL skiller seg fra Java og støtter egenskapene til forretningsprosesser. BPEL tilbyr også feil- og kompensasjonsbehandlere, hendelsesbehandlere og korrelasjonssett. Det gir midler til å uttrykke komplekse parallelle strømmer. Det gjør det også relativt enkelt å ringe asynkrone operasjoner og vente på tilbakeringing.
BPEL-prosesser krever et kjøretidsmiljø - en BPEL-server, som gir oss god kontroll over utførelsen. Vanligvis gir BPEL-servere kontroll over prosessforekomster som kjøres og de som er ferdige. De støtter langvarige prosesser og kan dehydrere prosesstilstand for å spare ressurser. Noen servere gir kontroll over prosessaktiviteter og tillater overvåking. Til slutt, ved hjelp av en BPEL-server, blir alle våre prosesser distribuert sentralt, noe som forenkler vedlikeholdet. Alt dette gjør BPEL-serveren til det foretrukne miljøet for å kjøre og administrere prosesser.
Å velge riktig BPEL-server kan imidlertid være ganske vanskelig, da det er flere valg. Noen av de mest populære BPEL-serverne som er basert på Java EE (Suns nye navn for J2EE) inkluderer Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration og AquaLogic. Det er også minst fire BPEL-servere med åpen kildekode tilgjengelig: ActiveBPEL Engine, FiveSight PXE, bexee og Apache Agila.
Eksempel på prosess
La oss nå se på et eksempel på BPEL-prosesser for forretningsreiser som vi har beskrevet ovenfor. Vi vil utvikle en asynkron prosess som bruker en synkron samtale for å sjekke den ansattes reisestatus og to asynkrone samtaler for å skaffe seg flybillettprisene. Figuren nedenfor viser den generelle strukturen i prosessen vår. Til venstre ser vi klienten som påkaller prosessen. Prosessen kaller først den ansattes reisestatus nettjeneste. Deretter påkaller den begge flyselskapenes webtjenester samtidig og asynkront. Dette betyr at prosessen må implementere tilbakeringingsoperasjonen (og en porttype), der flyselskapene vil returnere bekreftelsen på flybilletten. Til slutt returnerer prosessen det beste flybillettilbudet til klienten. I dette eksemplet, for å opprettholde enkelhet, vil vi ikke implementere noen feilhåndtering, noe som er avgjørende i virkelige scenarier.
La oss nå skrive BPEL-koden. Vi starter med prosesserklæringen — rotelementet, der vi definerer prosessnavnet og navnerommene:
Deretter må vi definere partnerkoblingene. Partnerkoblinger definerer forskjellige parter som samhandler med BPEL-prosessen. Dette inkluderer alle webtjenester som vil bli påkalt og klienten til prosessen. Hver partnerkobling spesifiserer opptil to attributter: min rolle som indikerer rollen til selve forretningsprosessen og partnerRolle som indikerer rollen til partneren. I vårt eksempel definerer vi fire partnerkoblinger:
For å lagre meldinger og for å reformatere og transformere dem, trenger vi variabler. Vanligvis bruker vi en variabel for hver melding som sendes til webtjenestene og mottas fra dem. I vårt eksempel trenger vi noen variabler. For hver variabel må vi spesifisere typen. Vi kan bruke en WSDL-meldingstype, en enkel XML-skjema-type eller et XML-skjema-element. I vårt eksempel bruker vi WSDL-meldingstyper for alle variabler:
Nå er vi klare til å skrive hovedprosessorganet. Den inneholder bare én aktivitet på toppnivå. Vanligvis er dette en som lar oss definere flere aktiviteter som skal utføres sekvensielt. Innenfor sekvensen spesifiserer vi først inndatameldingen som starter forretningsprosessen. Vi gjør dette med konstruere, som venter på den matchende meldingen. I vårt tilfelle er dette TravelRequest beskjed. Innen konstruere, spesifiserer vi ikke meldingen direkte. I stedet spesifiserer vi partnerkoblingen, porttypen, operasjonsnavnet og eventuelt variabelen som inneholder den mottatte meldingen for påfølgende operasjoner. Vi kobler meldingsmottaket med klientpartneren og venter på TravelApproval operasjon som skal påberopes på porttype TravelApprovalPT. Vi lagrer den mottatte meldingen i TravelRequest variabel:
Deretter må vi påkalle Employee Travel Status Web-tjenesten. Før dette må vi forberede innspillene til denne nettjenesten. Vi kan konstruere en slik melding ved å kopiere den ansattes del av meldingen som klienten sendte. Nå kan vi påberope webtjenesten Employee Travel Status. Vi lager en synkron påkalling, som vi bruker aktivitet. Vi bruker ansattTravelStatus partnerlink og påkalle EmployeeTravelStatus drift på EmployeeTravelStatusPT porttype. Vi har utarbeidet inngangsmeldingen i EmployeeTravelStatusRequest variabel. Fordi det er en synkron påkalling, venter samtalen på svaret og lagrer den i EmployeeTravelStatusResponse variabel:
Det neste trinnet er å påkalle begge flyselskapets webtjenester. Igjen forbereder vi først den nødvendige inngangsmeldingen (som er lik for begge webtjenester). Vi vil gjøre asynkrone påkallelser samtidig. For å uttrykke samtidighet tilbyr BPEL aktivitet. Påkallingen til hver webtjeneste vil bestå av to trinn:
- De
aktivitet brukes til den asynkrone påkallingen - De
aktivitet brukes til å vente på tilbakeringing
Vi bruker å gruppere begge aktivitetene. De to påkallelsene skiller seg bare ut fra navnet på partnerkoblingen. Vi bruker AmericanA Airlines for en og DeltaA Airlines for den andre:
...
