Interoperabilidad entre Plataformas de Agentes FIPA: Una Aproximación Basada en Componentes *

Transcripción

1 Interoperabilidad entre Plataformas de Agentes FIPA: Una Aproximación Basada en Componentes * M. Amor Dept. Lenguajes y C.C. Universidad de Málaga Málaga, Spain pinilla@lcc.uma.es L. Fuentes Dept. Lenguajes y C.C. Universidad de Málaga Málaga, Spain lff@lcc.uma.es M. Pinto Dept. Lenguajes y C.C. Universidad de Málaga Málaga, Spain pinto@lcc.uma.es Resumen El uso masivo de Internet ha propiciado la aparición de aplicaciones basadas en agentes desarrolladas sobre distintas plataformas de agentes. La interoperabilidad entre distintas plataformas de agentes es una característica crítica para el desarrollo de aplicaciones heterogéneas. Para conseguir esta interoperabilidad es muy importante el uso de las especificaciones propuestas por FIPA, organización encargada de la producción de estándares en el área de los agentes. Sin embargo las plataformas que siguen las especificaciones de FIPA pueden no ser completamente interoperables debido a algunas incompatibilidades que pueden ser fácilmente salvadas. Este artículo presenta una propuesta para desarrollar sistemas basados en agentes heterogéneos sin tener en cuenta las plataformas sobre las que son ejecutados permitiendo la comunicación entre agentes pertenecientes a plataformas no interoperables. La base de nuestra propuesta es el uso de la tecnología de componentes para el desarrollo de agentes software adaptables. Nuestro agente software un separa la distribución de mensajes a través de distintas servicios de transporte de mensajes ofrecidos por distintas plataformas de agentes del resto de funcionalidad propia de un agente, reduciendo la dependencia del agente de aquellos aspectos propios de la plataforma de agentes sobre la que será ejecutado. Palabras Clave Agentes, Componentes Software, FIPA, plataformas de agentes, interoperabilidad. INTRODUCCIÓN El creciente uso de Internet para realizar tareas de la vida diaria hace necesario el desarrollo de software capaz de hacer frente a entornos abiertos y dinámicos. Frente a otras tecnologías usadas para desarrollar aplicaciones distribuidas en la Web, los agentes software parecen presentar las características necesarias para soportar el desarrollo de sistemas abiertos y flexibles en este tipo de entornos. En concreto identificamos dos características que son relevantes para este enfoque: autonomía e interoperabilidad. La autonomía es necesaria en entornos dinámicos ya que facilita y permite la adaptación de los agentes software a nuevos protocolos de comunicación no soportados inicialmente. Por otra parte, la interoperabilidad es una condición crítica para la implementación de sistemas abiertos [1], ya que es deseable que diferentes plataformas puedan interoperar permitiendo la comunicación entre diferentes agentes y facilitando su reutilización en aplicaciones heterogéneas. Una de las formas de alcanzar la deseada interoperabilidad entre plataformas es la definición y uso de estándares aprobados por un comité internacional. En el área de los agentes, FIPA (Foundation for Intelligent Physical Agents) [2] es la organización encargada de producir especificaciones para la interacción de agentes y sistemas de agentes heterogéneos. Estas especificaciones comprenden principalmente la infraestructura (servicios, formatos) y las aplicaciones de agentes. Sin embargo, y a pesar de coexistir un gran número de implementaciones que cumplen estos estándares, existen algunas diferencias salvables que evitan una total comunicación entre diferentes plataformas. Estas diferencias surgen de las diferentes suposiciones o elecciones que se realizan durante la implementación de las plataformas sobre aquellos aspectos que no han sido cubiertos en una especificación FIPA. Una forma de solucionar estos problemas, propuesta por FIPA, es la utilización de pasarelas (gateways) entre plataformas que salven estas discrepancias y faciliten la comunicación entre agentes. Sin embargo éstas, que deben formar parte de la plataforma, no están siempre disponibles ya que es deber del desarrollador de la plataforma ofrecerlas. Otra de las posibles soluciones es dotar a los agentes de la posibilidad de operar en distintas plataformas. En nuestra opinión, es más fácil diseñar y construir un agente capaz de interoperar a través de distintas plataformas que extender y modificar una plataforma para que ofrezca comunicación con otras plataformas. Sin embargo, la capacidad de extensión y adaptación de un agente depende de su arquitectura interna, y las arquitecturas actuales sobre las que se desarrollan agentes (FIPA-OS [3], JADE [4] o ZEUS [5]) no ofrecen la flexibilidad requerida. Por tanto es necesario diseñar y desarrollar arquitecturas de agentes extensibles y adaptables. * Este trabajo ha sido financiado en parte por el proyecto CICYT TIC: C02-02

2 Nosotros proponemos una arquitectura composicional sobre la que desarrollar agentes software que facilita su construcción a partir de componentes software reutilizables. Esta arquitectura descompone la funcionalidad del agente en componentes totalmente independientes, facilitando la incorporación o sustitución componentes, y permitiendo un mayor grado de adaptación del agente resultante. Además, para conseguir una mejor descomposición funcional del agente software, aquellas propiedades que están presentes en (atraviesan) varios componentes se modelan como aspectos de acuerdo a lo que el desarrollo de software orientado a aspectos propone (DSOA, o en ingles AOSD) [6]. De esta forma, abstracciones que forman parte del agente como el comportamiento, los protocolos de interacción, y la distribución de mensajes a través de un servicio de transporte están separados internamente en entidades diferentes dentro de la arquitectura. Esta separación permite alterar cada uno de estos componentes en tiempo de ejecución sin que el resto se vea afectado. Así, por ejemplo, el agente podrá adaptarse al entorno entrenándose en un nuevo protocolo de interacción o transformarse en otro agente cambiando su funcionalidad sin necesidad de incluirla de antemano. Además en el caso que nos ocupa sacamos partido de la posibilidad de interoperar a través de distintas plataformas de agente para ofrecer una solución intermedia al problema de la interoperabilidad entre plataformas de agentes FIPA. para una arquitectura abstracta de FIPA[7] permite la creación de diferentes implementaciones y ofrece también las transformaciones tanto para transporte de mensajes, esquemas de codificación de mensajes y localización de agentes y servicios a través de directorios de servicios. Sin embargo FIPA no cubre otros aspectos que surgen o dependen de la implementación, bien por que están fuera de ámbito o porque no están incluidos en las especificaciones. El Modelo de Referencia FIPA Una plataforma de agentes FIPA se define como el software que implementa un conjunto de especificaciones FIPA. Para que se considere que sigue las normas de FIPA, una plataforma debe implementar al menos la especificación sobre la gestión de agentes[8] y las relativas al lenguaje de comunicación de agentes (ACL)[9]. La primera se ocupa del control y gestión de agentes dentro de y a través de plataformas de agentes. Las relativas al ACL se encargan del formato de los mensajes, los protocolos de interacción y de intercambio de mensajes entre agentes, la descripción de actos comunicativos que definen la semántica de los mensajes intercambiados y los diferentes lenguajes para expresar el contenido de un mensaje (lenguaje de contenido). Software Este trabajo presenta una propuesta de utilización de un agente desarrollado sobre esta arquitectura basada en componentes y que aprovechando las características derivadas de la comunicación a través de distintas plataformas actúa de representante (proxy) encargado de permitir la comunicación entre dos agentes en distintas plataformas donde no es posible solventar los problemas de comunicación. Agent Agent Platform Agent Management System Message Transport System Directory Facilitator En la siguiente sección describimos brevemente el modelo de referencia propuesto por FIPA de plataformas de agentes y detallamos algunas de las divergencias que pueden observarse en algunas de la implementaciones disponibles. A continuación presentamos la arquitectura de agentes software basada en componentes y las principales entidades de nuestro modelo. La sección 4 ilustra un escenario típico donde es beneficioso aplicar nuestra propuesta. Finalmente, en la última sección se extraen algunas conclusiones sobre el trabajo desarrollado y nuestra propuesta. MODELO DE REFERENCIA DE FIPA Uno de los objetivos principales de FIPA es especificar una arquitectura de agentes que permita la utilización de un amplio número de mecanismos y servicios, como varios protocolos de transporte o servicios de directorio. Dada la posibilidad elegir entre varios de estos mecanismos y protocolos, los sistemas de agentes construidos de acuerdo a esta arquitectura deberían de ser capaces de interoperar a través de pasarelas de transporte, ya que la especificación Message Transport System Agent Platform Figure 1. Modelo de Referencia FIPA (extraída de [7]) El objetivo de la especificación de gestión de agentes es ofrecer un marco de trabajo estándar donde los agentes FIPA existan y operen, estableciendo un modelo de referencia lógico para la creación, registro, localización, comunicación, migración y baja de agentes. Este modelo de referencia se compone de un conjunto de entidades (mostradas en la Figura 1) que ofrecen diferentes servicios. Estas entidades son:

3 Un Agente Software (Agent) es un proceso computacional que implementa la funcionalidad autónoma y comunicativa de la aplicación, ofreciendo al menos un servicio. Los agentes se comunican a través de un ACL. Un agente debe tener al menos un propietario y un identificador de agente (AID) que lo identifica de forma unívoca. Además, un agente puede disponer de varias direcciones de transporte a través de las cuales puede ser contactado. Dependiendo de la implementación de la plataforma un agente puede tratarse de un componente Java o un objeto CORBA.. Un Facilitador de Directorio (Directory Facilitator) que ofrece un servicio de páginas amarillas para localizar agentes. Los agentes deben registrarse previamente en este servicio para ser localizados como proveedores de un servicio, y recurren a él en busca de agentes que ofrezcan un determinado servicio. Un Sistema de Gestión de Agentes (AMS Agent Management System) que controla el acceso y uso de la plataforma de agentes. Sólo puede existir un agente AMS por plataforma, y se encarga de generar AIDs válidos además de ofrecer un servicio de búsqueda de agentes por nombre. Un Servicio de Transporte de Mensajes (MTS Message Transport Service) ofrece un servicio de comunicación entre agentes, encargándose del transporte de mensajes entre agentes. FIPA especifica para este componente un modelo de referencia y varias especificaciones sobre distintos protocolos y mecanismos de transporte que favorece la interoperabilidad entre plataformas. La plataforma de agentes (AP Agent Platform) ofrece una infraestructura física sobre la que desplegar los agentes y está compuesta de un software de soporte, los componentes para la gestión de agentes (DF, AMS, y MTS) y los agentes. Una entidad software (Software) sirve para representar cualquier sistema software accesible a través de un agente, como un componente COTS (Commercial offthe-shelf) o un servicio Web. Además FIPA también define y especifica una serie de elementos y conceptos importantes para alcanzar la interoperabilidad como son: un servicio, que define un conjunto de acciones incluidas en una ontología; un ACL, que es el lenguaje para construir mensajes y actos comunicativos; y un AID, que identifica un agente incluyendo denominaciones, roles y direcciones de transporte. Incompatibilidades entre plataformas FIPA Aunque estos componentes se encuentran en las implementaciones del modelo de referencia FIPA más populares como son Jade, FIPA-OS o Zeus, pueden hallarse algunas diferencias debidas a las suposiciones hechas por el desarrollador durante la implementación, que sin embargo pueden ser solucionadas en la mayoría de los casos fácilmente. Estro se debe a que el documento que especifica la arquitectura abstracta de FIPA no detalla algunos componentes y procesos de esta arquitectura como la creación e inicialización de agentes sobre una plataforma (bootstrapping), o la noción de pasarela, o la coordinación y configuración de agentes. Tampoco establece una especificación única que sirva de consenso para establecer un protocolo de transporte común o una representación común dentro de la variedad de representaciones especificadas disponibles. Concretamente estos son algunos ejemplos que pueden afectar a la interoperabilidad: FIPA ofrece una amplia variedad de especificaciones de protocolos de transporte sobre los que transmitir mensajes, sin especificar el número de transportes utilizados por una plataforma, ni la obligatoriedad de uno de ellos en particular. Pero en la práctica es necesario que dos plataformas compartan al menos un protocolo de transporte de los especificados por FIPA para que puedan interoperar. De hecho, Jade y FIPA-OS, a pesar de utilizar Java/RMI como protocolo de transporte interno, son incapaces de comunicarse a través de este protocolo debido a que FIPA no ofrece una especificación concreta para este protocolo de transporte y ambas implementaciones son totalmente incompatibles. Por otro lado, no basta con compartir un protocolo de transporte, sino que además ambos servicios de transporte deben compartir la misma representación para codificar la envoltura (envelope) del mensaje de transporte. FIPA también ofrece varias representaciones y, pesar de que existe una correspondencia natural entre el protocolo de transporte y la codificación elegida (p.e. IIOP MTS y CORBA IDL como representación) no existe una especificación que establezca de forma unívoca esta correspondencia dentro de los estándares de FIPA. De forma que cualquier otra combinación también es posible y válida, obstaculizando la interoperabilidad entre plataformas. Teniendo en cuenta que la libertad de elección puede complicar la interoperabilidad, FIPA propone la realización de pasarelas para solventar las posibles diferencias. Sin embargo, suministrarlos es tarea de los desarrolladores de las plataformas por lo que no siempre están disponibles a pesar de ser necesarios. Cuando una plataforma soporta varios protocolos de transporte que proporcionan interoperabilidad con otras plataformas, suele ser necesaria una configuración extra para hacer efectiva esta comunicación. Para usuarios no expertos que desconocen la posibilidad de utilizar varios protocolos de transporte puede resultar incómodo y difícil conseguir esta interoperabilidad ya que requiere configuración extra. La evolución y mejora de una plataforma de agentes que soporte más especificaciones y servicios depende en gran parte del equipo de desarrollo. Mientras que las

4 primeras versiones no ofrecen un gran número de servicios y especificaciones de las dadas por FIPA, esfuerzos como el de Agentcities [10], y el uso y su intento de integración hacen que versiones posteriores mejoren la interoperabilidad con otras plataformas, y se establezcan puntos de conformidad para alcanzar la interoperabilidad Dado que la lista de MTS permanece abierta, las plataformas de agentes deberían ofrecer una forma de añadir fácilmente nuevos MTS sin necesidad de depender de las socorridas pasarelas que deben ofrecer los proveedores de plataformas de agentes. Estos ejemplos muestran como se puede alcanzar la interoperabilidad pero que demanda un esfuerzo y un acuerdo común por parte de los diferentes proveedores de plataformas de agentes. ARQUITECTURA COMPOSICIONAL DE AGENTES SOFTWARE En esta sección presentamos un modelo basado en componentes para el diseño de agentes software. Los agentes son sistemas software capaces de llevar a cabo tareas y acciones de forma autónoma para conseguir una serie de objetivos. La parte más crítica del diseño de un sistema basado en componentes es su descomposición funcional. Para mejorar la descomposición funcional del agente aplicamos el principio de separación de aspectos, y modelamos la coordinación entre componentes en una nueva entidad, a la que llamaremos conector. Normalmente dentro de un mismo componente encontramos, además de su comportamiento interno, código relativo a la comunicación con el resto de componentes. Esto hace difícil reutilizar sólo la parte funcional de un componente cuando varían los componentes con los cuales se coordina. Entre las ventajas de esta separación está el aumento de la reutilización, tanto de la funcionalidad del componente, que ya no incluye código específico para la comunicación con otros componentes, como de los conectores que determinan los patrones de interacción. Por otra parte, también se ha separado en entidades independientes la comunicación con otros agentes o recursos del entorno a través de distintos servicios de transporte ofrecidos por plataformas de agentes. Dentro de su participación en una interacción un agente envía mensajes a otros agentes, cuya representación y envío dependerá del protocolo de transporte y de la plataforma que ofrece dicho servicio. Separando este aspecto, denominado de distribución, de la coordinación y de la funcionalidad ofrecida por el agente podemos desacoplar la participación del agente en una aplicación (ofreciendo un servicio y comunicándose a través de un protocolo de interacción)de la plataforma de transporte utilizada para enviar y recibir los mensajes. La Figura 1 muestra el diagrama de clases UML de la arquitectura composicional propuesta. Usamos estereotipos UML para modelar las entidades de nuestro modelo, denominadas <<Connector>>,, <<Mediator>>, <<Distribution>>, e <<Interface>>. Los conectores, representados en este diagrama por el entidad <<Connector>>, coordinan las diferentes interacciones o conversaciones en las que participa el agente de acuerdo a un protocolo de comunicación. Un agente puede participar en más de una conversación de forma simultánea, y cada conversación será controlada por un conector diferente. Realmente todos los conectores son iguales, y sólo difieren en tiempo de ejecución en el protocolo que coordinan, el cual es proporcionado al conector cuando es creado. Aunque dentro de nuestra arquitectura los conectores se encarguen de coordinar la ejecución de un protocolo, los patrones de interacción no se encuentran codificados dentro de los conectores como es usual. En su lugar, aceptan una descripción de un protocolo de coordinación y controlan su ejecución en base a esta [11]. Una descripción define no sólo el intercambio de mensajes que se lleva a cabo durante la interacción, sino también qué acciones internas lleva a cabo el agente durante la ejecución del protocolo. De esta forma es posible enlazar o conectar la participación del agente en un en una interacción siguiendo un protocolo de comunicación con la funcionalidad ofrecida por el agente. En general los componentes etiquetados como encapsulan datos y comportamiento. Algunos componentes están siempre presentes en la arquitectura ofreciendo la funcionalidad básica del agente como por ejemplo enviar un mensaje (componente BasicAgentActions) o almacenar datos (componente KnowledgeBase). Los componentes software ofrecen también funcionalidad específica de un dominio de aplicación, como por ejemplo negociar, pujar o comprar en un mercado electrónico (componente e-market). En realidad cualquier componente software puede ser incorporado como parte de la funcionalidad del agente, desde un componente COTS (Commercial Off-The-Shelf) hasta un servicio Web [12]. Esta flexibilidad se debe a que extendemos el uso de DAML-S [13], una ontología aplicada a la descripción de servicios, para describir, independientemente de la implementación, la interfaz pública de los componentes que proporcionan la funcionalidad del agente. Tanto la información acerca de los componentes registrados en la arquitectura como su identificador y su localización se almacena en objetos ComponentInfo.

5 Ontology -ontologyid -description 1..* ProtocolTemplate -protocolid -description 1..* Finite State Machine +inputmessage() +triggertransition() ProtocolTemplate <<Interface>> AgentInterface getprotocoltemplate() <<Connector>> ProtocolConnector doaction() handlemsg() result() perform action message ACLParser +encodemessage() +parsemessage() ComponentInfo -remoteaddress : java.net.url -OntologyID -reference -reference e-market -ontologyid = e-market +bid() +buy() -reference KnowledgeBase -ontologyid = KnowledgeBase +addvar() +getvar() +istrue() <<Mediator>> AgentCompositionalCore +deliver( Message ) +incomingmessage() +initializeconversation( protocol template ) : ProtocolConnector +perform(ontology,service, parameters) reference TPfNActions -ontologyid = TPfN +TrainProtocol() +UnderstandProtocol() +VerifyProtocol() BasicAgentActions +broadcast() +sendmessage() output message input message encoded message <<use>> <<Interface>> AgentExternalCommunication +receivemessage() +sendmessage() <<Distribution>> CommunicationDistribution MTSAdapter -@AID -@platformid +delivermessage() <<use>> +AMSregister() +sendmessage() encoded message <<table>> DistributionTable +get() +put() Figura 1. Diagrama UML de la Arquitectura Composicional de Agente Software. Durante la ejecución, cuando el agente inicia una nueva interacción el componente <<Mediator>> AgentCompositionalCore (ACC) se encarga de crear un nuevo conector que controle la participación en dicha conversación siguiendo un protocolo de interacción. Además, durante la ejecución del protocolo, este componente es el encargado de llevar a cabo la composición dinámica entre los componentes y los conectores. La composición se establece mediante la correspondencia entre el servicio solicitado por el conector y los servicios ofrecidos por los distintos componentes registrados. Como expusimos anteriormente, una ontología nos sirve para describir los servicios ofrecidos por los componentes software. Pero también es utilizada por los conectores, que solicitan la invocación de un servicio utilizando la descripción contenida en la ontología. Una vez resuelto el componente encargado de ofrecer dicho servicio, el ACC localiza el componente a partir de la información del objeto ComponentInfo correspondiente e invoca el servicio. En nuestra arquitectura existen otras abstracciones de los agentes que han sido separadas en entidades independientes, como es la utilización de diferentes implementaciones de servicios de transporte de mensajes ofrecidos por diferentes plataformas de agentes. Separando este aspecto, denominado de distribución, podemos hacer independiente la participación del agente en una interacción del servicio de transporte utilizado para intercambiar mensajes con otros agentes ejecutándose en distintas plataformas. Por lo tanto el componente de distribución CommunicationDistribution permite que el agente se comunique con otros agentes a través de distintas plataformas de agentes y servicios de transporte haciéndolo más versátil y adaptable. Este componente, mediante el uso de adaptadores, es el encargado de enviar y recibir mensajes a través de distintos servicios de transporte. Cada adaptador, que realiza la interfaz MTSAdapter, encapsula aquellos aspectos dependientes de una plataforma de agentes como el formato de la envoltura, o la invocación del servicio de transporte de mensajes. Cuando se inicia un objeto adaptador para una determinada plataforma de agentes, éste se encarga de obtener un identificador para el

6 agente y las direcciones de transporte para su comunicación a través de dicha plataforma. Además realiza cualquier proceso de inicialización y registro del agente dentro del AMS ofrecido por la plataforma (recordemos que la inicialización de agentes no se contempla en ninguna especificación de FIPA y depende de la plataforma sobre la que el agente es creado). Por otra parte la entidad <<Interface>>, representada por los componentes AgentExternalCommunication (AEC) y AgentInterface, se encarga de las interacciones del agente que no dependen del servicio de transporte ni del protocolo de interacción. El componente AEC se encarga de codificar y decodificar los mensajes de entrada y salida en diferentes representaciones del ACL, como XML, String o BitEfficient, y de procesar los mensajes de entrada descartando aquellos que contienen errores sintácticos de acuerdo a su representación. El componente AgentInterface incluye la interfaz pública del agente, que es una extensión de la interfaz pública tradicional de los componentes software para el caso de los agentes. En nuestro caso incluye la funcionalidad ofrecida por el agente (y proporcionada por los componentes) y una lista de protocolos de comunicación que el agente soporta, entre otros elementos. Este componente guarda además las descripciones de los protocolos soportados y las ontologías que describen los servicios ofrecidos por los componentes registrados. Las descripciones de los protocolos serán utilizadas por el ACC para crear nuevos conectores cuando el agente inicia o participa en una nueva interacción gobernada por alguno de estos protocolos, y las ontologías sirven para realizar la composición dinámica de componentes y conectores. Los distintos componentes y protocolos de interacción que formarán parte de un agente cuando éste es creado se detallan en un documento XML que contiene información de despliegue (mostrado en la Figura 2). Este documento, cuya estructura se define en un esquema XML, también contiene información sobre los posibles formatos de codificación de los mensajes. Por ejemplo, si se conoce que se codificarán los mensajes ACL como una cadena de caracteres, se incluye un codificador/decodificador para este tipo de representación. El documento de la Figura 2 muestra también como se particularizan los componentes software (componente emarket) que serán registrados en el agente como parte de su funcionalidad, indicando también su localización, los protocolos inicialmente soportados por el agente referidos mediante la descripción de dicho protocolo en un documento XML. Por último, se incluye también como información de despliegue una referencia a la implementación del adaptador a la plataforma de comunicación FIPA-OS. <?xml version="1.0" encoding="utf-8"?> <deployment xmlns:xsi=" xsi:nonamespaceschemalocation="c:\map\tesis\xml\deploymentschema.xsd"/> <!-- Fichero de despliegue de un agente de subasta--> <aclrepresentation> <format> <ID>String</ID> <URI>file:///c:/code/ca3.acladapter.StringEncoding.class</URI> </format> </aclrepresentation> <behaviour> <component> <ontology>file:///c:/onto/e-market.daml</ontology> <URI>file:///c:/code/ca3.behaviour.emarket.class</URI> </component> </behaviour> <coordination> <protocol> <ID>EnglishAuction</ID> <URI>file:///C:/xml/EnglishAuction.xml</URI> </protocol> </coordination> <distribution> <platform> <adapterto>fipaos</adapterto> <URI>file:///c:/code/ca3.distribution.FIPAOSAdapter.class</URI> </platform> </distribution> </deployment> Figura 2. Fichero de despliegue de un agente participante en una subasta. En el mejor de los casos no será necesario programar nueva funcionalidad, ya que si se desarrollan diferentes sistemas de agentes dentro del dominio del comercio electrónico es posible reutilizar componentes que ofrezcan funcionalidad propia de este dominio para, por ejemplo, pujar o comprar. Asimismo, adaptar el agente para que soporte un nuevo protocolo de interacción sólo requiere describir éste en XML para que el agente pueda incorporarlo. Por otra parte, hemos de puntualizar que la configuración descrita en la información de despliegue no tiene que permanecer fija una vez que el agente es creado. El agente es capaz de registrar nuevos componentes o actualizar los registrados en tiempo de ejecución para incorporar nuevas versiones, o puede aprender nuevos protocolos de negociación cargando nuevas descripciones de protocolos, o incorporar nuevos adaptadores a otras plataformas de agentes, codificadores y decodificadores de representaciones de mensajes ACL sin necesidad de suspender la ejecución del agente o reemplazarlo por otro que soporte nueva funcionalidad. NUESTRA PROPUESTA PARA ALCANZAR INTEROPERABILIDAD A continuación mostraremos con un breve ejemplo como podemos resolver el problema de la interoperabilidad en el contexto de una aplicación basada en agentes heterogéneos. Nuestro objetivo es facilitar la comunicación entre los participantes en un mercado electrónico sin tener en cuenta la plataforma a la que pertenecen. Este ejemplo ilustra la situación de dos plataformas FIPA que no comparten el mismo MTS y que ninguna de ellas ofrece una pasarela adecuada. El ejemplo es muy simple. Cada transacción es establecida por un agente Broker (Mediador) que se encarga de reunir a compradores y vendedores, simplificando la interacción dentro del mercado.

7 La Figura 3 muestra las interacciones que se llevan a cabo. En este mercado, un agente denominado Proveedor (Provider), que intenta vender sus productos, representa a un vendedor. En el ejemplo, si un Proveedor quiere vender naranjas le comunica al agente Broker que publique su oferta para vender naranjas (interacción 1 en la Figura 3). Los compradores están representados por el agente Comerciante (Trader) representante de un supermercado encargado de comprar productos para el almacén. 2. Quiero naranjas!! Trader query-if inform Broker propose accept-proposal 3. Negociación inform 1. Vendo naranjas!! subscribe Provider Figura 3. Interacciones del Mercado Electrónico Cuando el Comerciante necesita comprar un producto, por ejemplo naranjas, solicita al agente Broker los agentes que tenga registrados como vendedores de naranjas (interacción 2 en la Figura 3). En caso de encontrar correspondencia el agente Broker le devolvería el identificador del agente Proveedor ya registrado para que estos dos iniciasen una negociación sobre la compra y venta de naranjas (interacción 3 en la Figura 3). 1.1 Implementación del Mercado Para desarrollar esta aplicación de Mercado Electrónico deseamos reutilizar dos agentes ya desarrollados que reúnen los requisitos del agente Comerciante (Trader en la Figura 3) y del agente Proveedor (Provider en la Figura 3). Sin embargo estos dos agentes han sido desarrollados sobre diferentes plataformas de agentes (FIPA1Vendor y FIPA2Vendor) que además no son interoperables, por lo que ambos agentes no pueden comunicarse. Para solucionar esta situación nos planteamos la implementación de un agente intermediario (Broker en la Figura 3) sobre la arquitectura de agente propuesta en la sección anterior que pueda operar y comunicarse a través de ambas plataformas y de esta forma atender las peticiones de agentes compradores y vendedores. Además necesitaremos de un agente representante (Proxy en la Figura 3) que solucione los problemas de interoperabilidad entre los agentes de distintas plataformas mientras se lleva a cabo la negociación. Para implementar ambos agentes tan sólo necesitamos describir, en dos documentos de despliegue, la configuración de los componentes que conformarán los servicios de los agentes, los protocolos de comunicación soportados, y referencias para localizar adaptadores a las dos plataformas de agentes sobre las que deberán operar los agentes. Así pues, en el caso de agente Broker la información de despliegue incluirá la referencia a un servicio de registro, y a los ficheros que describen las interacciones con el agente Proveedor por un lado y el agente Comerciante por otro. Asimismo incluirá dos adaptadores para comunicarse a través de las plataformas. De igual forma, la información de despliegue del agente Proxy incluye ambos adaptadores. Como protocolo de interacción este agente debe soportar el protocolo de negociación usado por el agente Proveedor y el agente Comerciante para negociar la compraventa de un producto. Cuando el agente Broker establece una correspondencia entre una oferta y una demanda, y ante la imposibilidad de comunicación, este agente solicita los servicios de un agente Proxy que resuelva el conflicto. Como parte de su servicio y para poder establecer la comunicación entre los agentes Proveedor y Comerciante, el agente Proxy es informado por el agente Broker sobre los participantes de la interacción. Posteriormente, el agente Broker informa al agente Comerciante sobre la disponibilidad de un agente que satisface sus demandas y le devuelve la referencia al agente Proxy que hará de intermediario en la comunicación. El agente Comerciante iniciará la negociación enviando el mensaje correspondiente al agente indicado por el agente Broker, que en este caso es un intermediario que recibirá el mensaje para enviarlo al agente Proveedor indicado por el agente Broker cuando solicitó sus servicios, como contraparte en la interacción, enviando el mensaje tal cual, pero a través de la plataforma de agentes adecuada. La Figura 4 muestra en un diagrama de colaboración UML, como interaccionan los distintos componentes integrantes del agente Proxy durante la ejecución de la negociación. Como muestra la figura, este agente se comunica con ambos agentes Trader y Provider a través de distintos adaptadores, encapsulados en el aspecto de Distribución y que permiten la comunicación simultánea a través de dos plataformas de agentes diferentes. La coordinación de las interacciones entre los agentes se lleva a cabo independientemente de la plataforma de agentes sobre la que se realice la distribución de los mensajes que se intercambian durante la interacción. En este caso, el agente Proxy recibe los mensajes enviados por el agente Provider a través de uno de los adaptadores, concretamente el identificado como FIPAVendor2. En el caso de que sea el primer mensaje enviado por el agente Provider la tabla de distribución es actualizado con una entrada que establece la relación (FIPAVendor2, Provider AID). De esta forma, cuando el agente envie un mensaje a este agente, no será necesario determinar la plataforma de salida.

8 ProxyAgent <<Connector>> proxy : ProtocolConnector handlemsg( inputmsg ) sendmessage() <<Mediator>> ACC perform(ontology,service, parameters) sendmessage() deliver( Message ) bid incomingmessage() <protocol proxy> <messages> <transitions> <rules> : BasicAgentActions : KnowledgeBase <<Interface>> AEC : AgentExternalCommunication XML : ACLParser receivemessage() <<Distribution>> MTS : CommunicationDistribution <<table>> : DistributionTable {entry1="fipa1vendor" (agent-identifier name: Trader@fipa1vendor.map.es), entry2="fipa2vendor" (agentidentifier name: Provider@fipa2vendor.map.es), =} delivermessage() FIPAVendor2 : MTSAdapter {AID=:name proxy@fipa2vendor.map.es, PlatformID=FIPA2Vendor.map.es} FIPAVendor1 : MTSAdapter {AID=:name proxy@fipa1vendor.map.es, PlatformID=FIPA1Vendor.map.es} Message Message Message Message Provider:Agent {AID=:name Provider@fipa2vendor.map.es} Trader: Agent {AID=:name Trader@fipa1vendor.map.es} Figura 4. Diagrama de Colaboración del agente Proxy durante la ejecución de una negociación El mensaje es procesado por el componente AEC que decodificará el mensaje de acuerdo a la representación del ACL. Para cada posible representación, este componente posee el codificador (para los mensajes de salida) y decodificador (para los mensajes de entrada) de diferentes representaciones (XML, String, ). A continuación, el mensaje es recibido por el componente Mediator que determina el conector que debe gestionar el mensaje, utilizando para ello el identificador de la conversación contenido en el mensaje. Todos los mensajes intercambiados durante una interacción comparten el mismo identificador de conversación. Cuando este componente recibe el primer mensaje de una conversación es también el encargado de crear el conector que la controlará. Por tanto, en este caso, estos mensajes son enviados al conector encargado de gestionar la interacción (conector proxy). Este protocolo se encarga de enviar el mensaje enviado por un agente Provider al agente Trader correspondiente que se comunica a través de otra plataforma de agentes. Por tanto se enviará un mensaje al agente Trader a través del adaptador FIPAVendor1 que utiliza los servicios de la plataforma FIPA1Vendor. Esta correspondencia se estableció al inicio del servicio en el agente Proxy. De igual forma, los mensajes enviados por el agente Trader se enviarán al agente Provider (como consecuencia de la gestión del conector) a través de la plataforma FIPA2Vendor. CONCLUSIONES El objetivo de FIPA es estandarizar especificaciones que permitan la comunicación entre agentes software heterogéneos. Sin embargo, FIPA no proporciona una especificación única y obligatoria, sino que ofrece varias opciones entre las que elegir. Dejar abiertas las posibilidades y no cerrar el conjunto de especificaciones propuestas por FIPA tiene dos consecuencias: Por un lado permite que FIPA, y por tanto las plataformas de agentes, incorporen y adopten fácil y rápidamente nuevas tecnologías; pero por otro lado, entorpece el proceso de adopción de FIPA por parte de las plataformas de agentes, ya que deja a los desarrolladores un gran número de aspectos sin definir específicamente y que no garantizan la buscada interoperabilidad entre plataformas. Si se toman diferentes opciones y suposiciones, a pesar de seguir la directrices dadas por FIPA, la interoperabilidad a través de plataformas se ve comprometida y por tanto también se reduce la reutilización de agentes software ya desarrollados en aplicaciones que impliquen distintas plataformas. En este trabajo presentamos una arquitectura composicional de agentes software que proporciona una infraestructura para construir agentes a partir de componentes software reutilizables. Esta arquitectura combina componentes y separación de aspectos y separa en entidades distintas la funcionalidad, la coordinación del agente, y la distribución

9 de mensajes. En este artículo presentamos las ventajas que supone separar la distribución de mensajes de la funcionalidad y la coordinación del agente dentro de una aplicación, lo que nos ayuda a proporcionar una solución intermedia para solventar aquellas diferencias que dificultan la interoperabilidad entre plataformas de agentes FIPA. En otras plataformas de agentes, las arquitecturas internas del agente consisten en un conjunto de componentes y subsistemas fuertemente acoplados. Estas interdependencias son las que dificultan la extensión del agente para soportar, por ejemplo, el uso de otra plataforma de agentes. Sin embargo, nuestra propuesta consigue evitar esta dependencias separando la interacción con las plataformas de agentes de la funcionalidad y coordinación del agente dentro de una aplicación. Esta independencia favorece el desarrollo de agentes y su reutilización en aplicaciones heterogéneas independientemente de la plataforma sobre la que ha sido desarrollado. En el caso dado como ejemplo esta flexibilidad nos permite construir agentes que operan a la vez sobre distintas plataformas de agentes y que han servido como representantes de agentes en plataformas distintas a la propietaria. Para situar nuestra propuesta en un escenario que muestre su adecuación hemos descrito una situación en la que es necesario comunicar agentes de diferentes plataformas no interoperables. Aunque la propuesta conlleva la creación de dos nuevos agentes, hemos mostrado que el desarrollo de agentes sobre la arquitectura composicional propuesta requiere la descripción en un documento de despliegue de la composición inicial del agente detallando la funcionalidad, los protocolos de coordinación y los mecanismos de comunicación disponibles para la interacción con otros agentes. La arquitectura composicional propuesta permite adaptar el agente a nuevos requisitos y modificar su configuración en tiempo de ejecución sin que se vean afectados el resto de los componentes e incluso la actividad en curso del agente, ya que cada conversación es coordinada por conectores independientes. El agente que permite la comunicación entre agentes que pertenecen a plataformas no interoperables se encarga de reenviar mensajes a cada uno de los agentes a través de la plataforma adecuada. Esta solución no conlleva modificar ninguna de las dos plataformas implicadas en la aplicación, ni tampoco loa agentes que forman parte de la aplicación que y deseamos reutilizar a pesar de pertenecer a plataformas distintas y no interoperables, sino que propone la incorporación de un nuevo agente que llevará a cabo la comunicación entre los agentes pertenecientes a la aplicación de comercio electrónico original. Otra puntualización que deseamos realizar es que aunque en este caso ambos agentes, comprador y vendedor, comparten el mismo protocolo de interacción, y que la única incompatibilidad radica en que no pueden comunicarse por la incompatibilidad de las plataformas de agentes, esta solución también permitiría la comunicación entre agentes que no compartan el protocolo de comunicación, ya que el agente representante se encargaría de adaptar los mensajes entre agentes al protocolo correspondiente. Actualmente nuestro agente software, implementado en Java, es capaz de utilizar los servicios ofrecidos por las plataformas de agentes Jade, FIPA-OS y Zeus. REFERENCIAS [1] F. Bergenti and A. Poggi A development Toolkit to Realize Autonomous and Interoperable Agents. Proceedings of Agents 01, Canada, June [2] Foundation for Intelligent Physical Agents. [3] Emorphia, FIPA-OS. [4] TILAB, Java Agent Development Framework. [5] BtexaCT, The Zeus Agent Building Toolkit. [6] Aspect-Oriented Software Development. [7] Foundation for Intelligent Physical Agents, FIPA Abstract Architecture Specification [8] Foundation for Intelligent Physical Agents, FIPA Agent Management Specification rg/specs/fipa00023/ [9] Foundation for Intelligent Physical Agents, FIPA Agent Communication Language [10] Agentcities Network Services. [11] M. Amor, L. Fuentes, J.M. Troya, Training Compositional Agents in Negotiation Protocols. Next publication in the Integrated Computer-Aided Engineering International Journal. [12] M. Amor, L. Fuentes, J.M. Troya, Putting Together Web Services and Compositional Software Agents. Third International Conference on Web Engineering, LNCS 2722 pp Springer-Verlag, [13] DARPA. DAML-S.