Un Marco de Comunicación Inter-Agentes en una Biblioteca Digital  

Este trabajo ha sido financiado parcialmente por el centro de Bioinformática del Jardín Botánico de Missouri, a través de un convenio de colaboración con el Laboratorio de Tecnologías Interactivas y Cooperativas de la Universidad de las Américas-Puebla.

Los derechos de este material son propiedad del Jardín Botánico de Missouri y de la Universidad de las Américas-Puebla


Índice de contenido


  Índice de figuras

Figura 1. Taxonomía de agentes

Figura 2. Componentes en la interacción entre agentes

Figura 3. Sistema federado

Figura 4. Arquitectura de CORBA

Figura 5. Elementos de la arquitectura de la FDL que participan en la comunicación

Figura 6. Relación de MICK con los elementos que participan en la comunicación

Figura 7. Implementación de MICK

Figura 8. Interfaz principal del director de agentes de usuario

Figura 9. Ventana con la información de una instancia de agente

Figura 10. Forma para la captura de datos de un nuevo agente

 


 Índice de tablas

Tabla 1. Protocolo de comunicación entre el UAD y los agentes de usuario

Tabla 2. Protocolo de comunicación entre el UAD y ALiS

Tabla 3. Protocolo de comunicación entre el UAM y ALiS


  Sinopsis

Este proyecto de tesis se enfoca a resolver el problema de la comunicación entre los componentes de una biblioteca digital altamente distribuida. Específicamente, se consideró la arquitectura de la Biblioteca Digital Florística (FDL), la cual tiene una orientación hacia servicios a usuarios, incluyendo servicios de agentes. En este contexto, sobresalen los problemas de comunicación entre un director de agentes (una interfaz que permite controlar a los agentes) y los agentes de usuario y entre el mismo director de agentes y los servicios de biblioteca activa.

Para solucionar dicho problema se diseñó un marco de inter-comunicación formado por un lenguaje de comunicación entre agentes (KQML), un protocolo de comunicación definido en términos del lenguaje, un vocabulario de palabras, un ruteador de mensajes KQML y un facilitador que funciona como el mediador en una arquitectura por coordinación asistida para sistemas multiagentes.

La solución se implementó en Java, utilizando a un conjunto de paquetes también en Java (JATLite) como implementación de KQML. Se crearon ruteadores de mensajes que satisfacen las necesidades de comunicación de los agentes de usuario, del director de agentes y de los servicios de biblioteca activa. También se implementó un facilitador que coordina la comunicación y la mantiene robusta. Adicionalmente se desarrolló una nueva versión del director de agentes, también en Java, que utiliza el marco de intercomunicación y permite desde una misma interfaz controlar a los agentes de usuario y crear nuevos agentes.  


Capítulo 1

Introducción

Las bibliotecas digitales surgen como un ambicioso proyecto para organizar el abundante cúmulo de datos y la diversidad de medios que ofrece actualmente la tecnología de la información. Como sistema de información, las bibliotecas digitales pueden estar entre los más complejos y avanzados, puesto que frecuentemente incluyen soporte colaborativo, preservación de documentos digitales, administración de base de datos distribuidas, hipertexto, filtración de información, módulos de instrucción, administración de derechos de propiedad intelectual, servicios de información multimedia, servicios de referencia, descubrimiento de recursos y diseminación selectiva de información. En este esfuerzo, los métodos de Interacción Humano-Computadora para manejar la información son de particular importancia para ayudar eficazmente a los usuarios a realizar búsquedas, organizar, utilizar y aprender sobre el vasto repositorio de datos que se encuentra en las bibliotecas digitales [Fox et al. 1995; Fox y Marchionini 1998]. En este contexto las interfaces de usuario basadas en agentes se han propuesto como un medio que permite simplificar el diálogo entre el sistema y el usuario, automatizar tareas, manejar información compleja y dinámica y utilizar eficientemente los recursos. Este proyecto de tesis se aboca a la comunicación entre componentes de una biblioteca digital y este tipo de agentes con el objeto de maximizar las oportunidades de cooperación y minimizar las posibilidades de interferencia entre ellos.

1.1 Agentes

Las tendencias actuales hacen evidente que la complejidad del software continuará incrementándose dramáticamente en los próximos años. La naturaleza distribuida y dinámica de los datos y las aplicaciones requieren que el software no sólo responda a las solicitudes de información de los usuarios, sino que se anticipe, adapte y busque activamente maneras de darles soporte. Los sistemas no sólo deben ayudar a los humanos a coordinar sus actividades, sino que también deben ayudar a administrar la cooperación entre sistemas distribuidos. Como resultado de estas necesidades los agentes surgen como un área de rápido desarrollo donde se intersectan un gran número de disciplinas tan diversas como Interacción Humano-Computadora, Ingeniería de Software, Redes, Sociología e Inteligencia Artificial.

El término agente se ha vuelto muy popular en la industria de software y se ha dado un sobreuso de éste debido a la falta de consenso para definirlo. A pesar de esto, existen algunas propiedades que comúnmente se asocian con el concepto de agente, estas son: autonomía, sociabilidad, cooperación, reactividad, proactividad (con comportamiento dirigido por una meta y tomando la iniciativa), continuidad temporal (son procesos que están ejecutándose continuamente), adaptabilidad y la propiedad de ser personalizables [Chauhan 1998]. Esta tesis se enfoca especialmente a la sociabilidad, entendiéndose ésta como la habilidad de un agente de interactuar, cooperar y colaborar con otros agentes. La definición del término agente que se adopta es la dada por Sánchez [1996], quien considera que un agente en general es cualquier entidad autónoma o semiautónoma que desempeña una misión bien definida.

Existe un gran número de actividades donde es posible aplicar la tecnología de agentes, entre éstas están las interfaces de usuario, las telecomunicaciones, la administración de redes, el comercio electrónico y la recolección de información [Sánchez 1996]. Ejemplos de misiones que pueden ser delegadas a los agentes son la filtración de mensajes de correo electrónico o de información de acuerdo a las preferencias del usuario, el manejo de procedimientos de administración rutinaria y la negociación con otros usuarios o sus agentes para fijar horas de reunión. Incluso, algunas personas como Guilfoyle [1995] predicen que en 10 años la mayoría de los desarrollos en software se verán afectados y contendrán sistemas basados en agentes.

Una clasificación de agentes útil en el contexto de esta tesis es la que se propone en [Sánchez 1997] y en [Sánchez y Legget 1997] donde los dividen en agentes de programación, agentes de red y agentes de usuario. Los agentes de programación son abstracciones creadas en beneficio del programador que permiten conceptualizar, diseñar e implementar sistemas complejos donde se enfatiza el modelado de los procesos desempeñados por la computadora. Los agentes de red son entidades autónomas que viajan por la red, se instalan en algún nodo y utilizan sus recursos en beneficio del nodo que los envió. Finalmente, los agentes de usuario son abstracciones para que los usuarios finales interactúen con los sistemas. Estos últimos se subdividen en agentes de información, agentes de tareas y agentes sintéticos.

Los agentes de información ayudan a los usuarios a tratar con grandes espacios de información complejos y dinámicos. Los agentes de tareas se ejecutan concurrentemente con la aplicación del usuario, observan la actividad del usuario y ofrecen automatizar ciertas tareas. Los agentes sintéticos crean ambientes donde se introducen caracteres animados en la interfaz. Esta clasificación se resume en la Figura 1.

Figura 1. Taxonomía de agentes (adaptada de Sánchez [1997]).

1.2 Interacción entre agentes.

La habilidad de interactuar, esto es, de intercambiar información y conocimiento que sea mutuamente entendido es evidentemente deseable e importante para los agentes. Algunos autores como Genesereth y Ketchpel [1994] incluso afirman que no se puede llamar agente a una entidad que no se comunique correctamente en un lenguaje de comunicación de agentes. Simplemente, la idea de entidades aisladas no corresponde con la visión presente de un universo interconectado y descentralizado.

La interacción entre agentes de los llamados "de usuario" es particularmente útil e importante, ya que contribuye a dar solución a dos problemas que se presentan comúnmente en agentes de este tipo: 1) Dado que estos agentes van aprendiendo al observar al usuario, se requiere una cantidad de ejemplos considerable antes de que puedan ser realmente útiles y de que sus predicciones acerca del comportamiento del usuario sean acertadas, y 2) el agente está limitado a lo que pueda aprender de su usuario. Si se comparte la experiencia adquirida por los agentes de usuario, el tiempo requerido para que un agente alcance un nivel de utilidad aceptable disminuiría, además de que el agente puede aprovechar la experiencia y el conocimiento adquirido por otro usuario a través de su agente en situaciones de las que no se tiene antecedente [Lashkari et al. 1994].

La autonomía que caracteriza a los agentes no implica un total aislamiento, por el contrario, crea la posibilidad de una interacción entre ellos mucho más compleja y rica de la que se puede dar en un sistema distribuido tradicional en donde los mensajes que se intercambian no siguen una sintaxis y su semántica es variable. Esta interacción puede ser modelada en base a dos paradigmas distintos. El primer paradigma establece que la competencia emerge de un gran número de agentes relativamente simples integrados por una arquitectura inteligente. El segundo paradigma se basa en la idea de que la competencia surge de sistemas que procesan una gran cantidad de conocimiento útil, donde la arquitectura no es tan importante [Guha y Lenat 1994].

Al igual que en la interacción entre personas, la interacción entre agentes necesita más que un lenguaje común para lograr que ésta sea efectiva. Se requiere en general de tres componentes fundamentales: un lenguaje común, un entendimiento mutuo del conocimiento que se intercambia y la habilidad de intercambiar conocimiento en el lenguaje común.

1.3 Alcances del proyecto.

Este proyecto es parte del esfuerzo por construir una biblioteca florística digital (FDL) que incluya las floras de China, de Mesoamérica y de Norteamérica. Esta biblioteca digital consistirá de una colección distribuida de documentos en una variedad de medios y formatos incluyendo texto, mapas e ilustraciones y ofrecerá un amplio rango de servicios que podrán ser accesados en cualquier lugar de la red global.

En este proyecto se define el marco que permite que los agentes de usuario que están siendo desarrollados para la biblioteca florística digital interactúen con los componentes de la biblioteca digital. Para lograr esto es necesario definir la arquitectura que los organice, establecer el lenguaje en el que se van a comunicar y definir un protocolo de comunicación.

1.4 Organización del documento

Los capítulos restantes de este documento se organizan como sigue: en el capítulo 2 se presenta la información relevante para este proyecto encontrada durante la revisión bibliográfica, en el capítulo 3 se presenta el diseño conceptual de la solución al problema planteado, en el capítulo 4 se describe a detalle una implementación prototípica de la solución, en el capítulo 5 se evalúa el prototipo y finalmente las conclusiones se presentan en el capítulo 6.  


Capítulo 2

Comunicación en sistemas multiagentes y bibliotecas digitales

Autores como Mayfiled, Labrou y Finin [1995] proponen una arquitectura basada en agentes inteligentes como solución a los problemas que surgen con los ambientes distribuidos, heterogéneos y dinámicos que existen actualmente. Los problemas a los que se refieren son la restrictividad del modelo cliente servidor, la necesidad de interoperatividad real y la falta de herramientas y técnicas para la construcción de clientes y servidores inteligentes o para la construcción de software basado en agentes. Los mismos autores resaltan que una habilidad importante para poder considerar a estos agentes como inteligentes es la habilidad de comunicarse con otros agentes usando un lenguaje de comunicación.

En este capítulo 2 se presenta la revisión bibliográfica, que incluye la identificación de los elementos que se requieren en la comunicación entre agentes, los mecanismos o formas de organizar a los agentes para lograr la comunicación, los lenguajes de comunicación entre agentes, un lenguaje de comunicación en especial conocido como ACL, una arquitectura estándar orientada a objetos para apoyar la interoperación entre componentes de bibliotecas digitales y finalmente una descripción de trabajos realizados en otras bibliotecas digitales sobre el mismo tema de la comunicación.

2.1 Requerimientos

Un agente que interactúe con otros agentes requiere tener una serie de componentes que pueden agruparse en componentes de representación, componentes de comunicación y componentes no relacionados directamente con el entendimiento compartido.

Los componentes de representación incluyen las ontologías (un marco compartido de conocimiento, es decir, vocabularios estructurados que comparten los interlocutores) y las bases de conocimiento. Estos componentes tratan de resolver el problema del entendimiento mutuo, el cual se puede dividir en dos subproblemas: la traducción de un lenguaje de representación a otro y el compartimiento entre diferentes agentes del contenido semántico del conocimiento representado.

Los componentes de comunicación comprenden un protocolo de transporte, un lenguaje común y un protocolo de interacción. El protocolo de transporte se refiere al mecanismo de transporte usado para la comunicación (por ejemplo TCP, SMTP, HTTP, etc.). El lenguaje de comunicación es el medio por el cual las actitudes acerca del contenido del intercambio se comunican, es decir, por el lenguaje se sabe si el contenido de la comunicación es una aseveración, una pregunta o una solicitud. El protocolo de interacción se refiere a la estrategia que sigue el agente para interactuar con otros agentes, la cual puede ir desde esquemas de negociación y protocolos basados en teoría de juegos hasta protocolos muy simples en los que cada vez que el agente no sabe algo busca alguien que sepa y le pregunta [Finin et al. 1995].

Existen componentes en la interacción que no se relacionan directamente con el entendimiento compartido, pero que pueden estar presentes para mejorar las capacidades del agente y ayudarlo a desempeñar su tarea. Algunos componentes de este tipo son la habilidad de razonar sobre sus propias acciones, la capacidad de representar meta-conocimiento, la habilidad de planear actividades y la de modelar otros agentes. Estos componentes son periféricos a la base de conocimiento, aunque normalmente se construyen en base a ésta. Todos los componentes anteriormente descritos se ilustran en la Figura 2.

Figura 2. Componentes en la interacción entre agentes (adaptada de Finin et al. [1995]).

2.2 Arquitecturas de sistemas multiagentes

La forma en que se comunican los agentes depende en gran medida de la manera de organizarlos. Se han explorado y experimentado con dos formas de organización de agentes. Una es mediante comunicación directa y la otra es por coordinación asistida.

2.2.1 Comunicación directa

Una organización de agentes por comunicación directa se caracteriza por agentes que manejan su propia coordinación, la cual tiene la ventaja de que no depende de otros programas y la desventaja de que aumenta el grado de complejidad en la implementación de cada agente. Dentro de esta forma de organización existen dos arquitecturas que son la de red de contratos y la de especificación compartida.

En la arquitectura de red de contratos, los agentes cuando necesitan algún servicio distribuyen solicitudes a diferentes agentes. Los receptores de estas solicitudes las evalúan y lanzan ofertas, las cuales son usadas por los agentes solicitantes para decidir con que agente realizar un contrato. Esta arquitectura es evidentemente costosa por la cantidad de mensajes que se requieren enviar.

En la arquitectura de especificación compartida los agentes no hacen solicitudes de servicio sino que proveen de información a otros agentes acerca de sus capacidades y necesidades y cuando surge la necesidad de un servicio esta información es utilizada por los agentes para coordinar sus actividades. El número de mensajes que se intercambian se reduce considerablemente en comparación con la arquitectura anterior, lo que la hace una arquitectura más eficiente.

2.2.2 Coordinación asistida

Otra forma de organizar a los agentes es mediante la coordinación asistida y un ejemplo bastante popular de este tipo de organización es la arquitectura conocida como sistema federado, en donde en lugar de que los agentes se comuniquen directamente, lo hacen por medio de facilitadores. En esta arquitectura los agentes generalmente utilizan ACL (Agent Communication Language) para comunicar sus necesidades y habilidades a su facilitador local, quien se encarga de encontrar la ruta correcta por la cual hacer llegar solicitudes a otros facilitadores, quienes a su vez pasan las solicitudes a alguno de los agentes de su dominio que pueda satisfacer la solicitud [Genesereth y Ketchpel 1994].

Una característica importante de la arquitectura de federación es que soporta la interacción anónima entre los agentes a cambio de que éstos cedan algo de su autonomía al facilitador y de que se apeguen a condiciones adicionales. Para cada agente debe parecer que existe sólo un agente que maneja todas sus solicitudes directamente [Genesereth et al. 1994]. Una representación gráfica de esta arquitectura se presenta en la Figura 3.

Los servicios que el facilitador provee son los siguientes:

Figura 3. Sistema federado (adaptado de Genesereth y Ketchpel [1994]).

2.3 Lenguajes de comunicación entre agentes

El uso de un lenguaje de comunicación común facilita la creación de software interoperable porque permite disociar la implementación de la interfaz, esto es, siempre que un grupo de programas se apegue a un lenguaje de comunicación estándar, estos pueden interoperar independientemente del lenguaje en el que fueron implementados. Para diseñar estos lenguajes existen dos métodos a seguir: el método procedural y el declarativo.

El método procedural se basa en la idea de que la comunicación se puede modelar más adecuadamente como un intercambio de directivas. De esta manera se pueden transmitir no sólo comandos sino también programas enteros. Usualmente su ejecución es eficiente y directa. Las desventajas principales con este método son el requerimiento de información sobre el receptor del mensaje, la cual no siempre está disponible, y el carácter unidireccional del procedimiento, cuando la mayoría de las veces es conveniente que los agentes compartan información.

El método declarativo por el contrario, establece que la comunicación se modela de forma más adecuada utilizando enunciados declarativos. Este método para ser útil requiere que el lenguaje sea lo suficientemente expresivo como para comunicar diferentes clases de información incluyendo procedimientos, que sea compacto y que no se requiera que el vocabulario crezca demasiado para seguir manteniendo la comunicación. Un ejemplo de este tipo de lenguaje es ACL, un lenguaje desarrollado por ARPA [Genesereth y Ketchpel 1994].

2.4 ACL

Como resultado del esfuerzo por crear un lenguaje que permitiera la interoperación entre agentes autónomos distribuidos surgió el lenguaje llamado ACL (Agent Communication Language). ACL tiene tres componentes: un vocabulario, un lenguaje de contenido llamado KIF (Knowledge Interchange Format) y un lenguaje de comunicación llamado KQML (Knowledge Query Manipulation Language). Un mensaje de ACL es un mensaje en KQML que consiste de una directiva de comunicación y un contenido semántico en KIF expresado en términos del vocabulario.

2.4.1 Vocabulario

El vocabulario de ACL es un diccionario de palabras apropiado para áreas comunes de aplicación. Cada palabra en el diccionario tiene una descripción que es usada por las personas para entender su significado y una anotación formal (escrita en KIF) que es usada por los programas. El diccionario es abierto, es decir, es posible añadir nuevas palabras dentro de áreas existentes y en nuevas áreas de aplicación.

La existencia de este diccionario no significa que solamente hay una manera de describir una área de aplicación. Un diccionario puede contener múltiples ontologías para una área dada y un agente puede utilizar la ontología que le sea más conveniente. Las definiciones formales asociadas con cualquiera de estas ontologías pueden ser usadas por los agentes para traducir mensajes que usan una ontología en específico a mensajes que usan otras ontologías [Genesereth y Ketchpel 1994].

Cuando se comparte información en una comunidad se debe tener un acuerdo sobre el significado de los símbolos. Si esta comunidad es pequeña es posible que un vocabulario único sea utilizado por todos los objetos que se comunican. Sin embargo, si la comunidad es extensa, es muy posible que sea necesario soportar una colección de vocabularios [Singh y Gisi 1995].

2.4.2 KIF

KIF es una versión en prefijo del cálculo de predicados de primer orden con varias extensiones para incrementar su expresividad.

Este formato para intercambio de conocimiento permite primeramente expresar datos simples. Por ejemplo, las siguientes oraciones codifican dos tuplas en una base de datos personal. El primer argumento es el número de seguro social, el segundo es el departamento en el que la persona trabaja y el tercero es el salario de la persona:

(salario 016-46-3946 compras 7200)

(salario 415-32-4707 desarrollo técnico 4800)

Se puede expresar información más complicada mediante el uso de términos complejos. Por ejemplo, la siguiente oración afirma que una pieza es más grande que la otra:

( > (*(ancho pieza1) (largo pieza1) ) (*(ancho pieza2) (largo pieza2) ) )

KIF incluye una variedad de operadores lógicos para ayudar a codificar información lógica (esto es, negaciones, disyunciones, reglas, cuantificadores, etc.). La siguiente es una oración compleja en KIF que quiere decir que cualquier número x elevado a la n es positivo si x es real y n es par.

(<= (> (expt ?x ?n ) 0 ) ( número-real ?x) (número-par ?n) )

Una de las características que distinguen a KIF es su habilidad de codificar conocimiento acerca del conocimiento, usando los operadores ? y , y un vocabulario relacionado. Por ejemplo, la siguiente oración afirma que el agente joe puede manejar solicitudes de información sobre salario. El uso de comas señala que las variables no se deben tomar literalmente. Sin las comas, esta oración diría que joe sólo puede manejar la oración (salario ?x ?y ?z) en lugar de sus instancias.

( maneja joe ?(salario ,?x ,?y ,?z) )

KIF también puede ser usado para describir procedimientos, esto es, escribir programas para agentes. Dada la sintaxis en prefijo de KIF, tales programas se parecen a Lisp o Scheme. El siguiente es un ejemplo de un procedimiento de tres instrucciones escrito en KIF.

( secuencia ( fresh-line t) (print "¡Hola!") (fresh-line t) )

La semántica del KIF básico (KIF sin reglas ni definiciones) es similar a la de la lógica de primer orden. Existen extensiones para manejar operadores que no son estándar y una restricción a modelos que satisfacen algunos axiomas. A pesar de estas extensiones y restricciones el lenguaje conserva las características fundamentales de la lógica de primer orden.

KIF define un conjunto de objetos, funciones y relaciones cuyo significado es fijo, por ejemplo, números y funciones aritméticas. Sin embargo, es importante notar que KIF es abierto, es decir, los usuarios tienen la libertad de definir significados de cualquier otro símbolo que no esté predefinido.

2.4.3 KQML

Aunque es posible diseñar un marco de trabajo completo para la comunicación en el que todos los mensajes tengan la forma de oraciones en KIF, esto sería ineficiente, ya que se requeriría incluir información implícita sobre el agente que envía el mensaje y sobre el que lo recibe, debido a que la semántica de KIF es independiente del contexto. La comunicación se hace más eficiente si se provee una capa lingüística en la que el contexto se toma en cuenta. Esta es la función de KQML [Genesereth y Ketchpel 1994].

KQML es un lenguaje basado en la teoría de actos del habla, la cual es comúnmente usada en los sistemas multiagentes como método para construir una capa lingüística y formalizar las acciones lingüísticas de los agentes. La teoría de actos del habla ha contribuido en gran medida al entendimiento de la relación entre el estado interno de un agente y las expresiones que intercambia con otros agentes. La teoría se basa en la observación de que las oraciones expresadas por humanos durante la comunicación no siempre aseveran un hecho, sino que en realidad tratan de transmitir una creencia o conocimiento, una intención o un deseo. [Haddadi 1996].

KQML fue concebido como un formato de mensajes y como un protocolo que maneja los mensajes para permitir a un programa identificar, conectarse e intercambiar información con otros programas. En términos lingüísticos se puede decir que KQML se enfoca principalmente a la parte pragmática de la comunicación. De acuerdo a Finin, Labrou y Mayfield [1995] tres características importantes de KQML son:

  1. Los mensajes de KQML son opacos al contenido de lo que transportan, esto es, los mensajes en KQML no comunican únicamente oraciones en un lenguaje, sino que comunican una actitud acerca del contenido (por ejemplo, afirmación, solicitud, pregunta).
  2. Las primitivas del lenguaje se llaman performativas, las cuales indican las acciones u operaciones permitidas que los agentes pueden utilizar cuando se comunican.
  3. Un ambiente en el que los agentes se comunican con KQML puede ser enriquecido con un tipo de agentes especiales llamados facilitadores (descritos en la sección 2.2.2).

KQML se divide en tres capas: la capa de contenido, la capa de mensaje y la capa de comunicación. La capa de contenido se relaciona con el contenido real del mensaje escrito en el lenguaje de representación propio de cada agente. Un mensaje en KQML puede tener cualquier lenguaje de representación incluyendo lenguajes expresados como cadenas en ASCII y aquellos expresados utilizando una notación binaria. Cualquier implementación de KQML ignora la parte del contenido del mensaje excepto para determinar donde termina.

La capa de comunicación codifica un conjunto de características del mensaje, las cuales describen los parámetros de bajo nivel en la comunicación, tales como la identidad del agente que envía el mensaje y del que lo recibe y un identificador asociado con la comunicación.

La capa de mensaje se utiliza para codificar el mensaje que una aplicación desea transmitir a otra. Esta capa forma el corazón del lenguaje y determina las clases de interacciones que se pueden tener con un agente que "hable" KQML. La función primaria de la capa de mensaje es identificar el protocolo que se va a usar para entregar el mensaje (síncrono o asíncrono) y proveer un acto del habla o performativa que el transmisor le agrega al contenido. Además de esto, ya que el contenido es opaco a KQML, en esta capa también se incluyen características opcionales que describen el lenguaje del contenido, la ontología que se está asumiendo y alguna clase de descripción del contenido. Estas características hacen posible que las implementaciones de KQML analicen, ruteen y entreguen el mensaje apropiadamente aún cuando su contenido sea inaccesible.

Todo mensaje en KQML inicia con una performativa que como ya se ha dicho indica la intención del mensaje o el acto del habla. Existe un conjunto de performativas estándar con un significado al que toda implementación de KQML debe apegarse. Labrou y Finin [1996] dividen estas performativas estándar en tres grupos: 1) las performativas de discurso (ask-if, ask-all, ask-one, tell, deny, achieve, advertise, subscribe, entre otras), empleadas en el contexto de un intercambio de información y conocimiento entre dos agentes, 2) las performativas de intervención y mecánicas de la conversación (error, sorry, ready, next, discard, rest, standby), cuyo papel es intervenir en el curso normal de una conversación y 3) performativas de red y de facilitación (register, forward, broadcast, recommend-one, recruit-all, entre otras), los cuales, estrictamente hablando no son actos del habla, pero permiten a los agentes encontrar otros agentes capaces de procesar sus mensajes.

El siguiente es un ejemplo de un mensaje KQML donde un agente que se identifica como U solicita a un facilitador que envíe un mensaje proveniente del mismo U y escrito en kqml a otro agente A, asumiendo la ontología ontología-fdl. A su vez el mensaje que U quiere hacer llegar a A a través de facilitador indica que U desea que A haga cierto en su ambiente lo que esta en el contenido del mensaje (estado=suspendido) y que le responda con un mensaje identificado por id1.

(forward

2.5 Common Object Request Broker Architecture (CORBA)

A pesar de que KQML se plantea como una solución al problema de la comunicación entre agentes, se requieren infraestructuras estándares de más bajo nivel para lograr la coordinación y la interoperabilidad real entre aplicaciones en forma más global y robusta. Con esta motivación y con el objetivo de simplificar el desarrollo de aplicaciones distribuidas y de proveer bases flexibles para servicios de más alto nivel, se crea CORBA.

CORBA es una especificación para una arquitectura estándar orientada a objetos para aplicaciones. Es el producto de un consorcio llamado OMG (Object Management Group) que agrupa a más de 650 compañías de hardware, software, bancos, de telefonía, etc., cuya misión es definir interfaces para software interfuncional usando una tecnología orientada a objetos. La importancia de CORBA radica en que utiliza a los objetos como una metáfora de unificación para lograr poner todas las aplicaciones existentes (que pueden haber sido creadas con diferentes lenguajes y trabajar en diferentes plataformas) dentro de un mismo canal y así permitir una interoperatividad [Otte et al. 1996].

2.5.1 Arquitectura de CORBA

Los principales elementos que componen a CORBA (véase Figura 4) son los servicios comunes de objetos, las facilidades comunes, las aplicaciones y los dominios de aplicación, unidos éstos por interfaces a un ORB (Object Request Broker).

Figura 4. Arquitectura de CORBA (adaptado de Mowbray y Malveau [1997]).

El ORB es la parte medular de la arquitectura. Es la infraestructura de comunicación entre clientes y servidores por el que los objetos hacen peticiones y reciben respuestas. Específicamente, el ORB es responsable de recibir peticiones de objetos, encontrar el objeto (local o remoto) que las implemente, prepararlo y comunicar los datos en la petición. El ORB provee una serie de beneficios entre los cuales están:

Los servicios comunes de objetos son independientes del dominio y son usados por muchos programas distribuidos. Incluyen, entre otros, la creación y borrado de objetos, la búsqueda de otros servicios disponibles, el almacenamiento persistente de objetos, el control de concurrencia, transacciones, nombramiento de objetos y servicios de seguridad.

Las facilidades comunes son servicios que pueden usar directamente los usuarios finales. Estos servicios incluyen normalmente la presentación e intercambio de objetos basado en un modelo de documento (por ejemplo facilitar el ligado de un objeto de tipo hoja de cálculo a un documento de tipo reporte), accesos a bases de datos e impresión de archivos.

Los dominios de aplicación tienen roles similares a los de los dos elementos anteriores con la diferencia de que están orientados a dominios de aplicación específicos (por ejemplo el dominio financiero, el dominio de las telecomunicaciones, etc.).

Las interfaces para aplicaciones, son precisamente para aplicaciones específicas dadas y debido a que la OMG no desarrolla aplicaciones (sólo especificaciones), estas interfaces no están estandarizadas.

2.5.2 Interface Definition Language (IDL)

IDL es un lenguaje declarativo para definir las interfaces que unen a los componentes de la arquitectura CORBA. Estas interfaces son independientes de los lenguajes de programación y de los sistemas operativos e incluyen constantes, declaraciones de tipos, excepciones, atributos y operaciones.

De una interfaz escrita en IDL se generan mediante un compilador un esqueleto de código para el cliente, un esqueleto de código para el servidor y un archivo de encabezado. Esto significa, por ejemplo, que para que dos aplicaciones, una escrita en Java y otra escrita en C++, puedan interoperar es necesario que se defina la interfaz en IDL y que se cuente con un traductor de IDL a Java y de IDL a C++.

2.5.3 CORBA en la comunicación entre agentes

El método de interoperación de software basado en agentes frecuentemente se compara con la programación orientada a objetos. Al igual que un objeto, un agente proporciona una interfaz basada en mensajes independiente de sus estructuras de datos internas y algoritmos. La diferencia entre estas dos maneras de lograr interoperatividad y comunicación radica en que el significado de los mensajes pueden variar de un objeto a otro en la programación orientada a objetos, mientras que en una interoperación basada en agentes se utiliza un lenguaje común con semánticas que son independientes del agente [Genesereth et al. 1994]. Una diferencia más la hace notar FIPA [1997] al decir que los agentes se comunican a un nivel más alto de discurso, esto es que los contenidos de la comunicación son oraciones significativas sobre el ambiente o conocimiento del agente, mientras que con CORBA las interacciones se dan como invocación de métodos entre entidades computacionales fuertemente encapsuladas.

CORBA, al igual que DCOM (Distributed Component Object Model de Microsoft), se proponen en ocasiones como solución al problema de la comunicación entre agentes. Sin embargo, Mayfield [1995] los ubica como una tecnología de agentes dentro de la categoría de protocolos de coordinación y establece que estas tecnologías serán útiles en el desarrollo de agentes, pero que no proporcionan respuestas completas al problema de la comunicación entre agentes debido a que éstos no son únicamente conjuntos de estructuras de datos y métodos. Mayfield considera que estos estándares y protocolos pueden ser substratos sobre los que se pueden construir lenguajes de agentes.

2.6 Comunicación en bibliotecas digitales

Una vez vistos en las secciones anteriores los planteamientos de solución para el problema de la comunicación entre agentes, en esta sección se presentan soluciones en desarrollo al problema de la comunicación en dos de los seis proyectos pertenecientes a la DLI (Digital Library Initiative), iniciativa en Estados Unidos que comenzó en 1994 con un apoyo económico de 24 millones de dólares para 4 años. Estos dos proyectos son el de la biblioteca digital de la universidad de Michigan y el de la biblioteca digital de Stanford. Adicionalmente se incluyen los conceptos precursores planteados en un sistema de biblioteca digital. (DLS)

2.6.1 La biblioteca digital de la universidad de Michigan

La UMDL (University of Michigan Digital Library) adoptó una arquitectura basada en agentes, bajo el argumento de que la tecnología para las bibliotecas digitales está cambiando constantemente, por lo que las interfaces de usuario, las máquinas de búsqueda y la estructura de las fuentes de información se deben adaptar a innovaciones futuras. Más que adoptar estándares específicos, la arquitectura de la UMDL desarrolla operaciones genéricas de administración tales como asignar recursos y mediar conexiones. En esta arquitectura cada agente desarrolla una tarea bibliotecaria altamente especializada y tiene una interfaz de comunicación genérica [Atkins et al. 1996].

Cabe anotar que aunque se han publicado aspectos del diseño y algunos desarrollos iniciales, gran parte de los componentes descritos en esta sección aún no se implementan.

Tipos de agentes

Los agentes en esta arquitectura son de tres tipos: agentes de interfaz de usuario, agentes mediadores y agentes de interfaz a colección. Los agentes de interfaz de usuario (AIU) administran la interfaz que conecta los usuarios humanos con los recursos de la biblioteca. Entre otras cosas, los AIUs, a veces con ayuda de otros agentes, expresan las peticiones del usuario de manera que los agentes mediadores puedan interpretarlas, mantienen archivos de preferencias del usuario, personalizan la presentación de resultados y administran los recursos disponibles del usuario.

Los agentes mediadores proveen servicios de información intermedia. En la UMDL, los agentes mediadores interactúan exclusivamente con otros agentes más que con usuarios finales o colecciones. Llevan a cabo funciones tales como dirigir una petición de un AIU a una colección, monitorear el progreso de las peticiones, transmitir resultados, traducir formatos y mantener registros. Una subclase de los mediadores, se llaman facilitadores y su función es agrupar agentes para que realicen una tarea específica.

Los agentes de interfaz a colección (AIC) administran la interfaz de la UMDL para colecciones, las cuales son cuerpos definidos de contenido de la biblioteca. Entre otras tareas de comunicación el AIC publica el contenido y capacidades de una colección.

Equipos de agentes

Para llevar a cabo tareas complejas en la UMDL se requiere la coordinación de múltiples agentes especializados que trabajen juntos en favor del usuario y de quienes proveen material a la colección. Para formar equipos, los agentes deben se capaces de describir sus habilidades unos a otros de manera que todos puedan entenderlas.

Los agentes en la UMDL se comunican a tres niveles distintos de abstracción. Al nivel más bajo, los agentes emplean protocolos de red tales como TCP/IP para transmitir mensajes entre ellos. En un segundo nivel, los agentes interpretan y procesan mensajes de acuerdo a protocolos específicos de tarea. Por ejemplo, los agentes podrían usar SQL para comunicar una petición de obtener datos. La UMDL generalmente no restringe protocolos específicos de tarea, es decir, cualquiera que diseñe e introduzca los agentes puede escoger libremente el lenguaje que estos agentes hablen.

Evidentemente, los agentes serán usados con mayor frecuencia si se comunican en lenguajes ampliamente adoptados. En particular, el deseo de una amplia interoperatividad provee un incentivo para soportar los estándares que las bibliotecas usan con frecuencia. Esto aumenta el rango de colecciones accesibles a un agente que formula una petición dada.

Las capacidades de un agente especializado permanecerán sin descubrir a menos que dé a conocer sus habilidades y su localización y que participe en la formación de equipos. Se definen entonces protocolos especiales para la formación de equipos y tareas de negociación, los cuales son compartidos por todos los agentes de la UMDL. Estos protocolos representan el tercer nivel de abstracción en la comunicación inter-agentes.

Los agentes UMDL se definen por el contenido de información que pueden proporcionar, los servicios de información que pueden dar o ambos. Para que los agentes participen en los protocolos de la UMDL necesitan un lenguaje para describir estas capacidades. Los agentes describen lo que pueden contribuir en un equipo y cuales con sus limitaciones en un lenguaje de sinopsis llamado CL (Conspectus Language). Los facilitadores pueden usar también CL para describir las capacidades requeridas para la participación en un equipo.

Para averiguar la intención de un mensaje, los protocolos de la UMDL adoptaron una noción flexible de tipos de mensajes, modelados de acuerdo a KQML. Los tipos de mensajes UMDL, el equivalente de las performativas en KQML, corresponden a actos de comunicación de alto nivel. Un mensaje puede contener expresiones en CL con el tipo de mensaje comunicando lo que el receptor debe hacer con el contenido dado. Los protocolos UMDL definen un número reducido de tipos de mensajes estándar que todos los agentes deben ser capaces de interpretar y procesar.

Los protocolos UMDL se diseñaron de manera que los agentes se anuncien ellos mismos y se encuentren unos a otros en base a sus capacidades. En lugar de que cada agente mantenga modelos de los otros agentes y que periódicamente difunda sus descripciones a cada uno de los otros agentes, se diseñó un agente de registro al que todos los demás agentes saben como accesar , con el que todos los agentes se pueden comunicar usando los protocolos UMDL y que provee sus servicios por un precio fijo para evitar negociación. El agente de registro mantiene una base de datos de todos los agentes en el sistema de la UMDL, incluyendo descripciones de su contenido y capacidades. De la descripción anterior se puede observar que el sistema multiagente de la UMDL está modelado como una arquitectura por coordinación asistida (ver sección 2.2.2).

2.6.2. La biblioteca digital de Stanford

La biblioteca digital de Stanford se concentra en desarrollar un conjunto de protocolos de servicio por los cuales diferentes recursos de información y servicios pueden ser conjuntados. Esta serie de protocolos de servicio se conoce colectivamente como InfoBus, el cual es relevante para esta tesis porque utilizan a CORBA como el ambiente para el desarrollo del prototipo.

InfoBus

InfoBus es un prototipo de infraestructura que esta diseñado para proveer una manera de extender los protocolos actuales de la red de abajo hacia arriba con un conjunto de protocolos de más alto nivel para la administración de la información que actualmente no tiene la red [Röscheisen 1997].

InfoBus da a los clientes de la biblioteca un acceso uniforme a recursos y servicios de información distribuidos y heterogéneos. Una colección o servicio es parte de InfoBus si usa uno de los protocolos de InfoBus o existe un mediador InfoBus para este servicio.

Estos mediadores InfoBus son envolturas que pueden ser operadas ya sea por los mismos servicios o por otro proveedor de servicio (por ejemplo una biblioteca digital). Esta flexibilidad hace posible enriquecer la infraestructura de información y alcanzar interoperatividad de abajo hacia arriba.

Los clientes utilizan los recursos de InfoBus para llevar a cabo tareas complejas tales como escribir artículos, publicar boletines y rastrear el desarrollo de productos industriales de línea. Los recursos de información incluyen repositorios de información tales como catálogos en línea, periódicos, etc. Los recursos también incluyen servicios que operan sobre información tales como traducción y sumarización de documentos, indexado remoto y servicios de pago y de derechos de autoría.

Al nivel de implementación, la arquitectura de InfoBus se acopla bien con tecnologías como CORBA y DCOM que soportan un diseño orientado a objetos en un ambiente distribuido, por lo que han experimentado con CORBA como un ambiente prototípico para desarrollar InfoBus. Específicamente han utilizado la implementación de CORBA desarrollada por Xerox PARC conocida como ILU (Interface Language Unification). Cada entidad participante (clientes, recursos de información, documentos, contratos, etc.) es entonces implementada directamente como un objeto o se crea un objeto para actuar como un mediador para la entidad.

Los mediadores InfoBus se comunican con los servicios que representan a través de sus propios protocolos de acceso a servicio tales como telnet, Z39.50 o HTTP. Los clientes de InfoBus que están interactuando con los mediadores no necesitan estar conscientes de estas diferencias, simplemente usan las llamadas al protocolo para accesar los mediadores.

InfoBus se compone de cinco capas de servicio:

  1. El protocolo de interoperatividad de la biblioteca digital (DLIOP) que provee servicios básicos para la administración de componentes (por ejemplo documentos) y colecciones en un ambiente de red de modo que los clientes de InfoBus se puedan comunicar con los repositorios de información y solicitar y recibir información asíncronamente de los mediadores InfoBus.
  2. La arquitectura de metadatos de Stanford (SMA) que define una capa de servicio para el intercambio uniforme y la administración de metadatos necesarios para encontrar servicios InfoBus, para solicitar información a estos servicios y para interpretar los resultados estructurados que regresan estos servicios.
  3. La propuesta de protocolo de Stanford para la búsqueda y recuperación de información en la red (STARTS), la cual esta surgiendo para facilitar las tareas que desarrollan los meta-buscadores (escoger las mejores fuentes para evaluar una pregunta, evaluar una pregunta en esas fuentes y conjuntar las respuestas provenientes de esas fuentes).
  4. El protocolo de la interfaz de aplicación para el pago universal (UPAI) que permite que se tenga aplicaciones de clientes que incluyan transacciones de pago sin requerir que los clientes mismos conozcan los detalles de mecanismos específicos de pago.
  5. El marco para la administración interoperable de derechos (FIRM), el cual define un servicio de administración de derechos encima de los protocolos existentes en la red, soportando contratación digital, negociación privada, seguridad en red, entre otros.

2.6.3. Sistema de Biblioteca Digital (DLS)

DLS es una infraestructura de información para la cual Kahn [1988] describió una arquitectura abierta que incluye los componentes funcionales, la metodología por la cual los sistemas participantes se comunican entre sí y componentes de software activos y móviles llamados Knowbots. En esta sección se presentan los conceptos de DLS que se relacionan con la comunicación, los cuales son Knowbots y su ambiente de operación llamado KNOE.

Knowbots

El medio principal de comunicación e interacción entre los componentes de la DLS es el conjunto de programas activos llamados Knowbots, capaces de operar en su ambiente de software nativo y de transportar incluso a otros Knowbots. Los Knowbots se comunican por medio de mensajes y están presentes en cada uno de los diferentes componentes de DLS. Pueden ser replicados, creados, destruidos, pueden estar residentes en un sistema o moverse de una máquina a otra.

Generalmente un Knowbot puede ser visto como un Knowbot de usuario o como un Knowbot de sistema dependiendo si sirve directamente a un usuario individual o no.

Un Knowbot de usuario acepta de éste instrucciones para obtener información y determina cómo cumplir de la mejor manera los requerimientos establecidos, tal vez interactuando con otros Knowbots y elementos funcionales de DLS. Los Knowbots proceden entonces a adquirir la información deseada accesando las partes apropiadas del sistema de la biblioteca. La realización de esta tarea puede depender de servicios de indexación inteligente provistos por otros Knowbots o llevar a cabo búsquedas en texto donde se necesita.

Un conjunto de Knowbots de sistema específicamente atiende la información disponible localmente de la biblioteca, recibe solicitudes de los Knowbots de usuario y obtiene los documentos almacenados. Otro conjunto de Knowbots de sistema atiende las tareas administrativas y de soporte tales como diagnóstico, respaldo y contabilidad.

Una clase de Knowbots de confianza llamados mensajeros (el término en inglés es couriers) tienen la responsabilidad especial de cuidar los objetos seleccionados en favor de sus autores u otros propietarios de derechos en los objetos. A un mensajero se le confía la responsabilidad de una base de datos completa, un documento específico o una porción del documento. La combinación de un mensajero y su correspondiente entidad (base de datos, documento o párrafo) es un objeto controlado en el sistema.

Algunos Knowbots tienen un estado permanente dentro de cada sistema del usuario y son conocidos como Knowbots residentes. Otros tipos de Knowbots pueden ser producidos dinámicamente con el propósito de llevar a cabo una tarea específica para luego ser eliminados cuando la tarea se haya terminado. A estos últimos se les llama Knowbots transitorios.

El ambiente operativo Knowbot (KNOE)

Los Knowbots son creados, destruidos o de otra manera administrados por el ambiente de operación Knowbot llamado KNOE. Este ambiente provee el contexto en el cual los Knowbots funcionan dentro de DLS, administrando los recursos del sistema necesarios para soportarlos y soportando la comunicación entre Knowbots.

Cada componente principal de DLS contribuye y participa en el ambiente operativo Knowbot. Cada KNOE local conoce acerca de todos los Knowbots en sus sistema local y de Knowbots seleccionados de algún otro lugar en el KNOE común.

Las interacciones entre Knowbots son mediadas por el KNOE, el cual asiste en el transporte de mensajes entre Knowbots en un sistema personal dado y entre sistemas. El KNOE valida y autentifica los mensajes cuando es necesario. En un KNOE local dado, cualquier mensaje que contenga capacidades del sistema operativo se utiliza por el KNOE para proveer soporte a su capa o estrato.

Idealmente, el KNOE podría ser creado por sí mismo fuera del sistema residente de Knowbots, de manera que sólo un estilo de arquitectura sea necesario. Sin embargo, pragmáticamente, la implementación del sistema puede dictar que las porciones sean programadas de forma más convencional.

El sistema resultante será diseñado para una portabilidad sencilla a otras bases de hardware y software. La facilidad de portabilidad dependerá del grado en el que KNOE pueda ser transportado. Si la mayor parte de KNOE se compone de Knowbots entonces solamente una versión de inicio del KNOE puede ser requerida. Este es un requerimiento mínimo sobre el hardware y el sistema operativo base. Si todo el KNOE se programa en forma convencional, las exigencias hechas sobre hardware y software base pueden ser mayores también.  


Capítulo 3

Diseño conceptual

Retomando el propósito de este proyecto de tesis que es el de comunicar agentes de usuario con componentes de una biblioteca digital florística (relatado en el capítulo 1) y habiendo presentado en el capítulo 2 algunas propuestas de solución encontradas durante la revisión bibliográfica, en este capítulo se da una breve descripción de los elementos de la biblioteca que tienen necesidades de comunicación y posteriormente se describe un Marco de Inter-Comunicación basado en KQML (MICK) que comprende aquellos componentes que en este proyecto se proponen para hacer posible la comunicación.

3.1 Elementos que participan en la comunicación

La arquitectura actual de la biblioteca florística digital (FDL) es una evolución de la arquitectura presentada en [Sánchez y Leggett 1997]). En esta arquitectura, cuatro son los elementos que tienen necesidad de comunicarse entre sí. Estos son: un administrador de agentes de usuario (UAM), un director de agentes de usuario (UAD), unos servicios de biblioteca activa (ALiS) y el conjunto de agentes de usuario. En la Figura 5 se presentan estos elementos dentro de la arquitectura de la FDL y en las subsecciones siguientes se describe en forma breve cada uno de ellos resaltando las necesidades de comunicación que tienen. Una descripción más amplia es la que da Cabrera [1997].

3.1.1 Servicios de Biblioteca Activa (ALiS)

ALiS es el componente que interactúa directamente con el manejador de la base datos y se encarga de recibir y ejecutar las peticiones provenientes del UAD, del UAM o directamente de alguno de los agentes de usuario activos. Esto significa que el componente ALiS debe ser capaz de recibir e interpretar mensajes provenientes de el resto de los elementos y responder adecuadamente a éstos.

Figura 5. Elementos de la arquitectura de la FDL que participan en la comunicación (adaptada de Cabrera [1997] y de Sánchez y Leggett [1997]).

3.1.2 Administrador de Agentes de Usuario (UAM)

Este componente es realmente una interfaz mediante la cual los administradores de la biblioteca digital pueden controlar (consultar, dar de alta y dar de baja) las clases de agentes, las instancias de agentes, los usuarios, las acciones predefinidas que pueden ser utilizadas por los agentes y los servicios de la biblioteca. Cabe aclarar que en situaciones normales el administrador de agentes no dará de baja instancias de agentes, ya que esa tarea corresponde a los usuarios finales de los servicios de la biblioteca. Si algún administrador diera de baja instancias, el UAM tendría que ser responsable de enviar un mensaje al UAD del usuario al que pertenece la instancia dada de baja para evitar inconsistencia. De lo anterior se observa que generalmente la necesidad de comunicación de este componente es únicamente con ALiS para enviarle mensajes solicitándole la acción elegida por el administrador.

3.1.3 Director de Agentes de Usuario (UAD)

El UAD es una interfaz para los usuarios finales de la biblioteca, a través de la cual pueden llamar a alguno de sus agentes para pedirle resultados o ver su avance en la tarea asignada, ver la información completa relacionada con sus agentes, y cambiar el estado de los mismos (ya sea a suspendido, activado o terminado). Con esta interfaz los usuarios también pueden seleccionar alguna de las clases de agentes disponibles para crear un nuevo agente (instancia).

Este componente requiere entonces ser capaz de comunicar tanto a ALiS como a los agentes los cambios de estado que el usuario solicite por medio de la interfaz. También requiere enviar mensajes a ALiS solicitándole las instancias de agentes con las que cuenta el usuario, el conjunto de clases de agentes disponibles y la creación de una nueva instancia.

Es importante hacer notar que el UAD debe reconocer la autonomía de los agentes y por esa razón debe enviarles mensajes expresando la intención de que ese cambio se efectúe en ellos, y por su parte los agentes deben responder con un mensaje que refleje el resultado de la intención del UAD.

3.1.4 Agentes de usuario

Son instancias de clases de agentes que los usuarios han creado y personalizado para asignarle una tarea específica. Deben ser capaces de recibir mensajes provenientes del UAD solicitándole su cambio de estado, evaluar si el cambio es posible en ese momento y responder con otro mensaje. Estos agentes deben también no sólo responder sino iniciar una comunicación enviando al UAD un mensaje cuando el usuario cambie su estado desde su interfaz local. Una observación importante es que para evitar que los agentes tengan que interactuar directamente con la base de datos para actualizar sus estado deben tener la certeza de que el mensaje mandado al UAD (con el objeto de mantener consistencia entre lo que presenta el UAD en su interfaz y el estado real del agente) llegue también a ALiS.

3.2 Marco de Inter-Comunicacion basado en KQML (MICK)

Para lograr la comunicación entre los elementos anteriormente mencionados, estos se organizan en una arquitectura de coordinación asistida (ver sección 2.2) para sistemas multiagentes alrededor de un facilitador. Se ha usado KQML como lenguaje base para la comunicación por lo que se ha denominado a este esfuerzo Marco de Inter-Comunicación basado en KQML (MICK). En MICK, cada agente cuenta con un ruteador capaz de enviar y recibir mensajes en KQML, reconocer un conjunto de palabras y seguir un protocolo. Cada uno de estos elementos (el facilitador, el ruteador, KQML, el vocabulario y el protocolo) se describen a continuación. Una representación gráfica de la relación entre los elementos que participan en la comunicación y MICK se presenta en la Figura 6.

Figura 6. Relación de MICK con los elementos que participan en la comunicación. Las líneas sólidas representan canales por los que se intercambian mensajes en KQML y las líneas punteadas representan llamadas a funciones.

3.2.1 Facilitador

Este facilitador es el que define la arquitectura de coordinación asistida, ya que se encarga de aceptar conexiones, de recibir solicitudes de registro de los ruteadores y de mantener tablas con las direcciones de quienes se han registrado. Funciona como mediador en la comunicación, esto quiere decir que todos los mensajes que el UAD quiera hacer llegar a los agentes los envía al facilitador para que éste los envíe al agente correspondiente y de igual manera los mensajes que los agentes quieren enviar al UAD los envían al facilitador para que éste se los haga llegar al UAD. Este mecanismo evita que sea necesario que cada agente o componente mantenga tanto conexiones como una lista actualizada de las direcciones de todos los otros agentes o componentes con los que desee comunicarse y permite hacer referencias por el nombre o identificador con el cual se registraron.

3.2.2 Ruteador de mensajes

Todo elemento de la biblioteca que desee comunicarse con otros en el lenguaje establecido requiere tener asociado un ruteador que sirva como punto de contacto para comunicarse con el resto de los elementos. El ruteador se encarga en general de registrar a su agente o componente con el facilitador, recibir mensajes, interpretarlos para solicitar la acción correspondiente a quien está sirviendo, construir mensajes y enviarlos. Este ruteador funciona entonces para el agente como un cliente y como un servidor. Funciona como cliente cuando solicita una acción como resultado de la recepción de un mensaje y funciona como servidor cuando la aplicación a la que pertenece le solicita el envío de un mensaje.

Aunque todos los ruteadores tienen la misma estructura, difieren en el vocabulario que poseen y en el número de mensajes que manejan. Así, por ejemplo, el ruteador para los agentes de usuario es capaz de manejar solo aquellos mensajes provenientes del UAD que soliciten un cambio de estado y de enviar mensajes notificando un cambio en su estado. El ruteador del UAD, por su parte, además intercambiar mensajes con los agentes de usuario, es capaz de enviar mensajes a ALiS solicitando el cambio de estado de alguna instancia de agente específica y mensajes preguntando por las clases de agentes disponibles y por las instancias de agentes que tiene un usuario final. El ruteador de ALiS maneja entonces tanto mensajes que solicitan cambios de estado como aquellos donde se le pregunta por instancias y clases de agentes.

Dos características importantes de los ruteadores son las siguientes: 1) son procesos independientes, por lo que el envío y recepción de mensajes es completamente asíncrono y 2) requieren de cambios mínimos en la organización interna de las aplicaciones para permitir a éstas enviar y recibir mensajes.

3.2.3 El lenguaje

El lenguaje común utilizado para comunicar a los elementos de la biblioteca entre sí es el lenguaje de tipo declarativo conocido como KQML, descrito en la sección 2.4.3. Del conjunto de performativas estándar se utilizan sólo cuatro, las cuales se listan y explican a continuación:

1) tell.- esta es una performativa básica de tipo informativa que indica que lo que está en el contenido del mensaje está en la base de conocimientos o conjunto de creencias de quien envía el mensaje.

2) achieve.- esta performativa pide al que recibe el mensaje que trate de hacer cierta la sentencia que está en el contenido.

3) ask-about.- indica que quien envía el mensaje desea todas las sentencias relevantes contenidas en la base de conocimientos del receptor de acuerdo a lo que esta en el contenido del mensaje.

4) reply.- con esta performativa el que envía el mensaje indica que lo que está en el contenido es una respuesta adecuada a una pregunta recibida anteriormente.

5) forward.- indica que la intención del mensaje es la de ser reenviado por el agente que lo recibe. En su contenido puede tener otro mensaje en KQML.

Dos performativas extras se utilizan para manejar situaciones anormales:

1) sorry.- quien envía esta performativa indica que entiende el mensaje recibido anteriormente, pero no es capaz de dar otra respuesta.

2) error.- con esta performativa se indica que quien envía el mensaje no puede entender o considera que el mensaje recibido está mal formado.

3.2.4 El vocabulario

Como se describe en la sección 2.1. uno de los componentes requeridos para la comunicación es el de representación. Este requerimiento lo cubre un conjunto de palabras que los elementos de la biblioteca (específicamente sus ruteadores) reconocen en el contenido de los mensajes. Este diccionario de palabras es el siguiente:

1) status.- sustantivo que representa el concepto de estado del agente.

2) suspended.- adjetivo atribuible al estado de un agente que indica su suspensión temporal.

3) active.- adjetivo atribuible al estado de un agente que indica operación normal.

4) terminated.- adjetivo atribuible al estado de un agente que indica la eliminación permanente del agente.

5) added.- adjetivo atribuible a una instancia de agente, clase de agente, acción, usuario o servicio cuando éste se ha incorporado a la base de datos.

6) dropped.- adjetivo atribuible a una instancia de agente, clase de agente, acción, usuario o servicio cuando éste ha sido removido de la base de datos.

7) AgentInstance.- sustantivo que representa una instancia de agente.

8) AgentClass.- sustantivo que representa una clase de agente

9) User.- sustantivo que representa un usuario final de la biblioteca digital.

10) Action.- sustantivo que representa una acción predefinida utilizable por los agentes.

3.2.5 El protocolo de comunicación

En base a las cuatro performativas y al vocabulario descritos en las secciones anteriores, se definió el protocolo de comunicación entre el UAD y los agentes, entre el UAD y ALiS y entre el UAM y ALiS. Todos los mensajes que son parte del protocolo están compuestos por una performativa y una serie de parámetros que inician con dos puntos. La especificación del protocolo se detalla en las tablas 1-3. Los parámetros reservados sender y receiver que indican el nombre o identificador de quien envía el mensaje y a quien va dirigido el mensaje siempre están presentes por lo que se omiten en las tablas.

UAD -> agentes de usuario
 

Mensaje KQML Respuesta
achieve  
    : content(status = suspended)
tell  
    : content (status = suspended)
achieve  
    : content(status = active)
tell  
    : content (status = active)
achieve  
    : content(status = terminated)
tell  
    : content (status = terminated)

  Tabla 1. Protocolo de comunicación entre el UAD y los agentes de usuario.

La Tabla 1 ilustra el protocolo de comunicación entre el UAD y los agentes de usuario expresado con mensajes KQML. Como puede notarse, los contenidos de los mensajes sólo hacen referencia a cambios de estados en los agentes.

 UAD -> ALIS
 

Mensaje KQML Respuesta
ask-about  
: content (AgentClass) 
reply  
: content(AgentClass)  

: classID Id  

: name ClassName 

: summary ClassSummary 

: url ClassLocation

ask-about  
: content (AgentInstance)  

: userID Id

reply  
: content(AgentInstance)  

: instanceID Id  

: name InstanceName  

: classID Id  

: status: AgentStatus  

: description InstanceDescription

achieve  
: content (AgentInstance = added)  

: name AgentInstanceName  

: userID Id  

: description InstanceDescription  

: classID Id

tell  
: content (AgentInstance = added)  

: instanceID Id

achieve  
: content (AgentInstance = suspended)  

: instanceID Id

tell  
: content(AgentInstance = suspended)  

: instanceID Id

achieve  
: content (AgentInstance = active)  

: instanceID Id

tell  
: content(AgentInstance = active)  

: instanceID Id

achieve  
: content (AgentInstance = terminated)  

: instanceID Id

tell  
: content(AgentInstance = terminated)  

: instanceID Id

  Tabla 2. Protocolo de comunicación entre el UAD y ALiS.

En la Tabla 2 se presenta el protocolo de comunicación entre el UAD y ALiS también mediante mensajes KQML. Se puede observar que los contenidos de los mensajes en esta tabla hacen referencia a las clases de agentes, a las instancias de agentes, a la creación de nuevas instancias de agentes y a cambios de estado en las instancias de agentes.

UAM -> ALIS
 

Mensaje KQML Respuesta
achieve  

: content(Action = added)

tell  

: content(Action = added)  

: actionID id

achieve  

: content(Action = dropped)  

: actionID id

tell  

: content(Action = dropped)  

: actionID id

ask-about  

: content Action

reply  

: content Action  

: actionID id

achieve  

: content(User = added)

tell  

: content(User = added)  

: userID id

achieve  

: content(User = dropped)  

: userID id

tell  

: content(User = dropped)  

: userID id

ask-about  

: content (User)

reply  

: content (User)  

: userID id

achieve  

: content(AgentClass = added)

tell  

: content(AgentClass = added)  

: classID id

achieve  

: content(AgentClass = dropped)  

: classID id

tell  

: content(AgentClass = dropped)  

: classID id

ask-about  

: content(AgentClass)

reply  

: content(AgentClass)  

: classID id

ask-about  
: content (AgentInstance) 
reply  

: content (AgentInstance) 

achieve  

: content (AgentInstance = terminated)  

: instanceID Id

tell  

: content (AgentInstance = terminated)  

: instanceID Id

  Tabla 3. Protocolo de comunicación entre el UAM y ALiS.

En la Tabla 3 el protocolo de comunicación entre el UAM y ALiS se describe. Aquí, los contenidos de los mensajes KQML indican la creación, eliminación y obtención de acciones, usuarios, clases de agentes e instancias de agentes.  


Capítulo 4

Implementación prototípica

Los tres componentes de la biblioteca digital que se mencionan en el Capítulo 3 como elementos que participan en la comunicación (ALiS, UAD y UAM) fueron implementados como parte de la arquitectura llamada Mobots por Cabrera [1997]. El conjunto de agentes de usuario que se mencionan como el cuarto elemento que participa en la comunicación y que también se menciona en el Capítulo 3 se sigue ampliando.

Mobots se implementó como parte de una prueba de conceptos más general que logró la integración de servicios en la biblioteca florística digital. De este trabajo surgió la necesidad de atacar el problema de la comunicación de una manera más eficiente y enfocada a la naturaleza autónoma de los agentes. De acuerdo a Cabrera [1997] la manera en que está implementada la comunicación entre los agentes y el UAD en Mobots es ineficiente, ya que cuando se modifica el estado del agente desde el UAD, éste simplemente actualiza la información de la base de datos y es entonces responsabilidad del agente cuestionar periódicamente al UAD (en realidad a la base de datos) para saber de algún cambio de su estado realizado desde la interfaz del UAD.

Este proyecto de tesis se enfoca entonces en hacer eficiente la comunicación entre los agentes y el UAD creando los elementos descritos en el capítulo anterior para permitir una comunicación basada en mensajes KQML. Una descripción de la herramienta utilizada, así como la explicación de cómo fueron implementados dichos elementos y la versión mejorada del UAD se presenta en este capítulo.

4.1 Java Agent Template, Lite (JATLite)

Como herramienta de implementación se empleó JATLite, un conjunto de paquetes en Java creados en la Universidad de Stanford que facilitan la creación de agentes y proveen herramientas básicas de comunicación y modelos basados en TCP/IP. Especialmente JATLite facilita el desarrollo de agentes que intercambian mensajes KQML [Jeon 1997].

Existen cinco capas en la arquitectura de JATLite, de las cuales el desarrollador puede elegir la más apropiada para que a partir de ésta inicie la construcción de sus sistemas. Cada capa de un nivel superior impone nuevas restricciones a las aplicaciones de agentes. Las cinco capas, descritas a continuación, son:

  1. La capa abstracta es una colección de clases abstractas necesarias para la implementación de JATLite. Esta capa supone que las conexiones se hacen siguiendo el protocolo TCP/IP, aunque es posible extenderla para soportar otros protocolos tales como UDP.
  2. La capa base provee comunicación elemental basándose en el protocolo TCP/IP y la clase abstracta. En esta capa no hay restricción en el lenguaje de los mensajes o el protocolo.
  3. La capa KQML hace el análisis gramatical de mensajes KQML y permite su almacenamiento. Además de las performativas estándar, esta capa también implementa las extensiones a KQML propuestas por el Centro para la Investigación del Diseño (Universidad de Stanford) el cual provee un protocolo para registrarse, conectarse y desconectarse.
  4. La capa de ruteador provee los servicios de registro por nombre y de ruteo y almacenamiento de mensajes KQML. Todos los agentes envían y reciben mensajes mediante el ruteador el cual los reenvía a los destinos nombrados. Cuando un agente intencionalmente se desconecta o accidentalmente termina, el ruteador almacena sus mensajes hasta que el agente se vuelve a conectar. El ruteador es particularmente importante para agentes que son applets, ya que éstos sólo pueden iniciar conexiones con el servidor que los creó debido restricciones de seguridad del WWW y Java.
  5. El nivel más alto es la capa de protocolo la cual provee servicios tales como SMTP (Simple Mail Transfer Protocol) y FTP (File Transfer Protocol), aunque puede ser extendida para soportar otros protocolos. Esta capa es útil cuando los agentes requieren intercambiar archivos o enviar mensajes por correo electrónico.

4.2 La implementación de MICK

Los elementos de MICK que fueron implementados incluyen el facilitador y un conjunto de ruteadores adaptados a cada componente de la arquitectura que se describe en la sección 3.1. En las subsecciones siguientes se describe a detalle la implementación de estos elementos y en la Figura 7 se muestra gráficamente su relación.

Figura 7. Implementación de MICK. Los círculos representan puertos y las flechas indican qué elemento solicita conexión a qué elemento.

4.2.1 La implementación del ruteador de mensajes de ALiS

El ruteador de mensajes de ALiS se implementó a partir de la capa KQML de JATLite. Funciona como un servidor que acepta conexiones para comunicación en KQML, creando un proceso por cada conexión aceptada para que se encargue de enviar y recibir mensajes de esa conexión. Este ruteador sabe interpretar los mensajes KQML que recibe para luego llamar a las funciones que se requieren y entonces construir el mensaje respuesta y enviarlo a quien hizo la solicitud. Los mensajes que éste ruteador puede atender incluyen la solicitud para obtener todas las instancias de agentes que un usuario tiene, las clases que están disponibles, la solicitud para añadir una instancia nueva y la solicitud para cambiar el estado de alguna instancia.

4.2.2 La implementación del Facilitador

Este es un elemento central en la arquitectura de comunicación cuya implementación se basó igualmente en el paquete de clases que ofrece la capa KQML de JATLite. No se utilizó la funcionalidad de agente ruteador que es parte de la capa de ruteador de JATLite debido a problemas para iniciarlo adecuadamente.

Como ya se describió en el Capítulo 3, este elemento es un mediador en la comunicación entre el UAD y los agentes. Para lograrlo, acepta conexiones tanto del UAD como de los agentes y crea un proceso para atender cada canal de comunicación. También establece una conexión con el ruteador de ALiS con el objetivo de hacer llegar a éste los mensajes de cambio de estado entre el UAD y los agentes que el facilitador no pudiera hacer llegar a sus destinatarios por haber perdido la conexión o por no estar en ejecución aquel componente al cual va dirigido el mensaje.

El facilitador no requiere examinar el contenido de la comunicación ya que únicamente recibe mensajes que especifican en su performativa la intención de ser reenviado a otro destino (forward). Únicamente en caso de no poder hacer llegar el mensaje al destino especificado, el facilitador examina el contenido del mensaje para determinar si debe hacerse llegar al componente ALiS, si es así, construye el mensaje apropiado y lo envía.

Como dato adicional, hay que decir que el facilitador acepta las conexiones y recibe los mensajes por un sólo puerto, el cual debe ser conocido para todos los que deseen conectarse con él.

4.2.3 La implementación del ruteador de mensajes del UAD

De la misma capa de KQML se partió para implementar este elemento que ofrece al UAD el servicio de envío y recepción de mensajes. Cuando es creado se registra con el facilitador y con el ruteador de ALiS bajo un nombre compuesto por la cadena "UAD" y el identificador del usuario para establecer una conexión con ambos e iniciar un proceso independiente para que se encargue de la comunicación con ellos. Posteriormente envía un mensaje para solicitar a ALiS las instancias de agentes con las que cuenta el usuario y otro mensaje para solicitar las clases de agentes que están disponibles para que el usuario las instancíe. A la llegada de las respuestas a los mensajes anteriores este ruteador llama a funciones o métodos de la interfaz del UAD para que la información contenida en el mensaje se guarde y se despliegue al usuario.

Adicionalmente a los mensajes que envía como parte de su proceso de inicialización, el ruteador del UAD también envía mensajes a solicitud de la interfaz del UAD. Estos mensajes incluyen aquellos dirigidos a ALiS para solicitar la adición de una nueva instancia o el cambio de estado de alguna instancia.

Por último, hay que decir que a pesar de que cada interfaz de UAD inicia una copia de este ruteador, todos los ruteadores de este tipo "escuchan" en el mismo puerto.

4.2.4 La implementación del ruteador de mensajes de los agentes

Para que cada instancia de agente pueda recibir y enviar mensajes KQML requiere tener un ruteador el cual se registra con el facilitador bajo un nombre compuesto por el identificador de la instancia y de ésta manera participar en la comunicación. El ruteador acepta mensajes provenientes del UAD que le solicitan cambiar su estado, llama a la función que efectúa el cambio de estado solicitado, construye el mensaje de respuesta diciendo que el cambio se efectuó o que hubo un error y lo envía. También puede enviar mensajes al UAD a solicitud de la instancia de agente que sirve para notificar cuando el usuario cambie el estado del agente desde la interfaz de la instancia. Esto último evita que el agente tenga que accesar directamente la base de datos para actualizar la información en relación a su estado, ya que el UAD o el facilitador harán llegar esa notificación de cambio a ALiS.

Al igual que los ruteadores anteriores, todas las copias de este ruteador que sean iniciadas por las instancias de agentes recibirán los mensajes por un sólo puerto.

4.3 Interacción entre los ruteadores y sus aplicaciones

Dado que el ruteador de mensajes y la aplicación a la que sirve son dos programas independientes es necesario tener una interfaz común a través de la cual la aplicación sea vista por el ruteador. Por esta razón se definieron dos interfaces, una para las instancias de agentes y otra para el UAD.

La interfaz para los agentes define un agente KQML con un método para cambiar su estado. Esta interfaz puede verse como una clase abstracta que es implementada por las instancias de agentes. De esta manera el ruteador ve a su instancia de agente únicamente como un objeto con un método que puede ser llamado cuando recibe un mensaje de solicitud de cambio de estado.

De manera similar la interfaz para el UAD define una clase abstracta con métodos para ser llamados por su ruteador para obtener el identificador del usuario o cuando se reciben mensajes que contienen una clase de agente, una instancia, o el aviso/confirmación del cambio de estado de alguna instancia de agente.

4.4 La implementación de la nueva versión del UAD

Como ya se describió en el capítulo tres, la principal funcionalidad del UAD es permitir a los usuarios finales de la biblioteca tener acceso a sus instancias de agentes creadas y a las clases de agentes disponibles para ser instanciadas. Esta nueva versión del UAD ofrece dicha funcionalidad desde una sola interfaz accesible a través de un navegador de red. Para su implementación se utilizó el lenguaje de programación Java.

La interfaz (ver Figura 8) se divide en dos secciones, una donde el usuario trabaja con las instancias de agentes y otra en la que trabaja con las clases de agentes. En la primera sección el usuario puede realizar seis operaciones con cualquiera de los agentes presentados, estas son: tener acceso al agente o llamarlo para interactuar con él, ver la información referente al agente (ver Figura 9), cambiar el estado del agente a activado, cambiar el estado a suspendido, cambiarlo a terminado y terminar todas las instancias.


   

Figura 8. Interfaz principal del director de agentes de usuario

 

Figura 9. Ventana con la información de una instancia de agente.

En la segunda sección de la interfaz sólo una operación se puede realizar, y es la de seleccionar una de las clases enlistadas y crear un nuevo agente de ésta clase. Para lograr esto último se le pide al usuario que proporcione un nombre y una descripción opcional de la tarea que va a desempeñar el agente (ver Figura 10), para luego hacer que su ruteador envíe la solicitud a ALiS y una vez recibida la respuesta de ALiS que contiene el identificador de instancia asignado al nuevo agente, se presenta en el navegador la interfaz inicial del agente.


   

Figura 10. Forma para la captura de datos de un nuevo agente  


Capítulo 5

Evaluación

Una vez presentado en los capítulos anteriores el diseño conceptual y la implementación prototípica de MICK que da solución al problema de la comunicación entre agentes y de la nueva versión del director de agentes, en este capítulo se evalúan estos elementos junto con las herramientas y tecnologías elegidas para su elaboración.

5.1 MICK

Los elementos implementados para hacer posible la comunicación definen una arquitectura por coordinación asistida o mediada, la cual promueve la autonomía de los elementos que participan, es escalable y facilita su uso por parte de los elementos existentes, es decir, no incrementa el grado de complejidad en estos elementos y sólo se requieren cambios mínimos para utilizar las facilidades que otorga MICK.

La solución implementada para resolver el problema de la comunicación hace necesario que cada vez que una nueva clase de elementos desee participar en la comunicación se deba implementar un ruteador adaptado a las necesidades de ellos. Sin embargo, el esfuerzo para construir un ruteador que sirva a esa nueva clase de elementos se reduce considerablemente por el uso de un lenguaje declarativo común como lo es KQML. La solución también crea un costo de infraestructura considerable, debido a que cada elemento, para formar parte de la arquitectura de comunicación, debe tener asociado un mediador (un ruteador de mensajes KQML).

La implementación del facilitador comprende servicios tales como el mantenimiento de una comunicación robusta y el envío de mensajes a un agente específico sin necesidad de conocer la dirección física de éste. Sin embargo, no implementa todos los servicios que idealmente debe ofrecer un facilitador y que se enumeran en la sección 2.2. Entre los servicios que este facilitador no ofrece está el encontrar agentes no por su nombre o identificador sino por la tarea que pueden desempeñar o por el interés en cierto tema. Esta funcionalidad permitiría diseñar mecanismos de colaboración entre agentes de usuario como los que se plantean en [Lashkari et al. 1994].

Un aspecto importante con respecto al facilitador es que con la implementación de éste se logró eliminar las restricciones de conectividad que por razones de seguridad imponen los navegadores de red a los applets y dado que el UAD es un applet y que la mayoría de los agentes de usuario que se han desarrollado y están en desarrollo para la FDL también son applets, el facilitador adquiere mayor importancia.

Un posible problema con la forma en que está implementado el facilitador es el hecho de que este componente de MICK utiliza un sólo puerto para recibir y enviar mensajes tanto del UAD como de los agentes, lo que puede representar un potencial "cuello de botella" si el número de usuarios (a través de su UAD) y agentes conectados es grande y el tráfico de mensajes es intenso. Una solución a este posible problema es aprovechar las ventajas de escalabilidad que ofrece la arquitectura por coordinación asistida y repartir las conexiones entre varios facilitadores, es decir, crear otros facilitadores que "escuchen" en otros puertos. El mismo problema potencial se puede presentar en los agentes de usuario y en los directores de agentes que inicien los usuarios por utilizar cada grupo un sólo puerto como punto de contacto.

5.2 Las herramientas y tecnologías empleadas

En relación al lenguaje de comunicación elegido, KQML tiene una estructura que permite separar claramente los diferentes componentes de la comunicación. Separa aquellos elementos de bajo nivel que rodean al envío de un mensaje (a quien va dirigido, quien lo envía, etc.) del contenido real del mensaje definido por un conjunto de palabras compartidas por los agentes (el vocabulario) y de la intención del mensaje (performativa). El lenguaje también promueve y toma en cuenta la autonomía de los agentes al conceptualizar la comunicación como un intercambio de mensajes con intención entre sistemas independientes que persiguen diferentes metas y no como mensajes que realmente son comandos o llamadas a funciones entre elementos fuertemente ligados y dependientes.

Adicionalmente se puede resaltar la característica de KQML de soportar una comunicación asíncrona y la flexibilidad que ofrece en cuanto a la posibilidad de definir performativas propias y de incluir parámetros adicionales que incluyan información extra dentro del mensaje. El conjunto de performativas no fue necesario extenderlas, ya que el conjunto estándar del lenguaje bastó para definir el protocolo de comunicación entre los distintos elementos que componen MICK. La facilidad de añadir parámetros a los mensajes fue ampliamente aprovechada para incluir datos como los identificadores, los nombres entre otros.

Además de las ventajas ya mencionadas con las que cuanta KQML, la elección de este lenguaje de comunicación entre agentes se vio influenciada por la amplia disponibilidad de implementaciones del lenguaje y herramientas que facilitan su uso. Una alternativa a KQML la ofrece FIPA [1997], quien define un lenguaje para comunicación entre agentes, que sigue la misma estructura de los mensajes KQML, con la diferencia de que son otras las performativas que utiliza, propone parámetros adicionales y define más formalmente la semántica del lenguaje, además de que propone varios protocolos de interacción.

Para expresar el contenido de los mensajes no se utilizó un lenguaje como KIF (ver sección 2.4.2), únicamente se definió un vocabulario compartido por todos los elementos. Esta elección, comparada con la de un lenguaje formal, reduce el poder de expresividad, pero hace menos compleja su interpretación. Se observa que el vocabulario consta de pocas palabras, gracias a que el lenguaje hace posible diferenciar por medio de las performativas dos mensajes que tengan en su contenido las mismas palabras. Esta característica ayudó a simplificar y estructurar la interpretación del contenido de los mensajes por parte de los ruteadores.

El lenguaje de programación empleado para implementar tanto MICK como la nueva versión del UAD fue Java, básicamente por ser un lenguaje orientado a objetos que cuenta con un gran soporte, que permite crear aplicaciones accesibles a través de un navegador de red (applet) y que elimina el problema de interoperatividad entre plataformas.

JATLite, como herramienta para construir aplicaciones multiagentes, proporcionó funcionalidades esenciales para la comunicación entre agentes, no requirió de ningún proceso de configuración o instalación en sí y su utilización fue sencilla al ser ésta un conjunto de paquetes estructurados en capas. Una limitación de esta herramienta es que sólo apoya la coordinación centralizada de los agentes a través de ruteadores, cuando algunos autores como Chauhan [1998] argumentan que los sistemas multiagentes se deben caracterizar por un alto grado de descentralización y un bajo grado de control global para poder explotar todo el potencial de los sistemas multiagentes. El mismo autor advierte que JATLite no define ninguna metodología para especificar el comportamiento social de los agentes y propone entonces en su tesis un marco para el desarrollo e implementación de sistemas multiagentes llamado JAFMAS, que consiste de tres elementos: 1) una metodología para desarrollar sistemas multiagentes basados en la teoría de actos del habla 2) una arquitectura para agentes y 3) un conjunto de clases en Java para soportar la implementación de estos agentes.

5.3 La nueva versión del UAD

La implementación del UAD utiliza las facilidades que ofrece MICK y simplifica la interacción de los usuarios finales de la biblioteca con las instancias de agentes y con las clases de agentes, haciéndolos accesibles en una misma interfaz. Una ventaja importante es que los usuarios pueden indicar varias acciones en forma concurrente, es decir, el usuario no se ve obligado a esperar que se complete la acción solicitada sobre un agente para poder realizar otra acción con otra instancia. Esto se debe tanto al uso de procesos independientes que manejan la comunicación como a la característica de KQML de soportar asincronía en el envío de mensajes.  


Capítulo 6

Conclusiones

En este último capítulo se presenta un resumen de este proyecto de tesis, retomando el contexto y la importancia de los temas investigados y desarrollados. Igualmente, se describe el trabajo que se puede llevar a cabo a futuro para mejorar y extender el proyecto presentado aquí.

6.1 Resumen del proyecto

En este proyecto de tesis se investigó sobre los medios y las tecnologías actualmente disponibles en el área de comunicación en sistemas multiagentes y bibliotecas digitales, para aplicarlas en el contexto de una biblioteca digital florística. La investigación se enfocó sobre KQML, un popular lenguaje de comunicación entre agentes, y sobre CORBA, una arquitectura basada en el paradigma orientado a objetos propuesto por el consorcio de software más grande del mundo (OMG).

Ambas tecnologías están siendo aplicadas en proyectos de bibliotecas digitales y ambas son parte de un esfuerzo por lograr el gran reto de la interoperatividad entre sistemas. Este reto ha sido muy importante durante los últimos años y seguirá siéndolo debido a la gran variedad de sistemas computacionales, repositorios de información y aplicaciones que se siguen generando. En el contexto de bibliotecas digitales la interoperatividad significa acercar las diversas colecciones intelectuales y culturales y de esta manera lograr un entendimiento más profundo y una cooperación más extensa entre las personas.

Durante el desarrollo de este proyecto, se diseñó e implementó un marco de inter-comunicación basado en KQML al que se denominó MICK, el cual satisface las necesidades de comunicación entre componentes de una biblioteca digital florística (FDL). Estos componentes incluyen un director de agentes de usuario (UAD), los agentes de usuario que están siendo desarrollados y los servicios de biblioteca activa (ALiS).

MICK define una arquitectura por coordinación asistida y consta de un elemento mediador llamado facilitador, un ruteador de mensajes asociado a cada componente de la arquitectura de la FDL que tiene necesidades de comunicación, un protocolo de comunicación, un lenguaje de comunicación (KQML) y un vocabulario. Además de MICK, también se desarrolló una nueva versión del UAD que utiliza las funcionalidades de MICK.

6.2 Trabajo a futuro

MICK satisface las necesidades actuales de comunicación tanto del UAD como de los agentes de usuario desarrollados en Java. Sin embargo, existen componentes, específicamente el UAM y algunos agentes de usuario, que fueron implementados con la interfaz CGI que no pueden utilizar directamente el ruteador de mensajes KQML que ofrece MICK. Una alternativa factible para que el UAM pueda aprovechar lo que ofrece MICK es la de crear, al igual que el UAD, una nueva versión en Java de este componente que tome en cuenta desde su diseño la disponibilidad de los servicios de comunicación (esta implementación sería mucho más sencilla que la implementación original dado las facilidades que ofrece MICK). Para los agentes de usuario no implementados en Java existen dos opciones para que participen en la comunicación. Una opción es crear un ruteador de mensajes KQML en C para que pueda ser utilizado por los agentes sin problema y la otra es utilizar la implementación disponible de CORBA (ILU) para convertir en un objeto CORBA al ruteador de mensajes creado en Java para que pueda ser utilizado por estos agentes.

Una mejora interesante se puede lograr incrementando el número de servicios que ofrece el facilitador, en especial, aquel servicio que permitiera a los agentes de usuario colaborar entre sí. Esto significa que el facilitador además de las funcionalidades que ya tiene, tendría que ser capaz de recibir mensajes donde los agentes manifiesten sus temas de interés, capacidades y necesidades para que el facilitador encuentre por ellos otros agentes con los que puedan colaborar.  


Bibliografía

  Atkins, D., Birmingham, W., Durfee, E., Glover, E., Mullen, T., Rundensteiner, E., Soloway, E., Vidal, J:M., Wallace, R., y Wellman, M. 1996. Toward inquiry-based education through interacting software agents. IEEE Computer, (Mayo), 69-81. (Disponible electrónicamente en: http://computer.org/computer/dli/r50069/r50069.htm).

Cabrera, J. 1997. Integración de servicios y agentes de usuarios en la recuperación de información en una biblioteca digital. Tesis. Departamento de Ingeniería en Sistemas Computacionales. Universidad de las Américas-Puebla.

Chauhan, D. 1998. JAFMAS, a Java-based agent framework for multiagent systems development and implementation. Tesis. Departamento de Ciencias Computacionales e Ingeniería Eléctrica. Universidad de Cincinnati. (Disponible electrónicamente en: http://www.ececs.uc.edu/~abaker/JAFMAS/ ).

Finin, T., Labrou, Y., y Mayfield, J. 1995. KQML as an agent communication language. Reporte técnico. Departamento de Ciencias Computacionales. Universidad de Maryland Baltimore County. Baltimore, MD. (Disponible electrónicamente en: http://www.cs.umbc.edu/kqml/papers/).

FIPA. 1997. Agent communication language. Especificación FIPA 97 1.0, 2. Foundation for Intelligent Physical Agents. Ginebra, Suiza. (Disponible electrónicamente en: http://drogo.cselt.stet.it/fipa/spec/fipa97/fipa97.htm)

Fox, E., Akscyn, R., Furuta, R., y Leggett, J. 1995. Digital libraries. Communications of the ACM 38, 4, 23-28.

Fox, E., y Marchionini, G. 1998. Toward a worldwide digital library. Communications of the ACM 41, 4, 29-32.

Genesereth, M. R., y Ketchpel, S. P. 1994. Software agents. Communications of the ACM 37, 7, 48-53. (Disponible electrónicamente en: http://logic.stanford.edu/sharing/papers/agents.ps).

Genesereth, M. R., Singh, N. P., y Syed, M. A. 1994. A distributed and anonymous knowledge sharing approach to software interoperation. Reporte técnico. Departamento de Ciencias Computacionales. Universidad de Stanford. Menlo Park, California. (Disponible electrónicamente en: http://logic.stanford.edu/sharing/knowledge.html)

Guha, R.V., y Lenat, D. B. 1994. Enabling agents to work together. Communications of the ACM 37, 7, 127-142.

Guilfoyle, C. 1995. Vendors of agent technology. Seminario UNICOM sobre agentes inteligentes y sus aplicaciones en los negocios. Londres, 135-142

Haddadi, A. 1996. Communication and cooperation in agent systems. A pragmatic theory. En Lectures Notes in Artificial Intelligence 1056. Springer-Verlag, 45-49.

Jeon, H.1997. JATLite overview. http://java.stanford.edu/java_agent/html/JATLiteOverview.htm. Universidad de Stanford.

Kahn, R. E., y Cerf, V. G. 1988. The Digital Library Proyect. Volume 1: The World of Knowbots. Corporation for National Research Initiatives, Reston, Va.

Labrou, Y., y Finin, T. A proposal for a new KQML specification. Reporte técnico. Departamento de Ciencias Computacionales e Ingeniería Eléctrica. Universidad de Maryland Baltimore County, Baltimore, Maryland 21250. (Disponible electrónicamente en: http://www.cs.umbc.edu/kqml/papers/).

Lashkari, Y., Metral, M., y Maes, P. 1994. Collaborative interface agents. Proceedings of AAAI? 1994. (Disponible electrónicamente en: http://agents.www.media.mit.edu/groups/agents/papers/aaai-ymp/aaai.html).

Laurel, Brenda. 1990. Interface agents: methapors with character. En The Art of Human Computer Interface Design, Brenda Laurel, Ed. Addison Wesley.

Mayfield, J., Labrou, Y. y Finin, T. 1995. Evaluation of KQML as an agent communication language. Reporte técnico. Departamento de Ciencias Computacionales e Ingeniería Eléctrica. Universidad de Maryland Baltimore County. Baltimore MD 21228-5398. (Disponible electrónicamente en: http://www.cs.umbc.edu/kqml/papers/).

Mowbray, Thomas J. y Malveau, Raphael C. 1997. CORBA Design patterns. Wiley Computer Publishing.

Otte, Randy, Patrick, Paul, y Roy, Mark. 1996 Understanding CORBA. Prentice Hall.

Röscheisen, M., Baldonado, M., Chang, K., Gravano, L., Ketchpel, S., y Paepcke, A. 1997. The Stanford InfoBus and its service layers. Artículo en proceso. Departamento de Ciencias Computacionales. Universidad de Stanford, CA 94395. (Disponible electrónicamente en: http://www-diglib.stanford.edu/cgi-bin/WP/get/SIDL-WP-1997-0065).

Sánchez, J. A. 1997. A taxonomy of agents. Reporte técnico. ICT-97-1. Laboratorio de Tecnologías Interactivas y Cooperativas. Universidad de las Américas-Puebla, Cholula, Pue. 72820.

Sánchez, J. A. 1996. Agent services. Ph D. Dissertation. Departamento de Ciencias Computacionales, Universidad Texas A&M, College Station, Tex., Agosto.

Sánchez, J.A. y Leggett, J.J. 1997. Agent services for users of digital libraries. Journal of networks and computer applications, 21, 1.

Singh, Narinder P. y Gisi, Mark A. 1995. Coordinating distributed objects with declarative interfaces. Reporte técnico. Departamento de Ciencias Computacionales. Universidad de Stanford, Stanford, California 94305. (Disponible electrónicamente en: http://logic.stanford.edu/sharing/knowledge.html).