La mayor parte del software no trivial tiene que acceder a repositorios de información, lo que en el panorama actual se traduce en acceso a ficheros POSIX, ficheros de registros, bases de datos jerárquicas y relacionales, y sistemas persistentes (bases de objetos, serializaciones, etc.). Pese a que los ficheros POSIX y de registros representan más del 70% del actual modelo de almacenamiento de datos, nos centraremos, por su prevalencia en los modernos desarrollos de software, en las bases de datos relacionales y en su lenguaje SQL (Structured Query Language), aunque no olvidaremos revisar someramente sus extensiones orientadas-a-objetos [1]. Podríamos decir, así, que uno de los puntos de inflexión en la mayoría de aplicaciones actuales es el acceso a bases de datos relacionales vía SQL. Las opciones se limitan a dos: el acceso mediante cualquier implementación de SQL X/Open CLI ( Call Level Interface ), un interfaz estándar definido por el SQL Access Group (SAG) para el acceso a datos remotos, o el uso de ESQL (Embedded SQL), estándar definido en ISO SQL-92 para la inserción de frases SQL directamente en lenguajes de programación como COBOL, C, Pascal, etc. El problema con ESQL es que la base de datos que se pretende acceder debe conocerse en fase de compilación, y los precompiladores tienden a generar código cautivo para la misma (pues, por ejemplo, los requerimientos de binding son muy distintos para cada producto). De cualquier manera, distintas compañías están trabajando en la producción de ESQL para Java, así que nuestro interés se centrará en el acceso mediante CLI y derivados.

MICROSOFT ODBC

ODBC ( Open Database Connectivity ) es un API procedural, en lenguaje C, creado como extensión de SQL CLI. Inicialmente planteado como una necesaria pasarela de acceso a bases de datos relacionales desde Windows, la versión 1.0 del ODBC SDK presentaba serias carencias, incluida las relacionadas con la eficacia. Con el lanzamiento del ODBC SDK 2.0 en 1994 se subsanaron bastantes de estas deficiencias, a la vez que el API ODBC se extendió más allá de la plataforma Windows y se lanzaron los drivers de 32 bits, calificados en razón de su nivel de acceso, que puede ser básico, de nivel 1 o de nivel 2, en razón de las llamadas al API ODBC permitidas desde cada nivel (hasta un total de 61 en el nivel 2). Así que, teniendo en cuenta que el ODBC SDK 3.0, o su equivalente, está pronto a aparecer, ¿por qué JDBC? O sea, ¿cuáles son las razones para no usar lo que parece un estándar muy extendido?

• ODBC es una propiedad de Microsoft no sujeta a normalización y, por tanto, su evolución depende de influencias de mercado, presiones de comercialización y aspectos de direccionamiento estratégico de la compañía. Así, por ejemplo, ¿quién podría decir si el futuro de este interfaz se decantará por OLE/DB o más bien se ajustará a SQL3/CLI? Por ejemplo, dado que son las aplicaciones las que tienen que ajustarse al nivel de conformidad de los drivers que hayan de usar, la ambigüedad en ciertas clasificaciones de drivers y su posible cambio futuro podrían inutilizar una buena parte del código actual de acceso a bases de datos.
• ODBC es un API C, por lo que no observa las deseables características de seguridad que Java ya incorpora. Sólo esta característica ya trocaría necesaria la aparición de un nuevo API de acceso a bases de datos. Pero, ¿por qué no realizar una simple traducción literal del API de ODBC al nuevo JDBC? Pues porque la especificación ODBC, fuertemente ligada al lenguaje C y la mecánica de conversión de punteros, necesitaba, además, de una traducción orientada-a-objetos que encajara con la naturaleza de Java y de la computación moderna.
• Los drivers ODBC son excesivamente lentos comparados con los drivers nativos de acceso a bases de datos.
• Dado que ODBC conforma un API eminentemente estático y que los distintos motores comerciales de bases de datos ofrecen particulares e incompatibles extensiones al SQL nativo, trabajar simultáneamente contra distintas bases de datos, mediante el uso de distintos drivers ODBC, supondrá bien la codificación de bifurcaciones programáticas imposibles de mantener, bien la sujeción a un subconjunto mínimo operativo de SQL, que difícilmente se ajustará a las necesidades iniciales de las aplicaciones. En cambio los drivers JDBC no plantean restricciones para admitir cualquier cadena de caracteres, fiados de la naturaleza dinámica de Java y del excelente mecanismo de tratamiento de excepciones que incorpora el lenguaje.
• ODBC supone la instalación de ficheros binarios ODBC en las máquinas clientes, además de binarios de los clientes de las bases de datos pertinentes, lo que dificulta sobremanera su instalación, mantenimiento y gestión (o prácticamente las imposibilita, en el caso de Internet).

Claro que Microsoft no hace mucho que introdujo, además de OLE/DB, dos nuevos APIs de más alto nivel que ODBC para el acceso a BBDD: DAO (Data Access Objects) y RDO (Remote Data Objects). El problema es que, mientras que DAO se apoya en JET y tiene, por tanto, importantes problemas de eficacia (que pueden ser parcialmente mitigados mediante el uso de ODBC Direct), RDO supone, por otra parte, una extensión de los problemas notados en ODBC, manteniendo empero los relativos a la seguridad de acceso a múltiples bases de datos y al uso de Internet. Claro que estas tecnologías son perfectas para Intranets basadas en Wintel. De todas formas JDBC no supone un rechazo de ODBC, sino más bien su mejora gracias, sobre todo, a las posibilidades que proporciona la plataforma Java.

¿QUÉ ES JDBC?

JDBC [2] es un API Java para ejecutar frases SQL, basado, como ODBC, en X/Open SQL CLI , creado para posibilitar el acceso de los programadores a bases de datos locales y remotas mediante un interfaz común e independiente de la plataforma. La verdad es que JDBC se ha desarrollado con extraordinaria celeridad, teniendo en cuenta que la especificación inicial data del 08-03-96: al equipo de trabajo se le dio carta blanca para que crearan el mejor interfaz SQL posible para cualquier plataforma, y parece que lo han conseguido. El API JDBC está constituido por el siguiente conjunto de clases e interfaces Java, contenidas en el package "java.sql", que forman parte inseparable de la plataforma JDK 1.1.X (el código de tres niveles supone una versión de mantenimiento) y que se instalan localmente con la misma:

Tales clases posibilitan conexiones a Bases de Datos, representan frases SQL, definen conjuntos de resultados, controlan metadatos, etc. El uso de los métodos de estas clases nos permite, resumiendo, conectarnos con una base de datos, enviarle frases SQL y procesar los resultados. Pero vayamos a un ejemplo simple (no se preocupe el lector por la funcionalidad de las clases usadas, que más adelante detallaré suficientemente, sino más bien por captar la mecánica, por otro lado bastante simple, del uso de JDBC):

// Ante todo, la cualificación de acceso del espacio de nombres

import java.sql.*

// En primer lugar creamos un objeto de tipo Connection e indicamos

// al DriverManager que obtenga una conexión a la base de datos que

// hemos especificado como argumento, junto con la identificación y

// la contraseña apropiadas. El DriverManager intentará la conexión

// por orden con cada uno de los drivers que tenga registrados.

Connection miConexión = DriverManager.getConnection(

“jdbc:odbc:miBaseDeDatos”, "login", "contraseña" );

// En realidad deberíamos haber envuelto el código de conexión con

// un bloque try/catch, por si ésta no se hubiera

// podido establecer. Con todo, si la conexión hubiera generado

// algún aviso, podríamos mostrarlo en pantalla mediante

checkForWarning( con.getWarnings() );

// Ahora creamos un objeto Statement, que no es sino un contenedor

// para la ejecución de frases SQL, asociado a una conexión dada

Statement miFraseSQL = miConexion.createStatement();

// Seguidamente creamos una frase SQL asociada a nuestra conexión

String consulta = “SELECT Nombre, Ventas FROM Clientes”;

// y la ejecutamos, almacenando el resultado en un objeto de tipo

// ResultSet

ResultSet resultado = miFraseSQL.executeQuery( consulta );

// Por último, iteramos sobre la colección del resultado para

// procesar la información obtenida

while (resultado.next()) {

// Los métodos getString y getInt proporcionan un medio

// conveniente de transformar los tipos de datos SQL en

// tipos de datos Java.

String nombreCliente = resultado.getString(“Nombre”);

int ventas = resultado.getInt(“Ventas”);

// aquí procesamos la información (v.b., un listado)

}

URLs JDBC

En el ejemplo anterior apreciamos, además de la sencillez del código, que la localización de la base de datos se codifica mediante un esquema del tipo URL:

jdbc:<subprotocolo>:<nombreDeDominio>

de forma que, en nuestro caso, "odbc" es el subprotocolo de acceso a "miBaseDeDatos", que también podría haber incorporado el nombre del host, quedando, por ejemplo, como

jdbc:odbc://www.miSitio.com/miBaseDeDatos

Como subprotocolo también podría indicarse un servicio de nombres, lo que proporcionaría un nivel adicional de indirección, de forma que en la URL JDBC siguiente:

jdbc:miServicioDeNombres:otraBaseDeDatos

el subprotocolo convertiría el identificador "otraBaseDeDatos" en un nombre global necesario para establecer la conexión con la base de datos.

DRIVERS JDBC

Un driver JDBC es un conjunto de clases Java que implementan interfaces JDBC (que son como clases abstractas C++: colecciones de métodos abstractos, sin cuerpo). Los drivers JDBC no necesitan estar forzosamente codificados en Java, aunque esto posibilita su carga dinámica y el mantenimiento de todos los esquemas de seguridad. Existen, en fin, cuatro categorías distintas de drivers JDBC:

1. Drivers puentes JDBC-ODBC : Transforman las llamadas JDBC en llamadas equivalentes ODBC, lo que supone la existencia en la máquina cliente de binarios ODBC (el gestor de drivers, de Microsoft, y el driver ODBC para la base de datos específica) y, posiblemente, de código cliente específico de la base de datos a acceder, de forma que estos drivers resultan apropiados para redes corporativas (con departamentos dedicados al mantenimiento de máquinas clientes) o para servidores Java en arquitecturas 3-tier. Aunque ODBC también funciona sobre Mac y algunas plataformas UNIX, el driver puente de referencia, desarrollado conjuntamente por JavaSoft e InterSolv, sólo está disponible para las plataformas soportadas por Java: Solaris y Win32. Por supuesto se trata de la opción menos eficaz, pues simplemente se añade una capa más a la estructura de acceso existente mediante ODBC, pero puede resultar la solución idónea para integrar soluciones Java en "legacy systems". Por ejemplo, para acceder a DB2/400 via JDBC, podría usarse un puente JDBC-ODBC (de los varios existentes) más un driver ODBC en la parte cliente (Client Access viene con un driver ODBC incorporado), configurado para acceder al sistema de ficheros del AS/400.
   
2. Drivers para APIs nativos con Java-mix : Convierten las llamadas JDBC en llamadas al API cliente para Oracle, Sybase, Informix, DB2 y otras bases de datos. Usualmente requieren, como en el caso del puente JDBC-ODBC, la carga de determinados ficheros binarios en la parte cliente.
   
3. Drivers puros Java JDBC-Net : Traducen las llamadas JDBC a un protocolo de red independiente de las Bases de Datos, que a su vez será traducido a protocolos nativos (determinados en cada caso por el fabricante de la base de datos que pretende ser accedida) por otro servidor middleware, cuya función es conectar a sus clientes Java con diferentes bases de datos. Es el enfoque más flexible.
   
4. Drivers puros Java para protocolos nativos : Convierten las llamadas JDBC al protocolo de red usado directamente por las bases de datos, permitiendo, en Intranets, el acceso directo desde clientes a Bases de datos en servidores dados. Se trata, en definitiva, de un caso especial del driver JDBC-net en que la comunicación se establece directamente con el servidor de la base de datos mediante un protocolo usualmente propietario (por lo que serán precisamente los fabricantes de bases de datos los que habrán de proveer este tipo de drivers).

JDBC ha recibido un importante respaldo industrial, significado por la cantidad de drivers JDBC disponibles en este momento, aunque se espera una explosión comercial respecto de los drivers del tipo 4), pese a que lo deseable sería el uso de drivers del tipo 3). Por otra parte, Intersolv y JavaSoft están desarrollando una “suite” de validación y certificación de interoperabilidad para drivers JDBC que asegurará la estabilidad del mercado de éstos.

GESTOR DE DRIVERS JDBC

El gestor de drivers (DriverManager) representa la capa de JDBC dedicada a la gestión de los distintos drivers JDBC del sistema. En breve, el gestor de drivers establece una correspondencia entre una URL JDBC y un driver concreto. Naturalmente el gestor necesita saber qué drivers debe manejar y dónde están situados, por lo que surge la necesidad de que, para evitar problemas, sean los mismos drivers los que se registren automáticamente, de dos posibles formas:

• Mediante la invocación del método Class.forName , pasándole como parámetro el nombre cualificado (mediante la notación independiente formada por puntos) del driver dado:

Class.forName( "miDirectorio.drivers.miDriver");

• Por medio de la adición de distintos nombres de drivers separados por punto y comas a la propiedad "jdbc.drivers", haciendo uso del método java.lang.System.setProperty o, naturalmente, mediante su igual inserción en ficheros de inicialización. El problema con esta estrategia es que el DriverManager pueda haber leído ya, como de hecho hace al inicializarse, la propiedad "jdbc.drivers", de forma que cualquier adición no tendría efecto hasta que el gestor se iniciara de nuevo.

Con todo, ambos procedimientos requieren que se invoque al método DriverManager.registerDriver , pasándole como parámetro una instancia de la clase representativa del driver (se supone que tras el proceso de carga y las modificaciones antedichas, el driver creará una instancia de sí mismo y la usará aquí como parámetro).

¿CÓMO FUNCIONA JDBC?

Las llamadas JDBC (o sea, la invocación de métodos pertenecientes a clases del package "java.sql") se pasan a un gestor de drivers JDBC, el cual, a su vez, las pasará al driver JDBC concreto que pueda manejarlas.

Cuando una aplicación Java (o un applet, o un módulo) requiera del gestor de drivers JDBC una conexión con una base de datos determinada, el gestor examinará primero su lista de drivers registrados. Pero no "toda" la lista, sino únicamente la compuesta de los drivers validados (trusted drivers: estos son, los cargados en la inicialización del gestor) más los drivers que se hayan registrado después pero que procedan de la misma URL que el código invocador o que compartan el mismo cargador de clase (class loader). La razón es clara: se pretende evitar la vulneración del esquema de seguridad mediante la carga dinámica, desde otro punto de la red, de un driver en nuestra máquina para acceder a bases de datos situadas en lugares distintos del origen del mismo driver. Pero, ¿cómo conoce el gestor tal información para discriminar su lista? Pues porque cuando se produce el registro de un driver, el gestor conserva, entre otras cosas, la información del cargador de clase (class loader) correspondiente. Pero sigamos: el gestor de drivers "intenta" la conexión con cada uno de los drivers registrados, en el mismo orden de registro (los drivers detallados en la "Property" jdbc.drivers son cargados primero, por orden de aparición), y devolverá un objeto "Connection" asociado al primer driver que "entienda" la URL de conexión, de forma que a partir de ese momento se encaminarán por él las subsiguientes frases SQL.

APPLETS Y JDBC

El modelo de seguridad de los applets impide que desde un applet sin validar (untrusted applet -como lo son la mayoría de los que se ejecutan en un paginador Internet) se pueda realizar:

• El acceso general, y por supuesto mediante JDBC, a bases de datos situadas en URLs distintas de aquéllas de las que el applet mismo procede.
• La configuración de recursos locales como, por ejemplo, la información de la fuente de datos ODBC para usar el puente JDBC-ODBC.
• La descarga (downloading) de clases nativas: o sea, aquéllas cuyo nombre de package empiece con "java" (para evitar difíciles, aunque posibles, solapamientos de los esquemas de seguridad Java mediante la substitución dinámica del código de las clases del JDK local). Esta restricción afecta directamente a los paginadores que usan JDK 1.0.2 o anterior (y que constituyen la mayoría de los presentes en el mercado actual), pues JDBC es posterior a esta versión, de forma que las clases apropiadas (JDK 1.0.2 debe usar JDBC versión 1.21) no estarán instaladas localmente ni podrán ser descargadas de Internet por el applet. La única solución (la menos mala), y que precisamente es la que están siguiendo muchas compañías de desarrollo Java, es preparar los applets para el uso de los interfaces definidos en "java.sql", pero cambiando el nombre del package (por lo común a "jdbc.sql") que será puesto, tras su recompilación, en el servidor, junto con las clases de los drivers JDBC, para su descarga por el applet. La principal consecuencia es que, pese a que este enfoque también funcionaría en JDK 1.1, en este caso sería mucho más eficiente el uso de "java.sql" instalado localmente (en lugar de descargar "jdbc.sql" o similares, como "symjava.sql" en el caso de Symantec), por lo que las empresas deberían soportar simultáneamente dos drivers distintos. Claro que todo se solucionará cuando usuarios y empresas adopten JDK 1.1 de forma masiva.

Se dan, además, dos problemas adicionales de uso del puente JDBC-ODBC desde applets sin validar:

• Lo usual será que el necesario driver ODBC no pueda descargarse (ni configurarse, como vimos antes) de forma dinámica, ni por Internet ni en Intranets.
• El puente accede al interfaz de funciones ODBC por medio de llamadas C que utilizan el interfaz nativo de la plataforma Java. El problema es que JDK 1.1 incorpora, como parte de la plataforma Java, un nuevo interfaz nativo denominado JNI ( Java Native Interface ), que además deviene incompatible con las anteriores extensiones a código nativo de JDK 1.0.2, que son precisamente sobre las que Microsoft creó su RNI ( Raw Native Interface ) para MS Internet Explorer 3.0X. De hecho esta cuestión está generando una auténtica guerra de improperios entre Microsoft y Sun, pero lo que a nosotros nos importa es que el mismo código no podrá ejecutarse dependiendo del paginador que oficie de contenedor.

CORRESPONDENCIA ENTRE TIPOS JAVA Y SQL

Los tipos de datos con que operar en SQL no son los mismos con que cuenta Java, de manera que, para establecer un puente entre ambos mundos, los métodos getLoQueSea() y setLoQueSea(/*argumentos*/) de cada una de las clases del package "java.sql" realizan la conversión de acuerdo con la tabla:

POR ENCIMA DE JDBC

Como dijimos al principio, varias compañías están desarrollando ESQL (SQL embebido) y preprocesadores SQL para Java, pero también, y a mí me parece más importante, JavaSoft y otras compañías están preparando la creación de una correspondencia directa entre tablas relacionales y clases Java, que, en natural consecuencia, se integraría en herramientas software de construcción de aplicaciones. Así, por ejemplo, se daría la siguiente correspondencia:

De manera que podrían utilizarse directamente como código Java objetos transacción, objetos bases de datos, a la vez que se podrían hacer corresponder claves externas a referencias Java, y, en definitiva, operar con tablas como si fueran objetos Java:

//...

// Se crea una transacción, que engloba el código hasta su

// commit o abort.

Transaction miTransacción = Transaction.create();

ClientesSet cs = ClientesSet.query( miFiltroDeClientes );

// Ahora se obtiene la clave externa

Ventas miVendedor = miCliente.vendedor;

// El bloqueo de escritura, necesario para el establecimiento

// de la nueva dirección del cliente o el volumen de ventas

// del comercial se obtiene automáticamente

miCliente.dirección = newDirección;

miVendedor.ventas = miVendedor.ventas + estePedido;

// por fin se valida la transacción y los datos de cliente

// y vendedor se pasan a la base de datos

miTransacción.commit();

La integración de esta correspondencia directa en entornos de desarrollo posibilitará la creación automática de clases Java para cada una de las tablas del esquema de la base de datos, además de avanzar significativamente en las capacidades visuales de enlace (como correspondencias n-a-n, relaciones, etc.).

BASES DE OBJETOS

Obviando la discusión sobre su idoneidad, precio y penetración en el mercado, es evidente que las bases de objetos constituyen un segmento del mercado que, si bien pequeño, es sensible respecto de cualquier avance tecnológico en software. Las principales empresas fabricantes de OODBMSs, reunidas en ODMG [3], han puesto en marcha, con increíble celeridad, el enlace de Java con bases de objetos, que destaca, además de por no ser una iniciativa de JavaSoft, por observar la transparencia de uso (que supone un Java "natural" en código y estilo, tanto a nivel de administrador como de programador) como una cualidad esencial del "ODMG Java Binding", que reúne además las siguientes características:

• Funcionalidad completa de acceso a base de datos: OQL (un superconjunto de SQL2), transacción por hebra y bloqueo por objeto.
• Ortogonalidad de persistencia y tipo: O sea, que la persistencia no está asociada (no depende) del tipo-clase Java, de forma que las clases Java existentes podrán poseer instancias persistentes o transitorias, simultáneamente o no.
• Persistencia por alcance: Los objetos navegables desde el “root” serán automáticamente hechos persistentes tras la invocación de transaction.commit .
• Observancia del modelo completo de objetos de ODMG: mediante la adición de clases y otras estructuras al entorno Java.
• Uso de la biblioteca de clases de ODMG: Database, transaction, query y las clases de tipos agregados (colecciones).

Con todo esto podríamos codificar algo como lo siguiente (muy parecido al código de correspondencia objeto-relacional anterior):

// Se abre una base de objetos con derechos de lectura-escritura

Database.open(“Partidos Políticos”,Database.ReadWrite);

Transaction miTransacción = new Transaction;

// seguidamente elegimos, de entre los políticos del Partido

// general, el más proclive al soborno (difícil tarea).

SetOfPolíticos políticosDelPG = Políticos.query(

"exists npp in this.afiliadoA:

npp.partidoPolítico.nombre=\"Partido General\"");

Político miPolítico = Políticos.select(“id = 21PG653”);

// se opera con los tipos almacenados en la base de objetos como

// si fueran tipos Java.

Padrino antiguoPadrino = miPolítico.padrino;

miPolítico.padrino = newPadrino;

miPolítico.cuentaDeSobornos += 3500000;

// y se finaliza la transacción, con lo que los cambios serán

// volcados en la base de objetos

miTransacción.commit()

SERIALIZACIÓN

Java provee, además de lo visto, y también como parte inseparable de JDK 1.1.X, la posibilidad de que cualquier objeto puede ser convertido y recuperado en flujo de bytes, almacenables en ficheros o transportables por la red. Se trata del API de serialización, que tiene una gran importancia respecto del archivo y carga de Java Beans (es frecuente que un fichero JAR contenga varios Beans serializados), en la configuración de condiciones iniciales (los típicos ficheros .INI quedan ya relegados al museo) y, sobre todo, en relación a la Invocación de Métodos Remotos (RMI). Pero esto lo veremos próximamente en un artículo exclusivo.

REFERENCIAS

Pese a que JavaSoft proporciona información incesantemente actualizada sobre JDBC y tecnologías parejas en " http://splash.javasoft.com/jdbc/ ", el lector que se acerque a JDBC echará en falta algún texto introductorio o de ejemplo que le permita practicar y aprender paulatinamente el uso de las clases. Lo cierto es que, dada la juventud de JDBC, existen muy pocas obras dedicadas, aun parcialmente, al tema, y casi todas ellas bien se basan en versiones beta (los plazos de publicación son largos) bien están incompletas. He aquí, con todo, mi selección:

• JDBC TM Guide: Getting Started : Se trata del manual oficial de JavaSoft, incluido en la documentación del JDK 1.1 en formato HTML, pero también descargable en formato PDF. Finalmente se convertirá en el libro " JDBC TM Database Access with Java TM: A Tutorial and Annotated Reference". Por supuesto, se trata de la guía más actualizada, pero adolece de ejemplos prácticos de relevancia (aunque un capítulo entero se dedica sólo a código).
• Developing Intranet Applications with Java , por Jerry Ablan, 1996, Sams.net Publishing, 1-57521-166-1, 492 páginas y CD-ROM: Se trata de un libro ciertamente elemental, pero que encontró su nicho de mercado entre gestores y jefes de departamento, debido al enfoque pretendidamente empresarial que aporta. Los dos capítulos sobre JDBC que en él aparecen son elementales y se refieren a la versión 1.2X para trabajo con JDK 1.0.2, pero pueden proporcionar al lector una iniciación amable a la tecnología. El libro proporciona, también, el denominado "JIT: Java Intranet Framework" que, según el autor, direcciona muchas de las necesidades básicas de la codificación de aplicaciones para Intranets.
• Client/Server Programming with Java and CORBA , por Robert Orfali y Dan Harkey , 1997, Wiley Computer Publishing, 0-471-16351-1, 657 páginas y CD-ROM: Sin ninguna duda un favorito en la carrera editorial. Las anteriores obras de Orfali y compañía ("The Essential Client/Server Survival Guide" -actualmente en segunda edición- y "The Essential Distributed Objects Survival Guide") siguen siendo éxitos de ventas, y con razón. En el libro que nos ocupa el enfoque es claro: CORBA es la mejor arquitectura de interconexión independiente, mientras que Java proporciona una plataforma de implementación independiente, así que ¿por qué no unir fuerzas para el desarrollo de aplicaciones cliente/servidor? En esta línea, y como puede preverse, el acceso a bases de datos resulta indispensable, así que los autores abordan lo que ellos denominan el más largo manual sobre JDBC publicado en la galaxia. Las explicaciones son excelentes y el libro contiene código JDBC para dar y vender. Lo único malo es que la redacción del texto es anterior a la versión definitiva de JDK 1.1, por lo que los autores debieron trabajar con versiones beta, de forma que se produce alguna pequeña desviación.

[1] El lector que busque soluciones universales de acceso a datos debiera revisar el Persistent Object Service (POS) de CORBA, un modelo de arquitectura abierta, independiente de las fuentes de datos y con soporte para los repositorios corporativos, que tiene implementación real. Una buena obra de aproximación es el excelente y divertido libro de Roger Sessions "Object Persistence: Beyond Object-Oriented Databases", 1996, Prentice Hall, 0-13-192436-2.

[2] Al contrario que ODBC -y siempre según Javasoft- JDBC no es un acrónimo y, por tanto, no significa ni "Java DataBase Connectivity" ni nada parecido.

[3] Object Database Management Group, cuyos actuales miembros con voto son UniSQL, Versant, Objectitivy, Object Design, IBEX, POET, GemStone y O2. El lector inquieto puede hallar más información en http://www.odmg.org/