JDBC
Acceso a bases de datos con Java
JDBC hace posible que una aplicación o Applet Java se conecte a una base de datos para realizar consultas o actualizar datos. El código fuente es el mismo con independencia de la base de datos e incluso de dónde esté ubicada físicamente. Las ventajas y aplicaciones de JDBC son evidentes. A la potencia y versatilidad de Java se une la posibilidad de acceder a cualquier base de datos, se encuentre en una plataforma UNIX, Windows NT o cualquier otra. Esto cobra especial interés si tenemos en cuenta que la mayoría de las aplicaciones destinadas a Internet cuentan en alguna de sus partes con código que acceden a una base de datos.
El API JDBC se compone de un conjunto de clases e interfaces Java, contenidas en el paquete java.sql, que forman parte de la plataforma JDK 1.1.X. y por supuesto de Java 2, el nombre con el que se denomina a la plataforma Java surgida con JDK 1.2. Tales clases permiten hacer conexiones a bases de datos, representar frases SQL, definir conjuntos de resultados, etc. En definitiva, mediante un programa Java se podrá conectar con una base de datos, realizar las consultas que se deseen, procesar los resultados obtenidos y finalmente presentarlos de la forma que se considere más oportuna.
Controladores JDBC
Java consigue “dialogar” con las bases de datos mediante la utilización de controladores. Un controlador se define como una librería de software que permite tener acceso a una fuente de datos. Para cada sistema de administración de bases de datos será necesario tener un controlador diferente. Java se encarga de establecer la comunicación con el controlador apropiado en cada caso. De esta forma para el programador que desarrolla una aplicación es indiferente trabajar con un gestor u otro.
Existen diversos tipos de controladores JDBC que se diferencian entre sí por la manera de conectarse a los distintos sistemas gestores de bases de datos. Los controladores JDBC-ODBC, por ejemplo, convierten las llamadas JDBC en llamadas equivalentes ODBC. La siglas ODBC (Open Database Connectivity) representan un protocolo estándar para el acceso a la información de servidores de bases de datos SQL, como por ejemplo Microsoft SQL Server. De lo anterior se deduce que la utilización de los controladores JDBC-ODBC parten de la necesaria existencia de un controlador ODBC en la máquina donde se desarrolle la aplicación. Por consiguiente, los controladores JDBC-ODBC resultan adecuados únicamente en plataformas que soporten ODBC. No es una de las soluciones más eficaces para acceder a bases de datos mediante Java ya que simplemente se está añadiendo una capa más a la estructura de acceso existente mediante ODBC. Aún así, permiten desarrollar de forma sencilla soluciones Java integradas en estos sistemas.
Otro tipo de controladores son los JDBC-API nativos en los que las llamadas JDBC se convierten en llamadas a un API cliente para Sybase, Oracle, Informix, etc. Al igual que en el caso anterior, estos controladores requieren la presencia de determinados archivos binarios en la parte del cliente. También existen los controladores JDBC-Red mediante los cuales las llamadas JDBC se traducen a un protocolo de red independiente de las bases de datos. Estas tendrán que ser convertidas a su vez en llamadas nativas, las cuales dependerán en cada caso dependiente del fabricante de la base de datos al que se pretende acceder. Finalmente los controladores Java puros, son un caso especial de los controladores Java-Red en los que la comunicación se establece directamente con el servidor de la base de datos mediante un protocolo usualmente propietario.
JDBC ha tenido una calurosa acogida, por lo que hoy en día es posible encontrar un controlador prácticamente para cualquier sistema de bases de datos existente en el mercado.
Arquitecturas cliente-servidor en dos o tres capas
Desde el punto de vista de la arquitectura cliente-servidor, existen fundamentalmente dos formas de abordar el acceso a bases de datos mediante JDBC: el modelo en dos capas (two-tier model) y el modelo en tres capas (three-tier model).
Estructura en dos capas
En una arquitectura cliente-servidor clásica existen dos capas. En la primera se encuentra el cliente, donde se implementa la interfaz de la aplicación. Esta normalmente viene dada en forma de aplicación o Applet Java. La segunda capa representa el gestor de bases de datos, donde evidentemente se halla el origen de los datos. Con este modelo un Applet Java se carga en el navegador del cliente y habla directamente con la base datos mediante JDBC.
Esta arquitectura hace que se puedan mantener conexiones persistentes. El Applet se conecta con la base de datos y esa misma conexión es la que se utiliza para todas las transacciones. Por lo tanto se minimizan las peticiones al servidor traslandándose la mayor parte del trabajo al cliente. Esto redunda en un aumento del rendimiento. Sin embargo, también hay algunos inconvenientes que deben ser tenidos en cuenta. Esta solución es muy dependiente del tipo de controlador JDBC que se utilice. Como se accede a la base de datos directamente, los controladores deben estar instalados y configurados en la máquina del cliente donde esté ejecutándose el Applet, lo que hace que el modelo sea mucho menos portable. Por otro lado, debemos tener en cuenta los problemas de seguridad que se derivan de la utilización de Applets para acceder a bases de datos. Es de sobra conocido que decompilar un bytecode de Java es una tarea relativamente sencilla. Un Applet Java que acceda a una base de datos ha de llevar necesariamente en su código el usuario y la contraseña necesarios para poder llevar a cabo la conexión, y estos son datos que en ningún caso conviene hace
El API JDBC se compone de un conjunto de clases e interfaces Java, contenidas en el paquete java.sql, que forman parte de la plataforma JDK 1.1.X. y por supuesto de Java 2, el nombre con el que se denomina a la plataforma Java surgida con JDK 1.2. Tales clases permiten hacer conexiones a bases de datos, representar frases SQL, definir conjuntos de resultados, etc. En definitiva, mediante un programa Java se podrá conectar con una base de datos, realizar las consultas que se deseen, procesar los resultados obtenidos y finalmente presentarlos de la forma que se considere más oportuna.
Controladores JDBC
Java consigue “dialogar” con las bases de datos mediante la utilización de controladores. Un controlador se define como una librería de software que permite tener acceso a una fuente de datos. Para cada sistema de administración de bases de datos será necesario tener un controlador diferente. Java se encarga de establecer la comunicación con el controlador apropiado en cada caso. De esta forma para el programador que desarrolla una aplicación es indiferente trabajar con un gestor u otro.
Existen diversos tipos de controladores JDBC que se diferencian entre sí por la manera de conectarse a los distintos sistemas gestores de bases de datos. Los controladores JDBC-ODBC, por ejemplo, convierten las llamadas JDBC en llamadas equivalentes ODBC. La siglas ODBC (Open Database Connectivity) representan un protocolo estándar para el acceso a la información de servidores de bases de datos SQL, como por ejemplo Microsoft SQL Server. De lo anterior se deduce que la utilización de los controladores JDBC-ODBC parten de la necesaria existencia de un controlador ODBC en la máquina donde se desarrolle la aplicación. Por consiguiente, los controladores JDBC-ODBC resultan adecuados únicamente en plataformas que soporten ODBC. No es una de las soluciones más eficaces para acceder a bases de datos mediante Java ya que simplemente se está añadiendo una capa más a la estructura de acceso existente mediante ODBC. Aún así, permiten desarrollar de forma sencilla soluciones Java integradas en estos sistemas.
Otro tipo de controladores son los JDBC-API nativos en los que las llamadas JDBC se convierten en llamadas a un API cliente para Sybase, Oracle, Informix, etc. Al igual que en el caso anterior, estos controladores requieren la presencia de determinados archivos binarios en la parte del cliente. También existen los controladores JDBC-Red mediante los cuales las llamadas JDBC se traducen a un protocolo de red independiente de las bases de datos. Estas tendrán que ser convertidas a su vez en llamadas nativas, las cuales dependerán en cada caso dependiente del fabricante de la base de datos al que se pretende acceder. Finalmente los controladores Java puros, son un caso especial de los controladores Java-Red en los que la comunicación se establece directamente con el servidor de la base de datos mediante un protocolo usualmente propietario.
JDBC ha tenido una calurosa acogida, por lo que hoy en día es posible encontrar un controlador prácticamente para cualquier sistema de bases de datos existente en el mercado.
Arquitecturas cliente-servidor en dos o tres capas
Desde el punto de vista de la arquitectura cliente-servidor, existen fundamentalmente dos formas de abordar el acceso a bases de datos mediante JDBC: el modelo en dos capas (two-tier model) y el modelo en tres capas (three-tier model).
Estructura en dos capas
En una arquitectura cliente-servidor clásica existen dos capas. En la primera se encuentra el cliente, donde se implementa la interfaz de la aplicación. Esta normalmente viene dada en forma de aplicación o Applet Java. La segunda capa representa el gestor de bases de datos, donde evidentemente se halla el origen de los datos. Con este modelo un Applet Java se carga en el navegador del cliente y habla directamente con la base datos mediante JDBC.
Esta arquitectura hace que se puedan mantener conexiones persistentes. El Applet se conecta con la base de datos y esa misma conexión es la que se utiliza para todas las transacciones. Por lo tanto se minimizan las peticiones al servidor traslandándose la mayor parte del trabajo al cliente. Esto redunda en un aumento del rendimiento. Sin embargo, también hay algunos inconvenientes que deben ser tenidos en cuenta. Esta solución es muy dependiente del tipo de controlador JDBC que se utilice. Como se accede a la base de datos directamente, los controladores deben estar instalados y configurados en la máquina del cliente donde esté ejecutándose el Applet, lo que hace que el modelo sea mucho menos portable. Por otro lado, debemos tener en cuenta los problemas de seguridad que se derivan de la utilización de Applets para acceder a bases de datos. Es de sobra conocido que decompilar un bytecode de Java es una tarea relativamente sencilla. Un Applet Java que acceda a una base de datos ha de llevar necesariamente en su código el usuario y la contraseña necesarios para poder llevar a cabo la conexión, y estos son datos que en ningún caso conviene hace
