Nu marges van bedrijven onder druk staan, is het van belang bedrijfsprocessen zo efficiënt mogelijk uit te voeren en tegelijk de kwaliteit van het geleverde op peil te houden. Bpel (Business Process Execution Language) zou hierbij van nut kunnen zijn, meent een it-architect. Het is een nieuwe standaardtaal voor het beschrijven van bedrijfsprocessen die worden uitgevoerd door webdiensten. Bpel maakt het mogelijk standaard processtappen met elkaar te combineren tot een nieuw proces.
| Webdiensten Een service-georiënteerde architectuur gaat ervan uit dat applicaties herbruikbare diensten aanbieden in de vorm van services. Webdiensten zijn speciale services, die gebruik maken van internettechnologie. Belangrijke standaarden daarbij zijn XML, soap, Wsdl en uddi. XML is een uitbreidbare taal, waarin berichten kunnen worden gespecificeerd. Direct aan XML gerelateerd zijn standaarden als XML-schema en Xpath. XML-schema is bedoeld om de inhoud van XML-berichten te beschrijven. Met Xpath kunnen expressies worden gemaakt die bijvoorbeeld delen uit een XML-bericht te selecteren. Soap biedt een envelop voor XML-gebaseerde berichten, die via http of andere middleware kunnen worden verstuurd. Wsdl biedt de mogelijkheid om de interfaces van webdiensten te definiëren in de vorm van poorttypes en te binden aan protocol-specifieke poorten. Uddi biedt een ‘repository’ voor het beheren van webdiensten en hun bijbehorende meta-gegevens. Bedrijven hebben op dit moment veel aandacht voor webdiensten, omdat zij gebruik maken van open standaarden, waarbij interoperabiliteit voorop staat. |
Het zijn bedrijfsprocessen die bedrijven in staat stellen om producten en diensten te leveren aan klanten. Het verbeteren van die bedrijfsprocessen wordt dan ook steeds vaker ervaren als een belangrijke, continue activiteit om de concurrentie een stap voor te blijven. Het analyseren, modelleren, implementeren en monitoren van deze processen speelt hierbij een belangrijke rol. Informatietechnologie heeft een niet te onderschatten invloed op deze ontwikkelingen.
Ten eerste kunnen bedrijfsprocessen grotendeels geautomatiseerd worden uitgevoerd. Een servicegeoriënteerde architectuur geeft hieraan invulling door applicaties herbruikbare processtappen aan te laten bieden in de vorm van diensten (‘services’). Webdiensten zijn een specifiek soort diensten, die door een organisatie direct via intranet kunnen worden aangeboden aan andere organisatieonderdelen of via internet zelfs aan geheel andere organisaties.
Een tweede belangrijke rol van informatietechnologie ligt in het bieden van geautomatiseerde ondersteuning bij het uitvoeren van geautomatiseerde activiteiten. Er is dan ook een veelvoud aan tools, methoden en technieken beschikbaar. Het is in deze arena waar Bpel (Business Process Execution Language) gepositioneerd moet worden.
Bpel is een nieuwe standaardtaal voor het beschrijven van bedrijfsprocessen die gebaseerd zijn op webdiensten. Met Bpel is het mogelijk om standaard processtappen met elkaar te combineren tot een nieuw proces. De kracht van een dergelijke proceslaag is dat deze separaat van onderliggende applicaties kan worden gedefinieerd en gewijzigd. Het is daardoor mogelijk om relatief snel bestaande bedrijfsprocessen te wijzigen of nieuwe bedrijfsprocessen te introduceren, waarbij bestaande processtappen kunnen worden hergebruikt.
Bpel is ontwikkeld door IBM, Microsoft en BEA en bouwt voort op bestaande talen voor het beschrijven van processen, met name op Wsfl van IBM en Xlang van Microsoft. In tegenstelling tot andere procesbeschrijvingstalen is Bpel een open en royaltyvrije standaard, die volledig gebaseerd is op webdienststandaarden als XML, soap en Wsdl. In het bijzonder kun je Bpel zien als een taal om webdiensten te integreren tot een bedrijfsproces dat zelf ook weer als webdienst kan worden aangeroepen. Deze samengestelde service zal enerzijds zelf een Wsdl-interface aanbieden en anderzijds gebruik maken van de Wsdl-interfaces van onderliggende webdiensten. Het karakter van de samengestelde service kan uiteenlopen van een kortlopend proces met een beperkt aantal aanroepen, tot een zeer langlopend proces dat zelf uit een aantal subprocessen bestaat.
Er zijn verschillende toepassingsgebieden voor Bpel. Zo kan het worden gebruikt om het gemeenschappelijke deel van een proces te beschrijven dat organisatiegrenzen overschrijdt. Naast het beschrijven van dergelijke abstracte processen is het ook mogelijk om de exacte organisatiespecifieke inhoud van bedrijfsprocessen te beschrijven. Bpi-tools (business process integration) kunnen deze dan gebruiken om de processen ook daadwerkelijk uit te voeren. Bpel is daarmee in staat om alle relevante aspecten van bedrijfsprocessen te beschrijven, zoals de betrokken partijen, gegevens, activiteiten en overgangen tussen activiteiten, en de afhandeling van fouten. Met name voor langlopende activiteiten moet goed worden nagedacht over foutafhandeling, omdat activiteiten niet altijd eenvoudig kunnen worden teruggedraaid.
Servicelinks en referenties
Zoals gezegd kan Bpel worden gebruikt om de raakvlakken tussen organisaties te beschrijven. Bij het uitvoeren van organisatieoverstijgende processen zullen er berichten worden uitgewisseld tussen partijen in een bepaalde rol. Voor elk proces moet dus worden aangegeven welke rollen er bestaan en welke berichten de partners in deze rol ontvangen. Bpel kent hiervoor het begrip ‘servicelinktype’, dat een relatie tussen twee rollen aangeeft. Bij elke rol wordt aangegeven welke diensten door de andere soort rol kunnen worden aangeroepen. Partners worden later aan elkaar verbonden door aan te geven welke rol zij vervullen in een servicelinktype.
Als voorbeeld nemen we een kredietaanvraagproces, waarbij in ieder geval twee partners betrokken zijn: de kredietverlener en het Bureau Kredietregistratie (BKR) in Tiel. Deze laatste zal typisch de rol van kredietwaardigheidstoetser spelen en daarvoor een dienst aanbieden. De relatie tussen de kredietverlener en het BKR wordt gedefinieerd als servicelinktype.
Servicelinktypes en partners worden beschreven op een logisch niveau; er worden nog geen verwijzingen gemaakt naar fysieke diensten. De informatie begeeft zich dus op het niveau van Wsdl-poorttypes, die nog aan fysieke Wsdl-poorten moeten worden gebonden. Speciaal voor deze binding worden ‘servicereferenties’ gedefinieerd, die verwijzen naar de fysieke services. Voor alle partners worden automatisch van dit soort servicereferenties gegenereerd, maar het is ook mogelijk om deze servicereferenties dynamisch naar de juiste fysieke services te laten verwijzen.
Gegevensuitwisseling
Bij het uitvoeren van processen zullen gegevens worden uitgewisseld en verzameld. In Bpel worden hiervoor ‘containers’ gedefinieerd. Containers zijn gegevensstructuren die ofwel worden meegegeven in een aanroep naar een service, of het resultaat zijn van een serviceaanroep, óf gewoon intern in het proces worden gebruikt. In een kredietaanvraagproces zal bijvoorbeeld de invoer van de activiteit waarin de offerte wordt gemaakt een container zijn, die alle informatie bevat die nodig is voor het maken van de fysieke offerte.
Containers worden globaal gedefinieerd en zijn dus in het gehele proces beschikbaar. Om vanuit een activiteit toegang te krijgen tot specifieke delen in een container, is het mogelijk ‘properties’ (eigenschappen) te definiëren, die een logische naam introduceren om gegevens te manipuleren. Deze eigenschappen geven hiermee ook toegang tot applicatierelevante delen van berichten die worden uitgewisseld.
Een ander belangrijk concept in Bpel in relatie tot gegevensuitwisseling, is dat van ‘correlatie’. Het idee hierachter is dat het in veel gevallen niet voldoende is voor een proces om een bericht naar een bepaalde poort toe te sturen, aangezien het bericht betrekking heeft op een bepaalde instantie van een service met bijbehorende gegevens. Er bestaat daarom behoefte om berichten te kunnen correleren aan specifieke instanties van services. Voor dit doel biedt Bpel de mogelijkheid om ‘correlatiesets’ te definiëren. Dit zijn eigenschappen van bepaalde berichten die specifieke services kunnen identificeren. Je zou kunnen zeggen dat ze de primaire en vreemde sleutels in de uit te wisselen berichten beschrijven. Door een generiek mechanisme te bieden voor het uitwisselen van correlatiesets, kan het vinden van de juiste instanties worden gedelegeerd aan de middleware. In ons kredietaanvraagproces zullen typisch het klantnummer, de identificatie van zijn kredietfaciliteit en de kredietaanvraag deel uitmaken van de correlatieset.
Een laatste soort van gegevens die relevant zijn in een proces, zijn de ‘afgeleide gegevens’. De waarde van deze gegevens wordt bepaald aan de hand van andere gegevens. Het is daarvoor in Bpel mogelijk expressies te definiëren, waarbij Xpath de standaardtaal voor deze expressies is. Er zijn ook extra Xpath-functies gedefinieerd, die gegevens uit een container kunnen halen en de status van een link kunnen opvragen. Expressies worden bijvoorbeeld gebruikt in de definitie van een ‘property’ waarin wordt verwezen naar specifieke gegevens in een container.
Decompositie in activiteiten
De kern van Bpel is de beschrijving van de decompositie van een bedrijfsproces in activiteiten en hun onderlinge samenhang. Hiervoor zijn de mogelijkheden van het programmeertaalachtige van Xlang en de graafaspecten van Wsfl gecombineerd, waardoor een groot aantal verschillende workflowpatronen kunnen worden beschreven. Activiteiten zijn globaal in twee categorieën te verdelen: basisactiviteiten en gestructureerde activiteiten.
Basisactiviteiten zijn ondermeer het synchroon aanroepen van services en het versturen en ontvangen van berichten voor asynchrone aanroepen. In ons kredietvoorbeeld is zo’n basisactiviteit nodig om de kredietwaardigheidstoets van het BKR aan te kunnen roepen. Andere basisactiviteiten zijn het kopiëren van gegevens tussen containers, het signaleren van fouten, het voor een bepaalde periode wachten en het beëindigen van het proces.
Gestructureerde activiteiten geven de mogelijkheid om activiteiten te ‘nesten’ en in een bepaalde volgorde uit te voeren. Uiteraard kunnen gestructureerde activiteiten worden gedefinieerd die andere activiteiten sequentieel of parallel uitvoeren. Daarnaast zijn er ‘switch’- en ‘pick’-constructies, die een bepaalde activiteit uitvoeren op basis van respectievelijk condities en binnenkomende berichten. Ook is er een ‘while’-constructie, die bepaalde activiteiten blijft uitvoeren zolang een conditie geldt.
Het erfgoed van Wsfl is de mogelijkheid om tussen activiteiten ‘links’ te definiëren die een synchronisatierelatie beschrijven. Deze links leggen in feite een beperking aan de mogelijke overgangen tussen activiteiten. Er kunnen beperkingen als conditie worden gedefinieerd op de link zelf, waarbij de overgang tussen activiteiten alleen geldig is als de conditie geldt. Daarnaast is het mogelijk een conditie op de volgende activiteit te definiëren, die aangeeft welke inkomende links moeten zijn geactiveerd voordat de activiteit zelf wordt geactiveerd.
Foutafhandeling
Er kan van alles fout gaan bij het uitvoeren van bedrijfsprocessen en Bpel biedt dan ook verschillende constructies om met fouten om te gaan. Zo is het mogelijk om een fout te signaleren en als zodanig aan te merken. In het proces kunnen dan ‘faulthandlers’ (foutafhandelaars) worden gedefinieerd, die gepaste maatregelen kunnen ondernemen. Als in ons voorbeeld het maken van de offerte faalt omdat een printer offline is, dan zou een foutafhandelaar een andere printer kunnen proberen.
Speciaal voor langlopende processen is het van belang dat acties die al uitgevoerd waren toen de fout optrad, kunnen worden gecompenseerd. Het is namelijk niet realistisch om te veronderstellen dat in dit soort omstandigheden gedistribueerde transacties worden opgezet, aangezien dan gedurende langere tijd resources, zoals ‘locks’, vastgehouden moeten worden. Het enige wat je dan kunt doen, is compenserende acties definiëren die de eerder gedane transacties weer ongedaan maken. Bpel heeft ingebouwde ondersteuning voor een dergelijke compensatie. Het is zelfs mogelijk om eigen ‘compensation handlers’ te schrijven, die compenserende activiteiten kunnen uitvoeren. Zo’n ‘compensatieafhandelaar’ kan vanuit het proces worden aangeroepen, maar zal in veel gevallen bij het gedrag van een foutafhandelaar horen.
Verder is het relevant te weten dat het mogelijk is processen in ‘geneste scopes’ onder te verdelen die logische eenheden voorstellen. Een compensatieafhandelaar kan per scope worden gedefinieerd, maar er zijn standaard compensatie- en foutafhandelaren beschikbaar. Het gedrag van de standaard foutafhandelaar is het in omgekeerde volgorde aanroepen van compensatieafhandelaren van reeds uitgevoerde activiteiten binnen de scope, en het ‘doorgooien’ van de fout. Het gedrag van de standaard compensatieafhandelaar is vergelijkbaar met dat van de standaard foutafhandelaar, maar deze geeft alleen geen fout door.
Bpel biedt standaard géén ondersteuning voor korte transacties of gedistribueerde transacties. Op het gebied van gedistribueerde transacties is er al de ‘WS-transaction specification’. Op het gebied van korte transacties zal waarschijnlijk in de toekomst ondersteuning komen door atomaire scopes te definiëren, die als geheel slagen of falen. Wat al wél mogelijk is in Bpel, is het definiëren van ‘serializeerbare’ scopes, die exclusieve toegang tot een container mogelijk maken.
Ondersteuning
Er is een grote toekomst weggelegd voor bedrijfsprocesintegratie en alles wat daaromheen speelt. Anderzijds is er grote belangstelling voor webdiensten en open standaarden, met name hoger op de ‘webdienstprotocol-ladder’. De kans is groot dat Bpel in de toekomst een belangrijke rol gaat spelen in deze arena, met name op het gebied van volledig geautomatiseerde bedrijfsprocessen. Het succes is in sterke mate afhankelijk van de brede ondersteuning van de standaard in producten van softwareleveranciers. Het gaat daarbij niet alleen om producten voor het uitvoeren van processen, maar ook om tools voor het modelleren en monitoren van processen. Een dergelijke open standaard kan als lingua franca voor bedrijfsprocessen gaan functioneren. Uitwisseling van bedrijfsprocesgegevens tussen tools en omgevingen kan dan geschieden op basis van Bpel. De uitvinders van de standaard zullen hierbij vooruitlopen op de rest van de markt. Uiteraard staan de ontwikkelingen aan de kant van Bpel ook niet stil. Zo zal de taal in de toekomst waarschijnlijk ondersteuning gaan bieden voor onder andere lokale containers, ‘event handlers’, scopes die elkaar kunnen overlappen en scopes die automatisch transactioneel zijn.
Danny Greefhorst, It-architect, IBM Business Consulting Services
