3

ESPECIFICACIN, DISEO E IMPLEMENTACIN DE LA APLICACIN CLIENTE/SERVIDOR EJEMPLO.

En los inicios del presente trabajo de investigacin, fue motivo de especial atencin la situacin en la que se encontraban algunas instituciones (de naturaleza oficial) de la ciudad de Popayn. Era frecuente la situacin en la que la organizacin posea algn equipo con buena configuracin (para entonces) en los que se tena instalado algn Sistema Manejador de Base de Datos Relacional bajo la plataforma Unix. (como Unify, Informix u Oracle), pero tambin disponan (de manera totalmente independiente) de alguna red de computadores personales enlazados mediante una red local operando bajo Windows. Los procesos adelantados en las oficinas conectadas a la red Windows requeran con frecuencia acceder a la informacin residente en el servidor de Base de Datos bajo Unix; tambin se presentaba la necesidad de acceso a la informacin en el otro sentido -desde el servidor Unix a algn nodo de la red. Por limitaciones obvias en el presupuesto, se analizaron soluciones prcticas, teniendo como requisito utilizar en la medida posible los recursos de cmputo y de comunicacin existentes. De la anterior consideracin, en primera instancia, y de las expectativas latentes al rededor del tema en el entorno universitario, surge la idea de investigar el modelo Cliente/Servidor, y de concretar tales investigaciones en una aplicacin ejemplo.. En este captulo se presenta el esquema general de la aplicacin (segn las condiciones y restricciones encontradas), las especificaciones fundamentales de los procesos cliente y

servidor y los aspectos ms importantes del desarrollo e implementacin de la aplicacin, segn la metodologa presentada en el captulo anterior.

3.1

ESPECIFICACIN

3.1.1

Restriccin.

La principal restriccin dictamina el aprovechamiento de las plataforma y recursos computacionales existente (o que son de fcil consecucin), como base para el desarrollo del conjunto de funciones de las aplicaciones cliente y servidora.

3.1.2

Esquema General de la aplicacin

La aplicacin ejemplo se desarrolla en un entorno que es un modelo a escala, pero que conserva el esquema y las condiciones bsicas de las organizaciones empresariales antes mencionadas. El entorno se simula mediante un pequeo sistema conformado por dos computadores personales enlazados mediante una red Ethernet 10Base2(4). Los equipos que conforman la red tienen una configuracin elemental (y tal vez modesta en comparacin con las llamadas configuraciones estndar de los PCs de la poca.), pero

Ethernet 10 Base 2 es el nombre tcnico para las redes (o segmentos) que comparten un bus lineal formado

por cable coaxial delgado (RG-58) de 50 Ohmios. La velocidad mxima de transmisin en este tipo de redes es de 10 Mbits/seg, y distancia mxima permitida es de 185 mts.

pag. 74

suficiente para permitir el desarrollo de la aplicacin. La configuracin de los computadores empleados es la siguiente: Procesador Intel 486, 8MB RAM, Disco Duro de 1.2 GB El primero de los equipos se destina para el desarrollo (y posterior ejecucin) del proceso cliente bajo la plataforma operativa Windows 3.11. El otro equipo (que opera bajo Unix SCO), se destina para el desarrollo y ejecucin del proceso servidor. Los sistemas plataformas operativas de base Las herramientas software disponibles para el desarrollo de la aplicacin cliente son las siguientes: Plataforma operativa Windows 3.11 Lenguaje de programacin Borland C ++ (versin 4.0) Trumpet Winsock (interface socket y libreras que implementan el protocolo TCP/IP). Y las herramientas software disponibles para el desarrollo de la aplicacin servidora son: SCO Unix System V Release 3 versin 5. Esta versin adems del Sistema Operativo Unix Bsico, incluye el Sistema de Desarrollo (y entre otros productos, el compilador para el lenguaje C), la interface socket y el acceso al conjunto de protocolos TCP/IP. Sistema Gestor de Base de Datos (DBMS) Informix para Unix. Comunicacin de procesos entre nodos por medio de Sockets. La comunicacin entre los procesos cliente y servidor (nodos diferentes de la red) se lleva a cabo a travs de la interface socket (empleando protocolos TCP/IP). La figura 3-1 muestra el esquema general de la aplicacin Cliente/Servidor ejemplo.

pag. 75

Figura 3-1. Esquema General de la aplicacin Cliente/Servidor ejemplo.

3.1.3

Propiedades de la aplicacin.

Aislamiento al usuario de los detalles tcnicos de implementacin. Para el usuario el sistema desarrollado se reduce a una interface grfica de manejo intuitivo, por medio de la cual accede a ciertos servicios e informacin remota. Transparencia a la heterogeneidad de los sistemas. Uno de los objetivo de la implementacin, es que los procesos cliente y servidor pueda interactuar sin considerar que ellos se ejecutan en entornos operativos diferentes.

3.1.4

Servicios ofrecidos por la aplicacin a nivel usuario.

Servicios bsicos para el manejo de archivos remotos (como: navegacin por la estructura de archivos remota, copia de archivos, listado del directorio, etc.).

pag. 76

Servicios de consulta sobre una Base de Datos Relacional remota, mediante el empleo de sentencias SQL (SELECT). Posibilidad de acceder una Base de Datos Relacional remota, mediante el empleo de sentencias SQL para operaciones distintas a las de consulta (adicin, modificacin, eliminacin, etc.)

3.1.5

Funciones ofrecidas por la aplicacin a nivel del programador .

Para el entorno Unix se provee un conjunto de utilidades, reunidas en una librera de funciones al estilo C (API del programador). Un programa que desee invocar las utilidades de la API debe encadenar la librera, o incluirla en el momento de la compilacin. Las funciones estn concebidas para que sean empleadas por un servidor con caractersticas similares al presentado en esta aplicacin En la tabla 3-1 se presenta un resumen de las principales funciones que conforman la librera.

3.1.6

Consideraciones sobre la interaccin entre los procesos servidor y cliente.

El proceso servidor debe tener capacidad para ejecutar concurrentemente y atender las peticiones provenientes de diferentes procesos cliente. Hay un proceso servidor maestro que se encarga de atender las peticiones de conexin de los procesos cliente (que arriban por la red).

Tabla 3-1. Principales funciones de la librera Las funciones pueden ser invocadas por otros procesos servidores que operen en el mismo entorno (Unix.)

pag. 77

Funcin rdir() rcd() rcwd() rcopia() sql()

Propsito Lista un directorio. La salida se dirige al dispositivo identificado por el canal de comunicaciones Se cambia al directorio especificado. Informa cul es el directorio corriente de trabajo. Copia un archivo (cuyo nombre se pasa como parmetro) al canal identificado por un descriptor Permite la ejecucin de una sentencia SQL. Los resultados de la consulta son devueltos por el canal identificado por el descriptor que se pasa como parmetro.

Por eficiencia el proceso Servidor activa un proceso esclavo para cada solicitud. Cada proceso servidor esclavo maneja la interaccin con el proceso cliente. La interaccin se reduce a la seleccin de opciones por parte del cliente y la atencin del servicio por parte del proceso servidor esclavo. Por conveniencia, el esquema adoptado se basa en la implementaciones FTP comerciales. En esa implementaciones, el proceso servidor esclavo interacta con el proceso cliente mediante el canal establecido inicialmente; por ese medio, se intercambian mensajes que permiten la ejecucin de algn servicio, o la supervisin de alguna tarea previamente iniciada. Por el mismo canal viaja tambin la informacin necesaria para conformar un canal alterno de comunicaciones destinado al intercambio masivo de informacin. Cada peticin iniciada por el cliente ocasiona el establecimiento de dos canales, uno para propsitos de control y otro para el intercambio masivo de datos. El esquema es adecuado para circunstancias tpicas que suelen presentarse durante la interaccin Cliente/Servidor. Un ejemplo, ayuda a visualizar el esquema y su conveniencia: Considrese una solicitud de copia de un archivo iniciada por el proceso cliente; supngase que el archivo a copiar es de tamao considerable y su transferencia completa tardar varios minutos. Si existiera un camino nico entre el cliente y el servidor, una peticin de finalizacin anticipada no podra enviarse (a manera de mensaje) sino hasta que se complete la tarea inicial. Por el contrario con la definicin de los dos canales, si se ha iniciado la transmisin de informacin masiva

pag. 78

por el canal de datos, entonces por el canal de control podran intercambiarse mensajes que permitan verificar el curso de la transmisin, o incluso la terminacin anticipada de la misma. El esquema de interaccin mediante dos canales proporciona mucha flexibilidad. El canal de datos se establece por cada accin que puede significar intercambio masivo de informacin (copia de un archivo remoto, listado del directorio remoto y resultado de una consulta SQL). El proceso servidor esclavo (que se encuentra conectado con el proceso cliente a travs del canal de control), ante tales servicios solicita automticamente establecer una nueva conexin con el proceso cliente. El proceso cliente transmite por el canal de control su identificacin (direccin y nuevo nmero de puerto), de manera que el proceso servidor esclavo pueda conectarse a este nuevo destino. En el establecimiento del nuevo canal de comunicaciones, paradjicamente, los roles se invierten (el proceso servidor esclavo desempea un papel de cliente, y el cliente original se convierte en servidor). El esquema se muestra en la figura 3-2. Figura 3-3. Establecimiento de dos canales de comunicacin (control y datos) para la Interaccin en los procesos Cliente y Servidor

Canal de Datos

pag. 79

. . .
Comunicar a la red la direccin del canal.

. . .
Conexin con la direcc. del servidor peticin del servicio

Esperar peticin de servicio

esperar respuesta
fork()

Proceso Servidor Hijo. Control de la comunicacin

Proceso Cliente

Canal de Control

pag. 80

Para el desarrollo de la aplicacin ejemplo, se determin el empleo del modelo clsico (que como se sabe es apropiado para aquellos casos en donde los requerimientos ya estn plenamente definidos, como es el caso de la aplicacin ejemplo), con las extensiones propuestas por la metodologa, lo que significa la realizacin de las tareas cclicas de anlisis, diseo y revisin sobre los cuatro frentes (presentacin, procesos, Base de Datos y Arquitectura). La secuencia conduce desde el nivel conceptual hasta el nivel fsico. Sin embargo, considerando el tamao reducido de la aplicacin, se incurrira en aspectos redundantes al desarrollar los tres ciclos anteriores. En su lugar se presentan los resultados del diseo e implementacin definitivos.

DISEO

3.1.7

Arquitectura

La capa de Aplicaciones de Escritorio le permite al usuario seleccionar opciones ofrecidas por la aplicacin. Esta capa pasa como parmetro a la capa de Procesos una cadena que indica cul fue la opcin seleccionada, y -eventualmente- una cadena complementaria (como en el caso de la solicitud del directorio remoto, en donde la capa de Aplicaciones debe pasar a la capa de procesos el nombre del directorio remoto por listar, adems de la cadena que identifica la opcin. La capa de procesos le retorna los resultados de la ejecucin (una o varias cadenas) para que sean presentadas en pantalla. Adicionalmente a los datos resultantes, la capa de proceso enva a la capa de presentacin un entero que indica el xito o fracaso en la ejecucin de una tarea.

pag. 81

La capa de procesos, a su vez, enva a la capa de Base de Datos, una cadena que contiene una sentencia SQL para su ejecucin. El Sistema de Base de Datos le responde con una o ms cadenas correspondientes al resultado de la ejecucin de la sentencia SQL.

3.1.8

Aplicaciones de Escritorio (Presentacin).

El trmino flujo de trabajo o flujo de formas no es aplicable en el caso de la aplicacin ejemplo. En su lugar se presenta el prototipo de la interface de usuario (figura 3-3), encargada de la presentacin de las opciones principales de la aplicacin. Figura 3-6. Representacin inicial de la Interface de la Aplicacin. Forma Principal de la Aplicacin Opciones Principales
Conexin con el servidor Remoto Directorio de Trabajo Remoto Listado del Directorio Remoto Cambio de Directorio Copia de Archivo Remoto Ejecucin Remota de Sentencias SQL. Presentacin de Resultados en Excel

Va DDE

Presentacin de Resultados de una Consulta SQL en Excel.

Presentacin de Resultados Por pantalla.

Listado del directorio Remoto Consulta SQL. Resultado de la Operacin (xito o Error)

3.1.9

Capa de Procesos.

Los procesos de la capa son los que implementan las funciones establecidas en la especificacin. Obsrvese en el modelo de procesos inicial (figura 3-4) que no hay ninguna consideracin sobre aspectos fsicos de implementacin (plataforma operativa, equipos, etc.),

pag. 82

simplemente se han considerado los mdulos que implementan las funciones previamente especificadas. Figura 3-10. Diagrama de Procesos (Modelo Inicial).

Presentacin de la Aplicacin

Presentacin del Resultado en Excel

Interface con el Usuario

rcopy rcwd consultas SQL

rcd

rdir

Procesos

Base de Datos

pag. 83

En la figura 3-5 se presenta el diagrama de procesos definitivos antes de su implementacin. Ntese, en primer lugar, que se consideran aspectos relacionados con la plataforma operativa, y adicionalmente que la capa de procesos tiene componentes en cada una de las plataformas involucradas. Figura 3-11. Diagrama de Procesos Correspondiente al Nivel Fsico

W I N D O W S

Presentacin de la Aplicacin

Presentacin del Resultado en Excel Interface con el Usuario

Comunicacin Windows

rcwd

rcd rcopy

pag. 84

Procesos Base de Datos

pag. 85

Los procesos cliente (Windows) y servidor (Unix), encargados de manejar el proceso de establecimiento de la comunicacin y de la transmisin de informacin (empleando el conjunto de protocolos TCP/IP y la interface socket), puede representarse mediante mquinas de estados finitos (tal como se muestra en las figuras 3-6 y 3-7). Este tipo de representaciones es apropiada para aplicaciones cuyo protocolo de interaccin est bien definido y ordenado, tal como sucede con las aplicaciones para servidores y clientes FTP. El esquema de la aplicacin ejemplo se basa justamente en el esquema de una aplicacin FTP. Figura 3-12. Mquina de Estados Finitos para el Proceso Servidor encargado de manejar la comunicacin y el intercambio de informacin.

Recibe Solicitud de Conexin

conexin de Control Pendiente

Falla en la conexin

Comandos Pendientes
Conexin Exitosa Comandos Respuestas Solicitud Conexin de Datos Fallas en la conexin

Esperando Solicitudes de Conexin

Conexin de Control Establecida

Conexin de Datos Pendiente

Conexin de datos Exitosa

Conexin de Datos Establecida

Recepcin de Datos

Envo de Datos

pag. 86

Ntese la definicin de un canal destinado para el control de la comunicacin y otro canal para el intercambio masivo de datos. Ya se consignaron las razones (en el captulo de la especificacin de la aplicacin) que explican porque se gana flexibilidad por el hecho de tener dos canales separados (un canal de comunicaciones para el control de la misma y otro canal para el intercambio masivo de datos). Figura 3-13. Mquina de Estados Finitos para el proceso cliente encargado de manejar la comunicacin y el intercambio de informacin.

conexin de Control Pendiente

Inicia Conexin Falla en el intento

Comandos Pendientes
Conexin Exitosa Comandos Respuestas Inicia Conexin de Datos

No Conectado

Conexin de Control Establecida

Conexin de Datos Pendiente

Conexin de datos Exitosa

Conexin de Datos Establecida

Recepcin de Datos

Envo de Datos

Fallas en la conexin

pag. 87

El canal de datos es opcional, solamente ser necesario para los servicios que involucran un alto intercambio de informacin, como es el caso de los servicios rdir, rcopia y sql; para los otros casos, es suficiente (por la brevedad del servicio solicitado) con el establecimiento de un camino nico, de manera que para los servicios rcwd y rcd, la mquina de estado finito no incluye la parte correspondiente al establecimiento del canal de datos. Las conexiones son establecidas haciendo uso de la interface socket y de los protocolos de base TCP/IP entre procesos que se ejecutan en mquina enlazadas mediante una red Ethernet. Como se sabe, mediante TCP se establecen caminos virtuales entre las aplicaciones finales, sin importar que stas se ejecuten sobre plataformas diferentes. Para el caso de la aplicacin ejemplo, tomando como referencia la figura 3-6 (o la figura 3-7), el establecimiento del canal de control de comunicaciones (o de datos) tiene lugar entre dos aplicaciones (cliente y servidora) que operan sobre (Windows y Unix respectivamente). La aplicacin servidora que opera sobre Unix es de naturaleza concurrente, por lo que debe implementarse un mecanismo para la atencin simultnea de las solicitudes procedentes de los clientes. El mecanismo en mencin hace referencia al establecimiento de un proceso servidor maestro encargado nicamente del monitoreo de las solicitudes entrantes; el mismo proceso servidor maestro, una vez detecta una solicitud, crea un nuevo proceso hijo que se encargar de la atencin al cliente. El proceso servidor hijo hereda el canal de control establecido con el proceso cliente y adems es l (el proceso servidor hijo) quien inicia el establecimiento de un nuevo canal de datos, cada vez que el cliente haga una solicitud de un servicio que signifique intercambio intenso de informacin. El siguiente es el algoritmo correspondiente al proceso servidor maestro.
/******************************************/

pag. 88

/* ALGORITMO: PROCESO SERVIDOR MAESTRO */ /* ALGORITMO LLAMADO : Servidor_maestro() */ /******************************************/ PROGRAMA servidor_maestro { /* DEFINICIN DE VARIABLES */ Define socket_control: int Define resultado: int Define direccin_cliente, direccin_servidor /* APERTURA DE UN SOCKET ORIENTADO A CONEXIN */ socket_control = socket(orientado_conexin) /* CICLO INFINITO DE LECTURA DE PETICIONES DE CONEXIN */ mientras (1=1) { /* ACEPTA UNA CONEXIN */ accept(socket_control, direccin_cliente) /* CREACIN DE UN PROCESO HIJO PARA ATENDER AL CLIENTE */ resultado = fork() /* CDIGO DEL PROCESO HIJO */ SI resultado = hijo { proceso_hijo(socket_control) exit(0) } /* EL PADRE REGRESA AL CICLO DE ESPERA DE NUEVAS CONEXIONES */ } /* DEL CICLO INFINITO */ } /* DEL PROGRAMA PRINCIPAL */

La comunicacin entre el proceso cliente y el proceso servidor hijo, se basa en el protocolo FTP, en donde los datos que fluyen por el canal de control se componen de dos partes: una, el comando (conformado por los cuatro primeros bytes) y otra, el parmetro a procesar (de longitud variable). Segn sea el comando deber ser la accin a tomar. El proceso servidor hijo permanece en un ciclo infinito a la espera del arribo de nuevos datos por el canal de control. Slo cuando el dato sea una solicitud de finalizacin terminar el ciclo y el proceso servidor hijo finalizar. A continuacin se presenta el algoritmo para el proceso servidor hijo.
/*************************************/ /* ALGORITMO PROCESO SERVIDOR HIJO */ /* ALGORITMO LLAMADO : Servidor_hijo() /*************************************/ FUNCIN Servidor_hijo {

pag. 89

/* DEFINICIN DE VARIABLES */ Define cadena: char Define linea: char Define parmetro: char Define estructura direccion_datos { direccin char, puerto int } /* CICLO INFINITO */ mientras (1=1) { /* LEE EL MENSAJE PROCEDENTE DEL CLIENTE */ linea = leer(socket _control) /* COPIA LOS 4 PRIMEROS DATOS PROCEDENTE DEL CLIENTE */ cadena = str_copia(linea,4) /* COPIA EL RESTO DE LA CADENA A PARTIR DEL 5 BYTE */ parmetro = strN_copia(linea,5) /* ANALIZA EL COMANDO */ caso(cadena) { /* PETICIN DEL DIRECTORIO DE TRABAJO REMOTO */ SI cadena = PWD rcwd(parmetro)

/* PETICIN DE CAMBIO DE DIRECTORIO */ SI cadena = CWD rcd(parmetro) /* PETICIN DE ESTABLECIMIENTO DE UNA NUEVA CONEXIN (DATOS) OBTENCIN DE LA DIRECCIN Y DEL PUERTO EMPLEADAS EN ALGUNA DE LAS SOLICITUDES SIGUIENTES. */ SI cadena = PETICIN_CONEXIN dirccin_datos = obtener_direcc(parmetro) /* LISTADO DEL DIRECTORIO REMOTO */ SI cadena = LISTADO /* ESTABLECIMIENTO DE UN NUEVO CANAL DE DATOS */ conexion(socket_datos,direccion_datos) /* SE ENVA EL LISTADO POR EL SOCKET DE DATOS */ rdir(parmetro,socket_datos) desconexion( (socket_datos) /* COPIA DE UN ARCHIVO REMOTO */ SI cadena = RCOPIA conexion(socket_datos,direccion_datos) /* SE ENVA EL CONTENIDO DEL ARCHIVO POR EL SOCKET DE DATOS */ rcopia(parmetro,socket_datos)

pag. 90

desconexin(socket_datos) /* PETICIN DE TERMINACIN ANTICIPADA PARA EL SOCKET DE DATOS */ SI cadena = ABORT desconexin(socket_datos) /* PETICIN DE FINALIZACIN */ SI cadena = QUIT desconexin(socket_datos) desconexin(socket_control) FINALIZAR CICLO } /* DEL CICLO INFINITO */ } /* DE LA FUNCIN */

3.1.10 Capa de Base de Datos Dentro de los servicios prestados por la aplicacin servidora, se encuentra la opcin de navegar por la estructura de directorios remota. Esto brinda la posibilidad de hacer un recorrido hasta encontrar una Bases de Datos creada por el Administrador Informix, para abrirla y, luego de conocer su estructura, accederla mediante sentencias SQL. La metodologa para el diseo de aplicaciones distribuidas, propone la planeacin, diseo e implementacin de transacciones y consultas (hechas a la medida) para la modificacin y acceso a la informacin, claro est que la metodologa supone la existencia de una sola (y robusta) Base de Datos posterior. Sin embargo la aplicacin ejemplo ha sido concebida para permite el acceso dinmico a diferentes Bases de datos creadas mediante el uso del Administrador de Bases de Datos Relacionales Informix para Unix, por lo que en este caso no es congruente el diseo a la medida de transacciones y consultas. Segn la teora Relacional, una Base de Datos debe tener asociado un catlogo. El catlogo es el mecanismo que permite entre otras cosas: conocer la estructura de la base de datos, las tablas que la conforman, los atributos e ndices de cada tabla, las claves principales o primarias, las claves forneas (un campo de una tabla que es clave principal en otra: las claves forneas permiten el establecimiento de relaciones), los usuarios, etc. El propio catlogo (segn lo exige el modelo Relacional) deber representarse como tablas relacionadas de alguna manera (conocidas como tablas del sistema). En la figura 3-8 se
pag. 91

hace una representacin parcial del catlogo de una Base de Datos Informix. El Administrador de Bases de Datos crea automticamente el catlogo cuando se ejecuta una sentencia de creacin de una Base de Datos. Figura 3-21. Representacin mediante Diagramas Entidad -Relacin de algunas tablas del catlogo de una Base de Datos creada por el Administrador de Base de Datos Informix para Unix. sysusers

systables

sysindexes systabauth

syscolumns

sysviews

La tabla sysusers guarda informacin sobre los usuarios de la base de Datos. Los principales atributos son: username (nombre) que es la clave principal, usertype (tipo de usuario) y password (clave de acceso). La tabla systables almacena informacin sobre todas las tablas que hacen parte de la Base de Datos. Los principales atributos son: tabname (nombre de la tabla), owner (propietario)
pag. 92

clave fornea para usuario, tabid (nmero identificador de la tabla) que es la clave principal, nrows (nmero de filas), ncol (nmero de columnas en la tabla). Tomando una parte del diagrama E-R presentado en la figura 3-8, en particular la que atae a las tablas sysusers y systables, se aprecia que entre ellas se ha establecido una relacin que tiene una cardinalidad de uno a muchos, lo que en trminos prcticos significa que un usuario puede tener (o ms correctamente ser propietario de) una o muchas tablas. El valor de la clave primaria del usuario (en sysusers) puede aparecer en una o ms filas de la tabla systables (como clave fornea). La tabla syscolumns contiene informacin sobre todas las columnas de cada una de las tablas que hacen parte de la Base de Datos. Entre otros tiene los siguientes atributos: colname (nombre de la columna o atributo), tabid (nmero identificador de la tabla a la que pertenece) clave fornea para systables, colno (posicin de la columna dentro de la tabla), coltype (tipo de la columna), collength (longitud de la columna). La clave principal de esta tabla es combinada: tabid junto con colno. La tabla sysindexes contiene informacin sobre los ndices en cada tabla, y la tabla systabauth almacena informacin sobre las autorizaciones concedidas o revocadas sobre una tabla. El catlogo contiene otras tablas, cada una con informacin clave, de manera que el Manejador de la Base de Datos pueda adelantar su trabajo de administracin. La consideracin realizada en los prrafos anteriores sobre el catlogo, obedece a que l permite conocer cul es la estructura de una base de datos antes de accederla, y la forma de hacerlo es justamente mediante la ejecucin de sentencias SQL (ejecucin de sentencias SELECT sobre el propio catlogo). Por ejemplo, si se quisiera conocer cules son las tablas que conforman la Base de Datos, la consulta sobre el catlogo sera:
SELECT tabname, tabid FROM systables

pag. 93

Supngase que despus de ejecutar la sentencia anterior se descubre la existencia (entre otras) de una tabla llamada alumno cuyo nmero identificador (tabid) es 100, entonces la sentencia:
SELECT colname FROM syscolumns WHERE tabid = 100

Permite conocer cules son los atributos de la tabla alumno. Una vez se conocen los atributos de las tablas y sus relaciones, es posible comenzar a ejecutar sentencias SQL sobre ellas. Esta es la estrategia empleada en la aplicacin ejemplo para el acceso dinmico a las Bases de Datos residentes en el servidor.

IMPLEMENTACIN.

En esta seccin se presentan los aspectos ms importantes de la implementacin de las aplicaciones servidora y cliente.

3.1.11 Aspectos elementales de la configuracin de la red. Sobra mencionar aspectos relacionados con la configuracin de una tarjetas de red particular, mxime cuando la tendencia del hardware es hacia la facilitacin del reconocimiento automtico por parte del sistema operativo (Plug and Play). La red conformada para el ejemplo es una red Ethernet 10 Base 2 elemental, con un bus lineal formado por cable coaxial delgado (RG-58) de 50 Ohmios. El sistema operativo empleado para la implementacin de la aplicacin servidora es SCO Unix System V Release 3 versin 5 . Como se anot en el captulo de las especificaciones, esta versin adems del Sistema Operativo Unix Bsico incluye (entre otros productos), el Sistema de Desarrollo y el soporte para redes TCP/IP
pag. 94

El proceso de configuracin de la interface de red para la mquina servidora estar cargo del root (superusuario del sistema) invocando la utilidad netconfig, que es un shell script que gua paso a paso solicitando la informacin necesaria. netconfig , entre otros aspectos, permite establecer la direccin IP de la interface de red, que en este caso se eligi arbitrariamente como 192.168.169.170. Recurdese que es posible escoger una direccin IP libremente, siempre que no se vayan a efectuar conexiones con otras redes externas. En la aplicacin ejemplo, la mquina Unix simplemente se conectar (a travs del bus coaxial) a la mquina Windows (cuya direccin se eligi como 192.168.169.171). Despus del proceso de instalacin, netconfig reportar la presencia, al menos, de dos interfaces de red: la interface Loopback (reportada como SCO TCP/IP Loopback, que es indispensable para el acceso a los servicios de red y para la realizacin de pruebas locales de aplicaciones de red) y la interface Ethernet recientemente instalada (en este caso particular reportada como IBM LAN Adapter for Ethernet NE2000 Compatible I/O Addres 300). Posteriores llamadas a netconfig permiten la adicin de nuevas interfaces (Ethernet o seriales), o la modificacin de las ya existentes. La utilidad netconfig tambin altera los archivos necesarios para la operacin adecuada de la red. Entre otros el archivo hosts que se encuentra bajo el directorio /etc. Luego del proceso de instalacin previo, el archivo host tendr el siguiente contenido:
# @(#)hosts 6.1 8/21/93 - STREAMware TCP/IP source # SCCS IDENTIFICATION 127.0.0.1 localhost 192.168.169.170 servidor servidor.UUCP.com

Este archivo deber modificarse (mediante un editor de texto corriente como vi-) de manera que incluya una lnea por cada nodo de la red que se desee acceder. En el caso de la red para la aplicacin ejemplo, el contenido definitivo del archivo ser:

# @(#)hosts 6.1 8/21/93 - STREAMware TCP/IP source # SCCS IDENTIFICATION 127.0.0.1 localhost 192.168.169.170 servidor servidor.UUCP.com

192.168.169.171

cliente

pag. 95

Al iniciar una nueva sesin, deber notarse el reconocimiento de la interface de red. En el momento del arranque (boot), el sistema reportar (adems de los elementos corrientes como procesador, memoria, disco duro, unidad de disco flexible, etc.) la presencia de la tarjeta mediante una lnea como la siguiente:
%nat 0X300-0X031F 10 type=Infomover addres=00:40:05:11:78:a0

Que indica (en su orden) la direccin I/O, el vector de interrupcin utilizado, el tipo de la tarjeta y la direccin (propia de la tarjeta dentro del conjunto de direcciones asignadas al fabricante, que no guarda relacin alguna con la direccin IP) Para la parte complementaria (plataforma operativa Windows 3.11), deber considerarse en primer lugar que Windows 3.11 no incluye el soporte de la pila de protocolos TCP/IP (el conjunto de protocolos (nativo) para las comunicaciones en red es NETBEUI (aunque tambin podra instalarse el conjunto de protocolos IPX/SPX). Existen implementaciones comerciales (y otras de libre distribucin) del conjunto de protocolos TCP/IP y de la interface socket para Windows 3.11. En la aplicacin ejemplo se utiliz Trumpet Winsock (que se acoge al estndar propuesto para la API de Windows socket). Trumpet Winsock se consigue como un conjunto de libreras .dll que se instalan mediante una utilidad llamada tcpman. Esta utilidad permite, al igual que su par para Unix netconfig, el establecimiento de la direccin IP de la interface de red ( 192.168.169.171) y la definicin de las lneas del archivo hosts. Las tarjetas de red vienen con un manejador (driver) de paquetes que hace posible su utilizacin en programas de red. Por lo general el fabricante provee el driver o en caso contrario existen distribuidores especializados en este tipo de software. Una vez cargado el driver (en el proceso de arranque del sistema D.O.S.) la interface de red est habilitada para su operacin en red, pero adicionalmente es necesario cargar WINPKT, que es una interface virtual para el manejador de paquetes desde Windows 3.11. Para el caso de la aplicacin ejemplo, las siguientes lneas deben hacer parte del archivo de inicio autoexec.bat (inmediatamente antes de cargar Windows):

pag. 96

meth16pd 96 -w winpkt 0X60

La primera carga el driver de paquetes (provisto por el fabricante) para la interface de red empleando el vector 96 (60 hexadecimal). La segunda lnea carga la interface virtual para el manejador de paquetes desde Windows 3.11. Por ltimo, y debido a que se presentan conflictos entre la pila de protocolos de red de Windows 311 y la pila de protocolos TCP/IP de Trumpet Winsock, cada sesin de Windows deber inciarse sin el soporte de red, invocando el siguiente comando desde el prompt del sistema:
Windows /n

Siguiendo las anteriores instrucciones, la red para la aplicacin ejemplo que emplea para sus comunicaciones la pila de protocolos TCP/IP ya est configurada.

3.1.12 Implementacin de la Aplicacin Servidora en Unix. La herramienta para la implementacin es el lenguaje C. El proceso servidor maestro se implementa mediante una funcin llamada servi.c El proceso servidor hijo se implementa mediante un mdulo llamado servicios.c que contiene las siguientes funciones: rdir() rcd() rcwd() rcopia() obtener_direcc() obtener_puerto() Bsicamente, las funciones son las mismas que se presentaron en el captulo de las especificaciones. Las funciones obtener_direcc() y obtener_puerto() permiten conformar

pag. 97

la direccin IP y el nmero de puerto segn la informacin que la aplicacin cliente enva para el establecimiento del canal de datos. La funcin conexion(), como su nombre lo sugiere, establece un canal de comunicaciones (socket) con un proceso remoto, del que se conoce su direccin IP y su nmero de puerto; la funcin retorna un descriptor mediante el cual, la funcin llamante tendr acceso del canal. El mdulo que rene las funciones del servidor hijo puede compilarse para producir un archivo objeto (que puede ser encadenado con otras aplicaciones que deseen acceder a las funciones ofrecidas por l), mediante la siguiente instruccin (tecleada desde el prompt):
cc -c servicios.c -lsocket

Obsrvese que se incluye la Liberia socket. Algunas utilidades de propsito general (como aquellas para el manejo de cadenas) se agruparon bajo el mdulo util.c. Como en el caso anterior, el mdulo puede compilarse para producir un archivo objeto (cc - c util.c.) El programa principal que inicia el proceso servidor se obtiene mediante la siguiente instruccin (dada desde el prompt):
cc servi2.c servicios.o util1.o -o servi2 -lsocket.

Mediante esta lnea se invoca al compilador de C y se hace el encadenamiento con los archivos objetos previamente obtenidos y con la librera socket. El nombre del archivo de salida es servi2. El cdigo fuente que implementa al proceso servidor maestro (servi2.c), el proceso servidor hijo (servicios.c) y las utilidades (util.c) puede verse en el Anexo 1.

3.1.13 Implementacin de las Bases de Datos. Las Bases de Datos se crean mediante el administrador Informix para Unix, que se invoca mediante el comando isql. El programa presenta una interface de manejo intuitivo (orientada al texto), con un men de opciones que permite, entre otras cosas la creacin de
pag. 98

una Base de Datos en forma interactiva (siguiendo el camino de opciones DATABASE y CREATE). Otra forma de crear la estructura de la Base de Datos es mediante el uso de Sentencias SQL DDL (Lenguaje de Definicin de Datos) haciendo uso del editor de sentencias SQL (Opcin Query-Language del men principal). Al entrar a la opcin Query-Language se pregunta sobre el nombre de la Base de Datos a la cual estarn asociadas las sentencias SQL subsiguientes. Pero si lo que se desea es, justamente, crear una nueva Base de Datos, se ignora tal demanda pulsando la tecla de interrupcin (Delete), entonces es posible digitar y ejecutar una sentencia SQL o un conjunto de ellas, como en el siguiente ejemplo:
{CREACIN DE LA BASE DE DATOS LLAMADA PRUEBA} CREATE DATABASE prueba; {CREACIN DE LAS TABLAS } CREATE TABLE municipio (codigo_mpio INT, nombre_mpio CHAR(20) NOT NULL, PRIMARY KEY codigo_mpio); CREATE TABLE alumno(cedula nombre_al direccin telefono lugar_nac fecha_nac PRIMARY KEY FOREIGN KEY INT, CHAR(20) NOT NULL, CHAR(20), CHAR(10), INT, DATE, cedula, lugar_nac REFERENCES municipio)

En este ejemplo, por razones de eficiencia se ha establecido una relacin entre las tablas municipio y ciudad, a travs de un campo comn a cada tabla (codigo_mpio en la tabla municipio y lugar_nac en la tabla alumno). Se dice que la tabla municipio es dominante con respecto a alumno, por que el valor de su clave primaria (codigo_mpio) puede aparecer en una o ms filas de la tabla alumno (como el campo lugar_nac). Si la ejecucin de las tres sentencias SQL anteriores tiene xito, entonces se dispondr de una nueva Base de Datos llamada prueba con las tablas referidas. Pero adicionalmente, el Administrador de la Base de Datos crea automticamente el catlogo asociado. Los archivos que conforman el catlogo y las tablas explcitamente creadas residen en un directorio (directorio de datos) que guarda el mismo nombre de la base con la extensin .dbs.

pag. 99

La aplicacin ejemplo, que permite que un cliente Windows 3.11 navegue por la estructura de directorios Unix, supone que ha encontrado una Bases de Datos creada mediante Informix cuando encuentra un directorio con la extensin .dbs (se asumen por ejemplo, que el directorio prueba.dbs es el directorio de datos de la Base de Datos llamada prueba). Una vez encontrado el directorio de datos, es posible enviar sentencias SQL para acceder a la Base de Datos.

pag. 100