Voor een optimale benutting van de mogelijkheden van client/server-computing is een drielaags-architectuur vereist. Hierin zijn de voordelen van client/server-computing te verenigen met die van object-oriëntatie. Koos Haakma en Kaj Untersalmberger schetsen de drie voorwaarden, waaraan dient te worden voldaan. Het resultaat is een fundament onder grootschalige informatiseringsprojecten in een heterogene omgeving.
Twee begrippen beheersten de afgelopen vijf jaar de informatiseringswereld: client/server-computing en object-oriëntatie. Was client/server-computing vijf jaar geleden nog een buzzword, waarvan de toepasbaarheid op grote schaal nog te bezien viel, op dit moment kan gesproken worden over een bewezen technologie die door veel grote organisaties omarmd is. Op basis van de client/server-architectuur hebben behalve de inmiddels traditionele data-servers, ook begrippen als groupware, werkstroombeheer, imaging en multimedia hun weg weten te vinden in de automatiseringsoplossingen van organisaties. Client/server-computing heeft daarmee in vele varianten een belangrijke bijdrage geleverd in de informatievoorziening van vele organisaties.
Ook object-oriëntatie heeft zich de laatste jaren doen gelden en is met name succesvol in grafische gebruikersinterfaces. Object-oriëntatie heeft echter de grote potentie op het gebied van herbruikbare functionaliteit, snelle ontwikkeltrajecten en directe aansluiting bij de belevingswereld van de gebruiker nog niet kunnen waarmaken. Het is dan ook de vraag op welke wijze de eigenschappen van object-oriëntatie beter benut kunnen worden.
De inrichting van een omgeving, waarin hoge eisen gesteld worden aan flexibiliteit, schaalbaarheid, integratie en beschikbaarheid van de geautomatiseerde systemen, kan alleen succesvol zijn wanneer deze plaatsvindt op basis van een client/server-architectuur, bestaande uit drie lagen. Vervolgens blijkt dat object-oriëntatie van nature aansluit op deze architectuur en deze vervolmaakt.
Client/server-computing
Client/server-computing is een samenwerkingsverband van twee of meer autonome processen met als doel het optimaal vervullen van een gezamenlijke taak. In een client/server-architectuur zijn dan ook altijd drie componenten vertegenwoordigd: een client-proces, een server-proces en de ‘/’. In een client-proces wordt een verzoek gedaan tot het uitvoeren van een bepaalde dienst. In een server-proces vindt de uitvoering van die bepaalde dienst plaats. De ‘/’ vormt de lijm tussen de client- en de serverprocessen en wordt in het algemeen aangeduid met middleware.
Behalve het onderscheid tussen client-processen en server-processen is het van belang om client/server-computing te positioneren in een drielaags applicatie-architectuur. De eerste laag – de zogeheten presentatielaag – is verantwoordelijk voor de gebruikersinteractie. De tweede laag is de verwerkingslaag, waarin de functionaliteit van een applicatie is ondergebracht. De derde laag is de gegevenslaag, die de gegevens opslaat welke bewerkt worden door de verwerkingslaag. Figuur 1 geeft schematisch de drie lagen weer van een applicatie-architectuur en hun onderlinge relatie.
Tweelaags versus drielaags
In de inmiddels algemeen geaccepteerde tweelaags client/server-architectuur worden de drie lagen verdeeld over de client- en de server-processen. De mogelijke tweelaags c/s-architecturen zijn door de Gartner Group in hun bekende model verwoord. In figuur 2 is de tweelaags-architectuur schematisch weergegeven.
De tweelaags-architectuur is op dit moment de meest toegepaste c/s-architectuur. Deze architectuur is met name succesvol in vergelijking met de traditionele (gecentraliseerde) mainframe- of mini-architectuur.
De tweelaags-architectuur biedt als voordeel dat het een snelle systeemontwikkeling mogelijk maakt, doordat rapid-application- development-principes zeer goed toegepast kunnen worden. Daarnaast biedt het goede integratiemogelijkheden op de desktop. Tevens is de schaalbaarheid ten opzichte van de traditionele omgeving behoorlijk toegenomen. En tenslotte bestaat de afhankelijkheid tussen de functionaliteit en de hardware eigenlijk niet meer door de afname van de hardware lock-in.
Daartegenover staat ook een aantal nadelen. Deze zijn terug te voeren op de toegepaste middleware. De tweelaags-architectuur maakt gebruik van een communicatiemechanisme dat sterk gerelateerd is aan het gebruikte ontwikkelhulpmiddel (proprietary remote procedure call) of het gebruikte dbms (remote dbms-mechanisme of stored procedure). Dit heeft tot gevolg dat er een afhankelijkheid ontstaat van de dbms-leverancier of van de toegepaste ontwikkelhulpmiddelen. Verder is de ontsluiting van bestaande systemen in deze architectuur slechts zeer beperkt mogelijk. Als belangrijkste nadeel geldt echter de rigiditeit die de tweelaags-architectuur met zich meebrengt. Al in een vroeg stadium van de ontwikkelings-levenscyclus wordt de keuze van de onderverdeling in een client-proces of server-proces gemaakt. Deze is niet zonder meer te wijzigen wanneer een verandering in een bedrijfsproces daarom vraagt. Dit beperkt de schaalbaarheid en flexibiliteit van de systemen in belangrijke mate.
Drielaags-architectuur
De drielaags client/server-architectuur heeft de voordelen van de tweelaags-architectuur maar kent de genoemde beperkingen niet. In een drielaags c/s-architectuur wordt namelijk een enorme flexibiliteit bereikt door de volledige ontkoppeling van de presentatie- en de gegevenslaag van de verwerkingslaag en het gebruik van geavanceerde en bovenal gestandaardiseerde middleware.
In de drielaags c/s-architectuur worden alle services op een gestandaardiseerde wijze aangeboden. In deze architectuur ontstaat zo een netwerk van diensten die door de verschillende presentatiecomponenten gebruikt kunnen worden. Op deze wijze is het bijvoorbeeld mogelijk om vanuit zowel een grafisch gebruikersinterface als vanuit een voice-response interface dezelfde functionaliteit te benaderen, zie figuur 3.
Een voorbeeld van een succesvolle drielaags-architectuur is een systeem dat bij een grote vastgoedbeheerder in de VS werd geïmplementeerd. Het bedrijf bestaat uit een hoofdkantoor en een aantal vestigingen. Voor iedere vestiging werken enkele makelaars of beheerders vanuit kantoor of vanuit huis. Het hoofdkantoor beheert een bestand met woningen, huur- en koopprijzen, contracten, enzovoort, dat geïmplementeerd is in een gegevenslaag. De verwerkingslaag bevat functies voor opvraging van informatie uit de verschillende bestanden, zoals het opvoeren van contracten en het leggen van een verbinding met een andere vestiging. In de presentatielaag zijn alle invoer- en opvraagschermen gerealiseerd. Ook de fysieke implementatie bestaat in dit geval uit drie lagen. De gegevenslaag en de verwerkingslaag zijn geïmplementeerd op een NT-server. De gegevenslaag en verwerkingsfuncties op het hoofdkantoor zijn verbonden door middel van een local area network. Het hoofdkantoor en de overige vestigingen zijn verbonden via Internet. Voor makelaars die vanaf kantoor werken is de presentatielaag geïmplementeerd op OS/2-PC’s die via een lan met de verwerkingslaag-server verbonden zijn. Voor hen die vanuit huis werken, is de presentatielaag geïmplementeerd op OS/2-laptop’s die via Internet verbonden zijn met hun vestiging. Zodoende is de vastgoedbeheerder in staat om dezelfde functionaliteit in verschillende fysieke omgevingen te gebruiken zonder die in iedere fysieke omgeving opnieuw te implementeren.
Middleware
In de drielaags client/server-architectuur worden hoge eisen gesteld aan de gebruikte middleware die de interactie tussen de verschillende componenten verzorgt. De middleware dient in staat te zijn om netwerk-breed te zorgen voor de communicatie tussen de diverse componenten en voor de integratie van elementaire verwerkingen tot diensten. Daarnaast dient de middleware zorg te dragen voor een aantal ondersteunende services zoals naming, timing en security. Om dit te bereiken worden alle componenten voorzien van een gestandaardiseerde communicatie-interface.
Hiermee wordt bereikt dat de componenten volledig onafhankelijk van de onderliggende hardware en netwerken ontwikkeld kunnen worden. Dit heeft tot gevolg dat componenten probleemloos verplaatst kunnen worden naar andere platformen. Wanneer de middleware aansluit bij geldende standaarden, is bovendien gebruik te maken van componenten die buiten de organisatie ontwikkeld worden.
De drielaags-architectuur maakt het mogelijk om een schaalbare informatievoorziening op te zetten. Hierbij vindt integratie van diverse toepassingen op de desktop probleemloos plaats. Ook kunnen bestaande systemen geïntegreerd worden met behulp van de gestandaardiseerde interface. Op basis van de drielaags c/s-architectuur bestaat de mogelijkheid om een informatievoorziening in te richten, bestaande uit een aantal gespecialiseerde componenten die optimaal zijn af te stemmen op de bestaande IT-resources.
Object-oriëntatie
Het idee achter object-oriëntatie is een systeem dat bestaat uit samenwerkende objecten. Een object bevat eigen gegevens en kan bepaalde diensten (methods of ‘methoden’) uitvoeren.
Het belangrijkste voordeel van object-oriëntatie bestaat uit de mogelijkheid om softwarecomponenten opnieuw te gebruiken, hetgeen leidt tot kostenverlaging en produktiviteitsstijging bij de ontwikkeling en onderhoud van software. Daarnaast verhoogt hergebruik de kwaliteit omdat de gebruikte componenten reeds getest zijn.
Object-oriëntatie bezit een aantal eigenschappen dat van nature aansluit op de drielaags c/s-architectuur. Deze eigenschappen hebben betrekking op classificatie, communicatie en toewijzing van objecten.
Classificatie
Classificatie houdt in dat de object-klassen worden ondergebracht in een raamwerk op basis van de functionaliteit die zij bieden. Bij het samenstellen van nieuwe applicaties is dan gebruik te maken van reeds ontwikkelde objecten.
Terwijl dit concept al wordt toegepast op domeinen als het bouwen van gui-software gebaseerd op de Windows API (bijvoorbeeld Microsofts Foundation Classes), kan het ook naar een hoger niveau worden getild met object-klassen voor bepaalde bedrijfsfuncties. Een aantal bedrijven legt zich nu al toe op het creëren van een raamwerk van client- en server-objecten. Een voorbeeld hiervan is een verzameling accounting functies, bestaande uit gemaskerde text-controls of objecten voor valutaconversies om verschillende valuta in te kunnen voeren of presenteren. Andere voorbeelden zijn objecten voor het vaststellen van belastingtarieven of het opslaan van bankrekeningen. Een ontwikkeling die in dit rijtje niet mag ontbreken zijn de commercieel verkrijgbare VBX’en die in een keur van ontwikkelhulpmiddelen gebruikt kunnen worden.
Naast de functionele classificatie van de objecten is het mogelijk om de classificatie te relateren aan de drielaags client/server-architectuur. Hierbij ontstaat een classificatie van objecten in interface-, business- en service-objecten. Interface-objecten kapselen het specifieke gedrag van de gebruikersinterface in; zij komen overeen met de presentatielaag. Business-objecten bevatten de eisen van een bedrijfsproces (verwerkingslaag). Service-objecten omvatten een grote categorie van objecten die onder andere bestaat uit de zogenaamde persistente objecten. Deze kapselen de opslag van gegevens in een relationeel of object-georiënteerd dbms in. Daarnaast bestaat deze categorie uit objecten die een verscheidenheid aan services uitvoeren. Een voorbeeld van een service is het ontsluiten van bestaande systemen door gebruik te maken van zogenaamde object wrappers. Deze pakken de bestaande applicatie in, zodanig dat een deel van de applicatie zich manifesteert als object. Figuur 4 geeft een schematische weergave van een indeling in een raamwerk.
Communicatie
Objecten beschikken alle over een gestandaardiseerde interface, die het mogelijk maakt de communicatie tussen de objecten op eenduidige wijze tot stand te brengen. Door de gestandaardiseerde interface kunnen alle objecten op dezelfde wijze worden gelokaliseerd, ‘geïnstantieerd’ en benaderd. In een c/s-omgeving communiceren objecten met elkaar op basis van deze gestandaardiseerde interface. Deze communicatie vindt plaats door middel van een ‘makelaar’, die een message van een vragend object (client) afbeeldt op de method van het uitvoerende object (server). Deze makelaars worden aangeduid als object request broker (orb). Met behulp van een orb is vast te stellen of een object bestaat, waar het zich bevindt en welke methoden het bevat. Daarnaast kunnen kopie-objecten gedefinieerd worden voor een betere verdeling van de werklast of als uitwijkmogelijkheid in gevallen waarin het oorspronkelijke object niet beschikbaar is. In figuur 5 is het mechanisme van een orb schematisch weergegeven.
Wellicht de bekendste orb is object linking and embedding (ole) van Microsoft. Iedere applicatie die zich conformeert aan de ole- standaard kan gebruikt worden als server-object door applicaties die vragen stellen conform de ole-standaard (client-objecten). Een andere bekende standaard is de common object request broker architecture (corba) die gedefinieerd is door de object management group. De corba-standaard wordt gedefinieerd met instemming van hard- en softwareleveranciers en kan derhalve opereren in een heterogene omgeving van hard- en (systeem)software. Een aantal grote leveranciers heeft al orb’s geïmplementeerd die voldoen aan de corba-standaard. Voorbeelden zijn IBM (Dsom), Forté Software (Forté), Software AG (Entire Broker), Dec (Object Broker) en ICL (Daise).
Toewijzingsfunctionaliteit
Toewijzing houdt in dat de objecten worden afgebeeld op een fysieke omgeving van één of meer platformen die verbonden zijn door één of meer netwerken. Toewijzing biedt een aantal voordelen. Allereerst kunnen op deze wijze verschillende modellen doorgerekend worden met betrekking tot prestatie. Verplaatsing van objecten naar een ander platform kan een enorme prestatieverbetering betekenen. Daarnaast kunnen objecten gerepliceerd worden over verschillende machines om zodoende de werklast te verdelen. Een ander doel dat met deze techniek wordt bereikt, is vergroting van de beschikbaarheid van objecten door ze aan een non-stop platform toe te wijzen dan wel te repliceren op verschillende platformen. Tenslotte kan het voorkomen dat in een heterogene omgeving dezelfde functionaliteit beschikbaar moet zijn op verschillende platformen. Hierbij valt ondermeer te denken aan interface-objecten die beschikbaar moeten zijn in een Windows-gui en een Motif-gui.
Deze derde eigenschap van objecten wordt aangeduid met de termen deploy en partitioning. Bij het ontwerp en de bouw van een c/s-omgeving is het belangrijk dat ‘partitioning’ en ‘deploy’- beslissingen op ieder moment in de synchronous data link control (sdlc) genomen kunnen worden. In sommige i-case- en c/s-ontwikkeltools is deze beslissing uitsluitend in het begin van het ontwerptraject te nemen en ligt de ‘partitioning’ van de applicatie (objecten) en de ‘deploy’ daarmee vast. Een wijziging van de ‘partitioning’ heeft dan tot gevolg dat er opnieuw gecodeerd moet worden. Een aantal c/s-tools uit de tweede generatie is in staat om de ‘partitioning’- en ‘deploy’-functie op ieder moment in de sdlc te wijzigen.
Fundament
Om de voordelen van client/server-computing volledig te benutten dient een drielaags c/s-architectuur ingericht te worden op basis van gedistribueerde objecten. In deze architectuur is het mogelijk om de voordelen van de c/s-computing te verenigen met die van object-oriëntatie. Er dient dan aan drie voorwaarden voldaan te worden. Ten eerste dient de classificatie van de object-klassen op zodanige wijze plaats te vinden dat (her)gebruik van de componenten in een drielaags c/s-omgeving mogelijk is. Dit leidt tot een classificatie van de objecten in interface-, business- en service-objecten. Ten tweede dienen alle objecten te beschikken over een gestandaardiseerde interface. Op basis van deze gestandaardiseerde interface vindt de communicatie tussen de objecten plaats door middel van een corba-compliant communicatiemechanisme. Tenslotte dienen de tijdens het ontwikkel- en implementatietraject gebruikte hulpmiddelen te beschikken over de genoemde toewijzingsfunctionaliteit. Hierdoor kunnen ontwerpers applicaties samenstellen uit herbruikbare objecten, terwijl zij minder kennis hoeven te hebben van de onderliggende technologie.
Wanneer aan deze drie voorwaarden is voldaan, ontstaat een c/s-architectuur waarin herbruikbare objecten – voorzien van een gestandaardiseerde interface – onafhankelijk van elkaar en van de onderliggende platformen met elkaar samenwerken om invulling te geven aan iedere gewenste functionaliteit. Deze ’toekomstvaste’ architectuur – waarin de voordelen van zowel client/server-computing als object-oriëntatie verenigd zijn – zal in een heterogene, continu veranderende omgeving dienen als het fundament onder grootschalige informatiseringsprojecten.
Koos Haakma en Kaj Untersalmberger zijn werkzaam als consultant bij DCE Nederland.
