Software moet voldoen aan tal van eisen, waaronder prestatie en schaalbaarheid. Een aantal ontwerpaspecten is van belang bij het ontwikkelen van client/server-applicaties met een hoog prestatieniveau. Een voorbeeld is ‘groeperen’: het tijdstip waarop bepaalde componenten bij elkaar worden gebracht, tijdens compilatie of tijdens de uitvoering, beïnvloedt de prestatie. Een systeemontwerper belicht de verschillende aspecten van het ontwerpen, dat vanwege de complexiteit in teamverband moet plaatsvinden.
Binnen client/server bestaan relaties tussen processen die op verschillende machines plaatsvinden. Een van de processen (de server) verleent diensten aan een of meerdere andere processen (de clients). De service die een server verleent, kan een ‘resource’ genoemd worden. Een of meerdere clients kunnen gelijktijdig van de resource gebruik maken. De server bewaakt de kwaliteit van de resource. Een voorbeeld hiervan is een databasemanagementsysteem (server), die data (de resource) beheert ten behoeve van een of meerdere clients. Het dbms geeft de clients gecontroleerd toegang tot de data, zodat de kwaliteit van de data niet in het gevaar komt. Andere voorbeelden van servers zijn ’transaction-processing monitors’, webservers, groupservers en objectservers.
Zowel in de traditionele mainframe- als in de client/server-ontwikkeling is het een goed gebruik om software in logische lagen te organiseren. Het onderbrengen van functies in verschillende lagen komt de onderhoudbaarheid, herbruikbaarheid en de prestatie ten goede. Ten aanzien van client/server wordt vaak een opdeling in drie functionele categorieën gemaakt, welke weer uitgesplitst kan worden in vijf meer technisch georiënteerde lagen. Figuur 1 toont deze opdeling.
| Categorie | Laag | Beschrijving |
| Gebruikersinterface | Presentatiemanagement | Deze laag is verantwoordelijk voor het opbouwen van het beeldscherm. Hiervoor worden producten zoals Windows gebruikt. |
| Presentatielogica | Deze laag controleert de interactie met de gebruiker. Het bevat de logica om vensters op te bouwen, te reageren op het indrukken van knoppen door de gebruiker, te reageren op menukeuzes gemaakt door de gebruiker, enzovoort. Deze laag is applicatiespecifiek. | |
| Bedrijfslogica | Applicatielogica | Deze laag bevat de bedrijfslogica. Deze laag is vaak applicatiespecifiek. ‘Component based development’ richt zich op het bouwen van herbruikbare componenten; dit zijn dus componenten die in meerdere applicaties gebruikt kunnen worden. |
| Datamanagement | Data logica | Deze applicatiespecifieke laag bevat de logica die het opslaan en het ophalen van data verzorgt. |
| Databasemanagement | Deze component is verantwoordelijk voor het blijvend opslaan en beheren van data. Voor deze laag worden standaardproducten zoals IBM’s DB2 en Oracle 8.0 voor gebruikt. |
Figuur 1. Opdeling in applicatielagen bij client/server.
De opdeling in lagen is terug te vinden in figuur 2. Hierin zijn de verschillende lagen verdeeld over twee machines, een server en een client: het zogenaamde 2-tier model. Wanneer de lagen over drie of meer machines gedistribueerd worden, dan spreken we over 3-tier of n-tier machines.
Middleware
Middleware is speciale software die communicatie tussen verschillende processen mogelijk maakt. Het biedt een application programming interface (api) die de applicatiecode isoleert van netwerkcommunicatieformaten en -protocollen. Er zijn verschillende categorieën middleware te onderkennen zoals database-middleware en applicatie-middleware, zie figuur 2.
| Presentatie op afstand | Gedistribueerde logica | Datatoegang op afstand | |||
| Datamanager Datalogica Applicatielogica Presentatielogica | Datamanager Datalogica Applicatielogica | Datamanager | |||
| Server | Presentatie-middleware | Server | Applicatie-middleware | Server | Database-middleware |
| Client | Presentatie-middleware Presentatiemanager | Client | Applicatie-middleware Applicatielogica Presentatielogica Presentatiemanager | Client | Database-middleware Datalogica Applicatielogica Presentatielogica Presentatiemanager |
Figuur 2. Categorieën middleware.
Database-middleware ondersteunt de communicatie tussen een zelf ontwikkelde component op de client en een door een leverancier geleverde dbms op de server. Voorbeelden van database middleware zijn bijvoorbeeld Odbc en Jdbc.
Applicatie-middleware ondersteunt de communicatie tussen zelf ontwikkelde componenten zowel ten behoeve van de client- als van de serverkant. Veelal wordt er onderscheid gemaakt tussen middleware die synchrone communicatie ondersteunt (te vergelijken communicatie middels een telefoongesprek) en middleware die asynchrone communicatie (te vergelijken communicatie middels briefwisseling) ondersteunt.
De categorie applicatie-middleware biedt ontwikkelaars verschillende mogelijkheden, zoals sockets, named-pipes, remote-procedure-calls, message-oriented-middleware (mom) en object middleware. ‘Sockets’ en ‘named-pipes’ zijn te gebruiken om processen data uit te laten wisselen. Beide bieden een file-achtige interface. Het ene proces schrijft data in de file en het andere proces leest de data eruit. ‘Remote procedure calls’ maken het mogelijk procedures aan te roepen die op andere machines geplaatst zijn, en uit te voeren. ‘Sockets, ‘named-pipes’ en ‘remote procedure calls’ zijn voorbeelden van synchrone communicatie, hetgeen inhoudt dat beide in de communicatie betrokken partijen tijdens de communicatie beschikbaar moeten zijn. Dit geldt niet voor asynchrone communicatie. Dan schrijft een proces de gegevens bestemd voor het andere proces in een ‘queue’ (te vergelijken met een brievenbus). Op dat moment hoeft het proces waarvoor de data bestemd is, niet actief te zijn. Dat proces kan bijvoorbeeld pas een uur later die gegevens ophalen.
Prestaties
Twee begrippen spelen op het gebied van prestaties een belangrijke rol: verwerkingscapaciteit (throughput) en responstijd. Verwerkingscapaciteit kan gedefinieerd worden als de hoeveelheid werk (uitgedrukt in bijvoorbeeld transacties) dat een systeem in een bepaalde tijd kan verwerken. Het is ook te definiëren als de gemiddelde tijd waarin het systeem een vaste hoeveelheid transacties kan verwerken. Verwerkingscapaciteit wordt vaak gebruikt om de prestatie van batchsystemen te definiëren. Met betrekking tot de prestaties van batch-applicaties wordt ook vaak het begrip ‘batch-window’ gebruikt. Een ‘batch-window’ wordt gedefinieerd als de periode waarin alle batch-programma’s uitgevoerd moeten worden. Deze periodes worden vaak in de nachtelijke uren gepland, tijdstippen waarop gebruikers niet actief zijn en mogelijk dezelfde data via dialogen zouden benaderen.
Responstijd is de tijd die vereist is om een bepaalde taak te verwerken. Dit begrip wordt vaak gebruikt voor programma’s die door gebruikers bediend worden (gui-applicaties). Responstijd kan verder onderverdeeld worden in bijvoorbeeld de minimum responstijd and de effectieve responstijd. De minimum responstijd is de tijd die verstrijkt tussen het starten van een taak (bijvoorbeeld door het indrukken van een knop) en het tijdstip waarop de eerste output aan de gebruiker getoond wordt. De effectieve responstijd is de tijd die verstrijkt tussen het starten van een taak en het tijdstip waarop de gebruiker weer opdrachten aan het systeem kan geven, waarbij de taak nog niet geheel door het systeem uitgevoerd behoeft te zijn.
Hieronder gaan we in op de verschillende ontwerpaspecten. Kennis van elk van de ontwerpaspecten afzonderlijk en van de samenhang tussen de aspecten is essentieel voor het ontwikkelen van applicaties met hoge prestaties. Door bijvoorbeeld processen en data op één machine te groeperen (‘grouping-aspect’) kunnen goedkopere instructies (‘procedure call’ versus ‘remote procedure call’, disk i/o versus disk via lan-server) gebruikt worden ( aspect workload, werkbelasting).
Werkbelasting
Het aspect ‘werkbelasting’ richt zich op het specificeren van prestatie-eisen door de gebruiker (functioneel perspectief) en het verbeteren van de prestatie van applicaties door te bezuinigen op dure code (in tijd gemeten) en het elimineren van overbodige code (technisch perspectief).
Allereerst het functioneel perspectief. Ontwikkelaars zijn slechts in staat applicaties te ontwikkelen die voldoen aan de prestatiewensen van de gebruiker als deze wensen gekwantificeerd en gekwalificeerd zijn. Drie categorieën gegevens moeten gekwantificeerd worden: responstijden, transactievolumes of belastingprofielen, en databasevolumes.
De gebruiker moet aangeven wat hij acceptabele responstijden vindt. Tevens moet met hem overeen gekomen worden wat in dit geval onder responstijd verstaan wordt (minimum responstijd, effectieve responstijd, ervaren responstijd). Responstijden kunnen algemeen gespecificeerd worden (systeem geeft binnen drie seconden respons) of per gebruikerstaak (het invoeren van een reisreservering moet binnen 40 seconden gedaan kunnen worden).
Een transactievolume of belastingsprofiel definieert een belasting (uitgedrukt in een aantal transacties) voor een specifiek scenario (gemiddelde belasting per uur, piekbelasting per uur, ‘einde van de dag’-verwerking, ‘einde van de maand’-verwerking). In een belastingsprofiel moet zijn opgenomen welke typen gebruikers vanaf welke locaties bepaalde transacties initiëren. De kwalitatieve specificatie moet ook gekwantificeerd worden. Een voorbeeld. Dertig verkoopmedewerkers voeren per dag vanuit kantoor Amsterdam in totaal 243 koopovereenkomsten in. Op basis van de vermelding van de locatie en van de aantallen transacties zijn later tijdens de technische-ontwerpfase netwerkbelastingen te berekenen.
Database-volumes definiëren het aantal rijen per tabel dat de database na verloop van tijd zal bevatten. Deze periode verschilt per bedrijfsproces. Indicaties ten aanzien van database volumes zijn voor database ontwerpers nodig om bijvoorbeeld indices te definiëren.
Het technische perspectief van het aspect ‘werkbelasting’ richt zich op het elimineren van overbodige code en het vervangen van dure door goedkope code (uitgedrukt in tijd). Hoe minder instructies een applicatie behoeft uit te voeren en hoe sneller elke individuele instructie, des te sneller de applicatie zijn input verwerkt zal hebben. Enkele voorbeelden van ontwikkeltips uit deze categorie zijn:
Optimaliseer programma lussen. Instructies in programmalussen worden minimaal twee keer uitgevoerd maar vaak een veel groter aantal keren. Het is derhalve aan te raden dure operaties zoals ‘SQL CONNECT’ en ‘SQL DISCONNECT’ buiten de programma lus te brengen. In het geval van geneste programmalussen is het in het algemeen raadzaam de meest actieve lus tot binnenste lus te maken en de minder actieve tot buitenste lus.
| Device | Servicetijd | Met 1 seconde als basis |
| Hogesnelheids processor-buffer | 10 nanoseconden | 1 seconde |
| Random access geheugen | 60 nanoseconden | 6 seconden |
| ‘Procedure call’ | 1 microseconde | 2 minuten |
| Lokaal RPC | 100 microseconden | 4 uur |
| Magnetische schijf | 25 milliseconden | 4 weken |
| Disk via lan-server | 35-50 milliseconden | 6-8 weken |
Figuur 3. Kosten van programma-operaties.
Verminder het gebruik van dure operaties. Zoals figuur 3 aangeeft, zijn aan verschillende operaties verschillende kosten verbonden. Omdat de in de tweede kolom vermelde servicetijden eigenlijk te klein zijn om er een voorstelling van te kunnen maken, is in de derde kolom de servicetijd genoteerd waarbij 10 nanoseconden gelijkgesteld is aan 1 seconde. Bij het ontwikkelen van applicaties is het raadzaam hier rekening mee te houden.
Reduceer de grootte van SQL resultaat sets. Het is raadzaam alleen die kolommen en rijen van een databasetabel op te vragen waaraan daadwerkelijk behoefte is. Dit bespaart de databaseserver kostbare cpu-tijd en vermindert de hoeveelheid data die over het netwerk verstuurd moet worden.
Groepering
‘Groepering’ is gebaseerd op de al lang bekende begrippen cohesie en koppeling. Dit aspect adviseert sommige componenten (processen, data) al tijdens compilatietijd bij elkaar te brengen en andere pas tijdens de uitvoeringstijd. Enkele voorbeelden van ontwikkeltips uit deze categorie zijn:
Bufferen van data. Vaak komt het voor dat een applicatie meerdere keren de behoefte heeft aan dezelfde data. In plaats van de applicatie herhaaldelijk de data te laten ophalen van een, eventueel ‘remote disk’, is het beter de data op te slaan in een cache. Bufferen elimineert de overhead van disk en in geval van remote disks netwerk i/o. Natuurlijk moet de tijdgeldigheid van de gebufferde data (kopie van origineel) wel in het oog worden gehouden.
Database stored procedures. Dit zijn programma’s die in de database data in tabellen manipuleren. Stored procedures zijn in dezelfde database als de data opgeborgen en worden op dezelfde databaseserver uitgevoerd. Dat betekent dat geen data naar de client gebracht moeten worden voor bewerking. Alleen het resultaat van de bewerking behoeft over het netwerk naar de client verstuurd te worden.
Ontwerpen van gebruikersinterface. Door te ontwerpen met de gebruikerstaken in het achterhoofd, ontstaan interfaces die het de gebruiker mogelijk maken snel zijn taken uit te voeren. Hierbij valt de denken aan het bij elkaar plaatsen van knoppen en het tonen van gerelateerde data in één venster in plaats van de gebruiker hiervoor bijvoorbeeld twee of drie vensters te laten openen.
Delen
Het delen van resources is kenmerkend voor client/server; zo maken meerdere clients gebruik van de diensten van dezelfde databaseserver. Wanneer meerdere personen een voorwerp gezamenlijk willen gebruiken, dan houdt dat in dat op één bepaald tijdstip één van de personen de beschikking over het voorwerp heeft en dat de andere personen moeten wachten tot de tijdelijke eigenaar het voorwerp vrij geeft. Als de tijdelijke eigenaar het voorwerp niet meer vrij geeft, kan dat problemen opleveren voor de anderen. Dit gaat ook op voor clients en servers. Daarom moet er vastgesteld worden welke resources door de verschillende clients gedeeld zullen worden (functioneel perspectief), en moet gemeenschappelijk gebruik gecontroleerd worden (technisch perspectief).
Allereerst het functioneel perspectief. Tijdens het functioneel en technisch ontwerp kunnen ‘applicatie-resource-gebruik’-matrices gebruikt worden om het delen van resources te kwalificeren en te kwantificeren.
| Proces | Tijd | Type | PC 1 | PC 2 | Tabel 1 | Tabel 2 |
| Proces 1 | 09:00-17:00 | Online | Uitvoering op | T, L, W | L | |
| Proces 2 | 18:00-22:00 | Batch | Uitvoering op | T, W, V | ||
| dbms | 00:00-24:00 | Uitvoering op | Beheert | Beheert |
Figuur 4. Voorbeeld ‘applicatie-resource-gebruik’-matrix. ‘T’ staat voor het toevoegen van een nieuw gegeven aan de tabel; ‘L’ staat voor het lezen van een gegeven uit de tabel, ‘W’ voor het wijzigen van een gegeven in de tabel en ‘V’ staat voor het verwijderen van een gegeven uit de tabel.
Figuur 4 toont een voorbeeld van een kwantitatief gevulde matrix. Het technisch perspectief bij het aspect ‘delen’ betreft:
Delen van databases. Om data in databases optimaal te delen moet bewust omgegaan worden met ‘program isolation levels’, ‘lock duration ‘, ‘locking granularities’, ‘database locking strategies’ en het ontwerp van de tabellen in de database. Kleine misstappen in het ontwerp van de database (‘locking granularities’), geen kennis hebben van de ‘locking’-strategie van de database en van ‘program isolation levels’ tijdens het programma-ontwerp, kunnen gigantische gevolgen hebben voor de prestaties.
Delen van andere resources. Andere voorbeelden van gedeelde resources zijn netwerken en ‘dynamic name servers’. Ook hier moeten ontwerpers zich van bewust zijn. Met name moet rekening worden gehouden met piekbelastingen.
Communicatie
Gedistribueerde verwerking kent verschillende problemen, waaronder de volgende.
Variabele capaciteit. Verschillende componenten opereren in diverse omgevingen en met verschillende snelheden. Een clientcomponent wordt altijd gelimiteerd door de snelste servercomponent die hij gebruikt.
Variabele beschikbaarheid. Het is onzeker dat onafhankelijke componenten altijd beschikbaar zijn. Indien een servercomponent niet beschikbaar is, dan kan dat betekenen dat de clientcomponent moet stoppen met zijn werk.
Variabele vraag. Een gedistribueerde transactie kan over verschillende componenten verdeeld worden. Terwijl sommige componenten hun werk misschien in milliseconden kunnen doen, kost het andere componenten misschien wel minuten. Als de snelle componenten hierop moeten wachten, dan is dat zonde van hun tijd.
Indien de gedistribueerde componenten synchroon communiceren, dat wil zeggen dat beide partijen tijdens de communicatie sessie actief zijn, dan bestaat de kans dat een component op de andere moet wachten omdat deze langzamer is (variabele capaciteit), onverwacht niet beschikbaar is (variabele beschikbaarheid) of zeer langdurende taken heeft (variabele vraag). In geval van asynchrone communicatie kunnen beide partijen onafhankelijk van elkaar hun werk doen. Indien asynchrone communicatie gewenst is, dan kan message-georiënteerde middleware een goede keuze zijn.
Bij het bepalen van de gewenste vorm van communicatie (synchroon dan wel asynchroon) zijn de functionele eisen het uitgangspunt. De gebruiker moet aangeven of zijn processen – functioneel gezien – synchroon of asynchroon geïmplementeerd moeten worden. Het invoeren van bestellingen is bijvoorbeeld als synchroon of als asynchroon proces te zien. In het eerste geval bestaat het invoeren van een bestelling bijvoorbeeld uit het intypen van de bestelling inclusief het succesvol verzenden ervan naar een leverancier, terwijl in het tweede geval het verzenden van de bestelling naar de leverancier een activiteit is die later plaatsvindt.
Ontwerppatronen (‘design patterns’) bevatten bewezen oplossingen voor terugkerende problemen. Over ontwerppatronen is inmiddels een groot aantal boeken geschreven (A system of patterns, Frank Buschmann e.a.; Design patterns, Erich Gamma e.a.). Frank Buschmann heeft een aantal patronen in zijn werk opgenomen die zich speciaal richten op communicatie (‘forwarder-receiver’, ‘client-dispatcher-server’, ‘publisher-subsciber’). Het ‘publisher-subsciber’-patroon helpt samenwerkende componenten in een gesynchroniseerde toestand te blijven. Dit patroon kan bijvoorbeeld gebruikt worden om data te distribueren.
Product en parallellisme
Met het product-aspect wordt bedoeld dat het essentieel is om kennis te hebben van het onderliggende besturingssysteem, in gebruik zijnde ontwikkelgereedschappen en databases, enzovoort. Indien het bij de ontwikkelaars bijvoorbeeld niet bekend is dat het in gebruik zijnde databasemanagementsyteem een pessimistische vergrendelstrategie hanteert, dan kan dit leiden tot grote prestatieproblemen.
Parallellisme wil zeggen dat werk gelijktijdig wordt uitgevoerd. Werk kan door het gebruik van ‘multithreading’ parallel in één applicatie uitgevoerd worden, data zijn door het gebruik van raid-technologie parallel te lezen en dbms’en bieden ook mogelijkheden tot parallelle verwerking. ‘Multithreading’ kan binnen applicaties met een grafische interface gebruikt worden om op de achtergrond bijvoorbeeld een complex rapport te genereren, terwijl de gebruiker toch de controle houdt. Zo worden webpagina’s ook vaak opgebouwd, terwijl de plaatjes nog worden opgehaald (elk op een eigen thread) en is de gebruiker toch in staat de browser te bedienen.
Organisatie
Het is voor individuele ontwikkelaars niet meer mogelijk om systemen geheel alleen te bouwen, niet alleen vanwege de omvang van het systeem, maar ook omdat individuele ontwikkelaars niet alle vereiste kennis bezitten. Het ontwikkelen van software moet daarom ook teamwerk zijn. Gezamenlijk moeten de teamleden een aantal kennisgebieden dekken. Deze kennisgebieden worden hieronder in het kort besproken.
Applicaties worden ontwikkeld om bedrijfsprocessen effectiever en efficiënter te laten verlopen. Tevens maakt informatietechnologie nieuwe producten en diensten mogelijk. Willen ontwikkelaars in staat zijn een bijdrage te leveren aan het met behulp van IT verbeteren van bedrijfsprocessen, dan moeten zij een gedegen kennis van die bedrijfsprocessen hebben.
Logisch en fysiek databaseontwerp is niet een activiteit die ontwikkelaars er even bij kunnen doen. Database-experts moeten in de ontwikkelingswerkzaamheden betrokken worden.
De huidige ontwikkeltools moeten het ontwikkelaars gemakkelijk maken applicaties te ontwikkelen. Deze tools worden van meer en meer snufjes voorzien. Binnen het team moeten projectleden zitten die de gebruikte tools optimaal weten te benutten.
Verschillende programmeertalen hebben elk hun eigen voordelen, nadelen en valkuilen (‘memory-leakage’). Binnen het team moeten projectleden zitten die de gebruikte talen volledig beheersen.
Er bestaan verschillende middleware-producten die, zoals eerder beschreven, asynchrone dan wel synchrone communicatie ondersteunen. Implementatie en correct gebruik van deze producten vereisen een gedegen kennis van deze producten.
Clients en servers draaien op machines die met elkaar verbonden zijn door middel van een netwerk. Het is belangrijk netwerkspecialisten bij het project te betrekken die adviseren over mogelijke verwerkingscapaciteit, huidige en toekomstig mogelijke belasting en beschikbaarheid van het netwerk. Zeker ten aanzien van applicaties die over een wide area network gedistribueerd moeten worden, is de inbreng van netwerkspecialisten erg belangrijk.
Applicaties draaien op besturingssystemen. Het ontwikkelteam moet zich van de mogelijkheden en onmogelijkheden van het gebruikte systeem bewust zijn. Ook is het belangrijk op de hoogte te zijn van beschikbaarheid van additionele software zoals planningspakketten voor dat platform. Op het mainframe heeft men bijvoorbeeld de beschikking over een robuust ‘scheduling’-pakket (planningspakket, OPC) dat enkele tienduizenden jobs (een job is het uitvoeren van een applicatie) in de gaten houdt en aanstuurt. Hierbij wordt door het planningspakket ook met afhankelijkheden tussen de verschillende jobs rekening gehouden.
Hoewel het ontwerp van het gebruikersinterface niet direct met prestaties geassocieerd zal worden, beïnvloedt de interface wel degelijk de prestatie zoals de gebruiker die waarneemt. Het ontwerpen van gebruikersinterfaces is een vak op zich aan het worden en specialisten moeten voor het ontwerp van de grafische interface ingeschakeld worden. Zij zullen ook op de hoogte zijn van de binnen de organisatie gebruikte stijlgidsen.
Het is de taak van projectleiders om ervoor te zorgen dat het projectteam adequaat wordt bemand.
M. J. Sikkema, systeemontwerper ABN AMRO
