Vision

Bij het ontwerpen en realiseren van informatiesystemen spelen architecturen een grote rol. Het begrip architectuur heeft in de IT twee betekenissen: de architectuur van een specifiek systeem en architectuur als bouwstijl.

De architectuur van een specifiek systeem
De architectuur is een model dat aangeeft hoe een systeem globaal is onderverdeeld in samenstellende delen, en op welke wijze deze delen samenwerken om de functies van het geheel te realiseren. Doorgaans is sprake van een verzameling modellen die de totale architectuur van een systeem weergeven. In het geval van bedrijfsvoering en IT zijn afzonderlijke modellen nodig voor de architectuur van de bedrijfsprocessen en bedrijfsobjecten, de toepassingen en de computerapparatuur. De modellen kunnen statisch zijn, zoals een datamodel en de samenstelling van de hardware. Tegenwoordig zijn met simulatietools ook dynamische modellen mogelijk, zoals simulatie van de werking van een bedrijfsproces of van de werking van hardwarecomponenten.

Architectuur als bouwstijl
Een architectuur als bouwstijl is een verzameling regels die aangeeft hoe we systemen uit componenten kunnen samenstellen. Er gelden standaarden voor de werking van de componenten en vooral voor de onderlinge aansluiting van de componenten.

Deze paragraaf behandelt architectuur als bouwstijl, en in het bijzonder de architectuur van toepassingen. De opkomst van netwerksystemen is de reden dat toepassingsarchitecturen sterk in de belangstelling staan. De hardware van een netwerksysteem bestaat uit werkstations (bijvoorbeeld PC's) die via een netwerk in verbinding staan met computers in de rol van server (bijvoorbeeld midrange computers of een mainframe).

De netwerkarchitectuur van hardware brengt met zich mee dat we toepassingen kunnen ontwikkelen die uit verschillende componenten bestaan, die op verschillende computers in het netwerk draaien en onderling boodschappen uitwisselen.

Om dit soort toepassingen te kunnen bouwen, zijn van tevoren afspraken nodig over de componenten waaruit een toepassing kan bestaan, op welke computers de componenten kunnen draaien en hoe zij onderling communiceren. Er is dus een toepassingsarchitectuur, een bouwstijl, nodig die voorschrijft hoe de ontwikkelaars deze gedistribueerde toepassingen dienen te construeren.

Afbeelding 4.5 Netwerkarchitectuur van de hardware.

We behandelen twee toepassingsarchitecturen voor netwerksystemen. De eerste is de client/server architectuur, die op dit moment sterk in opkomst is. Deze gaat uit van toepassingen in de vorm van bestaande on line-programma's en geeft aan hoe deze toepassingen verdeeld kunnen worden over werkstations en servers.

De tweede architectuur die we beschrijven is gebaseerd op objectoriëntatie. Kenmerkend voor deze architectuur zijn autonome actieve objecten op verschillende computers, die onderling samenwerken. Deze architectuur hebben we de naam Collaborative Object Architecture gegeven.

4.5.1 Client/server-architectuur

Bij de client/server-architectuur bestaat een toepassing ten minste uit een component op het werkstation - de client - die gebruik maakt van diensten van componenten - de servers - op de midrange computers of het mainframe.

Afbeelding 4.6 De vijf typen van client/server-architectuur (bron Gartner Group).

In de client/server-architectuur zijn clients en servers aparte programma's. Om een toepassing uit te voeren, start de gebruiker op zijn werkstation de client op. Een client start via een aanroep een server op de servercomputer.

Wat de taakverdeling tussen de client en de server betreft, maakt de Gartner Group een onderscheid in vijf typen. Deze baseert zij op het feit dat een toepassing bestaat uit drie functies, te weten de presentatie naar de gebruiker, de toepassingslogica van de feitelijke verwerking en het datamanagement voor het raadplegen en muteren van gegevens in de database.

De vijf typen client/server worden hieronder kort beschreven.

Gedistribueerde presentatie
Bij deze oplossing zit bijna alle intelligentie in de server. Het werkstation verzorgt alleen een deel van de presentatie. Een voorbeeld is een toepassing op een mainframe met presentatie in de vorm van een Character User Interface op het werkstation. Deze vorm van client/server is niet zo interessant, omdat het bijvoorbeeld niet mogelijk is voor een server op een mainframe een Graphical User Interface op een PC aan te sturen.

Remote presentatie
Bij deze oplossing verzorgt de client de presentatie op het werkstation bij voorkeur via een GUI, terwijl de server de toepassingslogica en het data management voor zijn rekening neemt. De toepassingslogica moet wel de presentatie op de GUI goed kunnen aansturen. Dit is niet mogelijk wanneer de server een conventioneel transactieprogramma is op het mainframe.

Gedistribueerde toepassingslogica
Deze oplossing deelt de toepassingslogica in tweeën. De client verzorgt naast de presentatie vooral de proceslogica van de toepassing, zoals het tonen en afhandelen van windows via de GUI. De server verzorgt naast het data management ook de gegevenslogica van de toepassing, zoals het lezen en muteren van gegevens inclusief controles en beveiligingen. Deze oplossing is uitstekend geschikt voor een client op de PC met presentatie via een GUI en één of meer servers op een mainframe of midrange computers in de vorm van een conventioneel on line-transactieprogramma (echter zonder presentatie). De server kan ook gerealiseerd worden als zogenaamde remote procedure van een relationeel DBMS.

Remote DBMS
Bij deze oplossing zit alle intelligentie van de toepassing op de client. De server is in feite een DBMS. Deze oplossing is op het moment heel gebruikelijk in PC-LAN omgevingen met een PC of midrange computer als server. Op de server is een relationeel DBMS geïnstalleerd. De clients op de werkstations communiceren met een relationeel DBMS via SQL-opdrachten.

Gedistribueerd DBMS
Deze vorm van client/server komt nauwelijks voor, omdat DBMS'en een gedistribueerde database nog niet goed ondersteunen.

Welk type cliënt/server-architectuur het meest geschikt is, hangt sterk af van de toepassingssituatie.

4.5.2 Collaborative Object Architecture

De hiervoor beschreven vormen van client/server-architectuur hebben als nadeel dat zij voor één type toepassing gelden, namelijk een on line-transactie waarmee een gebruiker gegevens in de database raadpleegt en muteert.

Twee belangrijke vormen van toepassingen zijn daarom niet mogelijk:

• 'groupware' toepassingen, die bijvoorbeeld het communiceren en samenwerken van verschillende gebruikers ondersteunen;
• gedistribueerde toepassingen met (massieve) parallelle verwerking, die ook als vervanging kunnen dienen van bestaande batch-toepassingen.

In beide gevallen gaat het om toepassingen die we met netwerksystemen uitstekend kunnen ondersteunen.

Een tweede punt is dat in de client/server-architectuur een toepassing nog steeds een programma is, waarbij de gegevens gescheiden staan opgeslagen in een DBMS. Dit betekent dat we zowel programma's als gegevens apart moeten distribueren over het netwerk. Juist in een gedistribueerde omgeving heeft het daarom voordelen objecten als toepassingen te hebben. In dat geval kunnen we objecten als eenheden van gegevens, functies en interface distribueren over het netwerk.

We moeten streven naar een architectuur waarbij de verschillende toepassingscomponenten in een andere vorm samenwerken.Bij de huidige client/server-architectuur heeft deze samenwerking de vorm van Cooperative Processing. Dit is de benaming voor de samenwerking in een toepassing tussen een client, bijvoorbeeld op een werkstation, met één of meer servers op bijvoorbeeld een mainframe of midrange computer. De gebruiker start de client op, die op zijn beurt de servers aanroept. De samenwerking is dus 1 op n tussen client en servers. Het is een vorm van hiërarchische samenwerking. De client en de gebruiker wachten in principe tot de server antwoord geeft. De server is niet in staat bijvoorbeeld gedurende lange tijd zelfstandig een opdracht uit te voeren, of de hulp in te roepen van een andere gebruiker, als hij een opdracht krijgt die hij niet kan uitvoeren.

Waar we naar toe gaan is een architectuur met Collaborative Processing. Dit is de benaming voor een n op m samenwerking tussen zelfstandige toepassingscomponenten. Deze samenwerking is mogelijk tussen autonome, zichzelf besturende objecten die zich op dezelfde computer of verschillende computers in het netwerk bevinden en onderling communiceren. Een dergelijk autonoom object noemen we een actief object (Engelse benaming agent). Kenmerkend voor een toepassing die uit actieve objecten bestaat is dat deze objecten gelijktijdig parallel in werking kunnen zijn op verschillende locaties in het netwerk.

Actieve objecten kunnen als server voor de gebruikers opdrachten uitvoeren waarbij zij zelf bepalen wanneer zij de opdrachten uitvoeren. De actieve objecten kunnen met elkaar communiceren, waarbij zij elkaar over en weer vragen stellen en deze vragen beantwoorden. Actieve objecten kunnen ook via de interface contact zoeken met een gebruiker en hem een bepaalde vraag stellen of een bericht voor hem presenteren.

Afbeelding 4.7 laat de architectuur zien die collaborative processing tussen objecten ondersteunt. We hebben de architectuur de benaming Collaborative Object Architecture gegeven.

Afbeelding 4.7 Collaborative Object Architecture.

De toepassingen bestaan bij deze architectuur uit drie soorten objecten: interface-objecten, procesobjecten en domeinobjecten.

Interface-objecten
De interface-objecten verzorgen de mens/computer-interactie via een GUI of een multimedia interface. Ook zijn er interface-objecten voor de communicatie met printers en scanners.

Procesobjecten
De procesobjecten ondersteunen de processen die de gebruikers uitvoeren. Een voorbeeld van een procesobject is een elektronisch werkdossier dat het uitvoeren van een administratief proces door verschillende gebruikers ondersteunt. Procesobjecten kunnen onderling communiceren, waardoor zij in staat zijn communicatie tussen processen en tussen gebruikers te ondersteunen. Een procesobject kan actief zijn in de voorgrond, waarbij hij via de interface-objecten communiceert met een gebruiker of in de achtergrond, waarbij hij communiceert met andere procesobjecten.

Veel procesobjecten corresponderen met bedrijfsprocessen, waarvan zij het geautomatiseerde deel van de uitvoering verzorgen.

Domeinobjecten
De domeinobjecten bevatten gegevens die betrekking hebben op een bepaald toepassingsdomein, bijvoorbeeld klanten, produkten en contracten. De gebruikers willen deze gegevens langere tijd bewaren en gebruiken in de processen die zij uitvoeren. Deze domeinobjecten hebben dus een persistent karakter.

Veel domeinobjecten corresponderen met bedrijfsobjecten, waarvan zij de geautomatiseerde functies uitvoeren, inclusief het vastleggen van gegevens.

De Collaborative Object Architecture is eigenlijk een client/server/server-architectuur bestaande uit clients in de vorm van interface-objecten, processervers in de vorm van procesobjecten en dataservers in de vorm van domeinobjecten. Het is een variant op de 'gedistribueerde toepassingslogica', met drie lagen:

• presentatielogica voor een GUI of MUI;
• proceslogica;
• gegevens met logica voor raadplegen en bewerken.

Actieve Objecten
Het essentiële verschil tussen de architecturen zit in de laag extra proceslogica die bestaat uit procesobjecten. Deze procesobjecten zijn actieve objecten, die hun eigen real-time besturing verzorgen. Het verschil tussen actieve objecten en normale 'passieve' objecten zit in de wijze waarop zij een vraag van de gebruiker via interface-objecten, of een vraag van een ander procesobject afhandelen.

Een passief object handelt een vraag direct af en geeft onmiddellijk een resultaat terug. Het stellen van een vraag aan een passief object werkt voor de vrager als een subroutine-aanroep waarbij hij op het antwoord van het object moet wachten.

Een actief object kan als het ware 'klok kijken' en daardoor zelf bepalen wanneer hij een vraag afhandelt. Passieve en actieve objecten zien de aan hen gestelde vragen als events die zij moeten afhandelen. Een passief object doet dit onmiddellijk, maar een actief object bepaalt zelf het moment van afhandelen. Het resultaat is dat de toepassingen niet alleen een event-driven maar ook een real-time karakter krijgen. Een actief object handelt twee soorten events af: externe events en interne events.

Extern event
Een extern event is een vraag aan het actieve object die afkomstig is van een gebruiker, via een interface-object, of van een ander actief object. Het actieve object kan meer vragen tegelijk aangeboden krijgen en zelf beslissen wanneer hij een vraag afhandelt en wanneer hij het antwoord teruggeeft. De gebruiker of het andere actieve object dat de vraag stelt, wacht niet op antwoord. Wanneer het actieve object de vraag heeft afgehandeld, toont het via een interface-object een antwoord aan de gebruiker, of het stuurt een antwoord terug naar het andere actieve object.

Het actieve object heeft diverse mogelijkheden ten aanzien van het tijdstip waarop het een vraag afhandelt. Het kan een vraag net als een passief object direct beantwoorden. Het kan vragen van hetzelfde soort opsparen en later in één keer als een soort batch verwerken. Ook kan het een vraag op een later tijdstip afhandelen. Dit geeft de gebruiker de mogelijkheid een actief object een opdracht te geven die het bijvoorbeeld de volgende dag, of wekelijks, uitvoert. Een actief object is geschikt om vragen te beantwoorden waarvan de afhandeling erg veel tijd kost, omdat de gebruiker niet hoeft te wachten op antwoord.

Een actief object kan ook het verloop van een proces besturen waarbij meer gebruikers betrokken zijn. De eerste gebruiker start het actieve object op, waarna het object volgens 'dienstregeling' het proces afhandelt en via interface-objecten andere gebruikers bij het proces betrekt.

Intern event
Actieve objecten kunnen ook actief worden op basis van een zogenaamd intern event. Wanneer het actieve object een vraag op een later tijdstip afhandelt, plaatst het als het ware een reminder op een interne agenda. Bij het verstrijken van het tijdstip wordt het object actief en handelt het de vraag af. Hetzelfde mechanisme is bruikbaar voor een vraag met een opdracht iets periodiek af te handelen, bijvoorbeeld de opdracht jaarlijks de rente van een spaarrekening te berekenen.

Wanneer een actief object een vraag stelt aan een ander object zonder te wachten op antwoord, zet het een reminder in de agenda wanneer het antwoord verwacht. Wanneer het antwoord tijdig terugkomt (dat is ook een extern event) vervalt de reminder. Komt het antwoord niet tijdig, dan is het verstrijken van het tijdstip een intern event en treedt een foutafhandeling in werking. Dit mechanisme is ook toepasbaar voor het bewaken van het tijdig antwoorden van klanten.

Ondersteunende functies voor actieve objecten
Afbeelding 4.8 geeft de werking weer van een geautomatiseerd systeem volgens de Collaborative Object Architecture. De implementatie maakt gebruik van drie ondersteunende functies om de actieve objecten op de wijze te laten functioneren, zoals hiervoor is beschreven. Deze ondersteunende functies zijn op iedere computer in het netwerk beschikbaar, waardoor distributie van de objecten over werkstations en servercomputers mogelijk is.

Afbeelding 4.8 Werking geautomatiseerd systeem met actieve objecten.

De ondersteunende functies zijn het Object Base Management System (OBMS), de communicatiefunctie en de transactiebesturing.

Objectbase Management Systeem (OBMS)

Alle toepassingen krijgen ook ondersteuning van een OBMS, waarin alle gegevens en functies van de objecten zijn opgeslagen. Het OBMS dient als parkeerplaats voor alle (actieve en passieve) objecten die tijdelijk niets te doen hebben. Een voorbeeld is een actief object dat een vraag heeft uitstaan naar een ander object en wacht op antwoord. Het besturingssysteem start het weer zodra er antwoord komt, of zodra op een bepaald tijdstip geen antwoord is gekomen.

De communicatiefunctie
De communicatiefunctie ondersteunt de communicatie tussen actieve objecten. De actieve objecten kunnen zich op dezelfde computer bevinden of op verschillende computers in het netwerk. De functie ondersteunt wachtrijen met vragen en antwoorden tussen actieve objecten. Dit is nodig, omdat actieve objecten van verschillende kanten vragen kunnen krijgen. Verder kunnen zij vragen hebben uitstaan naar andere objecten waarvan de antwoorden ook tegelijkertijd kunnen terugkomen. Het actieve object heeft de wachtrijen nodig om zelf te kunnen bepalen wanneer hij de vragen of terugkomende antwoorden in behandeling neemt. De communicatiefunctie kan verder allerlei services bieden voor telecommunicatie, zoals het zoeken van personen en locaties in het netwerk.

De transactiebesturing
Er moet een algemene transactiebesturing zijn (het liefst als onderdeel van het besturingssysteem) die het starten van actieve objecten regelt bij het optreden van een extern of intern event. De transactiebesturing start een actief object uit het OBMS wanneer de communicatiefunctie een vraag of een terugkomend antwoord voor het actieve object in een wachtrij plaatst. Dit starten kan gebeuren op basis van prioriteit of wanneer een bepaald aantal vragen in de wachtrij staat. De transactiebesturing start een actief object ook wanneer een gebruiker via een interface-object voor de eerste keer een vraag stelt. Verder verzorgt de transactiebesturing het starten van een actief object uit het OBMS wanneer een actie op de agenda moet worden uitgevoerd. De transactiebesturing zorgt als het ware voor een 'klok' waarop het actieve object kan zien dat het tijd is bepaalde acties uit voeren. Ook heeft hij een wekkerfunctie die het object activeert wanneer het op een bepaald tijdstip iets moet uitvoeren.

Samenstelling actief object
Net als een gewoon object bestaat een actief object uit gegevens en functies, alleen kent het actieve object naast uitvoerend ook besturend gedrag.

Het actieve object bevat daartoe naast inhoudelijke gegevens met bijbehorende uitvoerende functies ook besturingsgegevens en besturingsfuncties. Het actieve object is in feite een cluster van objecten, flexibel samengesteld uit besturingsobjecten en inhoudelijke objecten.

Objecten waar een actief object gebruik van maakt kunnen bijvoorbeeld zijn:

• een 'agenda', waarin het object bijhoudt welke toekomstige opdrachten het moet uitvoeren;
• een 'journaal', waarin het object bijhoudt welke opdrachten het heeft uitgevoerd;
• een 'dienstregeling' voor een uit te voeren proces bij actieve objecten die een compleet proces besturen;
• een 'kennissenkring' van gebruikers en andere actieve objecten, interface-objecten en domeinobjecten, die het object kent en waarmee het mag communiceren;
• geografische kennis over locaties in het computernetwerk;
• de 'samenstelling' van het actieve object uit besturingsobjecten en inhoudelijke objecten.

Toepassingsmogelijkheden van actieve objecten
De mogelijkheden van actieve objecten laten zich het beste illustreren aan de hand van een aantal toepassingsmogelijkheden.

Elektronisch werkdossier
Een actief object in de vorm van een elektronisch werkdossier ondersteunt de procesbesturing (workflow) en de uitvoering van een administratief proces door verschillende medewerkers. Zie hoofdstuk 3 voor een beschrijving van de inhoud en de werking van een werkdossier.

Elektronische agenda
In een actief object in de vorm van een elektronische agenda kan de gebruiker zijn afspraken vastleggen. De agenda houdt bij waar de gebruiker zich bevindt, op welk werkstation hij actief is en of hij via telefoon of fax bereikbaar is.

Complexe zoekopdrachten
Een gebruiker kan met behulp van actieve objecten als processerver complexe zoekopdrachten in het netwerk uitzetten. Dit kan het zoeken naar gegevens, personen en locaties betreffen. Een actief object op de eigen locatie stuurt daarbij opdrachten naar actieve objecten op andere locaties, bijvoorbeeld om eerst te achterhalen waar bepaalde gegevens zich bevinden om vervolgens deze gegevens op die locaties te laten ophalen.

Procesbesturing en monitoring
Een actief object kan ook functies zoals het besturen en monitoren van processen uitvoeren. In een industriële omgeving wordt het actieve object via interfaces gekoppeld aan het te besturen fabricageproces. Het actieve object registreert het procesverloop en bestuurt het proces op basis van tijd, voorgeschreven procesverloop en condities die optreden tijdens het proces.

Elektronische markten
Een netwerk van actieve objecten kan ook een elektronische markt vormen, waarbij de actieve objecten als aanbieder optreden namens een aanbiedende partij of als vrager namens een vragende partij.

Parallelle verwerking
Actieve objecten ondersteunen de besturing van parallelle verwerking. Een actief object kan parallel opdrachten geven aan andere actieve objecten of aan domeinobjecten. Wanneer deze objecten op verschillende processors draaien, is parallelle verwerking van de opdrachten mogelijk. Het actieve object wacht tot het antwoord heeft van alle objecten en zet daarna zijn proces voort. Deze parallelle gedistribueerde verwerking kan ook dienen om bestaande omvangrijke batch-systemen op één centrale computer te vervangen, zoals boekingssystemen bij banken. Een aantal van deze systemen gaat het probleem krijgen dat ze de groeiende hoeveelheid dagelijkse transacties niet meer in 24 uur kunnen verwerken.

4.5.3 Middleware

Om toepassingen volgens de client/server-architectuur en de Collaborative Object Architecture te kunnen realiseren, is speciale programmatuur nodig die een brug slaat tussen de besturingssystemen van de computers en netwerken enerzijds en de clients en servers van de toepassingen anderzijds. Deze programmatuur heeft de benaming middleware. Middleware behoort het ontwerpen, ontwikkelen, beheren en uitvoeren van de gedistribueerde toepassingen over diverse hardware platformen te ondersteunen.

De belangrijkste onderdelen van de middleware voor de client/server-architectuur zijn :

• een relationeel DBMS;
• een TP-monitor voor transactiebesturing (indien deze niet door DBMS of besturingssysteem wordt gedaan);
• software voor netwerkcommunicatie tussen clients en servers;
• tools voor netwerkbeheer;
• software voor GUI's;
• ontwikkeltools voor clients en servers;
• tools voor gedistribueerd configuratiebeheer en versiebeheer van software en databases;
• tools voor het op afstand installeren en beheren van software en databases.

Op dit moment is er een grote keuze aan middleware van een groot aantal leveranciers. Voor de gebruiker is het moeilijk te kiezen en er is ook geen sprake van een standaard. Bovendien is middleware op een aantal essentiële punten nog in ontwikkeling. Dit betreft:

• het ondersteunen van gedistribueerde serverlogica door DBMS'en (eventueel in combinatie met een gedistribueerde TP-monitor);
• configuratie- en versiebeheer;
• software distributie;
• beveiliging van het netwerk en de gedistribueerde database;
• portabiliteit van software, waardoor clients en servers eenvoudig op verschillende typen hardware geïnstalleerd kunnen worden;
• het combineren van maatwerktoepassingen met pakketsoftware.

 

4.5.4 Samenvatting

Gedistribueerde toepassingssystemen volgens client/server en objectgeoriënteerde architecturen zijn nog volop in ontwikkeling. De middleware die het ontwikkelen, beheren en gebruiken van deze systemen moet ondersteunen, biedt nog niet alle benodigde functionaliteit. Bovendien zijn er te veel leveranciers die er allemaal hun eigen standaarden op na houden. Dit belemmert het combineren van toepassingen van verschillende herkomst (maatwerk en softwareleveranciers) in één systeem. Ook de portabiliteit van toepassingen over hardware van verschillende leveranciers kent zijn beperkingen.

Zodra deze belemmeringen zijn opgeheven en de ontwikkelaars meer ervaring hebben opgedaan, is een sterke groei van gedistribueerde toepassingen te verwachten. Dat komt doordat de distributie van toepassingen over het computernetwerk voordelen oplevert, zoals meer functionaliteit voor de eindgebruiker, meer flexibiliteit van de toepassingen en een betere benutting van de beschikbare computercapaciteit.

In de toekomst zullen door de verdere groei van de netwerken tot een elektronische snelweg de computersystemen van bedrijven en de thuissystemen van particulieren met elkaar verbonden raken, waardoor wereldwijde gedistribueerde toepassingen ontstaan. De eerste wereldwijde toepassing is reeds beschikbaar op Internet in de vorm van World Wide Web. De gebruikers kunnen op hun PC via een clientprogramma onder Microsoft Windows documenten opvragen die andere deelnemers op servers in het netwerk aanbieden. De documenten bestaan uit teksten en tekeningen en kunnen met hyperlinks naar elkaar verwijzen.