De juiste technologie is beschikbaar om componenten te bouwen die kunnen samenwerken over een lan of wan, ongeacht verschillen in platform, client, server of wat dan ook. Om goede component-architecturen te realiseren, moeten we echter afrekenen met enkele hinderlijke traditionele client/server-denkbeelden, aldus een consultant van DCE Consultants.
Het aantal leveranciers dat direct betrokken is bij het schrijven van een deel van de software waar een gemiddelde gebruiker elke dag mee werkt, is de afgelopen jaren enorm toegenomen. In het mainframe-tijdperk kon je ze op de vingers van één hand tellen. In het client/server-tijdperk is dat aantal verder gegroeid, en nu, in het Web-tijdperk, is het nog veel groter geworden. Dat komt omdat de software-industrie een benadering heeft gekozen die veelal wordt aangeduid als cbd (component based development). Deze benadering stoelt op de klassieke software-ontwikkelingsconcepten van samenhangende functionaliteit binnen componenten (cohesion) en losse koppeling (loose coupling) tussen componenten.
Wat de software-industrie als geheel is gelukt, geldt echter nog nauwelijks voor de gemiddelde IT-afdeling. Dat komt in de eerste plaats omdat men er niet in slaagt een cultuur te kweken waarbij componenten van elkaar worden overgenomen binnen een bedrijf. Software verschilt hierin niet veel van andere producten waaraan hoge betrouwbaarheidseisen kleven: ik wil best onderdelen en zelfs een hele auto van Ford kopen, maar zal nog geen wieldop aanschaffen die door mijn oom Henk gemaakt is. Ten tweede lukt het niet goed om een zinvolle indeling in componenten te maken of door middel van een praktische architectuur aan te geven hoe de componenten dienen samen te werken. De algemene principes van ‘cohesion’ en ‘loose-coupling’ zijn te weinig vertaald in pragmatische architecturen. Dit artikel geeft een denkkader en richtlijnen om deze vertaalslag te maken.
Client/server was het eerste paradigma waarin sprake was van componenten die zowel functioneel als technisch separaat konden worden ingevuld en toch een samenwerkend geheel vormden. Maar client/server-principes vormen vaak de meest onlogische en onproductieve manier om functionaliteit op te delen in componenten. Om goede component-architecturen te ontwerpen, moeten wij afrekenen met de hinderlijke denkbeelden – zeg maar, mythen – die het client/server-denken gevaarlijk maken.
Inflexibiliteit
Mythe 1: flexibiliteit volgt technologie.
Het eerste principe van client/server dat we moeten heroverwegen is de veronderstelling dat de juiste client/server-technologie het belangrijkste punt van aandacht is bij het bouwen van makkelijk te onderhouden informatiesystemen. ‘Kies voor open technologie en dan zullen legacy-systemen tot het verleden behoren’, zo werd ons verteld. Was dat maar waar! Natuurlijk was de oude technologie een garantie voor inflexibiliteit. Kleine veranderingen brachten hoge kosten met zich mee. Zo was het niet uitzonderlijk dat je een weekend bezig was met het opnieuw laden van de totale database als je alleen maar een veld wilde toevoegen. Sommige van dergelijke problemen zijn inderdaad mede dankzij client/server verdwenen. Maar andere problemen zijn juist erger geworden met als gevolg dat de onderhoudsbudgetten voor client/server over het algemeen hoger uitvallen dan de budgetten van de systemen die ze hebben vervangen. Het is helaas erg makkelijk een inflexibel systeem te bouwen met client/server-technologie.
De eerste oorzaak van inflexibiliteit is dat de meeste veranderingen in client/server-applicaties invloed hebben op veel componenten. Het probleem hierbij is dat de client- en server-componenten nauw (zoniet vast) aan elkaar gerelateerd zijn. In feite is sprake van het tegengestelde van ‘loose coupling’. Probeer maar eens een veld aan een client/server-systeem toe te voegen. Dan ben je gedwongen veranderingen aan te brengen en te coördineren in de presentatie-, applicatie logica- en databeheerlagen. Daarna moet nauwgezet worden getest of alles goed werkt, iets wat zelden eenvoudig is in client/server.
De tweede, meer fundamentele oorzaak van de inflexibiliteit is dat client/server zich richt op technologische flexibiliteit, en niet op de bedrijfsgeörienteerde flexibiliteit die een onderneming echt wil. Informatiesystemen zijn als duikplanken. Ze zijn flexibel in sommige richtingen, maar niet in andere. Iedereen die wel eens met enige snelheid de zijkant van een duikplank heeft geraakt, kan dat bevestigen. Bedrijfsgeoriënteerde flexibiliteit ontstaat wanneer
- voor elk deelprobleem de beste software kan worden toegepast, ongeacht op welke platform deze draait of van welke leverancier de software afkomstig is;
- processturing en procesuitvoering van elkaar worden gescheiden, opdat een verandering in de procesgang snel realiseerbaar is;
- veranderingen in de informatiesystemen van klanten en leveranciers slechts tot aanpassingen in de eigen informatievoorziening nopen indien er functioneel iets wijzigt. Niet als de andere partij een ander pakket, databasemanagementsysteem, edi-software, browser of tekstverwerker gaat gebruiken.
Scheiding client en server
Mythe 2: client-componenten doen client-werk, server-componenten doen server-werk
Bij traditionele client/server worden de werkzaamheden van de client bepaald door de locatie ten opzichte van de middleware. Client-componenten kunnen alleen client-werk uitvoeren, en presentatie- en server-componenten kunnen alleen server-werk uitvoeren, zoals toegang krijgen tot databases. Einde verhaal.
In de praktijk is het echter niet zo eenvoudig. Er is geen goede reden aan te wijzen waarom een zogenaamde server-component de gebruiker niet direct om informatie zou vragen. Als u bijvoorbeeld een document faxt, dan moet de fax-component aan u vragen waar hij het document naar toe moet sturen, ongeacht of het een client- of server-component is. Als u software voor werkstroombeheer gebruikt om uw werk te organiseren, dan moet die software een venster openen op uw client-machine, elke keer als u een actie selecteert om uit te voeren. Het hoort niet uit te maken of de werkstroom dat doet vanaf een client of vanaf een server.
De klassieke client/server-architecturen promoten de vrijheid van de PC, maar ze verwaarlozen in hoge mate zijn meest wezenlijke bijdrage aan IT, namelijk de mogelijkheid via meerdere vensters met dezelfde gebruiker gelijktijdig te communiceren. Zonder vensters zou de verbazingwekkende veelzijdigheid van de moderne PC ondenkbaar zijn. Een eenvoudig voorbeeld illustreert dit. Stel dat het faxen van een document zou vereisen dat uw tekstverwerker alle daartoe benodigde codes bevat, in plaats van slechts een gestandaardiseerde faxkoppeling. Dat zou betekenen dat iedere leverancier een volledige tekstverwerker- en fax-oplossing zou moeten leveren om te kunnen concurreren. De kosten om op de markt te komen zouden daardoor sterk stijgen, hetgeen zou resulteren in minder concurrentie. Dat zou weer leiden tot minder functionaliteit tegen hogere prijzen, net als in het mainframe-tijdperk.
Via vensters krijgt een component informatie uit de eerste hand over de wens van de gebruiker. Client/server-denken leidt ertoe dat de server-componenten de benodigde informatie van de gebruiker slechts uit de tweede hand krijgen. Deze beperking maakt het veel moeilijker nieuwe functionaliteit toe te voegen, omdat nieuwe functionaliteit normaal gesproken het verzamelen en presenteren van nieuwe informatie vereist. Het is net alsof je iedere keer je moeder moet vragen of je je vriendin mag kussen. Met als resultaat dat je moeder je vriendin kust en jijzelf je moeder.
Communicatie
Mythe 3: Clients communiceren met servers, punt uit!
Traditionele client/server-architecturen veronderstellen dat client-componenten exclusief met server-componenten communiceren en vice versa.
De belangrijkste beperking van deze veronderstelling is dat het de communicatie tussen client-componenten onderling negeert. Weleens gehoord van een clipboard, of van het feit dat het eenvoudiger zou zijn systeemintegratie van legacysystemen uit te voeren in de presentatielaag? Niet alleen omdat daarvoor betere hulpmiddelen zijn, maar omdat dat de enige plek is waar de legacy-systemen samenkomen op één platform? Weleens gehoord van de presentatielaag als de ‘logische’ plaats voor het integreren van data, omdat uiteindelijk de relatie tussen verspreide informatiebronnen ‘in het oog van de waarnemer’ zit?
De tweede beperking van de veronderstelling dat servers alleen communiceren met clients, leidde al vroeg in de geschiedenis van client/server tot de concessie dat servers ook kunnen functioneren als clients. Communicatie tussen servers blijft echter nogal onnatuurlijk.
Van servers wordt verondersteld dat ze passief zijn: ze komen alleen in actie als een client hen vraagt iets te doen. De aanname dat een server spontaan iets zou doen, zoals een ordersysteem actie onderneemt als de voorraad beneden een bepaald niveau raakt, is eigenlijk wezensvreemd aan het client/server-concept. Denken volgens de client/server-benadering verblindt ontwikkelaars zowel met betrekking tot interacties tussen clients onderling als servers onderling.
Gedistribueerde database
Mythe 4: de gedistribueerde database is de heilige graal.
Een van de meest ironische aspecten in de geschiedenis van client/server is dat de voorstanders de meest inflexibele manier om informatiesystemen met elkaar te laten communiceren als de ultieme vorm van client/server hebben gepromoot: de gedistribueerde database. Bij een dergelijke database wordt elk stukje data (logisch gezien) één keer opgeslagen, maar de data is toegankelijk voor elke applicatie die de data nodig heeft. Het dbms zorgt ervoor dat de data beschikbaar is waar en wanneer dat nodig is, zonodig door meerdere kopieën van de data te onderhouden.
Op zich is het idee van een gedistribueerde database prachtig. Echter, applicaties die gebruik maken van een gezamenlijke database, of die nu gedistribueerd is of niet, hebben veel overeenkomsten met een Siamese tweeling: elke belangrijke wijziging van de een heeft vrijwel altijd aanzienlijke invloed op de ander. Uit bittere ervaring heeft de IT-industrie geleerd dat databases die teveel doelen dienen, heel snel inflexibel worden. In het begin van de jaren tachtig probeerden veel organisaties databases voor de hele onderneming op te zetten. Die mislukten bijna allemaal. De verschillende onderdelen van de organisatie vertikten het eenvoudigweg om lang genoeg stil te zitten om het beton hard te laten worden, of begonnen erin te hakken voor het goed en wel droog was. De gedistribueerde database, waarin dit probleem samenkomt met technische problemen, is daarom tegenwoordig nog steeds een antwoord op zoek naar een probleem.
Het is niet zo dat het delen van een gezamenlijke database nooit een goede oplossing is. Verre van dat. Waar de gedistribueerde database voor productie-applicaties mislukt is, daar is het gegevenspakhuis voor bedrijfskennis-toepassingen juist een succes. De basis voor dit succes schuilt in de erkenning dat er veel werk nodig is om ervoor te zorgen dat de data, die is verzameld voor een bepaald doel, ook geschikt wordt voor andere doelen. Dat wil zeggen dat data moet worden gecorrigeerd, verrijkt uit andere bronnen, geaggregeerd, opnieuw verpakt, opgeslagen in andere dbms’en die beter geschikt zijn voor – bijvoorbeeld – analyse, en toegankelijk worden gemaakt via andere indexen. Van al die taken heeft de gedistribueerde databasetechnologie slechts aandacht besteed aan het werken met indexen.
Een reden waarom gedistribueerde databasetechnologie toch door de voorstanders wordt gepromoot, is het feit dat de techniek een oplossing biedt voor het probleem van ’transactie-atomiciteit’. Met deze technologie kan men er zeker van zijn dat meerdere, functioneel bij elkaar horende mutaties worden uitgevoerd, en als dit niet lukt, dat alles weer in de oude staat wordt teruggebracht. Maar voor dit probleem bestaan inmiddels oplossingen die algemener toepasbaar en tevens flexibeler zijn. Met een werkstroombeheersysteem kan een cluster van gerelateerde mutaties worden opgesplitst in kleinere transacties, die gescheiden in de tijd zijn uit te voeren, eventueel door andere gebruikers en met gebruik van andere technologie. Mocht één van de transacties mis gaan, dan zal het werkstroombeheersysteem automatisch instructies starten om de overige transacties weer terug te draaien.
Omslag
Goede ideeën alleen zijn nooit genoeg, de timing moet ook goed zijn. Een huwelijk heeft alleen kans van slagen als de partners er klaar voor zijn. Tot voor kort was dit nu juist het probleem bij het ontwikkelen op basis van componenten. De technologie stond niet op het juiste niveau en de IT-industrie was er niet klaar voor. Nu is de juiste technologie beschikbaar om componenten te bouwen die kunnen samenwerken over een lan of wan, ongeacht verschillen in platform, client, server of wat dan ook. We beschikken over de technologie om processen te besturen, gescheiden van de taken die ze uitvoeren.
De IT-industrie is bovendien rijp voor het concept van het denken in componenten. Het concept is al met veel succes toegepast bij het bouwen van moderne desktop-omgevingen. Dankzij de opgebouwde ervaring is men nu bereid om op interfaces te standaardiseren in plaats van op functionaliteit. Dat is een niet te onderschatten bevrijding. Het is veel makkelijker om het met elkaar eens te worden over de weg waarlangs een oplossing wordt bereikt dan over elk detail van de oplossing.
Het feit dat niets het werken met componenten in de weg staat, wil niet zeggen dat het ontwikkelen op basis van componenten nu ook werkelijkheid is. Niets is moeilijker dan een bestaande denkwijze overboord gooien en volgens nieuwe inzichten systemen gaan bouwen. Om dat te doen moet worden afgerekend met de mythen uit het verleden. Pas dan valt te genieten van een manier van werken die vroeger verboden was.
Ontwikkelen op basis van componenten
Moderne informatietechnologie biedt enkele goede en handige manieren voor het toepassen van samenhangende en losse koppelingen om de complexiteit van informatiesystemen te verminderen. Hierdoor is het mogelijk applicaties op basis van componenten te testen, te implementeren, te onderhouden en te managen. De hieronder volgende principes zijn als richtlijnen te gebruiken.
Dit principe wordt toegepast bij werkstroomtechnologieën en software voor systeembeheer, om maar eens twee geheel verschillende IT-technieken te noemen. Bij de management van taken is het van belang om de taken in hun samenhang te bezien. Dit vereist een bredere aanpak dan nodig is voor het uitvoeren van taken, waar het gezichtsveld tot de betreffende taak beperkt kan blijven. Worden deze gezichtsvelden gecombineerd, dan zijn geïntegreerde oplossingen te realiseren van zaken die functioneel weinig cohesie vertonen. Zo’n oplossing is veel moeilijker te realiseren, terwijl er nauwelijks voordelen tegenover staan. Geïntegreerde oplossingen voegen slechts waarde toe waar er sprake is van cohesie.
Dit principe ligt aan de basis van het gegevenspakhuis, ‘message queueing’ en de aloude batch-verwerking. Toepassing van dit principe zorgt ervoor dat het makkelijker is te testen of alles werkt zoals behoort, doordat het testen telkens gefocust kan worden op een deel van de functionaliteit dat synchroon wordt uitgevoerd. Voor elke tester is dat een droombeeld: de input en de output is toegankelijk en de verwerking is beperkt van omvang.
Ook al is het verleidelijk om te denken dat jouw oplossing het beste voor iedereen is, anderen zien dat meestal niet zo. Het voorschrijven van de enige juiste oplossing leidt vaak tot meer gemiste kansen en energieverlies dan het in baten oplevert. Stelt u zich bijvoorbeeld voor dat iedereen het eens had moeten worden over dezelfde browser voordat het World Wide Web van start kon gaan! Overigens, Java is het ultieme voorbeeld van dit principe. Java is revolutionair omdat software-acquisitie voor het eerst in de geschiedenis van de IT een zaak is van degene met het probleem. Zo bepaalt mijn leverancier welke software (lees: Java-applets) ik draai om bij hem goederen te bestellen, en niet ikzelf. Wanneer wij zullen leren om deze revolutie ten volle toe te passen, zijn de mogelijkheden onbegrensd.
Hans Wierenga, managing consultant bij DCE Consultants
