Instituto de Computación

Facultad de Ingeniería
Universidad de la República Oriental del Uruguay

Técnicas Avanzadas para Gestión de

Sistemas de Información
Carrera de Ingeniería en Computación

Edición 2003

Tarea obligatoria sobre:

Tecnologías para Sistemas de Información

Título Estado de los accesos a Bases de Datos desde Java

utilizando JDBC
Estudiantes Ana Inés Mora
Marquicio Pagola
Leandro Portela
Marcos Marsicano

Docente encargado:
Dr. Ing. Hermann Steffen

1
 Estado de los accesos a Bases de Datos

desde Java utilizando JDBC

Técnicas Avanzadas para la Gestión de Sistemas de Información - 2003

GRUPO 7
Marcos Marsicano – CI: 3.659.140-9
Ana Inés Mora – CI: 3.589.162-0
Marquicio Pagola – CI: 3.213.360-1
Leandro Portela – CI: 4.153.495-1
 INDICE
Introducción.................................................................................................................. 4
¿ Qué es la API de JDBC ?........................................................................................ 4
¿ Por qué crear la API JDBC ? .................................................................................. 6
¿ Cómo debía ser JDBC ? ......................................................................................... 6
¿ Cómo funciona JDBC ?.......................................................................................... 7
Una base para otras APIs .......................................................................................... 8
Requisitos..................................................................................................................... 8
¿ Qué se debe instalar ?............................................................................................. 8
1. Instalar Java y el JDBC en la máquina............................................................... 8
2. Instalar un driver en la máquina......................................................................... 9
3. Instalar el Controlador de Base de Datos si es necesario. ................................... 9
Compatibilidad con SQL........................................................................................... 9
Arquitectura................................................................................................................ 10
El Modelo JDBC de Java ........................................................................................ 10
Tipos .......................................................................................................................... 11
Tipo 1: Puente JDBC-ODBC. ................................................................................. 11
¿ Qué es el Puente JDBC-ODBC ? ...................................................................... 12
El puente JDBC- ODBC...................................................................................... 13
Obteniendo un Driver JDBC ............................................................................... 13
Implementación del puente.................................................................................. 13
Instalación........................................................................................................... 13
Usando el puente................................................................................................. 13
Usando el puente desde un Applet....................................................................... 13
La mayoría de los Browsers no soportan el Puente .............................................. 13
Drivers ODBC conocidos para trabajar con el puente .......................................... 14
Tipo 2: Driver parcial de Java ................................................................................. 15
Tipo 3: Drivers Java puros para middleware de bases de datos................................ 16
Tipo 4: Driver Java puro directo a la base de datos.................................................. 17
Versiones.................................................................................................................... 17
Qué incluye la API de JDBC 2.0 ............................................................................. 18
¿ Qué es pooling de conexiones ?............................................................................ 19
La API del núcleo de JDBC 2.0........................................................................... 19
El paquete opcional de la API JDBC 2.0 ............................................................. 19
Beneficios del pooling de conexiones...................................................................... 19
Pautas para escribir un driver JDBC............................................................................ 20
Requerimientos para todos los drivers ..................................................................... 20
Implementar métodos en las interfaces ................................................................ 20
Implementar un inicializador estático .................................................................. 21
Soportar extensiones al SQL-92 Entry Level ....................................................... 21
Soportar funciones escalares ............................................................................... 22
Proveer bloqueo para actualizaciones y eliminaciones posicionadas .................... 24
Soportar Multithreading ...................................................................................... 24
Lanzar excepciones en presencia de parámetros de entrada truncados ................. 24
Usar comportamientos por defecto para los tipos de datos SQL3......................... 24
Variantes permitidas ............................................................................................... 24
Cuando una funcionalidad no es soportada.......................................................... 25
 Variación en propiedades fundamentales............................................................. 25
Agregando funcionalidad .................................................................................... 25
Responsabilidades de seguridad de los drivers......................................................... 25
Verificar conexiones TCP compartidas................................................................ 25
Verificar todos los accesos locales a archivos...................................................... 26
Asumir lo peor .................................................................................................... 26
Lanzar una SQLException en caso de excepciones.............................................. 26
Implementaciones sugeridas.................................................................................... 26
Búsqueda anticipada de filas ............................................................................... 26
Ofrecer métodos "finalize” para Applets ............................................................. 27
Evitar estados dependientes de la implementación............................................... 27
Ventajas / Desventajas ................................................................................................ 27
Similitudes y diferencias con ODBC....................................................................... 27
API JDBC Vs ODBC.............................................................................................. 28
Comparación del uso de JDBC en un modelo de 2 capas y en uno de 3 capas: ........ 29
Alternativas a JDBC ............................................................................................... 30
Limitaciones de JDBC ............................................................................................ 30
Ventajas de la tecnología JDBC .............................................................................. 30
Influencia de datos de empresa existentes............................................................ 30
Desarrollo simplificado de la empresa................................................................. 31
Cero configuración para redes de computadoras.................................................. 31
Cero Instalación .................................................................................................. 31
Impulso en la industria ........................................................................................ 31
Conexión a la base de datos identificada por una URL ........................................ 31
Conclusiones .............................................................................................................. 32
Referencias ................................................................................................................. 33
Introducción
Durante los últimos años, la industria de la computación ha visto una explosión
en el crecimiento de Internet y la World Wide Web (WWW). En un corto período de
tiempo, la WWW ha evolucionado desde la entrega de simples páginas web estáticas
hasta la disponibilidad de las optimizadas páginas web dinámicas, creadas a través de
varias extensiones de los servidores Web existentes.

Durante el mismo período de tiempo, Java ha llegado a ser el lenguaje elegido

para desarrollar y desplegar aplicaciones Internet / intranet. Todos los SO líderes y
plataformas de browser están construyendo Máquinas Virtuales de Java en sus sistemas.
Adicionalmente, los mayores vendedores de herramientas de desarrollo y proveedores
de aplicaciones están proveyendo de soporte para Java. Los Java “applets” y “servelet”
aparecen por toda la Web, brindando rica funcionalidad a lo que antes era sólo un medio
estático.

El próximo paso en esta evolución, era el uso de Java para crear applets que
permitieran aplicaciones de misión crítica de negocio y transacciones procesadas sobre
la Internet / intranet. Este nivel requería nuevos métodos de alta performance y robustos
para acceder a los repositorios de datos corporativos. Uno de estos métodos es JDBC –
el estándar de Java para Conectividad de Bases de Datos.

¿ Qué es la API de JDBC ?

JDBC (Java Database Connectivity) es el equivalente en Java de ODBC. El
estándar JDBC fue creado con la ayuda de las bases de datos líderes y proveedores de
herramientas de bases de datos tales como Sybase, Oracle, Informix, Symantec, y
Intersolv. El estándar JDBC esta basado en X/Open SQL Call Level Interface, la misma
base que ODBC. JDBC existe desde 1996, y fue incluido desde la versión 1.1 del JDK
como el paquete java.sql, aunque también se hizo disponible para usarse con el JDK
1.02.

JDBC es una API de Java para acceder, virtualmente a cualquier tipo de datos
tabulares. La API JDBC consiste en un conjunto de clases e interfaces escritas en el
lenguaje de programación Java que provee una API estándar para desarrolladores de
herramientas/bases de datos y hace posible la escritura de importantes aplicaciones de
base de datos industriales usando una API cien por ciento Java.

Este incluye la API JDBC 1.0, que provee las funcionalidades básicas para el
acceso a datos, haciendo fácil el envió de sentencias SQL a sistemas de bases de datos
relacionales. La API JDBC 2.0 complementa a la API básica con elementos más
avanzados haciendo posible interactuar con otros tipos de fuentes de datos, tales como
archivos conteniendo datos tabulares; también provee una forma estándar para acceder a
los últimos elementos objeto-relacional que son soportados por los manejadores de
bases de datos relacionales de hoy en día. Además, la nueva API incluye cosas tales
como result set navegable y actualizable, actualizando múltiples ítems de datos con un
simple comando, y performance mejorada. Esta extiende la tecnología JDBC más allá
del cliente, hacia el servidor con “connection pooling” y transacciones distribuidas.
Connection pooling permite a los programadores reusar conexiones de bases de datos,
no siendo necesario hacer una nueva conexión a la base de datos para cada comando
nuevo de JDBC.
 El valor de la API JDBC es que una aplicación puede acceder virtualmente a
cualquier fuente de datos y correr en cualquier plataforma con la Máquina Virtual de
Java. En otras palabras, en la API JDBC, es innecesario escribir un programa para
acceder a una base de datos Sybase, otro programa para acceder a una base de datos
Oracle, otro programa para acceder a una base de datos IBM DB2, etc. Uno puede
escribir un programa simplemente usando la API JDBC, y el programa será capaz de
enviar SQL u otras sentencias a la fuente de datos. Y, con una aplicación escrita en el
lenguaje de programación Java, no es necesario preocuparse de escribir diferentes
aplicaciones para correr en diferentes plataformas. La combinación de la plataforma
Java y la API JDBC permite a un programador escribir una vez y correr en cualquier
lado.

La API de JDBC 2.0 extiende lo que puede hacerse con la plataforma Java. Por
ejemplo, la API de JDBC hace posible publicar una página web conteniendo un applet
que usa información obtenida desde una fuente de datos remota. O una empresa puede
usar la API de JDBC para conectar a todos sus empleados (aún si ellos están usando una
conglomeración de máquinas Windows, Macintosh y UNIX) a una o más bases de datos
internas vía una intranet. Con más y más programadores usando el lenguaje de
programación Java, la necesidad de un acceso a datos fácil y universal desde Java
continúa creciendo.

Manejadores de Sistemas de Información como la combinación de la plataforma

Java y la tecnología JDBC hacen la diseminación de la información fácil y económica.
Las empresas pueden continuar usando sus bases de datos y acceder a información
fácilmente aún si ésta está almacenada en diferentes DBMS u otras fuentes de datos. El
tiempo de desarrollo de nuevas aplicaciones es corto. La instalación y el control de
versiones es realmente simplificado. Un programador puede escribir una aplicación o
actualizar una, ponerla en el servidor, y todo el mundo tiene acceso a la última versión.
Y para los negocios de servicios de venta de información, la combinación de las
tecnologías de Java y JDBC ofrece una mejor forma de divulgar información
actualizada a clientes externos.

Al igual que ODBC, JDBC está fuertemente influenciada por las APIs
programables de bases de datos ya existentes, tales como X/OPEN SQL Call Level
Interface. Sun quiso reusar la abstracción clave de estas APIs, que sería fácilmente
aceptada por los vendedores de bases de datos y capitalizada en el conocimiento
existente de ODBC y desarrolladores de clientes SQL. Además, Sun reconoció que
derivando su API de otras ya existentes podía proveer rápidos desarrollos de soluciones
para motores de bases de datos que soportaran los viejos protocolos. Especialmente, se
trabajó en paralelo con Intersolv para crear un puente con ODBC que transformara
llamadas JDBC en llamadas ODBC, dando así acceso desde aplicaciones Java a
cualquier DBMS que soportara ODBC.

JDBC intenta mantenerse lo más simple posible mientras provee a los

desarrolladores con la máxima flexibilidad posible. Las tareas simples y comunes usan
interfaces simples, mientras que las tareas menos comunes o bizarras son provistas con
interfaces extras. Por ejemplo, tres interfaces manejan una vasta mayoría de accesos a la
base de datos. JDBC sin embargo provee muchas otras interfaces para manejar tareas
más complejas e inusuales.
¿ Por qué crear la API JDBC ?
Java era un lenguaje que prometía independencia de plataformas, lo cual lo hacía
un ambiente muy atractivo para crear todo tipo de aplicaciones, y el acceso a base de
datos era ya más una necesidad que un lujo.

Por ejemplo, aquí se tienen tres casos en donde esta solución es una necesidad:
N Cuando existe la necesidad de diseminar información internamente en una
compañía grande cuando los departamentos han sido estandarizados en
diferentes plataformas.
N Si una corporación ha pasado por una fusión y se encuentra con diferentes
sistemas operativos y bases de datos.
N Para e-commerce, aplicaciones que corren sobre Internet, cuando la compañía
no tiene control sobre el software que sus clientes usan. Los clientes solo
necesitan la tecnología Java apropiada, que puede ser descargada en el momento
a sus computadoras.

El lenguaje de programación Java, siendo robusto, seguro, fácil de usar, fácil de

entender, y descargable de la red, es un excelente lenguaje para aplicaciones de bases de
datos. Lo que se necesita es una manera para que las aplicaciones Java hablen con una
variedad de diferentes fuentes de datos. JDBC es el mecanismo para hacer esto.

¿ Cómo debía ser JDBC ?

Trabajando con líderes en el campo de las bases de datos, se desarrollo una API
simple para el acceso a base de datos, JDBC. Durante este proceso, se mantuvieron tres
metas en mente:
N JDBC debía ser una API a nivel de SQL.
N JDBC debía capitalizar la experiencia de APIs de base de datos ya existentes.
N JDBC debía ser simple.

La gente en Sun se preguntó como atraer a los programadores y a las empresas a

invertir su dinero y su tiempo en JDBC. Entonces decidieron que debía tener ciertas
ventajas sobre sus cercanos competidores.
N El programador debía sentirse como si usara Java, es decir, le debía proveer esa
estructura de objetos y un mapeo suave al paradigma de "tipos de datos" que
ofrecen los DBMS.
N El programador debía sentirse en contacto directo con el DBMS, no con un
socket o un proceso en cualquier maquina.
N La comunicación con el manejador de bases de datos debía ser fácil de
programar. Esto es, que las empresas que quisieran hacer controladores JDBC
para comunicarse con sus productos lo pudieran hacer en forma sencilla.
N Debía ser flexible para aceptar configuraciones diferentes de conectividad, o sea,
que la misma aplicación del desarrollador pudiese acceder a varios DBMS a la
vez, tal vez hasta en varios hilos simultáneos.
¿ Cómo funciona JDBC ?
La arquitectura de JDBC está basada en un conjunto de interfaces y clases de
Java que permiten conectarse con bases de datos, crear y ejecutar sentencias de SQL,
recuperar y modificar datos de una base de datos.

Todo el trabajo con JDBC comienza con la clase DriverManager, que es la que
establece las conexiones con las fuentes de datos, mediante los drivers o controladores
JDBC.

Los drivers de bases de datos se definen mediante clases que implementan la

interfaz Driver. Cada driver sabe cómo convertir peticiones SQL para una base de datos
concreta. Si no disponemos del driver adecuado, no podemos conectarlos a una base de
datos, dependiendo de las implementaciones concretas de cada fabricante. Por lo tanto,
lo primero que debe llevar a cabo un programa es cargar el driver adecuado para que el
código Java pueda comunicarse con la base de datos.

Podemos describir el funcionamiento de un programa Java con JDBC en los

siguientes pasos:
N Importar las clases necesarias
N Cargar el Driver JDBC
N Crear un objeto Connection
N Identificar el origen de datos
N Crear un objeto Statement
N Ejecutar una consulta con el objeto Statement
N Liberar el objeto ResultSet
N Liberar el objeto Statement
N Liberar el objeto Connection

El siguiente fragmento de código es un simple ejemplo de la carga de un driver

JDBC:
Connection con = DriverManager.getConnection(
"jdbc:myDriver:wombat", "myLogin", "myPassword");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM
Table1");
while (rs.next()) {
int x = rs.getInt("a");
String s = rs.getString("b");
float f = rs.getFloat("c");
}

Según Sun, están disponibles drivers especializados de JDBC para la mayoría

de las base de datos — incluyendo bases de datos relacionales desde Oracle Corp., IBM,
Microsoft Corp., Informix Corp. y Sybase Inc. — así como para cualquier fuente de
datos que use el sistema Microsoft's Open Database Connectivity.
Una base para otras APIs
La API de JDBC es usada para invocar comandos SQL directamente. Trabaja
muy bien y es más fácil de usar que otras APIs de conectividad de bases de datos, pero
fue diseñada para ser una base sobre la cual construir interfaces y herramientas
alternativas. Una interfaz alternativa tratará de ser "amigable" usando una API más
entendible o más conveniente que es transmitida en forma transparente dentro de la API
de JDBC. Dado que la API de JDBC es completa y lo suficientemente poderosa para ser
usada como base, tiene varios tipos de APIs alternativas desarrolladas sobre ella,
incluidas las siguientes:
1. SQL embebido para Java. Un consorcio que incluye Oracle, IBM, Sun, y otros
ha definido la especificación SQLJ para proveer esto. JDBC requiere que las
sentencias SQL básicamente sean pasadas como strings no interpretados a
métodos Java. Un preprocesador embebido de SQL provee chequeo de tipos en
tiempo de compilación y permite al programador mezclar e intercalar sentencias
SQL con sentencias Java. Por ejemplo, una variable Java puede ser usada en una
sentencia SQL para recibir o proveer valores SQL. El preprocesador SQLJ
traduce esta mezcla de Java y SQL en el lenguaje Java con llamadas a JDBC.
2. Un mapeo directo entre tablas de base de datos relacional con clases de Java.
Sun Microsystems cuenta con Java Blend_ como proveedor de esto, y tiene
otros productos similares. En este mapeo “objeto/relacional”, una tabla se
convierte en una clase, cada fila de la tabla se convierte en una instancia de la
clase, y cada valor de columna corresponde a un atributo de esa instancia. Los
programadores pueden operar directamente con objetos Java, las llamadas SQL
requeridas para buscar y almacenar los datos son generadas automáticamente en
segundos. Java Blend también permite un mapeo más sofisticado, por ejemplo,
cuando filas o múltiples tablas son combinadas en una clase Java.

Como el interés en la tecnología JDBC ha crecido, otras herramientas basadas

en JDBC se han desarrollado para hacer la construcción de programas más fácil. Por
ejemplo una aplicación debe presentar un menú de tareas de base de datos del cual
elegir. Luego que una tarea es elegida, la aplicación presenta blancos en donde llenar la
información necesaria para ejecutar la tarea seleccionada. Con la entrada requerida ya
ingresada, la aplicación automáticamente invoca los comandos de JDBC necesarios.
Con la ayuda de esta aplicación, los usuarios pueden ejecutar tareas de bases de datos
aún cuando tengan poco o ningún conocimiento de la sintaxis de SQL.

Requisitos
¿ Qué se debe instalar ?
Todo lo que se necesita instalar se describe a continuación:

1. Instalar Java y el JDBC en la máquina.

Para instalar tanto la plataforma JAVA como la API JDBC, simplemente se
siguen las instrucciones de descarga de la última versión del J2SDK (Java 2 Standard
Development Kit). Junto con el J2SDK también viene JDBC.. La última versión de Java
se puede encontrar en el sitio de Sun http://java.sun.com
2. Instalar un driver en la máquina.
El driver debe incluir instrucciones para su instalación. Para los drivers JDBC
escritos para controladores de bases de datos específicos la instalación consiste sólo en
copiar el driver en la máquina; no se necesita ninguna configuración especial.

El driver "puente JDBC-ODBC" no es tan sencillo de configurar. Si se descarga

la última versión de Java, automáticamente se obtendrá una versión del puente JDBC-
ODBC, que tampoco requiere una configuración especial. Sin embargo, ODBC, si lo
necesita. Si no se tiene ODBC en la máquina, es necesario preguntarle al vendedor del
driver ODBC sobre su instalación y configuración.

Afortunadamente, la interfaz JDBC y muchos de los drivers JDBC que se

necesitan están instalados por defecto así que ya se tienen si se ha instalado el J2SDK.
Los drivers que no han sido instalados por defecto pueden ser descargados de la web.

3. Instalar el Controlador de Base de Datos si es necesario.

Si no se tiene instalado un controlador de base de datos, es necesario seguir las
instrucciones de instalación del vendedor. La mayoría de los usuarios tienen un
controlador de base de datos instalado y trabajarán con una base de datos establecida.

Compatibilidad con SQL

SQL es el lenguaje estándar para acceder a bases de datos relacionales.
Desafortunadamente, SQL no es aún un estándar como se desearía.

Un área de dificultad es que los tipos de datos usados por diferentes DBMSs
(DataBase Management Systems) a veces varía, y las variaciones pueden ser
significantes.

JDBC maneja esto definiendo un conjunto genérico identificadores de tipos de

SQL en la clase java.sql.Types.

Otra área de dificultad con la compatibilidad de SQL es que a pesar que la

mayoría de los DBMSs usan una forma estándar de SQL para funcionalidades básicas,
ellos no conforman el estándar de sintaxis y semántica de SQL más recientemente
definido para funcionalidades avanzadas.

Por ejemplo, no todas las bases de datos soportan procedimientos almacenados o

outer joins y aquellos que lo hacen, no siempre son consistentes con los demás.
También el soporte para elementos de SQL3 y tipos de datos varía enormemente. Se
espera que la porción de SQL que es realmente estándar se expanda para incluir más y
más funcionalidades. Por el momento, sin embargo, la API JDBC debe soportar SQL
como es.

Una manera en que la API JDBC maneja este problema es permitiendo que
cualquier cadena de consulta sea pasada hacia el driver de DBMS. Esto significa que
una aplicación es libre de usar tantas funcionalidades de SQL como desee, pero
corriendo el riesgo de recibir un error en algunos DBMSs. En efecto, una consulta de
aplicación puede ser algo más que SQL, o puede ser un dialecto especializado de SQL
diseñado para DBMSs específicos (para consultas de documentos o imágenes, por
ejemplo).

Una segunda forma en que JDBC maneja los problemas de compatibilidad con
SQL es proveyendo de cláusulas de escape del estilo ODBC. La sintaxis de escape
provee una sintaxis estándar de JDBC para muchas de las áreas comunes de
divergencias de SQL. Por ejemplo, hay escapes para literales de fechas y para llamadas
a procedimientos almacenados.

Para aplicaciones complejas, JDBC maneja la compatibilidad en una tercer

manera. La API provee información descriptiva acerca del DBMS por medio de la
interfaz DatabaseMetaData así estas aplicaciones pueden adaptarse a los
requerimientos y capacidades de cada DBMS.

Dado que la API JDBC es usada como una API base para desarrollar
herramientas de acceso a bases de datos y otras APIs, también tiene que afrontar el
problema de compatibilidad para cualquier cosa construida sobre ella. Un driver JDBC
debe soportar por lo menos ANSI SQL-92 Entry Level. Note que aunque la API JDBC
2.0 incluye soporte para SQL3 y SQLJ, los drivers JDBC no están obligados a
soportarlos.

Arquitectura
El Modelo JDBC de Java
JDBC logra sus metas a través de un conjunto de interfaces Java, cada una
implementada en forma diferente por proveedores individuales. El conjunto de clases
que implementan las interfaces de JDBC, para un motor de bases de datos particular, es
lo que llamamos driver JDBC. Existen drivers específicos para cada DBMS, que son
implementaciones diferentes para cada uno de ellos. Cada uno de estos drivers posee
código diferente para establecer la comunicación con el DBMS correspondiente.
Existen varias configuraciones para ejecutar una aplicación usando JDBC, pero lo
principal es tener accesible el driver que se conectará al DBMS. La idea detrás de JDBC
es que al desarrollar una aplicación para una base de datos, no se tenga que pensar sobre
la implementación de las clases subyacentes, ya que JDBC oculta las características
específicas de cada base de datos y nos permite preocuparnos sólo en los aspectos de la
aplicación que estamos desarrollando.

JDBC consiste básicamente de cinco clases en el paquete java.sql. Las clases son:
N java.sql.Driver que representa al driver.
N java.sql.DriverManager que es la que establece las conexiones con las fuentes de
datos, mediante la carga de los drivers o controladores JDBC.
N java.sql.Connection hace la conexión a la base de datos.
N java.sql.Statment ejecuta las cláusulas.
N java.sql.ResultSet recibe los resultados de las cláusulas que se ejecutaron.
 Los drivers de bases de datos JDBC se definen mediante clases que implementan
la interfaz Driver. Cada driver sabe como convertir peticiones SQL para una base de
datos concreta. Si no se dispone del driver adecuado, no se podrá establecer una
conexión con la base de datos deseada, ya que el JDBC depende de las
implementaciones concretas de cada fabricante. Por lo tanto, lo primero que debe llevar
a cabo un programa es cargar el driver adecuado para que el código Java pueda
comunicarse con la base de datos. Sólo la clase java.sql.DriverManager se encuentra
completamente implementada; las demás son implementadas por el driver específico de
la base de datos con la que se desea trabajar.

Tipos
Una vez que su motor de base de datos esta instalado y su base de datos esta
configurada, necesitará un driver JDBC para el motor de base de datos. Los motores de
bases de datos mas comerciales, tales como Oracle, tienen drivers comerciales JDBC.
La mayoría de estos, sin embargo, le permiten tenerlo por un período de prueba gratis
para experimentar con el driver.

Estos drivers vienen en cuatro variantes. Los tipos 1 y 2 están pensados para
programadores que escriben aplicaciones, mientras que los tipos 3 y 4 son típicamente
usados por los vendedores de Middleware o bases de datos. La siguiente es una
descripción mas detallada de estos drivers:

Tipo 1: Puente JDBC-ODBC.

Provee acceso JDBC vía uno o mas drivers Open Database Connectivity
(ODBC). ODBC, el cual precede a JDBC, es ampliamente usado por desarrolladores
para conectarse a bases de datos en un ambiente no Java.
 Aplicación
Java

API JDBC


 

    

ODBC

Lib. Cliente DB

Servidor
B.D.

¿ Qué es el Puente JDBC-ODBC ?

El Puente JDBC-ODBC es un driver JDBC que implementa operaciones JDBC
al traducirlas a operaciones ODBC. Para ODBC esto aparenta como un programa de
aplicación normal. El Puente implementa JDBC para cada base de datos para la cual
haya un driver ODBC disponible. El puente es implementado como el paquete Java
sun.jdbc.odbc y contiene una librería nativa que se usa para acceder ODBC.

El Puente JDBC-ODBC fue desarrollado por Sun para tomar ventaja del
grandísimo número de fuentes de datos para ODBC. Las applets Java son escritas
usando la API de Java. Estas llamadas a JDBC son pasadas al puente JDBC-ODBC y
convertidas en las APIs ODBC del lenguaje C. Las llamadas ODBC son luego pasadas
al driver propietario ODBC para el almacenamiento de los datos en el back-end.

La ventaja principal de usar el puente JDBC-ODBC es que las aplicaciones

pueden acceder fácilmente a las bases de datos de múltiples vendedores al elegir el
driver apropiado para ODBC, debido a que las llamadas JDBC son convertidas a ultimo
momento en llamadas ODBC. Sin embargo, este tipo de conectividad a bases de datos
no implica un gasto considerable y complejidad, debido a que las llamadas deben ir
desde JDBC al puente y luego al driver ODBC, luego, de ODBC a la API nativa del
cliente, y para terminar en la base de datos. Adicionalmente este tipo de driver no
permite la entrega just-in-time de las Applets de Java. El software debe ser pre instalado
en el cliente usando el puente JDBC-ODBC. Los requerimientos para pre instalar el
software implican las mismas cargas administrativas que para aplicaciones
cliente/servidor. Además, el puente JDBC-ODBC típicamente es adecuado solamente
para aplicaciones intranet donde hay un control y mantenimiento de las máquinas
clientes.
El puente JDBC- ODBC
Si es posible use un driver puro de Java JDBC en vez de un puente y/o un driver
ODBC. Esto elimina completamente la configuración del cliente requerida por ODBC.
También elimina el potencial de que la Java VM pueda ser “corrompida” por un error
en el código nativo existente en el puente o en el driver ODBC (esto es: la librería
nativa del puente, la librería de manejo del driver ODBC, la librería del driver de ODBC
y la librería de la base del cliente).
Se recomienda el uso del driver JDBC-ODBC para prototipar los esfuerzos y para casos
cuando no existe otra tecnología basada en drivers JDBC. Si es comercial, o sea que
todos los drivers Java- JDBC están disponibles, se recomienda que sea usado en vez del
Puente.

Obteniendo un Driver JDBC

Se recomienda que se obtenga un driver comercial de JDBC de su vendedor de
bases de datos o su vendedor de bases de datos middleweare, y además se recomienda el
uso del puente de JDBC-ODBC solamente para usos experimentales o cuando no hay
otra alternativa.

Implementación del puente

El puente es implementado en Java y usa métodos nativos para llamar a ODBC.

Instalación
El puente es instalado automáticamente con Java 2 SDK, Standard Edition,
como paquete sun.jdbc.odbc. Se debe ver la propia información de su vendedor de
drivers para ODBC para la instalación y configuración de ODBC. No se necesita una
configuración especial para el puente. Se debe referir al proveedor de base de datos para
información de configuración e instalación.

Usando el puente
El puente es usado abriendo una conexión JDBC usando una URL con el
subprotocolo odbc. Antes de que la conexión sea establecida, la clase del driver del
puente, sun.jdbc.odbc.JdbcOdbcDriver, debe ser también agregada a la propiedad
Java.lang.System llamada jdbc.drivers, o debe ser explícitamente cargada usando
un cargador de clases Java. La carga explícita se puede hacer con la siguiente línea de
código:

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

Cuando es cargado, el driver ODBC crea una instancia de si mismo y lo registra

con el manejador de drivers JDBC.

Usando el puente desde un Applet

El uso de JDBC con un driver puro Java JDBC funciona bien con las Applets, a
diferencia del driver del puente, que no lo hace con las Applets.

La mayoría de los Browsers no soportan el Puente

Debido a que el Puente es un componente opcional del Java 2 SDK, Standard
Edition, puede que este no sea provisto por el Browser. Aún si es provisto, solamente
las Applets confiables (aquellas permitidas a escribir archivos) serán las capaces de usar
el puente. Se requiere esto para preservar la seguridad del Applet. Finalmente, y aún si
el Applet es confiable, las librerías de ODBC y del cliente de DBMS deben ser
configuradas en cada cliente.

Drivers ODBC conocidos para trabajar con el puente

Los drivers ODBC están disponibles para Oracle, Sybase, Informix, Microsoft
SQL Server, e Ingres.

Pros: Es una buena aproximación para aprender JDBC. Puede ser útil para compañías
que ya tengan drivers ODBC instalados en cada máquina cliente – típicamente el caso
de máquinas con Windows corriendo aplicaciones productivas. Quizás sea la única
manera de tener acceso a bases de datos de escritorios de bajo porte.
Contras: No es para aplicaciones de gran escala. La performance se ve afectada debido
a que hay algún costo asociado al trabajo de traducción entre JDBC y ODBC. Además,
no soporta todas las características de Java. Los usuarios están limitados por la
funcionalidad subyacente del driver ODBC.
Tipo 2: Driver parcial de Java
Convierte las llamadas que el desarrollador escribe en la API JDBC
de programación de aplicaciones en llamadas que conectan con la interfaz de
programación de aplicaciones de la máquina cliente para la base de datos específica.,
tal como Informix, IBM, Oracle o Sybase. De nuevo, esta solución requiere software en
el sistema del cliente.

Aplicación
Java

API JDBC







Lib. Cliente DB

Servidor
B.D.

Pros: La performance es mejor que la del Tipo 1, en parte porque el driver del Tipo 2
contiene código compilado que está optimizado para el sistema operativo del servidor
de bases de datos del back-end.
Contras: El usuario necesita asegurarse que el driver JDBC de la base de datos del
vendedor esté cargado en la máquina cliente. Debe haber código compilado para cada
sistema operativo sobre el cual se desee ejecutar la aplicación. El mejor uso de éste es
para ambientes controlados tales como Intranets.
Tipo 3: Drivers Java puros para middleware de bases de datos
Éste tipo de driver tiene la característica principal de que provee conectividad
para muchas bases de datos diferentes. Traduce llamadas JDBC al protocolo del
middleware del vendedor, el cual, a su vez, es convertido al protocolo específico de la
base de datos por el software del servidor del middleware. Como se puede ver, este
driver es extremadamente flexible ya que no requiere código instalado en el cliente y
que un único driver puede proveer acceso a múltiples bases de datos.




 


API JDBC











  

Servidor
B.D.

Pros: Mejor performance que los Tipo1 y Tipo 2. Puede ser usado cuando una
compañía tiene múltiples bases de datos y quiere usar un único driver JDBC para
conectarlas a todas. Está basado en el servidor, así que no se necesita código del driver
de JDBC en cada máquina cliente. Por razones de performance, el componente del
servidor del back-end está optimizado para el sistema operativo sobre el cual la base de
datos se está ejecutando.
Contras: Se necesita algo de código específico en el servidor del middleware. Si el
middleware debe ejecutarse en diferentes plataformas, puede que sea mas efectivo un
driver de Tipo 4.
Tipo 4: Driver Java puro directo a la base de datos.
Convierte llamadas JDBC en paquetes que son enviados a través de la red en el
formato propietario usado por la base de datos específica. Permite realizar una llamada
directa desde la máquina cliente a la base de datos.

 

 


API JDBC








Servidor
B.D.

Pros: Mejor performance que los Tipos 1 y 2. No se necesita instalar software especial
en el cliente y el servidor. Puede ser descargado dinámicamente.
Cons: No esta optimizado para el sistema operativo del servidor, asi que el driver no
puede tomar ventaja de las características del sistema operativo. ( El driver esta
optimizado para la base de datos y puede tomar ventaja de las funcionalidades de la
base de datos del servidor). Además, el usuario necesita un driver diferente para cada
base de datos diferente.

Versiones
JDBC Básico cubre la API JDBC 1.0, el cual está incluido en el JDK 1.1.
La segunda parte cubre la API JDBC 2.0, que forma parte de la versión 1.2 del JDK.
También describe brevemente las extensiones de la API JDBC, que, al igual que otras
extensiones estándar, serán liberadas independientemente.

La API de JDBC 2.0: Es el paquete Java.sql que está incluido en la versión

JDK 1.2 (conocido como la API JDBC 2.0) e incluye muchas nuevas características no
incluídas en el paquete Java.sql que forma parte de la versión JDK 1.1 ( referenciado
como la API JDBC 1.0).
 Con la API JDBC 2.0, se pueden realizar las siguientes cosas: Ir hacia adelante o
hacia atrás en una hoja de resultados o movernos a un fila específica. Hacer
actualizaciones de las tablas de la base datos utilizando métodos Java en lugar de
utilizar comandos SQL.

Enviar múltiples secuencias SQL a la base de datos como una unidad, o batch.
Utilizar los nuevos tipos de datos SQL3 como valores de columnas.

Qué incluye la API de JDBC 2.0

La API de JDBC 2.0 incluye todo lo de la API que es parte de Java 2 SDK,
Standard Edition, y también la API en la JDBC Standard Extension. La siguiente lista
define varios términos usados para referirse a la API de JDBC.

N API JDBC 2.0 – La API completa de JDBC, incluidas tanto en el paquete

java.sql (la API núcleo de JDBC 2.0) y el paquete javax.sql (la API de
JDBC Standard Extension). El paquete Java 2 SDK, Enterprise Edition, incluye
la API completa de JDBC 2.0.
N API del núcleo de JDBC 2.0 – El paquete java.sql: la API de JDBC que es
parte de Java 2 SDK, Standard Edition, la cual incluye la API de JDBC 1.0
además de la API de JDBC agregada en el paquete java.sql. Alguna de las
nuevas características en este paquete son los Resul Sets navegables,
actualizaciones por lote, y soporte para los nuevos tipo de datos de SQL3.
N La API de JDBC Standard Extension – El paquete javax.sql: este paquete
hace fácil construir aplicaciones del lado del servidor usando la plataforma Java
ofreciendo una arquitectura abierta que soporta pooling de conexiones y
transacciones distribuidas que abarcan múltiples servidores de bases de datos.
La API de DataSource juega una parte integral en las capacidades y también
trabaja con la Interfaz de Nombrado y Directorio de Java, (Java (tm) Naming
and Directory Interfaz (tm) o JNDI) para mejorar la portabilidad y hacer el
mantenimiento de código más fácil. El paquete javax.sql también provee la
API de RowSet, la cual hace fácil el manejo de conjuntos de datos de
virtualmente cualquier fuente de datos como de componentes JavaBeans.

Continuando con la política de mantener compatibilidad hacia atrás, las

aplicaciones escritas usando la API JDBC 1.0 continuarán corriendo en ambas Java 2
SDK, Standard Edition, y en Java 2 SDK, Enterprise Edition, tal cual siempre lo han
hecho. Habiendo sido bien diseñada desde el principio, la API JDBC 1.0 esencialmente
no ha cambiado. Las aplicaciones que usan aspectos agregados en la API de JDBC 2.0
deberán ser ejecutadas usando un driver que soporte estas características.

El paquete java.sql, que es parte de la API del núcleo, es incluido

automáticamente cuando se baja la Java 2 SDK, Standard Edition. Un vendedor de
drivers puede incluir el paquete java.sql con su producto, pero si el driver no incluye el
paquete, puede ser descargado del sitio en la red de JDBC en la dirección de URL:
http://java.sun.com/products/jdbc

También es posible el obtener el paquete javax.sql, descargando el Java 2

SDK Enterprise Edition¸ el cual incluye tanto el paquete Java.sql como el paquete
javax.sql. Los programadores que no estén programando componentes Enterprise
JavaBeans (EJB) o código de servidores, probablemente quieran descargar el Java 2
SDK, Standard Edition¸ en vez del Java 2 SDK, Enterprise Edition¸ para limitar la
cantidad de espacio de disco usada.

¿ Qué es pooling de conexiones ?

Originalmente, JDBC 1.0 definía las API’s de JAVA para acceso a bases de
datos relacionales. El modelo del manejador de conexiones, especifica cómo es
accedida la información a través de las APIs de JDBC 1.0. Con la introducción de
JDBC 2.0, las APIs fueron separadas en dos partes:

La API del núcleo de JDBC 2.0

Esta contiene mejoras evolucionadas, pero se ha mantenido pequeña y enfocada
como la API de JDBC 1.0 para promover el fácil uso de la misma. El código escrito par
la API de 1.0 continúa trabajando para la API de 2.0. Las clases de la API 2.0 siguen
estando en el paquete java.sql

El paquete opcional de la API JDBC 2.0

Este soporta la integración con estándares adicionales de Java. Incluyendo JNDI
(Java Naming and Directory Interface), JTA (Java Transaction API) y EJB (Enterprise
JavaBeans)

El pooling de conexión es el mantenimiento de un grupo de conexiones a bases

de datos para reuso de aplicaciones en servidores de aplicaciones y es parte del paquete
opcional de la API JDBC 2.0. Otra parte del paquete opcional de la API provee el uso
de JNDI y objetos DataSource en vez de objetos DriverManager de JDBC 1.0 para
acceder a los datos relacionales.

Beneficios del pooling de conexiones

Cada vez que un recurso intenta acceder a la base de datos, se debe conectar a
dicha base. Una conexión de base de datos incurre en un gasto; requiere recursos para
crear la conexión, mantenerla, y luego liberarla cuando ya no sea necesaria. El consumo
es particularmente alto para aplicaciones basadas en Web, debido a que los usuarios de
estas aplicaciones se conectan y se desconectan mas a menudo. Adicionalmente, las
interacciones con el usuario típicamente son cortas debido a la naturaleza dinámica de
los usuarios de Internet. A menudo, se gasta mas esfuerzo en conectar y desconectar que
el que se gasta durante las interacciones en si mismas. Además, debido a que los
pedidos de Internet pueden arribar virtualmente desde cualquier lado, los volúmenes
solicitados pueden ser grandes y difíciles de predecir.

Para solucionar éste problema, se permite a los administradores establecer un

“pool” de conexiones de bases de datos que pueden ser compartidas por aplicaciones en
un servidor de aplicaciones. El pooling de conexiones esparce la carga a lo largo de las
peticiones de los usuarios, conservando los recursos para futuros pedidos.

El pooling de conexiones puede mejorar el tiempo de respuesta de cualquier

aplicación que requiera conexiones, especialmente las aplicaciones basadas en Web.
Cuando un usuario realiza una solicitud de un recurso a través de la Web, el recurso
accede a un DataSource. La mayoría de las solicitudes no incurren en el gasto de crear
una nueva conexión debido a que el DataSource puede localizar y utilizar una conexión
existente de todas las conexiones disponibles. Cuando la conexión es satisfecha y la
respuesta es enviada al usuario, el recurso retorna la conexión al conjunto de conexiones
para su reutilización. De nuevo, se evita el gasto de desconectarse. Cada pedido de un
usuario incurre en una fracción del costo de la conexión o desconexión. Luego de que
los recursos iniciales son usados para producir las conexiones en el pooling, el costo
adicional es insignificante debido a que las conexiones existentes son reutilizadas.

Pautas para escribir un driver JDBC

A continuación se describe superficialmente los requerimientos mínimos que un
driver debe implementar para cumplir con la API JDBC.

El objetivo buscado es generar una API estándar que funcione uniformemente a

través de todas las bases de datos. Por esto se impone a los drivers una serie de
requerimientos pero, debido a las inevitables diferencias entre las bases de datos (por
ejemplo, soporte de diferentes características SQL o semánticas diferentes para las
mismas operaciones), se permiten algunas variantes en situaciones particulares.

A continuación se esbozan los requerimientos y las variantes permitidas, se

solucionan algunos problemas de implementación, y se listan las responsabilidades de
seguridad de los drivers.

Requerimientos para todos los drivers

Pese a que los requerimientos descritos a continuación se aplican a las
implementaciones estándar de un driver JDBC, en general, un driver no está obligado a
soportar una característica que su DBMS no soporta.

Implementar métodos en las interfaces

Deben implementarse todos los métodos en las interfaces contenidas en la API
JDBC 1.0 de forma de soportar al menos ANSI SQL-92 Entry Level. Como ya se
mencionó no se le exige a los drivers ir más allá de este nivel si el DBMS no lo permite.
En los casos de métodos que implementan características no soportadas por el DBMS
deben programarse lanzando una SQLException.

Las interfaces de metadatos (DatabaseMetaData, ResultSetMetaData) deben ser

completamente implementadas. En caso de que el proveedor del driver implemente de
la interfaz javax.sql.RowSet también debe implementarse interfaz
javax.sql.RowSetMetaData.

Los drivers JDBC que soportan transacciones distribuidas implementan las

interfaces XAConnection y XADataSource.

Interfases que siempre deben ser completamente java.sql.Driver

implementadas java.sql.DatabaseMetaData
java.sql.ResultSetMetaData
Interfaces deben ser implementadas, con java.sql.CallableStatement
métodos opcionales si la implementación de los java.sql.Connection
mismos depende de una característica que el java.sql.PreparedStatement
DBMS no suporta java.sql.ResultSet
java.sql.Statement
Interfaces opcionales (pueden omitirse si un java.sql.Array
DBMS no puede soportarlas)
Clases y excepciones
implementadas en la API JDBC 2.1
java.sql.Blob
javax.sql.ConnectionEventListener
javax.sql.ConnectionPoolDataSource
java.sql.Clob
javax.sql.DataSource
javax.sql.PooledConnection
java.sql.Ref
java.sql.SQLData
java.sql.SQLInput
java.sql.SQLOutput
java.sql.Struct
javax.sql.XAConnection
javax.sql.XADataSource
completamente java.sql.BatchUpdateException
javax.sql.ConnectionEvent
java.sql.DataTruncation
java.sql.Date
java.sql.DriverManager
java.sql.DriverPropertyInfo
java.sql.SQLException
java.sql.SQLWarning
java.sql.Time
java.sql.Timestamp
java.sql.Types

Implementar un inicializador estático

Todo driver debe tener inicializador estático (static initializer), que haga lo
siguiente al cargarse:

1. Crear un instancia de sí mismo

2. Registrar la instancia recién creada, invocando el método
DriverManager.registerDriver

Esto permite la carga y registro de drivers con el DriverManager invocando el

método Class.forName con el nombre de la clase Driver como argumento.

Los drivers cargados vía la API DataSource no se registran automáticamente con

el DriverManager. Las clases DriverManager y DriverPropertyInfo así como la interfaz
Driver entrarán en desuso en el futuro.

Soportar extensiones al SQL-92 Entry Level

Algunas características que van más allá del SQL-92 Entry Level son
ampliamente soportadas por los DBMS y es deseable incluirlas como una parte de la
definición de cumplimiento JDBC. De esta forma las aplicaciones podrán depender de
la portabilidad de estas características.

En cambio el SQL-92 Transitional Level (el siguiente nivel de cumplimiento

SQL definido por ANSI) no es ampliamente soportado. Incluso cuando sus semánticas
son soportadas, la sintaxis frecuentemente es distinta entre los diferentes DBMSs. Por
esto, JDBC define dos clases de extensiones al SQL-92 Entry Level que pueden ser
soportadas por un driver JDBC.

Sintaxis y semántica del Selective Actualmente la única característica a este

Transitional Level nivel que es requerida para compatibilidad
es DROP TABLE.
Sintaxis de escape que soporta la Un driver debería examinar y traducir esta
semántica del Selective Transitional Level. sintaxis de escape en sintaxis específica del
DBMS.

Soportar funciones escalares

JDBC soporta funciones numéricas, de strings, de tiempo, de fecha, de sistema,
y de conversión sobre valores escalares. Si se desea, la especificación del Open Group
CLI provee más información sobre la semántica de las funciones escalares.

Si un DBMS soporta una función escalar, el driver también deberá soportarla.

Debido a que las funciones escalares son soportadas por diferentes DBMSs con sintaxis
apenas diferentes, es responsabilidad del driver mapearlas a la sintaxis apropiada o
implementar directamente las funciones en su código.

Un usuario debería ser capaz de encontrar cuales funciones son soportadas

invocando métodos de metadatos (por ejemplo,
DatabaseMetaData.getNumericFunctions o DatabaseMetaData.getStringFunctions)
Funciones numéricas
Funciones de strings
Funciones de tiempo y fecha
Funciones de sistema
Funciones de conversión
ABS(number), ACOS(float),
ASIN(float), ATAN(float),
ATAN2(float1, float2),
CEILING(number), COS(float),
COT(float), DEGREES(number),
EXP(float), FLOOR(number),
LOG(float), LOG10(float),
MOD(integer1, integer2), PI(),
POWER(number, power),
RADIANS(number), RAND(integer),
ROUND(number, places),
SIGN(number), SIN(float),
SQRT(float), TAN(float),
TRUNCATE(number, places)
ABS(number), ACOS(float),
ASIN(float), ATAN(float),
ATAN2(float1, float2),
CEILING(number), COS(float),
COT(float), DEGREES(number),
EXP(float), FLOOR(number),
LOG(float), LOG10(float),
MOD(integer1, integer2), PI(),
POWER(number, power),
RADIANS(number), RAND(integer),
ROUND(number, places),
SIGN(number), SIN(float),
SQRT(float), TAN(float),
TRUNCATE(number, places)
ASCII(string), CHAR(code),
CONCAT(string1, string2),
DIFFERENCE(string1, string2),
INSERT(string1, start, length,
string2), LCASE(string),
LEFT(string, count),
LENGTH(string), LOCATE(string1,
string2[, start]), LTRIM(string),
REPEAT(string, count),
REPLACE(string1, string2,
string3), RIGHT(string, count),
RTRIM(string), SOUNDEX(string),
SPACE(count), SUBSTRING(string,
start, length), UCASE(string)
CURDATE(), CURTIME(),
DAYNAME(date), DAYOFMONTH(date),
DAYOFWEEK(date), DAYOFYEAR(date),
HOUR(time), MINUTE(time),
MONTH(date), MONTHNAME(date),
NOW(), QUARTER(date),
SECOND(time),
TIMESTAMPADD(interval, count,
timestamp),
TIMESTAMPDIFF(interval,
timestamp1, timestamp2),
WEEK(date), YEAR(date)
DATABASE(), IFNULL(expression,
value), USER()
CONVERT(value, SQLtype)
Proveer bloqueo para actualizaciones y eliminaciones posicionadas
No todos los DBMSs soportan las actualizaciones y eliminaciones posicionadas.
Una aplicación puede usar los métodos JDBC
DatabaseMetaData.supportsPositionedUpdate y
DatabaseMetaData.supportsPositionedDelete para determinar si una conexión en
particular las soporta. Cuando son soportadas las actualizaciones y eliminaciones
posicionadas (por ejemplo, sentencias del tipo SELECT FOR UPDATE), el driver debe
asegurar que las filas seleccionadas son adecuadamente bloqueadas de manera de que
no ocasionen anomalías de actualización u otros problemas de concurrencia.

Soportar Multithreading
Todas las operaciones sobre los objetos java.sql y javax.sql requieren ser seguras
en contextos de multihilos. Deben ser capaces de lidiar correctamente con la existencia
simultanea de varios hilos (threads) invocando el mismo objeto. Aún cuando se espere
que en la práctica la mayoría de los objetos JDBC serán accedidos desde un solo hilo, es
necesario el soporte para multihilos.

Algunos drivers pueden permitir mayor concurrencia que otros, pero los
desarrolladores deberían asumir una ejecución completamente concurrente. Si el driver
requiere alguna forma de sincronización, entonces él debe proveerla.

Lanzar excepciones en presencia de parámetros de entrada truncados

Si los parámetros de entrada son truncados, una excepción (DataTruncation
exception) deberá ser lanzada.

Usar comportamientos por defecto para los tipos de datos SQL3

Un driver escrito para un DBMS que soporta los tipos de datos SQL3, debe
implementar los comportamientos por defecto para los tipos de datos SQL3. La API
núcleo JDBC 2.1 especifica los comportamientos por defecto para los tipos de datos
SQL3 en dos áreas generales: (1) Su tiempo de vida y (2) si son implementados usando
localizadores (locators), o sea si se materializan sus datos en el cliente o no.

Variantes permitidas
Debido a las variaciones ya mencionadas entre los distintos DBMS, tanto en las
funcionalidades como en la sintaxis, se permite cierta variación en las implementaciones
de drivers. El SQL usado por una base de datos puede diferir del usado por otras bases
de datos. Por ejemplo, diferentes bases de datos ofrecen diferente soporte para los outer
joins. También puede variar la sintaxis para algunas de las características de SQL.

La interfaz java.sql.DatabaseMetaData ofrece un conjunto de métodos con los

cuales un usuario puede determinar exactamente que características SQL son soportadas
por una base de datos en particular. Es responsabilidad de quien escribe el driver
asegurarse de que el método DatabaseMetaData retorne información precisa acerca de
que soporta el DBMS y que no.
Cuando una funcionalidad no es soportada
Algunas características introducidas en la API núcleo JDBC 2.1 son opcionales
en drivers escritos para DBMSs que no las soportan. En estos casos los métodos que
soportan la característica pueden lanzar una SQLException. A continuación se listan la
características opcionales junto con los métodos DatabaseMetaData que indican si el
DBMS y el driver las soportan.

Método Característica opcional

DatabaseMetaData.supportsResultSetType Result sets navegables
DatabaseMetaData.supportsResultSetConcurrency Result sets actualizables
DatabaseMetaData.supportsBatchUpdates Actualizaciones batch
DatabaseMetaData.getTypeInfo Tipos de datos SQL3
Almacenamiento y obtención de
objetos Java

Además DatabaseMetaData.getUDTs retonará las descripciones de las UDTs

definidas en un esquema dado y DatabaseMetaData.getTypeInfo las descripciones de
los tipos de datos disponibles dentro del DBMS.

Variación en propiedades fundamentales

También se permite variación en algunas propiedades fundamentales, como los
niveles de aislamiento de transacciones. Invocando los métodos de la interfaz
DatabaseMetaData pueden obtenerse las propiedades por defecto de la base de datos
actual y el rango de propiedades que soporta.

Agregando funcionalidad
Los vendedores de bases de datos que quieren exponer funcionalidades
adicionales que son soportadas por sus bases de datos pueden crear subclases de las
clases JDBC existentes y ofrecer métodos adicionales en las nuevas subclases.

Responsabilidades de seguridad de los drivers

Debido a que los drivers JDBC pueden ser usados en diferentes situaciones, es
importante que los escritores de drivers sigan ciertas reglas de seguridad simples para
prevenir que Applets hagan conexiones ilegales a la base de datos. Estas reglas no son
necesarias si un driver es descargado como un Applet, debido a que el manejador
estándar de seguridad se encargará de esto.

Las reglas mencionadas se aplican al momento en que un conexión es abierta, ya

que este es el momento en el que el driver y la máquina virtual deberían verificar que el
invocador es realmente alguien que tiene permitido conectarse a la base de datos. Luego
no deben hacerse verificaciones adicionales. Sólo los drivers de código nativo necesitan
verificar el acceso a la base de datos antes de generar la conexión. Los drivers Java
puros pueden confiar en el manejador de seguridad.

Verificar conexiones TCP compartidas

Si un driver JDBC intenta abrir una conexión TCP, una vez abierta deberá ser
verificada por el manejador de seguridad Java (Java security manager). El manejador de
seguridad verificará si hay un Applet en la pila de invocaciones actual y si la hay,
restringirá la apertura al conjunto de máquinas que la Applet esta autorizada a invocar.
Como ya se mencionó, de esta manera, un driver JDBC puede dejar la verificación a la
hora de la apertura de conexiones TCP a la Máquina Virtual de Java (Java Virtual
Machine).

En el caso de que un driver JDBC quiere compartir una única conexión TCP
entre diferentes conexiones a bases de datos, es éste el que tiene la responsabilidad de la
verificación de los accesos a bases de datos usando esa conexión. Por lo tanto, antes de
permitirse la reutilización una conexión TCP existente, el driver JDBC deberá verificar
con el manejador de seguridad que quien hace la invocación actual tiene permitido
conectarse a esa máquina. En los casos en que no esté permitida la conexión el método
SecurityManager.checkConnect lanzará una java.lang.SecurityException.

Verificar todos los accesos locales a archivos

Si un driver JDBC necesita acceder a cualquier dato local en la máquina actual,
entonces debe asegurar que quien hace la invocación tiene permitido abrir los archivos.
El método Security.checkRead lanzará una java.lang.SecurityException en el caso de
que no esté permitido el acceso.

Como con las conexiones TCP, el driver debe sólo ocuparse de los problemas de
seguridad si los archivos son compartidos entre múltiples hilos invocadores y el driver
está siendo como código confiable.

Asumir lo peor
Algunos drivers pueden usar métodos nativos para interconectar con librerías de
bajo nivel de la base de datos. En estos casos, puede ser difícil de determinar cuales
archivos o conexiones de red serán abiertas por las librerías de más bajo nivel. En estas
circunstancias el driver debe asumir el peor caso, en cuanto a seguridad, y negar todo el
acceso a bases de datos a Applets descargadas a menos de que el driver confíe
completamente en que el futuro acceso será inofensivo.

Lanzar una SQLException en caso de excepciones

Como se ha dicho, si un DBMS no soporta cierta funcionalidad, un método para
soportarla debería implementarse de manera de que lance una SQLException. Pero hay
casos en que una Java RunTimeException y una SQLException pueden superponerse.
Es estos casos, es recomendado que la SQLException sea lanzada porque esto da a
JDBC control más consistente sobre los errores.

Implementaciones sugeridas

Búsqueda anticipada de filas

JDBC ofrece métodos para la obtención de columnas individuales dentro de filas
individuales, un campo por vez. Actualmente no se ofrece una forma de hacer
búsquedas anticipadas en porciones más grandes. Pese a esto, se recomienda que los
drivers normalmente realicen búsquedas anticipadas de filas en porciones adecuadas,
para reducir el número de interacciones con la base de datos.
 Los nuevos métodos en la API núcleo JDBC 2.1 establecen el número de filas a
ser buscados, pero un driver puede ignorar esto, especialmente si este parámetro entra
en conflicto con optimizaciones hechas por DBMS y/o el driver. Análogamente, los
drivers pueden también ignorar la dirección de búsqueda.

Ofrecer métodos "finalize” para Applets

Siempre se aconseja a los usuarios (programadores) invocar el método close
sobre objetos Statement y Connection cuando ya no serán utilizados, pero es frecuente
los usuarios se olviden de esto. Por eso, los drivers JDBC deben ofrecer métodos
“finalize” para ocuparse de los casos en que ocurre esta omisión.

Evitar estados dependientes de la implementación

Algunas bases de datos tienen restricciones que resultan en dependencias ocultas
entre objetos JDBC. Los estados dependientes de la implementación dificultan la
portabilidad, y las implementaciones que los contienen nos son totalmente compatibles.
Un ejemplo de esto sería un caso en que dos objetos Statement se abren, pero cuando el
objeto ResultSet de uno está en uso no se puede ejecutar el otro objeto Statement.

Ventajas / Desventajas
Similitudes y diferencias con ODBC
Sun Microsystems ha logrado con Java toda una plataforma empresarial y cuenta
con JDBC para el acceso a bases de datos compatibles con ODBC, es decir, se manipula
la información mediante objetos. JDBC hace para Java lo que ODBC para C (o Visual
Basic). A diferencia de ODBC, no se indica que nivel de SQL usar (ODBC tiene varios
niveles), sino que simplemente se pasan las cláusulas SQL al driver específico de la
base de datos. Es un complemento a la plataforma empresarial Java para manejar bases
de datos relacionales o que entienden SQL.

JDBC al igual que ODBC y ADO proporciona una abstracción al programador

que le permite olvidarse de la conexión con la base de datos y concentrarse en el
desarrollo de la aplicación y SQL.
API JDBC Vs ODBC
Antes del desarrollo de la API de JDBC, la API ODBC de Microsoft (Open
DataBase Connectivity) era la interfaz de programación más usada para acceder a bases
de datos relacionales. OBDC ofrece la habilidad de conectarse a casi todas las bases de
datos en casi todas las plataformas. Entonces surge una pregunta ¿Por qué no sólo usar
ODBC desde Java? La respuesta es que se puede usar ODBC desde Java, pero esto se
hace de una mejor manera con la ayuda de la API de JDBC en la forma de puente
JDBC-ODBC. Por lo que la pregunta a responder ahora es ¿Por qué es necesaria de API
de JDBC ?

Existen varias respuestas a ésta pregunta:

1- ODBC no es apropiado para el uso directo desde Java porque utiliza una interfaz
de C. Las llamadas desde Java a código nativo en C tienen varias desventajas en
seguridad, implementación, robustez y portabilidad automática de las
aplicaciones.
2- Una traducción literal de la API C de ODBC a una API de Java no sería
deseable. Por ejemplo, Java no maneja punteros y ODBC los utiliza en gran
medida, incluyendo el puntero a void genérico. Se puede pensar de JDBC como
un ODBC traducido a una interfaz de alto nivel orientada a objetos, lo que es
natural para programadores en Java.
3- ODBC es difícil de aprender. Mezcla características simples y complejas a la
vez, y tiene opciones complejas incluso para consultas simples. La API de
JDBC, por otro lado, fue designada para mantener simple lo que es simple
mientras permite capacidades más avanzadas donde se las requiere. Además
también es más fácil de usar simplemente porque es una API de Java, lo que
significa que el programador no necesita preocuparse del manejo de memoria o
alineamiento de bytes por ejemplo.
4- Cuando el driver JDBC es escrito completamente en Java, su código es
automáticamente instalable, portable y seguro en todas las plataformas Java
desde computadoras en la red hasta mainframes.
 En resumen, la API de JDBC es una interfaz natural de Java por trabajar con
SQL. La API JDBC mantiene algunas de las características básicas de diseño de
ODBC; en efecto, ambas interfaces están basadas en un nivel de interfaz con
instrucciones SQL X/Open. La gran diferencia está en que la API JDBC reafirma el
estilo y virtudes de Java y va más allá, enviando sentencias SQL a un RDBMS.

Microsoft ha introducido nuevas API mas allá de ODBC, como OLE (Object
Linking and Embedding) , ADO (ActiveX Data Objects), y RDS (Remote Data
Service). De alguna manera, estas APIs van en la misma dirección que JDBC; por
ejemplo, OLE y ADO son interfaces orientadas a objetos que pueden ser usadas para
ejecutar sentencias SQL. Sin embargo, OLE es una interfaz de bajo nivel designada para
herramientas más que para desarrolladores. ADO es mas nueva y se parece mas a
JDBC, pero no está desarrollada en un ambiente Java puro. Tampoco RDS esta escrito
en Java, y no es portable. Más recientemente, Microsoft ha introducido UDA (Universal
Data Access) que cubre lo que es OLE DB, ADO, RDS y ODBC. La API 2.0 de JDBC
cubre toda la funcionalidad importante de UDA y posee además otras características que
no se encuentran en UDA, como por ejemplo soporte para SQL3.

Comparación del uso de JDBC en un modelo de 2 capas y en uno de 3

capas:
En cuanto al esfuerzo de programación, el modelo de dos capas es más fácil de
comprender y mantener que el modelo de tres capas. Todo el código es ejecutado en el
cliente y no se necesita de programas adicionales para correr en alguna de las máquinas.
Además, los cambios afectan sólo al programa que se ejecuta en el cliente.

En cuanto a escalabilidad y realización, a la hora de desarrollar una aplicación

de calidad comercial, se debe estar consciente de los aspectos de performance y
escalabilidad de la aplicación a construir. Teniendo esto en cuenta, puede apreciarse que
debido a la relación directa uno a uno existente entre el cliente y el manejador de la base
de datos, para el caso del modelo de dos capas, una solución en éste sentido
seguramente tenga problemas de escalabilidad. Por ejemplo, una aplicación que maneja
miles de conexiones de clientes en forma concurrente a una base de datos representará
seguramente una enorme carga tanto para la red como para el DBMS. Por lo tanto, en
éste sentido sería deseable una solución multi-capas que use un servidor para mediar
entre los clientes y el DBMS. Además, un driver desarrollado para uso en una
arquitectura de dos capas puede tener otros problemas como por ejemplo el hecho de no
poder tomar ventaja de las capacidades multi-hilos de Java en caso de que las
bibliotecas del cliente no sean multihilos, y de esa manera perder performance, por
decirlo de alguna manera. Al usar un driver con un servidor intermedio que sea robusto
y se maneje en un ambiente puro de java, el cliente puede operar como una aplicación
multihilo y permitir al servidor intermedio el manejo de la sincronización y la espera de
los resultados de la comunicación con una biblioteca de cliente de un solo hilo.

Otro problema que presenta la arquitectura en dos capas es que muchos drivers
de JDBC contienen código nativo, dependiente del sistema, que es rechazado por los
navegadores web debido a temas de seguridad, por lo que es necesario utilizar drivers
implementados en java. Java se encuentra bien posicionado para la implementación de
soluciones en 3 capas ya que facilita la comunicación vía sockets entre el servidor y el
cliente y soporta la programación multi-hilos necesaria para el acceso multi-usuario.
 En cuanto a economía de transmisión y seguridad de los datos, en la arquitectura
de dos capas, cada aplicación del cliente debe comprender la aplicación JDBC, es decir,
tiene visibilidad sobre la misma. Éste código adicional es transmitido a los clientes,
causando una necesidad de procesamiento extra de este lado. Por otro lado, la aplicación
cliente se conecta directamente con el servidor de base de datos, necesitando por lo
tanto un usuario y contraseña no encriptados para el acceso, lo cual dificulta la creación
de una buena política de seguridad. En el modelo de 3 capas, la aplicación cliente es
más pequeña, siendo su principal tarea la de recuperar datos y mostrarlos en pantalla
(cliente más fino). Respecto al otro aspecto mencionado en el párrafo, en la arquitectura
de 3 capas, la capa intermedia puede ocultar al cliente cualquier tipo de información
referente al servidor de la base de datos, siendo ésta capa intermedia la que sabe como
encontrar y manipular los datos. El servidor intermedio puede proveer a los clientes de
un pool de conexiones al DBMS para evitar la necesidad de tener un usuario y
contraseña para la base de datos.

Alternativas a JDBC
Sin JDBC, sólo existen soluciones propietarias dispares de acceso a bases de
datos. Dichas soluciones propietarias obligan al diseñador a construir una capa de
abstracción por encima para crear código independiente de la base de datos. Sólo luego
que ésta capa de abstracción está completa es que el desarrollador se mueve realmente a
escribir la aplicación. Además, la experiencia que uno tiene con esa capa de abstracción
no se traduce inmediatamente a otros proyectos u otras personas o empresas que casi
están usando ciertamente sus propias capas de abstracción para proporcionar el acceso a
una variedad de motores de bases de datos. Claro, la especificación de ODBC existe
para mantener esta capa de abstracción universal para los lenguajes como C y C++ así
como para herramientas de desarrollo populares como Delphi, PowerBuilder, y
VisualBasic. Desgraciadamente, ODBC no disfruta de la independencia de plataforma
que posee Java. Usando el diseño de interfaz de JDBC, la aplicación servidora puede
elegir, en tiempo de ejecución, la base de datos según que tipo de cliente está conectado.

Limitaciones de JDBC
Una de las desventajas es que Java es un poco lento. Sin embargo, el idioma
promete estar con nosotros como una herramienta básica durante muchos años. JDBC es
sumamente útil para el desarrollo de aplicaciones del lado del servidor en que se puede
controlar el ambiente en un buen grado.

Ventajas de la tecnología JDBC

A continuación se presentan algunas de las ventajas que presenta JDBC:

Influencia de datos de empresa existentes

Con la tecnología JDBC, los negocios no se cierran en cualquier arquitectura
propietaria y pueden continuar usando sus bases de datos e información de acceso
fácilmente, aun cuando ésta es guardada en diferentes sistemas de gerenciamiento de
bases de datos.
Desarrollo simplificado de la empresa
La combinación de la API de Java y la API de JDBC hace del desarrollo de
aplicaciones algo fácil y barato. JDBC oculta la complejidad de muchas tareas de
accesos a datos, mientras hace la mayoría del trabajo pesado en forma transparente para
el programador. La API de JDBC es simple de aprender y barata de mantener.

Cero configuración para redes de computadoras

Con la API de JDBC, no se requiere ninguna configuración del lado del cliente.
Con un driver escrito en Java, toda la información que se necesita para hacer una
conexión está completamente definida por el URL de JDBC o por un objeto registrado
por medio de JNDI. Cero configuración del lado del cliente permite la centralización del
mantenimiento del software.

Cero Instalación
Un driver basado en JDBC no necesita de una instalación especial; es bajado
automáticamente como parte de la aplicación que realiza las llamadas JDBC.

Impulso en la industria
Líderes en bases de datos, middleware y vendedores han estado construyendo el
soporte para la tecnología JDBC en muchos productos. Esto asegura que clientes
puedan construir aplicaciones portables de Java mientras escogen, de una amplia gama
de productos competitivos, la mejor solución que se adecue a sus necesidades.

Conexión a la base de datos identificada por una URL

La tecnología JDBC se aprovecha de las ventajas de las URLs estándar de
Internet para identificar las conexiones a las bases de datos. La API de JDBC incluye
una buena manera de identificar y conectar a una fuente de datos, usando un objeto
DataSource, esto hace al código aún más portable y más fácil mantener.

Además de esta ventaja importante, los objetos DataSource pueden proporcionar

transacciones distribuidas y connection pooling, esenciales para la informática de base
de datos de empresa. Esta funcionalidad se proporciona transparentemente al
programador.

Conclusiones
Las grandes compañías desarrolladoras de bases de datos apoyaron casi desde un
principio a JDBC como tecnología de conexión a sus DBMS. Esto, sumado al auge de
Java, presionó al resto de las compañías (que no querían verse marginadas en un
mercado creciente y muy competitivo) a seguir el mismo camino, y ofrecer soporte
JDBC. Lo anterior derivó en la abundancia de drivers, middlewares y aplicaciones que
utilizan JDBC.

Entre las virtudes y desventajas de JDBC, se pueden listar:

N Facilita la programación de aplicaciones.

N Extiende la portabilidad multiplataforma de Java al acceso a fuentes de datos.
N Permite abstraerse de ciertas operaciones de bajo nivel como por ejemplo
establecer la conexión con el DBMS.
N Soluciona el problema de manejar varias fuentes de datos heterogéneas a la vez.
N Se encuentra disponible para la mayoría de los manejadores.
N Para los DBMS que no tengan driver JDBC pero si ODBC permite la conexión a
las mismas utilizando el puente JDBC-ODBC.
N Tiene ciertas limitaciones de performance debido a que utiliza Java el cual es
interpretado.
N No precompila las sentencias SQL que se mandan al manejador lo que podría
derivar en errores.
N Utilizándolo por si solo, el mapeo de objetos a datos relacionales tiene sus
dificultades.

La mayoría de las desventajas antes mencionadas, son tolerables o algunas

pueden resolverse utilizando otras API’s que se construyen a partir de la base de JDBC.
Además existe abundante información técnica acerca de JDBC lo que hace sus
problemas subsanables más fácilmente.

JDBC aparenta un cierto dinamismo que va acompasando los cambios de la

tecnología actual, desarrollándose además un conjunto de herramientas a partir de
JDBC, que permiten trabajar a mayores niveles de abstracción (SQLJ, Java Blend, etc)
facilitando la tarea de programación.

Java, junto con JDBC, constituyen una herramienta de uso recomendable para
desarrollar aplicaciones orientadas a objetos con acceso a bases de datos. No obstante,
debe evaluarse cuidadosamente las características del medio donde se pondrá en
producción, los diferentes requerimientos de performance, seguridad y robustez para
determinar cual es la variante (configuraciones de arquitectura) de ésta herramienta que
se ajuste más a los requerimientos de la aplicación.
Referencias
Tutorial JDBC
http://java.programacion.net/jdbc/

Sybase jConnect for JDBC Technical Whitepaper - Technical whitepaper for jConnect
http://www.sybase.com/
http://www.sybase.com/detail/1,6904,1009766,00.html

Introduction to Databases for the Web: Pt 4 - By Selena Sol - November 23, 1998
http://www.databasejournal.com/sqletc/article.php/26861_1431601_1

Database Programming with JDBC and Java -By George Reese - 1st Edition June 1997
1-56592-270-0, Order Number: 2700
Chapter 4: http://www.oreilly.com/catalog/javadata/chapter/ch04.html

Getting Started with JDBC API

http://java.sun.com/products/jdk/1.4/docs/guide/jdbc/getstart/GettingStartedTOC.fm.ht
ml

JDBC Data Access API – FEATURTES

http://java.sun.com/products/jdbc/features.html

The JDBC API Universal Data Access for the Enterprise

http://java.sun.com/products/jdbc/overview.html

Bases de Datos con Java (4ta parte)

http://www.cic.ipn.mx/ute/ogonzalez/Cursos/javabas/bdedjbcuatro.htm

JDBC Paper – Two-tier and three-tier architectures

http://rcswww.urz.tu-dresden.de/~nuehren/jdbc/4_2.htm

Replicación de bases de datos en Internet - Ing. Cayetano Pérez Martínez

http://148.204.45.136:9000/labsiybd/proyectos/TESIS/cayetano/DTeMae.htm

For Driver Writers – Sun

http://java.sun.com/products/jdbc/driverdevs.html