De multi-tier of, beter gezegd, drietraps, client/server-architectuur heeft het afgelopen jaar veel terrein gewonnen, vooral door het succes van SAP en R/3. Het basisidee is: gebruik specifieke computers voor specifieke taken en koppel deze via een netwerk aan elkaar. Dat concept op zich is niet nieuw, maar de specifieke toepassing ervan op PC-gebaseerde client/server-systemen heeft de belangstelling van veel IT-planners gewekt.
In beginsel hebben SAP en andere leveranciers de systemen opgesplitst per functioneel deelgebied. De gui-client op de PC roept via remote procedure calls zakelijke applicatieroutines aan, die op een afdelingsserver draaien. De afdelingsserver roept een back-end relationele database aan, die op een derde machine draait. Deze scheiding van functionele deelgebieden zou de schaalbaarheid verbeteren. Er kunnen client-PC’s worden toegevoegd totdat de afdelingsmachine overbelast raakt. In dat geval kan een extra machine worden ingezet, om nog meer PC-gebruikers te kunnen ondersteunen. De afdelingsservers gebruiken in dat scenario nog steeds één gemeenschappelijke database. In deze architectuur zit een cruciale denkfout. Hij bestaat uit drie computers en twee netwerken. Dit betekent dat men vijf kwetsbare punten inbedt in de applicatie. Dit euvel is te voorkomen door een grotere machine te gebruiken, waarop zowel de applicatiecode als de database draaien. Alleen als de applicatie echt geografisch gespreid is, zijn meerdere kleinere systemen zinvol. Dat impliceert wel een wan-koppeling tussen de applicatiecode en de database, waardoor de betrouwbaarheid afneemt.
De drietraps-hiërarchie is volgens mij niet meer dan een marketing-hype. Het succes van R/3 is te danken aan de moderne functionaliteit van de applicatie zelf, en aan het feit dat SAP weet wat een dunne client is. Daarbij draait een minimale hoeveelheid code op de PC; alle andere code draait op de server, onder controle van een TP-monitor. Dankzij de minimale functionaliteit in de PC-client is het risico dat de PC crasht veel kleiner dan bij een dikke client – de oplossing die database-leveranciers en Microsoft propageren. Hierdoor was SAP één van de eerste leveranciers met een produkt dat enigszins fatsoenlijk met Windows 3.1 samenwerkt. Dikke client-code, geschreven in ongeschikte talen als Visualbasic en C++, is complex en meestal onbetrouwbaar in combinatie met Windows 3.1. SAP heeft een manier gevonden om Windows 3.1 te kunnen gebruiken; dàt was de succesformule, en niet de drietraps-architectuur! Daarbij heeft SAP laten zien hoe moeilijk het is om code van de ene naar de andere rdbms over te dragen: het gebruikt een eigen TP-monitor en 4GL in plaats van de veel betere combinatie van Tuxedo en Cobol. De reden ligt voor de hand: SAP heeft zo een volledig leveranciersspecifiek systeem gecreëerd, terwijl het tegelijkertijd iets over open systemen kan roepen.
Hoewel de meeste transactie-applicaties meer hebben aan een tweetraps-architectuur met een dunne client, ontstaat er tegenwoordig meer en meer behoefte aan gedistribueerde systemen, om puur zakelijke redenen. In de meeste gevallen is er geen behoefte aan real-time toegang tot een centraal systeem. Daarom moet men het alternatief, een bericht-gebaseerd concept, serieus overwegen. Let wel, de applicatie moet daarbij ontworpen worden volgens het berichtmodel – en dat verschilt sterk van het online model.
Een bericht-georiënteerde architectuur maakt gebruik van een zelfstandig afdelingssysteem, met een eigen database en applicatiecode. Dat systeem stuurt berichten naar het centrale systeem voor verdere verwerking. De applicatiecode en de database op het centrale systeem voeren specifieke functies uit die sterk verschillen van de functies van het afdelingssysteem. Deze fundamentele scheiding van bedrijfsfuncties vereist een nieuw applicatie-ontwerp.
Berichten moeten op een betrouwbare manier worden overgestuurd; gegarandeerde, eenmalige bezorging. De transactiesoftware moet daarom veel robuuster en beter beheerbaar zijn dan bijvoorbeeld software voor e-mail. Het bericht-concept is gebaseerd op een store-and-forward mechanisme en wordt ook wel ‘asynchroon’ genoemd, omdat beide communicatiepartners niet gelijktijdig aanwezig hoeven te zijn. Voor rpc daarentegen is een actieve verbinding nodig – een ‘synchrone’ benadering.
De gebruikersprogramma’s zijn verantwoordelijk voor het formatteren en decoderen van de inhoud van het bericht, maar er bestaat tegenwoordig ook message-oriented middleware (mom). Ik geloof heilig in het aanschaffen van middleware, omdat die op meerdere platforms beschikbaar moet zijn en de ontwikkelaars zich dus kunnen concentreren op de functionaliteit van de applicatie. IBM’s MQ-serie is het belangrijkste produkt. Microsoft daarentegen stopt Falcon in NT – niet de beste manier om platformonafhankelijkheid te realiseren!
Het bericht-gebaseerde paradigma introduceert veel nieuwe mogelijkheden èn problemen. Training, beheertools, nieuwe ontwerpmethoden en nieuwe ontwikkelomgevingen lokken de third-party industrie naar de nieuwe wereld van transactieberichten. Die wereld ziet er veel beter uit dan het synchrone online multi-tier model!
