Índice de contenido

1. Las Clases que Forman el Sistema	1

1.1. ui	3

1.1.1. ServerConnect	3

1.1.2. Search	4

1.1.3. ShowResults	4

1.1.4. ShowTree	5

1.2. Drivers	5

1.3. protocols	6

1.4. querys	7

1.5. languages	7

1.6. metadataXML	8

1.7. parsers	9

1.8. utils	9

2. Estructura General del Sistema	10

3. Protocolos de Comunicación	11

3.1. z39.50	11

3.2. HTTP	11

3.3. SOAP	11

4. Protocolos de Catálogo	11

4.1. z39.50	11

4.2CSW	11

4.3. SRW	11

5. Lenguajes Soportados	12

5.1. BER	12

5.2. FILTER ENCODING	13

6. Los Tags	14

7. Librerías Necesarias	14

Este documento trata de explicar brevemente el diseño que se ha seguido en la elaboración del prototipo del cliente de catálogo. Su propósito es aclarar y justificar la estructura que se ha seguido en la elaboración del mismo.

El documento se divide en una serie de puntos fundamentales: en el primero se hace una breve explicación de todas las clases que tiene el sistema de forma individual. En el segundo punto veremos la relación que tienen estas clases entre ellas viedo el sistema como un todo. En los siguientes puntos veremos algunas partes concretas del sistema que creemos conveniente explicar con más nivel de detalle.

. Las Clases que Forman el Sistema

Todas las clases del prototipo están contenidas dentro de un paquete llamado es.gva.cit.CatalogClient. En la figura de abajo aparecen todos los paquetes que hemos creado (con sus respectivas clases) que se encuentran dicho paquete:

Primero vamos a hacer una breve descripción de las clases que contiene cada uno de estos paquetes. A continuación, vamos a explicar en detalle cada una de estas clases.

ui: Contiene las clases que implementan la interfaz gráfica.

drivers: Contiene las clases que implementan los drivers que implementan cada uno de los protocolos que el prototipo de catálogo soporta.

protocols: Contiene las clases que implementan los protocolos de comunicaciones que podemos usar para hacer peticiones a un servidor: HTTP, SOAP...

querys: Implementa las clases que crean las consultas específicas de cada protocolo.

languages: En todos los protocolos de catálogo tenemos que hacer una consulta de uno o más campos usando un lenguaje determinado. Este paquete contiene las clases que implementan la construcción de sentecias de consulta para cada uno de los lenguajes que soportan los distintos protocolos.

metadataXML: Implementa algunas clases que nos permiten manipular árboles XML.

parsers: Recupera la información de un árbol XML y crea una estructura con los campos recuperados.

utils: Contiene algunas funciones que hemos creado para manipular strings, trabajar con frames, etc.

Además de estos paquetes, podemos ver también dos clases: CatalogAP y CatalogClient. La primera de ellas simplemente sirve para lanzar la aplicación. Contiene un método main que crea una instancia de la clase que implementa la primera ventana de la aplicación (ui.ServerConnectDialog). La segunda hace de “puente” entre la interfaz gráfica y los distintos drivers que implementa la aplicación. En el punto siguiente explicacremos esto con más detenimiento.

En los siguientes apartados vamos a explicar la función de las clases que contienen cada uno de los paquetes principales de la aplicación.

. ui

Por cada nueva ventana que creamos en la aplicación hemos creado tres clases. La primera de ellas, terminada en “Dialog” extinede de Jframe y en ella se definen las cararterísticas de la ventana, como el tamaño, su modalidad, etc.

La segunda clase (terminada en “DialogPanel”) hereda de JPanel y implementa el panel que debe mostrar el frame. Básicamente está formada por un panel que contiene los botones de la parte inferior de la ventana y por otro panel que contiene el resto de componentes gráficos de la ventana. La tercera clase (terminada en “Panel”) hereda de JPanel y contiene todos los componentes que se deben ver en la ventana que la implementará, exceptuando los botones inferiores.

Se han creado dos paneles por ventana para facilitar la integración en Andami. Para aclarar que es lo que implementa cada ventana vamos ver las capturas de pantalla para las clases que implementan la primera ventana de la aplicación (la ventana de conexión con el servidor).

. ServerConnect

Ventana que permite al usuario seleccionar el servidor y el protocolo que soporta. Permite establecer una primera conexión con el servidor para ver si está activo y si soporta el protocolo especificado. Las clases que implementan esta ventana son:

ServerConnectDialog

ServerConnectDialogPanel

ServerConnectPanel

. Search

Ventana que implementa la interfaz que permite hacer búsquedas. Las clases que la

implementan son

SearchDialog

SearchDialogPanel

SearchPanel

. ShowResults

Ventana que presenta los resultados de la búsqueda. Las clases que la componen son:

ShowResultsDialog

ShowResultsDialogPanel

ShowResultsPanel

. ShowTree

Esta ventana implementa una tree-table de un documento en XML. Las clases que la implementan son:

ShowTreeDialog

ShowTreeDialogPanel

ShowTreePanel

. Drivers

Existe una clase “driver” por cada protocolo de catálogo distinto que hemos implementado. Los nombres de estas clases siguen el patrón <protocolo>CatalogServiceDriver. Todos deben implementar la interfaz IcatalogServiceDriver, que define los mínimos métodos necesarios que debe tener un cliente de catálogo. Estos métodos son:

isProtocolSupported: Dado una URL el driver debe ser capaz de comprobar si el servidor soporta el protocolo que implementa el driver.

getCapabilities: Intenta determinar las cararterísticas del servidor.

setParameters: Configura el cliente con las características que soporta el servidor.

getRecords: Se invoca para hacer una búsqueda de metadatos en el servidor.

Además de esta interfaz, los drivers deben de heradar de la clase abstracta AbstractCatalogServiceDriver que contiene los atributos comunes que tienen todos los protocolos de catálogo y tiene constructores para cada uno de ellos.

El siguiente diagrama de clases muestra la relación que tinen las clases del paquete drivers:

. protocols

Todas las clases que implementan un protocolo de comunicaciones implementan la interfaz Iprotocols, cuyo método doQuery es invocado para realizar una consulta al servidor utilizando el protocolo implementado por dicha clase. El propio nombre de la clase ya indica el protocolo que implementa. Los protocolos que hay implementados son:

HTTP Get

HTTP Post

Soap

Z39.50

. querys

Existe una clase llamada Query que contiene un atributo por cada campo por el que se puede preguntar al hacer la consulta. Existen tantas clases que heredan de esta como protocolos soporte nuestro servidor de catálogo.

Las clases <protocolo>Query deben de implemtar el método getQuery (por heredar de la interfaz Iquery), devolviendo un String con la consulta en el lenguaje soportado por el servidor. En este método contiene la implementación de cómo los distintos protocolos “definen” a los distintos campos por los que se puede hacer una consulta.

. languages

Las clases de este paquete implementan los distintos tipos de lenguaje que usan los protocolos para hacer la consulta. De momento, con los protocolos que hemos implemetado nos hemos encontrado dos lenguajes: el Filter Encoding, que usan los protocolos SRW y CSW, y el BER, que es usado por el Z39.50.

Estas clases deben implemtar la interfaz Ilanguages, cuyo método toString hará que devuelvan un String con la consulta que se tiene que realizar. La clase AbstractGeneralLanguage, simplementa implementa métodos comunes de todos los lenguajes.

. metadataXML

En este paquete existen dos clases:

XMLTree: Implementa métodos estáticos para manipular árboles DOM y ficheros XML. Se puede encontrar la descripción de sus métodos al generar el javadoc del fichero.

XMLTreeNumberOfRecordsAnswer: Crea un fiechero en XML con información de la consulta que se ha realizado. Al hacer invocar un método de tipo getRecords, el driver nos devuleve un vector con el número de elementos que ha encontrado. En la primera posición del vector podemos encontrar un documento XML en el que existe información de los resultados que hemos obtenido al hacer la consulta, como son el número de registros obtenidos, el primer registro recuperado y el último registro recuperado.

. parsers

Como existen dos tipos de documentos XML distintos que nos devuleven los servidores, hemos creado una clase por cada uno de ellos que se encargan de parsear el resultado de los ficheros XML devueltos por el servidor en una estructura común de datos: mirar los atributos de AbstractTags.

. utils

Algunas funciones útiles. Mirar los javadocs de estos documentos.

. Estructura General del Sistema

Hemos obviado la mayoría de clases a la hora de dibujar el diagrama de clases de todo el sistema. Algunas clases no aparecen porque son implementaciones de alguna clase abstracta que sí que aparece, y otras no aparecen porque son clases que implementan métodos estáticos y por lo tanto no deben aparecer.

Como podemos ver en el diagrama las clases que aparecen a la izquierda implementan la interfaz de usuario y se comunican con las clases que implementan la funcionalidad de catálogo utilizando la clase CatalogClient. Esta Clase tiene un atributo de tipo IcatalogServiceDriver que, (después de haber elegido en la primera pantalla de la aplicación el protocolo del servidor), deberá ser convertido (haciendo un casting) al un tipo de driver concreto.

Una vez hecho el casting, todas las operaciones que se hagan a continuación se harán para un protocolo concreto de catálogo. Por ejemplo, si en la segunda ventana de la aplicación de hace una invocación al método getRecords del objeto de tipo IcatalogServiceDriver y en la primera ventana (conexión) se ha elegido el protocolo z39.50, lo que estaremos haciendo realmente es hacer un getRecords de un objeto de la clase z3950CatalogServiceDriver.

Cuando un driver implementa los métodos getCapabilities y/o getRecords, debe de escoger un protocolo de comunicaciones para hacer una petición al el servidor. Dependiendo del protocolo de catálogo, puede usar un solo protocolo de comunicación o varios. En nuestra implementación se emplea el mismo protocolo siempre, pero esto haría falta mejoralo: p.e. intentando hacer una petición HTTPPost una vez una petición HTTPGet haya fracasado.

El driver tiene un atributo de tipo Query. Este atributo se ha puesto en el driver porque al hacer una búsqueda que produce muchos resultados, hacemos la búsqueda de 10 en diez, y la consulta la tenemos que mantener.

. Protocolos de Comunicación

En este punto vamos a describir brevemente los protocolos de comunicación que hemos implemetado. Estas clases no aparecían en el diagrama de clases anterior porque no son atributos de las clases driver. Estas clases se crean dinámicamente cada vez que se quiere hacer una petición al servidor.

. z39.50

Para su implementación hemos usado la líbrería de Java JZKIT (enlace al final de documento), que proporciona una interfaz para usar este protocolo.

. HTTP

Se ha implementado tanto una clase para la versión GET como para la POST. Se han usado el paquete HTTPClient disponible en la página web del proyecto Apache.

. SOAP

Se ha usado una librería especial que ofrece una interfaz para hacer peticiones SOAP (enlace al final de documento), que proporciona una interfaz para usar este protocolo

. Protocolos de Catálogo

En este punto vamos ha hacer una breve descrpción de los distintos protocolos de catálogo que se han desarrollado.

. z39.50

Es un protocolo diseñado para recuperar información bibliográfica. Para hacer una consulta a un servidor z39.50 debemos de establecer una conexión TCP/IP en un puerto determinado (típicamente el 2100) y enviarle un mensaje con una sintáxis concreta. El protocolo soporta más de una operación, y puede ser “statefull”, aunque en nuestro caso no vamos a usar esta característica.

El protocolo puede devolver XML, siempre y cuando nosotros lo indiquemos en la petición. Utiliza el protocolo de comunicaciones z39.50 descrito en el punto anterior. El servidor de Geonetwork lo implementa.

CSW

Utiliza los métodos de HTTP GET y POST (También SOAP) para interrogar al servidor. Es un protocolo sin estado. Devuleve un fichero XML con la repuesta a la consulta. El servidor de Deegree2 lo implementa.

. SRW

Utiliza la interfaz HTTP (GET y POST) para responder a las consultas. Devuleve un fichero en XML con la respuesta a la consulta. El servidor de la IDEE implementa este protocolo.

En la siguiente tabla podemos ver una comparativa de como los distintos protcocolos llaman a los mismos parámetros de la consulta. También hay una breve explicación de que significan cada uno de estos parámetros. El protocolo z39.50 no emplea ninguno, ya que simplemente se utiliza un lenguaje de interrogación para hacer consultas en el servidor.

. Lenguajes Soportados

En el punto anterior hemos visto los distintos protocolos de catálogo que existen. Si vemos la tabla, aparece un campo llamado Query que es implementado por todos los protocolos. Este campo representa una consulta en un lenguaje determinado de interrogación que servirá para preguntar por los campos que queremos recuperar. Para hacernos una idea, el lenguaje SQL podría ser considerado como un lenguaje de interrogación. Los lenguajes que hemos implementado son los siguientes:

. BER

Se puede consultar toda esta información en

http://www.blueangeltech.com/standards/GeoProfile/geo22.htm

Cada consulta por un atributo se hace de la forma:

@attr 1=4 @attr 4=6 @attr 2=3 "XXX"

donde “XXX” es el valor del atributo. Por delante se encuentran tres pares de elementos de elementos que comienzan por @attr cuyo significado es:

1. use: código que representa al atributo por el cual queremos preguntar

4. structure: tipo de dato por el que preguntamos

2. relation: operador

Use

4.	title

62.	abstract

2002	themekey

2041	boundign

Structure

1.	Phrase

2.	Word

6.	Word List

104	URx

109	Numeric String

201.	Coordinate String

204	Composite

210	Date String

Relation

"lessThan";

"lessThanOrEqual";

"equal";

"greaterThanOrEqual";

"greaterThan";

"notEqual";

"overlaps";

"fullyEnclosedWithin";

"encloses";

"fullyOutsideOf";

"near";

"membersContain";

"membersNotContain";

"before";

"beforeOrDuring";

"during";

"duringOrAfter";

"after";

. FILTER ENCODING

Podemos encontrar la especificación completa en

http://portal.opengeospatial.org/files/?artifact_id=8340

Tiene una estructura de XML. La consulta por un atributo se hace siguinedo el esquema:

<Filter>

<Operation>

<PropertyName>XXX</PropertyName>

<Literal>YYY</Literal>

</Operation>

</Filter>

Donde “XXX” es en nombre del atributo por el que se está preguntando e “YYY” es el valor del atributo. El tag Operation puede tener los siguientes valores:

PropertyIsEqualTo

PropertyIsNotEqualTo

PropertyIsLessThan

PropertyIsGreaterThan

PropertyIsLessThanOrEqualTo

PropertyIsGreaterThanOrEqualTo

PropertyIsLike

PropertyIsNull

PropertyIsBetween

. Los Tags

Cada uno de los servidores devuelve la información de una forma determinada. Todos los servidores devuelven un fichero XML, pero no nombran a todos los campos de la misma manera. Ni siquiera se estructuran de la misma manera, por lo que hay que recuperar la información por separado. Para ello se han creado las clases que están en el paquete parsers, que se encargan de recuperar el valor de un nodo concreto del árbol XML y dejar el valor en una estructura común de datos (clase AbstractTags).

. Librerías Necesarias

a2jruntime

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Requerida por el protocolo z2950.

activation

http://java.sun.com/products/javabeans/glasgow/jaf.html

JavaBeans Activation Framework. Necesario registrarse para descargarlo. Requerido por mail.jar.

amic-util

http://prdownloads.sourceforge.net/xmlvoc/amic-util.zip?download.

Implementa una TreeTable.

commons-codec

http://svn.apache.org/builds/jakarta-commons/nightly/commons-httpclient/commons-httpclient-20050522.zip

Requerida por httpclient-2.0.2.

commons.httpclient-2.0.2

http://svn.apache.org/builds/jakarta-commons/nightly/commons-httpclient/commons-httpclient-20050522.zip

Implementa un cliente HTTP.

commons-logging

http://svn.apache.org/builds/jakarta-commons/nightly/commons-httpclient/commons-httpclient-20050522.zip

Requerida por httpclient-2.0.2.

junit

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Requerida por el Z3950.

ki-jzkit-hss

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Librería necesaria para el protocolo z3950.

ki-jzkit-iface

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Librería necesaria para el protocolo z3950.

ki-jzkit-z3950

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Librería necesaria para el protocolo z3950.

ki-util

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Librería necesaria para el protocolo z3950.

log4j-1.2.4

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Requerida por httpclient.

mail

http://java.sun.com/products/javamail/downloads/index.html

JavaMail. Es necesario registrarse para descargarse esta librería.Requrida por soap.jar

ostermillerutils_1_04_03

http://ostermiller.org/utils/ostermillerutils_1_04_03.jar

Permite abrir un navegador desde un programa java.

soap

http://apache.rediris.es/ws/soap/version-2.3.1/soap-bin-2.3.1.zip

Librería necesaria para usar SOAP

xalan

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Requerida por xercesImpl.

xercesImpl

http://www.k-int.com/products/jzkit/latest/ki-jzkit-snapshot-16072002.tar.gz

Para trabajar con árboles XML

2005-05-18T14:09:38