BPEL of state transitions?

Door de komst van de service oriented architecture is de interesse voor business process modellering fors toegenomen. Zeker nu we met talen als BPEL (Business Process Execution Language) deze business processen formeel kunnen uitschrijven en er tools zijn waarmee we ze kunnen verwerken, de zogenaamde BPEL-engines. Maar is BPEL wel voor elke situatie ideaal? 

De bouwstenen van BPEL (en ook van BPEL-achtige talen) zijn gebaseerd op de bouwstenen van klassieke, procedurele programmeertalen. We kunnen met BPEL bijvoorbeeld condities en lussen programmeren en we kunnen aan variabelen een waarde toekennen. Het effect is dat een BPEL-proces een serieel karakter heeft. In feite is het een stappenplan. Voer eerst stap één uit, dan stap twee, als de conditie waar is dan stap drie en anders stap vier. Uiteraard kunnen er zaken parallel uitgevoerd worden, maar het blijft een serieel stappenplan.
 
Een stappenplan zal voor vele business processen meer dan geschikt zijn, maar niet voor alle! Wat gebeurt er bijvoorbeeld als ineens van dat seriële stappenplan wordt afgeweken? Wat als er ineens op dit proces wordt ingebroken? Als daar in het BPEL-model niet op geanticipeerd wordt, dan hebben we een probleem.
 
Er zijn situaties die zo event-driven van aard zijn dat het werken met seriële stappenplannen geen zin heeft. BPEL is dan niet de geschikte taal. Neem bijvoorbeeld het begrip vlucht van een fictieve vliegtuigmaatschappij genaamd HappyAir. Veronderstel dat HappyAir een vlucht inplant voor de komende zomer van Amsterdam naar San Francisco. Eerst zal een vliegtuigmodel, bijvoorbeeld een Boeing 777, aan de vlucht toegekend moeten worden. Dit is het eerste event dat op deze specifieke vlucht uitgevoerd wordt en daarmee de status van die vlucht verandert. Vervolgens kan het zijn dat er enkele piloten worden toegewezen en daarna een crew bestaande uit stewards en stewardessen. Dan worden er door klanten reserveringen voor de stoelen en voor vracht gemaakt. Dit zijn allemaal events die in een willekeurige volgorde aangeleverd worden en door HappyAir uitgevoerd moeten worden. Veronderstel dat om bepaalde redenen besloten wordt een ander vliegtuigmodel in te zetten. Alles verandert hierdoor. Bijvoorbeeld, andere piloten en een andere crew moet gekozen worden en passagiers zullen verplaatst moeten worden.
 
We kunnen hier wel een BPEL-model voor maken, maar een State Transition Diagram (STD) zal veel eenvoudiger en veel geschikter zijn. Het modelleren van deze event-driven omgeving voor een vlucht zal met een STD passender zijn. De mogelijke events die de status van een vlucht kunnen veranderen, worden dan geïnventariseerd en gedefinieerd. Deze events mogen dan op elk moment afgevuurd worden. Geen seriële, maar een event-driven status-georienteerde definitie.
 
Uiteraard vereist dit wel dat we engines hebben die in staat zijn deze STD's te verwerken. Laten we ze state transition diagram engines noemen. Dus wat een BPEL-engine is voor BPEL, dat is een STD-engine voor een STD. Sommige leveranciers, zoals IBM, ondersteunen momenteel naast BPEL een STD-engine. Het is wel interessant om te weten dat achter de schermen dit specifieke product van IBM elke STD omzet naar BPEL. Dus deze wordt uiteindelijk wel door de BPEL-engine verwerkt.
 
Het is niet dat BPEL geen nut heeft. Voor de wat meer seriële situaties is BPEL een prima optie. Maar ik denk dat we realistisch moeten zijn en de beperkingen van BPEL moeten accepteren en het daar moeten inzetten waar het geschikt is: in de niet event-driven omgevingen. In event-driven omgevingen zijn STD's echter aan te bevelen en vormen een verrijking van de service oriented architecture. Hopelijk zullen vele leveranciers van Enterprise Service Bussen deze niet-seriële toepassing aan hun producten toevoegen.

 
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.