• startpagina
• diensten
• samenwerking
• publicaties
• The Xpragmatic View
• archief
• Snippets of an Incomplete Mind
• auteursrecht
• wettelijke vermeldingen
• nieuws
• over xpragma
• contactinfo

Web Services - De ontdekking van het paradijs

The Xpragmatic View #49
16 juli 2002
door Marc Buyens (@mbuyens), Xpragma
marc.buyens@xpragma.be
url: http://www.xpragma.be/view49.php
Downloaden als een PDF-file

De voorbije maanden bleef het economische klimaat slecht, wat zich vertaalde in tegenvallende resultaten voor de meeste leveranciers van software technologie, inclusief onze kleine groep van EAI-spelers. De hoera-sfeer van een paar jaar terug is al lang niet meer aanwezig. Toch moet in deze barre tijden de marketing molen zijn werk blijven doen en de nodige aandacht creëren voor nieuwe oplossingen. Eén daarvan is het concept van Web Services. Een nieuwe ontdekking van het paradijs?

Het is al een tijdje geleden, maar een korte verlofperiode, zoals steeds gevolgd door een overbelaste agenda in de weken die er op volgen, hadden de nodige impact op mijn tijdsbesteding. Maar eigenlijk was dit niet zo'n probleem. De voorbije maanden viel er immers weinig belangrijk nieuws te noteren, dus er viel ook niet zoveel te commentariëren. De meeste EAI-leveranciers moesten zwakke kwartaalresultaten aankondigen en een algemeen herstel lijkt nog niet te bespeuren.

Maar ook in deze komkommertijd moeten leveranciers trachten de nodige interesse op te wekken bij hun klanten en prospecten. Een klassieke aanpak hierbij is de introductie van nieuwe producten of het supporteren van een of andere aanpak die reeds in de belangstelling staat. Dit laatste is momenteel vooral van toepassing op het concept van web services, waarvoor zowat iedereen recentelijk aankondigingen heeft gedaan.

Nu moet ik onmiddellijk toegeven dat er eigenlijk ook niets fout zit met deze web services. Dit is een technologie die een duidelijke waarde heeft en die haar plaats zal verwerven binnen het IT-wereldje. Maar men moet ook niet overdrijven. Web services zullen niet zomaar elk IT-probleem oplossen. Dus laat ons een en ander in het juiste perspectief bekijken. Een eerste vereiste daarvoor is een juist inzicht verwerven in wat de toegevoegde waarde van web services kan zijn, maar ook begrijpen waar ergens de beperkingen van deze aanpak liggen.

Het is daarbij zeker niet de bedoeling het ganse concept nog eens te presenteren of verder in te gaan op de technische details van zaken zoals XML, SOAP, WSDL en UDDI. We gaan uit van de veronderstelling dat onze lezers reeds voldoende gelegenheid hebben gehad om de grote principes te leren kennen. Is dit niet het geval, dan moeten we hen verwijzen naar de talrijke artikels en white papers die op het web te vinden zijn. In deze View willen we ons dus beperken tot een high-level analyse van de toegevoegde waarde en beperkingen van web services en hoe dit zich vergelijkt met benaderingen zoals EAI.

Het basisconcept

Wat men vandaag doorgaans verstaat onder het concept web services is een groep van technologieën die toelaat software componenten (al dan niet over het Internet) te herkennen, om vervolgens op een gestandaardiseerde manier de diensten van deze componenten aan te spreken en de resultaten ervan terug te krijgen, dit alles gebruik makend van standaard protocollen die onafhankelijk zijn van het gebruikte platform of de gebruikte toepassing.

Dit kan misschien wat complex lijken, maar dat is in essentie wat het is. Echter, wat dit al dan niet kan betekenen op het vlak van toegevoegde waarde voor een onderneming en hoe dit zich al dan niet verhoudt tot andere benaderingen (waarbij EAI vaak wordt geciteerd), daarover bestaan de nodige discussies.

Ik denk dat ik momenteel een verzameling heb van een 50-tal artikels en white papers over het concept web services. Als je die echter allemaal leest, dan is het nauwelijks te geloven dat ze allen handelen over hetzelfde onderwerp. De opinies variëren immers van "compleet waardeloos" tot "the next big thing".

Je moet je daarbij de vraag stellen hoe de gemiddelde gebruiker hiermee omgaat. Per definitie zal zijn input beperkter zijn. Zijn lees- of luisterwerk zal zich veelal beperkten tot de opinies van zijn traditionele leveranciers of van een paar gereputeerde analistenfirma's. De realiteit is echter dat hoger vermeld "compleet waardeloos" versus "the next big thing" dilemma eigenlijk niet zo idioot is. Afhankelijk van wat je effectief wenst te realiseren zullen web services al dan niet een waarde hebben. Als je dus niet begrijpt welke deze waarde is en in welke omgeving ze het best kan worden aangewend, dan ben je verplicht van een positieve of negatieve beslissing te nemen op basis van de "toevallige" en wellicht onvolledige informatie die je hebt gekregen.

Laat ons daarom eens kijken wat de basisprincipes zijn van web services en een goed startpunt daarbij is de vraag waarom men er überhaupt ooit mee begonnen is.

Het antwoord daarop is vrij eenvoudig. Gezien het groeiende succes van het Internet en de toenemende drang naar allerlei vormen van e-commerce hadden softwareontwikkelaars behoefte aan iets dat hun zou toelaten RPC (Remote Procedure Call) calls te doen over het Internet.

Er zijn allerlei goede redenen te verzinnen waarom dit een interessante oplossing zou zijn. Echter, de realiteit was dat het HTTP protocol dat alom gebruikt wordt op het Internet niet ontworpen was om RPC calls mogelijk te maken. Er was dus iets anders nodig en dat is SOAP geworden. SOAP maakt het dus mogelijk om een RPC call te doen over HTTP. De andere web services componenten zoals WSDL en UDDI hebben ook hun eigen specifieke functie, maar zijn van minder belang voor de rest van deze discussie.

De mogelijkheid om RPC calls te doen over het Internet, gebruik makend van platformonafhankelijke protocollen, is inderdaad iets dat enorme toegevoegde waarde kan hebben en mogelijkheden biedt voor tal van (nieuwe) toepassingen.

Ook is het duidelijk dat dit de ontwikkeling van tal van (Internet-)toepassingen gevoelig van vereenvoudigen en versnellen, met een beduidend lagere kost tot gevolg.

Bijkomend laat het toe om zogenaamde "composite applications" te bouwen, waar bvb. eigen software componenten kunnen samenwerken over het Internet met de toepassingsomgeving van een business partner. Vooral in dergelijke B2B omgevingen kan dit de basis vormen voor echte supply chain integration.

Samenvattend, de mogelijkheden lijken enorm en lijken voorgoed een einde te maken aan tal van beperkingen en onvolkomenheden van de traditionele IT omgevingen. Jammer genoeg zijn er echter ook beperkingen.

Je krijgt wat je vraagt

Het eerste belangrijke punt waar je moet mee rekening houden resulteert van de initiële ambitie van SOAP, met name RPC calls over het Internet mogelijk maken. Nu is het zo dat als je voor een RPC benadering kiest, je er ook de beperking van een request/reply paradigma moet bijnemen. Dit houdt o.a. in dat beide partijen (de aanvrager en de service die men aanspreekt) beiden beschikbaar moeten zijn en dat de aanvrager geblokkeerd is terwijl hij wacht op het antwoord van de service.

Voor tal van toepassingen stelt dit geen probleem en zijn bijgevolg web services een best bruikbare benadering. Er zijn echter ook talloze andere toepassingen waar dit niet zomaar opgaat en waar andere eisen worden gesteld. In het recente verleden is dit mede de aanzet geweest voor de ontwikkeling van technologieën zoals message queuing, publish/subscribe, message brokers, kortom van EAI zoals we het vandaag kennen.

Een eerste besluit is daarom dat de veel gehoorde vraag of web services nu beter zijn dan EAI of omgekeerd eigenlijk niet echt aan de orde is. Beide technologieën hebben een andere aanpak, maar trachten ook eigenlijk verschillende problemen op te lossen. Natuurlijk is er altijd ergens een grijs gebied waar beide benaderingen een bruikbaar alternatief zijn en dus concurreren. Ook is het zo dat de boodschap van web services die volledig gebaseerd zijn op het gebruik van standaarden erg interessant klinkt in vergelijking met de EAI wereld die toch nog in grote mate zijn eigen individuele benaderingen en protocollen hanteert.

Algemeen kan er dus verwacht worden ( en dat zagen we reeds in de voorbije maanden) dat de EAI leveranciers hun producten zullen uitbreiden naar web services toe. Dit is een zeer "natuurlijke" evolutie voor die producten, want web services betekenen voor hun niet veel meer dan een bijkomend protocol of toepassing die ze moeten ondersteunen, en dat is waar EAI producten voor gemaakt zijn. Ook mogen we verwachten dat er pogingen zullen zijn om in de EAI producten meer de nadruk te leggen op het gebruik van standaarden.

In vergelijking hiermee ligt het voor web services iets moeilijker. Hun natuurlijke basis is het RPC paradigma en een uitbreiding hiervan naar andere vormen van interactie toe ligt niet onmiddellijk voor de hand.

Eenvoud versus complexiteit

Een ander belangrijk verschil tussen web services en EAI is eveneens het gevolg van de originele opzet. In vergelijking met EAI is deze immers veel beperkter. EAI is ontstaan met de ambitie (en bijgevolg de design) om omgevingen te integreren die per definitie volledig heterogeen zijn en waar er geen consensus mogelijk is wat betreft de te gebruiken protocollen of interfaces.

De basisidee achter iets zoals SOAP is compleet verschillend. Deze aanpak is gebaseerd op de assumptie dat een gemeenschappelijk protocol haalbaar is en deze assumptie is zinnig gezien het feit dat men dit ontwikkelt boven op een standaard zoals HTTP, gekoppeld aan het gebruik van XML. XML is nog geen standaard zoals HTTP maar kan toch op algemene aanvaarding rekenen, ook al blijven de talloze dialecten voor de nodige complexiteit zorgen.

Een gevolg hiervan is dat het algemene web services concept ontworpen is om een beduidend "eenvoudigere" omgeving te behandelen dan de doorsnee EAI oplossing. In de EAI aanpak zijn zaken zoals schaalbaarheid, beschikbaarheid, transactionele integriteit, beveiliging, beheerbaarheid, enz. zaken van primordiaal belang en zijn ze bijgevolg van bij de aanvang in de design van de oplossing opgenomen. Bij web services zijn deze aspecten slechts in mindere mate of helemaal niet aanwezig in de initiële design.

In theorie is er echter niets dat belet dat web services ook hier de achterstand wegwerken. Hoe dit in de praktijk gaat evolueren is echter nog niet duidelijk. Gaan web services de ontbrekende EAI-mogelijkheden toevoegen of gaan de EAI-oplossingen zelf de volledige web services aanpak ondersteunen? In de praktijk denken we dat, zeker voor de komende periode, beide benaderingen zullen gevolgd worden.

We zijn echter ook van mening dat men daarbij het probleem niet op de juiste manier bekijkt. Veelal ziet men immers over het hoofd dat wat men vandaag als "web services" aanduidt in feite de groepering is van twee basisconcepten die niet noodzakelijk van mekaar afhankelijk zijn.

Componenten

Eerst en vooral is er de idee om business functionaliteit te verpakken in individuele componenten (services) die dan door andere componenten kunnen worden aangesproken. De notie van te werken in de richting van componenten staat in feite los van het gebruik van iets zoals SOAP. Ook een EAI benadering omvat alle bouwstenen voor het ondersteunen van componenten.

Dit laatste hebben we overigens al een paar jaar terug beschreven in onze EAI white paper. In het door ons gepresenteerde model beschreven we een componentenlaag die o.a. de volgende kenmerken had:

In our messaging based EAI approach, business components are logical objects that represent the execution of one or more business functions. Being a logical object, they are instantiated by one or more (physical) executables that perform the programming logic. These instances receive requests for processing and send replies via well defined but not necessarily uniform (messaging) interfaces.
Business components are fully logical elements, without an understanding of the underlying technical infrastructure. Components manipulate "logical data" (meta-data). Therefore, any business component is free to interact directly with any other business component.

Zoals je kan zien, dit is in niets verschillend van wat men met web services ambieert te doen. Wel moeten we vaststellen dat web services reeds een stap verder staan met standaarden zoals XML, WSDL en UDDI die de definitie en de interactie van componenten vergemakkelijken.

Interactie

De tweede bouwsteen van het web services paradigma is dan de manier waarop je de componenten aanspreekt en er mee interageert. Op dit vlak lijken web services en EAI in directe concurrentie te zijn omdat beiden een eigen manier voor integratie voorstellen. Maar dat is maar een oppervlakkige vaststelling.

Zoals hoger beschreven zullen web services en EAI zelden concurreren. Web services zullen de meest kosteffectieve aanpak geven voor omgevingen waar de complexiteit van de toepassingsomgeving het toelaat. In dergelijke omgevingen zal EAI vaak een al te dure of complexer aanpak zijn. In de meer complexe omgevingen is dan weer de functionaliteit van web services ontoereikend.

In feite is er dus niet zoiets als kiezen tussen beide benaderingen. Het echte probleem is het onderkennen van de echte businessvereisten en daaraan gekoppeld het kiezen van de gepaste aanpak. Daarom verwachten we dat nog geruime tijd web services en EAI mekaar zullen aanvullen om een globale portefeuille te vormen van integratiebenaderingen. Meer dan waarschijnlijk zal dit ook resulteren in een verdere consolidatie en integratie van beide paradigma's zodat uiteindelijk beiden zullen ophouden te bestaan als echt afzonderlijke benaderingen.

Conclusie

Samenvattend kunnen we stellen dat de vraag van web services versus EAI weinig zin heeft. Beiden hebben hun plaats in het huidige IT wereldje en ze moeten aangewend worden i.f.v. het specifieke probleem dat dient opgelost en niet i.f.v. een soort "religieuze" voorkeur.

Web services brengen de belofte van eenvoud, lagere kost en meer standaardisatie, maar EAI is niet te vermijden in de complexere omgevingen.

Beide benaderingen ondersteunen het concept van componenten als basis voor de ontwikkeling van composite applications. Op dat vlak is er dus geen conflict wat betreft de architectuur. Wel is het zo dat beide benaderingen nog steeds een onvolledige ondersteuning geven voor dit concept.

Ook moeten we vaststellen dat geen van beide benaderingen echt de juiste oplossing voor een enterprise-wide gebruik. Web services hebben te weinig maturiteit en te weinig "body" om dergelijke omgevingen te ondersteunen, maar EAI oplossingen zijn vaak te complex en te duur voor bepaalde deelgebieden.

De beste benadering ligt daarom (zoals steeds) ergens in het midden, wellicht gebruik makend van een EAI backbone die ook ondersteuning biedt voor web services, gecomplementeerd met een pure web services aanpak voor de eenvoudigere of minder bedrijfskritische omgevingen. In de praktijk zal dit vaak betekenen dat (zeker in de huidige fase) web services enkel zullen aangewend worden voor bedrijfsinterne toepassingen. Dit kan een beetje vreemd lijken gezien de initiële opzet van web services, maar er is een verschil tussen ambitie en realiteit.

Succes...

Tags: software as a service (SaaS)

 

comments powered by Disqus