In Java, il primo passo da compiere per poter interagire con un DataBase consiste nel creare una connessione al DataBase stesso.
Volendo fare una similitudine con un concetto molto diffuso, potremmo affermare che il processo di comunicazione verso un DB è paragonabile allo scenario in cui un browser dialoga con un web server. Infatti, in tale situazione, il browser effettua una connessione verso il server, invia ad esso un messaggio formattato (usando il protocollo HTTP) e riceve indietro una risposta dal server stesso.
Con JDBC il codice del client (applicazione desktop o web) utilizza le API di JDBC per instaurare una connessione verso un DataBase server, invia a questo un messaggio formattato in modo ben definito e riceve indietro una risposta dal server.
JDBC rappresenta un'astrazione che permette di scrivere del codice Java che si interfacci con un DataBase generico, prescindendo dalle specifiche del singolo produttore. Naturalmente, affinché ciò sia realmente possibile, è necessario che le API di JDBC si interfaccino, a un livello successivo, con le librerie specifiche del particolare DB con cui si intende comunicare.
Cos'è un Driver
Quando si crea una connessione con un DataBase non è necessario creare dei socket né ricorrere alle classi del package java.net. Tutti i dettagli della connessione sono gestiti da una classe appartenente alla libreria specifica del DB che si vuole utilizzare. Tale classe è nota come Driver.
Quello che avviene nella pratica è che il codice del client si avvale di una classe denominata DriverManager alla quale viene delegato il compito di creare la connessione con il DataBase. Per tanto la classe si occupa di interagire direttamente con il driver in modo da rendere effettiva la connessione desiderata.
Il principale vantaggio di utilizzare i driver è quello della portabilità: è possibile, infatti, utilizzare le stesse API di JDBC per comunicare con i più svariati DBMS semplicemente cambiando la libreria utilizzata all'interno del codice Java. A questo si aggiunge una maggior semplicità nella scrittura dei sorgenti grazie al fatto che i dettagli implementativi di basso livello sono tutti gestiti dal driver.
I tipi di Driver
Le specifiche di JDBC definiscono quattro tipologie di driver che è possibile utilizzare nella comunicazione verso i DataBase. La Sun Microsystems li classifica nel seguente modo:
- JDBC-ODBC bridge
- Native-API partly Java technology-enabled driver
- Net-protocol fully Java technology-enabled driver
- Native-protocol fully Java technology-enabled driver
Driver di tipo 1: JDBC-ODBC bridge
Questo driver funge da interfaccia tra JDBC e altre API di accesso ai dati che, a loro volta, invocano una libreria di API native per portare a compimento il processo di comunicazione con il database.
Poiché le API native sono strettamente legate ad una singola piattaforma, si intuisce facilmente che questo tipo di driver è generalmente poco portabile.
Il driver di tipo 1 più comunemente utilizzato è il JDBC-ODBC bridge, in quanto disponibile senza costi aggiuntivi con il pacchetto Java SDK.
ODBC (Object Data Base Connectivity) sono una serie di API che consentono di comunicare con i DataBase, indipendente dal linguaggio di programmazione utilizzato.
Pertanto, il driver di tipo 1, rappresenta una sorta di strato di traduzione tra un'applicazione scritta in Java e il driver ODBC.
È importante sapere che un driver di tipo 1 non dovrebbe mai essere utilizzato in un ambiente di produzione a meno che non ci sia nessuna alternativa disponibile.
La Sun Microsystems stessa ne suggerisce l'utilizzo soltanto per ambienti di collaudo o applicazioni prototipali, raccomandando di avvalersi, quando si parla di applicazioni di tipo enterprise, di un driver di tipo 2 o 4.
Driver di tipo 2: Native-API partly Java technology-enabled driver
Questa tipologia di driver è simile alla precedente in quanto prevede una comunicazione con il database attraverso della API native. Tuttavia, si tratta di un driver più efficiente del precedente, in quanto l'invocazione alle API native avviene in modo diretto senza utilizzare uno strato di accesso ai dati addizionale (ODBC).
Allo stesso modo del driver di tipo 1, anche in questo caso non si può prescindere dall'esistenza della libreria di API native.
Driver di tipo 3: Net-protocol fully Java technology-enabled driver
Questo tipo di driver invia le chiamate verso il database passando per un componente di middleware, in esecuzione su un altro server.
La comunicazione verso il middleware server avviene utilizzando un protocollo di rete indipendente dal database. Il middleware server, a sua volta, comunica verso il DataBase utilizzando un protocollo specifico del DB che si vuole utilizzare.
Il middleware server, viene fatto risiedere su un computer differente da quello in cui viene eseguita l'applicazione client ma potrebbe trovarsi sullo stesso computer in cui risiede il DataBase.
Tra i pregi del driver di tipo 3 c'è sicuramente da sottolineare il fatto che esso non implica l'utilizzo di una libreria nativa da parte del middleware server. Infatti, quest'ultimo, potrebbe tranquillamente essere scritto per intero utilizzando il linguaggio Java. Quello che è richiesto è che il middleware server traduca la chiamata JDBC ricevuta dal client in una chiamata verso il database.
Driver di tipo 4: Native-protocol fully Java technology-enabled driver
Il driver di tipo quattro (noto anche come thin client) è l'unico sicuramente scritto interamente in Java.
Questo driver comunica direttamente con un database utilizzando il protocollo nativo del DB stesso.
Grazie al fatto che è scritto in Java e senza codice specifico di una determinata piattaforma, il driver di tipo 4, è fortemente portabile e utilizzabile laddove vi sia installata una Java Virtual Machine. In questo scenario, JDBC viene direttamente tradotto nel protocollo nativo del DB senza l'uso di ODBC o di API native di altro genere.
Quale Driver scegliere?
Solitamente, si tende a scegliere I driver di tipo 2 o 4 per le applicazioni di tipo web.
I driver 1 e 3, poiché aggiungono uno strato di comunicazione tra JDBC e il DataBase, sono in genere meno efficienti.
Se l'obiettivo dell'applicazione è quello di essere utilizzata su una singola piattaforma, allora il driver di tipo 2 è la scelta più giusta. Se, al contrario, si prevede di supportare svariate piattaforme allora sarà buona norma utilizzare un driver di tipo 4.
In determinati casi potrà essere utile eseguire dei test di performance prima di effettuare una scelta definitiva.
