Web Trading​

En el desarrollo del sistema SOLERES hemos comenzado centrándonos en la implementación del Agente Web Trading. El primer paso ha sido crear una aplicación de ejemplo que ofrezca la posibilidad de probar el proceso de comunicación entre el agente trader y un usuario que interactúe con nuestro sistema.

Este subsistema de aplicación sigue el modelo "Consulta-Búsqueda-Recuperación-Respuesta" y tiene dos roles principales: el servidor y el cliente. El primer papel representa el componente de mediación del sistema y estará pendiente de la recepción de los mensajes de consulta enviados por el cliente; el segundo se refiere a los usuarios que interactúan con nuestro sistema. A continuación, mostramos algunos detalles de implementación de la arquitectura de la aplicación de ejemplo, haciendo hincapié en el agente de Web Trading y el agente de interfaz de usuario.

Contenido​

1. Arquitectura base
   1.1. Diagrama de clases
   1.2. Proceso de inicialización
2. Comunicación
   2.1. Proceso de comunicación
   2.2. Ontología de la comunicación
3. Representación de datos
   3.1. Ontología de datos
   3.2. Consulta de datos
4. Trader (Servidor)
   4.1. Comportamiento del agente trader
   4.2. Detalles de implementación del trader
5. Usuario (Cliente)
   5.1. Interfaz de usuario
   5.2. Comportamiento del Agente de Interfaz
   5.3. Detalles de la implementación

Arquitectura base​

Diagrama de clases​

Los roles cliente y servidor se han desarrollado como objetos agentes. El cliente se denomina "AppletApgentQI" y el agente servidor es la clase "TraderAgent". El primero se crea a partir de la clase "ClientContainer" y el segundo a partir de "ServerContainer". Ambas clases son subclases de la clase "AgentContainer" (tipo de la plataforma JADE) y son creadas por las clases lanzadoras "QIApplet" y "Trader" respectivamente.

Además de estas clases, en el ejemplo salen el "SPARQLParser" (interfaz traductor de consultas al lenguaje SPARQL del agente), el interfaz "Lookup" (que representa uno de los interfaces que debe implementar el trader) y el EID (un repositorio OWL que contiene la información de metadatos).

Proceso de inicialización​

Para la ejecución del ejemplo implementado es necesario seguir los siguientes pasos. En primer lugar, debemos ejecutar el proceso de servidor en el equipo que contiene el servicio de alojamiento. Este proceso creará el agente en un contenedor de agentes de la plataforma JADE y el agente ("TraderAgent") inicializará su comportamiento que comienza a esperar subcomportamiento de respuesta para los mensajes de consulta.

Por otro lado, cada usuario cliente accederá a nuestra aplicación a través de una página web. Esta página web inicializará un applet que representa la interfaz de usuario. El applet es el responsable de la creación del agente de interfaz y, a continuación, este agente añadirá su comportamiento que comienza a esperar la confirmación de envío de la consulta.

Una vez que hemos lanzado ambos procesos, ambos agentes se crean viviendo en una plataforma JADE y contenidos en un contenedor independiente. Esta característica permite probar la comunicación entre usuarios que ejecutan la aplicación en distintos lugares, enviando y recibiendo mensajes desde contenedores autónomos y desde la Plataforma JADE.

Comunicación​

Proceso de comunicación​

El proceso de comunicación de consulta del agente de comercio web, desde que el usuario cliente o el grupo de usuarios cliente establecen la consulta en la interfaz de usuario hasta que se muestran los resultados, es realizado por dos agentes principales, un agente de interfaz ("AppletQIAgent") y un agente de mediación ("TradeAgent") que utilizan la ontología Lookup para establecer la comunica

Ontología de la comunicación​

Para la implementación de la ontología de comunicación (Lookup), hemos hecho uso del formato XML, de forma que el cliente rellena los campos necesarios con la información correspondiente antes de enviar el mensaje. El servidor (trader) recibirá el fichero de contenido XML y extraerá los datos de los campos que necesite. Estas operaciones han sido posibles haciendo uso de las librerías Jdom, Saxon y otras librerías XML.

Está disponible el fichero lookup.xml y también la clase ontológica (Lookup_ontology.java) utilizada para el correcto rellenado y recuperación de la información.

Representación de datos​

Recordemos que el sistema SOLERES mantiene (en su conjunto) la información ambiental distribuida en diferentes repositorios OWL de dos niveles; unos que contienen metadatos ambientales (repositorios EIM) y otros que contienen metadatos de los primeros (repositorios EID). El comerciante gestiona un repositorio EID.

Ontología de datos​

La siguiente imagen muestra una ontología de datos de un repositorio EID. Recordemos que el dominio de aplicación que se va a modelizar aquí es el de la información ecológica (un tipo de información medioambiental): mapas cartográficos e imágenes de satélite. Está previsto que el sistema SOLERES incluya algoritmos avanzados basados en redes neuronales para encontrar una correlación entre la información por satélite y la información cartográfica. Estos algoritmos están siendo desarrollados por miembros del equipo de trabajo de SOLERES.

Para el cálculo de esta correlación, es necesario un tratamiento previo de las imágenes de satélite y mapas cartográficos (una clasificación de imágenes, Clasification). Un mapa cartográfico almacena su información en capas (Layer), cada una de las cuales está identificada por un conjunto de variables (Variable). Por ejemplo, en nuestro proyecto utilizamos mapas cartográficos clasificados en 4 capas (climatología, litología, geomorfología y suelos) con más de un centenar de variables (superficie de matorral, superficie de pastos, pluviometría media, entre otras). Algo similar ocurre con las imágenes de satélite. La información también se almacena en capas, pero aquí se denominan bandas. Un ejemplo de imagen de satélite son las imágenes LAND-SAT, que tienen 7 bandas (y ninguna variable almacenada aquí). Finalmente, tanto la clasificación cartográfica como la satelital tienen asociada información geográfica y ésta (Clasificación) es realizada en un momento dado (Tiempo) por un técnico o grupo de técnicos (Técnico). Como complemento y formalización para los gráficos y el metamodelo, la siguiente tabla muestra las aserciones completas de las ocho entidades de las ontologías.

El fichero OWL que representa la ontología de datos está disponible en el siguiente enlace: eid.owl

Consulta de datos​

Para la extracción de la información del documento OWL que representa la ontología de datos, hacemos uso de la librería AgentOWL desarrollada por Michal Laclavik (http://agentowl.sourceforge.net/). En la inicialización del agente trader, debemos crear un nuevo puerto de servidor para la comunicación y especificar el nombre del fichero de configuración para la creación del modelo que representa los datos contenidos en el fichero OWL.

Una vez que el agente trader recibe la consulta y quiere ejecutarla al fichero OWL, debe recuperar su modelo y utilizar las clases "Query", "QueryExecution", "QuerySolution" y "ResulSet" para obtener la información deseada como podemos ver en el siguiente código:

Trader (Servidor)​

Comportamiento del agente trader​

La tarea principal del agente trader es responder a los mensajes del usuario. Se ha dividido en cuatro subtareas correspondientes a cuatro subcomportamientos que hemos implementado para el agente. La siguiente imagen muestra un diagrama de máquina de estados finitos que representa las transiciones de comportamiento.

Para la implementación del comportamiento del agente trader, utilizamos la clase JADE denominada "FSMBehaviour". Esta clase implementa un comportamiento compuesto que programa a sus hijos según una máquina de estados finitos (FSM). La clase "FSMBehaviour" proporciona métodos para registrar subcomportamientos como estados FSM y para registrar transiciones entre estados.El comportamiento completo finaliza cuando se alcanza un estado de terminación y se ejecuta por completo. El comportamiento del agente trader se describe en el siguiente código:

Detalles de implementación del trader​

Atendiendo al diagrama de clases, la clase Trader es el lanzador del servidor, el TraderAgent es el agente creado por el servidor y es el que responde a las consultas de los clientes. La tarea de respuesta se resuelve mediante el comportamiento del agente que se implementa en la clase TraderAgentBehaviourFSM. El código de esta clase está disponible en los siguientes enlaces:

• Trader.java
• TraderAgent.java
• TraderAgentBehaviourFSM.java

Para explicar los subcomportamientos ofrecemos el código de la clase para cada uno de ellos:

• TraderAgentBehaviourFSM_WaitingBehaviour.java
• TraderAgentBehaviourFSM_ObtainBehaviour.java
• TraderAgentBehaviourFSM_ExecuteBehaviour.java
• TraderAgentBehaviourFSM_SendBehaviour.java

Usuario (Cliente)​

Interfaz de usuario​

La imagen muestra la ventana de la interfaz de usuario de la consulta. Hemos optado por un árbol de consulta ("Tree Model") para mostrar los datos que podemos consultar, así como a los elementos que acabamos de añadir a la consulta actual ("QueryTree").

Podemos realizar consultas de dos formas: manual o supervisada. El modo manual permite al usuario escribir directamente la consulta en la sección de consulta. La supervisión permite construir la consulta seleccionando las variables, variables y operadores en la interfaz.

Comportamiento del Agente de Interfaz​

El agente interfaz tiene la tarea de recuperar la consulta de la interfaz de usuario y enviarla al agente que puede resolverla. Posteriormente, el agente obtendrá el resultado de la consulta y se lo mostrará al usuario. Este complejo comportamiento se divide en siete subcomportamientos como se muestra en la siguiente figura:

Como hemos explicado en la sección Comportamiento del agente trader, para la implementación del comportamiento del agente interfaz, utilizamos la clase JADE llamada "FSMBehaviour". A continuación podemos ver el código de la clase behaviour:

Detalles de la implementación​

Tal y como muestra el diagrama de clases, QIApplet es el lanzador del cliente, el AppletAgentQI es el agente creado por el cliente y es el gestor de información del entorno ask. La tarea de qurey se resuelve mediante el comportamiento del agente que se implementa en la clase AppletAgentQIBehaviourFSM. El código de estas clases está disponible en los siguientes enlaces:

• QIApplet.java
• AppletAgentQI.java
• AppletAgentQIBehaviourFSM.java