ebXML en WUS: een droomkoppel

Electronic Business XML Messaging Services (ebXML) en de combinatie van Web Services met UDDI en SOAP (WUS) worden vaak gezien als bittere rivalen. Beide werelden hebben elkaar echter juist nodig om volledig te kunnen slagen.

WUS gaat over messaging (het proces); ebXML legt echter de nadruk op de messages (de vorm). De ontwikkeling van standaards voor WUS gaat vooralsnog moeizaam, terwijl de hecht doortimmerde set van ebXML-standaards vrijwel kant-en-klaar kunnen worden geïmplementeerd. Daarentegen begint WUS de de facto industriestandaard te worden, terwijl ebXML nog een hoop achterdocht heeft te overwinnen. Zo bezien zijn de twee absoluut geen rivalen, maar elkaars natuurlijke complement. Er is al een punt waarop ze elkaar kunnen ontmoeten: SOAP.

De behoefte

Als we bedenken dat het overgrote deel van alle conflicten in de wereld voortkomt uit een onvermogen om te communiceren, dan zou het fijn zijn als we allemaal dezelfde taal spraken. In de loop der tijden zijn er al heel wat pogingen geweest (denk aan Esperanto) om dat Utopia te bereiken, maar al die pogingen mislukten. Voor het grootste deel vanwege hun kunstmatige, top-down aanpak. Misschien is het juist daarom dat het Engels als bottom-up kandidaat nu zulke hoge ogen gooit als de facto lingua franca.

Ook in de e-business zijn er al pogingen gedaan om systemen op elkaar aan te sluiten zonder dat daar allerlei (onderling elkaar vaak uitsluitende) bilaterale afspraken voor nodig waren. Vaak waren die branchegericht: HL7 voor de medische wereld, EDIFACT voor de handel, RosettaNet voor de elektronica. Sommige van deze standaards beperkten zich tot de structuren van uit te wisselen gegevens, maar anderen (RosettaNet) bemoeiden zich ook met de structuren van de berichtenuitwisseling zelf.

Deze initiatieven werden, niet alleen door hun branchespecifieke aanpak, maar ook door hun top-down benadering, maar beperkt geaccepteerd. De behoefte, echter, bleef en daarom is er nu weer een nieuwe poging gedaan: e-business XML, kortweg ebXML. Zelfs de Verenigde Naties staan er nu achter, maar, wederom, top-down…

ebXML is een open standaard voor bedrijfsspecificaties die het mogelijk maakt om XML in een dusdanig consistente manier te gebruiken dat het gebruikt kan worden voor het uitwisselen van alle soorten van elektronische bedrijfsgegevens. ebXML gebruikt SOAP als berichtenprotocol, heeft eigen Business Process Specification Schemas voor het definiëren van de samenhang van bedrijfsprocessen en heeft in de core components een elegant generiek model voor het vastleggen van de structuur van de berichten zelf. Vorm, structuur, inhoud en de verpakking zijn zo in een hand gevat. Nu de acceptatie nog.

Positionering

De technieken die gebruikt worden door ebXML kennen een grote overlap met die van WUS. Echter, waar WUS alleen maar tools wil verstrekken waarmee bedrijven zelf hun e-businessprocessen kunnen automatiseren, is het doel van ebXML veel ambitieuzer: het standaardiseren van die bedrijfsprocessen zelf. Dit kan nog wel eens een brug te ver blijken te zijn, want ondernemingen hebben hier doorgaans verschillende ideeën over en zonder een goede economische reden zullen ze die niet gaan veranderen. Daarnaast lijkt het grootste deel van de industrie zich toch op WUS te richten.

Er zit dus momentum achter WUS en aan de lopende band worden nieuwe afspraken gemaakt over standaardisatie, die vervolgens hun weg vinden in fysieke (software)producten. De BPEL-specificatie (Business Process Execution Language) bijvoorbeeld, recent verschenen als vervanger voor de Web Services Flow Language (WSFL) van IBM en de XLANG van Microsoft, staat aan de basis van de orchestration binnen het fysieke product BizTalk.

Punt is wel dat ebXML al die standaarden al heeft. En dat daar heel wat beter over lijkt te zijn nagedacht. In het nadeel van ebXML, echter, werkt dat het weer een top-down ‘studeerkamerproduct’ is, terwijl SOAP en consorten duidelijk rechtstreeks vanaf de werkvloer lijken te komen en tot de facto standaard uitgroeien, simpelweg omdat de mensen die ermee werken vinden dat ze makkelijk in het gebruik zijn.

Vorm

WUS en ebXML rivalen? In eerste instantie was daar inderdaad sprake van, maar toen Microsoft haar SOAP in het publieke domein plaatste (en dus afzag van intellectuele rechten, tot dan toe een groot obstakel voor anderen om het te gaan gebruiken), was ebXML er snel bij om (een deel van) de SOAP-specificaties, inclusief SOAP With Attachments (SWA) als transportmechanisme te adopteren. Hoewel ebXML deze extensies als normatief deel van haar eigen specificaties ziet, blijft de implementatie van deze extensies implementatieonafhankelijk.

Even wat techniek: het SOAP-framework begint met een normale MIME envelope, waarin een (namespaced) SOAP envelope is opgenomen. ebXML bouwt voort op deze MIME-structuur door het multipart framework van SWA te gebruiken om additionele payload data mee te nemen, hetzij ‘by reference’, hetzij als content van multiple body parts. Hoewel business data in een SOAP envelope kan worden opgeslagen, raadt ebXML aan om hiervoor de additional body parts te gebruiken. De SOAP envelope kan dan worden gebruikt voor routing en transportinformatie.

Met de adoptie van SOAP kreeg ebXML nog een aantal features in de schoot geworpen, zoals het concept van Action en Actor en de error handling support van de SOAP-Env:SOAPFault. Het eindresultaat is een compleet product, waarin alle theoretische wensen worden vervuld.

Hoewel binnen WUS de samenhang tussen bedrijfsprocessen met BPEL kan worden gemodelleerd, zegt WUS verder niets over het wezen van die modellen. De Business Process Specification Schemas (BPSS) van ebXML, daarentegen, zijn heel eenduidig: het is een standaard met als doel het versnellen (en dus goedkoper maken) van zakelijke e-contacten.

BPSS maakt gebruik van het vertrouwde UML, binnen het raamwerk van de eigen UN/CEFACT Modelling Methodology (UMM). Het UMM Meta Model beschrijft bedrijfsprocessen op semantisch niveau, zodat zakenpartners de details van een bepaald scenario eenduidig kunnen vastleggen. BPSS legt vervolgens de relatie tussen de hieruit verkregen details vast en verwijst naar de verschillende te gebruiken documenten.

Berichten

Zoals gezegd concentreert WUS zich op vorm en zegt het alleen iets over de inhoud van de berichten als die relevant zijn voor routering of transport. ebXML, echter, heeft duidelijke standaards op zowel het gebied van berichten als van berichtuitwisselingsprocessen.

Standaards als EDI en RosettaNet trachtten generiek te blijven door domweg alle mogelijke data-elementen als optie in een generieke documentstandaard op te nemen. Dit zorgde ervoor dat elke organisatie die die standaard wilde gebruiken weer zijn eigen richtlijnen moest opzetten om te bepalen welke van de vele optionele data-elementen gebruikt mochten worden. Datzelfde gold natuurlijk voor de zakelijke partner en de mapping tussen de schema’s. Deze aanpak had dus al duidelijk grenzen als de standaard zich beperkte tot een bepaalde branche, maar een universele standaard (zoals ebXML wil zijn) moest, om werkbaar te blijven, wel een andere aanpak kiezen.

Berichten in ebXML zijn opgebouwd uit zogenaamde core components, bestaande uit een hiërarchische, onderling te combineren set ‘business information entities’ (bie’s). Deze op zich redelijk abstracte entiteiten (‘partij’ en ‘product’ kunnen eigenlijk overal aan refereren) worden door zogeheten ‘context drivers’ voor een bepaalde omgeving geconcretiseerd. Deze context drivers zijn een heel raamwerk van categorieën, zoals bedrijfsproces, regio, branche en wettelijke richtlijnen.

Een voorbeeld: elke in rekening te brengen zakelijke handeling kan op het hoogste abstracte niveau gezien worden als het afnemen van een ‘product’ door een ‘partij’. De zakelijke omgeving bepaalt dat we in een supermarkt het product zien als kruidenierswaren en de partij als ‘klant’, terwijl in een ziekenhuis dit een medische behandeling respectievelijk een patiënt zijn. De geografische omgeving van die laatste bepaalt vervolgens of we de patiënt identificeren met een SSN-nummer (in de VS) of een SoFi-nummer (in Nederland). Welke gegevens we vervolgens per patiënt vastleggen wordt vaak weer bepaald door allerlei wettelijke richtlijnen, die ook weer vaak langs geografische lijnen verschillen. Het resulterende multidimensionale product is complex, maar elegant, doordat het zeer nauw aansluit op de werkelijkheid en de gebruiker niet wordt opgezadeld met allerlei opties die nooit gebruikt worden en nodeloos verwarrend werken.

Helaas heeft de ebXML-groep bij het samenstellen van de geaggregeerde core components, zoals een factuur, toch weer gemeend de oude EDI-aanpak te moeten volgen, door alle mogelijke onderdelen per core component optioneel mee te nemen. Het moge hiermee duidelijk zijn dat ebXML op dit gebied nog in ontwikkeling is.

De competitie

Het voorgaande lijkt misschien op de opmaat voor weer een ict-stammenstrijd, maar dat is het niet. Juist door die al eerder gememoreerde overlap hebben WUS en ebXML erg veel met elkaar gemeen en kunnen ze elkaar dus veel bieden.

Als we kijken naar de invulling die ebXML en WUS geven aan de communicatie, dan zien we het verschil tussen de ‘werkvloeraanpak’ van WUS en de academische benadering van ebXML. Zaken als quality of service, non-repudiation en digital signatures (security) zijn bij ebXML tot in detail uitgewerkt, terwijl WUS eigenlijk net komt kijken, wat dus een reden is voor organisaties die zich juist intrinsiek verbonden hebben aan zaken als security (banken en overheidsinstellingen) om WUS met de nodige omzichtigheid te benaderen. In zo’n geval zal men al snel voor de rigide charmes van ebXML vallen, om vervolgens te moeten concluderen dat het weliswaar een standaard is, maar niet breed gedragen. En ‘iedereen’ gebruikt WSDL, UDDI en SOAP. Wat te doen? Het antwoord ligt voor de hand: samenwerken.

Handen en voeten

Het grote probleem van een academische oplossing is het in gang zetten van fysieke implementaties, of, eenvoudiger gezegd: hoe geef je dat geweldige idee handen en voeten? Op dit moment zijn van de grote aanbieders alleen Sun-producten ebXML-compliant, maar Microsoft laat heel actief ebXML (voorlopig) links liggen. En hoe haal je vendors over om jouw standaard te implementeren als je geen garantie kunt bieden dat de markt die standaard ook wil gebruiken? Er is hoop: er is wel interesse voor het concept op zich (automobielgiganten als GM, VAG en Ford zijn er al mee aan het spelen), maar men schrikt terug van een stap in een richting die buiten de de facto standaards (lees: WUS) lijkt te gaan.

Met de adoptie van SOAP lijkt deze horde genomen. Via SOAP ligt immers op transportniveau vrijwel het volledige spectrum aan middleware open. De XML-basis voor de structuur van de gegevens wordt ook alom gerespecteerd.

Op dit niveau zou dus al een breed gedragen pakket als BizTalk kunnen worden ingezet, ware het niet dat er nog een oplossing moet worden gevonden voor de structuur van de berichtenuitwisseling zelf. Hiervoor heeft iWay een adapter ontwikkeld, die kan worden gecombineerd met het voornoemde BizTalk. Via deze combinatie kan ook de non-ebXML wereld worden aangesloten op het ebXML-walhalla. Beter nog: doordat BizTalk ook de poort naar ‘klassieke’ combinaties openhoudt (er kan een ongelimiteerd aantal adapters gecombineerd worden) hoeft een overgang nu niet via een ‘big bang’ te geschieden, maar kan geleidelijk aan (ook binnen een enkel bedrijf of een enkele zakelijke relatie) worden toegewerkt naar een volledige implementatie van ebXML.

Zo kan worden voorkomen dat de grote ambities van ebXML ook meteen het einde van ebXML worden. Beter nog: doordat ebXML zeer doordachte eisen stelt op het gebied van bijvoorbeeld inhoud van berichten (welke data-elementen zijn er allemaal nodig voor een order voor metalen gordijnringen?) zal de non-ebXML wereld worden verleid om zich aan die eisen te conformeren. En hoe kan dat makkelijker dan door gewoon de ebXML-standaarden te adopteren?

Ed van Akkeren en Robert Mekking, Atos Origin