Download transmission of graphics on a distributed environment using java

TRANSMISSION OF GRAPHICS ON A DISTRIBUTED ENVIRONMENT
USING JAVA AND XML
Javier Rodeiro P, Gabriel Pérez
Departamento de Informática. E.S.E. Informática. Edificio Politécnico
Campus de As Lagoas. Universidad de Vigo
RESUMEN
Un problema que nos encontramos al hacer peticiones a una BD u hoja de cálculo
remotas y obtener el resultado de manera gráfica, es el envío a través de una red del
gráfico. Esto es debido a su tamaño, ya que al enviarlos a través de una red siempre
interesa que sea lo menor posible. Con este proyecto se pretende reducir el flujo de datos
necesario en la comunicación entre el cliente y el servidor para representar dichos
resultados. Para conseguirlo, en lugar de enviar el documento resultante en un formato
gráfico estándar, el servidor (servlet Java) enviará una representación en formato
XML(definido mediante un DTD), para generar, a través de un applet Java, la
representación gráfica de los datos. Uno de los puntos más importantes es el tamaño de
los applets. Por eso gran parte del esfuerzo en el desarrollo ha ido dirigido a su
optimización. Otro aspecto importante de los clientes es que no usan clases de Java para
manejar documentos XML. Se ha optado por crear los applets con su propio interprete.
En una conexión de 56600bits/s los applets se descargan en menos de un segundo. Si a
esto le añadimos el tiempo que tarda en abrirse la pagina web que lo contiene y la
ejecución del applet, el tiempo total de espera, desde que se solicita el grafico hasta que
esté en pantalla, es de 1 segundo.
ABSTRACT
One of the problems commonly found when creating graphical results from a remote
database or worksheet is to send the graphical result through the network. This is mainly
due to its size and therefore it is desirable to reduce this as much as possible in order to
speed the submission process. In this project we aimed to reduce the amount of data
1474
exchanged between the client and the server to represent those results. In order to
achieve this, instead of sending the resulting document in a standard graphical format, the
server (Java servlet) will send it in XML format (defined by DTD) and then will produce,
through a Java applet, the final graph of the data. One of the most important points is the
size of the applets and for this reason during the development effort was put into
optimising it. Another important aspect is that the clients do not follow Java classes to
manage XML documents. We then have created the applets with its own interpreter.
Through a connection at 56600 bits/s the applets are downloaded in less than one
second. After adding the time to open the webpage which contains the applet and its
execution the final waiting since asking for the graph until this appears on the screen is
one second.
1 PRIMERA FASE, gdXML
1.1 Desarrollo de la parte cliente
Se ha optado por comenzar el desarrollo del proyecto por la parte cliente basada en
applets Java. Esto es así ya que, una vez finalizada su implementación, nos permitirá
desarrollar una primera versión del servidor centrada solo en las funciones de
procesamiento XML. Esto será explicado con más detalle en la sección dedicada al
desarrollo del servidor. La primera decisión, quizás la más importante, es elegir entre un
applet genérico(es decir, que sea capaz de representar cualquier tipo de gráfico de datos)
y una colección de applets, uno por cada tipo de gráfico de datos al que queramos dar
soporte.
En un comienzo se trabajó con un único applet (gdXMLapp) que interpretaba y
representaba tanto gráficos angulares como de sectores(los dos primeros tipos de
gráficos en ser soportados). Para ello se incluía la clase renderer, que era la encargada
de crear un objeto URL para el archivo XML, abrir un flujo hacia el mismo, interpretarlo y
presentarlo en el navegador. El problema que presenta esta primera solución es que el
tamaño de la clase renderer crecía excesivamente, y de una manera proporcional al
número de tipos de gráficos soportados. Hay que tener en cuenta que debía incluir la
lógica de dibujado de todos y cada uno de los distintos tipos de gráficos a representar.
1475
Por ello, fue separada en clases específicas para cada tipo de gráfico (angulares y de
sectores, en una primera fase de desarrollo).
Las dos clases resultantes de esta separación fueron la clase angular y la clase circular.
Pueden entenderse como una especialización de la clase renderer, ya que cada una está
preparada para interpretar un tipo determinado de gráficos de datos. Con esto se
consigue reducir el tamaño final al incluir tan solo las funciones de dibujado necesarias
para representar el gráfico correspondiente. También es importante destacar la reducción
de tamaño final del applet lograda al eliminar todo el código que se debía incluir para que
la clase renderer distinguiese si lo que iba a interpretar era un tipo de gráfico u otro. Con
la estructura de un applet por tipo de gráfico ya no se hace necesaria esta distinción. El
funcionamiento de estos applets es el siguiente:
•
El applet obtiene del código de la página web el nombre del archivo a
interpretar.
•
Crea un flujo a partir de la URL del archivo.
•
Llama al constructor de la clase dándole como parámetro este flujo.
•
El constructor obtiene los valores necesarios para representar el gráfico.
•
El applet hace uso de los métodos de visualización necesarios para crear la
imagen en el navegador. El proceso de interpretación era un paso muy importante
en el funcionamiento de estos applets.
Hay que tener en cuenta que en esta primera fase se desarrolló sobre la base de un
lenguaje de marcado, gdXML, en el que no se trabaja con figuras o primitivas
geométricas. A continuación se expone una visión reducida del DTD que define gdXML.
<!-- DTD para definir documentos XML de gráficos de datos -->\\
<!ELEMENT grafico (angular | circular)>\\
<!ELEMENT angular(nombre,ymax, nbarras, distancia, ancho, barra *)>\\
<!ELEMENT nombre (\#PCDATA)>\\
<!ELEMENT ymax (\#PCDATA)>\\
<!ELEMENT nbarras(\#PCDATA)>\\
<!ELEMENT distancia (\#PCDATA)>\\
<!ELEMENT ancho(\#PCDATA)>\\
<!ELEMENT barra EMPTY>\\
<!ATTLIST barra valor CDATA \#REQUIRED\\
1476
índice CDATA \#REQUIRED>\\
<!ELEMENT circular (nombre, radio, nsectores, sectores \*)>\\
<!ELEMENT radio (\#PCDATA)>\\
<!ELEMENT nsectores (\#PCDATA)>\\
<!ELEMENT sectores EMPTY>\\
<!ATTLIST sectores porcentaje CDATA \#REQUIRED\\
indice CDATA \#REQUIRED>\\
En la descripción anterior se puede apreciar que el lenguaje utiliza, por una parte, valores
referentes al formato del gráfico a representar y por otro los valores de las series
numéricas. Esto implica que ha de ser el cliente (el applet) el encargado de transformar
los elementos de las series en las primitivas que compondrán el gráfico resultante. Con
esta técnica es posible reducir tanto el tamaño como el tiempo de ejecución del servidor,
al simplificar la tarea de conversión a XML de las peticiones realizadas contra el servidor.
Por el contrario se complica la tarea de programar los clientes ya que cada applet esta
completamente especializado en un único tipo de gráfico. Esta especialización se debe,
principalmente a la tarea de transformar los elementos de las series de datos en los
componentes de un gráfico completo y coherente.
Por ejemplo, el applet gdXMLsec (a través de la clase circular) es el encargado de
representar los gráficos de sectores, separando los sectores que forman la imagen. Para
poder hacer esto hay que desplazar el centro de la circunferencia que incluye al sector.
La solución implementada en la clase circular es dividir la circunferencia trigonométrica en
ocho zonas de 45 grados cada una y desplazar el centro de cada sector según la zona en
la que esté. Para saber en que zona esta un determinado sector se toma como referencia
su ángulo de comienzo. Según donde este se aplica un desplazamiento al punto que
debería ser el centro. Este desplazamiento debe ser acumulativo, es decir, si dos
sectores se encuentran en la misma zona no podemos aplicar un desplazamiento fijo ya
que esto provocaría que apareciesen pegados en la imagen final presentada en el
navegador. Esta técnica de desplazamientos presenta el problema de saber hacia donde
mover el centro de cada sector que compone el gráfico resultante.
1477
En la primera zona (la que comprende desde los 0º a los 45º) si desplazamos
acumulativamente el centro en el eje X obtendremos que todos los sectores que
comiencen ahí estarán superpuestos, por tanto han de ser desplazados en el eje Y.
Por su parte, el applet gdXMLang es el encargado de representar los gráficos de puntos,
líneas y barras. Para realizar esta tarea se sirve de la clase angular que incluye los
métodos necesarios tanto para interpretar el lenguaje XML, como para dibujar los
elementos que componen estos tres tipos de diagramas de datos.
Figura 1. Solapamiento de sectores por deplazamientos incorrectos
gdXMLang + clase angular
gdXMLsec + clase circular
4.23
4.63
Tabla 1. Tabla de tamaños, en KB.
A pesar de lo reducido de su tamaño (menos de 5KB entre el applet y la clase),
gdXMLang tiene las siguientes características:
•
Permite el cambio del tamaño de la fuente: Así, por ejemplo, el nombre del
grafico puede tener una fuente más grande que el texto que forma la leyenda del
mismo.
•
Ajustar la proporción del eje Y: El método hace una interpretación directa del
alto de la barra, es decir, si el dato a representar es 20 la barra tendría una altura
de 20 píxeles. Esto provocaría que algunos gráficos estuviesen desproporcionados
en la relación alto-ancho. Para evitarlo se aplica un corrector a los datos de
1478
entrada, para que, de esta manera, el eje Y tenga aproximadamente la mitad de la
longitud del eje X.
Como se puede observar, uno de los puntos más importantes de este proyecto es el
tamaño de los applets encargados de la interpretación de los archivos XML. Por eso una
gran parte del esfuerzo en el desarrollo del código ha ido dirigidos a su optimización.
Generalmente reducir el tamaño del cliente implica más trabajo a la hora del desarrollo de
la parte del servidor. También es importante observar que la interpretación por parte de
los applets de los datos de una manera directa complica de una manera bastante
importante su codificación. A esto hay que añadirle el problema implícito de mantener y
gestionar una colección creciente de applets. Otro aspecto muy importante del desarrollo
de la parte cliente es que no usa clases de Java para el manejo de documentos XML. Se
ha optado, como primera fase del desarrollo, por crear las clases angular y circular. Esto
es así ya que cada una de ellas realiza a su vez las funciones de un interprete XML, un
manejador del DOM (Document Object Model) e incluye métodos para la representación.
También cabe reseñar que no es necesario el uso de un DOM en ningún momento.
1.2 Desarrollo de la parte servidora
Como se indicó anteriormente se ha optado por el uso de la tecnología Java Servlet. Se
ha elegido este enfoque debido a que todos los servlets asociados a un servidor se
ejecutan dentro de un proceso simple. De esta manera cada vez que llega una petición al
servidor, la máquina virtual de Java crea un hilo para su manejo, reduciendo de esta
manera la sobrecarga del sistema. A la hora de desarrollar un servidor para este proyecto
ha de hacerse teniendo en cuenta su doble funcionalidad.
Por un lado debe encargarse de procesar los datos, en formato XML, que recibe y por
otra ha de generar el tipo de grafico que se le ha solicitado. Esto es clave a la hora de su
diseño ya que, a pesar de que las tareas de procesado de las peticiones son comunes a
todos los datos que recibe, la parte encargada de construir los gráficos finales varía
según el tipo concreto que ha sido solicitado.
También se ha de tener en cuenta el tiempo final de ejecución del servlet, si este tiempo
es excesivo no se habrá ganado tiempo de respuesta respecto a la transmisión de un
gráfico en un formato como puede ser GIF, JPG, etc. La única ventaja que se habría
1479
aportado sería una reducción en el tráfico de la red ya que, con el esquema de
funcionamiento del sistema basado en applets y servlets, la comunicación entre el
servidor y el cliente es mínima. Por tanto la solución al problema del tiempo de ejecución
del servlet se puede enfocar mediante el uso de una interfaz Java. De esta manera
podríamos dejar en el código propio del servlet los métodos necesarios para el
procesamiento de los documentos XML de las peticiones. Una vez procesados, se
invocaría a una implementación concreta de la interfaz. Cada una de estas
implementaciones sería la encargada de generar un determinado tipo de gráficos. Así, si
el cliente nos envía unas series numéricas y un tipo de gráfico en el que debe de ser
devueltas el servidor invocaría dinámicamente a la interfaz correspondiente. Este enlace
dinámico se logra manteniendo un archivo de configuración para el servlet en el que se
especifiquen todas las correspondencias entre los tipos de los gráficos y la
implementación correspondiente de la interfaz.
Figura2. Ejemplo de ejecución de gdXML.
Como ventaja añadida cabe destacar que, cuando se desee dar soporte un nuevo tipo de
gráfico, no es necesario introducir modificaciones en el código del servlet. La única tarea
necesaria es la de modificar el archivo de configuración para que el servidor sea
consciente del nuevo tipo soportado.
1480
2 SEGUNDA FASE, agML
2.1 Aspectos a mejorar respecto a gdXML.
Una vez que se ha finalizado una versión completamente funcional del sistema podemos
extraer conclusiones sobre su diseño y funcionamiento, de cara a mejorar tanto su
rendimiento como sus funcionalidades. Una de las primeras conclusiones que se puede
extraer es la complejidad de la implementación de los applets. El origen de esta
complejidad se encuentra en el propio lenguaje utilizado para definir los gráficos. Al estar
basado en el uso de etiquetas para elementos de las series numéricas los applets deben
incluir métodos para transformar estos datos en primitivas de dibujado. Para evitar esta
situación se puede optar por redefinir el lenguaje de marcado que se utiliza. A
continuación se expone un subconjunto de la DTD que define a agML. En este lenguaje la
descripción de los gráficos se basa en primitivas de dibujado, como puede ser líneas,
puntos, cajas, etc. Aparte se incluyen etiquetas para la inclusión de series numéricas,
utilizadas en el proceso de petición del gráfico.
<!-- DTD para definir documentos \\XML de graficos de datos
-->\\
<!ELEMENT agML (punto|linea|elipse|serie2d)\*>\\
<!ELEMENT punto (\#PCDATA)>\\
<!ATTLIST punto x1 CDATA \#REQUIRED\\
x2 CDATA \#REQUIRED\\
grosor CDATA \#REQUIRED>\\
<!ELEMENT linea (\#PCDATA)>\\
<!ATTLIST linea x1 CDATA \#REQUIRED\\
x2 CDATA \#REQUIRED\\
x3 CDATA \#REQUIRED\\
x4 CDATA \#REQUIRED>\\
<!ELEMENT elipse (\#PCDATA)>\\
<!ATTLIST elipse c1 CDATA \#REQUIRED\\
c2 CDATA \#REQUIRED\\
radio1 CDATA \#REQUIRED\\
radio2 CDATA \#REQUIRED>\\
<!ATTLIST serie2d valor1 CDATA \#REQUIRED\\
1481
valor2 CDATA \#REQUIRED>\\
2.2 Características de agML
En estos momentos se esta trabajando en agML (abstract graphing Markup Language),
un lenguaje que, al contrario que el actual, esta basado en primitivas gráficas. Para
solucionar el envío de los datos de las series numéricas al servidor se han incluido en el
lenguaje etiquetas para contener series numéricas, dando soporte, en estos momentos, a
dos y tres series numéricas lo que, en un principio, es suficiente para la mayor parte de
los gráficos de datos.
Se puede considerar agML como un lenguaje de dos vías ya que es utilizado de distinta
manera en la comunicación cliente-servidor (petición), que en la servidor-cliente
(respuesta). Durante la petición el cliente enviará al servidor los datos (las series) usando
agML, de esta manera podrá enviar, junto con las etiquetas correspondiente a los datos,
primitivas gráficas que compongan, por ejemplo, un logotipo corporativo. Para lograr
simplificar el diseño de los applets lo que realmente es útil es que las etiquetas de datos
sean procesadas en el servlet y que este solo devuelva (comunicación servidor-cliente)
primitivas gráficas. En este caso se puede volver a hacer uso de las interfaces Java. Se
ha de tener en cuenta que la transformación de los datos en componentes básicos del
gráfico resultante varia mucho según el tipo de diagrama que se haya solicitado.
Esta solución es muy similar a la que ya se encuentra implementada, solo que con mas
funcionalidad. Antes solo se tenia que encargar de añadir los datos de formato
correspondientes al gráfico solicitado, sin embargo ahora a de procesar por completo
todos los datos de las series para generar un documento XML que tan solo contenga las
primitivas gráficas necesarias.
Al añadir esta tarea de transformación del lado servidor se simplifica la parte cliente hasta
el punto de hacer innecesaria su especialización en applets distintos, uno por tipo de
gráfico. Con este nuevo diseño solo se hace necesario un applet que sea capaz de
representar todas las primitivas gráficas soportadas por el lenguaje. Esto se puede lograr
mediante el uso de las API Java 2D, Java 3D o incluso la API Java OpenGL para dar
soporte a primitivas 3D. Es interesante observar que la salida se genera en un formato
XML que solo contiene componentes básicos de dibujado (línea, polígono, arco, etc).
1482
Teniendo esto en cuenta es interesante dotar al servidor de algún mecanismo que le
permita transformar la salida desde agML a otros tipos de representación, como SVG o
VRML. Para lograr esto se esta implementando para el servidor una segunda interfaz,
encargada de transformar la salida agML en otra, como las arriba mencionadas, a
petición del cliente. El mecanismo de uso por parte del servlet de esta segunda interfaz
encargada de la traducción es el mismo que el de la encargada del procesamiento de las
peticiones. Tan solo ha de mantenerse un archivo de configuración para establecer la
correspondencia, en tiempo de ejecución, entre el formato de salida solicitado y la
implementación correspondiente de la interfaz traductora.
Figura 3. Ejemplo de ejecución de gdXML
3 CONCLUSIONES
El sistema implementado permite una independencia de plataforma y gestor de
visualización de elementos gráficos proporcionando un sistema de elección al usuario en
1483
el cual puede decidir el formato de salida del mismo. Esto unido a la utilización de
formatos intermedios de representación de la información gráfica mediante XML hace el
sistema modular y abierto para cualquier ampliación que desde la comunidad científica
pueda precisarse. El objetivo final de construir un sistema abierto utilizable por cualquier
internauta para enviar elementos gráficos a cualquier dispositivo eligiendo el formato de
visualización está cada vez más cerca.
4 REFERENCIAS
[1] http://www.w3c.org, pagina del world wide web consortium.
[2] D. Arnow y G. Weiss, "Introducción a la programación con Java. Un enfoque orientado
a objetos", Addison Wesley, 2000.
[3] J. Rodeiro y G. Pérez, "Internet client graphics generation using XML formats", Lecture
Notes 2330, Springer \& Verlag, 2002.
[4] http://www.adobe.com/svg/main.html, Página principal de Adobe SVG(c),,2002
[5] Benoît Marchal. "XML by example", Ed. Que, 201West 103rd street, Indianapolis,
Indiana 46290, Dic 1999, ISBN 0-7897-2242-9.
5 CORRESPONDENCIA
Javier Rodeiro Iglesias
Departamento de Informática. E.S.E. Informática.
Edificio Politécnico, Campus As Lagoas
Universidad de Vigo
32004 Ourense, España
e-correo: jrodeiro@uvigo.es
Teléfono: 988387020
Fax: 988387001
1484