Het multi-tier concept, zo virtuoos ingezet door SAP en anderen, is één van de slimste verkooptrucs die ik ken. Er bestaat namelijk geen andere manier om interactieve commerciële applicaties te bouwen.
Een belangrijke eigenschap waar SAP gebruik van maakt, is de implementatie van de ‘3-tier’ architectuur op verschillende computers, onderling verbonden door een netwerk. Daarvóór werden de drie componenten op een en dezelfde computer geïmplementeerd, waarbij zij onderling werden gekoppeld via de functies van het besturingssysteem. Het enige verschil: het fysieke user interface was een domme terminal en de ondersteuning voor de gebruikerslaag was minimaal. Op mainframes werkte de 3-tier architectuur nog het beste; daar werd gebruikgemaakt van logische partitionering om de applicatielogica (Cics) te scheiden van de database (DB2). Unix en de eerste mainframes maakten allemaal gebruik van eenzelfde combinatie van programma- en gegevensbeheer, waarbij de scheiding van logica en gegevens niet helder was (bijvoorbeeld Unix met C-Isam).
De opkomst van de PC en het Rdbms leidden helaas niet tot een goede ontwikkeling van de 3-tier architectuur, maar tot de (verkeerde) ontwikkeling van dikke client-systemen. En ondanks de vooruitgang van het grafische gebruikersinterface was dit een slechtere architectuur dan de Unix-systemen die op terminals gebaseerd waren, omdat nu alle applicatiecode op elke PC moest worden geïmplementeerd. Dit concept was reeds vanaf het begin gedoemd te falen.
De dunne client-architectuur is de enige oplossing voor een interactieve zakelijke applicatie voor meerdere gebruikers. Het enige verschil met een mainframe is de gebruikerslaag, die gescheiden is om een grafisch interface te kunnen realiseren. Wat we moeten inzien, is dat de 3-tier architectuur gebaseerd is op een logische, maar niet noodzakelijkerwijs fysieke scheiding.
IBM miste met de 3-tier architectuur bijna de boot, omdat ze het extreem moeilijk maakten om de 3270-interfaces door een dunne gui-client te vervangen – simpelweg doordat ze de eenvoudige connectiviteitseisen pas in een heel laat stadium oplosten.
Inmiddels zijn Ethernet, TCP/IP en RPC-oplossingen als Cics-client algemeen beschikbaar. Hierdoor is Cics de ideale logische laag en DB2 de ideale database-laag. Als IBM het meteen op die manier had gedaan, waren er nooit dikke client-problemen geweest.
Maar nu is er weer een andere revolutie, e-commerce, die een nieuwe dimensie introduceert, namelijk ondersteuning voor gebruikers die via Internet werken. Deze gebruikers kunnen niet ondersteund worden door dikke client-software, en ook niet door dunne PC-clients à la SAP. De nieuwe eis is dus ondersteuning van de webbrowser als nieuwe grafische interface, een BUI. Maar deze ‘bui’ is net zo dom als een 3270 of Ascii-terminal! Het downloaden van executeerbare code in de browser is dan ook een voor de hand liggend antwoord, en Java groeide uit tot een prominente oplossing.
Omdat nieuwe applicaties vandaag de dag geschikt moeten zijn voor het web en meestal ook interne interfaces nodig hebben, ligt het voor de hand om Internet- en intranet-interfaces te bouwen. Dit betekent een migratie van Windows-desktops naar browser-desktops (zelfs als die op PC’s draaien).
Nu de drie basislagen van de architectuur algemeen bekend zijn, is een poging om een nieuwe, meer beschrijvende terminologie te introduceren wel op zijn plaats.
Database server is daarbij de meest voor de hand liggende term voor de gegevenslaag. De term ‘Application Server’ wordt nu meestal gebruikt voor de applicatielaag, maar ik houd wel van IBM’s terminologie voor de gebruikerslaag, die ze de ‘Appliance Server’ noemen. (appliance: huishoudelijk apparaat – vert.)
Application Server is eigenlijk een verkeerde term, omdat de meeste Application Servers code uitvoeren die is geïntegreerd met andere systemen, met name bestaande zakelijke applicaties. Tenzij de Application Server alle applicatiecode uitvoert en die code direct is aangesloten op de database, is het meer een ‘integratieserver’. Verder wordt de term Application Server vaak gebruikt voor op Java gebaseerde servers met browsers als front-ends, terwijl er ook andere technologieën voor deze rol mogelijk zijn, bijvoorbeeld Cics of Microsoft ASP.
De term ‘Appliance Server’ is een juiste. Het is tijd om in te zien dat de dunne client-architectuur verschillende interface-apparaten mogelijk maakt, inclusief terminals en PC’s, maar ook telefoons, zuilen, spraakinvoer en een heel scala aan nieuwe randapparatuur. Het is vergelijkbaar met de PC, die de domme terminal verving.
Een goed ontworpen applicatie kan met uiteenlopende front-end apparatuur worden gebruikt. Hiervoor is wel een manier nodig om de applicatie op specifieke apparaten aan te sluiten. Niet elk apparaat ondersteunt alle mogelijke functies. Een PC kan meer dan een mobiele telefoon. Dit is een voor de hand liggend voorbeeld, maar er zullen meer variaties komen. En daarom zijn intelligente Appliance Servers hard nodig. Hoe zit het met spraakherkenning en apparatuur die werkt op basis van natuurlijke taal als de volgende stap?
Martin Healey, pionier ontwikkeling van op Intel gebaseerde computers en c/s-architectuur. Directeur van een aantal IT-bedrijven en professor aan de Universiteit van Wales.
