Webservices: de volgende ronde

Voor de zoveelste keer zijn IBM en Microsoft in een hutje op de hei bijeengekomen om een webservice-standaard te bedenken. De afkorting die ze voor deze jongeling bedacht hebben is BPEL4WS. Deze onmogelijke afkorting staat voor Business Process Execution Language for Web Services. Het is hun voorstel voor een taal waarmee we de interactie met webservices, ofwel de choreografie, kunnen vastleggen.

Standaarden als SOAP zijn bij de meesten wel bekend en zijn volop door de leveranciers geïmplementeerd. Met SOAP kunnen we webservices aanroepen en parameters uitwisselen. Voor sommige applicaties biedt SOAP voldoende functionaliteit. Denk hierbij aan webservices om de koers van een aandeel op te vragen of de prijs van een CD. De webservice wordt aangroepen en een antwoord wordt teruggestuurd. Simpeler kan haast niet. 

Als we complexere toepassingen willen automatiseren dan is SOAP nog steeds noodzakelijk, maar niet toereikend. Als we bijvoorbeeld een CD willen bestellen, dan moeten hierin meerdere webservices betrokken. Eerst moeten we ons aanmelden, dan moeten we CD’s selecteren, de bestelling plaatsen en vervolgens onze adresgegevens doorgeven. Een ander voorbeeld is die waarbij we een vakantie willen boeken en daarvoor de webservices van verschillende organisaties, zoals een hotelketen, een autoverhuurbedrijf en een vliegtuigmaatschappij, moeten activeren. 

Bij complexere toepassingen is er meestal een volgorde waarin webservices aangeroepen moeten worden. Het is net als bij de bakker en de slager, eerst moeten we een nummertje trekken en dan pas dienen we in de rij te gaan staan.

Er zijn dus talen nodig waarmee we kunnen aangeven in welke volgorde webservices moeten worden aangeroepen, of ze al dan niet in parallel mogen worden uitgevoerd, wat er moet gebeuren als de aanroep mis gaat en onder welke condities webservices kunnen worden aangeroepen. Met andere woorden, er is een taal nodig om de choreografie van webservices te specificeren.

Uiteraard kan in elke willekeurige applicatie de choreografie geprogrammeerd worden. Dit is echter zeer bewerkelijk en nadelig voor de onderhoudbaarheid. Daarnaast moet transactiebeheer geregeld worden wat een complexe aangelegenheid is. Kortom, dit is niet de aanbevolen oplossing.

Er moest dus een gestandaardiseerde choreografietaal komen. Enkele organisaties hadden reeds een dergelijke taal gecreëerd. Bijvoorbeeld, BPMI sleutelt al enkele jaren aan BPML, het WfMC heeft XPDL in ontwikkeling en ook ebXML bevat een dergelijke taal. Microsoft zelf had XLang in hun Biztalk-product geïmplementeerd en IBM had ooit in een van zijn onderzoekslaboratoria WSFL ontwikkeld. De nieuwe taal BPEL4WS kan gezien worden als een kruising van die laatste twee. Tevens heeft het veel weg van BPML. 

Zoals te vermoeden is, is BPEL4WS een XML-taal. Het maakt gebruik van reeds bestaande standaarden als SOAP en WSDL. Qua functionaliteit biedt zij minder dan de andere voorstellen. Maar de taal kan later altijd nog worden uitgebreid. Hoe deze taal echter gaat samenwerken met andere standaarden en voorstellen, zoals BTP (voor transacties) en WSCI (ook voor choreografie) is onduidelijk. Misschien hebben IBM en Microsoft met deze taal iets teveel naar zichzelf en te weinig naar andere ontwikkelingen gekeken.

Wat is nu de toekomst van BPEL4WS? Het is nog onbekend welke standaardisatieorganisatie zich met dit voorstel zal gaan bezighouden. Wel is duidelijk dat er op korte termijn een door iedereen geaccepteerde standaard voor choreografie moet worden gekozen. Een dergelijke taal is noodzakelijk om de volgende ronde in te gaan. Integreren met simpele webservices is nu al mogelijk. Nu is de tijd aangebroken voor de complexere toepassingen. BPEL4WS zou wel eens die standaard kunnen worden die ons daarmee gaat helpen. Misschien zijn de alternatieven beter, maar BPEL4WS heeft wel twee zwaargewichten achter haar staan.