Het huwelijk tussen Java en SQL

SQL was, is en blijft de databasetaal voor relationele databases. De populariteit van Java is nog steeds groeiende. Dat deze twee talen ooit gekoppeld zouden worden, kon iedereen voorspellen, maar dat er zoveel verschillende manieren zouden ontstaan in zo'n korte tijd, dat hadden niet velen verwacht. Als een programmeur nu vanuit een Java-programma een SQL-database wil benaderen zal hij drie beslissingen moeten nemen: welk koppelingsmechaniek zal hij gebruiken, waar zal de koppeling plaatsvinden (op de client of op de server) en moet Java binnen de databaseserver ingezet worden?

JDBC was een van de eerste, beschikbare koppelingsmechanieken. Het was een van de eerste API's om vanuit Javaprogramma's en -applets SQL-instructies af te vuren op een databaseserver. JDBC is wat functionaliteit betreft gebaseerd op het bekende ODBC. Maar ODBC was gericht op niet-object-georiënteerde talen als C en dus niet geschikt voor Java. JDBC is dat uiteraard wel. De aanpak en werkwijze zijn wel afgeleid van ODBC en daarmee heeft JDBC niet alleen de voordelen maar ook de nadelen van ODBC. Twee van de bekendste nadelen zijn: de programmeur kan niet om SQL en de onderliggende tabelstructuur heen en moet deze taal dus beheersen; daarnaast is programmeren met JDBC omslachtig. Er moet kortweg veel geprogrammeerd worden.

Recentelijk is door een aantal leveranciers, waaronder IBM, Oracle en Tandem, gewerkt aan SQLJ, een andere koppelingsmechaniek. SQLJ is in feite embedded SQL binnen Javacode. Een programmeur die gebruik maakt van SQLJ heeft niet veel meer of minder mogelijkheden dan bij JDBC. Ook hij behoort SQL en de tabelstructuur te kennen. Het verschil is dat programmeren met SQLJ eenvoudiger is. Er zijn echter twee nadelen. Ten eerste, SQLJ wordt niet door elk Java-tool ondersteund (wel uiteraard door die van IBM en Oracle), maar dat is waarschijnlijk een kwestie van tijd. Ten tweede, SQLJ kan alleen in programma's gebruikt worden waar vooraf alle SQL-instructies bekend zijn. 

Zoals reeds vermeld, bij JDBC en SQLJ moet de programmeur wel bekend zijn met SQL. Tevens worden de tabellen en hun kolommen niet afgeschermd. Via de derde koppelingsmechaniek, genaamd JavaBlend, is dit wel het geval. JavaBlend (ooit ontwikkeld door Baan, maar nu commercieel uitgebracht door Sun) is een 'dikkere' laag software. In deze laag software wordt online de tabelstructuur vertaald naar echte Java-classes. Programmeurs hoeven dus niet bekend te zijn met SQL. Zij programmeren direct in Java. JavaBlend zorgt ervoor dat als een Java-object opgeslagen moet worden dit vertaald wordt in een aantal SQL-instructies.

Een vierde methode om Java aan SQL te koppelen is door tussen de applicatie en de SQL-databaseserver een object-georiënteerde database te plaatsen. De programmeur ziet dan alleen maar Java, want SQL wordt volledig afgeschermd. De OO-databaseserver verricht de vertaling naar SQL. Producten als Objectivity en ObjectStore ondersteunen deze methode. De interface die vanuit de applicatie dan gebruikt wordt, voldoet aan een ODMG-standaard en is in hoge mate portable.

Er zijn nog andere, wat meer productafhankelijke methodes om Java aan SQL te koppelen, zoals JRB van Ardent Software, maar daar zullen we nu niet op ingaan.

Een tweede beslissing die genomen moet worden betreft de locatie waar we SQL gaan benaderen? Gaan we SQL aanroepen op de client of op de server. We kunnen SQL aanroepen vanuit een stukje Java-code dat op de client draait en via het netwerk (en LAN, WAN of het Internet) een database benadert. In dit geval worden er SQL-instructies met resultaten over het netwerk gezonden. Of we kunnen vanuit onze Java-applicatie op de client een stuk Javacode op de server aanroepen en vervolgens benadert de servercode de (lokale) databaseserver. Indien we voor de tweede benadering kiezen, is het gebruik van een applicatieserver als Apptivity van Progress, SilverStream of Bea's WebLogic Enterprise sterk te overwegen. Bij deze laatste aanpak is het dan weer aan te raden de Enterprise JavaBeans in te zetten. Voor kleine, simpele omgevingen gaan we waarschijnlijk voor de eerste oplossing en wanneer we veel gebruikers hebben en een hoge mate van schaalbaarheid vereisen, is de tweede vorm wenselijk.

De derde beslissing is onafhankelijk van de vorige twee: willen we wel of niet Java binnen de databaseserver gebruiken. Bij diverse databaseservers, waaronder DB2, Informix en Oracle, kan Java nu als taal voor de stored procedures gebruikt worden. Zoals u misschien weet, ondersteunt elke databaseserver zijn eigen proprietary taal hiervoor; Sybase kent bijvoorbeeld Transact-SQL en Oracle een taal genaamd PL/SQL. Hierdoor zijn stored procedures nooit portable geweest. Indien Java gebruikt wordt, verdwijnt dit probleem deels. Een aan te raden beslissing dus.

Databaseservers als Sybase staan ook toe dat Java gebruikt wordt voor het definiëren van eigen datatypes. U kunt bijvoorbeeld zelf de datatypes POSTCODE en ISBN definiëren, met alle bijbehorende operatoren. U doet dat door een Java-class te schrijven - pure Java dus. Daarna kunt u de class als datatype gebruiken bij de instructie waarmee u tabellen en kolommen definieert. Sybase loopt op dit gebied voor op de concurrenten. Hopelijk volgen zij wel dit voorbeeld, want dan zou ook deze code portable worden.

Concluderend: We kunnen Java en SQL op vele verschillende manieren koppelen. Deze verscheidenheid heeft voordelen (iedereen kan zijn eigen 'beste' methode kiezen), maar ook nadelen. Er is nog te weinig ervaring om nu al te kunnen zeggen welke aanpak superieur is. Hopelijk verandert dat binnenkort.