SQLJ: Een interessant alternatief
Auteur: Rick F. van der Lans
Geschreven: oktober 1999
Gepubliceerd in: CM Corporate.Net, nummer 139
Recentelijk kreeg ik een folder binnen van een congres met als thema 'ontwikkelingen rond Java'. Alle bekende termen en afkortingen werden vermeld, op één na. Tot mijn verbazing ontbrak SQLJ, een meer dan interessant alternatief voor het benaderen van databases vanuit Java.
JDBC (Java DataBase Connectivity) was de eerste API die speciaal ontwikkeld was voor het benaderen van databases vanuit Java. Deze API is qua functionaliteit en opzet afgeleid van ODBC en heeft daarmee vele voor- en nadelen van ODBC geërfd. Als alternatief voor JDBC hebben we nu SQLJ gekregen.
De SQLJ-specificatie bestaat uit drie delen, waarvoor de creatieve namen 0, 1 en 2 bedacht zijn. Deel 0 beschrijft hoe in Java-progamma's SQL-instructies opgenomen kunnen worden. Dit deel is werkelijk een alternatief voor JDBC. In feite wordt hier een vorm van embedded SQL voor Java beschreven. Het essentiële verschil is dat bij JDBC SQL-instructies als parameters doorgegeven worden en bij SQLJ worden ze gewoon als instructies opgenomen. Er is dan wel een zogenaamde Jtranslator nodig om die SQL-instructies naar Java om te zetten. En dit moet gebeuren voordat de compiler aangeroepen wordt. Het grote voordeel van deze aanpak is dat de programmeur vele details, die hij wel bij JDBC moet opgeven, volledig kan overslaan. De Jtranslator voegt al die details toe. Dit komt de productiviteit ten goede.
Een nadeel is dat er nog maar weinig ontwikkeltools bestaan die SQLJ ondersteunen. Uiteraard de tools van de databaseleveranciers, zoals die van IBM (VisualAge for Java), Oracle (JDeveloper) en Sybase (PowerJ), ondersteunen wel SQLJ. De verwachting is dat de andere tools deze specificatie op korte termijn zullen implementeren. Een ander nadeel is dat er geen dynamisch SQL gebruikt kan worden. Echter, omdat JDBC en SQLJ in een programma door elkaar heen gebruikt kunnen worden, is dit geen groot nadeel.
Deel 1 van de SQLJ-specificatie beschrijft hoe met Java 'stored procedures' en 'stored functions' gecreëerd kunnen worden. Het creëren van een dergelijke stored procedure geschiedt in twee stappen. Eerst wordt een 'class' bestaande uit een aantal 'methods' gecreëerd. Hiervoor kan elk Java-ontwikkeltool naar keuze gebruikt worden. Een method kan de body gaan vormen van een stored procedure. Voor het benaderen van de database vanuit een method kan JDBC of SQLJ gekozen worden.
Vervolgens wordt een CREATE PROCEDURE-instructie zonder body gecreëerd. De procedure bestaat alleen uit een opsomming van de parameters en een koppeling naar de desbetreffende method. Hiermee wordt een method uit de gecreëerde class bekend gemaakt binnen de SQL-databaseserver. De CREATE
PROCEDURE-instructie is dus niet in Java geschreven. Dit is een SQL-instructie en schermt tevens af dat de body van de procedure in Java geschreven is. Hierdoor is voor een programmeur een Java-stored procedure niet te onderscheiden van een 'gewone' stored procedure. Een Java-procedure kan dus vanuit elke willekeurige taal op de bekende wijze aangeroepen worden.
Het schrijven van stored procedures in Java heeft het voordeel dat we portable stored procedures kunnen ontwikkelen. Voorheen was men gedwongen bij de meeste databaseservers een proprietary taal te gebruiken, bijvoorbeeld PL/SQL bij Oracle en Transact-SQL bij Sybase. Het kunnen werken met Java maakt het concept stored procedure veel aantrekkelijker. Let wel, een Java-stored procedure zal nog steeds SQL-instructies bevatten. Of die portable zijn, dat is natuurlijk nog steeds de verantwoordelijkheid van de programmeur. Maar we kunnen nu wel portable stored procedures ontwikkelen, wat voorheen niet mogelijk was.
Deel 2 van de SQLJ-specificatie beschrijft hoe een Java-class gebruikt kan worden als datatype voor een kolom bij het creëren van een tabel. De werkwijze is gelijkwaardig aan die bij stored procedures. Eerst wordt een Java-class met al haar methods gecreëerd. We creëren bijvoorbeeld de class Lokatie met de method BerekenAfstand. Deze class wordt daarna met een speciale utility bekend gemaakt binnen de databaseserver. Vervolgens kan de naam van de class gebruikt wordt als datatype voor een kolom in een CREATE TABLE-instructie. Alle methods kunnen daarna geactiveerd worden door ze te gebruiken binnen, bijvoorbeeld, SELECT- en INSERT-instructies. Het voordeel van deze aanpak is wederom portability, want de leveranciers die SQLJ deel 2 willen ondersteunen, dienen het allemaal op dezelfde wijze te realiseren.
Voor de duidelijkheid, SQLJ is geen toekomstmuziek, het is reeds geïmplementeerd en beschikbaar. Deel 0 is al door vele leveranciers op de markt gebracht, IBM, Informix, Oracle en Sybase hebben al implementaties van deel 1, en Informix en Sybase ondersteunen ook al deel 2.
Kortom, SQLJ biedt ons geen extra functionaliteit. Het is echter een alternatieve manier voor het benaderen van databases en tevens is het een alternatieve manier voor het bouwen van stored procedures en datatypes die het bestuderen meer dan waard is.
