1. Vad är BPEL?
BPEL står för Business Process Execution Language. Ett antal stora företag som BEA, IBM och Microsoft tog fram BPEL-specifikationen, och det finns redan ett antal implementationer av BPEL, se
en.wikipedia.org/wiki/List_of_BPEL_engines .
Målet med BPEL är att på hög nivå modulera en affärsprocess genom att sätta samman flera webbtjänster till en stor sammansatt webbtjänst.
BPEL är ett språk som kan stödja både koordinationsprotokoll och komposition:
När BPEL konstruerades fanns bl.a. dessa syften:
- WSDL 1.1 Definiera affärspocesser som interagerar med externa entiteter via webbtjänser som definieras med WSDL 1.1.
- XML-baserat Utnyttja XML som bas. Grafisk representation och utveklingsmetod lämnas odefinierat.
2. BPEL-processen
På en hög nivå kan man säga att en BPEL-process definierar följande komponeter för en process:
- Roller : De roller (partnerLinks) som deltar i meddelandeutbytet.
- Gränssnitt: De gränssnitt (WSDL-portTypes) som måste stödjas av de olika rollerna och av processen självt.
- Orkestreringen: Hur processen orkesteras.
- Korreleringen: Hur meddelanden kan routas till rätt kompositionsinstans.
Bilden nedan ger exempel på olika komponenter i en BPEL-process:
3. BPELs komponentmodell
Komponentmodellen för BPEL kan beskrivas på följande sätt:
- Aktiviteter: BPELs komponentmodell består av aktiviteter. En aktivitet är kompositionens minsta beståndsdel. En aktivitet kan vara av två typer: Enkla ("Basic") eller strukturerad ("Structured").
- Operationer på aktiviteter: BPEL definerar en mängd operationer som opererar på aktiviteter. Denna typ operationer kallas strukturerade aktiviteter, och är alltså en aktivitet i sig.
- portType: BPEL förutsätter att de ingående webbtjänsernas gränssnitt beskrivs av WSDL-portTypes och att interaktionen med webbtjänsterna genomförs genom att man skickar meddelanden fram och tillbaka.
BPELs orkestreringsmodell beskrivs av BPELs enkla och strukturerade aktiviteter.
4. BPEL-processens livscykel
Livscykeln är enkel:
- Processinstansen skapas: Detta sker direkt då ett meddelande anländer, därför måste en process starta med en aktivitet som kan ta emot det inkommande meddelandet (pick eller receive).
- Processinstansen försvinner: Detta sker om processen har kört klart, avslutats av en användare (terminate) eller ett fel har uppkommit.
5. Val av webbtjänst (partnerLink)
BPEL beskrivs som en kompsition av abstrakta tjänster. Fördelen med att orkestrera tjänster på en abstrakt nivå är att det blir lättare att byta ut den konkreta tjänsten utan att modifiera själva processen.
- partnerLink: I BPEL används elementet partnerLink för att koppla loss de faktiska tjänsterna från BPEL-koden. I BPEL-koden används partnerLink-namnet för att referera till själva tjänsten.
partnerLink-elementet refererar till en partnerLinkType
- partnerLinkType: Detta element kan ha en eller två (namngivna) roller. Rollen innehåller ett portType-element som refererar till en WSDL-portType. partnerLinkType-elementen defineras ofta i en egen fil utanför själva BPEL-processen, detta för att ytterligare separera själva affärsprocessen från dess faktiska implementation.
Hur man ska mappa webbtjänstens slutpunkt ("endpoint") till elementet partnerLink beskrivs inte i BPEL-specifikationen. Det är alltså upp till leverantören att lösa detta problem. Här finns minst två olika strategier:
- statisk bindning: Vid sjösättning av BPEL-processen binds varje slutpunkt till en partnerLink en gång för alla.
- dynamisk bindning: För dynamisk bindning använder BPEL konceptet endpoint reference som definieras i WS-Addressing-specifikationen, se nedan...
En endpoint reference innehåller följande:
- slutpunkten: Slutpunktens adress.
- referensparametrar: Eventuellt definieras preferensparametrar.
- element: Eventuellt definieras element som används för att identifiera WSDL-portType, service och port för slutpunkten.
- policy: Eventuellt definieras policies för slutpunkten.
6. Datahantering
Datahanteringen kan sammanfattas på följande sätt:
- BPEL använder variabler för att hantera kontrolldata.
- Väl definierade kan en variabler fungera som inparameter eller utparameter till en operation eller användas i någon villkorssats.
- En variabel initieras genom assign eller genom att tilldelas värdet från ett inkommande meddelande.
- Variabler är serialiserade så att de inte samtidigt ska refereras av samtidiga processer.
7. Enkla aktiviteter
Vi har följande enkla aktiviteter:
| Enkel aktivitet | | Beskrivning |
|---|
| invoke | | Anropar en operation på en WSDL-portType. |
| receive | | Inväntar ett meddelande från en partner. |
| reply | | Returnerar ett svar på ett meddelande som tagits emot av receive. |
| terminate | | Avslutar hela processen. |
| throw | | Kastar ett undantag inifrån en process. |
| assign | | Tilldelar ett värde till en variabel. |
| wait | | Väntar en specifik tid, eller till en tidpunkt. |
| empty | | Inget. |
| compensate | | Startar en kompensation för en lyckad exekvering av grupp av aktiviteter. |
8. Strukturerade aktiviteter
Strukturerad aktivitet låter dig specifiera en samling av nästlade aktiviteter och den ordning de ska köras, se nedan:
| Strukturerad aktivitet | | Beskrivning |
|---|
| sequence | | Specifierar en sekvens av aktiviteter. |
| flow | | Specifierar en samling av aktiviteter som kan utföras parallellt. |
| switch | | Som switch i Java. |
| while | | En loop. |
| pick | | En av många grenar exekveras då ett passande meddelande anländer eller vi får en timeout. |
| scope | | Specifierar ett område där aktivitererna inom detta område har sina egna variabler, correlation sets och handlers. |
9. flow och link
Aktiviteten flow låter andra aktiviteter exekvera parallellt. Aktiviteter i en flow-aktivitet kan länkas samman med link-kommandot. Nedan beskrivs hur link fungerar i några punkter:
- source-target: En länk mellan aktiviteter har ett source-aktivitet och en target-aktivitet. Source-aktiviteten måste kört klart innan target-aktiviteten kan starta.
- transition:
- fork-aktivitet: Om en aktivitet är source för många länkar kallas denna en fork-aktivitet.
- join-aktivitet: Om en aktivitet är target för många länkar kallas denna för join-aktivitet.
Om en aktivitet i ett flow inte är länkad startar den direkt, så fort flow aktiveras.
10. Undantag i BPEL
Fel kan inträffa på följande sätt:
- Fel från webbtjänst: Ett fel returneras från en webbtjänst.
- Fel som kastas: Ett fel kastas explicit i processens logik.
- Fel som upptäcks BPEL-motorn: Ett fel påträffas av BPEL-motorn.
Mest intressant för oss är situation 3. Nedan listas olika situationer som resulterar i att ett BPEL-standardfel kastas:
- mismatchedAssignmentFailure: Inkompatibla typer vid assign.
- forcedTermination: Fel i scope
- correlationViolation: Innehåll i ett meddelande matchar inte "correlation data".
- uninitializedVariable: Man försöker använda en oinitialiserad del av en meddelandevariabel.
- invalidReply: Man försöker exekvera reply, trots att receive inte har körts.