Je kunt natuurlijk Java-code schrijven, of Unix-scripts die een reeks processen besturen — zoals ook een verzekeringsmakelaar doet, wanneer hij een aantal webtoepassingen gebruikt — maar dat is een arbeidsintensief proces en de code zou waarschijnlijk bijzonder log zijn. Met een bpel-toepassing kan echter een abstractielaag worden gecreëerd, die alle verschillende stappen beheert en met elkaar verbindt.

Gezeten aan een grafische gebruikersinterface van een bpel-ontwerper kan een manager (zoals de verzekeringsmakelaar) een bedrijfsproces definiëren dat onafhankelijk is van de onderliggende toepassingen. Als er dan wijzigingen in de toepassingen worden aangebracht, kan de schikking van deze toepassingen in de bpel-interface hetzelfde blijven. Mocht het businessplan van de verzekeraar veranderen, dan kan hij de processen anders neerzetten, eventueel nieuwe toevoegen of ongewenste processen verwijderen, en dat allemaal binnen de grafische gebruikersinterface.

Als men een gegenereerde bpel-code wil uitvoeren via een gui of door een xml-programmer, wordt de code geparsed door een bpel-engine die ongeveer dezelfde parsingtaak uitvoert als andere xml-interpreters. Elk uitgevoerd proces wordt gekenmerkt door een wdsl-document (web services description language), en de berichten worden via het web verzonden via het soap-protocol (simple object access protocol). Processen die beschikbare webservices opzoeken kunnen de uddi-directory (universal description, discovery and integration) gebruiken.

Bpel is voor het definiëren van bedrijfsprocessen voorzien van uiteenlopende xml-constructs, zoals 'partners', definities van de actoren in een zakelijke transactie; 'containers', definities van de berichten die moeten worden verzonden; 'operations', definities van het type webservices dat nodig is; en 'port types', definities van het type webserviceverbindingen dat nodig is voor operations.

De mogelijkheden van bpel gaan verder dan de traditionele, definitiegebaseerde xml-typen. Door processen te definiëren, wordt het onderscheid tussen xml — een definitietaal — en uitvoerbare talen als Java en Unix-shellscripts vager; vandaar het woord 'execution' (uitvoering) in de naam.

Voor het definiëren van de manier waarop processen moeten worden uitgevoerd heeft bpel xml-definities of -opdrachten die de volgorde van operations, het lussen van operations en de synchrone en asynchrone vereisten voor operations bepalen. (Synchrone operations blokkeren aanvragers totdat een aanvraag wordt gehonoreerd of geweigerd. Asynchrone operations staan aanvragers toe door te gaan zonder op een reactie te hoeven wachten.) Bpel heeft ook opdrachten die foutcondities kunnen afhandelen en operations ongedaan kunnen maken.

Een bpel-programma voor een verzekeraar vraagt bijvoorbeeld eerst financiële gegevens van een klant aan, loopt door aanbiedingen van verzekeringsbedrijven heen die via een uddi-zoekactie zijn gevonden (sommige aanbiedingen kunnen een tijdelijke geldigheidswaarde hebben) en legt de klant uiteindelijk een pakket voor. Als zich een fout voordoet of als de klant het aanbod afwijst, zelfs nadat dit voorlopig is geaccepteerd, maakt het bpel-programma de gewenste aanpassingen.

Bij het definiëren van bpel zijn verschillende bedrijven betrokken geweest, waarvan vele al eens eerder een bijdrage hebben geleverd aan de introductie van standaarden voor het gebruik van webservices. Dat zijn onder andere Adobe Systems, Avaya, BEA Systems, Booz Allen Hamilton, Electronic Data Systems, Hewlett-Packard, NEC, Novell, Oracle, Panacea, SAP AG en SeeBeyond Technology. IBM en Microsoft hebben echter de meeste invloed op de werking bpel. Web services flow language van IBM, dat een benadering van gerichte grafieken hanteert, en xlang van Microsoft, dat een blokstructuurbenadering gebruikt, zijn in augustus 2002 samengekomen onder auspiciën van OASIS (Organization for the Advancement of Structured Information Standards). Daaruit is een eerste concept voor de bpel-standaard voortgekomen.

Gerichte grafieken bepalen de keuzes die moeten worden gemaakt om van de ene transactiestatus naar de volgende te gaan. Financiële gegevens van klanten moeten bijvoorbeeld worden ontvangen voordat om offertes voor verzekeringen wordt gevraagd. Blokstructuurtalen bieden de programmeerflexibiliteit waaraan Java-, C- en C++-programmeurs gewend zijn.

Analisten lijken het over het algemeen met elkaar eens over de conclusie dat bpel bedrijfsprocessen zal 'dirigeren', wat betekent dat de centrale besturing van webservices in een bpel-engine zal zitten. Het protocol lijkt echter de mogelijkheid open te laten om webservices ergens in de toekomst te 'choreograferen'. Gechoreografeerde webservices reageren op elkaar zonder te worden gestuurd door een centraal besturingsprogramma. De mogelijkheid van bpel om de uitvoeringsvereistsen van een webservice te publiceren lijkt net datgene te zijn wat nodig is voor de meer decentrale visie van choreografie.

Ooit zullen bpel-engines het mogelijk maken om in drie telefoons tegelijk te praten, om hele terminalbanken in de gaten houden terwijl er in de schijnbare anarchie van de beursvloer verschillende biedingen worden uitgebracht, of om zelfs de reserveringen van vliegtickets, hotelkamers of auto's op elkaar af te stemmen. Mensen hoeven dan niet veel meer te doen dan af en toe op een muis te klikken.

Bron: Techworld