In het dunne client-model moet de applicatiecode gepartitioneerd worden. De lastige vraag hoe je zo’n partitionering zou moeten uitvoeren, leidde tot het dikke client-model, dat wordt geassocieerd met relationele databases. De SQL-procedures worden daarbij simpelweg in het Rdbms opgenomen; terwijl de rest van de code op de PC draait. De specificatie van Odbc, een standaard om PC-code op een database aan te sluiten, hielp daarbij een handje.
Het bleek niet makkelijk deze architectuur uit te breiden. Daarnaast ontstond een groeiende behoefte aan gemeenschappelijke applicatiecode voor specifieke bedrijfsprocessen. In de database opgeslagen procedures werden daartoe uitgebreid met leveranciersspecifieke procedures, zoals Oracles PL/SQL. Dit maakte des te duidelijker dat er een grote behoefte bestond aan het ontwerpen van gepartitioneerde code. Vandaag de dag is partitionering een stuk eenvoudiger, omdat veel tools en Case-systemen hier goed mee uit de voeten kunnen.
Als we aannemen dat uiteindelijk besloten is welke code door de client, respectievelijk de server uitgevoerd moet worden, ontstaat er een aantal mogelijkheden. De server kan op de klassieke manier geprogrammeerd worden, bijvoorbeeld in Cics/Cobol, maar kan ook gebruikmaken van EJB en applicatieservers om een integratie met bestaande systemen te bewerkstelligen. Er worden zelfs pogingen gedaan om de server volledig in C++, Java of Visual Basic te programmeren, maar dit is een aanpak die voorbijgaat aan de waarde van de bestaande ervaring met legacy-systemen en het feit dat Cobol of een 4GL geschikter zijn voor het ontwikkelen van commerciële applicaties.
Als de dunne client-architectuur eenmaal geaccepteerd is, en het ontwerp van de serverfuncties is begonnen, dan gaat er voor de client een hele nieuwe wereld open, zowel fysiek als qua software. Fysiek wordt de combinatie scherm/toetsenbord/muis mogelijk. Er zal een heel nieuwe generatie client-apparatuur ontstaan – niet in plaats van, maar naast de PC.
Veel mensen denken dat een dunne client gelijk staat aan Java, maar dat is niet waar. Een Visual Basic-client is prima mogelijk, als er maar geen bedrijfsfuncties in de client-code worden gestopt. De VB-applicatie is alleen verantwoordelijk voor presentatie en het gebruikersinterface, en roept remote procedures op de server aan met behulp van Cics client, Tuxedo client of Dole. Er bestaat een ruime keus.
In het algemeen is een Java-client gelijkwaardig aan een dunne PC-client; het enige verschil is dat de client in een moderne, objectgeoriënteerde taal is geschreven. Het belangrijkste verschil zit hem in het laden van de client. In het geval van een PC wordt de code van disk of van een server geladen, terwijl de Java-client altijd in run-time van een server gehaald moet worden. Deze laatste aanpak maakt het onderhoud eenvoudiger, leidt tot lagere kosten en is platform-onafhankelijk wegens het gebruik van Java. Als je er objectief tegenaan kijkt, is er geen enkele reden om Visual Basic te gebruiken; de toekomst is aan Java.
Een belangrijk voordeel van Windows en VB is de beschikbaarheid van volwassen API’s, waarmee serverfuncties kunnen worden aangeroepen. Odbc zou alleen voor eenvoudige applicaties moeten worden gebruikt. De ondersteuning is echter uitstekend. Alle leveranciersspecifieke RPC’s, zoals Cics client, Tuxedo client, DCE RPC, SQL*Net en dergelijke zijn beschikbaar vanuit VB en andere talen. Deze clients ondersteunen Dole, maar Dole mag niet worden gebruikt omdat het de server met handen en voeten aan Windows NT vastketent. (Al heeft Software AG inmiddels Dole-functionaliteit naar andere platforms gepoort.) NT zou een optie en geen verplicht nummer moeten zijn.
In de begindagen maakte Java gebruik van een uitbreiding genaamd Jdbc, een vertaling van Java-objecten naar de SQL-procedurele functies van Odbc. Dit kan nuttig zijn, maar niet op een client, omdat het Java weer terugzuigt in de dikke client-architectuur. Dikke Java-clients zijn net zo slecht als dikke VB-clients. Jdbc is nuttig op de server nu ook Java-servlets worden ondersteund, maar de echte toekomst op de server is weggelegd voor Enterprise Java Beans, niet voor Jdbc.
Dus Java-applets moeten objecten op andere machines kunnen activeren. Hiervoor zijn nieuwe technologieën noodzakelijk. Een uitbreiding van RPC’s als Dole volstaat niet, omdat Java objectgeoriënteerd is. Sun heeft hiertoe een basistechnologie geïntroduceerd, Remote Method Invocation (RMI). Maar RMI is puur Java-to-Java, en de wereld heeft al een standaard voor gedistribueerde objecttechnologie, namelijk Corba. Net als Dole kan ook RMI naar Corba worden vertaald. Maar zonder het dictaat van Microsoft kiest de Java-wereld voor een eigen oplossing, en zo is er een specifiek Java-interface voor Corba, Inter Internet ORB Protocol (IIOP). Sun blijft RMI aanprijzen, maar de meeste Java-applets groeien op met IIOP. Hierdoor hebben zij altijd toegang tot elk Corba-object, waar dan ook.
