Download agML: Lenguaje y servidor intermediario modular

agML: Lenguaje y servidor intermediario modular
Perez G.(p), Rodeiro J.
Escuela Superior de Ingeniería Informática Ourense.
SUMMARY
By means of the development of this system, composed of a part client/server and a
language, it is tried to provide a useful tool for the conversion between graphical
formats, as well as for the generation of graphs of data in distributed enviroments.
For the development of the language agML (abstract graphing Markup Language)
has been used XML. This allows to equip it with an intrinsic capacity to be used in
multiple platforms.
This language allows us to define simple primitive graphs (bidimensional as much
three-dimensional), as well as to transmit numerical series. The inclusion of the
numerical series must to the given direction to the system so that also it is possible
the generation of graphs of data. As far as the software part of the architecture agML,
has been decided on the use of the Java technology for its implementation. More
concretely Java Servlets the modular server and Java Applet for the native client.
The denomination native client is specified because it is possible to ask for requests
to the server that they use, an example would be the client for the platform VRML
that already is implemented, any other type of client, platform and/or format of
graphical storage.
RESUMEN
Mediante el desarrollo de este sistema, compuesto de una parte cliente/servidor y un
lenguaje, se pretende proporcionar una herramienta útil para la conversión entre
formatos gráficos, así como para la generación de gráficos de datos en un entorno
distribuido. Para el desarrollo del lenguaje agML (abstract graphing Markup
Language) se ha empleado XML. Esto permite dotarlo de una capacidad intrínseca
para ser empleado en múltiples plataformas.
Este lenguaje nos permite definir primitivas gráficas sencillas (tanto bidimensionales
como tridimensionales), así como transmitir series numéricas. La inclusión de las
series numéricas se debe a la orientación dada al sistema para que también sea
posible la generación de gráficos de datos. En cuanto a la parte software de la
arquitectura agML, se ha optado por el empleo de la tecnología Java para su
implementación. Más concretamente Java Servlets para el servidor modular y Java
Applet para el cliente nativo.
La denominación cliente nativo se especifica debido a que es posible solicitar
peticiones al servidor que empleen, un ejemplo sería el cliente para la plataforma
611
VRML que ya se encuentra implementado, cualquier otro tipo de cliente, plataforma
y/o formato de almacenamiento gráfico.
1. INTRODUCCION.
1.2 Objetivos.
Mediante este sistema se pretende crear un sistema que permita agilizar la
comunicación entre distintas computadoras a la hora de intercambiar ficheros
gráficos, concretamente los basados en series numéricas.
Para ello han de definirse:
•
Un lenguaje de descripción gráfica.
•
Un servidor.
•
Un cliente.
•
Módulos para la implementación de los formatos de salida y los tipos de
gráficos de datos que se desee soporte el sistema.
1.3 Descripción Técnica.
Se hará uso de un lenguaje de descripción de primitivas para la definición de los
gráficos. Este lenguaje será definido mediante el uso de una DTD (Data Type
Definition, definición de tipo de datos) de XML. Gracias a lo cual podremos
aprovechar las ventajas que nos proporciona un lenguaje de este tipo.
Esto se debe, principalmente, a la gran aceptación que tienen en estos momentos
los lenguajes de marcado enfocados al almacenamiento (de una forma estructurada)
de información.
Para desarrollarlo de manera práctica se va a utilizar tecnología Java,
concretamente Java Applet y Java Servlet debido a su portabilidad, y a la facilidad
para crear aplicaciones cliente/servidor.
Una vez realizado el estudio de las series numéricas y la descomposición de los
gráficos en representaciones basadas en lenguajes de marcas se han implementado
en Java, utilizando Applets y Servlets.
Es muy importante el hecho de que no es necesario el envío de este archivo al
emisor de la petición. El documento XML permanecerá almacenado en el servidor
para que el cliente, a través de un navegador apropiado, pueda visualizarlo.
También hay que destacar que el applet Java es solo uno de los posibles métodos
de visualización. Dada la arquitectura modular del sistema es posible obtener la
salida en otro tipo de formato, que no sea el nativo, como por ejemplo VRML,
SVG,…
2. ARQUITECTURA DEL SISTEMA.
612
Una vez que se han planteado los objetivos de este proyecto, es importante
presentar la arquitectura que se pretende posea el sistema.
2.1 Definición y comportamiento de la arquitectura.
Durante la petición el cliente enviará al servidor los datos (las series) usando agML,
ya que de esta manera podrá enviar, junto con las etiquetas correspondientes a los
datos, primitivas gráficas que compongan, por ejemplo, un logotipo corporativo.
Para lograr simplificar el diseño de la parte cliente (es decir, la parte encargada de
representar el gráfico final, procesado por el servidor) algo especialmente útil es el
hecho de que las etiquetas de datos sean procesadas en el servidor del sistema, y
que este solo devuelva (mediante la comunicación servidor-cliente) primitivas
gráficas.
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 (gráficos de
barras, puntos, sectores,...) que se haya solicitado.
Diagrama de la arquitectura del sistema agML.
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 clientes distintos, esto es,
uno por cada tipo de gráfico. Con este diseño solo se hace necesario un cliente
genérico que sea capaz de representar todas las primitivas gráficas soportadas por
el lenguaje.
Es importante observar que el proceso inicial de procesado genera un archivo de
primitivas intermedias en formato agML que solo contiene componentes básicos de
dibujado (linea, polígono, arco, etc).
613
Teniendo esto en cuenta es interesante dotar al servidor de mecanismos que le
permitan transformar la salida desde agML a otros tipos de representación, como
SVG o VRML.
Para lograr esto, se debe dotar al servidor de una 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 servidor de esta segunda interfaz, encargada de
la traducción, ha de ser el mismo que el encargado del procesamiento de las
peticiones en cuanto a la generación del gráfico.
2.2 Implicaciones para los gráficos de datos.
El primer punto importante que ha de incorporar cualquier sistema, es el referente a
la entrada de la información.
Ya se ha explicado que se pretende que agML sea, además de un lenguaje gráfico,
un lenguaje de generación de gráficos de datos. Por tanto es clave, para el
desarrollo de este proyecto, el modo en que el servidor reciba los datos que no se
correspondan con primitivas gráficas. Es decir, las series numéricas que han de ser
representadas mediante el gráfico de datos deseado.
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, a
series numéricas de dos y tres dimensiones, lo que, en un principio, es suficiente
para la mayor parte de los gráficos de datos.
Es por esto, que 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).
3. MODULARIDAD Y EXTENSIBILIDAD DE AGML.
Como ya se ha expuesto en esta documentación, uno de los principales objetivos de
este proyecto es conseguir que el sistema final tenga las siguientes características:
•
Facilidad de ampliación.
•
Gran adaptabilidad.
Aunque ambas se refieren a aspectos distintos del sistema, están muy
interrelacionadas. Así, una aplicación muy adaptable será, probablemente, más fácil
de ampliar que una rígida. En el caso opuesto, en un sistema fácil de ampliar, la
tarea de adaptarlo a los nuevos requerimientos que puedan surgir, es una tarea más
sencilla.
En este capítulo se detallan las distintas vías, aplicadas en el desarrollo de este
sistema, que permiten dotarlo de ambas características.
614
Es importante, sin embargo, recordar a que partes del sistema se le aplica el
enfoque modular:
Procesamiento de la entrada: Se encarga de interpretar el documento agML
inicial, en el formato de salida. En el caso de que el formato de salida también sea
agML el procesamiento se centra en la generación de gráficos de datos.
Generar la salida: Cada modulo implementa la manera de crear el entorno
necesario para presentar el gráfico en la plataforma de destino.
3.1 Modularidad.
Desde un principio, ya en el momento de definir la arquitectura agML, se consideró
la modularidad como indispensable.
Se pretendía construir una arquitectura que sirviese de paso entre diversos formatos
de salida gráfica. De igual manera, era deseable que también diese soporte a las
distintas plataformas que puedan servir como soporte para dichos gráficos.
3.2 ¿Qué aporta la modularidad?.
A continuación se expondrán las ventajas que se obtiene al aplicar dicho enfoque a
nuestro sistema.
•
Servidor genérico: Al extraer las funcionalidades hacia los módulos
conseguimos obtener un servidor mucho más ligero. Así mismo podemos
centrarlo sólo en tareas de alto nivel, como pueden ser gestión de la petición,
gestión de la salida,… Gracias a esto, el servidor no tiene que incluir las
funcionalidades, necesarias para trabajar con todos los tipos de gráficos que
soporte, que mediante este enfoque se encuentran en los módulos. Por
contra, ha de añadírsele la gestión y carga de dichos componentes.
•
Facilidad de ampliación: El proceso de integrar el soporte para un nuevo
formato es más rápido y sencillo. Es así ya que lo único que se debe hacer
es crear un módulo que maneje dicho formato y, por otra parte configurar el
sistema para que pueda hacer uso de el.
Para la configuración de estos módulos se emplean archivos XML. Esto permite
enlazar las tareas de los módulos de procesamiento gráfico con la de los módulos de
generación de la salida específica de una plataforma.
3.3 Extensibilidad.
Íntimamente relacionado con la modularidad podemos encontrar la extensibilidad. En
el caso de agML, la extensibilidad se logra, en parte a través de la modularidad.
En otra gran parta se logra gracias al empleo de XML como base para la gestión de
todos los aspectos del sistema. Básicamente, el uso de XML para dichas tareas nos
permite cambiar o ampliar (extender) las capacidades del sistema sin tener que
cambiar la implementación del diseño del sistema.
615
Para ello el sistema debe ser capaz de interpretar dicha información, referente a los
siguientes aspectos:
Configuración del servidor.
Gestión y configuración de los módulos.
Componer los estilos aplicables a los formatos de salida.
Definición de gráficos. Esta es la parte central, definir un lenguaje (agML)
mediante XML.
BIBLIOGRAFIA.
Jan Christian Herlitz, DrawML and SVG, Proceedings of the First XML Europe
conference (XML Europe 99), 1999, pp 61-70.
Mark Roberts, Graphic Element Markup, Proceedings of the First XML Europe
conference (XML Europe 99), 1999, pp 547—557.
Benoît Marchal, XML by example, Que 201West 103rd street Indianapolis Indiana
46290, Dic 1999, ISBN 0-7897-2242-9.
Javier Rodeiro, Gabriel Pérez, Generación de gráficos en arquitecturas clienteservidor mediante XML, Proceedings del XI Congreso Español de Informática
Gráfica, 2001.
CORRESPONDENCIA.
Javier Rodeiro Iglesias
Departamento de Informática. ESII. Edificio Politécnico.
Campus As Lagoas S/N. 32004. Ourense
Universidade de Vigo
Tlf: 988 387 020
Fax: 988 387 001.
e-mail: jrodeiro@uvigo.es
616