MECANISMOS DE COMUNICACIÓN Y GESTION DE SERVICIO DE UN BROKER DE INFORMACION MULTIAGENTE Francisco Valera 1, Jose Ignacio Moreno 1, Víctor A. Villagrá 2, Julio Berrocal 2 1 Area de Ingeniería Telemática, Universidad Carlos III de Madrid Avda. de la Universidad 30, 28911 Leganés (MADRID) Email:
[email protected],
[email protected] 2 Departamento de Ingeniería Telemática, Universidad Politécnica de Madrid Ciudad Universitaria s/n, 28040 MADRID Email:
[email protected],
[email protected] Resumen En este artículo, se presenta el entorno de un servicio de intermediación electrónico basado en tecnología de agentes. La primera parte introduce el concepto de intermediación y posteriormente se detalla la arquitectura del servicio, con objeto de entender globalmente el funcionamiento del sistema. Por último, se detalla el entorno de comunicaciones tanto internas (inter-dominio) como externas, así como algunos problemas detectados junto con las correspondientes soluciones adoptadas. Además se presenta el sistema de gestión que se ha adoptado para este servicio de intermediación, nuevamente desde el punto de vista arquitectural y funcional. Las principales conclusiones se han extraído de los proyectos de investigación ACTS ABROSE (AC 316) y ACTS ABS (AC 206).
1. Introducción El Comercio Electrónico está principalmente basado en un intercambio de información eficiente y preciso entre las diferentes entidades implicadas en la transacción (típicamente cliente y proveedor), usando la infraestructura de comunicaciones existente. Gracias a las facilidades de comunicación proporcionadas por Internet y las redes intranet en general, la cantidad de información disponible es muy grande y además, se va incrementando continuamente (de manera análoga, también es habitual el aumento de la cantidad de información demandada). Así, es necesario algún tipo de funcionalidad o mecanismo que permita a los clientes y a los servidores intercambiar información de manera fluida y precisa, tratando de minimizar el tiempo que normalmente se emplea en encontrar información verdaderamente útil y que suele ser bastante alto. 1.1. Servicio de Brokerage El servicio de brokerage (implementado por un broker de información), en el contexto del comercio electrónico, constituye una herramienta que ayuda tremendamente a potenciar la simetría de la tarea de intermediación, permitiendo que ambas partes se comuniquen de forma sencilla. Evidentemente el mayor problema con el que se enfrenta, es la búsqueda y posterior entrega de la información, específicamente requerida por los usuarios. Dicho servicio de brokerage, de manera genérica, suele habilitar al usuario, la navegación a través de una clasificación o índice por contenidos, por el que puede ir buscando hasta que encuentra lo que necesite. Entonces se le provee de un conjunto de información con el formato atributo/valor, hasta que finalmente localiza los datos deseados. Hay, sin embargo, aproximaciones más flexibles y transparentes basadas en el uso de recomendaciones personales (perfiles de usuario), que no obligan a tener que realizar la mencionada navega-
ción, que en ocasiones, también puede llegar a ser un poco tediosa [1] y [2]. Concretamente vamos a distinguir dos tipos de sistemas: • El primer modelo, utiliza un esquema de peticiones basado en una aproximación del lenguaje natural, de cara a que los usuarios puedan seleccionar la información que desean de una manera mucho más cómoda. Los usuarios pueden ir mejorando sus perfiles continuamente, basándose en las evaluaciones que ellos mismos hacen de la información recibida. Así, el mecanismo de búsqueda va refinándose progresivamente. • La segunda opción, consiste en utilizar filtros sintácticos colaborativos. La idea básica, es la de crear conjuntos de conocimientos comunes, de manera que los usuarios puedan obtener conocimientos unos de otros y aprovecharse mútuamente del proceso de refinamiento del mecanismo de aprendizaje anteriormente mencionado.
Figura 1. Plataforma de intermediación en el marco del comercio electrónico.
1.2. Intermediación Un servicio de brokerage del estilo del que acabamos de introducir, estaría considerado como parte integrante de lo que se denomina, plataforma de intermediación [3]. Dicha plataforma, trata de englobar el conjunto de tareas que, se supone deben regir toda transacción que tenga la forma de la del comercio electrónico. En la Fig. 1, podemos ver esbozadas las distintas tareas que constituyen la plataforma: intermediación (brokerage), seguridad, distribución, contabilidad, facturación y conectividad. Todas ellas, como ya se ha dicho, están orientadas a disminuir las distancias entre la oferta y la demanda desde el punto de vista comercial. 1.3. ABROSE * Centrados en el marco fijado por este entorno, lo que introduce este artículo, es precisamente, un Servicio de Intermediación Electrónica basado en tecnología de agentes, implementado utilizando Java (JDK1.1.7) y CORBA (OrbixWeb3.0) e incorporando un completo sistema de gestión. El servicio se desarrolla en el proyecto ABROSE (AC 316), dentro del programa ACTS la Comisión Europea. ABROSE, formalmente especificado utilizando UML (con Rational™ Rose98™), hace un especial énfasis en la tarea de brokerage, incluyendo los dos enfoques anteriormente citados (navegación y colaboración). *
En el proyecto ACTS ABROSE (AC 316), participan: DT-Berkom, FT-CNET, Univ. of Toulouse, Univ. of Athens, Univ. of Berlin, Infomures from Romania, Onyx Ltd England, Dégriftour sa France, Univ. Politécnica de Madrid, Univ. Carlos III de Madrid
2. ABROSE 2.1 Objetivos Los principales objetivos que se plantean en ABROSE (Agent Based Brokerage Services in Electronic Commerce) son: • Captura dinámica de conocimientos. • Incorporación de un sistema multiagente para la representación de la base de conocimientos. • Interfaz gráfica para la navegación y petición de resultados (apoyada también en la tecnología de agentes). • Interfaz gráfica y apoyo de agentes en el registro y propagación de ofertas por parte del proveedor. • Utilización de Java y CORBA como lenguajes de implementación del sistema. • Utilización de agentes colaborativos para optimizar la tarea de intermediación. • Evaluar la incidencia de la tecnología de agentes en el dominio de los brokers de información y de aplicaciones comerciales en general. • Aplicación de Java, CORBA y SNMP para la implementación de la plataforma de gestión del servicio utilizando también Tcl-Tk. 2.2 Funcionalidad Desde el punto de vista funcional, el sistema ABROSE, es un servicio de brokerage accesible por Internet, que trata de cubrir las necesidades planteadas en los apartados iniciales, abordando los diferentes objetivos tecnológicos expuestos anteriormente. El usuario accederá al sistema a través de un navegador de Web, pudiendo darse de alta o iniciar una sesión (con la consiguiente fase de acceso). Una vez dentro del servicio, dispondrá de una interfaz gráfica, por medio de la cual podrá realizar peticiones al broker o navegar por la base de conocimientos del mismo (ver Fig. 2).
Figura 2. Interfaz gráfica de peticiones.
Frente a una posible opción de implementación en la que el broker sería el encargado de consultar a los distintos proveedores y devolver las respuestas, que serían directamente presentadas en el navegador [4], en ABROSE lo que se hace es una búsqueda exhaustiva de proveedores afines a la petición y es el mismo usuario el que debe realizar el acceso.
La tecnología de agentes permitirá que el broker vaya aprendiendo de manera transparente las preferencias del usuario, aumentando la precisión a la hora de configurar la lista de proveedores afines, que hemos comentado. La Fig. 2 ofrece el aspecto de una de las interfaces gráficas del sistema ABROSE (concretamente, se trata de la interfaz que permite al cliente realizar peticiones al broker). El menú ‘Mode’ permitiría seleccionar, en función de que el sistema lo esté utilizando un usuario o un proveedor, si lo que se quiere hacer es una oferta o una petición. La descripción de dicha petición se escribiría en lenguaje natural en los campos de texto de la izquierda de la interfaz. A la derecha aparecerían los proveedores que ofrece el broker como respuesta (o los usuarios interesados en la oferta si el cliente del sistema es un proveedor). 2.3 Arquitectura La arquitectura del sistema está basada en dos dominios bien diferenciados: el dominio del broker, que tiene la doble misión de brokerage y gestión del sistema y el dominio del usuario, que asume toda la funcionalidad de visualización de información hacia el usuario final (navegación, peticiones, resultados, etc.). La Fig. 3 muestra un esquema de la arquitectura con los diferentes bloques y el flujo de información existente entre ellos. Por cuestiones de simplicidad, se han omitido algunos puntos referentes a comunicaciones y gestión, que posteriormente se comentarán en detalle. En lo que resta de apartado, se hará mención a los distintos módulos que constituyen el sistema, haciendo una división por dominios. Dicha descripción posibilitará una comprensión mucho más precisa del funcionamiento del sistema. Dominio del usuario
Dominio del usuario
(CLIENTE)
Dominio del Broker
UAM
CA
CA Spy
Spy AMA NA Terminal Cliente
(PROVEEDOR)
TA
TA
...
TA
AMA NA
MA
Terminal CP
BM
FE Terminal del Operador
OT Figura 3. Esquema arquitectural del sistema ABROSE
Dominio del Usuario • Asistente de Conexión (CA): es el bloque que ayuda al usuario a registrarse y conectarse al sistema. • Asistente de Gestión de Agentes (AMA): coordina las comunicaciones entre los diferentes módulos del dominio del usuario, así como la comunicación con el dominio del broker. • Asistente de navegación (NA): permite que el usuario (proveedor de contenidos o cliente) navegue por el espacio de conocimientos del broker y seleccione los dominios y criterios relevantes para sus peticiones. • Espía (Spy): se encarga de obtener información de las diferentes peticiones que haga el usuario, con el objetivo de mejorar el conocimiento del usuario que tiene el broker (perfil del usuario), lo cual irá facilitando progresivamente el proceso de adquisición de información precisa.
•
Front End (FE): es el punto de acceso a la información que posee el proveedor. El usuario obtendrá una referencia para conectarse al FE como respuesta a sus peticiones.
Dominio del Broker • Gestor de Acceso del Usuario (UAM): la función principal de este bloque es la de mantener los perfiles de los usuarios y verificar el acceso a ABROSE. El perfil del usuario, tendrá por lo tanto, la información necesaria para permitir el acceso del usuario (login y contraseña), como mínimo. Se creará al iniciarse el sistema y deberá ser mantenido mientras se mantenga el servicio. • Gestor del Broker (BM): monitoriza la interacción entre los diferentes módulos del sistema. Se encarga además del arranque del sistema (su labor se explicará más profundamente en el apartado de gestión). • Terminal del Operador (OT): ayuda al operador del sistema a realizar la gestión y administración del servicio que provee ABROSE. Muestra el estado de cada bloque, facilitando el acceso a los parámetros de gestión que tenga cada uno. • Sistema Multi-Agente (MAS): en el dominio del broker, los agentes representan tanto a los clientes como a los proveedores. Cada agente va asociado a un módulo TA (agente de transacción), estando todos los TAs agrupados por conocimientos y controlados por el módulo MA (agente de mediación). El conocimiento del sistema estará basado en una red de conocimientos (BN), formada por el conocimiento de todos estos agentes internos. Cada vez que se hace una petición, basada en conocimiento específico del MA y/o del TA, se localizará a los correspondientes agentes del proveedor. El caso simétrico también es posible, cuando un proveedor hace una oferta y se localizan los correspondientes agentes de usuario. La arquitectura de los bloques que constituyen el MAS, se analiza con un poco más de detalle en el siguiente subapartado. MAS (Multi-Agent System) Se trata de una arquitectura en tres niveles, estando formado cada nivel por agentes que se comunican entre sí, marcados por el mismo patrón. Así, un agente de un determinado nivel, estará formado por agentes cooperativos en un nivel inferior (ver Fig. 4): • Agente de mediación (MA), nivel superior: controlan el ciclo de vida de cada TA y encapsulan todo el conocimiento por ellos adquirido. El MA deberá controlar la creación de TAs asociados a nuevos usuarios, así como eliminar los TAs pertenecientes a clientes dados de baja. El MA puede añadirse o eliminarse del sistema, en función de la necesidad o no de un conocimiento global (BN global). Además, el MA va aprendiendo progresivamente de las transacciones que se hacen en el sistema. • Agente de transacción (TA), nivel medio: representan al usuario en el dominio del broker, almacenando conocimiento sobre él y tratando de conseguir información de otros TAs. Por eso, cada TA contendrá y mantendrá dos redes de conocimiento, una que contiene conocimientos sobre el propio usuario y otra con conocimiento del resto de TAs. El TA es el punto de entrada al dominio del broker, coordinando las comunicaciones entre dicho dominio y el usuario al que están asociados. MA
A BN
TA 1
TA 2
TA n
A1 BN
A2 BN
n BN
Figura 4. Esquema arquitectural del MAS.
•
Agentes de conocimiento, nivel inferior: tanto MAs como TAs, contienen información sobre sí mismos y sobre otros agentes situados en su mismo nivel. Esta información es la que organiza la sociedad de agentes. Los BAs son términos unidos a otros términos mediante enlaces con un determinado peso de unión. El BA de un TA o un MA constituye la BN (Belief Network) del agente, su base de conocimientos. Dicha BN está actualizándose continuamente para adaptarse a los conocimientos adquiridos durante las diferentes peticiones (además la BN del MA será un agregado de las diferentes BN de los TAs).
3. Comunicaciones en ABROSE Este apartado explica la arquitectura e implementación de las comunicaciones en ABROSE, presentando dos nuevos módulos UCOMMS y BCOMMS que constituyen la base de dicha arquitectura, pues son los responsables de poner en contacto al cliente y al servidor (ver Fig. 5). A lo largo del apartado se irá presentando progresivamente la arquitectura de comunicaciones en el dominio del usuario, en el del broker y entre ambos dominios.
Figura 5. Esquema de comunicaciones en ABROSE.
3.1 Dominio del usuario En términos generales, consistirá en un browser (Netscape) cuya máquina virtual ejecutará los diferentes módulos (CA, AMA, ...) que serán obtenidos del servidor de web mediante HTTP. Lo primero en ejecutarse, es un applet (lanzado desde la página web de acceso a ABROSE). Posteriormente se cargan el resto de los módulos en ventanas independientes, si es que incorporan una interfaz gráfica (como el CA o el AMA) o en threads independientes si no es así (UCOMMS). Para comunicarse entre sí, todos estos módulos usan sus respectivas referencias de objetos Java, por lo que lo único necesario para habilitar las comunicaciones es un método que permita intercambiar dichas referencias. Una vez que se conoce la referencia del objeto destino, la comunicación entre dos módulos es tan sencilla como ejecutar el método deseado en el objeto en cuestión. El módulo UCOMMS, responsable de comunicar el dominio del usuario con el dominio del broker, según se explicará en el apartado 3.3, se comunica con el resto de los bloques del dominio, haciendo uso también de las referencias de objetos Java. 3.2 Dominio del broker Las comunicaciones se hacen en los mismos términos que en el dominio del usuario. Cada módulo se implementa con un thread independiente (BM, UAM, BCOMMS, MA ...), aunque en este caso no se usa ninguna interfaz gráfica.
Inicialmente se lanza el BM, que es el módulo responsable de inicializar el resto de los módulos y de repartir las referencias de unos y otros. Como se ha mencionado, las comunicaciones se harán utilizando dichas referencias para ejecutar los correspondientes métodos. El módulo BCOMMS, hace el papel simétrico del UCOMMS en el dominio del broker. Es decir, será el encargado de unir el dominio del broker con el dominio del usuario. Las comunicaciones con el resto de los módulos del broker, se hacen igualmente utilizando la referencia Java. 3.3 Comunicaciones cliente-servidor (inter-dominio) Las comunicaciones entre ambos dominios se han implementado utilizando CORBA. Como se puede ver en la Fig. 5, se ha optado por un enfoque centralizado, con dos módulos (uno por dominio), responsables de enviar y recibir datos del otro dominio. De esta forma UCOMMS y BCOMMS son los dos únicos módulos que hablan CORBA entre sí. Cuando el usuario necesite enviar alguna petición al broker, se invocará un método en el UCOMMS y este módulo se encargará de comunicar con el BCOMMS, que a su vez entregará la petición al módulo adecuado dentro del dominio del broker. 3.4 Comparativa Otra posibilidad, consistiría en que cada módulo fuese responsable de sus comunicaciones con el resto de los módulos [5]. Cada módulo del dominio del broker constituiría un objeto CORBA y cada módulo del cliente accedería por su cuenta al módulo del broker correspondiente. Además los módulos del broker se comunicarían entre sí utilizando llamadas CORBA, en vez de las llamadas a través de referencias Java que es como se hace en nuestro caso. Con el esquema utilizado en ABROSE, los únicos módulos que tienen que utilizar CORBA, como ya se ha dicho, son UCOMMS y BCOMMS, por lo que las comunicaciones se pueden gestionar de una manera mucho más sencilla. El resto de los módulos se desvincula por completo de la complejidad que implica el entorno de comunicaciones (conexiones, recepción y envío de datos, control de errores, etc.) y sólo precisarán una invocación Java en el UCOMMS o BCOMMS para acceder al otro dominio. Otra ventaja de este modelo, es que todos los módulos del broker se ejecutan sobre la misma máquina virtual, con lo que la invocación de un método sobre una referencia Java es prácticamente inmediata. El otro esquema comentado, sin embargo, también tiene sus ventajas. El hecho de que prácticamente todos los módulos (salvo los del dominio del usuario entre sí) se comuniquen utilizando CORBA, exige definir previamente las correspondientes interfaces en IDL, quedando especificado ya desde el principio qué métodos y con qué atributos se pueden ejecutar desde el resto de los módulos. Esto puede suponer un mayor trabajo en la etapa de diseño, pero facilita tremendamente la integración del sistema, puesto que se tiene la certeza de que al menos la interconexión de módulos se hace de una manera homogénea. Además, este modelo de comunicación de módulos, permite aprovecharse de las ventajas que ofrece CORBA en cuanto a distribución de objetos se refiere, posibilitando que cada uno de los módulos pueda estar ejecutándose en una máquina diferente. Sin embargo, la utilización de CORBA se traduce en una disminución de la velocidad de ejecución con respecto al esquema de ABROSE. Además el esquema de ABROSE, como ya se ha dicho, sólo exige la ejecución de una máquina virtual en el broker (lo cual constituye uno de los motivos de la citada mayor velocidad de ejecución), mientras que de otra forma el consumo de recursos sería mayor.
Por último, hay que destacar que ABROSE no exige un alto grado de distribución, por lo que las ventajas del modelo centralizado tienen, en este caso, un mayor peso sobre las del esquema distribuido. 3.5 Multiusuario Cuando un usuario se conecta al sistema, una de las primeras cosas que se hacen, es crear un nuevo módulo UCOMMS. Dicho módulo contactará con el BCOMMS del broker pasándole su referencia CORBA (y obteniendo a la vez la propia referencia del broker) y a partir de ese momento ambos dominios quedan en comunicación. De este intercambio, puede deducirse que únicamente habrá una instancia del BCOMMS ejecutándose a la vez en el broker, mientras que puede haber varias instancias de UCOMMS (una por cada usuario conectado). Esto incrementa considerablemente la complejidad del BCOMMS, haciendo que no sea únicamente un módulo puente, que se dedique a recibir llamadas del UCOMMS y a reenviarlas convenientemente a un módulo que las trate o que reciba invocaciones del broker para enviar respuestas al cliente. Desde el momento en que podemos tener varios usuarios conectados a él simultáneamente, se plantea el problema de mantener al BCOMMS permanentemente desbloqueado y listo para recibir peticiones de clientes o respuestas del broker. La solución a este problema, pasa por crear un thread Java independiente, cada vez que el BCOMMS recibe una llamada del cliente. De esta manera, el proceso sería el siguiente: • Cuando el UCOMMS recibe una petición del usuario, se la transmite al BCOMMS. • En vez de hacer la petición al módulo del broker correspondiente él mismo (las peticiones CORBA pueden hacerse no bloqueantes, pero las peticiones Java, que son las que nos incumben ahora, bloquean al módulo llamante hasta que no termine la ejecución del método invocado), crea un thread que se encarga de hacer la verdadera petición. • Así, es este thread el que queda bloqueado, liberando al BCOMMS que vuelve a estar libre para seguir recibiendo peticiones. Para devolver la respuesta al usuario, ya ni siquiera hace falta pasar por el BCOMMS. Es precisamente el mencionado thread creado por dicho módulo, el que recibe la respuesta (que normalmente será el atributo que devuelve el método Java invocado) y se la envía directamente al UCOMMS (con lo que el BCOMMS no precisa ser sobrecargado con una petición más). Podemos ver este proceso ilustrado en la Fig. 6.
Figura 6. Detalle de comunicación entre bloques
3.6 Callbacks Los callbacks, presentan la posibilidad de transmisión asíncrona de información desde el servidor hacia el cliente. Generalmente, la respuesta a una petición, suele venir como el atributo que devuelve un determinado método invocado (en cuyo caso, podríamos considerar que el cliente recibe la respuesta tan pronto como se acaba de ejecutar el método en el servidor). En ocasiones, sin embargo, es interesante que dicha respuesta venga de una manera asíncrona. Si la petición se prevé que puede tardar mucho tiempo en ser procesada, conviene no tener bloqueado al cliente en espera de que acabe la ejecución de un método y resulta más eficiente, desde el punto de vista del usuario, que una vez hecha la petición, quede desbloqueado y sea el servidor el que envíe la respuesta por sí solo cuando esté lista.
El problema en nuestro caso, viene generado, como ya se ha mencionado, por la introducción de Java como medio de comunicación entre bloques. Todas las llamadas Java son por definición bloqueantes, es decir no liberan al llamante hasta que el módulo que incorpora el método invocado, no termine la ejecución del mismo. En CORBA sin embargo, existen los llamados métodos oneway, que obviamente no pueden devolver nada (de otra forma obligarían a bloquear al llamante en espera de que acabe de procesarse el valor del atributo a devolver), no bloquean al llamante y son precisamente los que se utilizan para implementar callbacks. En el caso de haber usado CORBA para comunicar los módulos del broker (siguiendo el esquema de comunicaciones distribuido que se ha contrapuesto al centralizado de ABROSE), no hacía falta ningún mecanismo del estilo de los threads auxiliares que se ha comentado para el BCOMMS, de cara a no dejarlo bloqueado. Hecha esta introducción a los callbacks, podemos comentar un detalle que hay que solventar en el cliente (concretamente en el UCOMMS) y así podremos acabar detallando las comunicaciones UCOMMS-BCOMMS. Cuando el usuario quiere hacer una petición, lo que en definitiva tiene lugar, es una invocación Java (bloqueante) típicamente del AMA o del CA hacia el UCOMMS. Para no dejar bloqueada la interfaz gráfica, se usa en el UCOMMS un artificio de threads semejante al que se utiliza en el BCOMMS. Sin embargo, hay ocasiones en las que sí es necesario bloquear la interfaz en espera del resultado de la petición. Por ejemplo en el caso del login, conviene bloquear el terminal hasta saber si el acceso es o no válido. Hay también otras circunstancias como la modificación, creación o eliminación de un usuario, en las que conviene esperar para confirmar que la operación se realizó con éxito (típico método que devuelve un boolean). En definitiva, ahora tenemos el caso contrario: queremos que el cliente se quede bloqueado. En principio para hacer esto, bastaría con que el UCOMMS no desviase la petición a un thread, sino que se encargase él mismo de procesarla haciendo una llamada CORBA bloqueante al BCOMMS. Cuando se acabe de procesar esa petición se devuelve un valor en la petición CORBA bloqueante y luego se devuelve un valor en la petición Java bloqueante. Sin embargo, desde el momento en que el BCOMMS no puede quedar bloqueado, no pueden usarse invocaciones CORBA bloqueantes, porque la idea es precisamente que tan pronto se hace la invocación CORBA, se genera un thread y se acaba el método invocado, con lo que se acabaría el bloqueo del UCOMMS y además el valor retornado no sería válido. Esto nos va a llevar a que todas las invocaciones CORBA deban ser oneway, es decir, no bloqueantes, lo cual exige otro tipo de solución al problema del bloqueo del cliente. La solución adoptada es mantener al UCOMMS en espera tras hacer la petición CORBA, bloqueando así la llamada del AMA o del CA, hasta que llegue el callback del broker. En ese momento, se permite la terminación del método Java invocado y el terminal queda desbloqueado.
4. Gestión 4.1 Introducción El esquema de bloques del sistema de gestión que incorpora ABROSE, tiene el aspecto de la Fig. 7. Básicamente podemos dividir en dos subsistemas diferentes todo el esquema de bloques: • El sistema ABROSE, descrito anteriormente.
Otras aplicaciones de gestión
Terminal Operador
SNMP
Sistema ABROSE
Memoria (java)
CORBA
TA MA
Agente extensible
UAM
BM
BComms MIB
SNMP A. Sistem A. Red
Figura 7. Esquema de bloques del sistema de gestión •
El Terminal del Operador (OT) y otras aplicaciones de gestión, que permitirán al operador interactuar con el sistema realizando múltiples acciones (iniciar el sistema, pararlo, grabar su estado, realizar una monitorización gráfica de los diferentes módulos, acceder a las diferentes variables de gestión, acceder a ficheros de registro y obtener notificaciones de los distintos módulos. En definitiva, gestionar el sistema completo.
Los agentes del sistema y de red, permiten gestionar el entorno hardware en el que se ejecuta el sistema, mientras que el agente extensible permite al operador monitorizar el sistema entero utilizando únicamente una interfaz ocultando la presencia de numerosos agentes. 4.2 BM Como puede apreciarse en la figura el BM es el módulo responsable de la gestión del sistema. Está encargado de iniciar, parar y almacenar el sistema, monitorizar el status de cada componente (ver Fig. 8) y actuar de puente entre el terminal del operador y el sistema, recibiendo peticiones sobre las variables a gestionar y enviando las notificaciones relevantes de cada módulo. Para hacer todo esto, el BM utiliza diferentes threads que interaccionan entre sí: • Principal: mantiene al resto de las threads y además se encarga de iniciar, almacenar y parar el sistema. • Gestor de notificaciones: recibe las notificaciones de cada módulo. Si son referentes a start, stop o save, las convierte en traps SNMP y se las reenvía al OT. • Gestor de información: se encarga de recibir la correspondiente petición de gestión (get o set) vía CORBA, de localizar el componente hacia el que va dirigida dicha petición (mirando en una tabla de configuración que mantiene el BM), de trasladar la petición al módulo adecuado utilizando referencias Java y de devolver el valor obtenido. • Ping: se encarga de acceder periódicamente a una variable de gestión de estado ubicada en cada componente, enviando notificaciones periódicas al OT. • Manejador de gestión: cada componente tiene un manejador de gestión, que incluye la información a gestionar del componente y además tiene la interfaz mediante la cual el gestor de información accede a las variables a gestionar. El manejador del BM, incorpora además la tabla de configuración donde se almacenan las referencias al resto de los módulos (y que utiliza el gestor de información para reenviar peticiones). 4.3 Información gestionada La información gestionada almacenada en un sistema, determina qué es exactamente lo que se va a gestionar. La existencia o no de una variable de gestión, implicará la posibilidad o no de gestionar una determinada característica del sistema.
Figura 8. Interfaz gráfica de gestión, con el status de cada componente
La idea inicial en ABROSE, es poder gestionar los cinco puntos definidos por el OSI MN (Open System Interconnection Managing System): fallos, configuración, anotaciones, prestaciones y seguridad (FCAPS). Para ello, se ha definido la siguiente información en la MIB (Management Information Base) de ABROSE: • Cada componente tiene una variable de status, que aporta información sobre el estado del módulo. • Se han definido traps para iniciar, parar y almacenar (start, stop, save) el sistema. • Tanto el BM como el BCOMMS, debido a su importante labor de interfaz al sistema de gestión y al broker respectivamente, tienen algunas variables adicionales: - El BCOMMS contabiliza el número de veces que los diferentes UCOMMS acceden al broker, almacenando también qué método se utilizó en cada acceso. También incorpora información del tiempo que se tardó en ejecutar cada método. - El BM tiene variables para configurar el tiempo entre muestreos del status de cada componente (polling), ubicación del fichero de registro de notificaciones, variables para llevar a cabo el start, stop, save y dos tablas: la ya mencionada de configuración, con todos los componentes y su estado y otra tabla con las notificaciones almacenadas durante el último arranque del sistema. 4.4 Funcionalidad de gestión Se han implementado dos diferentes maneras de gestionar el sistema, de cara a poder utilizar cualquier plataforma de gestión, sin limitación de protocolos. Sistema ABROSE
CallSystem
Memoria (java)
TA MA
CORBA
BM
UAM BComms
Figura 9. Aplicación de gestión CallSystem
CallSystem Es una aplicación que supone una funcionalidad mínima del sistema de gestión, pues utiliza el esquema presentado en la Fig. 9 en vez del de la Fig. 7. La idea es acceder directamente utilizando CORBA a la interfaz de gestión del BM, permitiendo únicamente iniciar, parar o almacenar el estado del sistema. Este esquema tan simple, resulta sin embargo de gran utilidad en entornos de prueba, aunque no puede utilizarse para gestionar el sistema en un entorno real. OT Es mucho más potente que la aplicación anterior, permitiendo iniciar el sistema, pararlo, almacenar su estado, monitorizar gráficamente los módulos, acceder a las diferentes variables de gestión, acceder a ficheros de registro y obtener notificaciones de los distintos subsistemas. Es la aplicación que permite gestionar por completo el sistema. Para conseguir esto, el OT accede al agente extensible, que se estará ejecutando en un puerto UDP bien conocido. Este consultará la MIB y reenviará la petición hacia el agente correspondiente o hacia la interfaz CORBA del BM, gracias a un traductor de SNMP específicamente diseñado. A diferencia del CallSystem, este esquema exige que tanto el agente extensible, como los diferentes agentes para manejar la red o el sistema, estén activos.
5. Conclusiones Las principales conclusiones extraídas con respecto a comunicaciones, están relacionadas con la elección de un esquema centralizado de comunicaciones entre dominios y la utilización de Java dentro de los dominios. El esquema centralizado, permite concentrar la complejidad inherente a todo sistema que exija cierta conectividad, únicamente en dos módulos, liberando al resto de la necesidad de tener en cuenta la arquitectura de comunicaciones. Como todo sistema centralizado, implica cierta pérdida de flexibilidad y un pequeño retardo adicional, al tener que pasar por un módulo intermedio antes de llevar a cabo la comunicación. El hecho de utilizar Java como medio de comunicación de módulos dentro de cada dominio, posibilita una mayor rapidez que si se usase CORBA, pero obliga a suplir la versatilidad que ofrece CORBA a la hora de realizar callbacks, con un código un poco más elaborado. Por otro lado, el entorno de aplicación no pretende ser excesivamente distribuido ni heterogéneo, lo cual sí justificaría la utilización de CORBA en las comunicaciones internas de los dominios. Desde el punto de vista de gestión, lo que se ha planteado es un modelo donde coexisten diferentes tecnologías: Java para gestionar internamente el sistema, CORBA como protocolo de comunicación del sistema con el exterior y SNMP como protocolo de conexión entre el gestor y los diferentes agentes. Para facilitar la labor de desarrollo, se utiliza una aplicación que, minimizando las tareas de gestión realizables, permite arrancar el sistema completo, así como pararlo y salvar su estado. El modelo completo de gestión incorpora un plataforma sobre Tcl-Tk, que permite utilizar una vistosa interfaz gráfica para monitorizar el status de cada componente, visualizar las diferentes variables de gestión, iniciar o parar el sistema, etc. Tanto la arquitectura de comunicaciones como la plataforma de gestión presentadas, ya han sido convenientemente verificadas y validadas en el prototipo implementado para la versión 1 de ABROSE.
Agradecimientos Este trabajo ha sido parcialmente financiado por la Comisión Europea a través de los proyectos ACTS ABROSE (AC316) y ABS (AC206).
Referencias [1] ACM – “Recommender Systems”. Special Issue of Communications of the Association of Computing Machinery – Vol40 N°3 – March 1997 [2] An adaptive Web page recommendation service”. Balabanovic Marko. Proceedings of autonomous agents, 1997 [3] ABS Broker Business Model, D23. P. Alzon, P. Tothesan, M. Hubert, E. Athanassiou, A. Hoang Van. 1996 (http://b5www.berkom.de/ABS/D23.htm) [4] ABS Brokerage Architecture, D42. 1998 [5] ABS General Service Description, D32. 1997 [6] An Approach to Electronic Brokerage in TINA Environments. Juan I.Asensio, Victor A. Villagrá, José I.Moreno, Julio Berrocal. Fifth International Conference On Intelligence in Services and Networks. IS&N’98. May 25-28, 1998. Antwerp, Belgium. Published by Springer in Lectured Notes in Computer Science 1430. [7] Application of TINA-C Computing and Service Architecture Concepts to the development of an Advanced Information Brokerage Service in the context of EC. J.I.Asensio, J.I.Moreno, V.Villagrá, J.Redondo. A. Nolle, I. Tothezan, G.Karestos. Telecommunications Information Networking Architecture. TINA'97 Conference. Santiago de Chile, 18-21 November 1997 [8] ABROSE: Agent Based Brokerage Services in Electronic Commerce (ACTS: AC316) http://b5www.berkom.de/abrose/ [9] ABS: Architecture for Information Brokerage Service (ACTS: AC206) http://b5www.berkom.de/ABS/
