BPEL (Business Process Execution Language) er blevet en af de vigtigste teknologier i SOA (serviceorienteret arkitektur) og muliggør nem og fleksibel sammensætning af tjenester i forretningsprocesser. BPEL er især vigtig, fordi den introducerer et nyt koncept i applikationsudvikling - programmering-i-det-store. Dette koncept giver os mulighed for hurtigt at udvikle processer ved at definere den rækkefølge, i hvilken tjenester der skal påberåbes. På denne måde bliver applikationer (og informationssystemer) mere fleksible og kan bedre tilpasse sig ændringer i forretningsprocesser.
Forretningsprocesser er normalt af dynamisk karakter. Virksomheder er nødt til at forbedre og ændre, handle agil, optimere og tilpasse processer for at forbedre hele virksomhedens lydhørhed. Enhver ændring og forbedring i en forretningsproces skal afspejle sig i applikationer, der yder support til dem. Selv om dette krav måske ikke lyder meget vanskeligt at opfylde, viser den virkelige situation os et andet billede. Ændring og ændring af applikationer er ofte et vanskeligt job, der kræver tid. Derfor kan applikationer ikke reagere med det samme på ændringer i forretningsprocesser - snarere kræver det noget tid at implementere, teste og implementere ændringerne.
At gøre informationssystemer mere fleksible og tilpasse sig ændringer og bedre tilpasset forretningsprocesser er SOAs største løfte. I denne artikel viser jeg, hvorfor BPEL er så vigtig, og demonstrerer, hvordan man udvikler en BPEL-proces.
Serviceorienteret tilgang
SOA-tilgangen til effektiv automatisering af forretningsprocesser kræver:
- Standardiseret måde at afsløre og få adgang til funktionaliteten af applikationer som tjenester
- Enterprise-businfrastruktur til kommunikation og styring af tjenester, herunder aflytning af meddelelser, routing, transformation osv.
- Specialiseret sprog til sammensætning af eksponerede funktioner i applikationer i forretningsprocesser
Det første krav er opfyldt af den nyeste distribuerede arkitektur - webservices. Det andet krav er opfyldt af ESB (enterprise service bus), som yder support til centraliseret, deklarativ og velkoordineret administration af tjenester og deres kommunikation. Det tredje krav, sammensætning af tjenester i processer, er opfyldt af BPEL, det almindeligt accepterede specialsprog til definition og udførelse af forretningsprocesser.
En forretningsproces, som BPEL ser, er en samling af koordinerede serviceopkald og relaterede aktiviteter, der giver et resultat, enten inden for en enkelt organisation eller på tværs af flere. For eksempel påkalder en forretningsproces til planlægning af forretningsrejser flere tjenester. I et overforenklet scenario kræver forretningsprocessen, at vi angiver medarbejdernavn, destination, datoer og andre rejseoplysninger. Derefter påkalder processen en webservice for at kontrollere medarbejderstatus. Baseret på medarbejderstatus vælger den den relevante rejseklasse. Derefter påkalder det webtjenester fra flere flyselskaber (såsom American Airlines, Delta Airlines osv.) For at kontrollere flybilletprisen og købe den med den laveste pris.
For klienterne afslører BPEL-processen dens funktionalitet på samme måde som enhver anden webtjeneste. Fra klientperspektivet vil det se ud som enhver anden webtjeneste. Dette er vigtigt og nyttigt, da det giver os mulighed for at komponere tjenester i enkle processer, enkle processer i mere komplekse processer osv. Dette betyder også, at hver BPEL-proces vil blive beskrevet med en WSDL-beskrivelse (Web Services Description Language).
Kernekoncepter
BPEL er et XML-baseret sprog. En BPEL-proces består af trin. Hvert trin kaldes en aktivitet. BPEL understøtter primitive aktiviteter og strukturaktiviteter. Primitive aktiviteter repræsenterer grundlæggende konstruktioner og bruges til almindelige opgaver, såsom dem, der er anført nedenfor:
- Påberåbe sig webtjenester ved hjælp af
- Venter på anmodningen ved hjælp af
- Manipulering af datavariabler ved hjælp af
- Angiver fejl og undtagelser ved hjælp af
, etc.
Vi kan derefter kombinere disse aktiviteter i mere komplekse algoritmer, der specificerer trinene i en forretningsproces. For at kombinere primitive aktiviteter understøtter BPEL flere strukturaktiviteter. De vigtigste er:
- Sekvens (
) til at definere et sæt aktiviteter, der påberåbes i en ordnet rækkefølge - Flow (
) til at definere et sæt aktiviteter, der påberåbes parallelt - Case-switch konstruktion (
) til implementering af filialer - Mens (
) til at definere sløjfer osv.
Som vi vil se, er BPEL ikke så forskellig fra programmeringssprog, såsom Java. Men vi vil se, at BPEL adskiller sig fra Java og understøtter egenskaberne ved forretningsprocesser. BPEL leverer også fejl- og kompensationsbehandlere, begivenhedsbehandlere og korrelationssæt. Det giver midler til at udtrykke komplekse parallelle strømme. Det gør det også relativt let at ringe til asynkrone operationer og vente på tilbagekald.
BPEL-processer kræver et runtime-miljø - en BPEL-server, der giver os god kontrol over deres udførelse. BPEL-servere giver typisk kontrol over procesforekomster, der udføres, og dem, der er færdige. De understøtter langvarige processer og kan dehydrere processtilstand for at spare ressourcer. Nogle servere giver kontrol over procesaktiviteter og tillader overvågning af dem. Endelig distribueres alle vores processer centralt ved hjælp af en BPEL-server, hvilket forenkler vedligeholdelsen. Alt dette gør BPEL-serveren til det foretrukne miljø til kørsel og styring af processer.
At vælge den rigtige BPEL-server kan dog være ret vanskelig, da der er flere valg. Nogle af de mest populære BPEL-servere, der er baseret på Java EE (Suns nye navn til J2EE), inkluderer Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration og AquaLogic. Der er også mindst fire open source BPEL-servere tilgængelige: ActiveBPEL Engine, FiveSight PXE, bexee og Apache Agila.
Eksempel på proces
Lad os nu se på et eksempel på en BPEL-proces til forretningsrejser, som vi har beskrevet ovenfor. Vi udvikler en asynkron proces, der bruger et synkront opkald til at kontrollere medarbejderens rejsestatus og to asynkrone opkald for at erhverve flybilletpriserne. Figuren nedenfor viser den overordnede struktur for vores proces. Til venstre ser vi klienten, der påberåber sig processen. Processen kalder først medarbejderens rejsestatus på webservicen. Derefter påberåber det sig begge luftfartsselskabers webtjenester samtidigt og asynkront. Dette betyder, at processen bliver nødt til at implementere tilbagekaldsoperationen (og en porttype), hvorigennem luftfartsselskaberne returnerer flybilletbekræftelsen. Endelig returnerer processen det bedste flybilletilbud til klienten. For at opretholde enkelheden implementerer vi ikke dette fejlhåndtering i dette eksempel, hvilket er afgørende i virkelige scenarier.
Lad os nu skrive BPEL-koden. Vi starter med proceserklæringen — rodelementet, hvor vi definerer procesnavnet og navneområdet:
Dernæst skal vi definere partnerlinkene. Partnerlink definerer forskellige parter, der interagerer med BPEL-processen. Dette inkluderer alle webtjenester, der påberåbes, og klienten til processen. Hvert partnerlink specificerer op til to attributter: myRole der indikerer selve forretningsprocessens rolle og partnerRolle det indikerer partnerens rolle. I vores eksempel definerer vi fire partnerlinks:
For at gemme meddelelser og omformatere og transformere dem har vi brug for variabler. Normalt bruger vi en variabel til hver besked, der sendes til webtjenesterne og modtages fra dem. I vores eksempel har vi brug for et par variabler. For hver variabel skal vi specificere typen. Vi kan bruge en WSDL-meddelelsestype, en simpel XML-skema-type eller et XML-skema-element. I vores eksempel bruger vi WSDL-meddelelsestyper til alle variabler:
Nu er vi klar til at skrive hovedprocesorganet. Den indeholder kun én aktivitet på øverste niveau. Normalt er dette en der giver os mulighed for at definere flere aktiviteter, der udføres sekventielt. Inden for sekvensen specificerer vi først den inputbesked, der starter forretningsprocessen. Vi gør dette med konstruktion, som venter på den matchende besked. I vores tilfælde er det dette TravelRequest besked. Indenfor konstruktion, specificerer vi ikke meddelelsen direkte. Vi specificerer snarere partnerlinket, porttypen, operationens navn og eventuelt variablen, der indeholder den modtagne besked til efterfølgende operationer. Vi forbinder meddelelsesmodtagelsen med klientpartneren og venter på Rejsegodkendelse operation, der skal påberåbes på porttype TravelApprovalPT. Vi gemmer den modtagne besked i TravelRequest variabel:
Dernæst er vi nødt til at påkalde Employee Travel Status Web-tjenesten. Før dette er vi nødt til at forberede input til denne webtjeneste. Vi kan konstruere en sådan besked ved at kopiere den medarbejderdel af den besked, som klienten sendte. Nu kan vi påberåbe sig webtjenesten Employee Travel Status. Vi laver en synkron påkaldelse, som vi bruger aktivitet. Vi bruger medarbejderRejsestatus partnerlink og påberåbe sig MedarbejderRejsestatus drift på MedarbejderRejsestatusPT porttype. Vi har forberedt inputbeskeden i EmployeeTravelStatusRequest variabel. Fordi det er en synkron påkaldelse, venter opkaldet på svaret og gemmer det i EmployeeTravelStatusResponse variabel:
Det næste trin er at påberåbe sig begge flyselskabers webtjenester. Igen forbereder vi først den krævede inputmeddelelse (som er lig for begge webservices). Vi foretager samtidige asynkrone invokationer. For at udtrykke samtidighed leverer BPEL den aktivitet. Påkaldelsen til hver webtjeneste består af to trin:
- Det
aktivitet bruges til den asynkrone påkaldelse - Det
aktivitet bruges til at vente på tilbagekaldet
Vi bruger at gruppere begge aktiviteter. De to påkaldelser adskiller sig kun i navnet på partnerlinket. Vi bruger AmericanA Airlines for en og DeltaA Airlines for den anden:
...
