We hebben er weer een nieuwe klasse producten bij: de applicatieservers. Ik moet toegeven dat ik aanvankelijk in de war was, omdat ik altijd dacht dat salarisadministratie, facturering, voorraadbeheer en dergelijke ook applicaties waren en dat de computers waar deze kernapplicaties op draaien daarom ook als ‘applicatieservers’ geclassificeerd zouden moeten worden.
Wat zich nu ontwikkelt, is een klasse producten die tussen de nieuwe subsystemen voor ‘user interfacing’ en de bestaande klassieke applicaties inzit. Om precies te zijn gaat het hier om applicatie-integrerende middleware-producten. Er zijn twee of drie drijvende krachten achter de groei van deze nieuwe applicatieservers.
(a) De puinhoop, veroorzaakt door dikke client/server-applicaties. Het is duidelijk dat deze applicaties eigenlijk volledig opnieuw ontworpen zouden moeten worden, maar dan zonder de enorme ondersteuning die nodig is voor bedrijfsomspannende applicaties. Terugkijkend op de eerste platforms en applicaties is het duidelijk dat de gebruikers in veel gevallen alleen maar behoefte hadden aan een nieuw interface; de kernapplicaties zelf waren in orde en werden al voldoende ondersteund door TP-monitors en dergelijke.
(b) De ontwikkeling van nieuwe web-technieken, ondersteund door Java. Deze technologieën zijn op dit moment het sterkste voor het gebruikersinterface en moeten daarom worden gekoppeld aan beproefde transactiesystemen.
(c) Het ontbreken van een multi-user besturingssysteem van Microsoft. Met Microsoft-technologie heb je voor 100 gebruikers tenminste 101 NT-licenties nodig. Met netwerkcomputers (NC’s) is een zware server-licentie voldoende. Door een web-server als middleware te gebruiken, kunnen meerdere NC’s worden ondersteund door één NT-licentie. Microsoft zal daarom inkomsten verwerven uit producten met toegevoegde waarde, die worden gebruikt om nieuwe applicatieservers te bouwen.
De applicatieserver is pas in de schijnwerpers komen te staan nadat SAP, Baan en dergelijke de ‘multi-tier’ client/server-architectuur hadden gepropageerd. Meerdere PC’s met een dunne client maken verbinding met een applicatieserver, die weer gekoppeld is met een database-server. Dit is natuurlijk het klassieke mainframe-model, maar dan met een grafische front-end in plaats van karakter-terminals. De hype concentreerde zich op buzzwords rond ‘open systemen’, zoals Unix, NT, relationele Dbms en dergelijke. Hieruit volgde dat er behoefte was aan afzonderlijke fysieke dozen voor applicatiecode en database, vandaar de opkomst van de eerste applicatieservers. Dit is grote onzin; met Cics of Tuxedo kunnen de applicatiecode en het Dbms op één machine draaien. Een multi-tier architectuur is logisch, niet fysiek.
Als we een stapje terug doen en dit concept nog eens bekijken, blijkt dat het probleem met de oude systemen alleen de front-end is. Alleen de front-end moet dus worden aangepast. Helaas duurde het jaren voordat IBM met eenvoudige PC-tools kwam waardoor een Cics-client op een PC met een gui front-end robuuste transacties op de host kan uitvoeren. Voordat deze tools op de markt kwamen, waren te veel organisaties al de mist ingegaan met een dikke client-applicatie.
Vaak is het niet voldoende om een oude applicatie een face-lift te geven. De meeste applicaties zijn functioneel inadequaat en moeten vervangen worden. Het is niet eenvoudig om de bestaande verzameling applicaties te beoordelen en te bepalen welke applicaties moeten worden aangepast en welke applicaties moeten worden vervangen. Softwaretools die bij deze analyse en beoordeling kunnen helpen, zijn een onmisbare investering als we een nieuw client/server-fiasco willen voorkomen. In essentie proberen we in het ideale geval de herbruikbare componenten in bestaande systemen te identificeren. We moeten inzien dat de meeste code enigszins moet worden aangepast om de herbruikbare componenten eruit te kunnen halen.
Het laagste gemeenschappelijke niveau is waarschijnlijk de database. In dat geval is de applicatieserver een nieuwe applicatie, maar zonder de vrijheid om de database opnieuw in te richten. In de meeste moderne applicaties komen ‘stored procedures’ voor, en het ligt voor de hand dat herbruikbare componenten het beste op dit niveau kunnen worden aangewezen. Op een hoger niveau is de mogelijkheid om herbruikbare componenten te verkrijgen afhankelijk van veel factoren. Is er complete specificatie beschikbaar? Bestaat de code uit grote, geïntegreerde modules of is de code netjes modulair opgebouwd? Als de componenten geschreven zijn in een lagere programmeertaal, zoals C++, zijn de klassebibliotheken dan bekend en gedocumenteerd?
Het is duidelijk dat applicaties die al kunnen samenwerken met een TP-monitor gemakkelijker zijn te op te splitsen in herbruikbare componenten dan de geïntegreerde code die zoveel voorkomt op Unix-systemen. Tenslotte is het mogelijk het bestaande karakterinterface van oudere applicaties te gebruiken als een gegevensbestand dat bewerkt kan worden. Front-end tools op basis van PC’s en web-technologie zij dan geschikt voor het bouwen van nieuwe applicaties. Aplicaties die gegevens in bestaande systemen kunnen opvragen en wijzigen door de op karakters gebaseerde I/O van een domme terminal te simuleren.
