De eerste kantoorapplicaties kenden weinig problemen, omdat ze alleen een file- en printserver nodig hadden. Dat was hoofdzakelijk Novell Netware. In de loop der tijd gingen echter steeds meer applicaties over op het ‘dikke’ client-model met gemeenschappelijke database-servers.
Toen kwamen de e-mailservers, en nu is er een overduidelijke behoefte aan ondersteuning van ‘dunne’ clients. Niet zozeer voor kantoorapplicaties, als wel voor transactiesystemen. Internet en het ‘world wide web’ leidden tot een nieuwe, speciale ‘dunne’ client-architectuur, en met de opkomst van e-commerce ontstond ook een grote behoefte aan transactiediensten. Voor al deze diensten moeten standaard-API’s bestaan, zodat programmeurs clients en servers met elkaar kunnen laten samenwerken. Het laagste niveau is dat van het communicatie-interface, waar Netbios en vooral sockets worden ondersteund; ook hier doet de invloed van het Web zich gelden. Boven de communicatie-API’s zijn er maar weinig file- en printstandaarden; voorbeelden zijn SMB, NCP en NFS, waardoor ondersteuning relatief eenvoudig is. In elk geval hoeven applicatieprogrammeurs deze protocollen zelden aan te spreken. Op de hogere niveaus is echter sprake van een wildgroei aan incompatibele producten, elk met hun eigen API. Rdbms-toegang is een sprekend voorbeeld. De client-software moet de redirector aanspreken, die de communicatielaag activeert om met de server te communiceren. Met een Rdbms moet deze API een gemeenschappelijke taal ondersteunen, SQL, en een verzameling primitieve operaties voor het opzetten van een verbinding, het afhandelen van fouten, het doorgeven van SQL-commando’s en het afbeelden van relationele gegevens naar variabelen in programma’s. De SQL Access Group definieerde een standaard, die door Microsoft werd geïmplementeerd als Odbc. Andere leveranciers als Oracle en Sybase hebben hun eigen client-API’s, waarmee de specifieke eigenschappen van hun product worden benut. Een Oracle-client werkt hierdoor niet samen met een Sybase-server, een Sybase-client werkt niet samen met Informix, en ga zo maar door. Odbc en het Java-equivalent Jdbc zijn prima, maar ze bieden niet de ideale vrijheid om elke client met elke server te kunnen laten samenwerken. E-mailsystemen kennen hetzelfde probleem: ze hebben vergelijkbare, maar incompatibele ‘messaging API’s’. ‘Dunne’ clients zijn er in twee smaken: (1) conventionele PC-code die een remote procedure aanroept, die weer wordt uitgevoerd op de server, en (2) Java-clients die requests met een Html-server uitwisselen via Http. Geen van deze benaderingen is vandaag de dag standaard, ondanks pogingen tot standaardisatie, zoals de remote machine interface (rmi). Het ‘dunne’ client-model is een gedistribueerd model, dat als specifieke point-to-point rpc (remote procedure call) geïmplementeerd kan worden, maar ook in de vorm van dynamische toegang tot een object op afstand. In het laatste geval is er een makelaar (broker), die het object opspoort en een bericht doorgeeft waarmee een specifieke functie kan worden uitgevoerd. De makelaar is nodig omdat het object zich in principe overal kan bevinden; als het object verhuist, kan de makelaar het opsporen zonder dat de client zich druk hoeft te maken. Door het toevoegen van parallelle IT-middelen kan de ‘performance’ dynamisch verbeterd worden. Dit gedistribueerde objectmodel is een van de weinige echte standaarden die we hebben; de standaard is gedefinieerd door de Object Management Group en heet de Common Object Request Broker Architecture (Corba). En hier komen we dan uit op het echte probleem. Microsoft, die de client-software domineert, heeft geen objectmodel, alleen een encapsulatietechniek genaamd Ole. Deze is ontworpen om PC-applicaties op elkaar te kunnen aansluiten. Ole is nu opgenomen in een totaalarchitectuur, genaamd COM. Het laten samenwerken van COM en Corba is niet eenvoudig, omdat de twee technologieën totaal verschillend zijn. De oorspronkelijke ‘dunne’ client-software maakte gebruik van rpc’s. Software op zowel de client als de server communiceerde om de twee met elkaar te synchroniseren, vandaar de term ‘synchrone API’, in tegenstelling tot de asynchrone API’s van berichtgeoriënteerde systemen. De procedure op de client prepareert de gegevens voor de server en roept dan een procedure aan, die eigenlijk op de server draait. De client geeft zowel de procedure-aanroep als de parameters – de gegevens – door aan de server. De server voert de procedure uit. Als de server klaar is, stuurt hij de resultaten terug naar de client, waarna het programma op de client gewoon doorloopt, nadat het antwoord van de server is doorgegeven aan het programma zelf. Er zijn een heleboel leveranciersspecifieke producten om rpc’s te implementeren; Dce bevat de HP-standaarden. Dce is een echte standaard, die helaas zelden gebruikt wordt. Om andere redenen zijn uitbreidingen van TP-monitoren als Cics en Tuxedo voor de client op dit moment de beste rpc-oplossingen. Microsoft jaagt echter ook op de server-markt en heeft daarom zijn eigen rpc gedefinieerd, dat een beetje is gebaseerd op Ole, maar daar weer niet compatibel mee is; het product heet Dcom. SAS heeft Dcom gepoort naar andere besturingssystemen als algemeen rpc-mechanisme voor dunne clients. Het is aardig om een de facto verzameling API’s voor rpc te hebben, maar toch is het beter om gebruik te maken van Tuxedo of Cics of het Corba-objectmodel.
