Als we de leveranciers van zakelijke software mogen geloven, vormen webdiensten hét antwoord op al onze problemen. Hiermee zouden we eindelijk wél elektronisch zaken met elkaar kunnen doen. Het lijkt het allemaal verdacht veel op het sprookje ‘De nieuwe kleren van de keizer’. Webdiensten kunnen bepaalde zakelijke problemen oplossen, maar we moeten er geen hype van maken.
Volgens een drieletterige it-reus zijn we op het moment aangeland in het ‘On demand’-tijdperk. We moeten echter niet in sprookjes geloven, we moeten ons realiseren dat b2bi (business-to-business-integratie) een moeilijk onderwerp is en dat we eigenlijk hun overbetaalde consulenten, die toch niets te doen hebben, zouden moeten inhuren om ons te helpen het probleem aan te pakken. Gelukkig maar dat we webservices als het ’technologieplatform’ hebben, wat deze taak zal verlichten, zodat we de informatie in ‘realtime’ ontvangen en ons op die manier werkelijk kunnen klaarmaken voor het ‘On demand’-tijdperk.
Wat betreft de rol van webdiensten is iedereen het eens met onze ‘On demand’-reus. Ze zijn de definitieve oplossing voor het probleem dat we jaren hebben gehad en ze maken het nu wél mogelijk om elektronisch zaken te doen met elkaar. Sterker nog, webdiensten zullen elk probleem oplossen dat te maken heeft met web, internet en integratie. Het zou immers geweldig zijn als een koper zelf kan controleren of zijn leverancier genoeg producten op voorraad heeft om aan zijn behoeften te voldoen? Natuurlijk zal de leverancier met alle plezier toegang verlenen tot het hart van zijn interne systeem om die informatie te verschaffen, waarmee de klant vervolgens kan besluiten om naar de concurrent te stappen. Net zoals de leverancier zijn klant al zijn productinformatie en prijzen zal laten zien, zodat de laatste een mooi systeem kan creëren om het aanbod van zijn leverancier te vergelijken met dat van diens concurrenten.
Onzin
Dit is fictie. In de logistieke keten hebben kopers al jaren geprobeerd om dit type informatie van hun leveranciers los te krijgen. Het is niet zo dat die er uit technisch oogpunt niet toe in staat waren om die informatie te verschaffen; er zijn simpelweg goede zakelijke redenen om het niet te doen. Een leverancier wil niet dat zijn klanten niets bij hem bestellen omdat hij onvoldoende producten op voorraad blijkt te hebben. Hij zal liever de producten zelf bij zijn concurrenten weghalen dan de band met zijn klant verliezen. Het laatste wat leveranciers willen is samen met hun concurrenten in een catalogus komen te staan waaruit klanten dan snel de goedkoopste producten kunnen selecteren. Webdiensten zullen het technisch heel makkelijk maken dit alles te implementeren, maar zakelijk gesproken is het onzin, behalve als er een hechte band bestaat tussen klant en leverancier.
Er is hier echter een probleem. Om de informatie-uitwisseling tussen de spelers in de keten te optimaliseren, is het noodzakelijk dat kopers correcte en actuele productinformatie voorhanden hebben. Anders kunnen ze nooit de juiste producten bestellen en zullen er fouten in de elektronische orders sluipen. Dit leidt tot menselijke tussenkomst en veel extra kosten. Het is beslist de doelstelling van de spelers in de keten om samen te werken, zodat het totaalpakket van producten en diensten dat een leverancier zijn klanten kan aanbieden, gebaseerd is op de hoogst mogelijke efficiëntie. Dit betekent dat de klant niet altijd de laagste prijs voor ieder product betaalt, maar over het algemeen zal hij de beste deal uit de nauwere samenwerking halen.
Daarom hebben de spelers in de bevoorradingsketen een gemeenschappelijk platform nodig om product- en andere informatie uit te wisselen. Ze moeten samenwerken om een gemeenschappelijke infrastructuur te creëren die voorziet in de behoefte aan informatie-uitwisseling, maar ze willen wél beschikken over voldoende controlemiddelen om een directe, ‘realtime’ informatiestroom in de hand te kunnen houden.
Controle
Een dcb (digital business community) is zo’n platform: een centraal systeem dat het de spelers in de logistieke keten gemakkelijk maakt om informatie uit te wisselen; zakelijke documenten en productinformatie, die door hun neutraliteit veel van de ingewikkelde zaken verbergen die zich manifesteren wanneer individuele verbindingen worden gemaakt tussen elke koper en de leverancier.
Daar hebben we geen ‘realtime’ webdiensten voor nodig. We willen controle hebben over de informatie-uitwisseling, maar we hoeven niet persé diepe links te maken naar elk van onze partners afzonderlijk. We zouden echter afspraken willen maken om dit platform zodanig te implementeren dat, wanneer eenmaal een link met een partner is gelegd, dezelfde link gebruikt kan worden om met alle partners elektronisch te handelen.
Dat is niet hetzelfde als een elektronische marktplaats. Bij dbc’s gaat het niet alleen over de dagelijkse aan- en verkoop, maar vooral ook over gecontroleerde en efficiënte samenwerking en informatie-uitwisseling tussen partners. Dus vanuit zakelijk oogpunt is de noodzaak voor ‘webdiensten voor b2bi’ afwezig, alhoewel sommige interessante toepassingen wel degelijk een plaats kunnen krijgen. We zullen het daar later over hebben. De vraag is dan: wat zijn webdiensten en waarom zijn alle it-leveranciers over de hele wereld er zo vol van?
Geen browser
Webdiensten zijn gedetailleerde beschrijvingen in XML die de representatie en overdracht regelen van via internet toegankelijke programma’s, onderwerpen, berichten of documenten voor directe ‘applicatie naar applicatie interactie’. De webdiensten zijn weliswaar te benaderen via browsers, maar hebben die browsers niet nodig, noch Html, noch het web. Ze verschaffen namelijk een dataonafhankelijk mechanisme om zakelijke diensten aan te bieden – binnen en buiten de firewall van de onderneming – door standaard internet/intranet/extranet-protocollen en ‘formats’ te gebruiken. Voor de acroniem-fans onder ons: XML, soap, Wsdl, uddi en http zijn de algemeen geaccepteerde technische bouwblokken van webdiensten. Maar andere acroniemen worden dagelijks verzonnen en met elkaar gecombineerd.
Om het simpel te zeggen, webdiensten zijn via internet te benaderen diensten die informatie kunnen halen uit een toepassing, berekeningen kunnen maken en veranderingen kunnen aanbrengen alvorens het resultaat terug te sturen naar de toepassing of browser van waaruit ze aangeroepen worden. Webdiensten kunnen andere webdiensten aanroepen op een voor de gebruiker vaak onzichtbare manier. Ze lijken sterk op rpc’s (remote procedure call), een gebruikelijke techniek in de Unix-omgeving.
Het voordeel van webdiensten is dat ze een platformonafhankelijke interface verschaffen en dat ze makkelijk te creëren zijn met redelijk stabiele standaarden, eenvoudige hulpmiddelen en de mogelijkheid om bestaande it-kennis te hergebruiken. We moeten beseffen dat deze keizer nog steeds geen nieuwe kleren heeft en oppassen om geen hype te creëren rond deze webdiensten. Dat zal immers weer leiden tot teleurgestelde gebruikers.
Het doel van webdiensten is dat iedereen een dergelijke dienst kan ontwikkelen en beschikbaar stellen voor een andere partij in een proces. Dat is best als het een intern proces is, daarom is eai (enterprise application integration) ook zo’n succesvolle toepassing voor webdiensten gebleken. Voor externe processen echter, die vaak worden aangeprezen als het grootste toepassingsgebied voor webdiensten, zijn er veel problemen die nog moeten worden opgelost. Denk aan veiligheid, beschikbaarheid, doorzichtigheid en bovenal de mogelijkheid tot onderhoud en controle.
Chaos
Het feit dat webdiensten zo gemakkelijk zijn te creëren is tevens hun grootste probleem. Een bedrijf zou snel kunnen zitten met duizenden kleine toepassingen, verspreid over allerlei it-systemen, die leuke links verschaffen en de integratiemogelijkheden prima benutten, maar zonder enige controle of mogelijkheid tot onderhoud. Er is geen overzicht van wélke webdiensten wát doen, geen documentatie, geen manier om ze terug te vinden en geen gegarandeerde betrouwbaarheid of beschikbaarheid, vooral niet in een externe omgeving.
Daarom leveren verschillende softwareleveranciers tegenwoordig productiviteitstools om de webdiensten, die zich als onkruid uitzaaien binnen het bedrijf, te ordenen, te documenteren, op te slaan en te controleren. Typisch, eerst leveren de softwaremakers de middelen om er een chaos van te maken en daarna verkopen ze nog meer middelen om weer orde te scheppen in de chaos.
Het probleem is dat het niet zo gemakkelijk is om die chaos weer op orde te krijgen, tenzij je een duidelijk omlijnde structuur hebt voor je webdiensten. Het beste is om deze structuur te definiëren voordat de webdiensten gecreëerd zijn, maar meestal komt een bedrijf erachter dat het een structuur nodig heeft nádat de chaos is ontstaan en honderden webdiensten rondwaren in de it-systemen zonder enige duidelijke controle. De structuur vooraf bepalen is vrijwel onmogelijk, omdat de creativiteit van de programmeurs de vrije loop wordt gelaten en de organisatie nog niet weet waar webdiensten zullen worden gecreëerd. Het is ironisch, maar de manier om uit dit dilemma te komen, is te kijken naar hoe b2bi, om precies te zijn eb-XML (electronic business), dit probleem zal oplossen.
Utopia
Er zitten twee hoofdgedachten achter eb-XML. De eerste is dat de ervaring ons leert dat, als we de betekenis van de informatie die we uitwisselen in een zakelijke omgeving willen definiëren (de semantiek of de ‘core components’, kerncomponenten), dit op mondiaal niveau moet gebeuren. Als dit niet dáár gebeurt, blijven we semantiek creëren die binnen een groep kan worden uitgewisseld, maar nooit de links kan creëren met alle partners met wie we te maken hebben als we zakendoen. Daar komt nog bij dat deze semantische componenten al tot vervelens toe zijn gedefinieerd in bestaande standaarden, zeker in edi.
De tweede hoofdgedachte is dat semantiek alleen te definiëren valt binnen de context van het zakelijke proces waar we haar voor gebruiken. Daarom moet elk bedrijf zijn zakelijke proces op een uniforme – gestandaardiseerde – wijze definiëren, zodat het door iedereen te begrijpen is. Eb-XML verschaft het kader om dat te doen. Hier ligt tevens de oplossing voor de structuur en de controle van webdiensten.
Eén standaard voor alle bedrijven op de markt, wereldwijd – dat moet Utopia zijn. Als bedrijven eerst hun zakelijke processen definiëren op de manier die eb-XML voorschrijft, zouden ze niet alleen de basis leggen waarop ze met andere ondernemingen kunnen communiceren, maar ook de structuur opzetten voor elke webdienst die ze zouden willen creëren.
Deze structuur en de uitleg over wat bepaalde webdiensten werkelijk doen, kan worden aangegeven in een uddi-directory, die intern wordt gebruikt en uiteindelijk met andere bedrijven wordt gedeeld. Vervolgens zouden bedrijven de semantiek moeten omschrijven van de kerncomponenten die zijn opgeslagen in een op mondiaal niveau verspreide ‘repository’. Dit zal een echte b2bi verzekeren, aangezien verbanden tussen kerncomponenten formeel te ‘linken’ zijn – iemands ‘order-id’ is bijvoorbeeld het ‘order-referentienummer’ van iemand anders.
Kinderschoenen
Door het gebruik van gestructureerde zakelijke processen en semantiek, verenigd met het gebruik van een dns-achtig netwerk van samenwerkende ‘repositories’, kunnen webdiensten hun werkelijke capaciteit ontplooien, omdat de chaotische omgeving controleerbaar is. Ook al zal de informatie-uitwisseling tussen verschillende bedrijven waarschijnlijk nog jaren worden gebaseerd op ‘messaging’. Deze manier om webdiensten te structureren is de beste oplossing om interne chaos te voorkomen.
De bruikbaarheid van webdiensten in een b2bi-omgeving staat momenteel nog in de kinderschoenen. Op dit moment zijn er bijvoorbeeld webdiensten om automatisch adressen in een document te voegen op basis van postcodes, of webdiensten die de afstand tussen twee punten berekenen en invoegen in een onkostenrekening. Er zullen nog veel meer van dit soort nuttige toepassingen worden opgezet. De onderliggende technologieën zijn XML en soap. Zo erven webdiensten normaal gesproken de voordelen van deze technologieën.
Ze hebben ook hun eigen definitietaal, de ‘Webservices Definition Language’ (Wsdl), die is gebaseerd op XML. Er is inderdaad een compleet gelaagd effect aanwezig aangezien eb-XML zelf te zien valt als ‘business layer webservices’ en de specificatie ‘eb-XML Message Services’ bijvoorbeeld is gebaseerd op soap. Er is echter functionaliteit op zakelijk niveau aan toegevoegd, zoals gegarandeerde ‘receipt tracking’, verhoogde veiligheid en kenmerken van betrouwbaarheid.
Langzaam
Voor de meeste bedrijven is er intern genoeg te doen om zich op e-handel voor te bereiden. Dat werk moet sowieso gebeuren. De huidige manier van elektronisch zakendoen zal verschuiven naar eb-XML en webdiensten, maar dit is een langzaam proces. Het zal nog vele jaren duren voordat investeringen in edi worden afgeschreven, de interne organisatie van handelspartners is aangepast aan de nieuwe omgeving en de denkrichting van mensen binnen deze organisaties is veranderd. De ‘fud-factor’ (‘fear, uncertainty and doubt’) is nog steeds erg hoog en mensen weten niet meer wat de juiste weg is.
Waar mogelijk kunnen bedrijven hun zakelijke interfaces met een doorzichtige technologie naar buiten brengen, gebaseerd op open standaarden, dusdanig samengebracht dat de beschrijvingen naadloos op elkaar aansluiten. De simpelste webdiensten kunnen de effectiefste zijn, zeker op korte termijn. Een webdienst om een adres op te zoeken aan de hand van een postcode kan vanuit vrijwel elke applicatie worden aangeroepen en voorkomt veel drukfouten.
Zoals al is bewezen met een reeks webdiensten voor datatransformatie en communicatie is het gunstig om functies van een b2bi-transactiesysteem om te zetten naar webdiensten. Dit zorgt voor een flexibel systeem met een solide webfundering, dat nog steeds te gebruiken is om de ‘legacy’-communicatie met vans (value added network services) en x.400 te hanteren, evenals de datatransformatie tussen XML en edi, in een gecontroleerde omgeving die te handhaven is.
Hoewel er vanuit een conceptueel, zakelijk oogpunt weinig nieuws aan is, zijn webdiensten in wezen een bestaande technologie die een nieuwe, zakelijke functie zou kunnen krijgen. De zakenwereld heeft dit soort interacties tussen verschillende toepassingen al jaren geïmplementeerd. We zijn dus niet zozeer op zoek naar een nieuwe manier om toepassingen te integreren, maar meer naar een modernere versie van iets waarvan we allang weten dat het werkt.
Laten we daarom niet blijven staren naar de nieuwe kleren van de keizer. Het gaat om niets meer of minder dan een nieuwe technische poging om een zakelijk probleem op te lossen.< BR>
Dick Raman, ceo Tie Holding