Het is een lange weg terug naar de introductie van het relationele databasemanagementsysteem. In de jaren tachtig geloofde niemand dat relationele technologie genoeg in zich had voor transactietoepassingen; SQL was alleen bestemd voor op queries gebaseerde systemen. Wat hadden ze het fout! Alle nieuwe applicaties worden gebouwd op relationele databasemanagementsystemen, hoewel omvang en prestaties van vele zeer grote databases nog het gebruik van oude technologieën voorschrijven, met name Vsam en IMS.
De ontwikkeling van de minicomputer, in het bijzonder de VAX van DEC, viel samen met de introductie van rdbms-producten door Oracle, Ingres, Informix, Sybase, enzovoort. Er was nog een derde ontwikkeling: het snel volwassen wordende Unix.
Het probleem was dat VAX, VMS, Unix en de rdbms geen ondersteuning hadden voor transacties (‘roll-back’, ‘multi-threading’, I/O-beheer, beveiliging, enzovoort). VMS en Unix zijn relatief eenvoudige besturingssystemen met timesharing.
Er was een voor de hand liggend antwoord op het dilemma dat ontstond als gevolg van het ontbreken van transactiediensten in de besturingssystemen van de minicomputers: bouw ze in de rdbms in. Tegelijkertijd werd de technologie geïntroduceerd om de SQL-‘werkeenheid’ te precompileren, en eveneens in de rdbms op te slaan. Zo kunnen meerdere ‘instances’ van applicatieprogramma’s dezelfde UOW delen, waarmee de prestaties drastisch toenemen.
Met de komst van de pc en het Ethernet, en de dominantie van Unix, waren de rdbms-leveranciers al gevestigd. Alle introduceerden een driver aan de client-kant die in een pc onder Windows draait. Deze zou een client-applicatie in staat stellen om de uitvoering aan te roepen van een procedure die aan de server-kant is opgeslagen, en die bijna compatibel is met lokale Unix-applicaties. Deze producten, door Oracle getypeerd als SQL*net, waren heel slim. Ze hadden sessieprotocols, de mogelijkheid werkruimte over het netwerk in kaart te brengen, logische namen toe te wijzen om de integratie met ontwikkeltools voor de pc te vergemakkelijken, en foutenbeheer.
Met behulp van deze interfaces waren SQL-functies te verzenden in de vorm van tekst-strings voor ‘dynamische’ interpretatie en waren oproepen te doen aan geprecompileerde opgeslagen procedures. De eerste voor ad-hoc queries, de laatste voor transacties.
Helaas had elke leverancier van databases zijn eigen protocollen tussen client en server. De SQL Access Group (SAG), een standaardisatieorganisatie die het niet zou redden, probeerde een standaard te definiëren. In wanhoop nam Microsoft deze standaard over en implementeerde hem. Dit is de huidige standaard Odbc geworden. Compatibiliteit en prestaties vormen nog steeds een probleem; veel ondernemingen verkiezen dan ook bedrijfseigen varianten. Met de komst van Java en de op Java gebaseerde applicatieservers, werd eenzelfde soort standaard als Odbc geïntroduceerd, genaamd Jdbc.
De ontwikkeling van opgeslagen procedures werd versneld met de introductie van de procedurele extensie PL/SQL door Oracle. Dit was een bedrijfseigen Oracle-taal, die SQL procedurele mogelijkheden gaf. De logische scheiding van een applicatie in twee lagen, die hieraan voorafging, was eenvoudig. De SQL draaide in de server, de rest in de client. Nu moest de ontwikkelaar beslissen welk deel van de applicatielogica in de client draait en welke multi-usercomponenten in de procedures die in het rdbms zijn opgeslagen. De prestaties verbeterden duidelijk, maar de applicaties – geschreven voor de Oracle-rdbms – waren totaal bedrijfseigen. De rdbms van Oracle was de omgeving geworden voor het uitvoeren van de applicatie; het besturingssysteem was irrelevant. Oracle deed alle multi-threading, I/O-buffering, enzovoort.
IBM daarentegen volgde de multi-tier architectuur en richtte zijn applicatiecode op Cics en DB2 als het rdbms. Het bedrijf introduceerde ‘plans’ in DB2, het equivalent van de ‘statisch’ opgeslagen SQL-procedures in Oracle. Dit werkte allemaal prima, totdat IBM besloot DB2 te introduceren op alle platformen. Onder MVS kon DB2 hulp krijgen van Cics, enzovoort, maar niet op een NT-, Linux of Unix-platform. En dus ontwikkelenden ze met DB2/UDB een DB2-product dat de architectuur volgde van Oracle, Sybase, enzovoort. Tegelijkertijd zette Microsoft overtollige Ingres-technici in en vernieuwden ze hun speelgoed-rdbms tot het concurrerende SQL-Server van vandaag. Er is zelfs een ‘standaard’ taal-equivalent voor de PL/SQL van Oracle. De andere ontwikkeling was dat Java werd toegevoegd aan de omgeving van opgeslagen procedures; zowel in de opgeslagen procedures als in standaarden voor het aanroepen van procedures vanaf een Java-client (normaliter een applicatieserver die EJB draait). Zo wordt Jdbc nog ondersteund voor ‘dynamisch’ SQL, maar ‘statische’ (geprecompileerde, opgeslagen) procedures moeten worden aangeroepen via een nieuwe EJB-interface, genaamd Sqlj.
Voor de ontwikkelaar resteert echter een probleem: wat moet gecodeerd worden in de applicatieserver en wat in opgeslagen procedures. Een toenemend gebruik van de betere case-ontwerptools is het antwoord op de lange termijn, maar de databases zullen nooit volledig compatibel zijn! Het is lastig om te weten waar de applicatieserver eindigt en de database begint!
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.
