Ik heb er al op gewezen dat de term ‘applicatieserver’ in feite van toepassing is op elke server die applicatiecode draait, zoals Cics of Tuxedo. Toch moeten we accepteren dat de term tegenwoordig wordt gebezigd voor middleware-producten die web-front-ends integreren met transactiesystemen.
De back-end kan een relationele database zijn, in welk geval de applicatieserver de middelste laag van de drie-lagenarchitectuur van SAP en andere leveranciers vormt. De belangrijkste rol van de applicatieserver is echter om herbruikbare modules in bestaande transactie-applicaties aan elkaar te koppelen. In deze rol kan de nieuwe code op de applicatieserver worden ingezet om het gebruikersinterface van de oude applicaties te verfijnen.
Toegang tot bestaande terminalinterfaces (screen scrapping met 3270 datasets, bijvoorbeeld) vereist maar weinig werk op het oude systeem. Een veel betere architectuur is te realiseren als de oude code wordt opgesplitst in kleinere, specifieke, herbruikbare componenten. Hiervoor moeten re-engineeringtools worden gebruikt, zoals Netron, Viasoft en dergelijke leveren. Deze aanpak maakt echter zeer flexibele code op de applicatieserver mogelijk. Samenvattend: het gebruik van de database is een hele nieuwe applicatie op zich, waarbij terminal-emulatie de meest eenvoudige weg is. Het uiteindelijke doel is het omvormen van bestaande code tot herbruikbare transactiemodules.
In de begindagen van de ontwikkeling van e-commerce werden er tools ontwikkeld om aan te sluiten op CGI en leveranciersspecifieke web-interfaces, zoals Nsapi (Netscape) of Isapi (Microsoft). Tegenwoordig zijn er echter twee duidelijke trends, de ene gebaseerd op Java, de andere op Ole. Ole is natuurlijk een Windows NT standaard. In tegenstelling hiermee zijn Java-producten heterogeen, die draaien op elk platform met een Java Virtual Machine (JVM) en een web/Http-server; tegenwoordig geldt dat voor alle platforms. Het lijkt moeilijk voorstelbaar dat organisaties kiezen voor de doodlopende weg van Microsoft, maar toch doen ze het.
De applicatieserver van Microsoft gebruikt IIS op een NT-platform, met Active Server Pages (ASP). ASP koppelt de web-server aan Ole. Met deze benadering kan de middle-tier applicatiecode in elke voor Ole geschikte taal worden ontwikkeld. Daarnaast kan Dole worden gebruikt om de verwerking te spreiden over meerdere NT-servers (en mogelijk ook andere servers).
Alle andere applicatieservers zijn gebaseerd op Java. De client-applets worden afzonderlijk beheerd door een web Http-server; als ze in de JVM van de browser worden uitgevoerd, kunnen ze via Http en Html met de server communiceren. Dit was vroeger zo. Tegenwoordig legt de Java-applet op de client contact met Java-code op de server, hetzij met behulp van Remote Method Invocation (RMI), een Sun Java-standaard, hetzij met Inter Internet ORB Protocol (IIOP). Al deze opties (Http, RMI en IIOP) moeten door de applicatieserver worden ondersteund.
Het is duidelijk dat de applicatieserver zowel een JVM als een Http-server moet hebben. Sommige producten, zoals Aptivity en Silverstream, kunnen overweg met elke willekeurige JVM en Http-omgeving; andere, zoals IBM’s Websphere en Oracles Application Server hebben een voorkeur voor bepaalde web-servers. Toch zijn ze allemaal in principe overdraagbaar en daarom ook schaalbaar.
De Java-api’s voor de client-applets zijn niet goed genoeg voor de ‘servlets’ op de server. De applets zijn sterk gericht op gui’s, die op een applicatieserver natuurlijk niets te zoeken hebben. De server-code moet juist toegang hebben tot transactie-interfaces, en daar zit de client nu juist weer niet op te wachten. De eerste servlets werden ontwikkeld met behulp van speciale klassebibliotheken voor TP-monitors en dergelijke, die werden gedefinieerd en geïmplementeerd als een verzameling geavanceerde componenten die luisterden naar de naam Enterprise Java Beans (EJB). Dit betekent dat de standaard JVM niet hoeft te worden uitgebreid.
De primaire services op de services zijn Java Management API (Jmapi), Java Naming and Directory Interface (Jndi), Java Transaction Services (JTS), Java Database Connectivity (JDBC), en Java Message Service (JMS). Daarnaast worden ook RMI en het Java/Corba-interface naar IIOP (I-IDL) ondersteund. Deze diensten zijn geïmplementeerd als containers, zodat de beans aangesloten kunnen worden op bestaande legacy-systemen, zoals JTS-toegang tot Cics voor mainframes of Tuxedo voor Unix.
Een ander aspect waarin de applicatieserver verschilt van de JVM in de client-browser is de noodzaak voor efficiënt beheer van de applicatie en de beans. Een Http-server met Html is de inherente manier om client-applets te laden, maar voor de applicatieserver is een snelle objectmonitor nodig. Merk op dat Corba uit de kast gekomen is en nu een integraal onderdeel van de applicatieserver vormt – behalve bij Microsoft.
