2

3
4
Agradecimientos
Ante todo debo agradecer a mis Padres Guadalupe Ibarra Zurita y Jose Manuel Borrego Hernandez por
su cari no y apoyo para salir a delante con mis estudios.
A mi Director de tesis el Dr. Eustorgio Meza Conde por su apoyo y amistad. Gracias por ayudarme a
forgar mi caracter, a tener disciplina, a no temer a nada en la vida y por ense narme a ser mas objetivo al
realizar mi proyecto.
Agradezco a mi compa nero y amigo M.C. Rogelio Ortega Izaguirre por sus incontables consejos y por com-
partir conmigo su conocimiento y experiencia. Ademas, le agradezco profundamente por las interminables
horas de trabajo que me permitieron concluir exitosamente este proyecto de investigacion.
Al Centro de Investigaci on en Ciencia Aplicada y Tecnologa Avanzada, Unidad Altamira por todos los
recursos academicos y nancieros que fueron destinados a este trabajo de Investigaci on y a su director el
Dr. Felipe de Jes us Carrillo Romo por su apoyo.
Al Centro Nacional de Ciencia y Tecnologa por la beca de estudios que me otorgo y por los recursos que
aporto al proyecto Red de Observaciones y Pronosticos de Variables Oceanicas en las Costas y Puertos del
Golfo de Mexico (ROPVO-GM) del cual esta tesis forma parte.
A mi jurado de tesis: Dr. Javier Arturo Montes de Oca Valero, Dr. Orzo Sanchez Montante, Dr. Miguel

Angel Arronte Garca y el Dr. Miguel Antonio Domnguez por su amistad y tiempo invertido en la revision
de este trabajo de investigaci on.
A mis amigos Alejandro Olivares Torres, Alejandro Davila Pe na, Adan Hernandez Sanchez, Hernan Per-
aza Vazquez, Aldo Hernandez Olivares, Juan Rodriguez Azuara, Pedro Jacobo Perez Vega y a todo el
escuadron del CICATA-IPN Unidad Altamira por su amistad y apoyo.
Esta investigacion recibio el apoyo del Consejo Nacional de Ciencia y Tecnologa (CONACYT) a traves
del proyecto 39382-U y la Coordinacion de Posgrado e Investigacion (CGPI) de Mexico Instituto Po-
litecnico Nacional a traves de los proyectos 20030593, 20040488, 20050768.
5
Contenido
Lista de Figuras iv
Lista de Tablas vi
Resumen vii
Abstract viii
Glosario ix
1 Introduccion 1
1.1 Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Justicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Objetivos especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Organizacion del Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Marco Te orico 10
2.1 Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Sistemas Distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Arquitectura Cliente/Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Arquitecturea Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Protocolos de comunicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Sistema Mutella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Especicaciones del protocolo Genutella V0.4 . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 El Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 La Word Wide Web (WWW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 El lenguaje HTML y localizar URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Sistemas de Informacion Basados en Web (SIBW) . . . . . . . . . . . . . . . . . . . 17
2.5 Esquemas de metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Modelo en Cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
i
3 Metodologa 21
3.1 Metabase de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 B usqueda Distribuida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Interfaz de B usqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Intermediario Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Componente de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.4 Presentaci on de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Consulta Distribuida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Interfaz de Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Intermediario de Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.3 Extraccion de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.4 Presentaci on de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Resultados 45
4.1 Metabase de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1 Denicion del Esquema de Metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.2 Creacion de la Metabase de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.3 Creacion del Diccionario de Terminos . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.4 Creacion del Deposito de Metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.5 Creacion del Deposito Temporal de Metadatos . . . . . . . . . . . . . . . . . . . . . 50
4.2 Proceso de B usqueda Distribuida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.1 Acceso a la Interfaz de B usqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.2 Intermediario Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.3 Proceso de B usqueda Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.4 Proceso de B usqueda Remota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.5 Resultados de la B usqueda Distribuida . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 Proceso de Consulta Distribuida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1 Acceso a la Interfaz de Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.2 Formulacion de la Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.3 Proceso de Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.4 Proceso de Extraccion de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.5 Resultados de la Consulta Distribuida . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Pruebas 71
5.1 Objetivos de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 Descripcion del Ambientes de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3 Casos de Prueba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.1 Prueba No. 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.2 Prueba No. 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.3.3 Prueba No. 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4 Otras Pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
ii
6 Conclusion y discusion 83
6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.2 Alcances Logrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.3 Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Bibliografa 88
iii
Lista de Figuras
1.1 Arquitectura de herramienta de acceso a base de datos. . . . . . . . . . . . . . . . . . . . . 3
1.2 Arquitectura de herramienta de acceso a multibases de datos. . . . . . . . . . . . . . . . . 4
2.1 Arquitectura Cliente/Servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Arquitectura Peer to Peer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Ciclo de vida del modelo en Cascada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Componentes de la Metabase de Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Componentes de la B usqueda Distribuida. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Componente de Comunicaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Subcomponente de B usqueda Local. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Diagrama de ujo de la funcion Analizador Lexico. . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Diagrama de ujo de la funcion Construccion de la Instruccion SQL. . . . . . . . . . . . . . 30
3.7 Diagrama de ujo que muestra el proceso para la extraccion de los metadatos. . . . . . . . 31
3.8 Subcomponente de B usqueda Remota. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.9 Ejemplo de la matriz de memoria que almacena los metadatos de los recursos que el usuario
del sistema desea consultar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.10 Componentes del Proceso de Consulta Distribuida. . . . . . . . . . . . . . . . . . . . . . . 36
3.11 Diagrama de ujo que muestra el proceso para la creacion de un conjunto de estaciones que
tienen un recurso en com un. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.12 Ejemplo de una matriz de metadatos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.13 Secciones de la Interfaz de Consulta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.14 Diagrama de ujo que muestra el proceso de creacion de la lista de estaciones. . . . . . . . 41
3.15 Diagrama de ujo que muestra el proceso para la extraccion de datos. . . . . . . . . . . . . 42
3.16 Ejemplo del dise no del archivo de texto para la presentacion de resultados. . . . . . . . . . 43
3.17 Ejemplo del dise no del archivo graco para la presentaci on de resultados. . . . . . . . . . . 44
4.1 Lnea de comando utilizada para la creacio n de la base de datos DBmetadatos. . . . . . . . 47
4.2 Lnea de comando utilizada en la creacion de la relacion stations. . . . . . . . . . . . . . . 48
4.3 Lnea de comando utilizada para la creacion de la relacion resource. . . . . . . . . . . . . . 48
4.4 Lnea de comando utilizada en la creacion de la relacion DataResource. . . . . . . . . . . . 49
4.5 Lnea de comando utilizada en la creacion de la relacion TempDataResource. . . . . . . . . 51
4.6 Interfaz de B usqueda de Recursos Distribuidos sobre Internet. . . . . . . . . . . . . . . . . 51
4.7 Interfaz para el registro de Estaciones Mareogracas. . . . . . . . . . . . . . . . . . . . . . 52
4.8 Interfaz para el registro de Diccionario de Recursos. . . . . . . . . . . . . . . . . . . . . . . 53
4.9 Interfaz para el registro de Comparticion de Recursos Oceanogracos. . . . . . . . . . . . . 53
iv
4.10 Funciones del Intermediario Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.11 Fragmento de codigo que ejemplica el paso de parametros de solicitud de b usqueda local
al componente Analizador Lexico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.12 Fragmento de codigo que ejemplica la deteccion de estaciones. . . . . . . . . . . . . . . . . 57
4.13 Fragmento de codigo que ejemplica la deteccion de recursos. . . . . . . . . . . . . . . . . . 58
4.14 Fragmento de codigo que ejemplica la construccion de la cadena SQL. . . . . . . . . . . . 59
4.15 Fragmento de codigo que ejemplica la ejecucion de la cadena SQL. . . . . . . . . . . . . . 60
4.16 Fragmento de codigo que ejemplica el almacenamiento temporal de metadatos. . . . . . . 61
4.17 Fragmento de codigo que ejemplica el paso de parametros de solicitud de b usqueda remota
al componente AnalizadorLexico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.18 Interfaz Web que muestra los metadatos que se obtuvieron del proceso de B usqueda de
Recursos Distribuidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.19 Interfaz Web de la estacion mareograca de Tampico, Tamaulipas. . . . . . . . . . . . . . . 64
4.20 Fragmento de codigo que ejemplica la creacion de un conjunto de estaciones que tienen un
recurso en com un. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.21 Interfaz Web para la Consulta de Recursos Distribuidos. . . . . . . . . . . . . . . . . . . . 66
4.22 Fragmento de codigo que ejemplica el proceso para la creacion del formato para la lista de
estaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.23 Fragmento de codigo que ejemplica el Proceso de Extraccion de Datos. . . . . . . . . . . . 68
4.24 Interfaz Web que muestra en forma de graca los datos extraidos de la estacion mareograca
de Tampico Tamaulipas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.25 Interfaz Web que muestra en forma de texto los datos extrados de la estacion mareograca
de Tampico Tamaulipas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1 Ambiente de pruebas n umero Uno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Ambiente de pruebas n umero Dos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Ambiente de pruebas n umero Tres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4 Interfaz de B usqueda de Recursos Distribuidos sobre Internet. . . . . . . . . . . . . . . . . 75
5.5 Interfaz que muestra los resultados de la B usqueda de Recursos Distribuidos sobre Internet. 76
5.6 Interfaz Web para la Consulta de Recursos Distribuidos. . . . . . . . . . . . . . . . . . . . 77
5.7 Graca que muestra los datos extrados de las estaciones de Mezquital, la Pesca y Tampico. 77
5.8 Interfaz que muestra los resultados de la B usqueda de Recursos Distribuidos sobre Internet. 78
5.9 Graca que muestra los datos extrados de las estaciones de Mezquital, la Pesca, Tampico
y Veracruz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.10 Interfaz que muestra los resultados de la B usqueda de Recursos Distribuidos sobre Internet. 81
5.11 Graca que muestra los datos extrados de las estaciones de Mezquital, la Pesca, Tampico,
Tuxpan y Veracruz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
v
Lista de Tablas
3.1 Ejemplo de una relacion de metadatos para la descripcion de los recursos almacenados en
un nodo de la comunidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Ejemplo de lista de claves y descripcion de recursos. . . . . . . . . . . . . . . . . . . . . . 34
3.3 Relacion de la matriz de metadatos M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Esquema de metadatos tomados del estandar FGDC, los cuales fueron seleccionados para
la relacion de metadatos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Estructura de la relacion stations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Estructura de la relacion resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Estructura de la relacion DataResource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Estructura de la relacion TempDataResource. . . . . . . . . . . . . . . . . . . . . . . . . . 50
vi
Resumen
En este trabajo se obtuvo una arquitectura y una herramienta de software para la b usqueda y consulta
de recursos distribuidos sobre Internet. El objetivo principal de esta herramienta es extraer los recursos
compartidos por diferentes organizaciones a traves de Internet, donde cada organizacion se considera como
un nodo. La creacion de la arquitectura de software incluyo el dise no y desarrollo de las siguientes 5 fases
principales: un portal Web de b usqueda y uno de consulta, la metabase de datos, el proceso de b usqueda
distribuida y el proceso de consulta distribuida. El portal Web de b usqueda permite al usuario realizar por
medio de atributos de recursos oceanogracos la b usqueda de recursos distribuidos a traves de Internet. La
metabase de datos cumple con el objetivo de almacenar los metadatos de los recursos que se desean com-
partir por una organizacion. El dise no del esquema de metadatos esta basado en el estandar de metadatos
FGDC, el cual se implemento posteriormente en una base de datos. El proceso de b usqueda distribuida
se encarga de propagar la solicitud de b usqueda del usuario y extraer los metadatos de los recursos desde
los nodos. Se utilizo el sistema peer-to-peer Mutella como motor de transferencia de recursos distribuidos
mediante el protocolo de comunicaci on Gnutella. El proceso de consulta distribuida se encarga de extraer
los datos de los recursos localizados por el proceso de b usqueda distribuida de los nodos. Se dise naron
y desarrollaron interfaces Web, para la consulta de recursos distribuidos, para habilitar el mecanismo de
extraccion remota de datos, y para la presentacion de los resultados al usuario.
El desarrollo de la herramienta demostro ser un medio de consulta de datos oceanogracos util para la
sociedad en general, ya que tiene el potencial de ayudar tanto en las actividades de investigaci on como en
las actividades operacionales que resguardan la seguridad en los puertos y la proteccion civil proximas a
la costa, facilitando el acceso a la informacion del clima oceanico en tiempo aproximado al real a traves
de Internet. A manera de ejemplo, se realizaron diversas pruebas con datos extrados de las estaciones
mareogracas ubicadas en Tampico, Mezquital y la Pesca Tamaulipas, administradas por la Secretara de
Marina, vericando la eciencia del sistema propuesto.
vii
Abstract
The present work shows the architecture and the software tool developen to performe both distributed
search and distributed consultation of resources on Internet. The main objective of this tool is to extract
the resources shared by dierent organizations through Internet, where each organization is considered
as a node. The creation of the software architecture includes the design and development of the next 5
main phases: a web searchingportal and web consultation, a data metabase, distributed search process
and distributed consultation. The web search portal allows user to carry out searching of distributed
resources through Internet by means of attributes of oceanographic resources. The data metabase ful-
lls the objective of storing metadatas of the shared resources from an organization. The design of the
metadata scheme is based on the metadata standard FGDC, which was implemented later as a database.
The process of distributed search will propagate the search query the application of the user and extracts
the metadatas of the resources from the nodes. The Mutella peer-to-peer system has been used as the
transfer engine motor of the distributed resources using Gnutella as communication protocol. The process
of distributed consultation extracts the data of the resources located by the process of distributed search
of the nodes. The following web interface were designed: web for consultation of distributed resources,
remote extraction of data, and results presentation to users.
The developed tool has demostrated to be a useful medium for consultation of oceanographic resources.
It can be use not only for scientic studies but as other mechanism to take safe decisions relating operations
in port, civil protection and others, taking into a account the near real time ocean to the data that can
be archieved with this tool. As an example, it was carried out a real tests by extracting data from tidal
stations, which are located in Tampico, Mezquital and La Pesca Tamaulipas, all of them were carry out
by Secretara de Marina and it was verifyed the eciency of the proposed system.
viii
Glosario
Actividad intermitente de los nodos. Proceso en donde las conexiones de los nodos ROPVO se
interrumpen, o cesan y luego contin uan o se repiten.
Base de Datos. Es un conjunto de datos operacionales almacenados, que pueden ser usados por aplica-
ciones de sistemas de alguna empresa en particular.
Caracter. Cualquier signo tipograco. Puede ser una letra, un n umero, un signo.
Componente. Parte discreta de un sistema capaz de operar independientemente, pero dise nada, con-
struida y operada como parte integral del sistema.
Comunidad ROPVO. Conjunto de organizaciones o instituciones que comparte el interes de compartir
recursos e informacion oceanograca a traves de internet.
DBI. La interfaz a base de datos (DBI, por sus siglas en ingles), es un conjunto de funciones que permiten
a los programas realizados con el lenguaje de programacion perl establecer conexion a diferentes bases de
datos y ejecutar sentencias SQL.
Funci on. Es el termino para describir una secuencia de ordenes que hacen una tarea especca de una
aplicacion mas grande.
Interfaz. Termino usado en los conceptos de hardware y software que permite la conexion entre dos o
mas elemento de la misma naturaleza.
JDBC. La Conectividad de Bases de Datos Java (JDBC, por sus siglas en ingles) es un conjunto de
funciones que permiten a los programas Java establecer conexion a diferentes bases de datos y ejecutar
sentencias SQL. JDBC permite a los programas Java interactuar con la mayora de las base de datos
compilada en SQL. Actualmente la mayora de los sistemas manejadores de bases de datos relacional
ix
soportan SQL. JDBC fue desarrollado por JavaSoft que es una sucursal de Sun Microsystems.
Metadato. Los metadatos son datos altamente estructurados que describen informacion de la informacion
o datos sobre los datos. Los metadatos describen quien, como y cuando han sido obtenidos un conjunto de
datos en particular. Los metadatos son esenciales para entender la informacion almacenada en un Sistema
de Informacion.
Multitarea. Facultad de ejecutar mas de una tarea a la vez en uno o varios procesadores.
MySQLConnect. Establece una conexion a un servidor MySQL. Todos los argumentos son opcionales,
y si no hay, se asumen los valores por defecto.
Nodo. Una computadora, union o punto de conexion en una red. Puede referirse a un solo dispositivo,
es decir, un interruptor limitador particular.
Proceso. Conjunto de actividades realizadas en forma secuencial que permiten transformar uno o mas
insumos en un producto o servicio.
Recurso. es un dato o conjunto de datos, pagina Web, imagenes, etc.
Relacion. Es el termino matematico dado para una tabla. Una relacion esta constituida de atributos,
dominios y tuplas. Una relacion de dominios D1, D2, .. Dn (no necesariamente todos distintos) consiste
de un encabezado y de un cuerpo.
Servent. Aplicacion de software que realiza la funcion de cliente y servidor simultaneamente.
Socket. Interfaz que ofrece un mecanismo de comunicacion general entre dos procesos cualquiera que
pertenezcan a un mismo sistema o ha dos sistemas diferentes.
Tubera. Son conexiones entre procesos. La salida de un proceso se encadena con la entrada de otro, esto
permite procesar los datos en una sola lnea de comandos.
x
Captulo 1
Introduccion
Hoy en da los sistemas de informacion proporcionan la comunicaci on y poder de analisis que muchas
empresas e instituciones requieren para llevar a cabo la administracion de la informacion a una escala
global. Prueba de ello, es el creciente interes que se ha observado en importantes organizaciones alrededor
del mundo como: la Red de Datos Marinos en el Mediterraneo (MEDAR, por sus siglas en ingles), el
Directorio de Datos Marinos (EDMED, por sus siglas en ingles), la Red de Observaciones Oceanicas en las
Costas de Texas (TCOON, por sus siglas en ingles) y en particular la Red de Observaciones y Predicciones
de Variables Oceanicas (ROPVO) en el Golfo de Mexico (GM) entre otros [1].
En la actualidad se estan realizando esfuerzos por administrar y compartir recursos oceanogracos
entre TCOON y ROPVO-GM. TCOON es una infraestructura compuesta de mareografos y satelites,
computadoras y el Sistema de Informacion Basado en Web (SIBW), Pharos. TCOON fue construido y es
operado por el Conrad Blucher Institute Division of Nearshore Research (CBI-DNR) en la Texas A&M
University-Corpus Christi (TAMUCC). TCOON esta integrado por 42 plataformas para la recoleccion de
datos de nivel del mar y meteorologicos que se mantienen bajo los estandares del Servicio Oceanico Na-
cional (NOAA, por sus siglas en ingles)[2]. El sistema Pharos es una herramienta de software que permite
poner a disposicion del p ublico en general datos oceanogracos en tiempo aproximado al real [3].
Por otra parte ROPVO es una infraestructura en desarrollo que esta compuesta de mareografos, equipo
1
CAP

ITULO 1. INTRODUCCI

ON 2
modem celular y computadoras. Actualmente los datos recolectados por sus mareografos son administra-
dos con el sistema Pharos donado por TAMUCC. Las organizaciones que participan en el proyecto ROPVO
son el Centro de Investigaci on en Ciencia Aplicada y Tecnologa Avanzada Unidad Altamira del Instituto
Politecnico Nacional (CICATAUA-IPN), TAMUCC, Universidad Nacional Autonoma de Mexico (UNAM),
Secretara de Marina (SEMAR) y Servicio Meteorologico Nacional (SMN) a los cuales nos referiremos en
este documento como la comunidad ROPVO . Cada uno de los organismos cuenta con sus propios recursos
oceanogracos que son bases de datos, archivos de texto, imagenes, gracas, sonido y video. Es impor-
tante aclarar que el proyecto ROPVO-GM es nanciado por el Consejo Nacional de Ciencias y Tecnologa
(CONACyT) a traves del CICATAUA-IPN en Altamira, Tamaulipas, realizado por E. Meza Conde et al.
[4]. Este trabajo de tesis forma parte del proyecto ROPVO-GM. El objetivo de este trabajo fue desar-
rollar e implementar una arquitectura de software para la b usqueda y consulta de recursos oceanogracos
distribuidos en la comunidad ROPVO, que se incorporara al proyecto ROPVO-GM y que servira como
motor de transferencia de recursos distribuidos a traves de Internet mediante el uso de metadatos de los
recursos oceanogracos.
Nota: Dada la naturaleza del tema y del proyecto de investigaci on, en este manuscrito se emplean
muchos terminos en ingles, algunos de ellos traducidos, pero la mayor parte formaran parte del texto sin
traduccion alguna.
1.1 Estado del Arte
La primera Herramienta de Consulta Basada en Ejemplos (QBE, por sus siglas en ingles) para una Base
de Datos en Internet fue realizada por F. Rasgado [5]. Esta herramienta permite consultar bases de datos
generadas con el Sistema Manejador de Bases de Datos Distribuidas (SiMBaDD). Una de las razones por
la que las bases de datos son implementadas con SiMBaDD se debe a que la herramienta debe presentar
al usuario informacion detallada de la denicion de la base de datos, ademas de informacion adicional,
para que el usuario seleccione las tablas y columnas que le pueden servir para formular su consulta. La
CAP

ITULO 1. INTRODUCCI

ON 3
informacion adicional se reere a datos como unidades de medida, formato de fecha y descripcion de las
columnas y de las tablas.
La arquitectura de esta herramienta, gura 1.1, incluye el uso de un servidor intermediario, un servidor
de bases de datos, un servidor Web y un applet que es una interfaz Web. En este caso la funcion principal
del intermediario es reexpedir la consulta denida en la interfaz QBE hacia el SiMBaDD. Si existe un re-
sultado, este es enviado al intermediario, quien a su vez lo reenva al applet. Otro motivo de la existencia
del intermediario es para resolver el problema de la conexion con bases de datos que no estan en la misma
maquina en la que reside el servidor Web de donde se descargo el applet de la interfaz Web. Sin el servidor
intermediario las bases de datos no podran ser consultadas por las restricciones de seguridad de los applets.
Figura 1.1: Arquitectura de herramienta de acceso a base de datos.
Continuando con los estudios relacionados en el lenguaje de QBE en el a no 2000, se dise no una Her-
ramienta QBE para M ultibases de Datos en Internet realizado por May Arrioja [6]. Esta herramienta
permite que usuarios inexpertos, consulten varias bases de datos al mismo tiempo. Esta versi on permite
realizar conversiones de unidades de medida y de formatos de fechas, ademas de que la interfaz le permite
al usuario escoger entre las tablas de las distintas Bases de Datos que le interesen para formular su consulta.
A diferencia del intermediario anterior escrito en C para Unix, este fue escrito completamente en Java
CAP

ITULO 1. INTRODUCCI

ON 4
y provee cuatro servicios fundamentales: obtencion de metadatos, obtencion de unidades de conversion,
ejecucion de la consulta global y conversion de unidad de medida y de formato de fecha. Ademas soporta
las peticiones de varios clientes, en otra palabras es multitarea. Un solo intermediario brinda servicio a
mas de una interfaz QBE. La arquitectura general de la herramienta, presentada en la gura 1.2, considera
tres componentes principales que son: la Interfaz QBE, Intermediario y Sistema Manejador de Bases de
Datos (SMBS). La arquitectura muestra la creacion de hilos para atender a los diferentes usuarios de la
herramienta, muestra tambien cuales son las peticiones de servicio que la interfaz QBE solicita al inter-
mediario, indica que las comunicaciones con los SMBD se realizan va JDBC, y que en el intermediario
esta instalado el SMBD comercial MS SQL Server con una base de datos cuyo nombre es Intermediario.
La herramienta utiliza la base de datos Intermediario para almacenar los resultados de las subconsultas y
realizar la consulta nal.
Figura 1.2: Arquitectura de herramienta de acceso a multibases de datos.
La herramienta cuenta con un mecanismo para traducir la consulta denida gracamente por el usuario
en lenguaje QBE a SQL, que se enva al intermediario y los resultados de la consulta son enviados al usuario.
Una parte fundamental de la herramienta es el uso de metadatos. Dado el desconocimiento del esquema
CAP

ITULO 1. INTRODUCCI

ON 5
de las bases de datos por parte de los usuarios, es necesario presentarles la mayor cantidad de informacion
acerca de esos esquemas, de aqu la importancia del uso de metadatos, ya que estos describen las tablas y
columnas de las bases de datos. El trabajo descrito por A. May [6] solo permite consultar bases de datos
distribuidas, en tanto que nuestro trabajo permite realizar b usquedas y consultas de recursos distribuidos.
Se observa que tanto la herramienta de software distribuido realizado por F. Rasgado y A. May se enfo-
can al acceso a bases de datos distribuidos a traves de Internet. La diferencia que existe entre los proyectos
realizados por ellos dos y este trabajo de tesis radica en que la arquitectura de software desarrollada se
enfoca a realizar b usquedas y consultas de recursos distribuidos a traves de Internet. Otra diferencia
notable es en la forma de emplear los metadatos. Los proyecto realizado por F. Rasgado y A. May utiliza
los metadatos para describir el contenido de los campos de las tablas de las bases de datos, mientras que
en este trabajo de tesis, los metadatos se utilizan para describir recursos oceanogracos distribuidos en la
comunidad ROPVO.
1.2 Justicacion
Los avances en la tecnologa de la comunicaci on, las redes de computo, el almacenamiento y acceso dis-
tribuidos de datos estan revolucionando internacionalmente a las interacciones cientcas[]. Instituciones
importantes en Estados Unidos como el Centro Nacional de Datos Oceanogracos (NODS), El Centro
Mundial de datos para la Oceanografa, y el Centro para el Analisis de Informacion sobre Bioxido de
Carbono y TCOON actualmente estan compartiendo sus recursos a traves de Internet. Por otra parte, en
Mexico se estan realizando esfuerzos por recopilar y compartir recursos entre instituciones de la comunidad
ROPVO, sin embargo, no se esta llevando a cabo estrategias que permitan la comparticion de recursos
entre instituciones. Este trabajo de investigacion propone estandarizar los procesos de almacenamiento de
los recursos de las instituciones en bases de datos. Esto permitira dise nar e implementar una arquitectura
de software que permitira realizar b usquedas y consultas de recursos distribuidos en la comunidad y que
estara disponible para el medio cientco y al p ublico en general a traves de Internet. En estos momentos
se estan enfocando los esfuerzos en la recopilacion de datos del nivel del mar y datos meteorologicos a lo
CAP

ITULO 1. INTRODUCCI

ON 6
largo de la costa y de los puertos del Golfo de Mexico. Estos datos seran administrados por diferentes
nodos ROPVO-GM. Posteriormente se incorporara el Centro de Informacion TCOON, esto ampliara los
margenes de informacion de datos y fomentar a el intercambio de ideas y apoyo mutuo entre naciones.
1.3 Planteamiento del problema
El Internet se ha convertido en uno de los medios de comunicacion mas usado en el mundo que permite
compartir informacion. La comunidad virtual ROPVO es una comunidad que realizara la administracion
de los recursos oceanogracos mediante el SIBW-Pharos. Actualmente el sistema Pharos permite realizar
b usquedas y consultas de datos oceanogracos en una sola computadora. Sin embargo la comunidad
ROPVO desea compartir recursos oceanogracos almacenados en diferentes computadoras conectadas a
traves de Internet, y Pharos tiene el problema de que no cuenta con un mecanismo que permita realizar
b usquedas y consultas distribuidas de recursos oceanogracos sobre Internet. Como resultado de este
trabajo se agrega al sistema Pharos la implementacion de la ASBUCORDI.
Cada uno de los integrantes de la comunidad ROPVO es una organizacion independiente, por lo que
hay que establecer un mecanismo adecuado de B usqueda y Consulta entre los organismos de la comu-
nidad ROPVO. Esto es, se debe considerar que las organizaciones de la comunidad virtual se agregan
y remueven constantemente, por lo cual el mecanismo de b usqueda y consulta debe poder adaptarse a
esta dinamica. Ademas se deben de tomar en cuenta los problemas de comunicacion sobre Internet que
se pueden presentar al realizar la b usqueda y consulta de recursos oceanogracos distribuidos. De esta
manera, se hace necesario que la comunidad ROPVO cuente con una estructura logica, que se lleva a
cabo mediante el dise no de un esquema de metadatos, para la organizacion distribuida de sus recursos
oceanogracos. Lo anterior plantea el problema de realizar un analisis que nos permita organizar los re-
cursos oceanogracos de la comunidad ROPVO bajo un esquema de metadatos, que pueda ser util para el
mecanismo de b usqueda y consulta distribuida de recursos. Una vez dise nado el esquema de metadatos, se
procedera a introducir estos en una base de datos que llamaremos de ahora en adelante Metabase de Datos.
CAP

ITULO 1. INTRODUCCI

ON 7
Una vez organizados los metadatos de los recursos compartidos en una metabase de datos, un mecan-
ismo de b usqueda distribuida requiere resolver el problema de encontrar a traves de los metadatos los
recursos solicitados a la comunidad virtual ROPVO. Esto es, a traves de un mecanismo de consulta de
recursos oceanogracos se debera permitir a los usuarios consultar los recursos oceanogracos localizados
por el mecanismo de b usqueda. Para ello, el mecanismo de consulta debera estar disponible a traves de
Internet y debera permitir que usuarios inexpertos puedan consultar los recursos oceanogracos a traves
del Web. Esto es, se debe permitir a los usuarios consultar recursos oceanogracos, de una manera trans-
parente [7], almacenando los metadatos de los recursos en metabases de datos distribuidas en la comunidad
ROPVO. Con respecto a los recursos de bases de datos administradas por el sistema Pharos, sus resultados
deberan ser presentados al usuario a traves de la Web, en forma de texto, o en gracas.
1.4 Hipotesis
Con base en una arquitectura peer-to-peer es factible dise nar e implementar un mecanismo de software
que permita la b usqueda y consulta de recursos oceanogracos distribuidos en una comunidad virtual,
utilizando una herramientas de software que sean totalmente libre y metabases de datos como esquemas
de conectividad de datos.
1.5 Objetivo general
Desarrollar e implementar una arquitectura de software para la b usqueda y consulta de recursos oceanogracos
distribuidos que se incorporara al proyecto ROPVO-GM y que servira como motor de transferencia de re-
cursos a traves de Internet mediante el uso de metadatos.
CAP

ITULO 1. INTRODUCCI

ON 8
1.6 Objetivos especcos
Los objetivos especcos del proyecto de investigaci on consisten en el dise no e implementaci on de:
Una metabase de datos distribuida donde se almacenen los metadatos de los recursos.
Un programa que implemente el protocolo Gnutella [8] para la b usqueda de recursos distribuidos a
traves de metadatos.
Un portal Web que permita al usuario realizar, por medio de atributos de recursos oceanogracos,
b usquedas de recursos distribuidos a traves del Internet.
Un programa servidor tipo Servent que coordine el procesamiento de consultas distribuidas e integre
los resultados.
Un portal Web para la presentacion de los resultados de consultas distribuidas en forma de texto o
gracas.
Integrar el mecanismo de b usqueda y consulta distribuida de recursos oceanogracos en Pharos.
Realizar pruebas sobre Internet
1.7 Organizacion del Documento
Este manuscrito se encuentra dividido en cinco captulos, cuyo contenido se describe a continuaci on.
En el captulo 2 se describe el marco teorico relacionado con el proyecto y que sirve de soporte para
su desarrollo. Se describe que es un Sistema Distribuido, la Arquitectura Cliente/Servidor [9] y la Arqui-
tectura Peer-to-Peer [10]. Igualmente describe el sistema Peer-to-Peer Mutella y conceptos relacionados
con el Internet. Finalmente se presentan los diferentes tipos de estandares de esquemas de metadatos y
los protocolos de comunicaci on.
CAP

ITULO 1. INTRODUCCI

ON 9
El captulo 3 muestra la metodologa de la Arquitectura de Software propuesta, el dise no de la Metabase
de Datos y ademas se describen los procesos de B usqueda y Consulta Distribuida de recursos a traves de
Internet.
El captulo 4 muestra los resultados del dise no de la arquitectura de software, la denicion del es-
quema de metadatos, los metodos para la creacion de la Metabase de Datos, el Diccionario de Terminos,
el Deposito de Metadatos y el Deposito Temporal de Metadatos. Igualmente se presenta el dise no de la
Interfaz de B usqueda y el dise no del Intermediario Web con las lneas de codigo que realizan el proceso
B usqueda Local, Analizador Lexico y propagacion de la solicitud de b usqueda. Finalmente se muestra el
dise no de la Interfaz de Consulta con las lneas de codigo que realizan el procesamiento de la Consulta y
Extraccion de Datos.
En el captulo 5 se describen las pruebas realizadas a la implementacion de la arquitectura de software
propuesta. Los objetivos de las pruebas, el ambiente de pruebas y los casos de pruebas realizados.
Captulo 2
Marco Te orico
2.1 Arquitectura de Software
En la ultima decada cambio la vision que los desarrolladores tienen sobre la estructura de un sistemas
de software. Esta nueva vision se llamo arquitectura. Desde los peque nos programas hasta los sistemas
mas grandes poseen una estructura y un comportamiento que los hace clasicables seg un su arquitectura.
Este nuevo aspecto hace posible el estudio de sistemas ya implementados as como el desarrollo de nuevos
sistemas. El tema arquitectura de software es a un nuevo en nuestros das ya que no se han establecido
bases solidas en su modo de uso y existen diferentes deniciones de arquitectura de software. De ahora en
adelante nos referiremos a arquitectura de software como AS . Una denicion reconocida es la de Clements
[12], quien la dene como una vista del sistema que incluye los componetes principales del mismo y las
formas en que los componentes interact uan y se coordinan para alcanzar la mision del sistema. Un com-
ponente es un conjunto de procesos. La vista arquitectonica es una vista abstracta, aportando el mas alto
nivel de comprension y la supresion de los detalles.
La AS es una forma de dise no de software que se maniesta en el proceso de creacion de un sistema.
Mary Shaw y David Garlan [13] sugieren que las estructuras de AS deben incluir una organizacion a
grandes razgos y una estructura global de control, protocolos para la comunicaci on, la sincronizacion y el
acceso a datos, la asignacion de funcionalidad a elementos del dise no, la distribucion fsica, la composicion
10
CAP

ITULO 2. MARCO TE

ORICO 11
de los elementos de dise no, escalabilidad, rendimiento y seleccion entre alternativas de dise no. Despues,
David Garlan y Mary Shaw [14] clasican a la AS en cinco modelos: modelos estructurales, modelos de
framework, modelos dinamicos, modelos de proceso y modelos funcionales.
En este trabajo utilizaremos el modelo estructural para describir el dise no de nuestra Arquitectura de
Software para la B usqueda y Consulta de Recursos Distribuidos sobre Internet. La Arquitectura de Soft-
ware a dise nar empleara componentes de mecanismos locales y componentes de mecanismos distribuidos
sobre Internet.
2.2 Sistemas Distribuidos
Un sistema distribuido es aquel al que sus usuarios ven como un ordinario sistema centralizado; sin em-
bargo, se ejecuta en diferentes e independientes CPUs [15]. En un sistema distribuido los componentes de
software y hardware locales se comunican y coordinan sus acciones solamente por el envo de mensajes.
Las computadoras conectadas a esta red, pueden estar espacialmente separadas por alguna distancia, por
ejemplo las computadoras pueden estar en continentes diferentes, pertenecer a una institucion en particular
o estar en el mismo cuarto. Un sistema distribuido conlleva las consecuencias de ser concurrente, manejar
alg un tiempo global y fallas de independencia. A continuacion presentamos dos modelos de arquitectura
para el dise no de sistemas distribuidos.
2.2.1 Arquitectura Cliente/Servidor
El termino cliente/servidor fue primeramente usado en los a nos 80 para referirse a las computadoras per-
sonales en la red y empezo a tener aceptacion a nales de la decada de los 80, ver gura 2.1. La arquitectura
cliente/servidor es una infraestructura vers atil y distribuida, basada en mensajes que esta pensada para
mejorar la exibilidad, interoperabilidad y escalabilidad de los sistemas [16]. Un cliente se dene como un
CAP

ITULO 2. MARCO TE

ORICO 12
solicitador de servicios y un servidor se dene como el proveedor de servicios [17].
Figura 2.1: Arquitectura Cliente/Servidor.
2.2.2 Arquitecturea Peer-to-Peer
Los sistemas Peer-to-Peer(P2P) se reeren a una clase de sistemas distribuidos que funcionan de una
manera descentralizada. Clay Shirky el autor del artculo What is P2P and What is not dene una
red Peer-to-Peer como un sistema distribuido de aplicaciones que toma ventajas de los recursos, almace-
namiento, ciclos, contenido y presencia humana disponible a traves de Internet [18], se reere a una red
que no tiene clientes ni servidores jos, sino una serie de nodos que se comportan simultaneamente como
clientes y como servidores de otros nodos conectados a la red.
La tecnologa Peer-to-Peer (P2P) ha ganando terreno en los ultimos a nos [19]. P2P llamo la atencion
cuando aparecio el programa Napster [20] que permita compartir archivos musicales. Aunque no era una
aplicacion P2P pura, este, cumple con algunas de las caractersticas de los sistemas Peer-to-Peer. Con la
misma idea de compartir archivos musicales, aparecieron otras aplicaciones como Gnutella [21], eDonkey
[22], y eMule [23]. Existen instituciones que han enfocado la tecnologa P2P a otras areas de investigaci on,
por ejemplo en las ciencias, los proyectos SETI@Home [24], Folding@Home [25], Genome@Home [26] y
Grid project [27], que han mostrado como la tecnologa P2P es muy util para resolver problemas complejos,
costosos y de caracter distribuido.
CAP

ITULO 2. MARCO TE

ORICO 13
Se puede entender que un peer es un participante en un sistema P2P. Estos participantes estan activos
en una aplicacion, de manera que pueden proporcionar servicios a otros participantes en el grupo. Una
ventaja comparativa con respecto a otros sistemas clasicos, es que los archivos o los procesos estan com-
pletamente decentralizados. Una de las metas de la tecnologa P2P es tomar ventaja de los recursos que
existen en la red, ver gura 2.2.
Figura 2.2: Arquitectura Peer to Peer.
2.3 Protocolos de comunicacion
Respecto a los estudios realizados sobre los protocolos de comunicaciones de Internet podemos mencionar
el Protocolo de Internet (IP, por sus siglas en ingles), que fue dise nado para interconectar sistemas basa-
dos en redes de intercambio de paquetes. El protocolo IP permite el intercambio de bloques de datos,
denominados datagramas, entre nodos conectados a una red, cada uno de ellos tiene una direccion unica
denominada direccion IP. La funcion de IP es encaminar datagramas a traves de una serie de redes inter-
conectadas. Este proceso se lleva a cabo pasando los datagramas desde un modulo Internet hacia otro,
hasta alcanzar el destino deseado. Se entiende por modulo Internet aquellos servicios que lleva a cabo la
capa de red dentro de una arquitectura TCP/IP. Otro protocolo de Internet es el Protocolo de Control de
Transmisi on (TCP, por sus siglas en ingles). El protocolo TCP es el metodo mas eciente y seguro para el
traco de red entre un cliente y un servidor o entre subredes en general. Aunque TCP se presenta como
CAP

ITULO 2. MARCO TE

ORICO 14
parte del grupo de protocolos de Internet (TCP/IP), es un protocolo de proposito general que se puede
adaptar para utilizarlo con otros sistemas de entrega. Las conexiones TCP funcionan de una forma muy
parecida a como lo hacen las conexiones va telefonica: el que esta a un lado de la lnea inicia una comu-
nicacion y esta debe ser aceptada por el usuario que se encuentra al otro lado. Cuando un cliente decide
establecer una comunicaci on con un servidor, es necesario que ambos esten de acuerdo en participar, de lo
contrario la comunicaci on no se podra llevar a cabo. Una conexion TCP viene identicada por una pareja
de sockets, es decir, una direccion IP y un n umero de puerto en cada extremo. La ventaja de este metodo
es que un unico nodo es capaz de mantener diferentes conexiones TCP a traves de un mismo puerto. Esto
es posible debido a que los paquetes que recibe el nodo se diferencian uno de otros porque utilizan sockets
distintos. Por ejemplo: un servidor Telnet permite que diferentes clientes accedan al puerto 23, que es
el puerto estandar para este servicio. Todos los clientes se conectan al mismo socket (direccion IP del
servidor + puerto 23), sin embargo, el servidor es capaz de distinguir a los diferentes clientes debido a que
cada uno de ellos utiliza un socket local diferente.
2.3.1 Sistema Mutella
El sistema Mutella es un software tipo peer-to-peer utilizado para el intercambio de archivos de texto,
sonido, programas, imagenes y videos. El sistema P2P Mutella se utilizara como motor de b usqueda de re-
cursos distribuidos en la implementacion de nuestra Arquitectura de Software. Este protocolo inicialmente
fue desarrollado por Max [31]. El sistema Mutella tiene la ventaja de ser un software con codigo fuente
libre (open source software); esto quiere decir que se permite descargar el codigo, estudiarlo y realizar las
modicaciones pertinentes para adaptarlo a nuestras necesidades. El codigo fuente puede ser descargado
desde su pagina ocial http://mutella.sourceforge.net. La tarea del sistema P2P Mutella es propagar la
solicitud de b usqueda de recursos en la comunidad ROPVO.
CAP

ITULO 2. MARCO TE

ORICO 15
2.3.2 Especicaciones del protocolo Genutella V0.4
Gnutella es un protocolo para b usquedas distribuidas. Aunque el protocolo Gnutella soporta un paradigma
tradicional de b usqueda de clientes/servidores centralizados, Gnutella se distingue en ser un modelo Peer-
to-Peer descentralizado. En este modelo, cada nodo es un servidor y cliente a la vez, a esta caracterstica
de Gnutella es conocida como Servents. Los Servents proveen interfaces para los usuarios, puede consultar
y ver los resultados de b usqueda, mientras que al mismo tiempo pueden aceptar consultas de otros Servents
comparando un conjunto de datos locales respondiendo favorablemente si la comparacion es verdadera.
Debido a su naturaleza distribuida, una red de Servents que implemente el protocolo Gnutella es altamente
tolerante a fallo, las operaciones de una red no sera interrumpida si un subconjunto de Servents queda
fuera de servicio [30].
2.3.3 JDBC
La Conectividad de Bases de Datos Java (JDBC, por sus siglas en ingles) es un conjunto de funciones
que permiten a los programas Java establecer conexion a diferentes bases de datos y ejecutar sentencias
SQL [36]. JDBC permite a los programas Java interactuar con la mayora de las base de datos compilada
en SQL. Actualmente la mayora de los sistemas manejadores de bases de datos relacional soportan SQL.
JDBC fue desarrollado por JavaSoft que es una sucursal de Sun Microsystems.
2.4 El Internet
El Internet es un sistema distribuido con una basta coleccion de redes de computadoras de diferentes tipos
interconectadas entre s. La interacci on de los programas en ejecucion de las computadoras conectadas a
la red se logra por el paso de mensajes, empleando una caracterstica com un de comunicaci on. El dise no
y construccion de los mecanismos de comunicacion de Internet llamados tambien protocolos Internet es la
principal tecnica que se ha logrado para dirigir mensajes permitiendo la ejecucion de un mensaje de un
programa en cualquier parte a cualquier otro programa. El Internet es tambien un sistema distribuido que
CAP

ITULO 2. MARCO TE

ORICO 16
permite a los usuarios, hacer uso de servicios tales como el WWW, email y transferencia de archivos. El
conjunto de servicios es nalmente abierto, este se puede extender para a nadir nuevos tipos de servicios y
computadoras servidoras [32].
2.4.1 La Word Wide Web (WWW)
La WWW es un sistema en evoluci on que permite acceder a servicios y recursos publicados a traves del
Internet [28]. A traves del browser para la web, tal como Netscape e Internet Explorer, los usuarios pueden
ver y recuperar diferentes tipos de documentos, escuchar audio, ver video e interactuar con un ilimitado
conjunto de servicios. La Web esta basada principalmente en tres componentes de tecnologa estandar que
son el Lenguaje de Marcado de Hipertexto (HTML, por sus siglas en ingles), el Localizador de Recursos
Uniformes (URL, por sus siglas en ingles) y una arquitectura de sistema.
2.4.2 El lenguaje HTML y localizar URL
El HTML es un lenguaje estandar con el que se escriben los programas (documentos) en el World Wide
Web. El HTML dene formatos, vnculos y otros aspectos de disposicion de textos, imagenes y objetos
dentro de una pagina Web [29]. El lenguaje HTML especica el dise no y contenido de las paginas, esto
es, la manera en que las paginas seran desplegadas por los exploradores Web. Una pagina Web contiene
encabezados, parrafos, tablas e imagenes. El URL identica los documentos y otros recursos almacenados
como parte de la Web, esto es, el proposito del URL es permitir al explorador Web la localizacion de estos
recursos. La arquitectura de sistema cliente/servidor cuenta con reglas bien denidas para la interaccion
entre aplicaciones, un ejemplo es el Protocolo de Transferencia de Hipertexto (HTTP, por sus siglas en
ingles) mediante el cual los exploradores Web y otras aplicaciones obtienen documentos y otros recursos
de los servidores Web.
CAP

ITULO 2. MARCO TE

ORICO 17
2.4.3 Sistemas de Informacion Basados en Web (SIBW)
Actualmente esta emergiendo una nueva tecnologa para la administracion de la informacion sobre Inter-
net que son los sistemas de informacion basados en Web (SIBW) [33]. Los SIBW tienen las siguientes
caractersticas:
El cliente Web, que es nombrado primera capa, es una interfaz de usuario estandar que permite al
usuario recuperar informacion en la forma de paginas HTML o que permite activar aplicaciones.
El Servidor Web, que es nombrado segunda capa, procesa y redirecciona la peticion del usuario,
recolecta los resultados y enva estos al cliente en la forma de paginas HTML.
Puesto que la primera capa es la unica responsable para interactuar con el usuario, la funcionalidad
de la aplicacion es implementada como un conjunto de servicios distribuidos en diferentes servidores.
Debido a que una parte importante de los servicios debe ser oculta para el usuario, esto obliga a
establecer polticas para la asignacion de servicios.
Las aplicaciones basadas en Web operan por lo regular en estaciones de trabajo. Los procesos del
servidor son ejecutados en maquinas de servidores dedicados. En gran manera el desempe no de la
aplicacion es inuenciada por la maquina servidor.
La comunicaci on entre las capas relacionadas con el usuario esta basada en el protocolo HTTP. Por
esa razon la identicaci on de los recursos se lleva a cabo a traves del uso del URL.
Un sistema tpico basado en WWW consiste de un sistema de base de datos, un lenguaje de consulta
de base de datos y varios componentes tales como scripts y servidores WWW que trabajan conjun-
tamente. Estos sistemas pueden tener una gran cantidad de informacion condencial que requiere
complejas polticas de seguridad.
CAP

ITULO 2. MARCO TE

ORICO 18
2.5 Esquemas de metadatos
Se han realizado diversos estudios concernientes al dise no y desarrollo de esquemas de metadatos. Entre
estos se encuentran los esquemas realizados por la National Information Standards Organization (NISO)
[34]:
DUBLIN. El objetivo original del dise no Dublin fue denir un conjunto de elementos y algunas reglas
que deben ser usadas por las organizaciones para describir sus propios recursos disponibles en la Web.
TEI. La Iniciativa de Codicacion de Texto (TEI, por sus siglas en Ingles), es un proyecto interna-
cional que desarrolla pautas para el marcado de texto electronico tales como novelas y poesas.
METS. La Codicacion de Metadatos y Estandares de Transmision (METS, por sus siglas en Ingles)
fue desarrollado para dise nar estandares de estructuras de datos para describir bibliotecas de objetos
digitales complejos. METS es un esquema basado en el Lenguaje Extensible de Marcado para crear
documentos XML.
MODS. Los elementos del esquema para la Descripcion de Objetos de Metadatos (MODS, por sus
siglas en Ingles) son mas ricos que el dise no Dublin, ya que estos elementos son mas compatibles con
los datos de librera en comparacion con el estandar de dise no Dublin.
LOM. El esquema de Aprendizaje de los Objetos de Metadatos (LOM: por sus siglas en Ingles)
propone metadatos de aprendizaje para permitir el uso y rehuso de tecnologas que soporten el
aprendizaje de recursos tal como el entrenamiento basado en computadoras y el aprendizaje a dis-
tancia.
CDWA. Las categoras para la Descripcion de Trabajos de Arte (CDWA, por sus siglas en Ingles)
fue desarrollado para describir y acceder a la informacion de los objetos e imagenes de trabajos de
arte.
MPEG. El grupo de Expertos de Imagenes en Movimiento (MPEG, por sus siglas en ingles) ha
desarrollado una serie de estandares para codicar la representaci on de audio y video digital.
CAP

ITULO 2. MARCO TE

ORICO 19
FGDC. El contenido Estandar de Metadatos Geoespaciales Digitales (FGDC, por sus siglas en ingles)
incluye datos topogracos y demogracos, sistema de informacion geograco y ayuda computarizada
de cartografa basada en archivos que son usados en una gran variedad de areas, incluyendo estudios
del uso del suelo, rastreos de cambios globales y climatologicos e imagenes de satelite.
ISO 19115. Finalmente el estandar para metadatos de informacion geograca ISO 19115, dene un
esquema internacional para describir servicios e informacion geograca.
Aunque los elementos del esquema internacional del estandar ISO 19115 se apegan mas a las necesidades
requeridas para realizar este trabajo, se debe de tomar en cuenta que el esquema internacional del estandar
ISO 19115 no es un esquema libre. De esta manera, el esquema del estandar FGDC sera empleado en este
trabajo para la creacion de los metadatos de la base de datos que contendr a los recursos oceanogracos
pertenecientes a la comunidad ROPVO y que seran puestos a disposicion del p ublico en general a traves
de Internet.
2.6 Modelo en Cascada
El modelo en Cascada es usado en la implementacion de sistemas de informacion y abarca las siguientes
actividades: ingeniera y analisis del sistema, analisis de los requisitos del software, dise no, codicacion,
prueba y mantenimiento, ver gura 2.3.
Figura 2.3: Ciclo de vida del modelo en Cascada.
CAP

ITULO 2. MARCO TE

ORICO 20
Ingeniera y Analisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el
trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando
alg un subconjunto de estos requisitos al software.
Analisis de los requisitos del software: el proceso de recopilacion de los requisitos se centra e intensica
especialmente en el software. El ingeniero de software debe comprender el ambito de la informacion
del software, as como la funcion, el rendimiento y las interfaces requeridas.
Dise no: el dise no del software se enfoca en cuatro atributos distintos del programa: la estructura de
los datos, la arquitectura del software, el detalle procedimental y la caracterizacion de la interfaz. El
proceso de dise no traduce los requisitos en una representaci on del software con la calidad requerida
antes de que comience la codicacion.
Codicacion: el dise no debe traducirse en una forma legible para la maquina.
Prueba: La prueba se centra en la logica interna del software. Se realizan pruebas que aseguren que
la entrada de datos al sistema, producen los resultados que realmente se requieren.
Mantenimiento: Los cambios ocurriran debido a que hayan encontrado errores, a que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifericos), o debido
a que el cliente requiera ampliaciones funcionales o del rendimiento.
Desventajas:
Los proyectos reales raramente siguen el ujo secuencial que propone el modelo, siempre hay itera-
ciones y se crean problemas en la aplicacion del paradigma.
Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El
ciclo de vida clasico lo requiere y tiene dicultades en acomodar posibles incertidumbres que pueden
existir al comienzo de muchos productos.
La ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora
de desarrollar el software.
Captulo 3
Metodologa
Este trabajo de tesis propone el dise no y desarrollo de una ASBUCORDI. La arquitectura permitira a
las comunidades virtuales compartir recursos. Su implementaci on requiere del analisis y dise no de una
Metabase de Datos y de los procesos de B usqueda y Consulta de Recursos Distribuidos.
3.1 Metabase de Datos
Figura 3.1: Componentes de la Metabase de Datos.
La gura 3.1 presenta el componente Metabase de Datos que tiene por objeto almacenar los metadatos
de los recursos pertenecientes a un nodo de la comunidad. Entiendase por metadato como la informacion
necesaria para describir un recurso, metabase de datos como la base de datos que almacena los recursos de
un nodo de la comunidad y por un nodo de la comunidad, una computadora de la comunidad virtual. Los
21
CAP

ITULO 3. METODOLOG

IA 22
elementos del componente Metabase de Datos son el Diccionario de Terminos, el Deposito de Metadatos
y el Deposito Temporal de Metadatos.
Diccionario de Terminos. Es el conjunto de nombres de recursos almacenados en el nodo de la
comunidad. Esto es, los nombres de los recursos representan palabras clave. Estas palabras clave
son comparadas con la solicitud de b usqueda para la identicaci on de estaciones y recursos que se
desean consultar.
Deposito de Metadatos. Es una estructura para el almacenamiento de los metadatos de los recursos
del nodo de la comunidad.
Deposito Temporal de Metadatos. Es una estructura para el almacenamiento temporal de los
metadatos de los recursos del nodo de la comunidad. Esto es, los resultados producidos por el
proceso de b usqueda son integrados en esta estructura temporal del nodo solicitante.
La tabla 3.1 muestra un ejemplo de la relacion de los metadatos propuestos para la descripcion de los
recursos de los nodos de la comunidad virtual que se almacenan en el deposito de metadatos. La lista
de metadatos almacenara una descripcion de los recursos que desea compartir un nodo. Estos metadatos
permitiran localizar, consultar y administrar los recursos de los nodos.
Tabla 3.1: Ejemplo de una relacion de metadatos para la
descripcion de los recursos almacenados en un nodo de
la comunidad.
Atributo Descripcion
Fecha de publicacion Fecha de publicacion del recurso
Edicion Edicion del recurso
Publicador Quien propone el recurso a compartir
Sigue . . .
CAP

ITULO 3. METODOLOG

IA 23
Continuacion...
Lugar de publicacion Donde se realizo la publicacion
Clave de estacion Identicador de la estacion
Clave de recurso Identicador del recurso
Ttulo Ttulo del recurso
Nombre Nombre del recurso
Descripcion Breve descripcion que detalle la importancia del recurso
Direccion en red Direccion electronica del recurso compartido
Nombre del recurso en
red
El nombre del archivo o servicio que permitira obtener el
conjunto de datos
Relacion Nombre de la relacion o tabla contenedora de datos
Usuario Nombre de usuario
Password Clave de acceso
Fin de la tabla 3.1
CAP

ITULO 3. METODOLOG

IA 24
3.2 B usqueda Distribuida
Figura 3.2: Componentes de la B usqueda Distribuida.
La gura 3.2 presenta el Proceso de B usqueda Distribuida que tiene por objeto encontrar recursos
dispersos en la comunidad. Los componentes del Proceso de B usqueda Distribuida son la Interfaz de
B usqueda, el Intermediario Web, el Componente Comunicaciones y la Metabase de Datos.
Interfaz de B usqueda. Es una aplicacion Web que permite al usuario del sistema formular consultas
que son procesadas por el mecanismo de B usqueda.
Intermediario Web. Es un programa que sirve de interfaz entre el Componente de Comunicaciones
y la Interfaz de B usqueda.
Componente de Comunicaciones. Realiza la b usqueda de los metadatos en el nodo local y en los
nodos remotos que forman parte de la comunidad.
Metabase de Datos. Este componente contiene la base de datos que almacena el esquema de los
metadatos de los recursos disponibles en el nodo local, as como el Diccionario de Terminos, el
Deposito de Metadatos y el Deposito Temporal de Metadatos, seccion 3.1.
En primer lugar, el usuario accede a un nodo de la comunidad a traves de su explorador Web (HTTP),
a este nodo se le conoce como nodo solicitante. En seguida, el usuario accede a la Interfaz de B usqueda
CAP

ITULO 3. METODOLOG

IA 25
y formula una solicitud de b usqueda de recursos, ver gura 3.2. El componente Interfaz de B usqueda
enva la solicitud al componente Intermediario Web por medio de Sockets (1). A su vez, el componente
Intermediario Web enva la solicitud de b usqueda al Componente Comunicaciones a traves de Tuberas
(2). En seguida, el Componente Comunicaciones extrae los recursos locales del componente Metabase de
Datos a traves de MySQLConnect (3). La b usqueda se propaga a otros nodos de la comunidad utilizando
Sockets (4).
3.2.1 Interfaz de B usqueda
La Interfaz de B usqueda incluye las siguientes funciones: Diccionario de Estaciones, Diccionario de Re-
cursos y Compartir Recursos.
Diccionario de Estaciones. Este diccionario permite al administrador del sistema organizar los datos
de los atributos de la relacion stations del nodo de la comunidad, tales como el identicador de la
estacion, nombre y descripcion de la estacion.
Diccionario de Recursos. Este diccionario permite al administrador del sistema organizar los datos
de la relacion Resource del nodo de la comunidad, tales como el identicador del recurso, nombre y
descripcion del recurso.
Compartir Recursos. Esta funcion permite al usuario del sistema ingresar y compartir recursos
oceanogracos del nodo de la comunidad.
3.2.2 Intermediario Web
El Intermediario Web es un programa que sirve de interfaz entre el Componente de Comunicaciones y la
Interfaz de B usqueda. Las comunicaciones entre la Interfaz Web y el Intermediario Web se llevan a cabo
mediante sockets.
CAP

ITULO 3. METODOLOG

IA 26
3.2.3 Componente de Comunicaciones
Figura 3.3: Componente de Comunicaciones.
En la gura 3.3 se presenta el Componente de Comunicaciones, el cual tiene por objeto buscar los
recursos en los nodos de la comunidad. Los subcomponentes del Componente de Comunicaciones son:
B usqueda Local y B usqueda Remota.
B usqueda Local. Es el conjunto de actividades que tienen por objeto extraer los metadatos de los
recursos almacenados en el deposito de metadatos del nodo solicitante.
B usqueda Remota. La meta de estas actividades es propagar la solicitud de b usqueda de recursos
hacia otros nodos de la comunidad. En cada uno de los nodos remotos de la comunidad, tambien se
activa la B usqueda Local.
B usqueda Local
La B usqueda Local, tal como se muestra en la gura 3.4, incluye las siguientes funciones: Analizador
Lexico, Construccion de Instrucciones SQL y Ejecucion de Consulta.
Analizador Lexico. Separa las palabras clave de la solicitud de b usqueda en funcion del diccionario
de terminos que se encuentra almacenado en el componente de Metabase de Datos.
CAP

ITULO 3. METODOLOG

IA 27
Figura 3.4: Subcomponente de B usqueda Local.
Construccion de Instrucciones SQL. Relaciona las palabras claves identicadas por el componente
Analizador Lexico con los terminos almacenados en el diccionario de terminos y se construye una
consulta en lenguaje SQL.
Ejecucion de Consulta. Se encarga de ejecutar la consulta SQL formulada en el punto anterior,
extrayendo los metadatos de los recursos del componente de Metabase de Datos y almacenarlos en
el Deposito Temporal de Metadatos. Enseguida los recursos localizados son mostrados al usuario a
traves del componente de Interfaz de B usqueda.
La gura 3.4 muestra como el proceso B usqueda Local enva la solicitud de b usqueda a la funcion Anal-
izador Lexico (1). De igual forma, la funcion Analizador Lexico enva las palabras claves identicadas, a
la funcion Construccion de Instrucciones SQL (2). La funcion Construccion de Instrucciones SQL enva
la consulta formulada en lenguaje SQL a la funcion Ejecucion de Consulta (3). Por ultimo la funcion
Ejecucion de Consulta extrae los recursos almacenados en el Deposito de Metadatos y los almacena en el
Deposito Temporal de Metadatos que forma parte del nodo solicitante.
La gura 3.5 muestra el diagrama de ujo de la funcion Analizador Lexico. Sea B, el conjunto de pal-
abras de la solicitud de b usqueda, V el conjunto de nombres de las estaciones, W el conjunto de nombres
de recursos oceanogracos y S el conjunto resultante de palabras de estaciones y recursos identicados.
Ahora bien, si el conjunto de nombres de estaciones es diferente a vaco, entonces, se toma el elemento v del
CAP

ITULO 3. METODOLOG

IA 28
conjunto de nombre de estaciones V , si el nombre de la estacion v, forma parte del conjunto de palabras
contenidas en la solicitud de b usqueda entonces, v se agrega al conjunto de estaciones y recursos identi-
cados S. En seguida el elemento v se elimina del conjunto de nombre de estaciones V . Por otra parte, si
el elemento v no forma parte del conjunto de nombres de estaciones entonces, el elemento v es eliminado
del conjunto V y no se agrega al conjunto S. El objetivo de estos pasos es identicar los nombres de las
estaciones que forman parte del conjunto de palabras de la solicitud de b usqueda del usuario. Ahora bien,
si el conjunto de nombres de estaciones es igual a vaco entonces, se inicia el proceso de identicaci on de
palabras asociadas a recursos, si el conjunto de nombres de recursos es diferente a vaco entonces, w es un
elemento del conjunto de nombres de recursos W, si el nombre del recurso w, forma parte de las palabras
contenidas en la solicitud de b usqueda de recursos entonces, el elemeto w formara parte del conjunto S, En
seguida, el elemento w se elimina del conjunto de nombres de recursos W. Por otra parte, si el elemento
w no forma parte del conjunto de nombres de recursos entonces, el elemento w es eliminado del conjunto
W. Finalmente, si el conjunto de nombres de recursos es igual a vaco entonces, termina la ejecucion. El
objetivo de estos pasos es identicar los nombres de estaciones y recursos que forman parte del conjunto de
palabras de la solicitud de b usqueda del usuario. Como ejemplo, considere B = primer, nivel, del,
mar, en, tampico, y, veracruz, V = Mezquital, La Pesca, Tampico, Madero, Tuxpan, Veracruz
y W = Primer nivel del mar, Temperatura del aire, Temperatura del mar, Velocidad del viento, Direccion
del viento, Presion barometrica, Marea alta, Marea baja, Salinidad. Ahora bien, de acuerdo al proced-
imiento Analizador Lexico, ver gura 3.5. El conjunto S resultante es 128,700,pwl. Esto se debe a que las
claves 128 y 700 corresponden a las estaciones de Tampico y Veracruz respectivamente, que con-
tienen el recurso primer nivel del mar y la clave pwl que corresponde al recurso Primer nivel del mar.
La gura 3.6 muestra el diagrama de ujo de la funcion Construccion de la Instruccion SQL. Sea S
el conjunto de palabras de estaciones y recursos identicados y C el conjunto de nombres de estaciones
y recursos para la formulaci on de la solicitud de b usqueda en lenguaje SQL. Si el conjunto de palabras
de estaciones y recursos identicados es diferente a vaco entonces, s es un elemento que forma parte del
conjunto de palabras de estaciones y recursos identicados, enseguida, el elemento s formara parte del
CAP

ITULO 3. METODOLOG

IA 29
conjunto de caracteres para la formulacion de la b usqueda C, nalmente, el elemento s se elimina del
conjunto de palabras de estaciones y recursos identicados. Finalmente, si el conjunto de estaciones y re-
cursos es vaco, entonces termina la funcion. El objetivo de estos pasos es formular la consulta de recursos
en lenguaje SQL y almacenarla en el conjunto S. Como ejemplo. Para la entrada S = 128,700,pwl. El
resultado del algoritmo 3.6 es C = Select * from DepositoDeMetadatos Where ClaveEstaci on = 128 y
ClaveEstacion = 700 y ClaveRecurso = pwl, donde el campo ClaveEstaci on almacena el identicador de
la estacion y el campo ClaveRecurso almacena el identicador del recurso. Estos dos campos pertenecen
al deposito de metadatos, ver tabla 3.1.
La funcion Construccion de la Instruccion SQL consiste de un conjunto de instrucciones que tiene
la nalidad de establecer conexion con la Metabase de Datos del nodo de la comunidad y extraer los
metadatos que cumplan con la solicitud de b usqueda de recursos del usuario, ver gura 3.7. Por ejemplo,
se toma la cadena de formato de b usqueda C = Select * from DepositoDeMetadatos Where ClaveEstaci on
= 128 y ClaveEstaci on = 700 y ClaveRecuerso = pwl y se procede a establecer conexion con la base de
datos del nodo ROPVO. Enseguida se ejecuta la cadena de formato de b usqueda C y se extraen los datos
del Deposito de Metadatos. Finalmente se almacenan los metadatos extrados en el Deposito Temporal de
Metadatos.
CAP

ITULO 3. METODOLOG

IA 30
Figura 3.5: Diagrama de ujo de la funcion Analizador Lexico.
Figura 3.6: Diagrama de ujo de la funcion Construccion de la Instruccion SQL.
CAP

ITULO 3. METODOLOG

IA 31
Figura 3.7: Diagrama de ujo que muestra el proceso para la extraccion de los metadatos.
CAP

ITULO 3. METODOLOG

IA 32
B usqueda Remota
Figura 3.8: Subcomponente de B usqueda Remota.
En la gura 3.8 se observa que el subcomponente B usqueda Remota propaga la solicitud de b usqueda
en los nodos de la comunidad a traves de Internet usando Sockets (1); cada nodo que recibe la solicitud
de b usqueda desde un nodo solicitante se conoce como nodo receptor. Enseguida, el Componente de Co-
municaciones del nodo receptor, recibe la solicitud de b usqueda (2) y la enva hacia su subcomponente
B usqueda Local (3). El subcomponente B usqueda Local extrae los metadatos de los recursos almacenados
en el componente Metabase de Datos (4). En seguida, el subcomponente B usqueda Local del nodo receptor
enva los metadatos localizados hacia el componente Metabase de Datos del nodo solicitante (5). Final-
mente el componente Interfaz de B usqueda extrae los metadatos almacenados en el deposito de metadatos
del nodo solicitante y se muestran al usuario a traves de una aplicacion Web (6).
3.2.4 Presentacion de Resultados
Los metadatos obtenidos por el Proceso de B usqueda, se muestran al usuario en forma de lista a traves
del componente Interfaz de B usqueda. La lista de metadatos visible para el usuario esta formada por
CAP

ITULO 3. METODOLOG

IA 33
los metadatos de ttulo, descripcion del recurso y direccion del recurso en red. La lista de metadatos no
visibles para el usuario esta formada por los metadatos de fecha de publicacion, edicion, publicador, lugar
de publicacion, identicador del recurso, identicador de la estacion, nombre del recurso, nombre de la
relacion, nombre usuario, password y abreviacion del recurso. La razon del ocultamiento de estos recursos
es por seguridad. Ahora bien, el proceso de B usqueda permite accesar a recursos a traves de enlaces Web
y almacenados en bases de datos de los nodos de la comunidad.
Para los recursos accesibles a traves del Web, el Proceso de B usqueda muestra al usuario los metadatos
de ttulo, descripcion del recurso y direccion del recursos en red. El texto del metadato de ttulo aparece
en forma de enlace y permite el acceso a la pagina Web del recurso que describe. Con respecto al alma-
cenamiento de recursos en bases de datos, es importante aclarar que los nodos de la comunidad cuentan
con dos bases de datos, separados entre s, con objetivos completamente diferentes. La metabase de datos
tiene la nalidad de almacenar una breve descripcion que permita la comparticion de recursos entre los
nodos de la comunidad y la base de datos del sistema tiene como objetivo almacenar datos de diferentes
recursos. La base de datos de los nodos estan en cada uno de los nodos de la comunidad. Por ejemplo,
la base de datos de cada nodo contiene datos de recursos de: nivel del mar, salinidad, temperatura del
mar y aire, nivel de marea baja y alta, velocidad y direccion del viento, presion barometrica, velocidad
del mar, entre otros. Para los recursos almacenados en bases de datos el Proceso de B usqueda muestra
al usuario los metadatos de ttulo, descripcion del recurso y direccion del recurso en red. El texto del
metadato de ttulo aparece en forma de enlace y permite el acceso al Proceso de Consulta Distribuida del
recurso que describe. Ademas, el metadato de ttulo esta precedido de una caja de vericacion que tiene
la funcionalidad de un interruptor, apagado o encendido. Cuando este interruptor es encendido por el
usuario, indica al Proceso de B usqueda que este recurso se ha seleccionado para su consulta, teniendose
entonces acceso a los datos de los recursos almacenados en las base de datos de los nodos de la comunidad.
Finalmente, a traves de un boton se lanza el Proceso de Consulta. En este punto de transicion del Proceso
de B usqueda de Recursos Distribuidos hacia el Proceso de Consulta Distribuida, los recursos marcados
por el usuario en la caja de vericaci on, pasaran a ser almacenados en una matriz de memoria M del nodo
CAP

ITULO 3. METODOLOG

IA 34
solicitante. La gura 3.9 muestra un ejemplo de la matriz de metadatos M, que almacena los metadatos
de los recursos que el usuario desea consultar, la matriz contiene r renglones por c columnas. Igualmente
la tabla 3.2 ejemplica una descripcion del signicado de las claves que aparecen en la columna Clave
Recurso de la gura 3.9. Por ultimo, los metadatos se envan al Proceso de Consulta Distribuida.
Tabla 3.2: Ejemplo de lista de claves y descripcion de
recursos.
Abreviacion Descripcion
pwl Nivel primario del mar
atp Temperatura del aire
wtp Temperatura del mar
wsd Velocidad del viento
wdr Direccion del viento
bpr Precion barometrica
hw Marea alta
lw Marea baja
sal Salinidad
CAP

ITULO 3. METODOLOG

IA 35
Figura 3.9: Ejemplo de la matriz de memoria que almacena los metadatos de los recursos que el usuario
del sistema desea consultar.
CAP

ITULO 3. METODOLOG

IA 36
3.3 Consulta Distribuida
La Consulta Distribuida es un mecanismo que permite formular una consulta y recuperar los datos
oceanogracos almacenados en las bases de datos de diferentes nodos de la comunidad. En la gura 3.10 se
presenta la Consulta Distribuida. Los componentes de la Consulta Distribuida son: la Interfaz de Consulta,
el Intermediario de Consulta y el Componente de Extraccion de Datos.
Figura 3.10: Componentes del Proceso de Consulta Distribuida.
Interfaz de Consulta. Es una aplicacion Web que permite al usuario del sistema formular consultas
distribuidas sobre los recursos identicados por el Proceso de B usqueda.
Intermediario de Consulta. Se encarga de coordinar la extraccion de recursos y de la integracion de
los mismos para ser presentados en la interfaz de consulta.
Componente de Extraccion de Datos. Se encarga de establecer la conexion con la Base de Datos y
extraer los datos de los recursos de diferentes nodos de la comunidad.
CAP

ITULO 3. METODOLOG

IA 37
Como se muestra en la gura 3.10, la Consulta Distribuida se realiza en cuatro etapas: Acceso a la
Interfaz de Consulta, Formulacion de la Consulta, Procesamiento de la Consulta y la Presentaci on de
Resultados de la Consulta Distribuida, mismas que son descritas a continuaci on:
3.3.1 Interfaz de Consulta
Primeramente el usuario accede al Componente Interfaz de Consulta. Enseguida el Componente Interfaz
de Consulta lee la matriz M de metadatos que fue generada por el proceso de B usqueda de Recursos
(ver gura 3.9). La gura 3.11 muestra el diagrama de ujo que usa la matriz M de metadatos para la
agrupacion de las estaciones, donde M es una matriz de orden (pxq), que contiene la relacion descrita en
la tabla 3.3.
Figura 3.11: Diagrama de ujo que muestra el proceso para la creacion de un conjunto de estaciones que
tienen un recurso en com un.
CAP

ITULO 3. METODOLOG

IA 38
Tabla 3.3: Relacion de la matriz de metadatos M.
Atributo Descripcion
1. Clave Contiene la clave del metadato
2. ChBox Almacena el nombre del ChBox relacionado con el metadato
3. N umero estacion Es el n umero de la estacion mareograca
4. Ttulo Contiene el ttulo del recurso
5. Descripcion Descripcion general sobre el proposito del recurso
6. Direccion red Almacena la ubicacion fsica del recurso a traves de Internet
7. Base de datos En caso de que el recurso se encuentre en una base de datos entonces,
este campo almacena el nombre de la base de datos del recurso
8. Relacion Almacena el nombre de la relacion del recurso
9. Usuario Contiene el nombre de usuario
10. Contrase na Almacena la contrase na de acceso a la base de datos
11. Clave recurso Almacena la clave del recurso
12. Abreviacion estacion Contiene la abreviacion de la estacion
Ahora, considere R como el conjunto de recursos diferentes que se encuentran en M(i, 11) donde
1 i p. Sea N una matriz que resulta del algoritmo del la gura 3.11 de orden (w, 2), esto es con w
renglones y 2 es el n umero de columnas, donde la columna 1 es la clave del recurso y la columna 2 es la
lista de estaciones, ver gura 3.12.
Figura 3.12: Ejemplo de una matriz de metadatos.
CAP

ITULO 3. METODOLOG

IA 39
Sea E
r
el conjunto de estaciones que contienen un recurso dado. Ahora bien, se verica que existan
estaciones en el conjunto R, si existen estaciones en R, entonces se toma un elemento de R y se almacena en
r. Enseguida, se comparan todos los elementos de la matriz M(i, 11) con el recurso almacenado en r. Para
los casos en que la comparacion sea verdadera, el n umero de estacion M(i, 3) se almacena en el conjunto
E
r
. As, cuando ya no existan mas elementos por analizar en la matriz M(i, 11), se toma el recurso r y se
almacena en la matriz N(j, 1) y se toma el conjunto de estaciones E
r
y se almacena en la matriz N(j, 2).
En caso de que ya no existan recursos en el conjunto R por analizar se termina el programa. El objetivo de
estos pasos es obtener el conjunto de estaciones que tienen un recurso en com un y almacenarlos en la ma-
triz N, ver gura 3.12. La matriz N sera usada mas adelante por el componente Intermediario de Consulta.
Ahora bien, el usuario procede a formular la solicitud de consulta, para lograr esto, el componente
Interfaz de Consulta contiene cajas de texto, listas de opciones m ultiples y botones que permiten al usuario
denir los parametros para la b usqueda de recursos. La denicion de los parametros se realiza en tres
secciones: Par ametros de B usqueda Basica, Opciones de Gracacion y Opciones ASCII, ver gura 3.13.
Finalmente a traves de un boton se lanza el Procesamiento de la Consulta.
Figura 3.13: Secciones de la Interfaz de Consulta.
Parametros de B usqueda Basica. En esta seccion se dene el intervalo de fechas de extraccion
de datos. Tambien se dene el formato para la presentaci on de resultados al usuario, siendo estos,
CAP

ITULO 3. METODOLOG

IA 40
archivos de texto o archivo graco.
Opciones de Gracacion. Permite denir el ttulo, tama no, borde, y las coordenadas en x,y de
la graca. Tambien permite denir varias etiquetas para la graca.
Opciones ASCII. Esta seccion permite activar o desactivar los comentarios. Tambien permite
denir un smbolo para sustituir los datos inexistentes.
3.3.2 Intermediario de Consulta
La formulaci on de la consulta del usuario, es enviada al componente Intermediario de Consulta(1), ver
gura 3.10. El componente Intermediario de Consulta recibe la solicitud, enseguida toma la matriz N,
(ver gura 3.12) y genera una lista de estaciones a consultar. La lista de estaciones debe tener el siguiente
formato: n umero de la estacion, seguido de un guion y posteriormente la clave del recurso. En caso de
que existan mas estaciones, el formato de la lista de las estaciones es separada por comas. Por ejemplo
128-pwl,700-pwl,128-wtp. Esta lista de estaciones es utilizada para la extraccion de datos (recursos) de
las bases de datos de los nodos ROPVO.
La gura 3.14 muestra el diagrama de ujo para la creacion de la lista de estaciones L
i
. Considere
E
i
= N(i, 2) como un conjunto, donde i es el n umero de la de la matriz N. Esto es, E
i
contiene el
conjunto de estaciones para el recurso almacenado en N(i, 1). Sea L
i
la cadena que contiene el formato
de lista mostrado en el parrafo anterior. Primeramente, vericamos que existan estaciones en N(i, 2), si
existen estaciones en N(i, 2), entonces se almacena el recurso contenido en N(i, 1) en r
i
y se almacena la
lista de estaciones contenida en N(i, 2) en E
i
. Para cada estacion e almacenada en E
i
, se agrega el recurso
r
i
y la estacion e a la lista L
i
. En caso de que ya no existan estaciones almacenadas en E
i
, se procede
a tomar la siguiente lista de estaciones N(i, 2) y se almacena en E
i
y el programa termina. Todos estos
pasos tienen como objetivo crear la cadena que contendr a el formato de lista de estaciones con su recurso,
respectivamente. Por ejemplo 128-pwl,700-pwl,128-wtp.
CAP

ITULO 3. METODOLOG

IA 41
Figura 3.14: Diagrama de ujo que muestra el proceso de creacion de la lista de estaciones.
La cadena que contiene el formato de lista de estaciones L
i
y los parametros de la solicitud de
b usqueda(fecha de inicio de la consulta, fecha nal de la consulta, tipo de archivo de salida, ttulo de
la graca, tama no de la graca, borde, y las coordenadas en x,y de la graca) son enviados al Componente
Extraccion de Datos a traves de Tuberas(2), ver gura 3.10. Enseguida el Componente Extraccion de
Datos extrae los datos de las Base de Datos de los nodos ROPVO. La extraccion de los datos se realiza a
traves de MySQLConnect (3)(4).
CAP

ITULO 3. METODOLOG

IA 42
3.3.3 Extraccion de Datos
La extraccion de datos consiste en un conjunto de instrucciones que tienen la nalidad de establecer
conexion con las bases de datos de los nodos de la comunidad y extraer los recursos que cumplan con la
solicitud de b usqueda, ver gura 3.15.
Figura 3.15: Diagrama de ujo que muestra el proceso para la extraccion de datos.
Para hacer esto, primeramente se verica que existan elementos en la cadena de formato de lista de
estaciones L
i
. Si existen elementos en la cadena L
i
, se procede a tomar un elemento de la cadena de
formato de lista de estaciones, por ejemplo: 128-pwl. Enseguida se procede a extraer la estacion y el
recurso del elemento cadena de formato de lista de estaciones. El siguiente paso es extraer la fecha de
inicio y la fecha nal de la solicitud de consulta del usuario. Despues, se procede a establecer conexion
con la base de datos del nodo de la comunidad, enseguida se crea la cadena de solicitud de consulta en
lenguaje SQL, usando como parametros de la consulta, el n umero de estacion, la clave del recurso, la fecha
de inicio y la fecha nal de la consulta. Se ejecuta la cadena de consulta y se extraen los datos de la
relacion recursos. Finalmente se almacenan los datos del arreglo en la relacion temporal de recursos. Los
datos almacenados en la relacion temporal de recursos se envan al componente Intermediario de Consulta
a traves de una Tubera (5), ver gura 3.10. Finalmente, la Interfaz de Consulta presenta los resultados
del Proceso de Consulta Distribuida al usuario.
CAP

ITULO 3. METODOLOG

IA 43
3.3.4 Presentacion de Resultados
La presentacion de los resultados al usuario se lleva a cabo de dos formas. La primera es presentar los
resultados de la consulta al usuario en forma de archivo de texto. La segunda es gracar los resultados de
la consulta y presentarla al usuario a traves de la Interfaz Web.
La gura 3.16 ejemplica el dise no del archivo de texto para la presentacion de los resultados del
proceso de Consulta Distribuida al usuario. El campo estacion y clave del recuros contiene las esta-
ciones que fueron consultadas. El campo recurso contiene los nombres de los recursos consultados. El
campo fecha inicial y fecha nal almacena los rangos de fechas de la consulta. El campo n umero de
registros contiene el total de registros consultados. El campo base de datos contiene el nombre de la
base de datos consultada por el Proceso de Consulta Distribuida. El campo clave estacion almacena el
n umero de estacion consultada. El campo fecha almacena la fecha en que fue registrado este recurso.
El campo clave recurso almacena la clave del recurso consultado. Ahora bien, desde la columna M1
hasta la columna M10 se almacenan mediciones (considerando mediciones cada 6 minutos), del recurso
que contiene el campo clave recurso. Esto es, desde M1 a M10 corresponde a 1 hora de mediciones por
intervalos de cada 6 minutos.
Figura 3.16: Ejemplo del dise no del archivo de texto para la presentaci on de resultados.
CAP

ITULO 3. METODOLOG

IA 44
La gura 3.17 ejemplica el dise no de la graca para la presentaci on de los resultados del proceso
de Consulta Distribuida. El area Valor de la medicion del recurso contiene los rangos posibles, desde
el valor mnimo de cero hasta el valor maximo de los datos de los recursos consultados. El area In-
tervalo de fechas de la consulta contiene el intervalo de fecha inicial y nal para la presentacion de los
resultados de la consulta. El Area de la graca, contiene los datos de las estaciones consultadas en
forma de graca y el area de Estaciones y recursos contiene una lista de las estaciones consultadas.
Ahora bien, es importante mencionar que la graca de resultados cuenta con el mecanismo para agrupar
los datos de las estaciones que pertenecen a un recurso. En caso de que el usuario seleccione consultar
mas de un recurso, entonces la Interfaz de Resultados mostrara, por cada recurso, una graca de resultados.
Figura 3.17: Ejemplo del dise no del archivo graco para la presentacion de resultados.
Captulo 4
Resultados
Este trabajo de tesis propone el dise no y desarrollo de una arquitectura de software para la b usqueda y
consulta de recursos distribuidos sobre Internet. La arquitectura permitio a la comunidad virtual ROPVO
compartir recursos oceanogracos. Para su implementacion se llevo acabo la creacion y codicacion de
una Metabase de Datos y de los procesos de B usqueda y Consulta de Recursos Distribuidos.
4.1 Metabase de Datos
El dise no de la metabase de datos incluye cuatro factores que son: la denicion del esquema de metadatos,
la creacion de la metabase de datos, la creacion del deposito de metadatos y la creacion del deposito
temporal de metadatos, mismos que son descritos a continuacion.
4.1.1 Denicion del Esquema de Metadatos
El esquema de metadatos se utiliza para describir los recursos que permiten la localizacion y adminis-
tracion de los recursos oceanogracos de la red ROPVO. Este esquema esta basado en las especicaciones
del Comite de Datos Geograco Federal (FGDC, por sus siglas en ingles) y es el resultado del analisis
para identicar los metadatos necesarios para la localizacion de los recursos oceanogracos en los nodos
ROPVO. Con base en la tabla 3.1 se denen los metadatos para la creacion del esquema de metadatos,
utilizado en este trabajo. (ver tabla 4.1).
45
CAP

ITULO 4. RESULTADOS 46
En la siguiente seccion se describe la creacion de la Metabase de Datos.
Tabla 4.1: Esquema de metadatos tomados del estandar
FGDC, los cuales fueron seleccionados para la relacion
de metadatos.
Metadato Descripcion del metadato
publication Date Fecha de publicacion
edition Edicion
publisher Quien propone la metabase de datos
publication place donde se realizo la publicacion
idstation Identicador de la estacion
idresource Identicador del recurso
title Ttulo del esquema de metadatos
station name Nombre de la estacion
resource description Descripcion del recurso
Network Address Direccion electronica del recurso compartido
Network Resource Name El nombre del archivo o servicio que permitira obtener el conjunto de
datos
Relation Nombre de la relacion
User Nombre de usuario
Password Clave de acceso
CAP

ITULO 4. RESULTADOS 47
4.1.2 Creacion de la Metabase de Datos
La metabase de datos se creo en el SMBD MySQL y su nombre es DBmetadatos. DBmetadatos tiene
la nalidad de almacenar los metadatos de los recursos compartidos por la organizacion de una manera
clara, sencilla y ordenada. La gura 4.1 muestra la lnea de comando para la creacion de la base de datos
DBmetadatos.
Figura 4.1: Lnea de comando utilizada para la creacio n de la base de datos DBmetadatos.
4.1.3 Creacion del Diccionario de Terminos
El diccionario de terminos se creo en la base de datos DBmetadatos y esta formado por dos relaciones: la
relacion stations y la relacion resource. La tabla 4.2 muestra la estructura de la relacion stations, mientras
que la gura 4.2 muestra la lnea de comando utilizada para la creacion de la relacion stations.
Tabla 4.2: Estructura de la relacion stations.
Campo Tipo de dato
id int(11)
idStation int(11)
Station Name varchar(200)
Resource Description text
latitude varchar(20)
longitude varchar(20)
stnabbr varchar(15)
CAP

ITULO 4. RESULTADOS 48
Figura 4.2: Lnea de comando utilizada en la creacion de la relacion stations.
La tabla 4.3 muestra la estructura de la relacion resource, y en la gura 4.3 se muestra la lnea de
codigo para la creacion de la relacion resource.
Tabla 4.3: Estructura de la relacion resource.
Campo Tipo de dato
id int(11)
idResource varchar(11)
resource name varchar(200)
resource description text
Figura 4.3: Lnea de comando utilizada para la creacion de la relacion resource.
4.1.4 Creacion del Deposito de Metadatos
El Deposito de Metadatos se creo en la base de datos DBmetadatos y su nombre es DataResource. En la
tabla 4.4 se muestra la estructura de la relacion DataResource mientras que en la gura 4.4 se muestra la
lnea de comando para la creacion la relacion DataResource.
CAP

ITULO 4. RESULTADOS 49
Tabla 4.4: Estructura de la relacion DataResource.
Campo Tipo de dato
id int(11)
publication date date
edition varchar(100)
publisher varchar(100)
publication place varchar(100)
idDataResource varchar(11)
idStation int(11)
idResource int(11)
title int(11)
resource description text
network address varchar(240)
network resource name varchar(150)
relation varchar(150)
User varchar(150)
password varchar(150)
stnabbr varchar(15)
Figura 4.4: Lnea de comando utilizada en la creacion de la relacion DataResource.
CAP

ITULO 4. RESULTADOS 50
4.1.5 Creacion del Deposito Temporal de Metadatos
El Deposito Temporal de Metadatos se creo en la base de datos DBmetadatos y su nombre es Temp-
DataResource. En la tabla 4.5 se muestra la estructura de la relacion TempDataResource mientras que en
la gura 4.5 se muestra la lnea de comando para la creacion de la relacion TempDataResource.
Tabla 4.5: Estructura de la relacion TempDataResource.
Campo Tipo de dato
id int(11)
iduser varchar(20)
IPServer varchar(20)
publication date date
edition varchar(100)
publisher varchar(100)
publication place varchar(100)
idDataResource varchar(11)
idStation int(11)
idResource int(11)
title int(11)
resource description text
network address varchar(240)
network resource name varchar(150)
relation varchar(150)
user varchar(150)
password varchar(150)
Sigue . . .
CAP

ITULO 4. RESULTADOS 51
Continuacion...
stnabbr varchar(15)
Figura 4.5: Lnea de comando utilizada en la creacion de la relacion TempDataResource.
4.2 Proceso de B usqueda Distribuida
A continuaci on se describe el dise no y desarrollo de los componentes del proceso de b usqueda de recursos
distribuidos: la Interfaz de B usqueda, el Intermediario Web y el Componente Comunicaciones.
4.2.1 Acceso a la Interfaz de B usqueda
Figura 4.6: Interfaz de B usqueda de Recursos Distribuidos sobre Internet.
La gura 4.6 muestra el dise no de la Interfaz de B usqueda de Recursos Distribuidos. La Interfaz de
CAP

ITULO 4. RESULTADOS 52
B usqueda es un programa creado con el lenguaje de programacion Perl y su nombre es MBBusquedaDis-
tribuida.cgi. La Interfaz de B usqueda incluye las funciones: Diccionario de Estaciones, Diccionario de
Recursos y Compartir Recursos Oceanogracos. Si el administrador del sistema elige dar un click en el
vnculo Diccionario de Estaciones, entonces se inicia la ejecucion del programa MBRegEstacion.cgi, que
permite dar de alta estaciones mareogracas de las cuales el nodo ROPVO tiene datos. Esta pagina solicita
al administrador que introduzca el identicador de la estacion, nombre y la descripcion de la estacion, ver
gura 4.7.
Figura 4.7: Interfaz para el registro de Estaciones Mareogracas.
Si el administrador del sistema elige dar un click en el vnculo Diccionario de Recursos entonces, se
inicia la ejecucion del programa MBRegTipoRecurso.cgi, que permite dar de alta recursos de los cuales
el nodo ROPVO tiene datos. Esta pagina solicita al usuario que introduzca el identicador del recurso,
nombre y la descripcion del recurso, ver gura 4.8.
Si el administrador del sistema elige dar un click en el vnculo Comparticion de Recursos Oceanogracos,
entonces se inicia la ejecucion del programa MBRegRecurso.cgi, el cual permite registrar los metadatos de
los recursos de los cuales el nodo ROPVO tiene datos. Esta pagina solicita al usuario que introduzca el
identicador de la estacion, el identicador del recurso, la fecha de publicacion, la edicion, el publicador,
CAP

ITULO 4. RESULTADOS 53
Figura 4.8: Interfaz para el registro de Diccionario de Recursos.
el lugar de publicacion, el ttulo, la descripcion del recurso, la direccion en la red, el nombre del recurso
en la red, el nombre de la relacion, el nombre del usuario y la contrase na, (gura 4.9).
Figura 4.9: Interfaz para el registro de Comparticion de Recursos Oceanogracos.
CAP

ITULO 4. RESULTADOS 54
Ahora bien, para iniciar el proceso de B usqueda Distribuida, primeramente el usuario escribe en la
caja de texto, Descripcion del recurso, la solicitud de B usqueda, Figura 4.6. Enseguida procede a dar un
click en el boton Buscar; esta accion enviar a la solicitud de b usqueda al componente Intermediario Web.
4.2.2 Intermediario Web
El Intermediario Web es un programa creado con el lenguaje de programacion Perl y su nombre es MBIn-
termediarioW.cgi. La gura 4.10 muestra las funciones que integran al Intermediario Web.
Figura 4.10: Funciones del Intermediario Web.
A continuaci on se describen cada uno de los elementos que integran al Intermediario Web.
Mutella Socket. Este procedimiento crea un socket para la comunicaci on entre la Interfaz Web de
B usqueda y el Intermediario Web.
RunDeamonProcess. Este procedimiento contiene el mecanismo para recibir las peticiones de la
Interfaz Web de B usqueda y hacerlas llegar al Mecanismo de B usqueda Distribuida.
Start Mutella. Inicializar el proceso de comunicaci on con el Intermediario Web por medio de una
tubera.
Send And Receive. Este procediemiento contiene las instrucciones necesarias para hacer llegar
las peticiones de la Interfaz Web de B usqueda al Intermediario Web.
CAP

ITULO 4. RESULTADOS 55
Restart Deamon. Se encarga de reiniciar el proceso del Intermediario Web en caso de falla.
Exit Deamon. Este procedimiento se encarga de nalizar la ejecucion de la aplicacion Intermediario
Web.
RemoveAnsiColor. Este procedimiento se encarga de eliminar los caracteres de color producto de
las respuestas del Mecanismo de B usqueda de Recursos Distribuidos.
Debug. Este procedimiento se encarga de mostrar los resultados del proceso de ejecucion del
Intermediario Web.
El Componente Comunicaciones es un programa P2P creado con el lenguaje de programacion C++ y
su nombre es mutella.c. El programa mutella contiene el proceso de b usqueda distribuida que a su vez
contiene dos procesos que son la B usqueda Local y la B usqueda Remota.
CAP

ITULO 4. RESULTADOS 56
4.2.3 Proceso de B usqueda Local
El Proceso de B usqueda Local (PBL) pertenece al Componente de Comunicaciones, (ver gura 3.3). El
PBL es una funcion que se realizo con el lenguaje de programacion C++ y su nombre es GnuSearch.cpp.
La Implementacion del PBL se realizo mediante la funcion void MgnuSearch::SendQuery() que pertenece
a la clase gnuSearch, por lo tanto, esta funcion contiene el codigo que realiza el PBL.
Figura 4.11: Fragmento de codigo que ejemplica el paso de parametros de solicitud de b usqueda local al
componente Analizador Lexico.
La gura 4.11 ejemplica el fragmento de codigo que se encargo de realizar el PBL de recursos. Note
que sQuery.c str() es la variable que contiene la solicitud de b usqueda del usuario. La lnea 4 muestra
como la instruccion System() invoca al programa AnalizadorLexico y le enva el parametro de solicitud de
b usqueda almacenado en sQuery.c str(). De esta manera se puede resumir que el PBL incluye las funciones
Analizador Lexico, Construccion de la Instruccion SQL, Ejecucion de la Consulta y Almacenamiento
Temporal de Metadatos.
Funci on Analizador Lexico
El Analizador Lexico es un programa dise nado con el lenguaje de programacion C++, ver seccion 3.2.3.
Su nombre es AnalizadorLexico.cpp que incluye dos programas que son FBibliotecaEstaciones y FBibliote-
caTipoRecurso. FBibliotecaEstaciones es un programa que identica los nombres de estaciones que forman
CAP

ITULO 4. RESULTADOS 57
parte de la solicitud de b usqueda del usuario. La gura 4.12 ejemplica las lneas de codigo del programa
FBibliotecaEstaciones.
Figura 4.12: Fragmento de codigo que ejemplica la deteccion de estaciones.
De la lnea 1 a la lnea 6 se obtienen los nombres de las estaciones de la relacion stations que pertenecen
a la metabase de datos DBmetadatos. De la lnea 7 a la lnea 17 se comparan los nombres de las estaciones
con la solicitud de b usqueda del usuario. Al terminar la funcion, la matriz MatEstaciones almaceno el
identicador de la matriz, la cadena idStation, el nombre de la estacion y la clave de la estacion que
pertenecen a la estacion buscada.
CAP

ITULO 4. RESULTADOS 58
FBibliotecaTipoRecurso es un programa que identica los nombres de los recursos que forman parte
de la solicitud de b usqueda del usuario. La gura 4.13 ejemplica las lneas de codigo del programa
FBibliotecaTipoRecurso.
Figura 4.13: Fragmento de codigo que ejemplica la deteccion de recursos.
De la lnea 1 a la lnea 6 se obtienen los nombres de los recursos de la relacion Resource que pertenecen
a la metabase de datos DBmetadatos. De la lnea 7 a la lnea 18 se comparan los nombres de los recursos
con la solicitud de b usqueda del usuario. Al terminar la funcion, la matriz MatEstaciones almaceno
el identicador de la matriz, la cadena idResource, el nombre del recurso y la clave del recurso que
pertenecen al recurso buscado.
CAP

ITULO 4. RESULTADOS 59
Construccion de la Instruccion SQL
La Construccion de la Instruccion SQL es un programa que se dise n o con el lenguaje de programacion
C++ el cual es llamado CadenaSQL (ver seccion 3.2.3). La gura 4.14 muestra las lneas de codigo de
la funcion CadenaSQL. De la lnea 2 a la lnea 15 se recorre la matriz MatEstaciones que contiene los
nombres de las estaciones y recursos a consultar. Al terminar la funcion, la cadena condicion contendr a
la instruccion SQL para el acceso a los metadatos de los recursos.
Figura 4.14: Fragmento de codigo que ejemplica la construccion de la cadena SQL.
Ejecucion de la Consulta
La Ejecucion de la Consulta es un programa que se dise n o con el lenguaje de programacion C++, el cual
es llamado EjecucionSQL (ver seccion 3.2.3). La gura 4.15 muestra las lneas de codigo de la funcion.
CAP

ITULO 4. RESULTADOS 60
De la lnea 1 a la lnea 8 se ejecuta la consulta SQL almacenada en la variable Condicion y se extrajeron
los metadatos que cumplieron con la solicitud de consulta de la relacion DataResource que pertenece a la
metabase de datos DBmetadatos. De la lnea 9 a la lnea 13, se encuentran los comandos que enva los
metadatos obtenidos por la consulta a la funcion Almacenamiento Temporal de Metadatos.
Figura 4.15: Fragmento de codigo que ejemplica la ejecucion de la cadena SQL.
Almacenamiento Temporal de Metadatos
El Almacenamiento Temporal de Metadatos es un programa que se dise n o con el lenguaje de programacion
C++, el cual es llamado FInsertarFilasEnTempRecursos (ver seccion 3.2.3). La gura 4.16 ejemplica las
CAP

ITULO 4. RESULTADOS 61
lneas de codigo de la funcion. De la lnea 1 a la lnea 7 se establece conexion con la base de datos DB-
metadatos. La lnea 8 almacena temporalmente los metadatos recibidos por la funcion EjecucionSQL en
la relacion TempDataResource perteneciente a la metabase de datos DBmetadatos.
Figura 4.16: Fragmento de codigo que ejemplica el almacenamiento temporal de metadatos.
4.2.4 Proceso de B usqueda Remota
El proceso de B usqueda Remota tambien pertenece al Componente de Comunicaciones, ver gura 3.3. El
Proceso de B usqueda Remota (PBR) es una funcion que se realizo con el lenguaje de programacion C++
el cual es llamado GnuSearch.cpp y se encargo de la propagacion la solicitud de b usqueda del usuario en
los nodos ROPVO. Ahora bien, la funcion encargada de recibir la solicitud de b usqueda que se propago por
un nodo ROPVO es: void MgnuNode::Receive Query(packet Query* Query, int nLength), que pertenece
CAP

ITULO 4. RESULTADOS 62
a la clase gnuNode, por lo tanto, esta funcion contiene el codigo que realiza el PBL para la extraccion de
los metadatos remotos al nodo solicitante.
Figura 4.17: Fragmento de codigo que ejemplica el paso de parametros de solicitud de b usqueda remota
al componente AnalizadorLexico.
La gura 4.17 ejemplica el fragmento de codigo que se encarga de recibir la solicitud de b usqueda que
se propago desde un nodo remoto ROPVO. Note que pSR > m query.Text es la variable que contiene
la solicitud de b usqueda del usuario. Ahora bien, en la lnea 3 se observa que la variable DatoR almacena
la ruta y nombre del programa Analizador Lexico mas el parametro de solicitud de b usqueda. La lnea 4
muestra como la instruccion System() invoca al programa AnalizadorLexico.cpp y le enva el parametro
de solicitud de b usqueda almacenado en pSR > m query.Text.
4.2.5 Resultados de la B usqueda Distribuida
Los resultados de la B usqueda Distribuida no es mas que la representaci on de los resultados del PBL y
PBR en una Interfaz Web. La funcion MBResultados forma parte del programa MBBusquedaGeneral.cgi
y es la encargada de mostrar los resultados de la solicitud de b usqueda en la Interfaz Web. La gura 4.18
muestra la Interfaz Web de Resultados de la B usqueda de Recursos Distribuidos. La Interfaz Web de
Resultados presenta al usuario los metadatos de ttulo del recurso, de descripcion y la direccion fsica en
red. Si el usuario desea consultar recursos almacenados en paginas Web entonces, procede a dar un click
CAP

ITULO 4. RESULTADOS 63
en el ttulo del recurso que desea consultar, ver gura 4.19. Si el usuario desea consultar los datos de los
recursos almacenados en base de datos entonces, el usuario procede a dar un click en una de las cajas de
vericacion que pertenecen al recurso que se desea consultar. En seguida se procede a dar un click en el
boton Consultar, esta accion inicia el proceso de Consulta de Recursos Distribuidos.
Figura 4.18: Interfaz Web que muestra los metadatos que se obtuvieron del proceso de B usqueda de
Recursos Distribuidos.
CAP

ITULO 4. RESULTADOS 64
Figura 4.19: Interfaz Web de la estacion mareograca de Tampico, Tamaulipas.
CAP

ITULO 4. RESULTADOS 65
4.3 Proceso de Consulta Distribuida
A continuacion se describen los elementos que incluyeron al proceso de Consulta Distribuida: el Acceso a
la Interfaz de Consulta, Formulaci on de la Consulta, el Proceso de Consulta, el proceso de Extraccion de
Datos y los Resultados de la Consulta.
4.3.1 Acceso a la Interfaz de Consulta
La gura 4.20 ejemplica las lneas de codigo para la creacion de un conjunto de estaciones que tienen un
recurso en com un.
Figura 4.20: Fragmento de codigo que ejemplica la creacion de un conjunto de estaciones que tienen un
recurso en com un.
Primeramente se hace notar que la matriz @MEstaSelec representa la matriz M y la matriz @ClasRe-
CAP

ITULO 4. RESULTADOS 66
cursos representa la matriz N, ver seccion 3.3.1. Ahora bien, de la lnea 1 a la lnea 20 se recorre la matriz
@MEstaSelec para obtener las estaciones que tienen un recurso en com un. De la lnea 3 a la lnea 6 se
registra la primera estacion que tiene un recurso en com un en la matriz @ClasRecursos. Enseguida, de
la lnea 7 a la lnea 17 se verica si el recurso almacenado en @MEstaSelec[j][10] pertenece a uno de los
recursos almacenados en la matriz @ClasRecursos . Para los casos en que la comparacion sea verdadera,
la estacion MEstaSelec[j][2] formo parte del conjunto de estaciones del recurso ClasRecursos[ki][1]. En
caso de que el recurso MEstaSelec[j][10] no formara parte del conjunto de recursos ClasRecursos[ki][0]
entonces, de la lnea 14 a la lnea 17 se creo un nuevo conjunto de estaciones con un recurso en com un
llamado MEstaSelec[j][10] que almaceno la estacion MEstaSelec[j][2] .
4.3.2 Formulacion de la Consulta
La formulacion de la consulta se llevo a cabo a traves de la Interfaz de Consulta que es un programa que
se creo con el lenguaje de programacion Perl, cuyo nombre es MBpquery.cgi. La gura 4.21 muestra el
dise no de la Interfaz de Consulta que incluye las secciones Par ametros de B usqueda Basica, Opciones de
Gracacion y Opciones Ascii.
Figura 4.21: Interfaz Web para la Consulta de Recursos Distribuidos.
CAP

ITULO 4. RESULTADOS 67
4.3.3 Proceso de Consulta
El Procesamiento de la Consulta lo realizo el Intermediario de Consulta que es un programa que se creo con
el lenguaje de programacion Perl, cuyo nombre es MBpmdata.cgi y se encarga de procesar la solicitud de
consulta del usuario. La gura 4.22 ejemplica las lneas de codigo para la creacion del formato para la lista
de estaciones. Primeramente se hace notar que la matriz @V arClasRecursosFila representa la matriz N,
ver seccion 3.3.1, y la variable V arsslist representan la cadena de formato para la lista de estaciones. De
la lnea 1 a la lnea 19 se recorre la matriz V arClasRecursosFila que contiene los conjuntos de estaciones
que contiene un recurso en com un. De la lnea 7 a la lnea 10 se obtiene el conjunto de estaciones que
pertenecen a un recurso y se almacena en la matriz V arEstaciones. Enseguida, de la lnea 11 a la lnea
19 se creo la cadena de formato de lista de estaciones y se almaceno en la variable V arsslist. Finalmente
el formato para la lista de estaciones es enviado al Proceso de Extraccion de Datos.
Figura 4.22: Fragmento de codigo que ejemplica el proceso para la creacion del formato para la lista de
estaciones.
CAP

ITULO 4. RESULTADOS 68
4.3.4 Proceso de Extraccion de Datos
El proceso de Extraccion de Datos es un programa que se creo con el lenguaje de programacion C++ cuyo
nombre es sxext.c. La gura 4.23 ejemplica las lneas de codigo para la extraccion de los recursos de la
base de datos del nodo ROPVO.
Figura 4.23: Fragmento de codigo que ejemplica el Proceso de Extraccion de Datos.
De la lnea 1 a la lnea 11 se establecio conexion con la base de datos DBmetadatos. La lnea 12
almacena en la variable sqlcmd la solicitud de consulta y el formato de cadena de lista de estaciones. De la
lnea 13 a la lnea 15 se ejecuta la solicitud de consulta almacenada en la variable sqlcmd y se extrajeron
CAP

ITULO 4. RESULTADOS 69
los recursos de la base de datos del nodo ROPVO. De la lnea 16 a la lnea 27 se envio los resultados
obtenidos de la ejecucion de la solicitud de consulta hacia la Interfaz Web del usuario.
4.3.5 Resultados de la Consulta Distribuida
La gura 4.24 muestra en forma de graca los datos oceanogracos recolectados de la estacion mareograca
de Tampico Tamaulipas. El intervalo de fechas de los datos mostrados por la graca van de 01/01/2006 a
01/09/2006 con una altura maxima del nivel del mar de aproximadamente 4m.
Figura 4.24: Interfaz Web que muestra en forma de graca los datos extraidos de la estacion mareograca
de Tampico Tamaulipas.
CAP

ITULO 4. RESULTADOS 70
La gura 4.25 muestra los resultados obtenidos del proceso de Consulta Distribuida en forma de texto
en la Interfaz Web.
Figura 4.25: Interfaz Web que muestra en forma de texto los datos extrados de la estacion mareograca
de Tampico Tamaulipas.
Captulo 5
Pruebas
Este captulo contiene la descripcion de las pruebas, las cuales incluyen la descripcion del ambiente y
condiciones de prueba realizadas a la implementaci on de la arquitectura.
5.1 Objetivos de las pruebas
El objetivo principal de las pruebas fue comprobar la funcionalidad de la herramienta en los siguientes
aspectos.
La capacidad de la herramienta de software para acceder a los recursos oceanogracos distribuidos
en los nodos ROPVO a traves de Internet.
Vericar que la herramienta de software permite la b usqueda remota de los metadatos distribuidos
en diferentes nodos ROPVO.
Vericar que la herramienta de software permite la consulta remota de los recursos de las estaciones
mareogracas de los nodos ROPVO.
71
CAP

ITULO 5. PRUEBAS 72
5.2 Descripcion del Ambientes de Pruebas
Las siguientes pruebas principalmente se realizaron en la Intranet del CICATA Unidad Altamira Ubicado
en Altamira, Tamaulipas Mexico y otras se realizaron en el Internet. Ambos ambientes de pruebas se
mencionan a continuaci on.
La gura 5.1 muestra el ambiente de pruebas Uno, que incluye la computadora A y el Nodo ROPVO A.
En el Nodo A se encuentran los datos de las estaciones mareogracas de Mezquital, La Pesca y Tampico.
Las comunicaciones entre las computadoras se realiza en la Intranet instalada en el CICATA. La computa-
dora A es una HP Compaq y posee un procesador Intel Core 2 Duo E4400 a 2.0 Ghz, memoria de 1 GB,
disco duro de 160 GB, tarjeta de red 10/100, monitor LCD de 17 pulgadas y sistema operativo Windows
XP. La computadora A descarga la Interfaz de B usqueda y Consulta Distribuida del Nodo ROPVO A. El
nodo ROPVO A es una computadora Intel y posee un procesador Intel Pentium 4 a 2.26 Ghz, memoria
Ram de 256 MB, tarjeta de red 10/100, disco duro de 40 GB, tarjeta madre Intel, monitor de 17 pulgadas y
sistema operativo Red Hat Linux 9.0. El nodo ROPVO A, contiene la implementaci on de ASBUCORDI y
el sistema de informacion Pharos. Para conocer la instalacion del sistema Pharos checar [35], que almacena
los recursos oceanogracos que desea compartir el nodo ROPVO A.
La gura 5.2 muestra el ambiente de pruebas Dos, que incluye la computadora A y los nodos ROPVO
A y B. En el Nodo B se encuentran los datos de la estacion mareograca de Veracruz. Las comunicaciones
entre las computadoras se realiza en la Intranet instalada en el CICATA. El ambiente de pruebas Dos
es similar al ambiente de pruebas mostrado en la gura 5.1, la diferencia radica en que el ambiente de
pruebas Dos contiene un Nodo adicional. El nodo ROPVO B es una computadora Compaq Presario con
procesador Pentium 4 a 1.8 Ghz, memoria de 512MB en Ram, tarjeta de red 10/100, disco duro de 80 GB,
tarjeta madre Intel, monitor de 17 pulgadas y sistema operativo Red Hat Linux 9.0. El Nodo ROPVO
B, contiene la implementaci on de ASBUCORDI y el sistema de informacion Pharos, que almacena los
recursos oceanogracos que desea compartir el Nodo B.
CAP

ITULO 5. PRUEBAS 73
La gura 5.3 muestra el ambiente de pruebas Tres, que incluye la computadora A y los nodos ROPVO
A,B y C. En el Nodo C se encuentran los datos de la estacion mareograca de Tuxpan. Las comunicaciones
entre los nodos se realiza en la Intranet instalada en el CICATA y la computadora A se comunica con
los nodos ROPVO a traves de Internet. El ambiente de pruebas Tres es similar al ambiente de pruebas
mostrado en la gura 5.2, la diferencia radica en que el ambiente de pruebas Tres contiene un nodo adi-
cional, y que la computadora A no se encuentra en la red del CICATA. El nodo C es una computadora
Intel con procesador Pentium 4 a 2.6 Ghz, memoria de 512MB en Ram, tarjeta de red 10/100, disco
duro de 200 GB, tarjeta madre Intel, monitor de 17 pulgadas y sistema operativo Red Hat Linux 9.0. El
Nodo ROPVO C, contiene la implementacion de ASBUCORDI y el sistema de informacion Pharos, que
almacena los recursos oceanogracos que desea compartir el nodo ROPVO C.
Figura 5.1: Ambiente de pruebas n umero Uno.
CAP

ITULO 5. PRUEBAS 74
Figura 5.2: Ambiente de pruebas n umero Dos.
Figura 5.3: Ambiente de pruebas n umero Tres.
CAP

ITULO 5. PRUEBAS 75
5.3 Casos de Prueba.
Como se describe en el paso anterior se presenta en total tres casos de prueba, con los que se comprueba
la funcionalidad de la herramienta ASBUCORDI.
5.3.1 Prueba No. 1.
Probar que la herramienta de software efectua B usquedas y Consultas de recursos sobre un nodo ROPVO
dentro de la red del CICATA.
Ejecucion de la prueba. Para esta prueba se utilizo el ambiente de pruebas Uno, en donde tenemos
un usuario conectado al Nodo ROPVO A, gura 5.1. En el Nodo A se encuentran los datos de las
estaciones de Mezquital, La Pesca y Tampico. Primeramente se accede a un nodo ROPVO a traves de un
navegador Web, escribiendo en el URL del explorador http://148.204.119.55/MBBusquedaDistribuida.
Enseguida se procede a escribir en la caja de texto titulado descripcion del recurso primer nivel del mar,
gura 5.4. Despues se procede a presionar el boton Buscar, esta accion mostrara la Interfaz de Resultados
de B usqueda.
Figura 5.4: Interfaz de B usqueda de Recursos Distribuidos sobre Internet.
CAP

ITULO 5. PRUEBAS 76
La Interfaz Web de Resultados de la B usqueda muestra al usuario los recursos extrados del nodo A,
gura 5.5. Enseguida el usuario procede a marcar con un click las cajas de vericaci on de las estaciones
mareogracas de Mezquital, Tampico y Pesca. Enseguida presiona el boton Consultar Recursos y la
herramienta muestra al usuario la Interfaz Web de Consulta de Recursos Distribuidos.
Figura 5.5: Interfaz que muestra los resultados de la B usqueda de Recursos Distribuidos sobre Internet.
La Interfaz Web de Consulta de Recursos Distribuidos permite al usuario denir los atributos de la
solicitud de Consulta que se aplicaran en el proceso de Extraccion de los recursos de las estaciones de
Mezquital, Pesca y Tampico. Ahora bien, el usuario procede a formular la solicitud de consulta en la
Interfaz de Consulta. En el campo Dates escribe 01/23/2004-01/30/2008, en el campo Format
selecciona la opcion Gif, en el campo Elevation selecciona la opcion Station Datum, en el campo
Time Zone selecciona la opcion Coordinated Universal Time(UTC). Enseguida presiona el boton
titulado Click here to retrieve data quien mostrara la Interfaz Web de Resultados de la Consulta,
gura 5.6. En la gura 5.7 se muestra la Interfaz Web de Resultados de la consulta distribuida en forma
de graca, gif.
CAP

ITULO 5. PRUEBAS 77
Figura 5.6: Interfaz Web para la Consulta de Recursos Distribuidos.
Figura 5.7: Graca que muestra los datos extrados de las estaciones de Mezquital, la Pesca y Tampico.
CAP

ITULO 5. PRUEBAS 78
5.3.2 Prueba No. 2.
Probar que la herramienta de software efectua B usquedas y Consultas de recursos sobre dos nodos ROPVO
dentro de la red del CICATA.
Ejecucion de la prueba. Para esta prueba se utilizo el ambiente de pruebas Dos, en donde tenemos
dos Nodos ROPVO conectados entre s, gura 5.2. En el Nodo A se encuentran los datos de las estaciones
de Mezquital, La Pesca y Tampico, En el Nodo B se encuentran los datos de las estaciones de Veracruz.
El ejemplo para la b usqueda de recursos fue primer nivel del mar, gura 5.4. La Interfaz Web de
Resultados de la b usqueda muestra al usuario los metadatos de las estaciones de Mezquital, La Pesca,
Tampico y Veracruz extraidos de los nodos ROPVO A y B, gura 5.8.
Figura 5.8: Interfaz que muestra los resultados de la B usqueda de Recursos Distribuidos sobre Internet.
El usuario procede a marcar con un click las cajas de vericacion de las estaciones mareogracas de
CAP

ITULO 5. PRUEBAS 79
Mezquital, La Pesca, Tampico y Veracruz. Continuando con el procedimiento presiona el boton Consultar
Recursos que muestra la Interfaz Web de Consulta de Recursos Distribuidos al usuario. Ahora bien, el
usuario del sistema formula la solicitud de b usqueda de recursos en base a los parametros mostrados en
la gura 5.6. En este punto se realiza la consulta a m ultiples Bases de Datos y se integran los resultados
para presentarlos en la Interfaz de Resultados de la Consulta como una graca gif, gura 5.9.
Figura 5.9: Graca que muestra los datos extrados de las estaciones de Mezquital, la Pesca, Tampico y
Veracruz.
CAP

ITULO 5. PRUEBAS 80
5.3.3 Prueba No. 3.
Probar que la herramienta de software efectua B usquedas y Consultas de recursos utilizando tres nodos
ROPVO a traves de Internet.
Ejecucion de la prueba. Para esta prueba se utilizo el ambiente de pruebas n umero Tres, en donde
tenemos tres nodos ROPVO conectados entre s, gura 5.3. En el nodo A se encuentran los datos de las
estaciones de Mezquital, La Pesca y Tampico, En el nodo B se encuentran los datos de las estaciones de
Veracruz y en el nodo C se encuentran los datos de las estaciones de Tuxpan. El ejemplo para la b usqueda
de recursos fue primer nivel del mar, gura 5.4. Enseguida la Interfaz Web de Resultados de la b usqueda
muestra al usuario los metadatos de las estaciones de Mezquital, La Pesca, Tampico, Tuxpan y Veracruz
extrados de los nodos ROPVO A,B y C, gura 5.10.
Enseguida el usuario procede a marcar con un click las cajas de vericaci on de las estaciones mare-
ogracas de Mezquital, La Pesca, Tampico, Tuxpan y Veracruz. Posteriormente presiona el boton Consul-
tar Recursos y se muestra al usuario la Interfaz Web de Consulta de Recursos Distribuidos. Ahora bien,
el usuario del sistema formula la solicitud de b usqueda de recursos en base a los parametros mostrados
en la gura 5.6. Finalmente se realiza la Consulta a m ultiples Bases de Datos y se integran los resultados
para presentarlos en la Interfaz de Resultados de la Consulta como una graca gif, gura 5.11.
5.4 Otras Pruebas.
Se realizaron las tres mismas pruebas con salida a archivos. Sin embargo los listados no se incluyen para
evitar muchas guras.
CAP

ITULO 5. PRUEBAS 81
Figura 5.10: Interfaz que muestra los resultados de la B usqueda de Recursos Distribuidos sobre Internet.
CAP

ITULO 5. PRUEBAS 82
Figura 5.11: Graca que muestra los datos extrados de las estaciones de Mezquital, la Pesca, Tampico,
Tuxpan y Veracruz.
Captulo 6
Conclusion y discusion
6.1 Conclusion
La planeacion y desarrollo del proyecto de investigacion demostro la importancia del esquema de metadatos
estantar FGDC, como metodo que permite la organizacion e identicacion de los recursos oceanogracos
compartidos en los nodos ROPVO mediante un mecanismo de b usqueda automatizado, que al ser imple-
mentado en una metabase de datos hace posible la comparticion y extraccion de recursos oceanogracos
distribuidos a traves de Internet. Para la adaptacion correta del estandar FGDC a nuestro esquema de
metadatos propuesto en la seccion 4.1.1, fue necesario agregar algunos metadatos particulares como idsta-
tion, idresource, station name y relation.
La comunidad ROPVO ahora cuenta con un mecanismo que le permite compartir recursos oceanogracos
a traves de Internet. Estos recursos se encuentran almacenados en diferentes Bases de Datos. Los recur-
sos de las instituciones que participan en la red ROPVO pueden almacenar y compartir recursos que se
encuentran almacenados en texto, imagenes, video, sonido, paginas Web o bases de datos. Los cientcos
del area de ingeniera oceanica y costera ahora cuentan con una herramienta poderosa para la b usqueda y
consulta de recursos oceanogracos distribuidos sobre Internet.
La herramienta de b usqueda y consulta de recursos distribuidos es un medio de consulta de datos
83
CAP

ITULO 6. CONCLUSI

ON Y DISCUSI

ON 84
oceanogracos util para la sociedad en general, ya que apoya a las instituciones encargadas de la seguridad
en los puertos y proteccion civil al informarles del clima oceanico del Golfo de Mexico en tiempo casi real.
Gracias a esta nueva tecnologa, las Instituciones interesadas en compartir recursos oceanogracos tienen
la posibilidad de compartir su informacion a traves de Internet.
Los resultados exitosos obtenidos de nuestra herramienta en el proceso de b usqueda y consulta de
recursos oceanogracos distribuidos en la comunidad ROPVO, ver seccion 5.1. demostro que es factible el
desarrollo de aplicaciones distribuidas mediante el uso de software libre.
La implemetacion de esta herramienta dise nada bajo una arquitectura peer-to-peer, demostro ser una
herramienta factible para el intercambio de recursos oceanogracos distribuidos en la comunidad ROPVO,
ademas esta arquitectura permitio reducir los costos monetarios en equipo de computo, aproximadamenta
a $1,200.00 por cada nodo conectado a la comunidad. Debido a su naturaleza, nuestra herramienta de-
mostro ser un sistema altamente tolerante a fallos a pesar de la actividad intermitente de los nodos de la
comunidad ROPVO, evitando asi la cada total del sistema.
El empleo de cookies fue de gran importancia en el desarrollo de este proyecto ya que fue el medio
utilizado para el paso de parametros entre paginas Web. La utilizacion de la interfaz de comunicaci on
socket fue la clave para la comunicacion entre aplicaciones de software realizadas en diferentes lenguajes
de programacion.
El SMBD MySQL demostro ser una herramienta ecaz para el almacenamiento de los metadatos y re-
cursos de la comunidad ROPVO. Sin embargo, Por defecto las bases de datos creada por MySQL no cuenta
con el permiso de acceso remoto desde otras computadoras, por lo que fue necesario estalecer estos per-
misos de acceso mediante los comandos setpasswordfor, quien permite establecer la contrase na de acceso
a base de datos y grantallprivilegeson, quien permite el acceso al usuario desde una computadora remota.
CAP

ITULO 6. CONCLUSI

ON Y DISCUSI

ON 85
Finalmente, el sistema Pharos desarrollado por DNR[3], es ahora ampliado con un mecanismo que le
permite realizar extracciones y consultas de datos oceanogracos distribuidos sobre Internet.
6.2 Alcances Logrados
La implementaci on de la Arquitectura de Software actualmente puede crecer hasta soportar 10 nodos
simultaneamente por cada nodo conectado a la red ROPVO. Sin embargo el administrador del sistema
puede incrementar o decrementar el n umero de nodos participantes en la red ROPVO sin que esto afecte
el desempe no del sistema. Esto se logra cambiando el valor del paramentro MaxConnection = 10, quien
contiene el n umero maximo de nodos permitidos para conectarse a un nodo ROPVO. Este parametro se
localiza en el archivo de conguracion .mutella/mutellarc.
Actualmente la metabase de datos sopora cinco recursos oceanogracos que son: Primer Nivel del Mar,
Temperatura del Mar, Salinidad y Velocidad Promedio, sin embargo es posible incrementar los tipos de
recursos que soporte el sistema. Para esto, la Interfaz de B usqueda de recursos cuenta con el modulo
Diccionario de recursos que permite al administrador del sistema agregar, modicar o borrar los nombres
de los recursos que soporte el sistema.
En estos momentos la implementaci on de la arquitectura de software opera solamente bajo el sistema
operativo Red Hat Linux 9.0. El equipo de hardware empleado requiere, para un optimo funcionamiento
como mnimo, un procesador pentium 4 a 2.5. Ghz, memoria de 1 GB en Ram, tarjeta de red 10/100,
tarjeta madre Intel y monitor de 17 pds.
Por el momento las conexiones entre los nodos ROPVO se realizan de un modo manual. Esto quiere
decir, que el administrador del sistema necesita ingresar al Componente de Comunicaciones Mutella y
ejecutar la lnea de comando open Direccion IP:Puerto; donde el parametro Direccion IP:Puerto cor-
responde a la direccion IP y puerto del Componente de Comunicaciones Mutella perteneciente al nodo
CAP

ITULO 6. CONCLUSI

ON Y DISCUSI

ON 86
ROPVO con quien se desea establecer comunicacion, ver seccion 3.2. Por tal motivo se requiere desarrollar
un mecanismo automatico que realice las actividades mencionadas anteriormente y que permita al sistema
establecer conexion con cada uno de los nodos ROPVO.
6.3 Trabajos Futuros
Desarrollar un software tipo Web cache, que contenga un mecanismo que permita localizar automaticamente
nuevos nodos en la red ROPVO. El software debera contener un archivo llamado Host, que almacene las
direcciones IP de los nodos ROPVO. Cuando el administrador del sistema ejecute la herramienta, esta
establecera comunicacion con el software Web cache que devolver a las direcciones IP de los nodos ROPVO
disponibles para el intercambio de recursos. Enseguida con la herramienta de software presentada en este
trabajo se procedera a establecer conexion con cada uno de los nodos devueltos por el sistema Web cache
iniciandose con el proceso de intercambio de recursos.
Actualmente la instalacion de la herramienta ASBUCORDI en computadoras con Red Hat Linux 9.0
se realiza manualmente por lo que es necesario dise nar e implementar un software para la instalacion
automatica de la herramienta. El software se encargara de instalar los Procesos de B usqueda y Consulta
distribuida, ademas de instalar el sistema peer to peer mutella, encargado de la comunicaci on entre los
nodos ROPVO.
En estos momentos la herramienta de software ASBUCORDI opera bajo el sistema operativo Red Hat
Linux 9.0, por lo que otro trabajo interesante sera emigrar la herramienta de software al Sistema Operativo
Windows (SOW). Para lograr esto, es primeramente necesario instalar en la maquina con SOW el ambi-
ente de desarrollo de la herramienta, que son: el servidor Web Apache, la herramienta para el desarrollo
de paginas Web dinamicas WIKI y el lenguaje de programacion para Internet PHP y PERL. Enseguida
se tendra que vericar la compatibilidad del codigo de la herramienta con el ambiente de desarrollo de
sitios web para Windows. Finalmente se tendran que realizar las modicaciones necesarias al codigo de
CAP

ITULO 6. CONCLUSI

ON Y DISCUSI

ON 87
la herramienta para lograr una migracion exitosa al SOW.
Una vez emigrado la herramienta de software ASBUCORDI al SOW, otro trabajo a futuro consistira
en implementar el software de instalacion automatica de la herramienta para el SOW.
Bibliografa
[1] Comision Oceanograca Intergubernamental, 2002, El desarrollo sostenible y la Comision
Oceanograca Intergubernamental de la UNESCO, 30 pp.
[2] http:\\lighthouse.tamucc.edu\TCOON, Texas Coastal Ocean Observation Network (TCOON).
[3] http:\\dnr.cbi.tamucc.edu\TCOON\HomePage, Texas Coastal Ocean Observation Network
(TCOON).
[4] Meza E., Salles P., Figueroa J., Silva Rodolfo, 2003 Red de Observaciones y Predicciones de Variables
Oceanicas en las Costas y Puertos del Golfo de Mexico (ROPVO-GM).
[5] Fabiola Rasgado Celaya, 1999, Herramienta para Consultas Basadas en Ejemplos (QBE) para una
Base de Datos en Internet, Centro Nacional de Investigaci on y Desarrollo Tecnol ogico, Cuernavaca
Morelos.
[6] May Arrioja, Alfonso de los Angeles, 2000, Herramienta para Consultas Basadas en Ejemplos (QBE)
para Multibases de datos en Internet. Centro Nacional de Investigaci on y Desarrollo Tecnologico,
Cuernavaca Morelos.
[7] George Coulouris, Jean Dollimore, Tim Kindberg, 2005, Sistemas Distribuidos Conceptos y Dise no,
Editorial Addison Wesley, Tercera Edicion, 287 pp.
[8] http://www9.limewire.com/developer/gnutella-protocol 0.4.pdf, 2001, Gnutella: The gnutella pro-
tocol specication v.0.4
88
BIBLIOGRAF

IA 89
[9] Carmen de Pablos Heredero, Jose Juaqun Lopez-Hermoso Aguius, Direccion y gestion de los sistemas
de informacion en la empresa una vision Integrada. Segunda Edicion, Universidad Rey Juan Carlos,
342 pp.
[10] Ramon Jes us Millan Tejedor, 2007, Domine las Redes (P2P) Peer-to-Peer, Editorial Alfaomega,
Segunda Edicion, 330 pp.
[11] Ming-Hsiang Tsou, 2002, An operacional Metadata Framework for Searching, Indexing, and Retriev-
ing Distributed Geographic Information Services on the Internet Departament of Geography, San
Diego State University, [email protected].
[12] Paul Clements. A Survey of Architecture Description Languages. Proceedings of the International
Workshop on Software Specication and Design, Alemania, 1996.
[13] David Garlan y Mary Shaw., 1994, An introduction to software architecture. CMU Software Engi-
neering Institute Technical Report, CMU/SEI-94-TR-21, ESC-TR-94-21.
[14] Mary Shaw y David Garlan.,1996, Software Architecture: Perspectives on an emerging discipline,
Upper Saddle River, Prentice Hall.
[15] Andrew S. Tanenbaum, Roberto Escalona Garca, 2004 Sistemas Operativos Modernos, Editorial
Prentice Hall, Segunda edicion, 951 pp.
[16] Peter Rob, Carlos Coronel, 2002 Sistemas de Bases de Datos, Dise no, Implementacion y Adminis-
tracion, Editorial Prentice Hall, Quinta edicion, 838 pp.
[17] Edelstein, Herb., 1994 Unraveling Client/Server Architecture. 34 pp.
[18] http://www.openp2p.com/, Clay Shirky, 2000, What is P2P ... And What is not.
[19] Jose Antonio Ma nas, Rafael Fern andez Calvo, 2003, Mundo IP, Introduccion a los Secretos de
Internet y las Redes de Datos, Editorial nowtilus, 360 pp.
BIBLIOGRAF

IA 90
[20] Manuel G. Velasquez, 2006,

Etica en los Negocios, Conceptos y Casos, Sexta edicion, Editorial

Prentice Hall, 448 pp.
[21] http://www.gnutella.com/, Gnutella
[22] Wally Wang, 2004 Steal this File Sharing Book: What They Wont Tell You about File, 273 pp.
[23] Gonzalo Asensio, 2006, Seguridad en Internet. Una gua practica y ecaz para proteger su PC con
software gratuito, editorial nowtilus, 318 pp.
[24] http://setiathome.ssl.berkeley.edu/download.com/, SETI@Home, B usqueda de Inteligencia Ex-
traterrestre
[25] http://www. stanford.edu/group/pandegroup/folding/, Folding@Home, Comp. distribuida
[26] http://www.stanford.edu/group/pandegroup/gnome/, Genome@Home, The Human Genome
Project
[27] Ahmar Abbas, 2005, Grid Computing: A Practical Guide to Technology and Applications, 408 pp.
[28] Belazquez, F., Cabero, J. y Loscertales, 1994, Nuevas tecnologas de la Informacion y la Comuni-
cacion para la Educacion. Ediciones Alfar, pags. 114-121.
[29] Gunter Born, 2001, Compendium HTML: Con XHTML, DHTML, CSS, XML, XSL y WML, Edi-
torial marcombo, 974 pp.
[30] http://www9.limewire.com/developer/gnutella protocol 0.4.pdf, LimeWire Site, The Gnutella Pro-
tocol Specication v0.4, Document Revision 1.2
[31] http:\\mutella.sourceforge.net\ ,Sistema peer to peer Mutella
[32] Ingo Lackerbauer, 2000, Todo sobre Internet: Completo, Claro y Conciso, Editorial marcombo ,215
pp.
[33] Amit Sheth, Miltiadis D. Lytras, 2007 Semantic Web-based Information Systems: State-of-the-art
Applications, 317 pp.
BIBLIOGRAF

IA 91
[34] http:\\www.niso.org, 2004, Understanding Metadata, National Information Standards Organiza-
tion
[35] Manuel Borrego, Eustorgio Meza, Rogelio Ortega, 2005 Dise no y Desarrollo de un Portal Web para
un Sistema de Observaci on Oceanograco en el Golfo de Mexico, CICATA-IPN. 77 pp.
[36] F.J. Ceballos, 2006 Java 2: Lenguaje y aplicaciones, Editorial Ra-ma, 215 pp.