Análisis de tecnologías de bases de datos en el World Wide Web

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

CAMPUS CHIHUAHUA

ANÁLISIS DE TECNOLOGÍAS DE BASES DE DATOS EN EL

WORLD WIDE WEB

Co-Asesor:

Co-Asesor:

TESIS QUE PARA OPTAR EL GRADO DE

MAESTRO EN CIENCIAS COMPUTACIONALES

PRESENTA

BENJAMÍN NEVÁREZ CHÁVEZ

Dr. JAVIER VEGA-PINEDA

L·.

Comité de tesis:

M. en C. RAÚL DELHUMEAU OÑATE

D~JUANCORONABURGUEÑO

Jurado:

M. en C. RALF EDER LANGE

D~JUANCORONABURGUEÑO

M. en C. RALF EDER LANGE

Dr. JAVIER VEGA-PINEDA

M. en C. RAÚL DELHUMEAU OÑATE

Presidente

Secretario

Vocal

Vocal

3

CONTENIDO

l. INTRODUCCIÓN .............................................................................................................................. 5 2. JAVA DATABASE CONNECTIVITY (JDBC) ........................................................................................... 9

2.1 INTRODUCCIÓN ......................................................................................................................... 9 2.2 JDBC y ODBC ............................................... ............................................................................ 10 2.3 MODELOS lWO-TIER Y THREE-TIER ............... ..... .... ..................................................... ............ 11 2. 4 SQL ......................................................................................................................................... 13 2.5 COMPONENTES JDBC ................................................................................................................ 14 2.6 TIPOS DE CONTROLADORES ..................................................................................................... 14 2.7 CONEXIÓN CON LA BASE DE DATOS ......................................................................................... 16 2.8 EJECUCIÓN DE SENTENCIAS SQL ................................................... .... ... .... ................................ 17 2.9 EL OBJETO RESULTSET ............................................................................. .......... ....... ......... .. .... 19 2.10 USO DE SENTENCIAS PREPARADAS ......................................................................................... 20 2.11 USO DE TRANSACCIONES ....................................................................................................... 22 2.12 PROCEDIMIENTOS ALMACENADOS .......................................................................................... 23

3. OPEN DATABASE CONNECTIVITY (ODBC) ....................................................................................... 26 3.1 INTRODUCCIÓN ....................................................................................................................... 26 3.2 ARQUITECTURA DE ODBC ..... .. ................................... ............................ .. ................................. 28

4. OLE DB / ADO ............................................................................. ...... ......... ................................... 32 4.1 INTRODUCCIÓN ....................................................................................................................... 32 4.2 COMPONENT OBJECT MODEL (COM) ......................................................................................... 34 4.3 OLE DB .................................................................................................................................... 36 4.4 ACTIVEX DATA OBJECTS (ADO) ................................................................................................ 37 4.5 MODELO DE OBJETOS ADO ........ .. .. .. .... ....................... .... .......................................................... 38 4 .6 EL PROVEEDOR DE OLE DB PARA ODBC ....................................... .. .. ........................ .. ... .... ........ 44 4.7 ACTIVE SERVER PAGES (ASP) ...................................................... ................................... .......... 46

S. LIVEWIRE DATABASE SERVICE ....................................................................................................... 50 5.1 INTRODUCCIÓN ....................................................................................................................... 50 5.2 JAVASCRIPT SERVER-SIDE ........................................................................................................ 51 5.3 CONEXIONES ........................................................................................................................... 54 5.4 POOLS DE CONEXIONES ....... ...... ................. ........................... .. ................... .......... .. .. ...... .. ....... 55 5.5 BASES DE DATOS MULTIHILOS ... .............................................................................................. 56 5.6 MANEJO DE POOLS DE CONEXIONES ................................................... ....................... ...... .. ...... 57 S. 7 CONEXIONES INDIVIDUALES .................................................................................................... 58 5.8 CONEXIONES ACTIVAS A TRAVES DE PETICIONES ..................................................................... 59 5. 9 SENTENCIAS SQL ..................................................................................................................... 60 5.10 CURSORES ............................................................................................................................. 61 5.11 MANEJO DE TRANSACCIONES .............. ........................... ................... ............ .. ... ........... ... ...... 66 5.12 DATOS BINARIOS ........................ ........................................................................................... 68 5.13 PROCEDIMIENTOS ALMACENADOS .......................................................................................... 69

6. CONCLUSIÓN .............................................................. .................................................................. 72 ANEXO A. LA ESPECIFICACIÓN CGI .................................................................................................... 76

A.1 INTRODUCCIÓN ....................................................................................................................... 76 A.2 FUNCIONAMIENTO DE CGI ....................................................................................................... 77 A.3 PASO DE INFORMACIÓN DEL SERVIDOR ................................................................................... 77 A.4 ENVIO DE INFORMACIÓN AL CLIENTE ....................................................................................... 79 A.5 WINDOWS CGI. ............................................................................................................. ........... 79 A.6 FASTCGI ............ ...................................................................................................................... 80

GLOSARIO ........................................................................................................................................ 82 BIBLIOGRAFÍA ................................................................................................................................... 84

4

LISTA DE FIGURAS

FIG. 3.1. ARQUITECTURA DE ODBC ................................................................................................... 29 FIG. 4.1. ARQUITECTURA DEUDA ..................................................................................................... 33 FIG. 4.2. MODELO DE OBJETOS DE ADO ............................................................................................ 38

1. INTRODUCCIÓN

El World Wide Web o Web, propuesto por Tim Berniers-Lee del European

Laboratory for Particle Physics, fué diseñado como un sistema distribuido basado en

hipertexto. El proyecto definió la comunicación utilizada por los clientes y servidores,

denominada HyperText Transfer Protocol (HTTP) así como el formato en el cual los

documentos serían transferidos, denominado HyperText Markup Language (HTML).

Otro aspecto clave del Web fué su capacidad de especificar direcciones de objetos

particulares dentro del sistema, conocidas como Uniform Resource Locators (URL).

5

Aunque el HTML es una forma poderosa de presentar información tiene severas

limitaciones, entre ellas su naturaleza estática. Debido a que los documentos HTML

son archivos de texto, estos necesitan ser continuamente actualizados para incorporar

nueva información. Además, la mayor cantidad de información en las organizaciones se

encuentra en bases de datos y no en documentos. La necesidad de un método para

mantener esta información cambiando dinámicamente dió nacimiento al concepto de

Common Gateway Interface (CGI). En la especificación CGI [1 ], un programa redirige

su salida a un cliente HTTP generando código HTML en forma dinámica. El servidor de

HTTP está diseñado para interpretar esta salida y enviarla al cliente.

Los primeros métodos para llevar la información de base de datos relacionales al

Web utilizaban programas CGI. Estos métodos se basaban en la ejecución de un

programa que se conectaba a la base de datos, realizaba una operación específica y

enviaba sus resultados al cliente. Este proceso consistía en los siguientes pasos:

6

• El cliente Web requería la información al servidor Web.

• Cuando el servidor de Web recibía la petición del cliente ejecutaba el programa CGI

el cual se conectaba a la base de datos.

• El servidor de la base de datos ejecutaba el correspondiente código SOL.

• El programa CGI recuperaba la salida enviada por el manejador de base de datos

agregándole código HTML adicional que el visualizador requería para desplegar los

datos.

• Finalmente el servidor de Web enviaba al cliente el código HTML generado

dinámicamente por el programa CGI, donde era desplegado.

Sin embargo, realizar la conectividad con la base de datos desde los programas

CGI no era fácil. Ciertos programas, denominados gateways, fueron diseñados para

recibir datos del cliente Web y usarlos para comunicarse con la base de datos [2] .

Desafortunadamente, estos gateways, implementados sobre todo en sistemas UNIX,

tenían que ser diseñados para bases de datos específicas. Para construir tales

gateways un programador necesitaba accesar las interfaces de programación de la

base de datos, normalmente proporcionadas por el vendedor de la misma. Estas

interfaces consistían de un conjunto de llamadas a bibliotecas para ser utilizadas por

programas en operaciones sobre bases de datos. Estos programas eran escritos

generalmente en el lenguaje C. Algunos ejemplos de estas interfaces utilizadas eran

Pro*C de Oracle y ESQL/C de lnformix.

Además, CGI presentaba otras desventajas, entre ellas su desempeño. Debido a

que cada petición iniciaba una nueva instancia de la aplicación, CGI utilizaba muchos

de los recursos del sistema y el desempeño bajaba drásticamente en servidores

procesando múltiples accesos a la bases de datos.

7

Más recientemente el lenguaje Java se está convirtiendo en uno de los lenguajes

favoritos de los desarrolladores de aplicaciones de bases de datos debido a sus

características multihilos, a que es altamente portable y a que incluye manejo de

sockets para la programación cliente/servidor. Los programas Java pueden ser

ejecutados como applets, servlets o aplicaciones. Los applets son programas Java

normalmente obtenidos a través de una red y ejecutados por un cliente Web. Los

servlets proporcionan una solución basada en Java para solucionar los problemas

relacionados con la programación lado servidor de APls específicos a una plataforma o

CGI. Son la contraparte lado servidor de lo que los applets son en el lado cliente y a

diferencia de estos no presentan componentes GUI.

Java Database Connectivity (JDBC) es un API SQL que incluye clases Java, un

administrador de controladores y controladores de bases de datos. El controlador

contiene la lógica necesaria para accesar tanto bases de datos de escritorio como

servidores SQL. JDBC, al igual que ODBC, esta basada en el estándar Call Level

Interface (CU) de X/Open. La lista de compañías desarrollando tecnologías JDBC

incluye a Oracle, Sybase, lnformix, IBM, Visigenic e lntersolv entre otros.

La conectividad con bases de datos ha sido también agregada a los servidores

Web, lo que permite a los administradores de sitios Web agregar sentencias SQL en

sus documentos HTML y scripts haciendo el desarrollo de aplicaciones más fácil. Entre

estos servidores destaca el Netscape Enterprise Server que por medio de JavaScript y

su LiveWire Database Service, puede accesar bases de datos en servidores de Oracle,

Sybase, lnformix y 082, además de servidores utilizando ODBC.

Por otra parte, Microsoft con una visión más amplia, promueve su estrategia

Universal Data Access (UDA), por medio de la cual cualquier cliente será capaz de

utilizar cualquier dato independientemente de donde esté localizado y como se

encuentre almacenado. UDA incluye OLE DB como una interface de bajo nivel a

cualquier tipo de datos, sin importar su tipo, formato o ubicación; ActiveX Data Objects

(ADO) como un modelo de programación a nivel aplicación que permite al programador

escribir aplicaciones sobre datos OLE DB; y Open Database Connectivity (ODBC) la

API para acceso a bases de datos SQL más ampliamente utilizada.

8

El negocio del Web y las bases de datos también ha incluido a los mismos

vendedores de bases de datos. Estas compañías han comprendido que muchos

clientes necesitan la habilidad de enlazar la información de sus bases de datos al Web.

Entre estas compañías destaca Oracle Corporation con su Oracle WebServer. El

Oracle WebServer es un servidor Web con un servidor Oracle estrechamente integrado

que permite la creación de documentos HTML dinámicos a partir de datos almacenados

en una base de datos Oracle. Cuando los datos de esta base de datos cambian, los

documentos HTML son actualizados automáticamente sin ningún esfuerzo adicional por

parte del administrador del sitio Web [3].

Este trabajo analiza las principales tecnologías de bases de datos utilizadas en

el desarrollo de aplicaciones en el Web, lo cual es de gran utilidad para webmasters

buscando integración con bases de datos así como para desarrolladores que desean

implementar aplicaciones con bases de datos en Internet o en una intranet. En

particular se enfoca a las tecnologías JDBC, ODBC, ADO / OLE DB y LiveWire. El

trabajo asume que el lector tiene conocimientos básicos tanto de la tecnología Web así

como de bases de datos relacionales [4]. En particular se requieren conocimientos

básicos de HTML [5], Java [6], JavaScript [7][8] y SQL [9].

9

2. JAVA DATABASE CONNECTIVITY (JDBC)

2.1 INTRODUCCIÓN

JDBC es un API para la ejecución de sentencias SQL. Consiste en un conjunto

de clases e interfaces escritas en el lenguaje de programación Java. JDBC proporciona

un API estándar para desarrolladores de herramientas y aplicaciones para bases de

datos [1 O].

Utilizando JDBC es posible enviar sentencias SQL a diversas bases de datos. En

otras palabras, usando JDBC, no es necesario escribir un programa para accesar una

base de datos Oracle, otro para accesar una base de datos Sybase y otro para accesar

una base de datos lnformix. Con JDBC solo será necesario la escritura de un programa

el cual enviará las sentencias SQL a la base de datos apropiada. Además, con una

aplicación escrita en el lenguaje Java tampoco hay que preocuparse por escribir

aplicaciones para correr en diferentes plataformas [11].

En resumen, JDBC hace posible tres cosas: establece una conexión con la base

de datos, envía sentencias SQL y procesa los resultados de estas sentencias. El

siguiente fragmento de código da un ejemplo básico de estos pasos:

Conne ction con e xion = Drive rManager . g e t Connecti on(

"ora c le. j dbc. driver. Orac l eDr i ver", " scot t", "tiger")

Statement sentencia conexion.createStatement();

Re s ultSet re s ultado= sentenc ia. executeQuery (" SELECT titul o , precio FROM

album") ;

while (resultado.next()) {

String titulo= getString ("titulo");

int precio= getFl oat("precio");

10

JDBC es una interface de bajo nivel, lo que significa que es utilizada para llamar

sentencias SQL directamente. Puede utilizarse de esta forma o puede usarse también

como una base sobre la cual construir interfaces y herramientas de más alto nivel. Una

interface de alto nivel es amigable al usuario ya que utiliza un API más comprensible y

conveniente el cual es trasladado a una interface de más bajo nivel como JDBC.

2.2 JDBC y ODBC

Actualmente ODBC es la interface de programación más ampliamente utilizada

para el acceso a bases de datos relacionales. ODBC ofrece la habilidad de conectarse

con una gran cantidad de bases de datos en varias plataformas.

Aunque es posible utilizar ODBC directamente desde el lenguaje Java esto es

realizado en forma más eficiente a través de JDBC por medio del JDBC-ODBC bridge

[11].

Existen varias razones por las cuales utilizar JDBC en lugar de usar ODBC.

ODBC no es apropiado para usarse directamente desde Java debido a que usa una

interface C. Las llamadas desde Java a código nativo C tienen varias deficiencias en

seguridad, implementación y portabilidad de aplicaciones. Por otra parte, una

traducción literal del API en C de ODBC a un API Java no sería una opción adecuada.

Por ejemplo, Java no utiliza apuntadores y ODBC hace un extenso uso de ellos. Podría

pensarse que JDBC es una traducción de ODBC con una interface orientada a objetos

para el lenguaje Java.

ODBC es también difícil de aprender ya que combina características sencillas y

avanzadas y presenta opciones complejas aún para consultas sencillas. Finalmente, un

11

API Java como JDBC es necesario para lograr una solución completamente Java.

Cuando se utiliza ODBC, el administrador de controladores ODBC y sus controladores

deben ser instalados manualmente en cada computadora cliente. Cuando el

controlador JDBC está escrito completamente en Java el código es automáticamente

instalable, portable y seguro en todas las plataformas Java desde microcomputadoras

hasta mainframes.

Recientemente, Microsoft ha introducido nuevos APls más allá de ODBC: RDO.

DAO, ADO y OLE DB. Estos diseños van en la misma dirección que JDBC en cierta

forma, por ejemplo, al ser interfaces orientadas a objetos basadas en clases que

pueden ser implementadas en ODBC.

2.3 MODELOS TWO-TIER Y THREE-TIER

La arquitectura cliente/servidor divide el procesamiento entre dos o más

procesos, normalmente, en dos o más computadoras. Cualquier aplicación de bases de

datos es una aplicación cliente/servidor que maneja el almacenamiento de datos en el

proceso de la base de datos y la manipulación y presentación de los datos en algún

otro lado. El servidor es el motor de bases de datos que almacena los datos y el cliente

es el proceso que obtiene o crea los datos. La forma más simple de una arquitectura

cliente/servidor es llamada arquitectura two-tier [12].

La arquitectura de un sistema depende de la aplicación. Por ejemplo, para

situaciones como el despliegue de simples páginas Web un diseño two-tier es

suficiente. Esto se debe a que el despliegue de páginas HTML estáticas requiere poca

manipulación de datos. Aún cuando la aplicación fuera ligeramente más compleja,

como una aplicación de entrada de datos utilizando formas HTML, una arquitectura

two-tier podría aún ser buena opción.

Idealmente la arquitectura cliente/servidor deja a cada computadora realizar el

procesamiento relevante a su especialización. Las estaciones de trabajo están

12

diseñadas para proporcionar al usuario una interface gráfica de tal forma que ellas

realizan la presentación de los datos. Los servidores están diseñados para manejar

datos complejos de tal forma que ellos sirven como almacenamiento de datos. Pero

conforme los sistemas se vuelven más complejos aparecen nuevas necesidades las

cuales no tienen un lugar claro en el modelo two-tier. Además, los sistemas two-tier son

notorios por su falta de capacidad para adaptarse a ambientes nuevos y a un

crecimiento en el número de usuarios y volumen de datos.

El reuso de objetos es un concepto central en el desarrollo orientado a objetos.

En cierta forma el reuso de objetos es simplemente el reuso de código. Pero en otro

sentido, el reuso de objetos significa usar exactamente las mismas instancias de

objetos en una aplicación que las que se utilizan en otra aplicación. Implementar el

reuso de objetos en un sistema two-tier es casi imposible ya que cada cliente termina

con sus propias copias de los datos.

Se pueden evitar estos problemas extendiendo los sistemas two-tier a three-tier.

Una arquitectura three-tier agrega al modelo two-tier una tercera capa que aísla el

procesamiento de datos en una ubicación central y maximiza el reuso de objetos.

En un modelo three-tier las sentencias SQL son enviadas a una capa intermedia

de servicios la cual envía estas sentencias a la base de datos. La base de datos

procesa las sentencias y envía los resultados de regreso a la capa intermedia la cual a

su vez los envía al usuario. Entre las ventajas del modelo three-tier están que la capa

intermedia hace posible el mantener un control sobre los accesos y los tipos de

actualizaciones que pueden realizarse a los datos. Otra ventaja es que el usuario

puede utilizar un API de más alto nivel el cual es trasladado por la capa intermedia a las

llamadas de bajo nivel necesarias.

Hasta ahora la capa intermedia ha sido típicamente escrita en lenguajes como C

o C++ los cuales ofrecen el más alto desempeño. Sin embargo, con la introducción de

compiladores optimizadores que trasladan bytecode Java a eficiente código máquina,

esta siendo cada vez más práctico implementar estas capas intermedias en Java.

13

2.4 SQL

Un área de dificultad con el uso de SQL es que aunque la mayoría de las bases

de datos utilizan SQL para una funcionalidad básica estas no se adaptan

a la sintaxis del estándar SQL más recientemente definido o a su funcionalidad más

avanzada. Por ejemplo, no todas las bases de datos soportan procedimientos

almacenados y aquellas que lo hacen utilizan sintaxis no consistente una con otra. Se

espera que la porción de SQL que es realmente estándar se extienda para incluir más

funcionalidad.

Una forma por medio de la cual JDBC trata este problema es permitiendo que

cualquier cadena de consulta sea pasada a través del controlador de la base de datos.

Esto significa que la aplicación puede usar la funcionalidad SQL que desee pero corre

el riesgo de recibir errores en algunas bases de datos. De hecho, una consulta de una

aplicación no necesariamente tiene que ser SQL sino que puede ser un derivado

especializado de SQL diseñado para bases de datos específicas.

Para aplicaciones más complejas JDBC trata la compatibilidad SQL en forma

diferente. JDBC proporciona información descriptiva acerca de la base de datos por

medio de su interface DatabaseMetaData de tal forma que las aplicaciones se

puedan adaptar a los requerimientos y capacidades de cada base de datos.

Debido a que JDBC será utilizado como un API base para el desarrollo de

herramientas de acceso a bases de datos y APls de más alto nivel, enfrenta también el

problema de compatibilidad SQL de cualquier software construido con él. La

designación "JDBC Compliant" fué creada para establecer un nivel estándar de

funcionalidad JDBC. Para utilizar esta designación un controlador debe soportar al

menos el ANSI SQL-2 Entry Level. ANSI SQL-2 se refiere al estándar adoptado por el

American National Standards lnstitute en 1992. Entry Level se refiere a una lista

específica de capacidades SQL. Los desarrolladores de controladores se deben

asegurar que sus controladores cumplen con estos estándares utilizando el software de

prueba disponible con el API JDBC.

14

La designación "JDBC Compliant" indica que la implementación JDBC de algún

vendedor ha pasado las pruebas de compatibilidad proporcionadas por JavaSoft. Estas

pruebas verifican la existencia de todas las clases y métodos definidos en el API JDBC

así como también que la funcionalidad SQL Entry Level esté disponible. Aunque estas

pruebas no son exhaustivas proporcionan cierto grado de confiabilidad en la

implementación JDBC.

2.5 COMPONENTES JDBC

JavaSoft proporciona tres componentes de JDBC: el administrador de

controladores JDBC, la suite de prueba de controladores JDBC y el JDBC-ODBC

bridge.

El administrador de controladores JDBC es la parte principal de la arquitectura

JDBC y forma parte del Java Development Kit. Su función principal es conectar las

aplicaciones Java con el controlador JDBC adecuado. La suite de prueba de

controladores JDBC, disponible desde el sitio Web de JDBC, proporciona cierta

confiabilidad acerca de la funcionalidad de los controladores JDBC. El JDBC-ODBC

bridge permite que los controladores ODBC puedan ser utilizados como controladores

JDBC.

2.6 TIPOS DE CONTROLADORES

Los controladores JDBC disponibles actualmente caen en alguna de las

siguientes categorías:

Tipo 1. JDBC-ODBC bridge. El JDBC-ODBC bridge, desarrollado en forma

conjunta por JavaSoft e lntersolv, proporciona acceso JDBC a bases de datos mediante

el uso de controladores ODBC. Para lograr esto las llamadas a funciones JDBC son

convertidas a llamadas a funciones ODBC. El JDBC-ODBC bridge es especialmente

atractivo como una solución inmediata con clientes que actualmente usan ODBC asi

como para el uso con bases de datos para las cuales no existen aún productos JDBC

pero sí controladores ODBC.

15

El JDBC-ODBC bridge fué escrito en C++ e implementado como una biblioteca

de enlance dinámico (Dynamic Link Library o DLL) o como una biblioteca compartida.

Los controladores ODBC son tambien escritos en C o C++ e implementados como

DLLs o bibliotecas compartidas. El hecho de que tanto el JDBC-ODBC bridge como los

controladores ODBC no sean componentes Java significa que no pueden ser cargados

desde Internet e interpretados por un visualizador. Ademas, tanto el JDBC-ODBC

bridge como los controladores JDBC deben ser previamente instalados en cada

máquina cliente. Por otra parte, al estar escritos en C o C++, son dependientes de la

plataforma por lo que se deben desarrollar implementaciones por separado para cada

arquitectura y sistema operativo. Por tanto, este tipo de controlador es más adecuado

en redes en las cuales la instalación del cliente no sea un problema mayor o en

servidores de aplicaciones escritos en Java en una arquitectura three-tier.

Tipo 2. Controlador parcialmente Java con API nativa. Este tipo de controlador

convierte llamadas JDBC a llamadas en el API cliente para Oracle, Sybase, lnformix u

otras bases de datos. Especificamente aprovecha tecnologías de transporte de red

como SQL *Net, 1-Connect y OpenClient de Oracle, lnformix y Sybase respectivamente.

Debido a que el software de transporte de red (SQL *Net, 1-Connect o OpenClient) está

implementado como DLLs o bibliotecas compartidas y escritas en C o C++ no puede

ser cargado desde Internet o interpretado en tiempo de ejecución por algún

visualizador. Por el contrario, el software de transporte de red cliente debe ser instalado

previamente en todas las máquinas cliente.

Tipo 3. Controlador Java puro JDBC-red. Este controlador traslada llamadas

JDBC a un protocolo de red independiente de la base de datos el cual es después

trasladado a un protocolo de la base de datos por un servidor. Este servidor esta

habilitado para conectar sus clientes Java a muchas diferentes bases de datos. En

general, esta es la alternativa JDBC más flexible.

16

Tipo 4. Controlador Java puro con protocolo nativo. Este tipo de controlador

convierte llamadas JDBC directamente a un protocolo de red utilizado por la base de

datos. Esto permite una llamada directa de una máquina cliente a la base de datos y es

una excelente solución para acceso en una intranet. Esencialmente, estos

controladores remplazan el software de transporte de red (SQL *Net, 1-Connect o

OpenClient) con un cliente Java puro. La principal ventaja de este tipo de controlador

es que no es necesaria la instalación de algún software en las máquinas cliente por lo

que son una solución ideal para el desarrollo de applets. La fuente principal de estos

controladores son los vendedores de bases de datos debido a que el software de

transporte de red es típicamente propietario. Una desventaja de este tipo de

controladores es que están diseñados para una base de datos particular en lugar de ser

controladores universales que puedan conectarse a una gran variedad de bases de

datos. Por tanto, un applet que requiera conexiones a múltiples bases de datos

necesitara cargar varias versiones de este tipo de controlador, uno por cada base de

datos.

JavaSoft espera que eventualmente las categorías de controladores 3 y 4 sean

las formas preferidas para acceso a bases de datos con JDBC. Las categorías de

controladores 1 y 2 son soluciones temporales en los casos donde no existe aún

soluciones totalmente Java.

2. 7 CONEXIÓN CON LA BASE DE DATOS

Establecer una conexión con una base de datos involucra dos pasos: cargar el

controlador y realizar la conexión.

Cargar los controladores implica únicamente una línea de código. Por ejemplo,

para cargar el JDBC-ODBC bridge se debe utilizar una línea de código como la

siguiente:

Class .forNarne( "sun.j dbc.odbc .JdbcOdbcDr iver");

17

La documentación del controlador proporcionará el nombre de la clase a utilizar.

Por ejemplo, si el nombre de la clase es oracle . jdb c.driver. OracleDriver se deberá

utilizar la siguiente línea de código:

Class.forName("orac le.jdbc.dri ve r.OracleDri veru);

No es necesario crear una instancia del controlador y registrarlo con el

DriverManager ya que Class. forName hace esto automáticamente. Cuando se ha

cargado un controlador, está disponible para realizar una conexión con la base de

datos. Un ejemplo de lo anterior se muestra en la siguiente línea de código:

Connection conex ion DriverMana ger.getConnecti on(url, " scot t u ,

"tigeru);

La cadena a proporcionar en el parámetro url dependerá de varios factores. Si

se esta utilizando el controlador del JDBC-ODBC bridge, el URL iniciará con

j dbc: odbc. El resto del URL es generalmente la fuente de datos o el sistema de

bases de datos. Para el caso de un controlador JDBC la documentación del controlador

indicará que subprotocolo utilizar. Por ejemplo, Oracle ha registrado el nombre ora c l e

como subprotocolo por lo que la primera y segunda parte del URL será j dbc: oracle.

La documentación del controlador indicará como formar el resto del URL.

Si alguno de los controladores que han sido cargados reconoce el URL

proporcionado al método Dri verManager. getConnection el controlador

establecerá una conexión con la base de datos especificada en el URL. La clase

Dr i verMa nager maneja todos los detalles respecto al establecimiento de la conexión.

La conexión regresada por el método Dr i ve rManage r. g e t Connectio n es una

conexión que puede ser utilizada para enviar sentencias SQL a la base de datos.

2.8 EJECUCIÓN DE SENTENCIAS SQL

La siguiente sentencia SQL crea la tabla a/bum:

CREATE TABLE album (

catalogo INTEGER

artista CHARACTER(60)

titulo CHARACTER(80)

empresa CHARACTER ( 4 O) ,

ano INTEGER,

precio FLOAT)

PRIMARY KEY,

NOT NULL,

NOT NULL,

18

Este código no termina con un terminador de sentencias ya que este puede

variar de una base de datos a otra. Por ejemplo, Oracle usa punto y coma (;) y Sybase

la palabra go para indicar el fin de una sentencia. El controlador a utilizar

proporcionará el terminador de sentencia adecuado por lo que no será necesario

incluirlo en el código JDBC.

Un objeto Statement es lo que envía las sentencias SOL a la base de datos.

Para enviar sentencias SOL solo es necesario crear un objeto Statement y ejecutarlo

proporcionando el método de ejecución apropiado. El método executeUpda te es

utilizado para sentencias DDL (Data Definition Language) así como para sentencias

que actualizan tablas. El método executeQuery es utilizado para ejecutar sentencias

SELECT. Para crear un objeto Statement es necesario una instancia de una conexión

activa. En el siguiente ejemplo se muestra la creación del objeto Statement sentencia

mediante el uso del objeto Connection conexion:

Statement sentencia conexion.createStatement();

En este punto sentencia existe, pero aún no tiene una sentencia SOL para enviar

a la base de datos. Es necesario proporcionar esta sentencia al método usado para

ejecutar sentencia como se muestra a continuación:

sentencia . executeUpdate("CREATE TABLE album" +

"(catalogo INTEGER PRIMAR Y KEY, " +

" art i sta CHARACTER(60 ) NOT NULL, " +

"titulo CHARACTER ( 80) NOT NULL, " +

"empresa CHARACTER ( 4 O) , " +

"ano INTEGER , " +

"precio FLOAT)");

También es posible asignar una sentencia SQL a una variable y utilizar esta

variable con executeUpdate:

String crearTabla = "CREATE TABLE alburn" +

" ( catalogo INTEGER PRIMAR Y KE Y, " +

"artista CHARACTER ( 60) NOT NULL, " +

"titulo CHARACTER(BO) NOT NULL, " +

"empresa CHARACTER ( 4 O) , " +

"ano INTEGER, " +

"precio FLOAT)";

s e nt e ncia.executeUpdate(crearTabla);

El siguiente código inserta una fila de datos en la tabla a/bum:

Staternent sentencia = conexion . createState rnen t ();

sentencia.executeUpdate("INSERT INTO alburn" +

"VALUES (3427756, 'Jethro Tull', 'Aqualung', 'Chrysa lis', " +

"1973, 9.99)");

2.9 EL OBJETO RESUL TSET

JDBC regresa los resultados de sentencias SELECT en un objeto Resul t s et

por lo que es necesario declarar una instancia de esta clase. El siguiente código

demuestra la declaración del objeto Resul tSet resultado y la asignación de las filas

resultantes de una consulta al mismo:

ResultSet resultado

FROM album") ;

senten cia.executeQuery{"SELECT titulo , prec i o

19

La variable resultado, la cual es una instancia de Resul tSet, contiene las filas

resultantes de la consulta anterior. Para accesar estos datos es necesario ir a cada fila

y recuperar los datos de acuerdo a su tipo. El método next mueve lo que es llamado

un cursor a la siguiente fila y hace esa fila, llamada la fila actual, la fila en la cual se

puede operar. JDBC no proporciona un método previous de tal forma que no es

posible moverse de regreso en un objeto Resul tSet.

20

Es necesario utilizar el método getxxx del tipo apropiado para recuperar el valor

de cada columna. Por ejemplo para recuperar un dato SQL VARCHAR se usará

getString y para un tipo SQL FLOAT getFloat. El siguiente código accesa e

imprime los valores almacenados en la fila actual de resultado.

St r ing consulta= "SELECT titulo , precio FROM album";

ResultSet re s ultado= sentencia . executeQuery( consulta);

whi le (r esultado . n e x t () ) {

String tit u lo= resultado . getString("titulo");

Float preci o = resultado . ge tfloat("preci o" );

Sys tem. out.println(titulo +" " + prec i o) ;

JDBC ofrece dos formas de identificar la columna de la cual el método g etXXX

obtendrá algún valor. Una forma es indicando el nombre de la columna, como en el

ejemplo anterior. La segunda forma es indicando el índice o número de columna como

en:

String ti t ulo = r e s ultado .getString( l) ;

Fl oat prec i o = r esul t ado . ge t Fl oat (2 );

en donde el número se refiere al número de columna en el conjunto de resultados y no

en la tabla original.

2.10 USO DE SENTENCIAS PREPARADAS

En algunas ocasiones es más conveniente o más eficiente utilizar un objeto

Prepa r edS t ate rne n t para enviar sentencias SQL a la base de datos. Este tipo

especial de sentencia es derivado de la clase más general Staternent utilizada

anteriormente.

q.JS5 'j

21

Si es necesario utilizar un objeto Statement muchas veces, el uso del objeto

PreparedStatement normalmente reducirá el tiempo de ejecución. La característica

princípal de un objeto PreparedStatement a diferencia de un objeto Statement, es

que este recibe una sentencia SOL cuando es creado. La ventaja de esto es que en la

mayoría de los casos la sentencia SOL será enviada a la base de datos

inmediatamente, en donde es compilada. Como resultado, un objeto

PreparedStatement contiene no solo una sentencia SOL sino también una sentencia

SOL que ha sido compilada.

Los objetos PreparedStatement pueden ser utilizados para sentencias SOL

con parámetros a las cuales se les proporcionaran valores diferentes cada vez que

sean ejecutadas. Al igual que con los objetos State ment, los objetos

PreparedStatement son creados con un método Connectio n. Un ejemplo del uso

de PreparedState me nt con dos parámetros de entrada se muestra a continuación:

Pr eparedStatement s e ntencia= c onexion.prepareS tatement(

"UPDATE alburn SET p rec i o =? WHERE c atalogo=?" ) ;

Será necesario proporcionar valores antes de poder ejecutar una sentencia

PreparedStatement. Esto se realiza por medio de los métodos SetXXX de la clase

Prepare d Statement. Utilizando el objeto Pre paredSta t eme nt del ejemplo anterior

se podría utilizar:

s ente nc ia.setfloat(l, 11. 99);

sent enc ia . set int( 2 , 3427756 ) ;

El primer argumento dado a setXXX indica cual signo de interrogación en la

sentencia original será reemplazado, y el segundo argumento indicara el valor que este

tomará. Después de que los dos valores de la sentencia Prepa r edStateme n t han

sido establecidos esta se ejecutará utilizando el método execu teUp da te :

senten c ia.exec ut e Update( ) ;

Mientras que el método e x e c uteQuery regresa un objeto Resul tSet

conteniendo los resultados de la consulta enviada a la base de datos, el valor

regresado por executeUpdate es un entero que índíca cuantas filas de una tabla

fueron actualizadas. Cuando el método executeUpdate es utilizado con una

sentencia DDL esta retornará el entero O.

2.11 USO DE TRANSACCIONES

22

Una transacción es un conjunto de una o más sentencias que son ejecutadas

juntas como una unidad de tal forma que o todas o ninguna de ellas son ejecutadas.

Cuando una conexión es creada esta se encuentra en modo auto-commit. Esto sígnifíca

que cada sentencia SQL índívidual es tratada como una transaccíón y será

automáticamente completada (commit) después de ser ejecutada con éxíto. Para

permitir que dos o más sentencias sean agrupadas en una transacción es necesario

deshabilitar el modo auto-commit como en la siguiente línea de código:

c o ne x ion. setAutoCommit( f alse) ;

Una vez que el modo auto-commit es deshabilitado ninguna sentencia SQL será

completada hasta que se llame al método comrni t explícitamente. Todas las

sentencías ejecutadas después de la llamada previa al método comrni t serán incluidas

en la transacción actual y serán completadas juntas como una unidad. Cada vez que el

método comrni t es llamado, ya sea automática o explícitamente, todos los cambios

resultantes de las sentencias en la transacción se hacen permanentes.

Para evitar conflictos durante una transacción, un manejador de bases de datos

utiliza candados, los cuales son mecanismos para bloquear el acceso a otros a los

datos que están siendo accesados por la transacción. En el modo auto-commit, donde

cada sentencia es una transacción , los candados son establecidos solo por una

transacción. Una vez que un candado es establecido este permanecerá hasta que la

transacción sea completada o cancelada (rollback). El efecto de este candado podría

ser prevenir a un usuario de una lectura errónea (dirty read). Accesar un dato

actualizado que no ha sido completado es considerado una lectura errónea ya que es

posible que esta transacción sea cancelada y el dato regresado a su valor previo.

La forma en que los candados son establecidos es determinado por el nivel de

transacción. Un ejemplo del nivel de transacción es TRANSACTI ON_READ_COMMITED

el cual no permite que algún valor sea accesado hasta que la transacción sea

completada. La interface Connect ion incluye cinco valores que representan los

niveles de transacciones que se pueden usar en JDBC.

23

Normalmente no es necesario establecer un nivel de transacción y es preferible

utilizar el nivel por defecto definido en la base de datos. JDBC permite consultar que

nivel de transacción esta utilizando la base de datos mediante el método

getTransactionisolation y también permite establecer un nuevo nivel a través del

método setTransactionisolation.

Una llamada al método rollbac k cancela una transacción y regresa cualquier

dato que haya sido modificado a su valor previo. Si al tratar de ejecutar una o más

sentencias en una transacción se obtiene un SQLException se deberá llamar al

método r o llback e iniciar la transacción de nuevo.

2.12 PROCEDIMIENTOS ALMACENADOS

Un procedimiento almacenado es un grupo de sentencias SQL que forman una

unidad lógica y realizan una tarea particular. Los procedimientos almacenados son

utilizados para encapsular un conjunto de operaciones o consultas para ejecutarse en

la base de datos. Estos procedimientos pueden ser compilados y ejecutados con

diferentes parámetros y resultados y pueden tener cualquier combinación de

parámetros de entrada y salida.

Los procedimientos almacenados son soportados por la mayoría de las bases de

24

datos aunque existen una gran variación en su sintaxis y capacidades. Por ejemplo, la

siguiente sentencia SQL crea un procedimiento almacenado en Oracle:

CREATE PROCEDURE altas (catal og o IN INTEGER, artista IN CHARACTER,

titulo in CHARACTER, empresa IN CHARACTER, ano IN I NTEGER,

precio IN FLOAT)

AS BEGIN

END ;

INSERT INTO a lbum VALUES (cata l ogo , a r tista , t i t ulo , e mpresa , ano ,

precio);

El primer paso para llamar a un procedimiento almacenado es crear un objeto

CallableStatement. Al igual que con los objetos Statement y

PreparedStatement esto es llevado a cabo utilizando el objeto Connecti o n . Un

objeto CallableStatement contiene una llamada a un procedimiento almacenado y

no contiene el procedimiento en sí. El siguiente código es un ejemplo de la ejecución de

procedimientos almacenados en JDBC:

Cal l ableStatement sentencia = conexion . prepareCall( "{ ca l l

altas(? , ? , ? , ? , ?,?) }" ) ;

sent e ncia.setint(l, catalogo );

sente n c ia.setString(2 , artista );

sentencia . setString(3, titulo ) ;

sentencia . setString ( 4 , e mp r esa );

sentencia . setint( S , a no) ;

sen ten c ia.se t Fl oat( 6 , precio) ;

sentenc ia.exec ute Up d a te();

La primer línea de código crea una llamada al procedimiento almacenado altas.

Si el procedimiento contiene una consulta se deberá ejecutar utilizando el método

executeQuery. Por otra parte si el procedimiento contiene una actualización a datos

o una sentencia DDL el método a utilizar será e xecu t eUpda t e . Cuando un

procedimiento almacenado contiene más de una sentencia SQL que pueda producir

más de un conjunto de resultados o más de una actualización se deberá utilizar el

método execute . La clase Callab l eStat e me nt es una subclase de

PreparedStatement, por lo tanto un objeto CallableStatement puede tomar

parámetros de entrada al igual que un objeto PreparedStatement. Además, un

objeto CallableStatement puede tomar tanto parámetros de entrada como de

salida.

25

26

3. OPEN DATABASE CONNECTIVITY (ODBC)

3.1 INTRODUCCIÓN

ODBC es un API para acceso a bases de datos ampliamente utilizado. Esta

basado en las especificaciones Call-Level Interface (CLI) de X/Open e ISO/IEC y utiliza

SQL como su lenguaje de acceso a bases de datos. ODBC esta diseñado para permitir

a una aplicación accesar diferentes bases de datos utilizando el mismo código fuente.

Estas aplicaciones para bases de datos llaman funciones de ODBC, las cuales están

implementadas en controladores específicos a una base de datos. Debido a que los

controladores son cargados en tiempo de ejecución un usuario solo tiene que agregar

un nuevo controlador para accesar una nueva base de datos sin necesidad de

recompilar o reenlazar la aplicación [13] .

Las funciones del API de ODBC son implementadas por los desarrolladores de

los controladores específicos para cada base de datos. Las aplicaciones llaman las

funciones en estos controladores para accesar las bases de datos en forma

independiente. El Driver Manager de ODBC administra la comunicación entre las

aplicaciones y los controladores.

Aunque Microsoft proporciona un Driver Manager para computadoras corriendo

Windows NT Server, Windows NT Workstation y Windows 95 y ha escrito varios

controladores ODBC, cualquiera puede escribir aplicaciones y controladores ODBC. De

hecho la mayoría de las aplicaciones y controladores ODBC son producidos por otras

27

compañías. Además estas aplicaciones y controladores están también disponibles para

la plataforma Macintosh y varios sistemas UNIX.

Para ayudar a los desarrolladores de aplicaciones y controladores Microsoft

ofrece el ODBC Software Development Kit (SDK) en las plataformas Windows actuales.

Además, Microsoft en conjunto con Visigenic Software ha portado este SDK tanto a la

plataforma Macintosh y como a varios sistemas UNIX. Salvo pequeñas excepciones,

ODBC esta diseñado para obtener las capacidades de la base de datos y no para

complementarlas por lo que utilizar ODBC en una base de datos sencilla no la

convertiría en una más sofisticada.

ODBC utiliza dos requerimientos en su arquitectura para estandarizar el acceso

a bases de datos:

• Las aplicaciones deben ser capaces de accesar múltiples bases de datos utilizando

el mismo código sin necesidad de recompilación o reenlace del mismo.

• Las aplicaciones deben ser capaces de accesar múltiples bases de datos

simultáneamente.

Las aplicaciones pueden enviar sentencias utilizando la gramática de ODBC o

una gramática específica a la base de datos. Si una sentencia utiliza una gramática

ODBC que es diferente a la gramática de la base de datos el controlador la convierte a

esta ultima antes de enviarla a la fuente de datos. Sin embargo, tales conversiones son

poco comunes y la mayoría de las bases de datos utilizan una gramática SQL estándar.

ODBC proporciona un número significativo de características de las bases de

datos pero no requiere que los controladores soporten todas estas características. Por

otra parte, si ODBC proporcionara solo características que sean comunes a todas las

bases de datos su utilidad seria muy limitada. En lugar de eso, ODBC requiere que los

controladores implementen solo un subconjunto de estas características. Estos

controladores implementaran las características restantes solo si están soportadas por

su base de datos o si estos pueden emularlas. Para que una aplicación pueda

determinar que características son proporcionadas por el controlador y la base de

datos, ODBC proporciona las funciones SQLGetinfo y SQLGetFunctions que

regresan información general acerca de las capacidades del controlador y de la base

de datos además de una lista de las funciones soportadas.

3.2 ARQUITECTURA DE ODBC

La arquitectura de ODBC tiene cuatro componentes:

28

• Aplicación. Es el componente que ejecuta llamadas a funciones ODBC para enviar

sentencias SQL y recuperar resultados.

• Driver Manager. El Driver Manager carga y elimina controladores para la aplicación.

Procesa las llamadas a las funciones ODBC o pasa estas al controlador.

• Controlador. El controlador procesa las llamadas a funciones ODBC, envía la

petición SQL a una fuente específica de datos y regresa los resultados a la

aplicación. Si es necesario, el controlador modifica la petición de la aplicación de tal

forma que esta cumple con la sintaxis soportada por la base de datos asociada.

• Fuente de datos. La fuente de datos consiste de los datos que el usuario desea

accesar además del manejador de base de datos, sistema operativo y, en algunos

casos, red necesarios para accesar los datos.

La figura 3.1 muestra la relación entre estos cuatro componentes. La figura

muestra como pueden existir múltiples controladores y fuentes de datos, lo cual permite

a la aplicación el acceso simultáneo a datos de más de una fuente de datos. Por otra

parte, muestra como el API ODBC es utilizado tanto entre la aplicación y el Driver

Manager como entre el Driver Manager y el controlador. La interface entre Driver

Manager y el controlador es llamada Service Provider Interface o SPI.

Aplicación

1

D PAPldeODBC

1

Driver Manager

D D D PAPldeODBC

Controlador Controlador Controlador

D D D Fuente de Fuente de Fuente de

Datos Datos Datos

Fig. 3.1. Arquitectura de ODBC.

Algunas tareas son comunes a todas las aplicaciones independientemente de

como utilicen ODBC. Estas tareas definen el flujo de cualquier aplicación ODBC:

• Seleccionar una fuente de datos y conectarse a ella.

• Enviar una sentencia SQL para su ejecución.

• Recuperar resultados, si existen.

• Procesar errores.

• Completar o cancelar la transacción.

• Desconectarse de la fuente de datos.

29

30

El Driver Manager es una biblioteca que administra la comunicación entre la

aplicación y los controladores. Por ejemplo, en las plataformas Windows, el Driver

Manager es una biblioteca de enlace dinámico (DLL) escrita por Microsoft. El Driver

Manager resuelve algunos problemas comunes a todas las aplicaciones. Estos incluyen

determinar que controlador utilizar basado en el nombre de la fuente de datos, cargar y

descargar estos controladores y llamar funciones en estos controladores.

La aplicación es enlazada al Driver Manager y llama las funciones ODBC en el

Driver Manager no en el controlador. La aplicación identifica el controlador destino y la

fuente de datos. Cuando el Driver Manager carga el controlador construye una tabla de

apuntadores a las funciones de este controlador.

Los controladores son bibliotecas que implementan las funciones de ODBC.

Cada controlador es específico a una base de datos; por ejemplo, un controlador para

Oracle no podrá accesar directamente datos en una base de datos lnformix. Entre las

tareas realizadas por un controlador se incluyen:

• Conectarse y desconectarse de la fuente de datos.

• Encontrar errores de funciones no revisados por el Driver Manager.

• Iniciar Transacciones.

• Enviar sentencias SQL a la fuente de datos para su ejecución.

• Enviar y recuperar datos de una fuente de datos incluyendo la conversión de tipos

de datos especificados por la aplicación.

La arquitectura del controlador cae en dos categorías dependiendo del software

que procesa las sentencias SQL:

• Controladores basados en archivos. En este caso el controlador accesa los datos

físicos directamente. El controlador actúa tanto como controlador como fuente de

datos, es decir, procesa llamadas ODBC y sentencias SQL. Por ejemplo, los

controladores dBASE son controladores basados en archivos ya que dBASE no

proporciona un motor de bases de datos que el controlador pueda utilizar. Es

importante notar que los desarrolladores de controladores basados en archivos

necesitan escribir sus propios motores de bases de datos.

31

• Controladores basados en manejadores de bases de datos relacionales. En este

caso el controlador accesa los datos físicos a través de un motor de bases de datos

separado. El controlador únicamente procesa llamadas ODBC. Pasa las sentencias

SQL al motor de bases de datos para su procesamiento. Por ejemplo, los

controladores de Oracle son controladores basados en manejadores de bases de

datos relacionales ya que Oracle tiene un motor de bases de datos que el

controlador utiliza.

32

4. OLE DB I ADO

4.1 INTRODUCCIÓN

Las aplicaciones actuales requieren la integración de información almacenada

no solamente en los tradicionales sistemas de bases de datos sino también en

sistemas de archivos, hojas electrónicas, bases de datos de escritorio, herramientas

administradoras de proyectos, correo electrónico, servicios de directorios y datos

multimedia entre otros. Varias compañías de bases de datos están promoviendo un

método basado en la base de datos tradicional. En este método, el vendedor de bases

de datos extiende la base de datos e interfaces de programación para soportar nuevos

tipos de datos, incluyendo texto, video y audio. Este método requiere mover todos los

datos requeridos por la aplicación, los cuales pueden estar distribuidos en diversas

fuentes a través de la empresa, al sistema de base de datos del vendedor.

UDA (Universal Data Access) es una alternativa al método anterior. Sin

embargo, también puede implementarse como un método complementario y utilizarse

en conjunto con este. La premisa de UDA es permitir a las aplicaciones el acceso

eficiente a los datos donde estos residan sin replicación, transformación o conversión.

UDA es una plataforma para el desarrollo de aplicaciones que requieren acceso

a diversos datos relacionales y no relacionales a través de una intranet o de Internet.

UDA consiste de una colección de componentes software que interactúan unos con

33

otros utilizando un conjunto común de interfaces a nivel sistema definidas por OLE DB

[14].

OLE DB es la interface de programación a nivel sistema de Microsoft diseñada

para proporcionar acceso a cualquier tipo de dato sin importar su tipo, formato o

ubicación. OLE DB especifica un conjunto de interfaces COM que encapsulan u ocultan

varios servicios de administración de bases de datos. Mientras OLE DB es una

interface de programación a nivel sistema, ADO es una interface de programación a

nivel aplicación. ADO es un modelo de programación de bases de datos que permite al

programador escribir aplicaciones sobre datos OLE DB desde cualquier lenguaje

incluyendo Visual Basic, Java, VBScript, JavaScript y C/C++.

Consumidores

Servicios

Proveedores de Datos

~ o ü o ~ o ü

Motor de Cursor

Hoja Electrónica

Aplicación o Herramienta

ActiveX Data Objects (ADO)

OLE DB

Motor de Consultas

OLE DB

ODBC/SQL Correo

Electrónico

Fig. 4.1. Arquitectura de UDA.

Datos Multimedia

L.. (].)

2:: (].) (/)

e: o u (I] (/) e: ~ 1-.:= o (/)

o L..

ü

~

La figura 4.1 muestra la arquitectura de UDA. En esta arquitectura existen tres

tipos generales de componentes de bases de datos:

• Proveedores de datos. Los proveedores de datos son componentes que

representan las fuentes de datos como pueden ser bases de datos relacionales,

34

hojas electrónicas y datos multimedia.

• Servicios. Los servicios son componentes que consumen y producen datos OLE DB.

• Consumidores de datos. Los consumidores de datos son componentes que

consumen datos OLE DB. Estos pueden ser modelos de acceso a datos de alto

nivel como ADO o aplicaciones escritas en lenguajes como C++ o Java.

Todas las interacciones entre los componentes de la figura 4.1, indicadas por

flechas bidireccionales, pueden ocurrir en procesos a través de protocolos de red como

COM Distribuido (DCOM) o HTTP.

4.2 COMPONENT OBJECT MODEL (COM}

Tradicionalmente diferentes tipos de software han proporcionado sus servicios

en diferentes formas. Por ejemplo, una aplicación puede enlazarse a una biblioteca y

luego accesar sus servicios por medio de llamadas a funciones de esta biblioteca. O

una aplicación puede utilizar los servicios proporcionados por otra, la cual corre en un

proceso separado, requiriendo la definición de un protocolo entre las dos aplicaciones.

O quizás otra aplicación utilice los servicios del sistema operativo a través de llamadas

al sistema. O quizás aún, una aplicación necesite los servicios de otra aplicación

corriendo en una máquina diferente accesible a través de una red. COM define una

forma estándar por medio de la cual un software pueda proporcionar sus servicios a

otro software.

Con COM cada software implementa sus servicios como uno o más objetos

COM. Cada objeto COM soporta una o más interfaces cada una de las cuales incluye

cierto número de métodos. Un método es típicamente una función o procedimiento que

realiza una función específica y puede ser llamado por el software que utiliza el objeto

COM (el cliente de este objeto). Cada cliente accesa los servicios proporcionados por

un objeto COM únicamente al invocar los métodos de las interfaces del objeto y no

pueden accesar directamente cualquiera de los datos del objeto.

Para llamar los métodos de una interface COM el cliente debe adquirir un

apuntador a esta interface. Un objeto COM típicamente proporciona sus servicios a

través de varias interfaces por lo que un cliente deberá tener un apuntador separado

por cada interface cuyos métodos necesite utilizar. Una vez que un cliente tiene un

apuntador a la interface deseada de un objeto en ejecución puede empezar a utilizar

los servicios de dicho objeto llamando los métodos de la interface.

35

El uso de objetos es una idea central en COM aunque la forma en que COM

define y usa objetos difiere de la forma en que los objetos son utilizados en otras

tecnologías populares orientadas a objetos. Por otra parte, COM proporciona un

mecanismo efectivo para el reuso de software permitiendo la creación de componentes.

En los últimos 35 años los diseñadores de hardware han pasado de construir

computadoras del tamaño de un cuarto a lap-tops basadas en pequeños y poderosos

microprocesadores. Por otra parte en este mismo periodo de tiempo los desarrolladores

de software han pasado de construir grandes sistemas basados en ensamblador y

Cobol a construir aún grandes sistemas en C y C++. La razón por la cual el diseño de

software no ha avanzado a la misma velocidad que el diseño de hardware se debe a

que el diseño de hardware ha sido enormemente apoyado por el reuso de

componentes existentes. El reuso de componentes es también una forma de crear

mejor software. El crear nuevas aplicaciones a partir de componentes existentes

permite producir código más confiable además de que puede efectuarse en un proceso

más rápido y en una forma más económica [15].

Al igual que las bibliotecas tradicionales los objetos que resuelven problemas

específicos pueden ser creados una vez y reutilizados muchas veces. Pero los objetos

tienen aún más que ofrecer que las bibliotecas. A través de la herencia un objeto puede

reutilizar la definición de interfaces de otro objeto. Además el polimorfismo simplifica el

reuso escondiendo diferencias irrelevantes.

A pesar de sus ventajas, la tecnología de objetos no ha alcanzado su máximo

potencial de permitir el reuso de software, no existiendo un mercado de objetos

reusables actualmente. El principal problema es que no existen estándares para

enlazar objetos binarios. Aunque es posible compilar un objeto y después utilizar este

objeto binario a través de una biblioteca, su funcionamiento solo está garantizado

cuando el mismo compilador es utilizado tanto en la biblioteca como en la aplicación

que está utilizando la biblioteca. Otro problema es el reuso de objetos a través de

diferentes lenguajes.

36

COM pretende solucionar estos problemas. Los objetos COM son empacados en

bibliotecas o archivos ejecutables y luego distribuidos en un formato binario. Debido a

que COM define una forma estándar de accesar estos objetos binarios, los objetos

COM pueden ser escritos en algún lenguaje y usados en cualquier otro. Además,

debido a que los objetos COM son instanciados conforme son utilizados, cuando una

nueva versión es instalada en el sistema todos los clientes automáticamente obtendrán

la nueva versión la siguiente vez que utilicen el objeto.

4.3 OLE DB

Al revisar una base de datos relacional típica se puede ver que está compuesta

internamente de una serie de funciones separadas. Un motor de bases de datos

relacionales incluye un catálogo de metadatos, un motor SQL y analizador para el

procesamiento de peticiones, un administrador de transacciones, probablemente un

motor de cursores y los datos almacenados en tablas. El concepto de OLE DB es

explotar la base de datos en sus partes básicas [16]. OLE DB proporciona

componentes externos a la base de datos que proporcionan esta funcionalidad típica

de bases de datos en una arquitectura de componentes reusables. Y debido a que

estos componentes no están directamente enlazados a la base de datos pueden ser

compartidos a través de múltiples aplicaciones.

OLE DB define una jerarquía de cuatro objetos principales [17]. El objeto Da ta

37

Source encapsula funciones que identifican un proveedor de datos particular, verifica

que el usuario tenga los permisos apropiados para conectarse al proveedor e inicializa

la conexión a una fuente de datos específica.

El objeto Session encapsula las funciones para conectarse a una fuente de

datos particular.

El objeto Corrunand encapsula las funciones que permiten a un consumidor

invocar la ejecución de comandos de definición o de manipulación de datos.

Los objetos Rowset son creados ya sea directamente de una sesión o como el

resultado de la ejecución de algún comando.

4.4 ACTIVEX DATA OBJECTS (ADO)

ADO es un conjunto de interfaces de alto nivel que actúan sobre datos OLE DB.

Aunque OLE DB es una poderosa interface para manipular datos, la mayoría de los

desarrolladores de aplicaciones no necesitan el bajo nivel de control que OLE DB

proporciona sobre el acceso a los datos [18].

ADO soporta características clave para el desarrollo de aplicaciones

cliente/servidor así como aplicaciones basadas en el Web como las siguientes:

• Objetos independientes. A diferencia de Data Access Objects (DAO) o Remate Data

Objects (ROO) con ADO no es necesario navegar a través de una jerarquía para

crear objetos debido a que la mayoría de los objetos pueden ser creados en forma

independiente.

• Procedimientos almacenados. ADO soporta procedimientos almacenados con

parámetros de entrada y salida así como valores de regreso.

38

• Cursores. ADO soporta diferentes tipos de cursores.

• Conjuntos de resultados. ADO soporta múltiples conjuntos de resultados a partir de

procedimientos almacenados u otras sentencias.

El Remate Data Service (ROS) de ADO permite el manejo de datos en forma

remota. Por medio de ROS es posible mover datos de un servidor a una aplicación

cliente o página Web, manipular los datos en el cliente y regresar los datos

actualizados al servidor en un solo paso. Previamente liberado como Advanced Data

Connector, ROS ha sido combinado con el modelo de programación de ADO para

simplificar el manejo de datos en el lado cliente.

Connection Connection

Errors Error Command

Record set

Parameters Para meter Field

Record set Properties Property

Fields Field

Fig. 4.2. Modelo de objetos de ADO.

4.5 MODELO DE OBJETOS ADO

Aunque los objetos ADO pueden crearse fuera del ámbito de una jerarquía estos

objetos muestran una relación jerárquica según en el modelo de objetos ADO mostrado

en la figura 4.2. Los siete objetos de este modelo son: Connec ti o n, Command,

Recordse t , Error, Pa rame t er, Field y Propert y [19].

Un objeto Connection representa una conexión abierta con una fuente de

datos. En el caso de un sistema de base de datos cliente/servidor puede ser el

equivalente a una conexión de red con el servidor. Con las colecciones, métodos y

propiedades del objeto Connection se pueden realizar operaciones como:

• Configurar la conexión antes de abrirla con las propiedades Mode,

ConnectionString y ConnectionTimeout.

• Establecer la base de datos por defecto con la propiedad Defaul tDatabase.

• Establecer el nivel de aislamiento para las transacciones abiertas por medio de la

propiedad IsolationLevel.

• Especificar un proveedor OLE DB con la propiedad Provider.

• Establecer e interrumpir las conexiones físicas a la fuente de datos mediante los

métodos Open y Close.

• Ejecutar una sentencia en una conexión con el método Execu te y configurar la

ejecución con la propiedad CommandTimeout.

• Administrar transacciones sobre la conexión abierta, incluyendo transacciones

anidadas cuando el proveedor las soporte, con los métodos BeginTrans,

CommitTrans y RollbackTrans y con la propiedad Attribu tes.

• Examinar errores regresados de la fuente de datos con la colección Errors.

• Obtener información acerca del esquema de la base de datos con el método

OpenSchema.

39

40

El objeto Comrnand es una definición de una sentencia específica que se desea

ejecutar contra una fuente de datos. Este objeto se utiliza para consultar una base de

datos y regresar resultados en un objeto Recordset o para manipular la estructura de

la base de datos. Con las colecciones, métodos y propiedades del objeto Comrnan d se

pueden realizar operaciones como:

• Definir el texto ejecutable de una sentencia (por ejemplo, una sentencia SOL)

mediante el uso de la propiedad ComrnandText.

• Definir consultas parametrizadas o argumentos de procedimientos almacenados con

objetos Parameter y la colección Parameters.

• Ejecutar una sentencia y regresar un objeto Recordset utilizando el método

Ex ecu t e .

• Especificar el tipo de sentencia con la propiedad ComrnandType antes de la

ejecución para optimizar el desempeño.

• Controlar si el proveedor salva o no una versión preparada o compilada de la

sentencia antes de su ejecución mediante la propiedad Prepared.

• Establecer el número de segundos que un proveedor esperara para la ejecución de

una sentencia mediante la propiedad ComrnandTimeout.

• Asociar una conexión abierta con un objeto Comrna n d por medio de su propiedad

ActiveConnec ti on.

Un objeto Re co r dse t representa el conjunto completo de registros resultantes

de una consulta. En un momento dado el objeto Recordse t hace referencia

únicamente a un registro denominado el registro actual.

41

En ADO existen cuatro tipos de cursores:

• Cursor dinámico. Este tipo de cursor permite ver registros agregados, modificados y

eliminados por otros usuarios.

• Cursor de clave. Este cursor se comporta como un cursor dinámico excepto que

impide visualizar registros que otros usuarios agregan así como registros que otros

usuarios eliminan. Los datos cambiados por otros usuarios permanece visibles.

• Cursor estático. Proporciona una copia estática de un conjunto de registros para

localizar datos o generar reportes. Registros agregados, modificados o eliminados

por otros usuarios no serán visibles.

• Cursor solo hacia adelante. Este cursor se comporta en forma idéntica a un cursor

dinámico excepto que solo proporciona una navegación hacia adelante a través de

los registros. Esto mejora el desempeño en situaciones en donde solo es necesario

hacer un recorrido hacia adelante en el conjunto de registros.

Para escoger el tipo de cursor se deberá especificar la propiedad Curso rType

antes de abrir el objeto Recordset o pasar un argumento CursorType con el método

Open. Algunos proveedores no soportan todos los tipos de cursores. Si no se especifica

el tipo de cursor, ADO utilizara un cursor solo hacia adelante por defecto. Se pueden

crear tantos objetos Recordset como sean necesarios.

Cuando se abre un objeto Recordset el apuntador de registro actual es

posicionado en el primer registro, si existe, y las propiedades BOF y EOF son puestas en

False. Si no existen registros ambas propiedades son puestas en True. Se pueden

utilizar los métodos MoveFirst, MoveLast, MoveNext, MovePrevious y Move así

como las propiedades Abso lutePosi tion, AbsolutePage y Fil ter para

reposicionar el registro actual. Los objetos Recordset solo hacia adelante únicamente

soportan el método MoveNext.

42

El objeto Error contiene los detalles acerca de errores en acceso a datos

pertenecientes a una determinada operación. Cada operación involucrando objetos

ADO puede generar uno o más errores del proveedor. Cuando ocurre un error, uno o

más objetos Error son colocados en la colección Errors del objeto Connectio n.

Cuando otra operación ADO genera un error, la colección Errors es inicializada y un

nuevo conjunto de objetos Error son colocados en esta colección. Cada objeto Error

representa un error especifico del proveedor no un error de ADO. Los errores ADO son

expuestos en el mecanismo de manejo de errores en tiempo de ejecución.

Para obtener detalles específicos acerca de cada error se pueden leer las

propiedades del objeto Error, entre ellas las siguientes:

• La propiedad De ser ipt ion contiene el texto del error.

• La propiedad Number contiene el valor entero del error.

• La propiedad Source identifica al objeto que generó el error.

• Las propiedades SQLState y Nati veError proporcionan información acerca de

las fuentes de datos SQL.

El objeto Parameter representa un parámetro o argumento asociado con un

objeto Command basado en una consulta parametrizada o un procedimiento

almacenado. Muchos proveedores soportan sentencias parametrizadas. En estas

sentencias la acción a realizar es definida una vez aunque los parámetros son

utilizados para alterar algunos detalles de la sentencia.

Un objeto Field representa una columna de datos con un tipo de datos común.

Un objeto Reco rdset contiene una colección Fie l ds construida de objetos Field.

Cada objeto Field corresponde a una columna en el objeto Reco rdset. La propiedad

Val u e de los objetos Field se utiliza para establecer o regresar datos para el registro

actual. Algunas de las funciones que se pueden realizar con las propiedades de un

objeto Field son:

• Regresar el nombre de un campo con la propiedad Name.

• Visualizar o modificar los datos en el campo con la propiedad Value.

• Regresar las características básicas de un campo son las propiedades Type,

Precision y NumericScale.

43

El objeto Property representa una característica dinámica de un objeto ADO

definida por el proveedor. Los objetos ADO tienen dos tipos de propiedades:

construidas y dinámicas. Las propiedades construidas son aquellas implementadas en

ADO e inmediatamente disponibles a cualquier nuevo objeto. Las propiedades

construidas no aparecen como objetos Property en una colección Properties de

algún objeto.

Las propiedades dinámicas son definidas por el proveedor de datos y aparecen

en la colección Properties del objeto ADO apropiado.

Un objeto Property tiene definidas cuatro propiedades construidas:

• La propiedad Name, la cual es una cadena que identifica la propiedad.

• La propiedad Type, la cual es un entero que especifica el tipo de datos de la

propiedad.

• La propiedad Value, que contiene el valor de la propiedad.

• La propiedad At tributes, la cual es un valor que indica características de la

propiedad específicas al proveedor.

44

4.6 EL PROVEEDOR DE OLE DB PARA ODBC

El proveedor OLE DB para ODBC de Microsoft permite a ADO conectarse a

cualquier fuente de datos ODBC. Los controladores para ODBC están disponibles para

las mayores bases de datos relacionales disponibles actualmente. El proveedor soporta

transacciones aunque diferentes bases de datos ofrecen diferentes tipos de soporte a

transacciones. Para conectarse a este proveedor se deberá establecer el argumento

Provider de la propiedad ConnectionString con el dato MSDASQL. Debido a que

este es el proveedor por defecto de ADO, si se omite el parámetro Provider de la

cadena de conexión, ADO tratara de establecer una conexión con este proveedor.

Ya que se puede omitir el parámetro Provider de la cadena de conexión esta

puede ser idéntica a la cadena de conexión de ODBC para la misma fuente de datos.

La cadena de conexión cuando se utiliza un Data Source Name (DSN) de ODBC es:

11 [ Provider=MSDASQL; J { DSN=nombre I FileDSN=archi vo [DATABASE=base de

datos;) UID=usuario; PWD=contrasena 11

La cadena de conexión sin utilizar un DSN es:

11 [Provider=MSDASQL;) DRIVER=controlador; SERVER=servidor; DATABASE=base de

datos; UID=usuario; PWD=cont rasena 11

Si se utiliza un DSN este debe ser definido a través del Administrador de ODBC

en el panel de control de Windows.

ODBC proporciona una sintaxis específica para el llamado de procedimientos

almacenados. Para la propiedad CornmandText de un objeto Cornmand, el argumento

CornmandText de un método exec ute en un objeto Connection o el argumento

Source de un método Ope n en un objeto Recordset la sintaxis es la siguiente:

11 { [ ? ) call procedimiento [ ( ? [, ? [ , . . . ) ] ) ] } 11

45

donde cada símbolo de interrogación hace referencia a un objeto en la colección

Parameters. El primer símbolo de interrogación hace referencia a Paramete r s ( o),

el segundo a Parameters ( 1) y así sucesivamente. Los parámetros son opcionales y

dependen de la estructura del procedimiento almacenado. Si un procedimiento

almacenado no utiliza parámetros se deberá utilizar lo siguiente:

"{ call p r ocedimient o)"

Si el procedimiento utilizara dos parámetros se deberá utilizar:

" {c all pro cedimi e nto(? , ?) )"

Si el procedimiento regresa un valor, este valor será tratado como otro

parámetro, como en el ejemplo siguiente:

"{ ? call proce dimiento)"

A continuación se muestra un ejemplo escrito en VBScript en el medio ambiente

Active Server Pages (ASP) el cual envía una sentencia SQL a la base de datos e

imprime los resultados utilizando una tabla HTML.

<HTML >

<BODY>

<% Set cone x ion = Crea t e Ob ject ("ADODB . Connecti on")

c onexi o n.Open ''DSN=d sn;UID=sco tt;pwd=tiger"

Set resul t ado = con ex i on.Exe c ut e("S ELECT * FROM album" ) %>

<TABLE BORDER = l >

<% Whil e resul tad o . EOF <> Tr u e %>

<TR>

< / TR>

<% Fo r Eac h co lumna In r esultado . Fields %>

<TD>

<% Respons e .Write columna . Va lue %>

< / TD>

<% Ne x t %>

<% resultado .MoveNex t %>

<% Wend %>

<% conexion.Close %>

</TABLE>

</BODY>

</HTML>

Para establecer una conexión con la base de datos, el ejemplo anterior crea un

objeto Conne ction mediante la sentencia:

Set c onexion Createübject("ADODB.Connection ")

la conexión es luego establecida con:

conexion.Open "DSN=dsn;UID=scott;pwd=tiger"

Una vez que la conexión ha sido establecida, el ejemplo utiliza el método

Execute para ejecutar una sentencia SOL, la cual regresa un objeto Recordse t .

Set re s ul t ado= c one xion.Execu te (" SELECT * FROM album")

46

El programa posteriormente utiliza la propiedad EOF y el método MoveNex t para

recorrer cada una de las filas resultantes de la consulta. Asimismo utiliza los objetos

Field del objeto Re co rdset para desplegar los datos de cada campo mediante el uso

de la propiedad Value.

Finalmente la conexión es liberada utilizando el método Close.

4.7 ACTIVE SERVER PAGES (ASP)

ASP es una tecnología desarrollada por Microsoft para crear páginas Web

dinámicas o desarrollar aplicaciones Web complejas por medio del uso de scripts en el

lado servidor. Las páginas ASP son archivos que contienen etiquetas HTML, texto y

ordenes. También pueden llamar componentes ActiveX para realizar diversas tareas

47

como conectarse a una base de datos o realizar algún cálculo. ASP utiliza lenguajes

basados en scripts como Microsoft VBScript y Microsoft JScript. La salida resultante de

una página ASP es código estándar HTML.

Cuando un usuario requiere una página ASP a través de un visualizador el

servidor de Web recibe la petición y, al reconocerla como una página ASP, la pasa al

componente ASP del servidor de Web. El componente ASP del servidor interpreta el

código de la página y envía los resultados de regreso al visualizador cliente. Por tanto,

todo el procesamiento es realizado en el servidor y el visualizador únicamente

despliega código HTML estándar.

Es necesario utilizar etiquetas especiales para delimitar código de scripts en

ASP. Estas etiquetas toman las formas <%%> y <SCRIPT> </SCRIPT>. Debido a que

ASP soporta varios lenguajes de scripts necesita dos etiquetas diferentes. Las

etiquetas<% %> utilizan el lenguaje por defecto, que puede ser establecido para todo el

servidor o para toda una página, mientras que las etiquetas <SCRIPT> < / SCRI PT>

permiten especificar en que lenguaje esta escrito el script. Por ejemplo el siguiente

archivo ASP

<HTML>

<HEAD >

<T ITLE >Ho l a mundo</TI TLE>

</HEAD>

<BODY>

<% Re sponse.Write ("Hola mundo") %>

</BODY>

</ HTML>

al ser ejecutado aparecerá en el visualizador cliente como

<HTML >

<HEAD>

<TI TLE >Ho la mundo</TI TLE>

</ HEAD>

<BODY>

Hola mundo

</BODY>

</H TML>

48

Las aplicaciones ASP se componen de cinco objetos principales para almacenar

y recuperar datos entre páginas. Estos objetos son Request, Response, Session,

Application y Server.

El objeto Request contiene los datos enviados al servidor de Web cuando el

visualizador hace una petición. Estos incluyen datos de formas GET y POST además de

cookies e información de encabezado HTTP. Se puede utilizar la propiedad Form para

recuperar datos de formas enviadas por el método POST. Por ejemplo,

Request. Form ("nombre") recupera el elemento nombre del objeto Request. Se

deberá utilizar el método QueryString del objeto Request para recuperar la cadena

enviada por una forma utilizando el método GET. Por ejemplo, para recuperar el campo

nombre de una cadena se utiliza Request. QueryS tring ("nombre").

El objeto Response es la contraparte del objeto Request. El objeto Request

contiene datos enviados al servidor y el objeto Response es utilizado para regresar

datos al visualizador. La función más utilizada del objeto Response es el método

w rite. Este método escribe los datos que serán pasados al visualizador. El objeto

Re sponse también permite al programador enviar datos cookie de regreso al cliente y

establecer el encabezado HTTP que será regresado al visualizador.

El objeto Session proporciona la habilidad de guardar datos por cada sesión de

usuario. Cuando un visualizador requiere por vez primera una página de una aplicación

ASP es creado un nuevo objeto Session. El objeto Session utiliza el protocolo

utilizado por las cookies de tal forma que visualizadores no habilitados para manejar

cookies no podrán guardar datos en el objeto Session. Para habilitar una propiedad

en el objeto Session es necesario pasar a este objeto el nombre de la propiedad .

El objeto Application almacena variables específicas a la aplicación actual. El

49

objeto Server es similar al objeto Application pero su ámbito abarca a todo el

servidor. Tanto el objeto Application como el objeto Server poseen métodos lock

y unlock, los cuales permiten que las propiedades de estos sean modificadas en una

página sin que puedan ser modificadas en otra al mismo tiempo.

En algún momento dado quizás sea necesaria más funcionalidad en ASP que la

proporcionada por VBScript o JScript. Microsoft resuelve este problema mediante el

uso de componentes ActiveX. ActiveX permite al programador desarrollar componentes

en C++, Visual Basic y Java, los cuales corren en el servidor de Web. Estos

componentes tienen acceso a las variables y métodos de los objetos Request,

Response, Application y Server por medio de interfaces. Para utilizar un

componente ActiveX este debe ser primero asignado a un objeto empleando el método

CreateObj ect del objeto Server.

50

5. LIVEWIRE DATABASE SERVICE

5.1 INTRODUCCIÓN

Las aplicaciones JavaScript corriendo en el Netscape Enterprise Server pueden

utilizar el LiveWire Database Service para accesar bases de datos de Oracle, Sybase,

lnformix y 082, además de servidores utilizando el estándar ODBC. Las aplicaciones

corriendo en el Netscape FastTrack Server pueden accesar únicamente bases de datos

a través de ODBC [7].

Generalmente, para interactuar con una base de datos usando LiveWire se

siguen los siguientes pasos:

• Utilizar el objeto database o crear un objeto DbPool para establecer un pool de

conexiones de bases de datos. Esto se realiza típicamente en la página inicial de la

aplicación a menos que se requiera que los usuarios utilicen una conexión especial.

• Conectar el pool a la base de datos. Al igual que el anterior, este paso es realizado

típicamente en la página inicial de la aplicación.

• Recuperar una conexión del pool. Esto es realizado implícitamente cuando se utiliza

el objeto database o explícitamente cuando se utiliza el método connection del

objeto DbPool.

51

• En los casos en que se desee actualizar información en la base de datos se deberá

iniciar una transacción.

• Crear un cursor o llamar un procedimiento almacenado en la base de datos para

trabajar con información de la base de datos. Esto puede implicar desplegar

resultados de una consulta o actualizar el contenido de la base de datos. Será

necesario cerrar cualquier cursor, conjunto de resultados o procedimientos

almacenados que se haya utilizado.

• Completar (commit) o cancelar (rollback) cualquier transacción abierta.

• Liberar la conexión con la base de datos ( en el caso de que se esté utilizando

objetos Connection).

5.2 JAVASCRIPT SERVER-SIDE

JavaScript es un lenguaje de scripts para el desarrollo de aplicaciones tanto

cliente como servidor. JavaScript es comúnmente utilizado para desarrollo de

aplicaciones en el lado cliente. Las aplicaciones de mayor escala frecuentemente

tienen necesidades más complejas tales como comunicación con bases de datos

relacionales. Para estas situaciones los servidores de Netscape proporcionan

JavaScript server-side el cual tiene objetos adicionales para soportar capacidades del

lado servidor. Además, algunos aspectos del lenguaje actúan en forma diferente

cuando este es utilizado en el lado servidor.

El código JavaScript para aplicaciones cliente es incluido directamente en las

páginas HTML donde este es interpretado por el visualizador completamente en tiempo

de ejecución. Debido a que las aplicaciones servidor generalmente tienen mayores

demandas de desempeño estas son compiladas antes de su ejecución.

Los visualizadores pueden interpretar las sentencias JavaScript client-side

52

incluidas en una página HTML. Cuando el visualizador o cliente solicita tal página, el

servidor de Web envía el contenido completo de tal documento, incluyendo las

sentencias JavaScript y HTML, a través de la red. El cliente lee la página desplegando

los resultados del código HTML y ejecutando las sentencias JavaScript. Las sentencias

JavaScript client-side pueden responder a eventos del usuario como pueden ser clicks

del ratón, entrada de datos en formas o navegación de páginas. Por ejemplo, es

posible escribir una función JavaScript que verifique que el usuario ha introducido

información valida en una forma.

En el servidor el código JavaScript también esta incluido dentro de páginas

HTML. Las sentencias del lado servidor pueden realizar conexiones a diversas bases

de datos, compartir información a varios usuarios, accesar el sistema de archivos del

servidor o comunicarse con otras aplicaciones a través de Java y LiveConnect. Las

páginas HTML con código JavaScript server-side también pueden contener código

JavaScript client-side.

En contraste con los scripts lado cliente, las páginas HTML que utilizan

JavaScript server-side son compiladas en archivos ejecutables bytecode. Estos

archivos ejecutables son ejecutados por el servidor de Web en conjunto con su motor

JavaScript en tiempo de ejecución.

Cuando un visualizador solicita una página compilada el motor en tiempo de

ejecución ejecuta cada sentencia JavaScript server-side encontrada en la página y

dinámicamente genera la página HTML a regresar. El resultado de ejecutar sentencias

server-side puede agregar nuevo código HTML o sentencias JavaScript client-side a la

página HTML original. El motor en tiempo de ejecución envía posteriormente la página

generada a través de la red al visualizador cliente el cual ejecutará, en caso de existir,

el código JavaScript client-side, y desplegará los resultados. En contraste con los

programas CGI, todo el código JavaScript es integrado directamente en la página

HTML.

El Session Management Service de JavaScript contiene objetos los cuales se

pueden utilizar para mantener datos que pueden persistir a través de peticiones de

clientes, múltiples clientes y múltiples aplicaciones. El LiveWire Database Service

proporciona objetos para acceso a bases de datos que sirven como interface a

servidores de bases de datos SQL.

Las aplicaciones JavaScript pueden ser visualizadas como una arquitectura

cliente servidor de tres capas. Estas tres capas son:

• Cliente Web. Esta capa proporciona una interface de usuario final a la aplicación.

53

Esta capa puede también contener alguna lógica de la aplicación como por ejemplo

validación de datos implementados usando JavaScript client-side. Los clientes

pueden estar dentro o fuera de un firewa/1.

• Servidor Web / cliente de bases de datos . Esta capa consiste del servidor de Web

de Netscape. Contiene la lógica de la aplicación, maneja la seguridad y controla el

acceso a la aplicación por múltiples usuarios. Esta capa permite a clientes dentro y

fuera de un firewa/1 accesar la aplicación. El servidor de Web también actúa como

un cliente a un servidor de bases de datos relacionales.

• Servidor de bases de datos. Esta capa consiste de servidores de bases de datos

SQL típicamente corriendo en estaciones de trabajo de alto desempeño. Contiene

todos los datos de la base de datos, metadatos y reglas de integridad referencial

requeridas por la aplicación. Esta capa se encuentra típicamente dentro de un

firewa/1 y puede proporcionar un nivel adicional de seguridad al proporcionado por el

servidor de Web.

Al crear una aplicación JavaScript las páginas HTML pueden contener tanto

sentencias a ejecutarse en el lado cliente como en el lado servidor. El código

JavaScript client-side es delimitado por la etiqueta SCRI PT mientras que el código

server-side es delimitado por la etiqueta SERVER. También es posible escribir archivos

que contengan únicamente código JavaScript y no código HTML. Si los archivos HTML

o JavaScript contienen sentencias a ejecutarse en el servidor estos necesitan

compilarse en un archivo ejecutable. El archivo ejecutable es llamado archivo web y

tiene la extensión .web. El compilador de aplicaciones JavaScript convierte el código

fuente HTML en bytecode independiente de la plataforma.

54

En tiempo de ejecución, cuando el visualizador solicita una página de una

aplicación, el motor en tiempo de ejecución localiza el archivo y ejecuta todo el código

server-side creando una página HTML que es enviada al cliente. Esta página puede

contener etiquetas HTML así como sentencias JavaScript client-side. El código server

side no podrá utilizar objetos client-side así como el código client-side no podrá utilizar

objetos server-side.

5.3 CONEXIONES

Existen dos formas básicas de conectarse a una base de datos utilizando

LiveWire. Se puede usar los objetos DbPool y Connection o el objeto database [8].

Al utilizar los objetos Db Poo l y Connecti o n se crea un pool de conexiones de

bases de datos para trabajar con una base de datos relacional. Con este método se

crea una instancia de la clase DbPoo l y se accesan objetos Connect ion a través de

este objeto DbPool. Este método ofrece gran flexibilidad ya que la aplicación puede

tener varios pools, cada uno con su propia configuración de base de datos y usuario.

Cada pool puede tener múltiples conexiones para determinada configuración. Esto

permite accesos simultáneos a múltiples bases de datos o a la misma base de datos

desde múltiples cuentas de usuario.

El objeto databas e es utilizado para conectar una base de datos con una

configuración de conexión de base de datos y usuario. El objeto da tabase puede

compararse a un pool sencillo de conexiones. Este método es más sencillo e implica

utilizar únicamente el objeto database. Sin embargo, carece de la flexibilidad del uso

de los objetos Db Poo l y Conn ect ion . Si se utiliza el objeto databa se y se desea

55

conectar a diferentes bases de datos o con diferentes cuentas de usuario se deberá

desconectar de una configuración antes de conectarse a otra. Además, una transacción

sencilla no podrá extenderse a múltiples peticiones cliente y no podrán realizarse

conexiones simultáneas a múltiples bases de datos.

5.4 POOLS DE CONEXIONES

Si se desea utilizar el objeto database no es necesario crearlo ya que es un

objeto predefinido por el motor en tiempo de ejecución de JavaScript. Por otra parte, si

se desean las capacidades adicionales de la clase DbPoo l es necesario crear una

instancia de esta clase y conectar el objeto resultante a una base de datos particular lo

cual crea un pool de conexiones.

Es posible crear un objeto DbPoo l genérico para después especificar la

información de la conexión utilizando el método connect o también especificar esta

información al crear el pool. Si se utiliza el objeto database se debe realizar siempre la

conexión por medio de database. connect que toma el siguiente formato:

connect(tipo, serv idor, usuario , contraseña, nombre, conexiones,

comrni t);

Es necesario especificar la siguiente información cuando se realiza una conexión

ya sea al crear un objeto DbPool o cuando se llama al método connect de DbPool o

da tabase:

• tipo. Especifica el tipo de base de datos. Puede tomar los valores "ORACLE",

"SYBASE", "INFORMIX", "082" o" ODBC".

• servidor . Indica el nombre del servidor de bases de datos al cual se desea

conectar. El nombre del servidor es normalmente establecido cuando la base de

datos es instalada.

• usuario. Especifica el nombre del usuario en la base de datos.

• contraseña. Indica la contraseña del usuario.

• nombre. Especifica el nombre de la base de datos a conectar para un servidor

determinado. Se utiliza con bases de datos que soportan múltiples bases de datos

para un solo servidor. Para Oracle, ODBC y 082 se deberá proporcionar una

cadena vacía.

56

• conexi o nes. Parámetro opcional que indica el número de conexiones que estarán

disponibles en el pool de la base de datos. No deberá establecerse este parámetro

a un valor mayor al que la licencia del cliente de la base de datos indica. Si no se

especifica este valor para el objeto DbPool su valor será 1. Si no se especifica para

el objeto database su valor será definido por el valor Built-in Maximum Database

Connections al instalar la aplicación usando el Application Manager.

• commi t . Parámetro booleano opcional que especifica si se completan o cancelan

las transacciones abiertas cuando la conexión es finalizada. Se especifica true

para completar transacciones abiertas y false para cancelarlas. Si no se especifica

este parámetro para el objeto DbPool su valor será false. Si no se especifica para

el objeto da tabas e será true.

Por ejemplo, la siguiente sentencia crea un nuevo pool de cinco conexiones a

una base de datos Oracle con el cual las transacciones no completadas son

canceladas:

pool new DbPool ("ORACLE", "nombretns", " scott", "tiger", 5);

5.5 BASES DE DATOS MUL TIHILOS

LiveWire soporta acceso multihilos a bases de datos. Esto significa que es

57

posible tener más de un hilo de ejecución accesando una base de datos al mismo

tiempo. Esta característica explica el porque tiene sentido el tener un pool de conexión

con más de una conexión en él. Sin embargo, muchas bibliotecas de vendedores de

bases de datos no son multihilos. Para estas bases de datos no importa cuantas

conexiones existan en el pool de conexión ya que solo una de ellas podrá accesar la

base de datos a la vez.

Una base de datos que no soporta múltiples hilos probablemente tiene serios

problemas de desempeño. Debido a que solamente un hilo de ejecución puede accesar

la base de datos a la vez, otros hilos deben esperar a que el primer hilo termine de usar

la conexión antes de que puedan utilizar la base de datos. Si muchos hilos intentan

usar la base de datos cada uno de ellos podría tener que esperar bastante tiempo.

5.6 MANEJO DE POOLS DE CONEXIONES

En un momento dado, un objeto DbPool o database conectado y todas las

conexiones en el pool están asociadas con una configuración de base de datos

particular. Esto significa que todo en un pool esta conectado a un servidor de base de

datos particular, como un usuario determinado, con una contraseña particular y a una

base de datos determinada.

Si la aplicación siempre utiliza la misma configuración se puede utilizar un objeto

DbPool o utilizar el objeto database y conectarse exactamente una vez. En este caso

la conexión debería hacerse en la página inicial de la aplicación.

Si se utiliza el objeto database y múltiples configuraciones solo hay una opción.

En este caso se deberá conectar, desconectar y volver a conectar el objeto database

cada vez que sea necesario cambiar algo acerca de la configuración. Si se usan

objetos DbPool y se tienen múltiples configuraciones aún será necesario conectar,

desconectar y volver a conectar el mismo objeto DbPool. Sin embargo, con objetos

DbPool se tiene más flexibilidad. Bajo este esquema se pueden crear tantos pools

como sean necesarios y colocarlos bajo el control del objeto pro j ect. Utilizar

múltiples pools es más eficiente y generalmente más seguro que reutilizar un pool

sencillo (tanto con el objeto database como con un objeto DbPool).

Al administrar los pools se deben considerar dos factores: cuantas

configuraciones diferentes son necesarias y si una conexión simple necesita

extenderse a múltiples clientes. Si el número de configuraciones posibles es pequeño

se puede crear un pool separado por cada configuración.

58

Si se tiene un número muy grande o desconocido de configuraciones (por

ejemplo, cuando cada usuario utiliza su propio nombre de usuario) existen dos

situaciones a considerar. Si cada conexión dura únicamente por una petición se podrán

crear pools individuales en la página cliente. Sin embargo, algunas veces una conexión

debe expanderse a múltiples peticiones cliente o quizás no se desee reconectarse a la

base de datos en cada página de la aplicación. En estas situaciones es conveniente

crear un arreglo compartido de pools.

Con cualquiera de estos métodos, cuando una conexión individual en un pool no

sea ya necesaria, se deberán limpiar los recursos utilizados por la conexión de tal

forma que estos estén disponibles para otro usuario. Para realizar esto se deberán

cerrar todos los cursores, procedimientos almacenados así como conjuntos de

resultados que hayan sido abiertos. Finalmente se deberá liberar la conexión (esto no

será necesario si se esta utilizando el objeto database).

5.7 CONEXIONES INDIVIDUALES

Una vez que se ha creado un pool de conexiones, una página cliente puede

accesar una conexión individual del pool. Si se esta utilizando el objeto database la

conexión esta implícita en ese objeto, es decir, se deben utilizar los métodos del objeto

database para accesar la conexión. Sin embargo, si se utilizan objetos DbPoo l , una

conexión esta encapsulada en un objeto Connec t ion, el cual se obtiene llamando un

59

método del objeto DbPool. Por ejemplo, si se tiene el siguiente pool:

pool new DbPool ("ORACLE" , "nornbretns" , "scott", " t iger", S);

se puede obtener una conexión del pool con la siguiente llamada:

con e x ion poo l .connection( " Con e x ión" , 30 );

Los parámetros de este método son opcionales. El primero es un nombre para la

conexión, utilizado para depuración, y el segundo un entero indicando el tiempo

máximo en segundos que se deberá esperar para lograr la conexión. En este ejemplo,

si el pool tiene una conexión disponible a más tardar en 30 segundos, esta es asignada

a la variable conexión. Si no existe una conexión disponible en este periodo de tiempo

el método regresara sin una conexión.

Cuando se ha finalizado el uso de la conexión se debe regresar al pool llamando

el método release del objeto Co nnection. Si se esta utilizando el objeto datab ase

no es necesario liberar la conexión. Antes de llamar al método r e l ea se se deberán

cerrar todos los cursores, procedimientos almacenados y conjuntos de resultados que

hayan sido abiertos. Cuando se llama al método r elease el sistema espera a que los

cursores, procedimientos almacenados y conjuntos de resultados abiertos sean

cerrados y luego regresa la conexión al pool de la base de datos. La conexión estará

luego disponible para otro usuario.

5.8 CONEXIONES ACTIVAS A TRAVES DE PETICIONES

En algunas situaciones será necesario extender una conexión a múltiples

peticiones de clientes, o sea, utilizar la misma conexión en múltiples páginas HTML.

Típicamente se utilizan las propiedades del objeto c li e nt para información que se

extiende a varias peticiones cliente. Sin embargo, el valor de una propiedad c l ien t no

puede ser un objeto. Por tanto no se puede almacenar un pool de conexiones en un

objeto e l i e nt y en su lugar se utilizara un pool de conexiones en un objeto p r oj ect.

60

5.9 SENTENCIAS SQL

La forma más sencilla de desplegar los resultados de una consulta es utilizar el

método SQLTable del objeto database o del objeto Connection. Este método toma

una sentencia SELECT y regresa una tabla HTML. Cada fila y cada columna de la

consulta son una fila y una columna de la tabla. La tabla HTML tiene también

encabezados por cada columna en la tabla de la base de datos. El método SQLTa ble

no permite controlar el formato de la salida y si esta contiene un objeto Blob el objeto

no es desplegado como una imagen.

Por ejemplo, si conexión es un objeto Connection, la siguiente sentencia

despliega los resultados de la consulta en una tabla:

c onexi on. SQLTable("SELECT * FROM album");

El método execute del objeto database o del objeto Conn ection permite a

una aplicación la ejecución de cualquier sentencia SQL. Utilizar execute se denomina

passthrough SQL ya que las sentencias SQL son pasadas directamente al servidor. El

método execut e puede utilizarse para cualquier sentencia SQL DDL o DML (Data

Manipulation Language) soportada por el servidor de la base de datos. Aunque puede

usarse este método con cualquier sentencia SQL no se podrán regresar datos a través

de él.

El método execute permite ejecutar sentencias SQL estándar y no extensiones

de SQL proporcionadas por algún vendedor de bases de datos. Por ejemplo no se

podrá llamar la función describe de Oracle por medio de execute . Por ejemplo para

eliminar una tabla de la base de datos que es referida por la propiedad tabla del objeto

proj ect se puede usar la siguiente llamada:

c o ne xion . e xecut e ("DROP TABLE " + proj ect . tab l a) ;

5.1 O CURSORES

En muchas situaciones se necesitará cambiar el formato del resultado de una

consulta o realizar algún procesamiento con este. Para esto se deberá trabajar con

cursores regresados por la consulta a la base de datos. Para crear una instancia de la

clase Cursor se llama al método cursor del objeto database o del objeto

Connec tion pasando una sentencia SQL como su parámetro.

61

Un cursor es semejante a una tabla, con filas y columnas especificadas por la

consulta. Un cursor también contiene la noción de fila actual, la cual es un apuntador a

una fila en la tabla virtual. Cuando se realizan operaciones sobre un cursor

normalmente afectarán a la fila actual.

Al terminar de usar el cursor se deberá cerrar este utilizando el método e los e .

Una conexión de base de datos no podrá ser liberada hasta que todos los cursores

asociados a ella hayan sido cerrados. Por ejemplo, si se llama al método relea s e del

objeto Connec t i o n y la conexión tiene un cursor asociado que no ha sido cerrado la

conexión no es liberada hasta que el cursor sea cerrado.

Crear un objeto Cursor también abre el cursor en la base de datos por lo que

no es necesario una sentencia explícita para abrirlo. Se puede proporcionar la siguiente

información al crear un objeto Cursor:

• Una sentencia SQL soportada por el servidor de base de datos. Para asegurarse

independencia de la base de datos se deberá usar sintaxis SQL 89/92. El cursor

será creado como una tabla virtual de los resultados de la sentencia SQL.

• Un parámetro booleano opcional que indica si el cursor es un cursor actualizable.

Este parámetro se deberá utilizar solo si se desea cambiar el contenido de la base

de datos.

62

Por ejemplo, la siguiente sentencia crea un cursor de registros de la tabla a/bum:

resultado= conexion.cursor("SELECT catalogo, titul o , precio FROM

album");

Cuando un cursor es creado el apuntador es posicionado justo antes de la

primer fila de la tabla virtual. Se pueden encontrar varios problemas al crear un objeto

cursor. Por ejemplo, si la sentencia SELECT utilizada se refiere a una tabla no

existente la base de datos regresara un error y el método cursor regresara un nulo en

vez de un objeto Cursor. En esta situación se deberá utilizar los métodos

maj orErrorCode y maj orErrorMessage para determinar que error ha ocurrido. Por

otra parte, si la sentencia SELECT se refiere a una tabla existente pero la consulta no

regresa filas, la base de datos no regresará ningún error y el método cursor regresará

un objeto Cursor válido. Sin embargo, ya que este objeto no contiene filas, la primera

vez que se utilice el método next, este regresara false. La aplicación deberá revisar

esta posibilidad.

Cuando se crea un cursor se obtiene una propiedad colNa me por cada columna

en la tabla virtual (excepto aquellas correspondientes a funciones agregadas)

determinada por la sentencia SELECT. En el ejemplo anterior, el cursor tiene las

propiedades catalogo, titulo y precio. Se puede desplegar los valores de la primer fila

regresada utilizando las siguientes sentencias:

// Crear el objet o Cursor

r esul t ado= c onexion. c ursor("SELECT cata l ogo , titulo , precio FROM

album");

// Asegurarse de que no ha habido un error en la base de da tos

// y que se ha regresado un cur sor real

if (resultado && (conexion .majorErrorCode() == 0)) {

//Obtenerla primer f ila

resultado.next();

//De splegarlos valores

write("<8>Nómero de catálo go :</8>" +resultado.catalogo+ "<BR>" ) ;

write("<B>Titulo: </8>" +resultado.ti t ulo+ "<BR>" ) ;

write(" <8 >Precio: </8 >" + resultado.precio);

/ / Cerrar el cursor

resultado. c l a se();

63

También es posible referirse a las propiedades de un objeto Cursor (y de hecho

a cualquier objeto JavaScript) como elementos de un arreglo. El elemento cero del

arreglo corresponde a la primer columna. Por ejemplo las sentencias wri te anteriores

se pueden escribir:

write("<B>Nómero de catálogo:< / 8 >" + resultado [OJ + "<8R>" ) ;

write(" <8 >Titulo: < /8>" + resultado [l] + " <BR>");

wri t e (" <B>Precio: </ B>" + resultad o [ 2 ]);

Esta técnica es particularmente útil dentro de un ciclo. Por ejemplo, se puede

crear un objeto Cursor y desplegar los resultados en una tabla HTML con el siguiente

código:

// Crear el objeto Cursor

r e s ultado = con e xio n. c u rso r("SELECT catalogo, titul o , prec i o FROM

a l b um" );

// Asegurarse de que no ha habido un error en la base d e datos

// y que se ha regresado un c urso r real

if (resultado && (conex i on.maj o rErro r Code( ) == 0 )) {

wr ite(" <TABLE BORDER 1 >" ) ;

/ /Desplegarlos n ombres de las columnas como encabeza do s

wri t e (" <TR>" ) ;

i = O;

whil e ( i < r esult a d o . c o lumn s ( ) ) {

writ e (" <TH>", r esul tado . columnName (i), " </TH>" ) ;

i++;

write ("</TR>");

// Despliega cada fila en la tabla virtual

while(resultado.next())

write ("<TR>");

i = O;

while ( i < resultado.columns())

write(" <TD>", resultado[i], " </ TD>");

i++;

write ("</TR>");

write(" </ TABLE>");

// Cierra el cursor

resultado.clase();

64

Las sentencias SELECT pueden recuperar valores que no son columnas en una

base de datos como por ejemplo valores agregados y expresiones SQL. La única forma

de accesar las propiedades de estos objetos Cursor es como elementos de un

arreglo. El siguiente ejemplo crea un cursor llamado resultado, encuentra la fila de este

cursor y despliega el valor recuperado por la función agregada MAX:

result a do= c onex i on. c ursor(" SELECT MI N(precio ), AVG (pr e ci o) ,

MAX (pre c i o ) FROM album");

if (resultado && (conexion.majorErrorCode () == O)) {

e x istefila = resultado.next();

if (existefila )

writ e ("E l precio má s al t o e s r esultado [ 2 ] ) ;

Inicialmente el apuntador de un cursor es posicionado antes de la primer fila de

la tabla virtual. El método next se utiliza para mover el apuntador a través de los

registros en la tabla virtual. Este método mueve el apuntador a la siguiente fila y

regresa true si encuentra otra fila en la tabla virtual. Si no encuentra otra fila regresará

fa l se .

65

El método c o lumns de la clase Cursor regresa el número de columnas de un

cursor. Este método no necesita parámetros. El método col umnName de la clase

Cursor regresa el nombre de una columna en una tabla virtual. Este método toma un

entero como parámetro donde este entero especifica el número de la columna iniciando

en cero. Por ejemplo, la siguiente expresión asigna el nombre de la primer columna en

el cursor resultado a la variable encabezado:

encabe zado re s ultado.columnName(O);

El método columnName no garantiza el orden en que se asignan números a las

columnas cuando se utiliza un asterisco en SELECT para seleccionar las columnas en

una tabla como en

resul tado conexio n. c u rso r (" SELECT * FROM a lbum" ) ;

por lo que es recomendable indicar los nombres de las columnas en la sentencia

SELECT.

Es posible modificar una tabla basándose en la fila actual del cursor por medio

de cursores actualizables. Para crear un cursor actualizable se debe agregar el

parámetro true como en el siguiente ejemplo:

resultado = conex i on . c u rsor("SELECT cata l og o , t i t ulo , precio FROM

album", true ) ;

Para que un cursor sea actualizable la sentencia SELECT a utilizar debe generar

una consulta actualizable. Por ejemplo, la sentencia no puede recuperar filas de más

de una tabla o contener una cláusula GROUP BY. Se deberá consultar la

documentación del vendedor de la base de datos para información en como construir

consultas actualizables.

Cuando se utilizan cursores para realizar actualizaciones en la base de datos se

deberá siempre trabajar dentro de una transacción explícita. Esto se realiza mediante

66

los métodos beginTransaction, c omrni tTransaction y rollbackTransa c tion.

Si no se utilizan transacciones explícitas en estas situaciones se podrían obtener

errores de la base de datos. Por ejemplo, Oracle regresa Error ORA-01002: f etch

out of sequence al utilizar un cursor actualizable fuera de una transacción explícita.

El siguiente ejemplo utiliza un cursor actualizable para actualizar los precios de todas

las filas de la tabla:

conexion.beginTransaction();

resultado = conexion .curso r("SELECT * FROM album", true ) ;

i f ( resultado && (conex ion.maj orErrorCode () ==O))

/ / Iteració n sobre las filas del curso r

while (resultado.next()) {

// Ac tualiza r infor maci ón

res u l t ado . precio= resultado . precio* 1 . 1 ;

resultado.updateRow ("album");

// Cerrar el cursor y c omp letar la transacción

resul t ado . c l ase() ;

conexion. commitTr ansact i on();

else {

/ /Sino e x i s te cursor cancelar la transacción

c o nexi on.rollbackTransac ti on( ) ;

5.11 MANEJO DE TRANSACCIONES

Aunque los diversos servidores de bases de datos implementan las

transacciones en forma ligeramente diferente, LiveWire proporciona los mismos

métodos para el manejo de transacciones con todas las bases de datos. Para la

mayoría de las bases de datos, si no se realiza un control de transacciones explícito, .el

motor en tiempo de ejecución utilizará la característica autocommit que trata a cada

sentencia como una transacción separada. Cada sentencia es entonces completada o

cancelada inmediatamente basada en el éxito o falla de la sentencia individual. El

manejo explícito de transacciones sobrescribe este comportamiento por defecto.

67

Para utilizar transacciones en forma explícita LiveWire proporciona los siguientes

métodos del objeto database o del objeto Connection:

• beginTransac tion. Inicia una nueva transacción, conocida como la transacción

actual.

• Commi tTransaction. Completa la transacción actual. Este método intenta

completar todas las sentencias desde la ultima llamada a b e g i nTransacti o n.

• Ro llbac kTra n sact i o n . Cancela la transacción actual. Este método cancela

todas las modificaciones desde la ultima llamada a beginTran saction.

Por supuesto estos métodos no podrán ser utilizados en bases de datos que no

soportan transacciones. Por otra parte, LiveWire no soporta transacciones anidadas. Si

el método beginTransaction es llamado múltiples veces antes de completar o

cancelar la primer transacción se obtendrá un error.

Para el objeto d a t abas e el ámbito máximo de una transacción se limita a la

actual petición del cliente (página HTML) en la aplicación. Si la aplicación sale de la

página antes de llamar a los métodos commi tTran sac tio n o

rollb a c kTran sact i o n la transacción es automáticamente completada o cancelada

basada en el parámetro commi t proporcionado al realizar la conexión con la base de

datos.

Para los objetos Conne c t ion el ámbito de una transacción esta limitado al

tiempo de vida del objeto. Si la conexión o pool de conexiones es liberada antes de

llamar los métodos commitTransa c ti o n o rollbac kTransac tio n la transacción

es automáticamente completada o cancelada basado en el parámetro c omrni t

proporcionado al realizarse la conexión, ya sea con el método con nect o con el

constructor DbPool.

5.12 DATOS BINARIOS

Los datos binarios para contenido multimedia como imágenes o sonido son

almacenados en una base de datos como un binary large object (BLOb). Se pueden

utilizar dos técnicas para el manejo de datos binarios en aplicaciones JavaScript:

68

• Almacenar los nombres de los archivos en la base de datos y mantener los datos en

archivos separados.

• Almacenar los datos en la base de datos como BLObs y accesarlos con los métodos

de la clase Blob.

Si no es necesario mantener datos BLOb en una base de datos se pueden

almacenar los nombres de archivos en la base de datos y accesar estos archivos en la

aplicación con etiquetas HTML estándar.

Si se necesita manipular datos binarios en la base de datos, JavaScript reconoce

cuando el valor de una columna es BLOb. Cuando el software crea un objeto Cursor y

una de las columnas de la base de datos contiene datos BLOb este crea un objeto

Blob para el valor correspondiente en el objeto Cursor. Posteriormente es posible

utilizar los métodos del objeto Blo b para desplegar los datos.

El método blo bimage obtiene un BLOb desde la base de datos, crea un archivo

temporal del formato especificado y genera la etiqueta IMG que se refiere al archivo

temporal. El motor en tiempo de ejecución elimina el archivo temporal después de que

la página es generada y enviada al cliente.

El método blo bL i nk obtiene datos BLOb desde la base de datos, crea un

archivo temporal y genera una liga HTML hacia el archivo temporal. El motor en tiempo

de ejecución elimina el archivo temporal después de que el usuario hace click en la liga

o 60 segundos después de que la petición ha sido procesada.

69

5.13 PROCEDIMIENTOS ALMACENADOS

LiveWire proporciona dos clases para trabajar con procedimientos almacenados,

Stproc y Resul tset. Con los métodos de estas dos clases se puede llamar a un

procedimiento almacenado y manipular los resultados de tal procedimiento.

Los procedimientos almacenados funcionan en forma diferente en las varias

bases de datos soportadas por LiveWire. Un procedimiento almacenado puede ejecutar

una o más sentencias SELECT, recuperando información de la base de datos. Esta

información se recupera en forma de una tabla virtual, muy similar a un cursor de solo

lectura.

LiveWire utiliza una instancia de la clase Resul tset para contener las filas

regresadas por una sentencia SELECT de un procedimiento almacenado. Si el

procedimiento almacenado contiene múltiples SELECT se puede obtener un objeto

Resul tset por cada una de estas sentencias. Se debe utilizar el método resul tSet

de la clase Stproc para obtener un objeto Resultset y luego utilizar los métodos de

este objeto para manipular los resultados de la consulta.

Visto como una llamada a una función, un procedimiento almacenado puede

tener un valor de regreso. Para Oracle y Sybase existe un valor de regreso además del

conjunto de resultados. Puede usarse el método ret urnVa l ue de la clase Stproc

para accesar este valor. Sin embargo, los valores de regreso en lnformix son utilizados

para generar su conjunto de resultados. Por esta razón, ret urnVa l ue siempre

regresara un nulo en los procedimientos almacenados en lnformix. Además, estos

valores de regreso no están disponibles para OD8C y 082.

Los pasos para utilizar procedimientos almacenados difieren según la base de

datos:

• Registrar el procedimiento almacenado en las tablas del sistema apropiadas

(únicamente para 082).

• Definir un prototipo para el procedimiento almacenado (082, OD8C y Sybase

únicamente).

• Ejecutar el procedimiento almacenado.

• Crear un objeto resul tSet y obtener los datos de este objeto.

• Completar la ejecución accesando el valor de regreso (082, OD8C y Sybase

únicamente).

70

• Completar la ejecución obteniendo los parámetros de salida (082, OD8C, Oracle y

Sybase únicamente).

Para varias bases de datos se puede completar la ejecución del procedimiento

almacenado ya sea obteniendo un valor de regreso o accesando los parámetros de

salida. Una vez que se ha realizado cualquiera de estos dos pasos no se podrá trabajar

con los conjuntos de resultados creados en la ejecución del procedimiento almacenado.

Para ejecutar un procedimiento almacenado, el cual es un paso necesario en

cualquiera de las bases de datos mencionadas, se requiere la creación de un objeto

Stproc utilizando el método storeProc de los objetos database o Connection.

Cuando se crea un objeto procedimiento almacenado debe especificarse el nombre del

procedimiento así como los parámetros de este. Por ejemplo, si se tiene un

procedimiento almacenado llamado altas que utiliza seis parámetros, el siguiente

método crea el objeto procedimiento e invoca este procedimiento almacenado:

procedimiento= conexion.storedProc("altas", 3768953, "Pin k Floyd",

"Wi s h You Whe re Here", "CBS", 197 5 , 12. 99) ;

Cualquiera de las bases de datos soportadas por LiveWire necesitara también la

creación de un objeto resul tSet para recuperar la información desde un

procedimiento almacenado.

71

Al igual que para los objetos cursor, los objetos resul tSet tienen una fila

actual. Inicialmente, el apuntador es posicionado antes de la primer fila del conjunto de

resultados. Para obtener los valores de las siguientes filas se utiliza el método n e xt .

Conforme existan más filas en el conjunto de resultados, el método next regresa true

al avanzar a la siguiente fila. Cuando el apuntador sobrepasa la ultima fila este método

regresa false.

Una base de datos Oracle, Sybase, 082 u ODBC puede crear múltiples

conjuntos de resultados. En estos casos, los procedimientos almacenados

proporcionan un objeto resul tSet por cada uno.

72

6. CONCLUSIÓN

Todas las tecnologías analizadas permiten la realización de las operaciones

básicas en bases de datos: seleccionar una fuente de datos y conectarse a ella, enviar

una sentencia SQL para su ejecución, recuperar resultados, completar o cancelar la

transacción y desconectarse de la fuente de datos. Estas tecnologías proporcionan

además métodos para el manejo de transacciones y ejecución de procedimientos

almacenados. Sin embargo, existen también algunas características que podrían ser

decisivas al momento de elegir alguna de estas tecnologías.

Si el desarrollo de aplicaciones de bases de datos en Internet o una intranet

incluye diversas plataformas, o al menos no se desea utilizar la plataforma Windows

NT, se deberá considerar el uso de LiveWire o JDBC. LiveWire se encuentra disponible

actualmente para los sistemas operativos Digital UNIX, HP-UX, AIX, IRIX, Sun Solaris y

Windows NT. Por su parte, Java y JDBC están disponibles en las plataformas más

importantes. Java esta diseñado para soportar aplicaciones que puedan ser ejecutadas

en ambientes de red heterogéneos. En tales ambientes, las aplicaciones son capaces

de ejecutarse en varias arquitecturas hardware así como en diversos sistemas

operativos. Para realizar esto, el compilador Java genera bytecode, el cual es un

formato intermediario para transportar código a múltiples plataformas de hardware y

software [6]. ADO y OLE DB están actualmente limitados a la plataforma Windows NT.

Aunque esto significa que tanto el servidor Web como ADO y OLE DB deben estar

instalados en Windows NT, el servidor de la base de datos puede estar corriendo en

una computadora en cualquier otra plataforma o sistema operativo.

73

En lo que se refiere a aplicaciones a ejecutarse en el lado cliente la mejor opción

es el uso de JDBC en applets. Debido a que tanto el código del applet como el

controlador JDBC puede ser obtenido a través de la red, se puede lograr conectividad

con bases de datos sin ningún requerimiento ni instalación previa en el cliente más que

un visualizador basado en Java como el Netscape Navigator o el Internet Explorer.

ADO y OLE DB también pueden ser utilizados en el lado cliente pero esto solo seria

práctico en una intranet ya que requiere la instalación de ADO y OLE DB en cada

computadora cliente. Además, si se desea utilizar VBScript se deberá utilizar Internet

Explorer. Por su parte, los objetos asociados a LiveWire solo están disponibles en

JavaScript server-side por lo que no podrán utilizarse en el lado cliente.

Otro factor a considerar es el número de servidores Web con los cuales se

puedan utilizar estas tecnologías Web. Los servidores soportando servlets podrán

ejecutar aplicaciones JDBC. El número de estos esta aumentando y entre ellos

tenemos a Java Web Server, O'Reilly WebSite Professional V2 Server, Jigsaw 1.0beta1

y Netscape Enterprise Server. Los servidores soportando ASP podrán a su vez ejecutar

aplicaciones de bases de datos basadas en ADO y OLE DB. Actualmente los

servidores Internet lnformation Server y O'Reilly WebSite Professional V2 Server

soportan ASP. El medio ambiente en tiempo de ejecución de JavaScript server-side

solo esta disponible actualmente en los servidores Web Netscape Enterprise Server y

Netscape FastTrack Server por lo que LiveWire se limita a estos servidores.

Debido a que la gran mayoría de los servidores Web soporta CGI o alguna de

sus variantes, se puede aprovechar su uso en servidores en los cuales este es el

principal medio para ejecutar aplicaciones. Estos servidores podrán ejecutar

aplicaciones JDBC como programas CGI en cualquier plataforma en la cual Java este

disponible. Estos servidores podrán también utilizar ADO y OLE DB en programas CGI

pero su uso estará limitado a la plataforma Windows. Entre los servidores que no

proporcionan alguna tecnología de conexión a bases de datos se encuentran Apache y

NCSA. Según Netcraft, los servidores Apache conforman más del 49 por ciento de los

servidores actualmente conectados a Internet mientras que los servidores NCSA

conforman más del 2 por ciento [20].

74

En cuanto al número de bases de datos que cada tecnología puede accesar

ODBC puede conectar 55 bases de datos diferentes. JDBC cuenta actualmente con

controladores para las bases de datos más populares. Además JDBC puede utilizar su

ODBC bridge para realizar conexiones con bases de datos ODBC para las cuales aún

no existe un controlador JDBC disponible. Por otra parte, un gran número de empresas

han anunciado que han desarrollado o están desarrollando productos basados en

JDBC. Tanto LiveWire como ADO I OLE DB soportan servidores de bases de datos a

través de ODBC. LiveWire además soporta conexión por medio de controladores

nativos a bases de datos de Oracle, Sybase, lnformix y DB2. Además, si se planea

accesar datos no SOL, OLE DB esta diseñado para proporcionar acceso a cualquier

tipo de datos sin importar su tipo, formato o ubicación.

Indudablemente Java, y por tanto JDBC, cuenta con un mayor número de

herramientas para desarrollo de aplicaciones. Entre las más importantes tenemos a

Symantec Visual Café, Microsoft Visual J++, SunSoft Java Workshop y VisualAge for

Java. Visual Café for Java Database Development Edition incluye dbANYWHERE, el

cual es un servidor que soporta JDBC y proporciona controladores nativos para Oracle,

lnformix, Sybase y Microsoft SOL Server, además de soporte ODBC.

Por su parte, Netscape ofrece su Netscape SuiteTools que incluye Netscape

Component Builder y Netscape Visual JavaScript Pro. El Netscape Component Builder

incluye herramientas necesarias para construir componentes Java, JavaScript y

CORBA. Estas herramientas son Symantec Visual Café Professional Development

Edition, NetObjects JavaScript Bean Builder, Netscape Component Developer's Kit y

Netscape JavaScript Debugger.

Entre las herramientas de desarrollo de Microsoft se cuentan Microsoft Visual

Studio 97 el cual contiene Microsoft Visual Basic, Microsoft Visual C++, Microsoft Visual

J++, Microsoft Visual lnterDev y Microsoft Visual FoxPro. Estas herramientas permiten

el desarrollo de aplicaciones Web así como aplicaciones cliente/servidor tradicionales.

Microsoft Visual lnterDev proporciona soporte para páginas ASP y Dynamic HTML.

De las tecnologías comparadas, tanto JDBC como ADO I OLE DB pueden ser

también utilizadas en el desarrollo de aplicaciones cliente/servidor tradicionales lo que

crea un ambiente de desarrollo homogéneo en organizaciones donde deban coexistir

aplicaciones Web y aplicaciones tradicionales.

75

76

ANEXO A. LA ESPECIFICACIÓN CGI

A.1 INTRODUCCIÓN

El Common Gateway Interface (CGI) es un estándar para conectar aplicaciones

externas con servidores de información como los servidores Web. Un documento HTML

plano que el servidor de Web recupera es estático, lo que significa que existe en un

estado constante: un archivo texto que nunca cambia. Un programa CGI, por otra parte,

es ejecutado en tiempo real y por lo tanto puede proporcionar información dinámica

[21].

Ya que un programa CGI es ejecutable, es básicamente el equivalente de

permitir que cualquiera pueda ejecutar un programa en un sistema lo cual no es lo más

seguro de implementar. Debido a esto, existen algunas precauciones en cuanto a

seguridad que deben ser tomadas en cuenta con el uso de programas CGI. Una de

ellas es el hecho de que los programas CGI necesitan residir en un directorio especial

de tal forma que el servidor de Web pueda decidir cuando ejecutar el programa en

lugar de solo tratar de desplegar el archivo correspondiente en el visualizador. Este

directorio esta generalmente bajo el control del webmaster prohibiendo al usuario

normal la creación de sus programas CGI propios. Existen otras formas de permitir el

acceso a scripts CGI al resto de los usuarios también bajo el control del webmaster.

El directorio especial en el cual los programas CGI residen es denominado

/cgi-bin. Un programa CGI puede ser escrito en cualquier lenguaje que pueda ser

77

ejecutado en el sistema como por ejemplo C/C++, Fortran, Peri, Tel. cualquier she/1

UNIX, Visual Basic o AppleScript. Si se utiliza algún lenguaje de programación como C

o Fortran será necesario compilar el programa antes de que este pueda ser ejecutado.

El código fuente de estos programas, instalados en / cgi-bin, normalmente se

colocará en el directorio /cgi-src. Si se utiliza algún lenguaje de programación

basado en scripts, como Peri o algún she/1 de UNIX, el script mismo deberá residir en el

directorio / cgi-bin ya que este no tiene código fuente asociado. Los scripts CGI

generalmente son más fáciles de depurar, modificar y mantener que los programas

compilados.

A.2 FUNCIONAMIENTO DE CGI

Antes de que el servidor de Web ejecute el programa CGI prepara un conjunto

de variables de medio ambiente por medio de las cuales pasará información a este

último. Estas variables son como cualquier otra variable de medio ambiente y solo

duraran hasta que el programa CGI haya terminado, por lo que cada programa en

ejecución poseerá su propio medio ambiente. Por otra parte, si el programa es llamado

utilizando el método POST el servidor de Web utilizara la salida estándar para pasar

información al programa CGI [1].

El programa CGI posteriormente lee las variables de medio ambiente y, si fué

ejecutado utilizando el método POST, lee además la entrada estándar. Después realiza

la función para la que fué diseñado y escribe un encabezado MIME y su salida a la

salida estándar. El servidor de Web detecta que el programa CGI ha terminado, envía

la salida estándar de este al visualizador y cierra la conexión con este último.

Finalmente el visualizador despliega la salida estándar del programa CGI.

A.3 PASO DE INFORMACIÓN DEL SERVIDOR

Cada vez que un cliente hace una petición al URL correspondiente al programa

CGI el servidor de Web ejecutará este en tiempo real. La salida de este programa será

dirigida al cliente.

El servidor de Web utiliza las variables del medio ambiente para enviar

información a los programas CGI. Las dos variables más importantes para este

propósito son:

78

• QUERY STRING. Esta variable es definida como la cadena que sigue al primer signo

? en el URL. Esta información puede ser agregada principalmente por un

documento ISINDEX o por una forma HTML (usando el método GET). Esta cadena

es codificada en el formato estándar de URL intercambiando espacios por + y

codificando caracteres especiales en la forma hexadecimal %xx. Es necesario

decodificar esta cadena antes de ser utilizada. Si el programa no decodifica los

resultados de una forma HTML la cadena QUE RY _ STRING podrá ser decodificada

desde la línea de orden. Esto significa que cada palabra de esta cadena estará en

una sección diferente de ARGV. Por ejemplo, la cadena "Programa CGI" aparecerá

en el programa como a rgv [ 1] = " Programa" y a rgv [ 2 ] = "CG I" . Utilizando

este método no es necesario hacer un procesamiento de los datos antes de usarlos.

• PATH INFO. CGI permite el paso de información extra en el URL del programa CGI.

Esta información es normalmente disponible después de la vía de acceso del

programa CGI en el URL y no esta codificada. El ejemplo más útil del uso de esta

variable es transmitir ubicaciones de archivos al programa CGI.

Existen dos métodos por medio de los cuales los programas CGI pueden

accesar información enviada a través de las formas HTML. Estos son los métodos GET

y POST. Utilizando el método GET el programa CGI recibirá la entrada de la forma

HTML en la variable de medio ambiente QUERY _ STRING. Con el método POST el

programa CGI recibirá la entrada de la forma a través de la entrada estándar. El

servidor no envía un código de fin de archivo al final de los datos por lo que el

programa deberá utilizar la variable CONTENT _ LENGTH para determinar la cantidad de

datos que deberá leer de la entrada estándar.

79

A.4 ENVIO DE INFORMACIÓN AL CLIENTE

Los programas CGI pueden regresar diversos tipos de documentos. Ellos

pueden regresar una imagen al cliente, un documento HTML, un documento plano o

incluso un audio clip. También pueden regresar referencias a otros documentos. El

cliente debe saber que tipo de documento se le está enviando de tal forma que pueda

desplegarlo correctamente. Para que el cliente reciba esta información el programa CGI

debe indicarle al servidor que tipo de documento esta regresando.

Para indicar al servidor que tipo de documento se esta regresando, ya sea un

documento completo o una referencia a un documento, CGI requiere colocar un

pequeño encabezado en la salida. Este encabezado es un texto ASCII seguido por una

línea en blanco.

En el caso de un documento completo el programa debe indicarle al servidor que

tipo de documento será producido por medio de un tipo MIME. Los tipos MIME más

comunes son tex t / html para documentos HTML y tex t / plain para texto ASCII

plano. Por ejemplo, el siguiente código regresa un documento HTML de regreso al

cliente:

Con t ent - type: text/ h tml

<HTML>

<HEAD>

<TITLE>Salida HTML d e un pro grama CGI </TITLE >

</ HEAD>

<BODY>

<Hl > Salida HTML de un programa CGI</H l >

</ BODY></ HTML>

A.5 WINDOWS CGI

Bajo Windows NT es posible el paso de variables del medio ambiente en la

misma forma que en UNIX. Sin embargo, la programación CGI con algunos lenguajes

80

como Visual Basic utilizando variables del medio ambiente es difícil debido a que

algunas funciones que son utilizadas en aplicaciones CGI en UNIX no están disponibles

en estos lenguajes.

La interface DOS CGI fué el primer intento para implementar aplicaciones CGI

corriendo en servidores de Web en Windows. Debido a que Windows no tiene un

interprete de ordenes básico es necesario utilizar una sesión DOS para correr

programas CGI utilizando generalmente archivos por lotes o ejecutables DOS. La

principal desventaja de usar DOS CGI, además de las capacidades limitadas de los

archivos por lotes es que Windows tiene que crear una sesión DOS para cada petición

CGI. Esto significa que solo se puede tener un número limitado de sesiones DOS al

mismo tiempo, además de que esta técnica resulta en el uso de grandes cantidades de

memoria del servidor.

Windows CGI fué desarrollado por Bob Denny para corregir las limitaciones de

DOS CGI. Windows CGI utiliza ejecutables Windows en lugar de sesiones DOS.

Además, los datos del servidor al cliente y del cliente al servidor son pasados a través

de archivos de entrada y de salida en lugar de utilizar variables del medio ambiente. El

archivo de entrada tiene el mismo formato que los archivos de inicialización (.INI) de

Windows. Los archivos .INI comparten el mismo formato debido a que Windows

contiene servicios que permiten a los programadores leer y escribir estos archivos.

A.6 FASTCGI

FastCGI es una extensión de CGI cuyo objetivo es eliminar las desventajas de

CGI proporcionando un mejor desempeño y permaneciendo compatible con las

aplicaciones CGI existentes. Los procesos FastCGI son persistentes ya que son

reutilizados para manejar múltiples peticiones. Esto soluciona el problema de

desempeño de crear procesos nuevos por cada petición [22).

FastCGI es conceptualmente bastante similar a CGI. El servidor de Web crea

81

una aplicación FastCGI para manejar las peticiones. Este proceso puede ser creado ya

sea en un periodo de inicialización o al existir una petición. Cuando se recibe una

petición de algún cliente el servidor de Web abre una conexión con el proceso FastCGI.

El servidor de Web envía las variables del medio ambiente y la entrada estándar a

través de esta conexión. El proceso FastCGI envía la salida estándar y la información

de error de regreso al servidor utilizando la misma conexión. Cuando el proceso

FastCGI cierra la conexión la petición ha sido terminada. El proceso FastCGI espera

otra conexión del servidor de Web.

Las aplicaciones FastCGI pueden correr localmente o remotamente. Para

aplicaciones locales el servidor utiliza una tubería fu/1-duplex para conectarse con el

proceso FastCGI. Para aplicaciones remotas utiliza una conexión TCP.

82

GLOSARIO

API (Application Programming Interface). Conjunto de rutinas que una aplicación utiliza

para llevar a cabo servicios de bajo nivel.

Applet. Programa Java que puede ser obtenido a través de una red y ejecutado por un

visualizador.

Base de datos de escritorio. Base de datos diseñada para correr en una computadora

personal. Generalmente estas bases de datos no proporcionan un motor de bases de

datos por lo que tienen que ser accesados a través de un controlador basado en

archivos.

BLOB (Binary Large Object). Cualquier dato binario de un número de bytes grande.

Estos datos son enviados hacia y recuperados desde la fuente de datos generalmente

en partes.

Clase. Plantilla para objetos múltiples con características similares. Comprende todas

las características de una serie particular de objetos.

Cliente/servidor. Estrategia de bases de datos en la cual uno o más clientes accesa

datos a través de un servidor. Los clientes generalmente implementan la interface de

usuario mientras que el servidor controla el acceso a la base de datos.

Cursor. Pieza de software que regresa filas de datos de una aplicación. Un cursor en un

83

conjunto de resultados indica la posición actual del mismo.

Data Definition Language (DDL). Subconjunto de comandos SQL para la manipulación

de objetos de una base de datos. Sentencias SQL que definen los datos.

Data Manipulation Language (DML). Subconjunto de comandos SQL que manipulan los

datos.

Metadata. Datos que describen el tipo de funcionalidad que una base de datos

proporciona, por ejemplo, si soporta características SQL específicas, además de los

tipos de datos de esta.

Motor de base de datos. Software en una base de datos que analiza y ejecuta

sentencias SQL y accesa a los datos físicos.

Socket. Interface de comunicación abstracta construida a partir de capacidades de

streams.

X/Open. Compañía que publica estándares. En particular, publica estándares del SAG

(SQL Access Group) el cual a su vez es un consorcio de compañías relacionadas con

bases de datos SQL.

Webmaster. Administrador de sitios Web.

84

BIBLIOGRAFÍA

[1] National Center for Supercomputing Applications, "The Common Gateway Interface", http://hoohoo.ncsa.uiuc.edu/cgi.

[2) Pyung-Chul Kim, "A Taxonomy on the Architecture of Database Gateways for the Web", Chungnam National University, 1996.

[3) Oracle Corporation, "Oracle WebServer User's Guide", 1995.

[4] Henry F. Korth y Abraham Silberschatz, "Database Systems Concepts", McGraw-Hill, 1993.

[5] Dave Raggett, "HTML 3.2 Reference Specification", World-Wide Web Consortium, http://www.w3.org/pub/WWW/TR/PR-html32-961105, 1996.

[6] Sun Microsystems, "The Java Language Environment. A White Paper'', 1995.

[7] Netscape Communications Corporation, "Writing Server-Side JavaScript Applications", 1997.

[8] Netscape Communications Corporation, "JavaScript Reference", 1997.

[9] James R. Groff y Paul N. Weinberg, "Using SQL", McGraw-Hill, 1992.

[10) Graham Hamilton y Rick Cattell, "JDBC: A Java SQL API", Sun Microsystems, lnc., 1996.

[11) Graham Hamilton, Rick Cattell y Maydene Fisher, "JDBC Database Access with Java", Addison-Wesley, 1997.

[12) George Reese, "Database Programming with JDBC and Java", O'Reilly & Associates, lnc., 1997.

[13] Microsoft Corporation, "ODBC 3.0 Programmer's Reference".

[14) Microsoft Corporation, "OLE DB / ADO: Making Universal Data Access a Reality", http://www.microsoft.com/data/ado/sigmod98.htm.

[15J David Chappell, "Understanding ActiveX and OLE. A Guide for Developers and Managers", Microsoft Press, 1996.

[16) Microsoft Corporation, "Universal Data Access through OLE DB", http://www. microsoft. com/data/oled b/prod info/wpapers/wpapers. htm.

[17] lntersolv, "A Practica! Guide to ADO and OLE DB", http://www.oledb.com/oledb/guide.html.

[18] Joyce Chen y Richard Patterson, "ADO and SQL Server Developer's Guide", Microsoft Corporation, 1997.

[19] Microsoft Corporation, "Windows NT 4.0 Option Pack Documentation", 1997.

[20] Netcraft, "The Netcraft Web Server Survey", http://www.netcraft.co.uk/survey.

85

[21] D. Robinson, "The WWW Common Gateway Interface Versión 1.1 ", Internet Draft, University of Cambridge, 1996.

[22] Mark R. Brown, "Understanding FastCGI Application Performance", Open Market, lnc., 1996.

Análisis de tecnologías de bases de datos en el World Wide Web

Documents

Transcript of Análisis de tecnologías de bases de datos en el World Wide Web