Benemrita Universidad Autnoma de Puebla Facultad de Ciencias de la Computacin

Aplicaciones de Bases de Datos Cliente Servidor

Dr. Manuel Martn Ortz

marzo 2004

B D / C S : : 2 0 0 4 : : M M

Dedicatoria
Cada vez que alguien escribe algo que se expone a terceros, expone la manera en que ve las cosas y lo que espera del mundo. Hay quienes solo escriben una vez y es para despedirse de sus semejantes. Hay otros que no sabemos si escribieron y solo nos queda el recuerdo de ellos; de sus ideas, ilusiones, planes y dems cosas que todo el tiempo pensaron y pensamos, pero no saben ni sabemos si se cumplirn. Se puede dedicar a los vivos en cuerpo, a los vivos en recuerdo y a otras clases de vivos. Quiero dedicar este esfuerzo a alguien que al igual que muchos de los lectores de ste material se inici en los secretos y ardides de la programacin perdi ms de una vez la paciencia tratando de entender como resolver un problema no conoci la frontera entre la noche y el da muchas veces hasta hallar una solucin olvid la tarea el da de entrega a pesar de haberla hecho utiliz sus mejores oficios para satisfacer las exigencias de los dems emprendi la gran tarea de poblar nuestro planeta, al margen de conocer el maana construy una familia y amistades que a veces la entendieron y otras no sembr su simiente para no pasar desapercibida dibuj sonrisas, melancolas, tristezas y otros sentimientos sin quererlo muchas veces nos ha heredado sin decirlo la responsabilidad de ser mejores nos dej la tarea de continuar construyendo lo que no pudo hacer, pero pens nos dej caminando, soando y estando, sin poder replicar Para RITA de corazn (q.e.p.d). Abril de 2004 Manuel Martn Ortz

B D / C S : : 2 0 0 4 : : M M

Introduccin
Este material se ha desarrollado como gua de curso. Cubre los elementos bsicos tericos y prcticos acerca de Aplicaciones de Bases de Datos Cliente Servidor. El objetivo de ste material es mostrar los fundamentos para crear Aplicaciones de Bases de Datos en el Modelo Cliente servidor, en particular se har nfasis en el esquema concreto de Internet, el cual se puede reutilizar en una Intranet Corporativa. Para la parte prctica se utilizarn aplicaciones de corte libre robustas, multiplataforma, documentadas y de uso generalizado. Los captulos que comprende el material son los siguientes: 1. Introduccin al Modelo Cliente Servidor. En ste se explica el modelo, sus mecanismos de operacin y los procesos involucrados en la ejecucin de tareas. 2. Acceso Bases de Datos sobre la Web. Como contenido del tema se explican los detalles que deben ser contemplados en el modelo cliente servidor para el caso de las Bases de Datos, los aspectos especficos relativos a la seguridad y las metodologas clsicas de operacin. 3. Acceso a Bases de Datos Remotas con PHP/MySQL. En ste tema se hace un resumen de las

B D / C S : : 2 0 0 4 : : M M

CONTENIDO
DEDICATORIA........................................................................................................................................................... 2 INTRODUCCIN ....................................................................................................................................................... 3 CAPTULO 1. INTRODUCCIN AL MODELO CLIENTE SERVIDOR ........................................................... 5 1.1. INTRODUCCIN ..................................................................................................................................................... 5 1.2. COMR.....................................1R96 158.3(I1 ) 6(96 158. 0 T58. B......1 ) .... 0 T6.....2-109.9629(..........2....6 VA ) N..........249[ 96.12 595.560 O ( M) 1 -11.6( Tm R Tm0 ....0 .1 M-0 Tm-0 .5 0 2.5 0 Tc0 2 .Tc0 9 80 22N .9 80 256/TT 0 . 84 0 94.08 5911C)-10.E...

B D / C S : : 2 0 0 4 : : M M

Captulo 1. Introduccin al Modelo Cliente Servidor

El Modelo Cliente Servidor es una abstraccin que nos permite separar conceptualmente los mecanismos

B D / C S : : 2 0 0 4 : : M M

especialistas en Sistemas y Computacin dicha responsabilidad, esperndose de ellos que sean capaces de implementar soluciones en ste entorno. Para este fin es necesario conocer y saber manejar los fundamentos tericos - prcticos de los sistemas distribuidos y sus variantes, donde el esquema tradicional ms simple que resuelve esta clase de problemas son las Aplicaciones de Cmputo Cliente Servidor.

1.2. Componentes bsicas del Modelo Cliente Servidor

Una aplicacin cliente servidor se basa en el modelo de solicitud respuesta, el caso ms simple corresponde a la situacin en la cual una aplicacin (el cliente) solicita un recurso y otra (el servidor) la atiende para brindarle el servicio de ser posible. En el siguiente esquema (Fig. 1.1) se muestra dicho proceso.

Solicitud

Cliente

Servidor

Respuesta

Fig. 1.1. Modelo Simple de interaccin Cliente - Servidor

En los sistemas aislados se ha explotado este modelo para controlar y administrar algunos recursos, como ejemplo podemos citar algunos componentes del SO (Sistema Operativo): el administrador de procesos, el manejador de ventanas en ambientes orientados a ventanas en ambiente grfico y el gestor de medios de almacenamiento masivo (discos, duros, CDs, DVDs, etc.). Donde debemos recalcar que a pesar de tratar el caso de sistemas modernos monousuario, ya que stos ofrecen la opcin de la multitarea, es necesario controlar las acciones de los procesos que el usuario ejecuta en primer o segundo plano para evitar conflictos e inconsistencias. Para regular las relaciones entre el cliente y el servidor normalmente se definen reglas, las cuales se encapsulan en libreras que permiten la operacin entre las entidades involucradas. Estas reglas conforman los denominados protocolos de interaccin. Y los procedimientos pblicos habilitados para la interaccin se organizan en Interfaces de Programacin de Aplicaciones (API). Este binomio permite a los desarrolladores conocer como utilizar los mtodos de trabajo, las variables involucradas y sus tipos, as como el alcance y restricciones de explotacin. En los sistemas de cmputo conectados en red local (LAN) o en redes amplias (WAN), adems se deben tomar en cuenta las facilidades que el Sistema Operativo de Red (NOS) ofrece, as como las restricciones

B D / C S : : 2 0 0 4 : : M M

que impone. De aqu se puede inferir que es importante conocer y controlar no solo la dinmica de lo que sucede en cada nodo de la red, sino como se deben coordinar los diferentes nodos y medios de enlace entre ellos, es decir se deben considerar cada uno de los elementos involucrados en el sistema: locales, remotos e intermediarios. Un ejemplo de aplicacin cliente servidor corresponde a los denominados Sitios de Conversacin (Chat), analicemos su estructura general (Fig. 1.2): En la red se destina una mquina que sirve como nodo de confluencia para los usuarios, para lograr la funcionalidad deseada se instala un programa que recibe los textos de cada usuario y los publica colocando el alias de cada usuario como prefijo, este programa juega el papel de Servidor de Chat. En los nodos de los usuarios de instala otra aplicacin que enva los textos que escribe cada integrante del grupo al servidor y recibe una actualizacin del pizarrn comn cada vez que hay un cambio en l.
Usuario A (Cliente de Chat) Usuario B (Cliente de Chat) Usuario N (Cliente de Chat)

Servidor de Chat

Fig. 1.2. Modelo cliente servidor para un Chat

En el siguiente cuadro se muestran los procesos bsicos que se ejecutan durante la operacin del Chat.

T
T+0 T+1 T+2 T+3

Servidor
El programa inicia y espera a que se conecte algn cliente.

Cliente
El cliente inicia y el usuario enva un texto al servidor

El servidor recibe el mensaje y lo enva a todos los clientes conectados El cliente recibe una copia del pizarrn si hay cambios

Bajo este esquema cada vez que el servidor recibe un nuevo texto, dado que se produce un cambio en el pizarrn, se envan a los clientes activos los cambios y en consecuencia todos pueden leer lo que los dems escriben de manera local en sus terminales, incluyendo sus propios textos. Es lgico esperar que si el servidor se apaga o se desconecta de la red, entonces los clientes perdern contacto y para reanudarlo requieren que la rutina vuelva a comenzar. Este es uno de los cuellos de botella tpicos de los sistemas cliente servidor, cuando falla la aplicacin servidora o bien el enlace de red, el sis7

B D / C S : : 2 0 0 4 : : M M

tema estero falla, a pesar que los clientes estn arriba. Esto se debe a que la aplicacin es fuertemente dependiente de la parte servidora. Vamos a entender que las aplicaciones de esta clase se conforman al menos de tres partes:

El Servidor

El Enlace

El Cliente

Fig. 1.3. Elementos bsicos de un Sistema Cliente Servidor Donde en general puede haber muchos clientes operando, en este caso el servidor requiere emprender acciones de conciliacin, secuenciacin y bloqueo, entre otras, para que los clientes sean atendidos de manera oportuna y expedita.

Cuando en el sistema opera un solo servidor y un solo cliente se dice que tenemos una Aplicacin Cliente Servidor Simple. Este modelo se puede desarrollar incluso en una misma estacin de trabajo. En particular es el caso de una Manejador de Base de Datos (DBMS) que se ejecuta en una mquina y en la misma mquina se ejecuta un programa que interacta con el DBMS realizando una o varias tareas. En este modelo que llamaremos local, la aplicacin saca provecho de la capacidad de realizar transacciones del DBMS y se centra en la lgica requerida para resolver los problemas particulares del problema especfico. En general en ste enfoque la aplicacin brinda una interfase simpEn ( de73.92 0 TD-080201 Tc080321 Twinaamigacul1(b)c)-2le al [(u

B D / C S : : 2 0 0 4 : : M M

1.3. Elementos de Bases de Datos Distribuidas

En el procesamiento distribuido una mquina, conectada en una red local (LAN) o amplia (WAN) a otras mquinas, puede realizar una tarea de procesamiento de datos en ell-0.01930.0s1( )10(y s)6.3(obr)5s1(e el-0.019 r)5s1(e)-1.9

B D / C S : : 2 0 0 4 : : M M

a. Un cliente puede acceder a cualquier servidor, pero solo a uno a la vez. De tal forma que el cliente conoce donde debe solicitar la informacin. En este esquema no es posible combinar datos de dos o ms servidores en una misma peticin. b. El cliente puede acceder a varios servidores a la vez, de tal forma que una peticin de base de datos puede combinar informacin de varios servidores. Este modelo tiene la ventaja de que el usuario no tiene que saber en qu servidor se encuentran ubicados los datos. El soporte de una base de datos distribuida implica que las aplicaciones deben operar de manera transparente sobre los datos que estn dispersos sobre la red, donde es posible que los manejadores de BD locales (en cada servidor) utilicen una representacin diferente para los datos, es decir los DBMS no tienen que ser iguales, as como los Sistemas Operativos (SO) en cada servidor. Al referirnos a transparencia debemos entender que la aplicacin opera como si los datos fueran manejados por un solo DMBS y en una sola mquina donde reside un servidor virtual. Una caracterstica extra de este modelo es que un servidor puede atender a muchos clientes o bien servidores a la vez. Para que un sistema distribuido trabaje adecuadamente adems es necesario contar con un sistema de comunicaciones (red) robusto, estable y oportuno. Lo cual incluye un ingrediente ms a la arquitectura de los sistemas distribuidos. En la siguiente figura se muestra la topologa de los sistemas antes mencionados.

Fig. 1.4. Esquema de Arquitecturas Centralizada (izquierda) y Distribuida (derecha). El principio fundamental de una Base de Datos Distribuida (BDD) es que: Ante un usuario, un sistema distribuido se comporta exactamente igual que uno no distribuido. Entonces los problemas de los sistemas distribuidos son problemas internos o en el nivel de implementacin, y no externos o en el nivel del usuario [2: cap. 20]. Los sistemas de BDD operan sobre 12 reglas u objetivos interrelacionados, a continuacin se presenta un resumen de estos, para mayor detalle ver [2: cap. 20, secc. 3]. 1. Autonoma local. Los sitios deben ser autnomos, es decir las operaciones en un sitio X estn controladas por l; de tal suerte que la operacin satisfactoria de X no depende de otro sitio Y. Es-

10

B D / C S : : 2 0 0 4 : : M M

to implica que los datos locales son propiedad del sitio y son administrados por l. Debido a esto la seguridad, integridad y representacin de almacenamiento de los datos locales permanecen bajo

11

B D / C S : : 2 0 0 4 : : M M

pueden realizar varias transacciones de forma concurrente en diferentes sitios, los agentes se encargarn de realizar las transacciones en cada sitio representando la transaccin original del usuario. 9. Independencia del hardware. Esta regla define que debe ser posible ejecutar el mismo DBMS en diferentes plataformas de hardware, de tal manera que cada mquina participe como un socio igualitario ene l sistema distribuido. 10. Independencia del Sistema Operativo. Este criterio implica que cada sitio puede funcionar con

12

B D / C S : : 2 0 0 4 : : M M

Donde en los servidores (S) se encuentran los datos y su correspondiente DBMS y en los clientes (C) las aplicaciones o interfases. Podemos definir un Sistema CS mediante las siguientes reglas [3]:

Modelod5

cial

7]TJ3TJ18.44 y

86

TD0.002147

local

51124acionx

13

B D / C S : : 2 0 0 4 : : M M

En el primero modelo, el cliente juega el papel de manejar la interfase de la aplicacin simplemente y la lgica de la aplicacin y el DMBS residen en el servidor. En el segundo caso la lgica de la aplicacin se comparte entre el cliente y el servidor; y en el ltimo caso la lgica de la aplicacin se localiza en el lado del cliente. Esta divisin del trabajo imprime las siguientes caractersticas dependiendo donde se ubica la lgica de la aplicacin:. En el lado del Cliente La semntica est dividida entre los programas Cada programa solo maneja un parte del problema Los controles estn embebidos en el cdigo de los programas Existen fuertes problemas de mantenimiento, duplicidad de esfuerzos y de integridad

En el lado del Servidor La lgica est centralizada y en general es consistente Aumenta la seguridad e integridad Algunos controles se pueden expresar de manera simple en SQL y otros pueden ser rutinas complejas (procedimientos almacenados) Aumenta el trabajo en el servidor y su complejidad

2. Modelo de tres capas. En este modelo se separa la lgica de la aplicacin de la interfase ubicada en el lado del cliente y del DBMS situado en el lado del servidor. El esquema se muestra en el diagrama adjunto. Este modelo se aplica en los siguientes casos: Cliente: Interfase a. Cuando se ofrecen muchos servicios en el lado del server. b. Si las aplicaciones que se ejecutan en el server se operan con diferentes lenguajes (tipo intrprete). c. Se manejan sistemas de BD heterogneos. d. Hay muchas transacciones por unidad de tiempo. e. Hay muchos usuarios conectados simultneamente. f. Existe mucha comunicacin entre las aplicaciones.

Lgica de la Aplicacin

Servidor: DBMS

14

B D / C S : : 2 0 0 4 : : M M

3. Modelo de N capas. Este esquema se utiliza principalmente cuando la operacin se realiza mediante la colaboracin de varios servidores de software en el lado del server o bien los clientes acceden a varios servicios segn sea su necesidad. En el siguiente diagrama se muestra un ejemplo de esta arquitectura: Cliente Cliente Cliente Interfases Red
Servidor de WEB Servidor de FTP Servidor de Aplicaciones

Lado de server
Servidor de Aplicaciones

Servidor DBMS

BD

Fig. 1.5. Esquema del Modelo de N capas. Este modelo se utiliza cuando se tiene una arquitectura compleja compuesta por varios servicios serializados que de manera conjunta resulten algunos problemas especficos. Tenemos como ejemplos de esta arquitectura: x x x Sistemas de acceso a BD mediante interfases WEB. Sistemas que utilizan Proxies y Firewalls. Sistemas de manejo remoto de archivos con derecho a ejecucin.

15

B D / C S : : 2 0 0 4 : : M M

Captulo 2. Acceso a Base de Datos sobre la Web

En ste captulo se presentarn los conceptos y elementos que permiten crear aplicaciones que acceden a Bases de Datos usando un cliente de Web como interfase.

2.1. Arquitectura de una Aplicacin Web con acceso a BD.

Utilizando los conceptos de las arquitecturas cliente servidor podemos decir que una aplicacin de base de datos que utiliza a un navegador de Web (browser) como interfase para acceder a una BD, la cual puede realizar diferentes tareas en general, corresponde a un modelo de 3 capas. El esquema operativo de dicho modelo se presenta a continuacin (Fig. 2.1).

Cliente

Cliente

Cliente

Cliente

16

B D / C S : : 2 0 0 4 : : M M

En el modelo se puede observar como diferentes clientes (parte superior) acceden mediante un navegador a la red y realizan un operacin sobre una BD que se encuentra en algn server (parte inferior). Quin re-

17

B D / C S : : 2 0 0 4 : : M M

Como ncleo de ste paradigma hay tres conceptos clave: URL, HTTP y HTML. Comentemos cada uno de ellos para aclarar la situacin. 2.2.1. URL La manera en que se buscaba informacin en Internet en sus inicios era bastante compleja, ya que las interfaces eran de texto simple y uno deba conocer muy bien el terreno para realizar las tareas de consulta y recuperacin de informacin. Para simplificar el proceso se introdujo un esquema llamado URL (Uniform Resource Locator) o localizador uniforme de recursos, ste permite localizar de manera unvoca un documento dentro de la red. Su estructura es tcnicamente simple: protocolo://servidor[:puerto]/ruta/recurso donde, protocolo : indica que protocolo (conjunto de reglas para que una aplicacin se coordine con otra para realizar alguna tarea) se utilizar para la comunicacin. servidor : se refiere a la direccin ip o por nombre del equipo al cual uno se desea conectar. puerto : indica un puesto alternativo al estndar para realizar la conexin. Normalmente se definen puertos por defecto para hacer la conexin, pero es posible configurar los servicios en otros puertos para crear ambientes con privacidad, seguridad o bien habilitar varias instancias de servidores de la misma clase que atienden servicios especializados y dedicados. indica la ruta en el rbol de directorios del nodo base del servidor. En general se define un sitio por defecto que funge como nodo raz de la aplicacin y a partir de ste se puede construir una estructura de archivos que facilite la administracin de la informacin y restringa en caso necesario el acceso a la misma por parte de los usuarios. Esto permite introducir mecanismos de privacidad y seguridad. hace referencia al archivo que se desea acceder. Y dependiendo del protocolo utilizado se realizar la tarea correspondiente con l.

ruta:

recurso:

Los protocolos primitivos en Internet que operan bajo ste esquema son los siguientes: Protocolo ftp malito news telnet http Descripcin File Transfer Protocol: Tiene como propsito la transferencia de archivos. Se utiliza para envo de correo electrnico. Sirve para la lectura de noticias (news) sobre USENET. Habilita establecer sesiones de trabajo remotas. Hiper Text Transfer Protocol: Permite la transferencia de hipertexto.

18

B D / C S : : 2 0 0 4 : : M M

Por ejemplo para solicitar el archivo plan.html ubicado en la carpeta /users/paco del servidor www.ps.uar.mx en el puerto 8010 usando el protocolo http, el URL correspondiente tendr la forma: http://www.ps.uar.mx:8010/users/paco/plan.html. 2.2.2. Protocolo HTTP Este es un protocolo de aplicacin de la suite TCP/IP, probablemente el ms utilizado en la navegacin sobre Internet, ste enva los datos como texto ASCII, por debajo del protocolo HTTP debe haber una conexin TCP segura entre el cliente y el servidor cada vez que se realice un intercambio de datos. Por defecto el puerto de enlace es el 80 como punto de conexin. El protocolo HTTP consiste de dos elementos: el grupo de solicitudes de los visualizadores a los servidores y el grupo de respuestas en sentido inverso [4: cap. 7, pag. 690-691]. Grupo de solicitudes. Todas las versiones de HTTP reconocen dos tipos de solicitud: sencillas y completas. Una solicitud sencilla es una sola lnea GET que nombra la pgina deseada, sin la versin del protocolo. La respuesta es una pgina en bruto, sin cabecera, sin MIME y sin codificacin. Una solicitud completa se indica por la presencia de la versin del protocolo en la lnea de solicitud del GET. Las solicitudes puedes consistir en mltiples lneas, seguidas de una lnea en blanco que indica el final de la solicitud. La primera lnea de una solicitud completa contiene el comando (por ejemplo GET), la pgina deseada y el protocolo con su versin. Grupo de respuestas. Una respuesta simple puede ser una lnea simple que indica el resultado de la peticin o un error de acceso. Y una respuesta completa es un conjunto de lneas que contienen una pgina Web y sus encabezados para ser correctamente interpretada. Acerca de las MIME. Cuando se crearon las primeras aplicaciones de correo electrnico, los mensajes es simples archivos de texto en ingls en ASCII restringido (7 bits). Este modelo limitaba las posibilidades para mandar mensajes en otros idiomas, por ejemplo aquellos que requieren de acentos (espaol, francs y alemn), idiomas que no estn basados en caracteres latinos (ruso, hebreo y rabe), idiomas carentes de alfabeto (chino y japons) y mensajes que no contienen texto (imagen, audio o video). Se propusieron varias soluciones que se estn sintetizadas en los RFC (Request For Coment) 1341 y 1521. Esta solucin llamada MIME (Multipurpose Internet Mail Extensions extensiones multipropsito de correo Internet) propone mantener la compatibilidad de los mensajes de correo especificados en el RFC 822, pero agrega una estructura al cuerpo de los mensajes y define reglas de codificacin para los mensajes no ASCII. Para interpretar de forma adecuada los mensajes se debe especificar de que MIME se trata y utilizar programas transmisores y receptores adecuados a cada MIME. El MIME define 5 nuevas cabeceras para los mensajes, stas son: Mime-Version: la cual identifica la versin del MIME; Content-Description: que es una cadena de texto que describe el contenido; Content-Id: que es un identificador nico; Content-Transfer-Encoding: Indica como se ha codificado el mensaje (envoltura) para su transmisin; y Content-Type: se refiere a la naturaleza del mensaje. En general cualquier mensaje que no contenga una cabecera MIME-Version se debe interpretar como un mensaje de texto normal en ingls [4: cap.7 pag. 650 - 657].

19

B D / C S : : 2 0 0 4 : : M M

El protocolo HTTP fue diseado para usarse en la Web, pero en su modelo se encuentra la filosofa de la Orientacin a Objetos. Un elemento que refleja ste hec

20

B D / C S : : 2 0 0 4 : : M M

Campo URI

Descripcin Identificador Universal del Recurso (Universal Resource Identifier). Especifica la ruta y el nombre del objeto que desea recuperar.

21

B D / C S : : 2 0 0 4 : : M M

Como puede verse la informacin que viene en la peticin permite identificar al usuario, el sitio donde esta conectado y otros parmetros que sern importantes cuando se produzca la respuesta. Por otro lado debemos citar las posibles respuestas del servidor al cliente, la primera corresponde a una pgina o recurso existente, en este caso el objeto es enviado al cliente precedida por el protocolo, su versin y el cdigo 200 OK que indica xito, en general podra haber mas elementos en la cabecera de respuesta. La sintaxis de una respuesta tiene la forma: Protocolo/Versin Estado Descripcin [cabecera general | cabecera de respuesta | cabecera entidad] [cuerpo de la entidad] La tabla siguiente presenta un resumen de Estados de una respuesta: Cdigo 200 201 202 204 301 302 304 400 401 403 404 500 501 502 503 Descripcin Accin realizada con xito. Se devuelve despus de enviar un POST cuando el documento se ha creado con xito. Se ha recibido la consulta, pero se ejecutar mas tarde. Accin realizada con xito, pero no se devuelve algn objeto. El objeto solicitado est en otro lugar en el servidor, se regresa la nueva direccin del objeto El objeto solicitado se encuentra temporalmente en la direccin indicada en la respuesta. Respuesta a una solicitud GET cuando no se regresa algn objeto debido a que no existe una nueva versin de l. Error de sintaxis en la peticin del cliente. Se necesita una identificacin por parte del cliente, ya que est ausente. Acceso denegado para el objeto solicitado. El recurso solicitado no est en el servidor. Error interno del servidor. El servidor no acepta la accin especificada. Este cdigo lo regresa un Proxy o Gateway cuando el servidor al que se ha dirigido la solicitud no responde. El servidor no puede responder por estar sobrecargado de trabajo. Tabla 2.4. Cdigos de Estado enviados por el servidor La cabecera general puede ser de dos tipos: Date: Indica la fecha en la que se cre la consulta enviada por el cliente, pe. Date: Sun, 18 Apr 2004 20:55:03 GMT Pragma: Inicia el intercambio de informacin de datos entre el cliente y el servidor no estandarizados y especficos del programa, pe. Esta directiva solicita el archivo original y no el que se encuentre en el cach del servidor. Pragma: no-cache
22

B D / C S : : 2 0 0 4 : : M M

Las cabeceras de respuesta permiten enviar informacin complementaria que la que aparece en la lnea de estado. Hay cuatro tipos: Location. En este campo el servidor indica la nueva direccin del recurso solicitado por el cliente. Server: Indica el nombre y versin del programa que opera como servidor de HTTP. Content-Language. El servidor muestra al cliente el idioma en el que est escrito el documento solicitado. WWW-Authenticate. Este campo aparece junto al cdigo de respuesta 401, cuando el servidor solicita al cliente que se autentique. La cabecera de entidad muestra informacin adicional sobre el cuerpo de la entidad o sobre el recurso, existen siete tipos: Allow. Indica el conjunto de mtodos de peticin admitidos por el servidor. Content-Encoding. Indica la codificacin utilizada en el objeto referenciado. Content-Length. Indica el tamao en bytes del documento anexo en el cuerpo de la solicitud. Content-Type. Tipo de documento enviado segn un MIME. Expires. Indica la fecha y hora a partir de la cual el objeto entregado deja de tener validez. Last-Modified. Indica la fecha de la ltima vez en que se modific el recurso solicitado. Y finalmente el cuerpo de la entidad que es opcional (cuando no hay respuesta por ejemplo est ausente) contiene los datos solicitados por la aplicacin cliente. Para mayor informacin se pueden consultar los RFC 1945 para el protocolo HTTP/1.0 y el RFC 2068 para el HTTP/1.1. 2.2.3. Lenguaje HTML Este es un lenguaje para la composicin de documentos y especificacin de ligas de hipertexto que define una sintaxis adaptada al Web. Esta basado en el estndar ISO 8879 que corresponde al SGML (Standard Generalized Markup Language : Lenguaje de Marcas Estndar Generalizado). Los modelos de descripcin de documentos se crearon como base de los procesadores de texto y tienen como propsito indicar la manera en que los documentos sern presentados por parte del visualizador y eventualmente por los subsistemas de impresin. Un lenguaje que ha sido ejemplo persistente es TEX creado por Donald Knuth para crear documentos cientficos y sus Macro Lenguajes asociados como es LATEX. El elemento central de stos lenguajes es la marca, sta indica la manera en que una palabra, prrafo o grupo de lneas ser tratado. Normalmente los documentos se escriben en ASCII con herramientas simples y son interpretados por un visualizador, en el caso del Web el visualizador es el Navegador de Web. En el caso de HTML se incluyen marcas para incluir ligas (links) a otros documentos o recursos que no son de tipo texto, de tal manera que no se habla de documentos sueltos, sino de grupos de documentos
23

B D / C S : : 2 0 0 4 : : M M

organizados en un grafo navegable a travs de las ligas. Esto produce un concepto de nivel superior, el cual permite describir documentos estructurados como lo son: Libros, Manuales y Propaganda. Las ligas que permite incluir HTML habilitan la navegacin dentro y fuera de un servidor, es decir la informacin en general est distribuida en un conjunto de servidores. Esto marca el modelo como un modelo por excelencia distribuido desde el punto de vista de la computacin. El lenguaje HTML se ha estandarizado para que los desarrolladores de Navegadores ofrezcan a sus usuarios una interfase regular y compatible. La organizacin que define sta norma es un consorcio formado por instituciones privadas y pblicas [5]. Este esfuerzo es parte de un grupo ms amplio conocido como Grupo de Trabajo de Ingeniera de Internet (IEFT) [6], el cual no solo norma al HTML sino define y administra cada aspecto de la tecnologa asociada a Internet., los documentos ofiales que ste grupo genera se denominan RFC (Request For Comment), estos se numeran y se publican en el sitio oficial del Grupo. Actualmente la versin liberada del Lenguaje HTML es la 4.0 y es utilizada por la mayora de los Navegadores de Web. Existe una amplia gama de literatura relacionada con este lenguaje [7,8], en particular se puede visitar un pequeo tutorial creado en la FCC [9]. Las extensiones para los archivos HTML son htm y html y se crean y modifican con un editor ASCII simple o mediante herramientas visuales especializadas, pero debe recordarse que en todos los casos el archivo debe ser salvado como ASCII simple. Entrando en detalle podemos decir que un documento en HTML se compone de dos partes: la cabecera y el cuerpo. La primera se engloba entre las etiquetas <head>cabecera<</head> y el cuerpo se identifica por estar contenido entre las etiquetas <body>cuerpo</body>. De tal suerte que la cabecera y cuerpo se enmarcan entre las etiquetas <html> y </html>. El lenguaje HTL no distingue entre maysculas y minsculas al manejar sus etiquetas, pero algunos elementos si pueden ser dependientes del tipo, principalmente la inclusin de archivos en el caso de operar sobre SO que hacen la distincin como es el caso de UNIX y sus implementaciones (Linux, AIX, HPUX, IRIX, etc.).

Originalmente HTML se diseo junto con los servidores de Web y sus correspondient

24

B D / C S : : 2 0 0 4 : : M M

A pesar que ese fue el diseo original surgi la necesidad de que el servidor no solo regresara pginas de Web planas y estticas, sino que tuviera la capacidad daeregresara gi7.87id]TJ19.6(60 TD-0.01987Tc0.04827[(ds)6. c)om

25

B D / C S : : 2 0 0 4 : : M M

2.3. Estndares de interaccin.

En general uno puede recurrir a cualquier mecanismo para realizar la comunicacin entre el cliente y el servidor, y luego entre el servidor y el DBMS. El nivel ms bajo para la primera fase se puede hacer utilizando sockets sobre TCP/IP, pero no es en general una alternativa sencilla de implementar puesto que se requiere conocer su funcionamiento detallado y adems para cada problema se debe crear una pareja de aplicaciones: una en el lado del cliente y otra en el lado del servidor. Este modelo prevaleci por muchos aos habilitando a los desarrolladores ofrecer soluciones, pero con el conocido crecimiento de Internet se aprovech su estandarizacin y se crearon modelos que requiriesen menos esfuerzo y fueran independientes de los SOs, las plataformas fsicas es decir se creo una corriente de simplificacin y las particularidades de los problemas. Esto fue unificando los esfuerzos corporativos e institucionales y ha llevado a varias propuestas operativas transparentes y sencillas de manejar, donde se ha incluido la interaccin con los DBMS. Ocasionando que las pocas en las cuales cada compaa ofertaba la mejor solucin se redujese y se normalizarn los mecanismos, permitiendo la interoperatividad entre plataformas fsicas y lgicas, lo cual es uno de los imperativos de los Sistemas Distribuidos. Dentro del esquema se considera el hecho que en la mayor parte de los sistemas de cmputo que se utilizan ya incluyen Navegadores de Web, lo cual ofrece de manera directa una parte de la solucin, es decir la Interfase de Usuario, de donde slo resta regular el resto de mecanismos. Con esto debemos entender que ya no ser necesario escribir programas dedicados en el lado del cliente, que deban ser distribuidos y actualizados, sino que se aprovecha el Navegador y sus caractersticas para montar sobre l las interfases de usuario. Esto reduce de manera natural los costos, los problemas de distribucin y de mantenimiento del software. Con la adopcin de la idea de forma masiva, diversas compaas y grupos de trabajo han creado aplicaciones con sus mecanismos de instalacin, operacin y distribucin correspondientes. Podemos decir que el modelo es el mismo, pero existen alternativas para implantar ste tipo de soluciones. Cada caso tiene sus bemoles y no se debe hacer a un lado, ms bien se debe contemplar como lo que es: una opcin. A continuacin se hace un resumen de diferentes modelos, el cual no agota la variedad de soluciones que hay.

2.4. Categorizacin de la interfaces Web/DBMS

Las aplicaciones de usuario para la interaccin de bases de datos con el Web son simplemente modelos del ambiente cliente/servidor, con una capa adicional para crear resultados HTML que puedan ser visualizados a travs del Navegador de Web, por medio del procesamiento de los datos obtenidos en la forma que han sido introducidos por el usuario/cliente. Adems, al usar estas interfaces se puede crear el programa principal de la aplicacin. Como puede observarse, estas herramientas permiten construir poderosas aplicaciones en el Web, pero se requiere que programadores experimentados logren un desarrollo a gran escala. Tambin, el mantenimiento de las mismas es significativamente ms complejo y extenso. Una de las estrategias bsicas para la creacin de aplicaciones de interaccin con el Web, es la de descargar del Web aplicaciones o componentes funcionales que se ejecutarn dentro del Navegador (plugins). Con ellas se realiza un procesamiento complejo del lado del cliente, lo cual requiere un gran esfuerzo para crear las componentes de la aplicacin. Estas estrategias poseen dos caractersticas principales: garantizan la seguridad tanto en los sistemas de distribucin como en la comunicacin que se establece con tales aplicaciones, a travs de Internet.

26

B D / C S : : 2 0 0 4 : : M M

Tambin han aparecido bibliotecas que incluyen motores propios en el lado del servidor que corren de forma conjunta con el Servidor de Web, lo cual facilita el desarrollo de nuevas aplicaciones. Una aplicacin que posibilita interconectar al Web con una base de datos tiene muchas ventajas, adems de que las funciones que cumplen actualmente los Servidores Web y las herramientas de desarrollo de aplicaciones Web, hacen ms fcil que nunca la construccin de aplicaciones ms robustas. Tal vez el mayor beneficio del desarrollo de estas aplicaciones en el Web sea la habilidad de que funcionen para plataformas mltiples, sin el costo de distribuir mltiples versiones del software como se mencion anteriormente. Cada una de las interfaces para comunicar al Web con bases de datos, ha sido creada basndose en una tecnologa de integracin especial, a travs de procesos de interconexin especiales. Cuando se utiliza una interfaz para lograr la integracin del Web con cierta base de datos, se puede verificar que los procesos seguidos varan, dependiendo de la tecnologa que se est utilizando. Entre estas tecnologas se tienen las siguientes [11]: 2.4.1. El Common Gateway Interface (CGI) Actualmente, sta es la solucin que ms se est utilizando para la creacin de interfaces Web/DBMS. Fue probada por primera vez en el servidor que distribuye de manera gratuita la NCSA. Se ha comprobado que si el Servidor Web recibe un URL con una solicitud, para devolver un documento HTML como respuesta, tendr que cargar el servicio (programa) que le indique las variables de ambiente y de la forma HTML. La mayora de las veces dicha llave es el "cgi-bin". Entre las ventajas de la programacin CGI, se tiene su sencillez, ya que es muy fcil de entender, adems de ser un lenguaje de programacin independiente, ya que los escritos CGI pueden elaborarse en varios lenguajes. Tambin es un estndar para usarse en todos los servidores Web, y funcionar bajo una arquitectura independiente, ya que ha sido creado para trabajar con cualquier arquitectura de servidor Web. Como la aplicacin CGI se encuentra funcionando de forma independiente, no pone en peligro al servidor, en cuanto al cumplimiento de todas las tareas que ste se encuentre realizando, o al acceso del estado interno del mismo. Pero el CGI presenta cierta desventaja en su eficiencia, debido a que el Servidor Web tiene que cargar el programa CGI: luego conectarse y desconectarse con la base de datos cada vez que se recibe una requisicin. Adems, no existe un registro del estado del servidor, sino que todo hay que hacerlo manualmente. 2.4.2. Interfaz de Programacin de Aplicaciones (API) Es un conjunto de rutinas, protocolos y herramientas para construir aplicaciones de usuario. Una buena API hace ms fcil el trabajo de desarrollo de un programa, ya que debe proveer componentes bien documentados y estables para construirlo. El programador lo nico que hace es poner todos los bloques en el orden que se requieran en base a un diseo particular. Las APIs estn diseadas especialmente para los programadores, ya que garantizan que todos los programas que la utilizan, tendrn interfaces similares. Asimismo, esto le facilita al usuario aprender la lgica de nuevos programas y las especificaciones bsicas en los manuales de usuario se reducen.

27

B D / C S : : 2 0 0 4 : : M M

Cuando se realiza una requisicin, el servidor llamar al API, brindando la ventaja de disponer de una mayor cantidad de servicios. Y cuando estas se organr6( or) 0 8.04 306 0.2(icidt or) Brbliotce sgaLDL.)de d8(a.12 T019

28

B D / C S : : 2 0 0 4 : : M M

cio solicitado. Uno de los programas ISAPI ms usados es el HTTPODBC.DLL que se usa para enviar

29

B D / C S : : 2 0 0 4 : : M M

Las aplicaciones clsicas proveen de informacin acerca de los tipos de formato (tipos MIME). Los browser del Web rpidos son capaces de aprender cmo tratar con nuevos protocolos y dar formato dinmicamente a los datos.

Seguridad
Java est diseado para proveer la mxima seguridad posible en redes pblicas, con mltiples formas de seguridad ante virus, posibles invasiones o accesos incorrectos y archivos basura. Java debe entenderse que opera como C++, es decir es un Lenguaje Orientado a Objetos completo, en la cual se puede causar cualquier dao. Es funcional como C y modular como C++.

Conectividad de Bases de Datos de Java (JDBC)

Se considera el primer producto estndar de Java con capacidades de un DBMS, creado y ofrecido por primera vez en marzo de 1996. JDBC ofrece una interfase de programacin que permite comunicarse con las bases de datos mediante un concepto similar al de componentes ODBC, el cual se ha convertido en el estndar que se utiliza en computadoras personales o en redes locales. El estndar de JDBC est basado en un nivel de interfase con instrucciones SQL X/Open, que es bsicamente lo mismo que en ODBC. Las clases de objetos para iniciar la transaccin con la base de datos, estn escritas completamente en Java, lo cual permite mantener la seguridad, robustez y portabilidad de este ambiente. El puente JDBC-ODBC manipula la traduccin de llamadas JDBC a aquellas que puedan ser entendidas por el cliente ODBC a un nivel de lenguaje funcional. 2.4.5. JavaScript Es un lenguaje muy poderoso y especialmente diseado para la creacin de scripts (programas que operan en un ambiente interpretado), que se alojan dentro de un documento HTML. Dicho lenguaje es creacin y propiedad de la compaa Netscape, la cual distribuye un Navegador de cdigo abierto. Es un API programable que permite crear scripts para el manejo de eventos, objetos y acciones, bajo cualquier plataforma. Gracias a que JavaScript es parte de la conexin en vivo, se puede usar para construir formas interactivas entre documentos HTML, Plug-ins (aplicaciones que corren dentro del browser del Web) y Java. Las conexiones en vivo habilitan: x x Navegacin con Plug-ins, que se cargan en una pgina para interactuar con JavaScript y se encuentran activos dentro de la misma pgina. Aplicaciones de Java cargadas en la misma pgina para comunicarse con los scripts hechos con JavaScript activos dentro de la misma pgina, y viceversa.

Mediante el uso de JavaScript se pueden enviar respuestas ante una variedad de eventos, objetos y acciones, permitiendo cambiar imgenes o activar sonidos ante determinados eventos, tales como entrar o salir de una pgina y sensar los eventos del ratn como medio de la interfase de usuario (GUI). JavaScript es un lenguaje compacto, basado y orientado a objetos, para el desarrollo de aplicaciones Internet Cliente/Servidor. Las instrucciones JavaScript que reconocen y responden ante eventos, pueden ser introducidas directamente en una pgina Web. Por ejemplo, se puede escribir una funcin JavaScript que

30

B D / C S : : 2 0 0 4 : : M M

verifique la correcta entrada de datos a una forma, sin necesidad de transmisin de datos a travs de la red. As, una pgina HTML con cdigo JavaScript pu.4(.)11arna0.48(te]TJ021.220 TD00.01214Tc0.04514Tc[(Arpr)-2.9(et)-351 Bdisponiblesden el m11.48ern 10(aL principal n11.41.)1.71verd4(.)8adde d10(aes]TJ02.0430 TD00.0119

31

B D / C S : : 2 0 0 4 : : M M

Oracle soporta clientes/servidores con entornos heterogneos, donde cliente y servidor pueden usar diferentes juegos de caracteres. El juego de caracteres de cada cliente es definido por el valor de la variable NLS_LANG de su sesin. Para facilitar la conexin entre las bases de datos individuales de una base de datos distribuida, Oracle usa database links, los cuales definen trayectorias (paths) a las bases de datos remotas. 2.4.7. Cold Fusion Este modelo para el manejo de bases de datos sobre Internet introdujo un concepto revolucionario, ste consisti en extender al Lenguaje HTML, de tal manera que dentro de su cdigo se incluyesen instrucciones para el manejo de las BD. Posteriormente muchas compaas y grupos tomaron este camino. Cold Fusion centra su potencialidad en la confiabilidad y el control del manejo de datos. Reconoce la complejidad del manejo e interaccin de escritos CGI, ofreciendo una potente seguridad, veloz carga de datos, procesamiento rpido de escritos CGI que posibilita el cumplimiento de tareas de entrada o devolucin de datos [11]. Utiliza fuentes de datos ODBC de 32-bits, las cuales debern cumplir con el nivel 1 de los ODBC API y soportar las sentencias SQL. Entre las funciones de Cold Fusion estn:
x

Sirve a cualquier requisicin de datos una vez cuente con la instalacin y configuracin de las fuentes de datos ODBC de 32-bits. Detecta errores producidos por la mala configuracin o por el registro completo de la bitcora del servidor SQL. Funciona correctamente en una mquina remota. Se ejecuta sin problemas en el Microsoft Internet Information Server (IIS), an teniendo gran cantidad de solicitudes. Gracias a ello brinda un correcto funcionamiento tanto en Internet como en Intranets. Provee de ayuda para la configuracin que permita generar pginas HTML en forma dinmica. Crea estructuras condicionales dinmicamente para personalizar la solicitud de datos y el envo de los mismos hacia el cliente. As mismo, disea cadenas de datos para crear dinmicamente mens desplegables y para llenar listas de seleccin y listas de documentos.

x x

Para crear aplicaciones de Cold Fusion, se necesita del conocimiento previo de sentencias SQL para la generacin de cdigo en la seleccin de la correcta informacin alojada en una base de datos. Gracias a las sentencias SQL se tiene un control completo sobre qu, dnde y por qu desplegar los datos dentro de un sitio Web. Funcionamiento de Cold Fusion Una vez se ha realizado la instalacin de este paquete, se pueden realizar requisiciones a travs de un URL, las cuales son enviadas al servidor Web, y ste a su vez la hace a la interfaz de Cold Fusion, la que se conecta a una fuente de datos ODBC, a la cual solicita los datos que requiere extraer de la base de datos. Como puede verse, Cold Fusion utiliza fuentes de datos ODBC, de las que incluye una versin dentro del software de instalacin, para poder manipular la informacin dentro de las bases de datos.

32

B D / C S : : 2 0 0 4 : : M M

Una vez se ha obtenido la informacin que se ha solicitado, la interfaz enva los datos hacia el Servidor Web y ste al browser, en donde los mismos son desplegados grficamente. En la siguiente figura se muestra el proceso que sigue Cold Fusion al momento de recibir y responder a una requisicin.

Fig. 2.5. Arquitectura de Cold Fusion para acceder bases de datos en el Web. Entrada y Despliegue de datos Cold Fusion hace uso de formas HTML estndar con validacin de datos de los campos, para realizar la insercin y actualizacin de registros dentro de una tabla en una base de datos. Para la entrada de datos se especificar el tipo de dato a introducir en un campo especfico. Este tipo de datos puede ser de valor entero, flotante, de fecha o en un rango especial de fechas. Adems, se puede registrar la hora de introduccin del valor de un campo, la direccin IP (Protocolo Internet) desde la que se hace una solicitud, el nombre del cliente y el tipo de browser que ste utiliza para acceder los datos, todo ello sin necesidad de escribir una lnea de cdigo. En cuanto al despliegue de datos, Cold Fusion solamente recibe la solicitud del cliente y realiza la presentacin de los mismos de una manera muy sencilla. Cold Fusion posee un control completo del formato de despliegue de datos, permite colocar enlaces entre los mismos datos extrados de la base, en las pginas HTML que han sido generadas al vuelo. Gracias a esta flexibilidad, se puede realizar cualquier tipo de seleccin de despliegue de datos, y el software se acomodar a las especificaciones realizadas. Como puede observarse, Cold Fusion realiza todo el procedimiento necesario, desde la recoleccin de informacin en un servidor de base de datos SQL, hasta el despliegue de la misma. As mismo, Cold Fusion permite alojar procedimientos y pasar datos a ellos muy fcilmente.

33

B D / C S : : 2 0 0 4 : : M M

2.4.8. Perl

Probablemente este sea uno de los lenguajes mas utilizados para el manejo de BD en sitios Web en los ambientes del Software Libre. La razn es simpi(e)-e: naci en los entornos UNIX, se ha mejorado en los Linux, existe mucha documentacin [16, 17] y soporte a travs de los grupos y por ser gratuito. Su manejo para los programadores de C, C++ y scripts en shell es simpie, no as para los programadores acostumbrados a las interfaces visuales de desarrollo. Respecto a esto ltimo en los ambientes Linux se ha desarrollado reciente mente una plataforma visual (privada) en modo grfico i(e).7(l)0.7(ama)7.9(d)1.7(a V)8.9(i)0.7(s)6.4(u)1.4(alP)4.2(e)

Existencia de operadores extremadamente robu

34

B D / C S : : 2 0 0 4 : : M M

cuales sern enviadas a la base de datos. Las principales funciones que las extensiones ODBC ofrecen a un escrito Perl son:
o o o o

new(): Crea una instancia del objeto que establece conexin con una base de datos. sql(): Enva sentencias SQL a la base de datos, va ODBC. fieldnames(): Genera los nombres de los campos obtenidos a partir de una sentencia SELECT. fetchrow(): Recupera hacia el buffer, una fila del conjunto de resultados obtenidos por una sentencia SELECT. data(): De cada fila de resultados , se obtienen los respectivos campos seleccionados. error(): Si existe algn error en las llamadas a las anteriores funciones , informa del tipo del error.

o o

Para usar las extensiones ODBC de Perl-Win32, en un escrito que acte como CGI deben incluirse:
o o o o o o o

Llamada a mdulo ODBC al principio de escrito Perl. Descodificar entrada proveniente del formulario. Imprimir Tipo de Contenido a desplegar en el Browser (Texto HTML). Crear una instancia para cada base de datos con la que se desea establecer comunicacin. Construir dinmicamente sentencia SQL, en base a los datos ingresados por el usuario. Ejecucin de sentencia SQL. Si la sentencia SQL es un SELECT deben manipularse los datos provenientes de la base de datos, para luego desplegarse al usuario en el formato adecuado.

Arquitectura
Las extensiones ODBC deben ser llamadas desde un escrito Perl que pueda comportarse como aplicacin CGI 1.1. Tales extensiones permiten que desde un escrito Perl se pueda establecer comunicacin con una base de datos a travs de ODBC; lo cual implica que los criterios que un usuario ha especificado en un formulario se procesen y se conviertan en sentencias SQL, para que el ODBC las intrprete y sean enviadas a la base de datos, con el objetivo de obtener los resultados esperados de la misma. Este procedimiento se ilustra en la Figura 2.6. Las extensiones ODBC para Perl constan de dos archivos: 1. ODBC.PLL: Es la extensin Perl para ODBC, escrita y compilada en Lenguaje C. Un archivo con extensiones .PLL no es ms que un .DLL, que ser cargado dinmicamente por Perl cada vez que se requieran los mdulos o extensiones dentro de un escrito Perl. 2. ODBC.PM : Archivo que provee al programador de una interfaz sencilla para hacer uso de las funciones contenidas en ODBC.PLL.

35

B D / C S : : 2 0 0 4 : : M M

Fig. 2.6. Arquitectura de de Extensiones ODBC para Perl Win32.

En los ambientes Linux Perl viene incluido en la mayora de la distribuciones y forma parte de muchas de las aplicaciones que el SO realiza. 2.4.9. C# Hay una corriente que no debemos dejar fuera ya que a nivel comercial tiende a ser una gran ola en las aplicaciones para el Web y se trata de una propuesta de Microsoft llamada C# (C sharp). Este lenguaje es una sntesis que trata de unificar los esfuerzos de la mencionada empresa para contar con una plataforma uniforme de desarrollo en Internet y lo propone como una alternativa a futuro para ASP. Microsoft en el mercado de ambientes para desarrollar aplicaciones Web introdujo diversas clases y bibliotecas a sus lenguajes de batalla, a saber: Visual Basic y Visual C++, las adiciones incorporadas trataron de darles a stos la funcionalidad para crear aplicaciones en ste entorno. Dado que otras opciones, como lo es Java, empezaban a desplazar a sus producto en ese ambiente se formul una alternativa que pudiera competir y esa es este lenguaje. Toma el esquema general de la POO, elimina los apuntadores, como Java lo hizo, usa un clon entre C y Basic como gramtica y se ofrece inicialmente como software libre. Luego se incorpora en una plataforma uniforme para crear programas para Internet llamada .NET (punto net). Y se crea la ola que ha hecho que las diversas empresas de su clase la incluyan en sus propuestas de herramientas de desarrollo. Se entiende que C# es el lenguaje nativo para el ambiente de ejecucin .NET (Common Language Runtime), est basado en el paradigma de componentes, es decir los objetos se escriben como componentes y las componentes son el centro de accin de las aplicaciones [18]. Los conceptos relativos a las componentes, tales como: propiedades, mtodo y eventos; son los ciudadanos de primera clase del lenguaje as como del ambiente de ejecucin asociado. La informacin declarativa (conocida como atributos o propiedades) puede ser aplicada a los componentes para pasar informacin a los ambientes de diseo y ejecucin acerca de ellos a otras partes del sistema. La documentacin puede escribir dentro de la componente y puede ser exportada a XML. Los objetos en C# no requieren de archivos de encabezado (como sucede con ASP) o bibliotecas de tipos (como es el caso de Visual C++) para ser creados o usados. Los componentes creados en C# se autodescriben y pueden ser usados sin procesos de registro. Microsoft arguye que C# es auxiliado en la creacin de componentes por los ambientes de ejecucin y trabajo de la plataforma .NET, lo cual ofrece un tipo unificado de sistema en el cual todo puede ser tratado como un objeto, pero sin la incidencia en el rendimiento asociada a los sistemas formados por objetos puros, como es el caso de Smalltalk.

36

B D / C S : : 2 0 0 4 : : M M

En lo relativo al manejo de errores C# ofrece el esquema de manejo de excepciones dentro de su ambiente y tiende a proteger la aplicacin cuando se utilizan

37

B D / C S : : 2 0 0 4 : : M M

- PHP 3 PHP 3.0 era la primera versin que se pareca fielmente al PHP tal y como lo conocemos hoy en da. Fue creado por Andi Gutmans y Zeev Zuraski en 1997 rescribindolo completamente, despus de que encontraran que PHP/FI 2.0 tena pocas posibilidades para desarrollar una aplicacin comercial que estaban desarrollando para un proyecto universitario. En un esfuerzo para cooperar y empezar a construir sobre la base de usuarios de PHP/FI existente, Andi, Rasmus y Zeev decidieron cooperar y anunciar PHP 3.0 como el sucesor oficial de PHP/FI 2.0, interrumpindose en su mayor parte el desarrollo de PHP/FI 2.0. Una de las mejores caractersticas de PHP 3.0 era su gran extensibilidad. Adems de proveer a los usuarios finales de una slida infraestructura para muchsimas bases de datos, protocolos y APIs, las caractersticas de extensibilidad de PHP 3.0 atrajeron a docenas de desarrolladores a unirse y enviar nuevos mdulos de extensin. Sin duda, sta fue la clave del enorme xito de PHP 3.0. Otras caractersticas clave introducidas en PHP 3.0 fueron el soporte de sintaxis orientado a objetos y una sintaxis de lenguaje mucho ms potente y consistente. Todo el nuevo lenguaje fue liberado bajo un nuevo nombre, que borraba la implicacin de uso personal limitado que tena el nombre PHP/FI 2.0. Se llam 'PHP' a secas, con el significado de ser un acrnimo recursivo - PHP: Hypertext Preprocessor. A finales de 1998, PHP creci hasta una base de instalacin de decenas de millares de usuarios (estimados) y cientos de miles de sitios Web informando de su instalacin. En su apogeo, PHP 3.0 estaba instalado en aproximadamente un 10% de los servidores Web en Internet. PHP 3.0 se liber oficialmente en Junio de 1998, despus de haberse esperado unos 9 meses en pruebas pblicas. - PHP 4 En el invierno de 1998, poco despus del lanzamiento oficial de PHP 3.0, Andi Gutmans y Zeev Suraski comenzaron a trabajar en la reescritura del ncleo de PHP. Los objetivos de diseo fueron mejorar la ejecucin de aplicaciones complejas, y mejorar la modularidad del cdigo base de PHP. Estas aplicaciones se hicieron posibles por las nuevas caractersticas de PHP 3.0 y el apoyo de una gran variedad de bases de datos y APIs de terceros, pero PHP 3.0 no fue diseado para el mantenimiento tan complejo de aplicaciones eficientemente. El nuevo motor, apodado 'Motor Zend' (comprimido de sus apellidos, Zeev y Andi), alcanz estos objetivos de diseo satisfactoriamente, y se introdujo por primera vez a mediados de 1999. PHP 4.0, basado en este motor, y acoplado con un gran rango de nuevas caractersticas adicionales, fue oficialmente liberado en Mayo de 2000, casi dos aos despus que su predecesor, PHP 3.0. Adems de la mejora de ejecucin de esta versin, PHP 4.0 inclua otras caractersticas clave como el soporte para la mayora de los servidores Web, sesiones HTTP, buffers de salida, formas ms seguras de controlar las entradas de usuario y muchas nuevas construcciones de lenguaje. PHP 4 es actualmente la ltima versin liberada de PHP. Ya se est trabajando en modificar y mejorar el motor Zend para integrar las caractersticas que se disearan para PHP 5.0. Hoy, se estima que PHP es usado por cientos de miles de programadores y muchos millones de sitios informan que lo tienen instalado, sumando ms del 20% de los dominios en Internet. El equipo de desarrollo de PHP incluye docenas de programadores, as como otras docenas de personas trabajando en proyectos relacionados con PHP como PEAR y el proyecto de documentacin.

38

B D / C S : : 2 0 0 4 : : M M

- PHP 5 El futuro de PHP est dirigido por su ncleo, el motor Zend. PHP 5 incluir el nuevo motor Zend 2.0. Para obtener ms informacin sobre este motor, consultar su pgina Web [21]. Caractersticas.[22] El siguiente es un script en PHP:
<html> <head> <title>Example</title> </head> <body> <?php echo "Hi, I'm a PHP script!"; ?> </body> </html>

Podemos ver que no es lo mismo que un script escrito en otro lenguaje de programacin como Perl o C ++ En vez de escribir un programa con muchos comandos para crear una salida en HTML, escribimos el cdigo HTML con cierto cdigo PHP embebido (introducido) en el mismo, que producir cierta salida (en nuestro ejemplo, producir un texto). El cdigo PHP se incluye entre etiquetas especiales de comienzo y final que nos permitirn entrar y salir del modo PHP. Lo que distingue a PHP de la tecnologa Javascript, la cual se ejecuta en la mquina cliente, es que el cdigo PHP es ejecutado en el servidor. Si tuvisemos un script similar al de nuestro ejemplo en nuestro servidor, el cliente solamente recibira el resultado de su ejecucin en el servidor, sin ninguna posibilidad de determinar que cdigo ha producido el resultado recibido. El servidor Web puede ser incluso configurado para que procese todos los archivos HTML con PHP. Lo mejor de usar PHP es que es extremadamente simple para el principiante, pero a su vez, ofrece muchas caractersticas avanzadas para los programadores profesionales. Aunque el desarrollo de PHP est concentrado en la programacin de scripts en la parte del servidor, se puede utilizar para muchas otras tareas, en general se puede considerar un lenguaje de propsito general. Su estructura es tipo C, ms no requiere de declaracin de variables, para el lenguaje todas son cadenas, en caso de ser nmeros las cadenas, stos se pueden operar aritmtica y lgicamente de manera normal. Tiene manejo de archivos locales, se pueden declarar funciones, es posible utilizar el paradigma de programacin orientada a objetos y crear clases [27, parte II], en esta referencia se presentan los siguientes temas: Sntaxis bsica Tipos Variables Constantes Expresiones Operadores Estructuras de Control Funciones Clases y Objetos Explicando las Referencias

39

B D / C S : : 2 0 0 4 : : M M

Captulo 3. Acceso a BD remotas con PHP/mySQL

PHP puede hacer cualquier cosa que se pueda hacer con un script CGI, como procesar la informacin de formularios, generar pginas con contenidos dinmicos, o mandar y recibir cookies, entre orermac3( s)6.1(ac:)79(cicon)11.7e

40

B D / C S : : 2 0 0 4 : : M M

Quizs la caracterstica ms potente y destacable de PHP es su soporte para una gran cantidad de bases de datos. Escribir un interfaz va Web para una base de

41

B D / C S : : 2 0 0 4 : : M M

3.1.1. Formas en HTML Una forma se declara mediante el par <FORM> contenido </FORM>,

42

B D / C S : : 2 0 0 4 : : M M

Los elementos bsicos (type) que pueden ser utilizados dentro la etiqueta <input> son los siguientes: 1. text: Campo de Texto (TextEdit). Se utiliza para la introduccin de cadenas (texto) 2. password: Es una clase que campo de texto que de forma visual sustituye los caracteres de entrada por asteriscos, con el propsito de esconder lo que el usuario introduce. 3. file: Permite la insercin de un archivo almacenado en el cliente y enviarlo al servidor. 4. radio: Se utiliza para definir una casilla de opcin nica o excluyente con otras de su tipo. Para formar un grupo de seleccin el nombre (name) de las casillas debe ser el mismo y stas se discriminarn por su valor definido en value. Se enviar al servidor solo aquella que haya sido seleccionada (cheked). De cada grupo se podr seleccionar solo una. 5. checkbox: Se utiliza para definir una casilla de opcin complementaria, puede haber marcada ninguna, varias o todas. Estas se pueden manejar a travs del atributo name como un grupo: aquellas que llevan el mismo nombre; o como independientes, si cada una tiene un nombre diferente, se enviar el valor de cada chekbox seleccionada. Si stas se agrupan y se marca mas de una se enviarn todas las marcadas con el mismo nombre (name) y diferentes valores (value). 6. Botn de accin. Presenta un botn de respuesta inmediata no cancelable que aceptan todo el contenido de la forma. Hay tres tipos: a. submit: Botn de envo. Manda el contenido de la forma al servidor desde el navegador. Puede colocarse ms de un botn de envo, para diferenciarlos se utilizan los atributos name y value. b. reset: Botn de restauracin. Limpia o restaura los campos de la forma, en el primer caso los borra y en el segundo les asigna los valores predeterminados (defaults). Este no enva datos al servidor, es de accin local, acepta el atributo value. c. image: Botn personalizado. Se construye junto con el atributo src, el cual indica el origen (source) de la imagen que contendr el botn. Cuando se hace Click en l por parte del usuario el Navegador enva la forma al servidor (como es el caso del submit) e incluye las coordenadas X-Y del cursor del ratn donde se encuentra la imagen. Acepta los atributos: name, align y border. Cuando se incluyan varios botones en el seno de una forma, para distinguirlos uno debe incluir el atributo value con un valor determinado y diferente para cada botn. Normalmente si se trata de botones de envo se suele asignar el mismo nombre (name) a cada botn para que el programa que atiende la forma en el servidor de Web diferencie lo que usuario eligi y modificar el flujo de la aplicacin. Se debe tener cuidado con los botones de imagen, ya que estos no aceptan el atributo value, entonces para distinguirlos se debe manejar el atributo name. 7. hidden. Campos Ocultos. Este es un tipo singular de campo, ya que no es interactivo con el usuario, es decir no es visible en el Navegador. Se utiliza para incluir informacin en las formas que no debe ser ignorada o alterada por el navegador o el usuario. Se deben incluir los atributos name y value de la etiqueta <input>. Los valores de estos campos se enviarn al servidor como es usual. Algunos usos que se le da a ste campo son: a. Clasificacin de Formas. b. Identificacin de la versin de una forma.

43

B D / C S : : 2 0 0 4 : : M M

c. Administrar las interacciones CS. Por ejemplo se puede incluir informacin del solicitante cuando el servidor produce la pgina con la forma e identificar a quin pertenece esa peticin y en consecuencia hacer un seguimiento. d. Selector de acciones en el lado del servidor. Dependiendo de uno o varios campos ocultos el programa en el lado del servidor que atiende a la forma puede cambiar su proceder dependiendo de los valores de las variables ocultas. Otros elementos que pueden incluirse dentro de una forma son los siguientes: 1. <textarea>: Crea un rea de texto multilnea en la ventana del navegador. En ella se puede introducir informacin. Al ser enviadas al server se agrupan en una cadena, donde cada lnea de texto se separa por el cdigo CR-LF (%0D0A) la cadena se asigna al atributo name del rea de texto. Pueden utilizarse los atributos cols, que regula el nmero de columnas y rows que define el nmero de renglones visibles, a ambas se les asigna un entero. En el caso que se exceda el nmero de renglones aparecer una barra se scroll vertical. Se acepta tambin el atributo warp que sirve para hacer rompimiento automtico de lneas, si su valor es virtual, se enviarn cdigos de salto (CR-LF) slo si el usuario los inserta y si se define Physical, se enviarn cdigos de salto en cada rompimiento que se produzca en el rea de texto aunque el usuario no los haya insertado. 2. <select>: Se utiliza para crear listas de elementos seleccionables (comboBox). Los atributos que acepta son: a. multiple: Habilita una seleccin mltiple. b. size: Determina el nmero de opciones que el usuario podr ver a la vez. SU valor debe ser un entero positivo. El valor predeterminado es uno. c. name: Indica el nombre del selector. d. <option>: Define una componente de una lista de seleccin. Requiere el atributo value asociado a un valor, ste es que enviar la forma en caso de ser seleccionado. texto-simple: Es una cadena que se introduce para que visualizada por el usuario dentro de la lista. Se debe escribir a la derecha Es posible mejorar la apariencia, funcionalidad y presentacin de las formas usando JavaScript. Puede consultarse ms informacin sobre los elementos de una forma en la literatura relacionada con HTML [7, 8, 10]. 3.1.2. Interfase de Usuario Una Interfase de Usuario en una aplicacin Web directa es de tipo grfico, por lo cual se le asigna la categora de Interfase Grfica de Usuario (GUI), siempre que el navegador opere en sta modalidad, recuerde que existen Navegadores de Web en modo texto como es el caso Lynx de Linux, estos no sern operativos para el manejo de las formas. sta se genera mediante las etiquetas antes mencionadas, la funcionalidad debe estar determinada por el tipo de accin que se desea realizar. La accin ser realizada por el programa asociado a manera de URL en la forma mediante el atributo action. Dicho programa recibir la informacin recolectada por la forma como se mencion anteriormente dependiendo del mtodo (GET o POST). Dentro de la GUI se pueden incluir otros elementos de HTML pasivos para guiar al usuario en el manejo de la forma, tales como: textos, tablas (<table>) y lneas de divisin (<hr>).

44

B D / C S : : 2 0 0 4 : : M M

Existen herramientas como es el caso de HomeSite, Dreamweaver y Flash distribuidos comercialmente por Macromedia, entre otras, que permiten crear dichas GUI con ms elementos tales como mens, barras de botones grficos y paneles0a[(2 5086.0188 Tc0.1299 Tw[(1299otones 1.7(5( com)1s)embellec)/Css0aHomeSla interfco

45

B D / C S : : 2 0 0 4 : : M M

Los procedimientos de instalacin y configuracin son claros y generalmente si la plataforma cumple los requerimientos solicitados el sistema es funcional y estable. Las carpetas que crea el proceso de instalacin de los archivos binarios son tpicamente las siguientes: Carpeta
bin `data `docs `include `lib `scripts `share/mysql `bench examples doc embebed scripts

Contenido
Programas cliente y mysqld server Sitio para las Bases de Datos y archivos de registro (logs) Documentacin Archivo Include (header) Bibliotecas mysql_install_db Archivos con mensajes de error en diferentes idiomas Benchmarks Ejemplos Documentacin en texto y HTML del sistema Bibliotecas estticas y DLLs Scripts de ejemplo y sitio para nuevos scripts

Tabla 3.1. Carpetas de MySQL tpicas El sistema ofrece diferentes API para realizar aplicaciones sobre el DBMS, algunas de ellas corresponden a: C, C++, Java, Delphi, Pitn, PHP, Perl, Tcl y Eiffel. En el manual oficial [24] se puede encontrar informacin detallada de su uso.

3.3. Apache
Apache es un servidor de Web tambin bajo el esquema de Open Source que tiene soporte para una gran variedad de plataformas, algunas de stas son:
AUX 3.1 BSDI 2.0 FreeBSD 2.1 HP-UX 9.07 IRIX 5.3 Linux NetBSD 1.1 NEXTSTEP SolarisX86 2.5 Solaris 2.4 Solaris 2.5 SunOS 4.1.3 UnixWare 1.1.

Netware MS Windows Mac OS X

El servidor opera como uno normal y contiene las siguientes extensiones: x x x x x x Autenticacin basada en Cookies Soporte para definir el UID y GID al ejecutarse scripts CGI Autenticacin de usuarios usando el sistema de BD de cuentas de UNIX Mdulos mejorados en el lado del servido: Server Side Include (SSI) Intrprete incrustado de Perl Autentificacin basada en Kerberos
46

B D / C S : : 2 0 0 4 : : M M

x x x x x x x x

Traductores de conjuntos de caracteres Mdulos de autentificacin de usuarios para BD Postgres95 y mSQL Contadores de pginas Web Formatos de registro extendidos (logs) Autenticacin NIS Mdulos de reescritura de URI/URL Procesador de scripts para Tcl Diferentes alternativas para mdulos CGI, pe. FastCGI

La documentacin del servidor es bastante completa e indica cmo instalarlo y configurarlo, ste se puede levantar automticamente o de manera manual. Se ofrece en algunas plataformas una interfase para monitorearlo y administrarlo. En las secciones 5 y 6 del manual se discuten las diferentes maneras para ejecutar CGI, as como los lenguajes soportados por defecto, algunas extensiones y funciones, en particular es interesante el apndice C que contiene la interfase de programacin para el esquema mejorado de CGIs llamada FastCGI.. En la seccin 10 del manual se explican los mdulos que se pueden utilizar, cmo levantarlos y configurarlos. Este material se puede encontrar en el CD adjunto a estas notas en la carpeta de Apache [26].

3.4. PHP

Como se explic en el captulo anterior PHP es un lenguaje de propsito general que es posible usar para el desarrollo de aplicaciones en lado del servidor sobre la Web. Al incluir el manejo de PHP dentro del servidor de Web Apache 2.0 uno logra la funcionalidad completa del lenguaje, en particular PHP habilita un conjunto muy completo de funciones y mtodos para acceder a BD sobre MySQL, a continuacin se enlistan: FUNCION PHP
mysql_affected_rows mysql_change_user mysql_client_encoding mysql_close mysql_connect mysql_create_db mysql_data_seek mysql_db_name mysql_db_query mysql_drop_db mysql_errno mysql_error mysql_escape_string mysql_fetch_array mysql_fetch_assoc mysql_fetch_field mysql_fetch_lengths

DESCRIPCIN
Devuelve el nmero de filas afectadas de la ltima operacin MySQL Cambia el usuario conectado en la conexin activa Devuelve el nombre del juego de caracteres Cierra el enlace con MySQL Abre una conexin a un servidor MySQL Crea una base MySQL Mueve el puntero interno Obtener datos de resultado Enva una sentencia MySQL al servidor Borra una base de datos MySQL Devuelve el nmero del mensaje de error de la ltima operacin MySQL Devuelve el texto del mensaje de error de la ltima operacin MySQL Cadena de escape para su uso en mysql_query. Extrae la fila de resultado como una matriz asociativa Recupera una fila de resultado como una matriz asociativa Extrae la informacin de una columna y la devuelve como un objeto. Devuelve la longitud de cada salida en un resultado

47

B D / C S : : 2 0 0 4 : : M M

FUNCION PHP

DESCRIPCIN

671(ne-7671(r inf-51.7(mo)3.3(rmac-7671(in d)5.96e)-4671(l c-7671(lie-7671(nt-51056me-7671( M)-7671(SQL-7675 )]TJ1T*00.002 Tc0.00253Tw[(my)-7.25s mys7.27(q)03(l_4.5(m)-81.6 fi4.5(me_4.5(md_f_4.5(ma)1(g).4(Is7.27(c)1 mysql_fetch_object Extrae una fila dlacz

48

B D / C S : : 2 0 0 4 : : M M

Y como referencias al lenguaje existe documentacin que incluye la manera de crear y manejar PHP para ofrecer soluciones de manejo de BD sobre MySQL [28, 29, 30].

49

B D / C S : : 2 0 0 4 : : M M

3.5.1. Tipos de acceso Un elemento bsico en el proceso es determinar el tipo de acceso al sistema o partes de l, se pueden distinguir al menos dos esquemas: 1. Acceso libre. Cualquier usuario que conozca la direccin del servidor y una pgina activa puede ingresar al sistema, donde las tareas que puede hacer las determina el sistema mismo. Esta clase de esquema normalmente corresponde a la realizacin de solo consultas. 2. Acceso Restringido. Un usuario puede conocer el sitio y la pgina activa, pero requiere de una autentificacin para ingresar al uso del sistema. Normalmente para lograr esto se le debe asignar a los usuarios permisos de acceso mediante un esquema de identificacin, el ms simple consiste en asignarle a cada usuario reconocido un nombre (login) y clave de acceso (password). Esta informacin se almacena en el lado del servidor en una BD de usuarios registrados y cada vez que el usuario requiere acceder a alguna aplicacin debe dar sus datos, luego el servidor lo valida y de ser correcta la informacin dada por el usuario se le da permiso de realizar las tareas que su rango le confieren. Esto quiere decir que en general los permisos de cada usuario pueden ser diferentes y dependiendo de su clase se le habilitar a realizar una u otra tarea. Cada vez que uno hace una aplicacin CS debe definir el tipo de usuarios que la explotarn y crear una tabla con al menos cuatro elementos: Campo login passwd tipo_usuario estado Tipo cadena cadena encriptada clave_interna (activo, inactivo)

Dependiendo del tipo_usuario el sistema o sistemas definirn a que tiene acceso el usuario que ha dado el par: login password correctos. El campo de estado se utiliza para inhabilitar a un usuario por periodos y controlar su acceso segn se requerido sin borrarlo de la tabla. Este mecanismo permite por ejemplo: cerrar el sistema a algunos usuarios temporalmente mientras se realizan tareas de mantenimiento o modificacin y luego abrirlo cuando stas se han finalizado, o bien deshabilitar a usuarios por razones administrativas y de seguridad. Este modelo facilita que se organicen los usuarios en clases y segn sea su tipo sean tratados de la misma manera por parte de la aplicacin como usuarios genricos, lo cual simplifica el diseo y mantenimiento de la aplicacin Otra forma de controlar el acceso es mediante la asignacin de permisos a nivel del DBMS, esto involucra que a cada usuario se le deben dar permisos especficos para cada recurso del sistema. Normalmente esto se hace mediante scripts que administran los permisos para cada usuario y cada recurso que maneja el DBMS. A nivel de programacin de las aplicaciones frontales bajo HTML se puede utilizar un campo <input> de tipo hidden que plasme en la pgina que contiene la aplicacin informacin que permita dar seguimiento al usuario. Algunos elementos comunes de ste mtodo es incluir cadenas encriptadas con informacin del
50

B D / C S : : 2 0 0 4 : : M M

usuario y tiempo de expiracin de las pginas para evitar que las pginas que se dejen abiertas por descuido sean utilizadas de manera indebida. Al recibirse la siguiente peticin mediante las funciones de desencriptado y fecha-hora se valida la informacin oculta y se toman las decisiones convenientes. A ste modelo se le llama modelo de boletos y permite darle un boleto a la terna usuario origen hora, de tal manera que si se salva la pgina y se trata de ejecutar en otra mquina o por otro usuario o en un momento posterior al vlido se pueda detectar la suplantacin y pedir en consecuencia que el ejecutante se vuelva a validar, lo cual permite rechazar solicitudes espurias. Se puede proponer como mecanismo organizar la informacin de la terna de validacin en una cadena, encriptarla e incluirla en las pginas subsiguientes que son enviadas al usuario en el proceso de operacin de la aplicacin. Este modelo puede presentar el inconveniente de presentar vacos en el caso que el usuario elija una secuencia de navegacin ajena a la lgica de la aplicacin, en estos casos se requerir volver a pedir que el usuario se autentique y volver a incrustar la informacin de control en las pginas de respuesta. Para la implantacin de estos mtodos PHP ofrece funciones de criptografa directa e inversa. 3.5.2. Manejo del origen de los accesos Otra situacin que se debe contemplar es la limitacin de los accesos en funcin del sitio desde donde se conectan los usuarios. Es comn pedir restricciones de acceso incluso al libre por dominios de Internet. Por ejemplo, una institucin puede requerir que todos los empleados que laboran en ella puedan acceder a ciertos sistemas sin necesidad de autentificacin, simplemente si lo hacen desde una mquina ubicada en algn(os) dominio(s) especfico(s), esto se puede resolver construyendo una tabla dentro del sistema de base de datos o mediante archivos de configuracin de las aplicaciones mismas que definan como sern los accesos en funcin de la mquina que los solicita y no solo se tome la decisin validando al usuario. Este modelo ayuda a evitar que se realicen accesos indebidos desde ciertas mquinas o dominios especficos, restringir el acceso a ciertas aplicaciov-196.6(s)6.6(ta Otricy abrir14.8(eel ac)8.8( )qui11.5(i)natae es)6.o a iic

51

B D / C S : : 2 0 0 4 : : M M

Este modelo jerrquico ayuda a delimitar las funciones de cada usuario y equipo en el mar de sistemas que pueden existir dentro de una institucin. Los sistemas pueden ubicarse en una o varias mquinas que operen como servidores dentro de la institucin y cada una puede colaborar con otras para la solucin de los problemas. 3.5.3. Disponibilidad En un ambiente tradicional que se pretenda sea tolerante a fallas, al menos debern estar presentes los servidores de respaldo, que deben entrar a operar si los servidores primarios llegasen a fallar o entrar en fase de servicio. Se pueden escribir aplicaciones que mantengan estos sitios de respaldo actualizados o aprovechar herramientas de respaldo automtico ya construidas. Para verificar si un sistema est activo se pueden escribir pequeas aplicaciones que verifique su estado de manera peridica y en caso de determinarse que algn servidor ha dejado de funcionar o no hay enlace a l sobre la red falla en el sistema de comunicaciones mediante un sistema de suplantacin o un portal de acceso reconfigurable se levanta el servidor auxiliar y restablece el servicio mientras se resuelve el problema con el servidor primario. A estos sistemas se les conoce como de alta disponibilidad. Otro caso que debemos comentar es el de sistemas auxiliares de apoyo cuando se presenta saturacin de algn servidor por exceso de carga por los usuarios o los procesos internos. Para restaurar el rendimiento de los sistemas se puede utilizar un cluster funcionando con un SO que realice el balance de carga y que vaya activando nuevos nodos en funcin de la demanda, haciendo una reubicacin de procesos de manera automtica entre sus nodos. Y al momento de reducirse la carga volver a hacer un reacomodo y liberar nodos ociosos. Para una implantacin de sta clase existen SOs creados ex profeso, a estos se les llama sistemas operativos distribuidos. Estos sistemas incluyen mecanismos de balance y migracin de procesos. Una manera de medir la carga del sistema o sistemas es mediante una estadstica de tiempo de respuesta a los clientes locales y remotos, as mediante la definicin de reglas para los tiempos de atencin mximos y medios se activan los servidores o nodos auxiliares en funcin de la arquitectura y SO disponibles. 3.5.4. Colaboracin y apoyo Las aplicaciones de BD bajo PHP/MySQL son por naturaleza colaborativas ya que es posible que un script en PHP haga una peticin a una BD ubicada en un servidor (fsicamente) diferente a aquel donde se ha recibido la peticin por parte del Servidor de Web. Esto se refleja en el hecho de cmo se realiza la conexin a la BD de MySQL, analicemos la sintaxis del mtodo de conexin de PHP: int mysql_connect([string host [: int puerto] [, string usr [, string passwd] ] ]) el primer parmetro host es una cadena que indica la direccin del servidor, la cual en general puede ser remota o local. Por lo tanto una aplicacin que se ejecuta en un nodo puede conectarse a otro nodo donde se encuentra una instancia de MySQL ejecutiva. Al abrirse la conexin el manejador que devuelve el mtodo mysql_connect, contiene la informacin necesaria para interactuar en ese nodo y el MySQL que atiende remotamente. En caso de omitirse los parmetros del mtodo se tomarn los parmetros por defecto que corresponden a: host ='localhost', usr = el propietario del proceso del servidor y password vaco.

52

B D / C S : : 2 0 0 4 : : M M

Algunos modelos de sistemas piden que se ejecute ms de una instancia de MySQL en cierto nodo, esto se puede hacer cambiando el puerto

53

B D / C S : : 2 0 0 4 : : M M

Bibliografa

[1] [2] [3] [4] [5] [6] [7] [8] [9]

Dittrich, Object Oriented Data Model Concepts, Proceedings of the NATO Advanced Study Institute on OODBS, Springer Verlag, 1994. Date, Introduccin a los Sistemas de Bases de Datos, Prentice hall, 7. Ed. ,2001. Peralta Vernica, Taller de Sistemas de Informacin, http://proa.ei.uvigo.es/. Tanenbaum Andrew, Redes de Computadoras, 3 Ed. , Prentice Hall, 1997. Consorcio World Wide Web (W3C), http://www.w3c.org/ Grupo de Trabajo de Ingeniera de Internet (IEFT), http://www.ieft.org/ HTML 4.0 Especification, W3C, http:/www.w3c.org/ Soria, Ramn. Diseo y creacin de pginas Web, HTML 4. Alfaomega Rama, 1999. Martn, Manuel. Tutorial de HTML. FCC BUAP, http://www.cs.buap.mx/~mmartin, 2000.

[10] Gundavaram Shishir. CGI Programming on the WWW. OReilly, 1996. [11] Corts C., Melndez J. y Tobar M. Interfaz CGI para Servidores Web y Sistemas de Administracin de Bases de Datos, Tesis de la Universidad Centroamericana Jos Simen Caas, El Salvador, 1997 [12] Sitio oficial de Sun Microsystems, http//www.sunsite.com [13] Aramburu y Garca. Curso de diseo de Bases de Datos. Universitat Jaime I, Departamento de Ingeniera y Ciencia de los Computadores. http://www3.uji.es /~aramburu [14] Sitio oficial de Perl. http://www.perl.com [15] Roth Dave. Sitio para el Manejo de Perl sobre Windows. http://www.roth.net/ODBC [16] Larry Wall and Randal L. Schwartz, Programming Perl, O'Reilly & Associates, Inc. 1991 [17] Comprehensive Perl Archive Network, http://www.cpan.org [18] Gunnerson Eric, A programmers introduction to C#. Apress, 2000. [19] Sitio Oficial de PHP. http://www.php.net [20] Museo de PHP, http://museum.php.net

54

B D / C S : : 2 0 0 4 : : M M

[21] Tendencia de PHP, http://www.zend.com/zend/future.php [22] Grupo de Documentacin de PHP, Manual de PHP, http://www.php.net , 2003 [23] Proyecto GTK-PHP. http://gtk.php.net [24] Sitio Oficial de MySQL. http://www.mysql.com/, http://www.mysql.com/documentation [25] Maslakowski, Butcher. Aprendiendo MySQL en 21 das. SAMS - Prentice Hall, 2001. [26] Apache Server Survival Guide. Ubicada en el CD adjunto. [27] Bakken, Aulbach, Schmid, Winstead, Torben Wilson, Lerdorf, Zmievski, Ahto. Manual Oficial de PHP 4. Editado por Rafael Martnez, Angela Pardo, Federico Finos, Pablo Daniel Rigazzi, Robert Snchez y Leonardo Boshell. http://www.opencontent.org/openpub/ , 2003. [28] Meloni, PHP Fase & Easy web development, 2 Edicin, Premier Press, 2002. [29] Gutirrez y Bravo. PHP 4 a travs de ejemplos. Alfaomega Rama, 2004. [30] Pineda, Ivo H. Aplicaciones de Bases de Datos Locales. FCC BUAP, 2004.

55