Agentes de software móviles: un paradigma alternativo para … · 2011. 6. 2. · 2.5.1 Los...

Agentes de software móviles: un paradigma alternativo para diseñar sistemas distribuidos

Carla Mónica Capart - Marcia Silvana Stippi

Director de tesina: Ing. Alejandro Rosales

Tesina presentada a la Facultad de Ingeniería de la Universidad Nacional de la Patagonia San Juan Bosco como parte de los requisitos para la obtención del título de Licenciado en Informática

Trelew, diciembre de 2006

Facultad de Ingeniería – Sede Trelew

Universidad Nacional de la Patagonia San Juan Bosco

Agradecimientos

De Carla:

A mi esposo Rodrigo y a mi hijito Franco, por comprenderme y perdonarme por todo el

tiempo que les he quitado.

A mamá, papá y mi hermano Alejandro, por valorar y apoyar siempre mis decisiones y

proyectos.

A mis suegros, por su acompañamiento durante la realización de este trabajo.

De Marcia:

A mi esposo Alexis, por su paciencia sin límites y su aliento constante.

A toda mi familia, especialmente a mis padres, por inculcarme la importancia del estudio y ser

un ejemplo de perseverancia y esfuerzo.

De Carla y Marcia:

Al Ing. Alejandro Rosales, por su dirección y sus sugerencias durante el desarrollo de esta

tesina.

Carla M. Capart - Marcia S. Stippi Pág.: 1

Resumen

Un agente móvil es una entidad de software que tiene la capacidad de migrar en forma

autónoma entre los nodos de una red. Para ello, suspende su ejecución, se transporta con su

código, datos y estado de ejecución, y continúa ejecutándose en el nodo destino.

En este trabajo, se presenta una aproximación general de la teoría de agentes móviles y

su comparación con otros paradigmas de cómputo distribuido, se mencionan diferentes

arquitecturas utilizadas para construir agentes de software, y se profundizan dos aspectos

principales relacionados con la movilidad: el proceso de migración y la comunicación de

agentes. Finalmente, se desarrolla un ejemplo siguiendo una metodología de análisis y diseño

orientada a agentes con el propósito de facilitar la aplicación de los conceptos teóricos en un

caso práctico.


Índice

CAPÍTULO 1 INTRODUCCIÓN ............................................................................................................... 4 1.1 ORGANIZACIÓN ............................................................................................................................................. 4 1.2 MOTIVACIÓN ................................................................................................................................................. 5 1.3 EL CAMPO DE ESTUDIO .................................................................................................................................. 6 1.4 OBJETIVOS..................................................................................................................................................... 8

1.4.1 Generales .............................................................................................................................................. 8 1.4.2 Particulares .......................................................................................................................................... 8

CAPÍTULO 2 CONCEPTOS BÁSICOS .................................................................................................... 9 2.1 DEFINICIÓN DE AGENTE ................................................................................................................................. 9 2.2 CLASIFICACIÓN DE AGENTES ....................................................................................................................... 10 2.3 DEFINICIÓN DE AGENTE MÓVIL.................................................................................................................... 11 2.4 PARADIGMAS DE DISEÑO DE SISTEMAS DISTRIBUIDOS ................................................................................. 12

2.4.1 Cliente-servidor .................................................................................................................................. 14 2.4.2 Evaluación remota .............................................................................................................................. 14 2.4.3 Código por demanda........................................................................................................................... 15 2.4.4 Agentes móviles como un nuevo paradigma de diseño ....................................................................... 15 2.4.5 Comparación entre paradigmas ......................................................................................................... 16

2.5 BREVE HISTORIA DE AGENTES MÓVILES....................................................................................................... 17 2.5.1 Los primeros pasos en código móvil ................................................................................................... 17 2.5.2 Evaluación Remota ............................................................................................................................. 18 2.5.3 Objetos móviles................................................................................................................................... 18 2.5.4 Procesos móviles................................................................................................................................. 19 2.5.5 Agentes móviles................................................................................................................................... 19

2.6 CARACTERÍSTICAS DE LOS AGENTES MÓVILES............................................................................................. 20 2.7 VENTAJAS DE LA UTILIZACIÓN DE AGENTES MÓVILES ................................................................................. 20 2.8 POSIBLES DOMINIOS DE APLICACIÓN ........................................................................................................... 22

CAPÍTULO 3 MODELOS Y ARQUITECTURAS ................................................................................. 23 3.1 ARQUITECTURAS ABSTRACTAS PARA AGENTES INTELIGENTES .................................................................... 23

3.1.1 Agentes puramente reactivos .............................................................................................................. 24 3.1.2 Subsistemas de Percepción y Acción .................................................................................................. 24 3.1.3 Agentes con estado.............................................................................................................................. 25

3.2 TIPOS DE ARQUITECTURAS .......................................................................................................................... 26 3.2.1 Agentes de razonamiento deductivo.................................................................................................... 26 3.2.2 Agentes de razonamiento práctico ...................................................................................................... 29 3.2.3 Agentes reactivos ................................................................................................................................ 31 3.2.4 Agentes híbridos.................................................................................................................................. 33

3.3 ARQUITECTURAS MULTIAGENTES ............................................................................................................... 36 3.4 LA ARQUITECTURA FIPA............................................................................................................................. 39 3.5 ARQUITECTURA MASIF .............................................................................................................................. 42

CAPÍTULO 4 MIGRACIÓN DE AGENTES .......................................................................................... 44 4.1 TERMINOLOGÍA BÁSICA ............................................................................................................................... 44 4.2 ESTRUCTURA DE UN AGENTE MÓVIL............................................................................................................ 45 4.3 CICLO DE VIDA DE UN AGENTE MÓVIL ......................................................................................................... 46



4.4 PROCESO DE MIGRACIÓN DE UN AGENTE ..................................................................................................... 48 4.5 TÓPICOS DE DISEÑO DE LA MIGRACIÓN DE AGENTES.................................................................................... 50

4.5.1 Vista del programador........................................................................................................................ 51 4.5.2 Vista del agente................................................................................................................................... 58 4.5.3 Vista de la red ..................................................................................................................................... 61

4.6 DESVENTAJAS DE LAS TÉCNICAS DE MIGRACIÓN SIMPLES ........................................................................... 62 4.7 RENDIMIENTO DE LOS AGENTES MÓVILES................................................................................................... 63

4.7.1 Aspectos de runtime ............................................................................................................................ 63 4.7.2 Aspectos de transmisión...................................................................................................................... 65

CAPÍTULO 5 COMUNICACIÓN DE AGENTES MÓVILES .............................................................. 68 5.1 TÓPICOS DE COMUNICACIÓN DE AGENTES MÓVILES .................................................................................... 68 5.2 CLASIFICACIÓN DE LOS MODELOS DE COMUNICACIÓN................................................................................. 70

5.2.1 Pasaje de mensajes ............................................................................................................................. 70 5.2.2 Espacio de información ...................................................................................................................... 72

5.3 COMUNICACIÓN TRANSPARENTE DE LA UBICACIÓN..................................................................................... 72 5.3.1 Servidor Central.................................................................................................................................. 73 5.3.2 Servidor Origen .................................................................................................................................. 74 5.3.3 Punteros de Reenvío ........................................................................................................................... 74 5.3.4 Broadcast ............................................................................................................................................ 75 5.3.5 Aproximaciones Jerárquicas............................................................................................................... 76

5.4 COMPONENTES DEL MODELO DE COMUNICACIÓN ........................................................................................ 77 5.5 LENGUAJES DE COMUNICACIÓN................................................................................................................... 78

5.5.1 KQML (Knowledge Query and Manipulation Language) .................................................................. 78 5.5.2 FIPA ACL (FIPA Agent Communication Language).......................................................................... 81

CAPÍTULO 6 PLATAFORMAS PARA AGENTES MÓVILES ........................................................... 85 6.1 CARACTERÍSTICAS DE ALGUNAS PLATAFORMAS.......................................................................................... 85 6.2 ELECCIÓN DE LA PLATAFORMA A UTILIZAR ................................................................................................. 92 6.3 DESCRIPCIÓN DE LA PLATAFORMA ELEGIDA: JADE .................................................................................... 92

6.3.1 Arquitectura de la plataforma............................................................................................................. 92 6.3.2 Modelo de comunicación .................................................................................................................... 95 6.3.3 Características de un agente JADE .................................................................................................... 97 6.3.4 Comportamientos.............................................................................................................................. 101 6.3.5 Modelo de movilidad......................................................................................................................... 102 6.3.6 Requerimientos de software .............................................................................................................. 105 6.3.7 Ejecución de la plataforma............................................................................................................... 105 6.3.8 Principales herramientas gráficas.................................................................................................... 106 6.3.9 Ventajas de la utilización de JADE................................................................................................... 110

CAPÍTULO 7 CASO DE APLICACIÓN ............................................................................................... 114 7.1 PRESENTACIÓN DE LA APLICACIÓN............................................................................................................ 114 7.2 METODOLOGÍAS PARA EL DESARROLLO DE SISTEMAS MULTIAGENTES ...................................................... 116 7.3 ANÁLISIS Y DISEÑO DE LA APLICACIÓN...................................................................................................... 118

7.3.1 Fase de Análisis ................................................................................................................................ 118 7.3.2 Fase de Diseño.................................................................................................................................. 127

7.4 DIAGRAMAS DE CLASES............................................................................................................................. 141 CAPÍTULO 8 CONCLUSIONES............................................................................................................ 146 GLOSARIO ....................................................................................................................................................... 149 APÉNDICE A LUCENE........................................................................................................................... 152 APÉNDICE B INSTRUCTIVO DE LA APLICACIÓN........................................................................ 154 APÉNDICE C MAILS A LISTA DE JADE............................................................................................ 160 BIBLIOGRAFÍA............................................................................................................................................... 169


Capítulo 1 Introducción

1.1 Organización

A través de este trabajo pretendemos ofrecer una primera aproximación al

paradigma de agentes de software, y en particular de agentes de software móviles, mostrando

el estado del arte en lo que respecta a esta tecnología y aplicando una metodología de análisis

y diseño orientada a agentes en el desarrollo de un caso práctico.

Delinearemos a continuación, la secuencia de contenidos que iremos desarrollando

en esta tesina.

En el presente capítulo mencionamos nuestra motivación por el tema elegido;

presentamos el campo de estudio, describiendo de manera general el paradigma de agentes

móviles y cómo se inserta esta nueva tecnología dentro de los sistemas distribuidos actuales; e

incluimos los objetivos de nuestra investigación.

En el capítulo 2 introducimos los conceptos básicos referentes a agentes de software,

y en particular a agentes de software móviles. Detallamos también los paradigmas

tradicionales de diseño de sistemas distribuidos comparándolos con la tecnología de agentes

móviles. Finalmente, describimos brevemente la evolución histórica de los agentes móviles y

los posibles dominios de aplicación de esta tecnología.

En el capítulo 3 presentamos arquitecturas abstractas para el modelado de agentes e

incluimos una clasificación de los tipos de arquitecturas que se utilizan en la actualidad para

construir agentes, la cual se basa en los diferentes modelos de representación del

conocimiento y razonamiento utilizados en el diseño de los agentes. Luego abordamos las

arquitecturas de sistemas multiagentes, mencionando los estándares FIPA y MASIF.

En el capítulo 4 detallamos la estructura de un agente móvil y los pasos que tienen

lugar en el proceso de migración. Luego explicamos los distintos tópicos de diseño

concernientes a la migración de agentes y mencionamos los factores que inciden en el

rendimiento de los mismos.



En el capítulo 5 tratamos los tópicos referentes a la comunicación de agentes

móviles y describimos los distintos modelos de comunicación existentes. Explicamos también

las técnicas que utilizan las plataformas de agentes para permitir que éstos se comuniquen de

manera confiable a medida que van cambiando de ubicación durante la migración.

Finalizando el capítulo, presentamos los lenguajes de comunicación de agentes, mencionando

algunos estándares.

En el capítulo 6 especificamos las características más relevantes de algunas

plataformas para el desarrollo de agentes móviles. Luego presentamos la plataforma elegida

para el desarrollo del caso de aplicación, justificando su elección; a continuación detallamos

las características de esta plataforma y explicamos cómo utilizar el toolkit que provee para

programar agentes móviles.

En el capítulo 7 describimos el caso de aplicación desarrollado, presentamos la

metodología seguida y exponemos los resultados obtenidos en las fases de análisis y diseño,

incluyendo también los diagramas de clases de la aplicación.

Finalmente, en el capítulo 8, exponemos algunas conclusiones del estudio realizado

y sugerimos algunos trabajos que se podrían considerar en el futuro para profundizar en el

conocimiento de esta tecnología y su aplicación.

La tesina concluye con tres apéndices. En el apéndice A, describimos las

características más relevantes de Lucene, la librería utilizada en la aplicación desarrollada

para confeccionar los índices y realizar las búsquedas en los documentos. En el apéndice B

incluimos información sobre los requerimientos y la configuración del programa, así como

también el instructivo de uso. En el apéndice C recopilamos los mails intercambiados con los

desarrolladores de la plataforma utilizada.

1.2 Motivación

La tecnología de agentes móviles plantea para nosotras un nuevo universo dentro del

diseño de sistemas distribuidos, ya que es un tema que trasciende las fronteras de los

contenidos abordados en materias como Redes y Transmisión de Datos y Sistemas

Distribuidos, de la Licenciatura en Informática, en las cuales hemos estudiado algunas

técnicas tradicionales de distribución de código como cliente-servidor (aplicaciones basadas

en RPC, RMI, etc.) o código bajo demanda (por ejemplo, Applets en lenguaje Java).



Teníamos conocimiento del auge de la mencionada tecnología y de las afirmaciones de

investigadores que la proponen como una solución promisoria para satisfacer las demandas

del usuario de hoy, que surgen de la computación nómada y del uso creciente de las redes

inalámbricas, entre otras tendencias actuales. Estas demandas conllevan a buscar soluciones

tan dinámicas y móviles como los usuarios finales. Esto nos llevó a interiorizarnos sobre el

tema ya que concebimos como profesionales en informática, que para aplicar una tecnología

es importante conocer, además del uso de las herramientas, los fundamentos que la sustentan.

Todo lo expuesto nos orientó a enfocar la investigación en los mecanismos utilizados

para implementar la movilidad y a profundizar sobre los aspectos de diseño relacionados con

el proceso de migración y la comunicación de los agentes móviles, ya que consideramos que

en ambientes distribuidos con ciertas características (entornos abiertos y cambiantes, con

redes heterogéneas y con conexiones de red de distinta calidad) la tecnología de agentes

móviles se convierte en una herramienta que se debe tener en cuenta a la hora de diseñar

sistemas distribuidos.

1.3 El campo de estudio

Como consecuencia de los avances de los últimos años en las tecnologías de redes y

computación, los sistemas distribuidos, antes compuestos por un conjunto de computadoras

homogéneas, con igual tipo de procesador y de sistema operativo, conectadas por una red

dedicada, evolucionaron permitiendo la conexión de un gran número de computadoras

heterogéneas.

Internet ha sido ampliamente aceptada como un medio de intercambio de información

muy importante, incrementándose continuamente el número de usuarios y el número de

servicios ofrecidos en la red. El proceso de encontrar los datos más adecuados para un usuario

se ha convertido en una tarea sumamente compleja, llevando al desarrollo de nuevas técnicas

inteligentes para búsqueda, filtrado y gestión de datos con el fin de optimizar el uso de los

recursos compartidos. Sumado a esto, han surgido nuevas tendencias que van tomando

importancia, tales como el uso de redes inalámbricas y la computación nómada, la cual

implica que los usuarios deben poder conectarse desde diferentes lugares y dispositivos y ver

uniformemente los mismos datos y aplicaciones. Braun y Rossak (2005) sostienen que estas



tendencias requerirán la utilización de técnicas basadas en principios de comunicación entre

pares (peer-to-peer), más que paradigmas centralizados como cliente-servidor.

Es en este contexto que la tecnología de agentes de software móviles ofrece un

paradigma de diseño de sistemas distribuidos alternativo a otras técnicas de cómputo

distribuido más tradicionales, como cliente-servidor, código bajo demanda o evaluación

remota. Este paradigma se basa en la utilización de código móvil y acepta la distribución

como concepto básico, ofreciendo además nuevas características que permiten alcanzar un

nuevo nivel de abstracción y calidad.

Así como la programación orientada a objetos ofrece un mayor nivel de abstracción

que la programación estructurada, facilitando el desarrollo y el mantenimiento del software, la

teoría de agentes, y en particular la de agentes móviles, otorga una serie de mecanismos que

permiten dar un paso más allá en el desarrollo de sistemas informáticos distribuidos,

agregando características como la interacción dinámica de componentes de software

autónomos y heterogéneos.

Un agente de software es un programa capaz de interactuar en forma autónoma con el

ambiente en el cual se encuentra, a fin de lograr sus objetivos. Un agente móvil es un tipo

especial de agente de software, que tiene la capacidad de suspender su ejecución, moverse a

otro nodo de la red transportando su código, datos y estado de ejecución, y continuar

ejecutándose en el nodo destino.

Los agentes móviles ayudan a los usuarios a operar en entornos dinámicos y

distribuidos que exigen que el software, además de responder a los requerimientos del

usuario, se adapte a las circunstancias, se anticipe e intente solucionar los inconvenientes que

se presentan sin la intervención del mismo.

La diferencia principal entre el paradigma de agentes móviles y los otros

mencionados, consiste en que los agentes poseen la capacidad de controlar su propia

localización en una red, con el fin de desplazarse en forma autónoma hacia donde se

encuentran los recursos – tanto de hardware como de información – que necesita para llevar a

cabo determinada tarea. Esta característica se traduce en ventajas como la reducción del

tráfico en la red, la eliminación de latencia de red en aplicaciones de tiempo real y la

posibilidad de operar sin conexión, las cuales resultan muy beneficiosas para los usuarios que

utilizan computadoras portátiles, con baja capacidad de proceso o con poco espacio de

almacenamiento y los que tienen bajo ancho de banda en la red.



1.4 Objetivos

1.4.1 Generales

Investigar el paradigma de agentes de software, en particular, aquellos denominados

móviles.

Desarrollar un ejemplo de aplicación práctica que utilice la tecnología de agentes móviles.

1.4.2 Particulares

Estudiar las características generales de agentes, así como también su clasificación y los

diferentes problemas en los cuales encuentran aplicación.

Investigar ventajas/desventajas del paradigma de agentes móviles respecto a otros

tradicionales como cliente-servidor.

Presentar las distintas arquitecturas, modelos de movilidad y de comunicación de agentes

móviles.

Diseñar e implementar una aplicación basada en agentes móviles de tal forma de poder

aplicar en forma práctica los conceptos teóricos investigados.

Investigar las plataformas existentes que permiten la implementación de agentes móviles,

a fin de seleccionar una de ellas para el desarrollo de la aplicación práctica.


Capítulo 2 Conceptos básicos

En este capítulo se presentarán los conceptos básicos referentes a agentes de

software, y en particular a agentes de software móviles: definición, clasificación, orígenes,

ventajas y posibles dominios de aplicación. Además se describirán brevemente algunos

paradigmas tradicionales de diseño de sistemas distribuidos, comparándolos con la tecnología

de agentes móviles.

2.1 Definición de agente

El término agente viene del latín agere que significa hacer. Agente deriva del

participio agens. Expresa la capacidad de acción o actuación de una entidad.

En las Ciencias de la Computación, el término agente ha sido usado desde mediados

de la década del 70 y fue introducido por el área de la Inteligencia Artificial.

No existe una definición universalmente aceptada para el término agente de

software, ya que ésta se ve influenciada por las diferentes áreas en las que los agentes se han

aplicado, como la Inteligencia Artificial, los Sistemas Distribuidos, la Ingeniería de Software,

etc. En el presente trabajo se abordará la definición desde el punto de vista de los Sistemas

Distribuidos: “un agente es una entidad de software con una arquitectura robusta y

adaptable que puede funcionar en distintos entornos o plataformas computacionales y es

capaz de realizar de forma inteligente y autónoma distintos objetivos intercambiando

información con el entorno, o con otros agentes humanos o computacionales” (Garijo, 2002:

2). La entidad de software involucrada puede ser un programa de computadora, un

componente de software, o, en términos de lenguajes orientados a objetos, simplemente un

objeto. Sin embargo, los verdaderos agentes de software, deben considerarse como una

extensión más general del concepto de objetos o componentes de software, ya que mientras

los objetos de software son pasivos, los agentes son activos.



La definición de qué constituye exactamente un agente de software ha sido y

continúa siendo debatida por la comunidad de investigadores. Sin embargo, existe un acuerdo

común en que un agente debe exhibir algunas características mínimas para ser calificado

como tal. Dichas características son:

Autonomía: los agentes operan y funcionan de acuerdo con sus propios planes, no

necesitan seguir un orden en la ejecución del plan dado por su propietario y no necesitan

pedirle confirmación al mismo para ejecutar cada tarea (Braun y Rossak, 2005: 9).

Comportamiento Social: los agentes interactúan con otros agentes o humanos mediante

algún mecanismo de comunicación. Esta comunicación puede restringirse a un

intercambio puro de información o puede incluir sofisticados protocolos de negociación

(Braun y Rossak, 2005: 9).

Reactividad: los agentes perciben su ambiente y responden a los cambios de éste

(Wooldridge, 2005: 23).

Proactividad: los agentes no solo actúan en respuesta a su ambiente, sino que son capaces

de tomar la iniciativa y tener comportamiento orientado a metas para satisfacer sus

objetivos de diseño (Wooldridge, 2005: 23).

2.2 Clasificación de agentes

Al igual que sucede con la definición de agentes de software, no hay una sola

clasificación posible de los mismos.

En base a sus capacidades de resolver problemas se clasifican en:

Agentes reactivos: realizan tareas sencillas. Reaccionan a cambios en su ambiente o a

mensajes provenientes de otros agentes. No son capaces de razonar acerca de sus

intenciones. Sus acciones se realizan como resultado de reglas establecidas.

Agentes cognitivos: realizan tareas complejas. Son capaces de razonar acerca de sus

intenciones y conocimientos, crear planes de acción y ejecutar dichos planes. Utilizan

algún tipo de representación explícita (simbólica) del conocimiento. Además, pueden

tener la capacidad de aprender en base a su experiencia.

En base a su movilidad:



Agentes estáticos: son entidades que permanecen siempre fijas en un nodo, es decir, no se

les permite migrar.

Agentes móviles: son entidades de software capaces de viajar por redes de computadoras

visitando distintos nodos a fin de realizar las tareas necesarias para cumplir con sus

objetivos de diseño. Una vez concluido su trabajo pueden regresar a su lugar de origen o

eliminarse.

En base a la tarea que desempeñan:

Agentes colaborativos: enfatizan su autonomía y cooperación (con otros agentes) para

llevar a cabo tareas para sus propietarios.

Agentes de interfaz: asistentes personales que colaboran con el usuario en un ambiente

dado. Soportan y proveen asistencia al usuario observándolo y sugiriéndole otras formas

de realizar las acciones.

Agentes de entretenimiento: agentes que proveen al usuario de algún tipo de

entretenimiento (por ejemplo, juegos).

Agentes de información: también se conocen como agentes web, de búsqueda, spiders,

worms, robots o crawlers. Realizan la tarea de administrar, manipular o recolectar

información proveniente de varias fuentes distribuidas.

Agentes híbridos: son aquellos que en su funcionamiento poseen la combinación de dos o

más de las capacidades de los tipos mencionados.

Con respecto a los agentes de información, cabe mencionar que su uso más

difundido está dado por los motores de búsqueda (google, yahoo, etc.) para buscar en páginas

web y construir índices automáticamente. Los agentes web convencionales son estáticos; se

conectan a los servidores web mediante el protocolo HTTP para solicitar una página html y la

procesan en forma local. Sin embargo, existen agentes web móviles que migran a los

servidores web y realizan su tarea utilizando los recursos del nodo destino.

2.3 Definición de agente móvil

Los agentes de software móviles se definen como “programas de computadora

completos e identificables, empaquetados con su código, datos, y estado de ejecución, que

pueden moverse dentro de una red heterogénea de sistemas de computación. Ellos pueden



suspender su ejecución en un punto arbitrario y transportarse a sí mismos a otro sistema de

computación. Durante esta migración el agente es transmitido completamente, esto es, como

un conjunto de código, datos, y estado de ejecución. En el sistema de computación destino, la

ejecución de un agente es reanudada exactamente en el punto donde fue suspendida antes”

(Braun y Rossak, 2005: 11).

Desde el punto de vista de los Sistemas Distribuidos, la tecnología de agentes

móviles se puede considerar como un paradigma de diseño adicional en el área de la

programación distribuida y un suplemento útil a otros paradigmas tradicionales tales como

cliente-servidor, los cuales se tratarán en la próxima sección.

2.4 Paradigmas de diseño de sistemas distribuidos

Para presentar los distintos paradigmas de diseño se partirá de la definición de

sistema distribuido. Según Tanenbaum y Van Steen (2002: 2) “un sistema distribuido es una

colección de computadoras independientes que se presentan a sus usuarios como un solo

sistema coherente”. Para lograr satisfacer esta definición, este tipo de sistemas se organiza

frecuentemente en una jerarquía de capas de software como se muestra en la figura 2.1.

Figura 2.1: Sistema distribuido estructurado como middleware

La capa inferior, ubicada sobre el hardware, está conformada por el sistema

operativo (S.O.), que provee servicios básicos tales como la administración de archivos,

Aplicaciones Distribuidas

Sitio

Sitio

Sitio

Sistema Operativo Sistema Operativo Sistema Operativo

Sistema Operativo de Red Sistema Operativo de Red Sistema Operativo de Red

Hardw

are

Middleware



memoria y procesos. Sobre la capa del S.O. se localiza el sistema operativo de red, que

provee servicios de comunicación dependientes de la localización de los recursos (por

ejemplo, sockets). Entre el sistema operativo de red y las aplicaciones se encuentra ubicada

una capa denominada middleware, que oculta la heterogeneidad de las plataformas

subyacentes y brinda transparencia de distribución a dichas aplicaciones.

Los sistemas distribuidos que ofrecen movilidad de código presentan una

perspectiva diferente, ya que no ocultan la estructura de la red a los programadores. En estos

sistemas, la capa middleware no brinda transparencia de distribución, sino que provee un

entorno de ejecución el cual permite que los componentes de software migren de un sitio a

otro de la red (ver figura 2.2).

De acuerdo con lo explicado anteriormente, se puede resaltar que la diferencia entre

un sistema distribuido que provee movilidad de código y uno que no, se encuentra en el hecho

de que, en el primero, el programador debe tener en cuenta la localización de los componentes

de software. Esto último, sumado a la capacidad de movilidad que posee cada componente,

influye directamente en el modo en que éstos interactúan con los recursos, dependiendo de si

son locales o remotos.

Figura 2.2: Sistema distribuido que provee movilidad de código

A continuación se mencionan tres paradigmas tradicionales de diseño de sistemas

distribuidos. El primero, cliente-servidor, se incluye por su amplia difusión aunque no

presenta la característica de movilidad. Los dos restantes, evaluación remota y código por

Sitio

Sitio

Sitio

Sistema Operativo

Sistema Operativo

Sistema Operativo

Sistema Operativo de Red Sistema Operativo de Red Sistema Operativo de Red

Hardw

are

Aplicaciones Distribuidas

Entorno de Ejecución Entorno de Ejecución Entorno de Ejecución



demanda, sí explotan la noción de movilidad de código. Por último, se presenta un paradigma

alternativo de diseño de sistemas distribuidos basado en agentes móviles.

En lo que resta de esta sección se utilizarán los siguientes términos:

Sitio: representa una localidad en un sistema distribuido, por ejemplo, una simple

computadora como parte de una red.

Recursos: los recursos de un sitio son cualquier tipo de archivo, base de datos, o cualquier

dispositivo externo.

Interacción: cualquier relación entre código o recursos del mismo o distintos sitios.

2.4.1 Cliente-servidor

Cliente-servidor es, en el presente, el paradigma de computación distribuida más

común (figura 2.3). En él, un sitio que actúa como servidor ofrece un conjunto de servicios.

Otro sitio, el cliente, requiere de alguno de esos servicios para completar su tarea; entonces,

envía al servidor un requerimiento por un servicio específico usando una interacción. El

servidor ejecuta el servicio requerido utilizando recursos locales y envía el resultado al cliente

usando otra interacción. En este paradigma, todos los componentes son inmóviles con

respecto a su ejecución, no existe código móvil. El requerimiento usualmente contiene el

nombre del servicio junto con algunos parámetros adicionales.

Este concepto es usado, por ejemplo, en Remote Procedure Call (RPC), Remote

Method Invocation (RMI) y CORBA. En los últimos años, ha ganado popularidad una nueva

técnica cliente-servidor para sistemas distribuidos, denominada Web Services. Mientras que

las aplicaciones basadas en CORBA o RMI se desarrollan principalmente para ser ejecutadas

en redes de área local (intranets), los web services son componentes de software distribuidos

ampliamente en Internet.

2.4.2 Evaluación remota

A diferencia del paradigma anterior, en este caso el cliente envía un fragmento de

código al servidor para que sea ejecutado allí, como se muestra en la figura 2.4. El servidor

ejecuta el código utilizado recursos locales y luego envía el resultado al cliente usando una

interacción. Aquí el código es móvil y se envía desde cliente a servidor. El tipo de código

depende de la implementación concreta del paradigma, puede ser algún tipo de script que se

transmite como código fuente o algún formato de código intermedio que puede ser



interpretado fácilmente por el servidor. Por ejemplo, el lenguaje PostScript utilizado por

algunas impresoras, permite que una aplicación interactúe con la misma enviándole

programas PostScript. Dichos programas son ejecutados por la impresora, por lo tanto pueden

utilizar los dispositivos de impresión tales como el tóner, tractor, etc., los cuales en este caso

cumplirían el rol de recursos. Este esquema permite flexibilizar al máximo las capacidades de

software de la impresora (por ejemplo, se utiliza para descargar fuentes en el disco rígido de

la impresora), a la vez que permite alivianar la carga de CPU de la computadora que utiliza la

impresora.

2.4.3 Código por demanda

En este paradigma se invierten los roles con respecto a evaluación remota, ya que en

este caso el código viaja de servidor a cliente (figura 2.5). Éste último tiene acceso a sus

recursos pero el código para accederlos se encuentra en el servidor, el código se envía del

servidor al cliente y se ejecuta allí. El ejemplo más claro de esta técnica son los applets del

lenguaje Java.

2.4.4 Agentes móviles como un nuevo paradigma de diseño

En este paradigma, el código, mientras se está ejecutando en un sitio, determina que

necesita acceder a algún recurso actualmente localizado en otro sitio. Los dos sitios

interactúan de forma tal que el código se transmite al sitio destino, junto con alguna

información acerca del estado de ejecución actual. En el sitio destino, el código se continúa

ejecutando, accediendo a los recursos locales. Más tarde, puede decidir que necesita recursos

de otros sitios, y entonces, migrar nuevamente hacia otro sitio.

Figura 2.3: Cliente-Servidor

Cliente Servidor

Sitio A Sitio B

C C R Requerimiento (1)

Respuesta (2)

Referencias C: Componente de código R: Recurso F: Fragmento de código



Figura 2.4: Evaluación Remota

Figura 2.5: Código por demanda

Figura 2.6: Paradigma de agentes móviles

2.4.5 Comparación entre paradigmas

La diferencia principal entre el paradigma cliente-servidor y los demás mencionados

es que en el primero el código permanece en una ubicación fija, en cambio, en los otros la

localización puede variar, transformándolos en modelos más flexibles y configurables. Al

mismo tiempo estos paradigmas, con la posibilidad de movilidad de código que brindan,

promueven la descomposición de la aplicación en varios componentes simples. Esta

característica es aprovechada al máximo por el paradigma de agentes móviles, en el cual se

aspira, además, a que cada componente sea autónomo. De esa manera, las aplicaciones se

Sitio A Sitio B Sitio C

C C C R R Migración (1)

Migración (2)

Migración (3)

Cliente Servidor

Sitio A Sitio B

R C F C F

Req. de código(1)

Código (2)

Cliente Servidor

Sitio A Sitio B

F C RFCódigo (1)

Respuesta (2)



constituyen de varios agentes, cada uno de los cuales realiza una tarea específica, tratando de

minimizar las interacciones remotas con otros componentes.

Otro aspecto a considerar cuando se compara entre los paradigmas cliente-servidor y

agentes móviles es el nivel de granularidad de servicios ofrecidos por cada uno. En cliente-

servidor, para proveer un nivel de granularidad alto, es decir para que el servidor cumpla

exactamente el servicio que el cliente necesita, éste último tiene que realizar varias llamadas a

procedimientos remotos para satisfacer sus requerimientos. Esta secuencia de llamadas a

través de la red incrementa en gran medida el tráfico sobre la misma, especialmente cuando se

envían grandes volúmenes de datos, viéndose perjudicado el rendimiento de todo el sistema.

En cambio, en agentes móviles, la flexibilidad y reusabilidad de los servicios se incrementan

considerablemente, aumentando el nivel de granularidad ofrecido por cada agente.

2.5 Breve historia de agentes móviles

2.5.1 Los primeros pasos en código móvil

La idea de enviar código en un formato independiente de la arquitectura hacia

diferentes hosts en una red fue introducida, probablemente por primera vez, en 1969 por

Rulifson y sus colaboradores en el desarrollo del lenguaje de programación DEL (Decode-

Encode-Language) (Braun y Rossak, 2005: 18). La idea era comunicarse a un host remoto y

descargar un programa al comienzo de la sesión. Dicho programa, escrito en DEL, podía

entonces controlar la comunicación y usar eficientemente el ancho de banda disponible entre

el host del usuario local y el host remoto.

Aproximadamente diez años más tarde, un grupo de investigación de una Universidad

en Suiza tuvo la idea de construir una red de radio orientada a paquetes, llamada Softnet.

Cada paquete enviado por la red era un programa escrito en lenguaje FORTH, y cada nodo de

red que recibía el paquete ejecutaba inmediatamente el programa. Usando esta técnica, cada

usuario podía proveer a cada nodo de la red de nuevos servicios. En 1982, se hicieron los

primeros experimentos con software móvil para la empresa Xerox, los cuales consistían en

gusanos (worms) que buscaban en una red de área local procesadores ociosos.



2.5.2 Evaluación Remota

Joseph R. Falcone abordó, en 1987, el problema de proveer interfaces específicas del

cliente para servicios remotos a través de un sistema distribuido heterogéneo (Braun y

Rossak, 2005: 18). En lugar de ofrecer una interfaz simple con muchas funciones pequeñas

para satisfacer a una gran cantidad de clientes, Falcone buscaba habilitar a los clientes para

que programen sus propias interfaces, usando un nuevo lenguaje de programación llamado

NCL (Network Command Language). En NCL un cliente envía una expresión al servidor, el

cual ejecuta la expresión usando funciones estándar provistas en forma de una librería. El

servidor envía el resultado (otra expresión) hacia el cliente, el cual puede comenzar otra vez el

proceso.

Hubo otras aproximaciones similares a NCL, por ejemplo, REV (Remote-Evaluation),

el cual extendía la idea de llamadas a procedimientos remotos (RPC) surgida en 1984. En

REV, un cliente enviaba un requerimiento hacia el servidor en la forma de un programa. El

servidor ejecutaba el programa y enviaba el resultado al cliente.

2.5.3 Objetos móviles

Un paso más hacia la tecnología de agentes móviles fue la incorporación de un

mínimo tipo de autonomía al concepto de mensajería. Esta técnica se conoció como objetos

móviles. La idea era crear mensajes activos, es decir, mensajes que eran capaces de migrar

hacia host remotos. Un mensaje contenía datos y algo de código de programa que era

ejecutado en cada servidor. Sin embargo, en este concepto, dominaba la porción de datos por

sobre la porción activa (es decir, el código).

El proyecto Messengers propuso en 1996 el concepto de objetos autónomos, los que se

llamó mensajeros. Los mensajeros eran capaces de migrar autónomamente a través de una

LAN de servidores dedicados que aceptaban esos objetos. La diferencia con respecto a las

técnicas descriptas previamente es que un mensajero no se transfería únicamente a un servidor

remoto sino que era capaz de migrar autónomamente a través de una red completa. Sin

embargo, el concepto estaba limitado a LANs estáticas y no incluía ninguna noción de

inteligencia a nivel de aplicación. La autonomía de un mensajero estaba limitada a resolver

problemas del sistema y no requerimientos del usuario.



2.5.4 Procesos móviles

Otro predecesor de los agentes móviles fueron los procesos móviles, de los cuales los

agentes heredan la habilidad para capturar su estado de ejecución actual. La idea fue

desarrollada en el área de los sistemas operativos distribuidos hacia fines de la década del 80

y consistía en que un proceso que estaba ejecutándose sobre un sistema de computadora podía

moverse a otro sistema para balancear la carga del sistema distribuido completo. Un ejemplo

de sistema operativo con migración de procesos fue Sprite.

La diferencia entre este concepto y el de agentes móviles es que, en estos últimos, el

motivo de la migración no es únicamente balancear la carga o satisfacer otros objetivos

técnicos de bajo nivel, sino facilitar el uso de los servicios disponibles sobre la capa de

aplicación de la red a través del agente.

2.5.5 Agentes móviles

En 1994, James E. White, asociado con la empresa General Magic, publicó un trabajo

que puede considerarse como el inicio de las investigaciones sobre lo que actualmente se

llama agentes móviles (Braun y Rossak, 2005: 20). En dicho trabajo, White introdujo la

tecnología Telescript, que comprendía un ambiente de ejecución y un lenguaje de

programación dedicado para agentes móviles, los cuales ya presentaban la mayoría de las

características que ofrecen las plataformas actuales. Sin embargo, el desarrollo de Telescript

fue dejado atrás cuando quedó claro que esta tecnología no iba a ser capaz de competir con el

lenguaje de programación Java como la base de la mayoría de las plataformas de agentes.

El próximo avance en la investigación sobre agentes móviles fue un trabajo presentado

por Chess en 1997, el cual describía un framework de agentes itinerantes como una extensión

del modelo cliente-servidor (Braun y Rossak, 2005: 20). Los agentes itinerantes eran

despachados desde una computadora origen y recorrían la red de servidores hasta que

completaban su tarea. En el mismo año, Chess presentó otra publicación en la cual discutía las

ventajas de los agentes móviles comparadas con las técnicas basadas en el modelo cliente-

servidor.

Desde el proyecto inicial de General Magic, la comunidad de investigadores

interesados en los agentes móviles ha estado en continuo crecimiento.



2.6 Características de los agentes móviles

Recordando la definición de agentes móviles y considerándolos como un nuevo

paradigma de diseño de sistemas distribuidos, se pueden identificar cuatro características

distintivas de los mismos:

1. Los agentes móviles son usados típicamente en áreas amplias y redes heterogéneas en las

cuales no se pueden hacer suposiciones sobre la confiabilidad de las computadoras

conectadas o la seguridad de las conexiones de red.

2. La migración de un agente móvil es iniciada por el mismo agente, al contrario de los

sistemas de objetos móviles, en los cuales la migración es iniciada por el sistema

operativo subyacente o middleware. La autonomía de un agente para decidir cuándo

migrar depende de su arquitectura interna; las decisiones pueden estar basadas en reglas

de inferencia lógica, algoritmos de planificación o respuesta a estímulos1.

3. Los agentes móviles migran para acceder a recursos que sólo están disponibles en otros

servidores de la red y no simplemente para balancear la carga.

4. Los agentes móviles son capaces de migrar más de una vez, esta característica se

denomina habilidad multi-hop. Un agente, después de visitar un sitio, puede migrar a

otros para continuar su tarea. En los paradigmas de evaluación remota y código por

demanda el código móvil es transferido solamente una vez.

2.7 Ventajas de la utilización de agentes móviles

A continuación se mencionan algunas ventajas técnicas que proveen los agentes

móviles y que convierten a esta tecnología en una herramienta nueva e interesante para

construir sistemas distribuidos:

1. Permitir el cómputo asíncrono y autónomo: debido a que los agentes móviles tienen su

propio hilo de ejecución, pueden trabajar de manera asíncrona respecto de otros procesos

que se ejecutan en el mismo nodo, y aún en distintos nodos, ya que tienen la capacidad de

trabajar sin conexión a la red. El hecho de poder decidir qué hacer ante los cambios en su

ambiente, así como saber hacia dónde, cuándo y cómo migrar, son muestras del grado de

autonomía de estos procesos. 1 Los distintos tipos de arquitecturas se detallan en el capítulo 3.



2. Ser naturalmente heterogéneos: los agentes móviles son generalmente independientes

del tipo de transporte y cómputo, únicamente dependen de su ambiente de ejecución.

Proveen condiciones óptimas para la integración de sistemas distribuidos.

3. Proporcionar ambientes robustos y a prueba de fallas: la habilidad que poseen los

agentes para reaccionar dinámicamente ante las situaciones desfavorables de su ambiente

hace más fácil el desarrollo de sistemas distribuidos robustos y tolerantes a fallas. El

hecho de que los agentes móviles no requieran de conexiones permanentes y de que sus

estados estén centralizados en sí mismos, también favorece a que las fallas que se

presenten puedan solucionarse de manera más sencilla que con otros paradigmas, como

por ejemplo, cliente-servidor.

4. Reducir el tráfico de red: los agentes móviles permiten empaquetar un mensaje y

enviarlo a un nodo destino, donde los procesos se realizan localmente. En el mensaje se

envían los datos y procedimientos para la ejecución del proceso; el control del mismo

puede llevarse a cabo por medio de supervisiones locales reduciendo así el tráfico de la

red, el cual es crucial si se considera que existen usuarios que se conectan con un ancho de

banda muy bajo. Este aspecto es opuesto al paradigma de Llamada a Procedimientos

Remotos (RPC), en el cual se establecen dos enlaces de comunicación, uno para enviar al

servidor la solicitud y los argumentos necesarios y otro para recibir los resultados.

5. Favorecer el procesamiento en paralelo: un trabajo que requiere alto poder de cómputo

podría descomponerse en sub-trabajos que se asignarían a distintos agentes. Éstos

ejecutarían dichas unidades de trabajo de forma distribuida, es decir, viajarían a otras

máquinas en una red y ejecutarían la tarea en otros nodos; al finalizar los resultados serían

presentados al agente encargado de administrar el proceso en paralelo.

6. Mantener comunicación punto a punto: una característica del paradigma cliente-

servidor es que los servidores habitualmente no se comunican entre sí. Los agentes

móviles se consideran como entidades punto y, como tales, pueden adoptar la postura que

más les convenga de acuerdo con sus necesidades. Por ejemplo, cuando un agente solicita

un recurso toma el papel de cliente; sin embargo, cuando otro agente le hace una consulta,

se comporta como servidor. Esta característica resulta ventajosa en el contexto de

ambientes distribuidos.



2.8 Posibles dominios de aplicación

Hay varios dominios de aplicación donde los agentes móviles ya han sido probados y

en los cuales han resultado muy valiosos, por ejemplo:

Recolección de información: una de sus principales aplicaciones está en la recuperación

de información en forma distribuida. Los agentes se mueven hacia donde está la

información y la obtienen localmente eliminado las transferencias de resultados

intermedios a través de la red, de esta forma se logra reducir la latencia entre nodos.

Búsqueda y filtrado de datos: debido a la gran cantidad de información que hay en la

red, el filtrado de datos insume mucho tiempo. Los agentes móviles pueden viajar a través

de la red en busca de la información requerida y retornar al usuario con el reporte de lo

encontrado.

Monitoreo: ya que la información de monitoreo se debe obtener de hosts remotos, es útil

poder visitar cada host para acceder a su estado directamente en forma local y luego

acumular la información del estado general.

Diseminación de información: los agentes móviles pueden entregar actualizaciones a los

hosts de una red.

Negociación: pueden interactuar con otros agentes e intercambiar información, por

ejemplo, para organizar reuniones entre personas.

Trueque: el comercio electrónico es una buena aplicación de los agentes, por ejemplo,

éstos se pueden encargar de hacer reservas, comprar, realizar intercambios, etc.

Procesamiento paralelo: dado que los agentes se pueden dividir en subagentes, éstos

pueden realizar tareas en paralelo en distintos hosts de una red, haciendo mucho más

rápido el cómputo y transparente la comunicación.

Entretenimiento: los agentes, por su autonomía, pueden representar jugadores

inteligentes.


Capítulo 3 Modelos y Arquitecturas

La arquitectura de un agente determina los mecanismos que utiliza el agente para

reaccionar a los estímulos, actuar, comunicarse, etc. y establece cómo se descompone el

agente en un conjunto de módulos que interactúan entre sí para lograr la funcionalidad

requerida.

Existe una amplia variedad de propuestas, y además cada implementación particular

de una arquitectura posee características propias que dependen del tipo de problema sobre el

cual se aplica.

En este capítulo se presentan algunas arquitecturas abstractas para el modelado de

agentes y, posteriormente, una clasificación de los tipos de arquitecturas que se utilizan en la

actualidad para construir agentes. Dicha clasificación está basada en los diferentes modelos de

representación del conocimiento y de razonamiento utilizados por los agentes para actuar con

el fin de satisfacer sus objetivos.

Dado que los agentes móviles son un caso particular de los agentes de software, en

este capítulo se abordarán características relacionadas con la arquitectura de los agentes en

general. Los aspectos inherentes a la movilidad se tratarán en el próximo capítulo.

3.1 Arquitecturas abstractas para agentes inteligentes

El modelo básico de interacción de un agente con su entorno es el siguiente: el

entorno parte de un estado inicial y el agente comienza eligiendo una acción a ejecutar sobre

ese estado; como resultado de esta acción el entorno responde con uno de un número de

estados posibles y, sobre la base de este segundo estado, el agente elige nuevamente una

acción a ejecutar; y así sucesivamente.

Una ejecución de un agente en un entorno es una secuencia de estados del entorno y

acciones intercalados. Esta secuencia puede finalizar con un estado del entorno o con una



acción. Este último caso ocurre cuando no hay un estado sucesor posible, por lo cual el

sistema termina su ejecución.

El efecto que tienen las acciones de un agente sobre un entorno se representa

mediante una función de transformación de estado, la cual asocia una ejecución del agente

finalizada con una acción, con un conjunto de posibles estados del entorno que pueden

resultar de la realización de la acción:

estadon = τ(estado0, acción0, estado1, acción1, … , estadon-1, acciónn-1)

En este modelo el entorno es dependiente de la historia, ya que el siguiente estado no

está determinado sólo por la acción llevada a cabo por el agente y por el estado actual, sino

que también influyen las acciones realizadas previamente por el agente. Además, el entorno es

no determinista, por lo que hay incertidumbre sobre el resultado de ejecutar una acción en

algún estado.

Los agentes se modelan como funciones que asocian ejecuciones, finalizadas con un

estado del entorno, con acciones:

acciónn = f(estado0, acción0, estado1,acción1, … , estadon)

3.1.1 Agentes puramente reactivos

Ciertos tipos de agentes, llamados puramente reactivos, deciden qué acción realizar

basándose únicamente en el estado actual del entorno, sin ninguna referencia a su historia.

Estos agentes se pueden representar mediante una función de mapeo entre estados y

acciones:

acción = f (estado)

3.1.2 Subsistemas de Percepción y Acción

Como se dijo al principio del capítulo, una arquitectura de agente especifica cómo se

descomponen los agentes en subsistemas para llevar a cabo las tareas requeridas. El modelo

abstracto de agentes presentado anteriormente se puede refinar separando la función de

decisión de un agente en dos subsistemas: percepción y acción, como se muestra en la figura

3.1.



Figura 3.1: Subsistemas de percepción y acción

El subsistema percepción representa la capacidad del agente para observar su

entorno, es decir, sus sensores, y el subsistema acción representa el proceso de toma de

decisión del agente.

Ahora un agente se puede modelar como una función de mapeo entre estados del

entorno y percepciones y otra función que mapea secuencias de percepciones a acciones:

percepción = g (estado)

acción = f (percepción*)

3.1.3 Agentes con estado

En los modelos anteriores, la función de decisión de un agente mapea secuencias de

estados del entorno o secuencias de percepciones a acciones, lo que permite modelar agentes

cuya toma de decisión está influenciada por la historia. Una forma equivalente de representar

agentes de este tipo consiste en modelar agentes que mantienen estado, como se muestra en la

figura 3.2. Estos agentes almacenan información histórica sobre el estado del entorno en

estructuras de datos internas y se basan en esta información para tomar decisiones.

La función percepción se define igual que en el modelo anterior, la función acción

se define como un mapeo de los posibles estados internos de un agente a acciones, y se agrega

una nueva función próximo que mapea un estado interno y una percepción a un estado

interno:

percepción = g (estado)

Percepción

AGENTE

Acción

AMBIENTE



acción = f (estado_interno)

próximo = h (estado_interno, percepción)

El comportamiento de los agentes con estado es el siguiente: el agente comienza con

un estado interno inicial, luego observa el estado de su entorno y genera una percepción con la

cual actualiza su estado interno mediante la función próximo, finalmente ejecuta la acción

asociada al nuevo estado interno para luego entrar en otro ciclo.

Figura 3.2: Agente con estado

3.2 Tipos de Arquitecturas

3.2.1 Agentes de razonamiento deductivo

La aproximación tradicional consiste en generar el comportamiento inteligente de un

agente dotándolo de una representación simbólica de su entorno y del comportamiento

deseado y manipulando sintácticamente dicha representación. Para la construcción de este

tipo de sistemas, llamados agentes de razonamiento deductivo o agentes basados en la lógica,

se utilizan fórmulas lógicas como representación simbólica, y la manipulación sintáctica

corresponde a deducción lógica o demostración de teoremas.

AGENTE

Percepción Acción

AMBIENTE

Próximo Estado interno



Demostración de teoremas

Los agentes de razonamiento deductivo se representan de manera similar al modelo

de agentes con estado detallado anteriormente. En este caso, el estado interno del agente

consiste en una base de datos de fórmulas de lógica de predicados de primer orden, las cuales

representan las propiedades de su entorno.

El proceso de toma de decisión de un agente se modela mediante un conjunto de

reglas de deducción (reglas de inferencia lógica). El programador del agente debe diseñar una

fórmula codificando las reglas de deducción y la base de datos mencionada de tal forma que

la mejor acción a ejecutar sea aquella para la cual se pueda derivar la fórmula a partir de la

base de datos usando las reglas de deducción. Así, el proceso de selección de una acción

consiste en intentar probar la fórmula diseñada para cada acción disponible. Si el agente no

logra probar la fórmula para ninguna acción, entonces intenta encontrar una acción que al

menos sea consistente con las reglas y la base de datos, es decir una para la cual no se pueda

derivar la negación de la fórmula.

Programación orientada a agentes

Yoav Shoham propuso un nuevo paradigma de programación, al que llamó

programación orientada a agentes, el cual se basa en el uso de un mecanismo de abstracción

que consiste en atribuir a los agentes nociones mentales tales como creencias, deseos e

intenciones (Wooldridge, 2005: 54). Este mecanismo fue desarrollado por los teóricos

dedicados al estudio de sistemas de agentes, quienes sostienen que definir un sistema

complejo mediante actitudes mentales similares a las del ser humano facilita la tarea de

describir, explicar y predecir su comportamiento.

La primera implementación de este paradigma fue el lenguaje de programación

Agent0. En este lenguaje un agente se especifica mediante un conjunto de capacidades (que

representan las cosas que el agente puede hacer), un conjunto de creencias iniciales (que

representan la información que el agente tiene acerca de su entorno), un conjunto de

compromisos iniciales (acciones a ejecutar) y un conjunto de reglas de compromiso. Cada

regla de compromiso contiene una condición de mensaje, una condición mental y una acción.

La condición de mensaje se compara con los mensajes que el agente recibe, la condición

mental se compara con las creencias del agente, si ambas condiciones se verifican el agente se

compromete a realizar la acción. La operación de un agente consiste en el siguiente ciclo:



1. Leer los mensajes recibidos, que pueden ser informativos o solicitudes para que el agente

ejecute o se abstenga de ejecutar una acción.

2. Actualizar sus creencias y compromisos, de ser necesario.

3. Ejecutar todos los compromisos para el ciclo actual donde se satisfacen las condiciones de

la acción asociada.

Lenguaje MetateM Concurrente

Este lenguaje, desarrollado por Michael Fisher, se basa en la ejecución directa de

fórmulas lógicas (Wooldridge, 2005: 56). Un sistema MetateM Concurrente contiene un

número de agentes ejecutándose concurrentemente, cada uno de los cuales es capaz de

comunicarse con sus pares mediante pasaje asíncrono de mensajes broadcast. Cada agente es

programado mediante una especificación de lógica temporal que se ejecuta directamente para

generar su comportamiento. Dicha especificación consiste en un conjunto de fórmulas lógicas

compuestas por un antecedente referente al pasado y un consecuente referente al presente o

futuro. Básicamente, el ciclo de operación de un agente es el siguiente: actualizar su historia

con los mensajes recibidos de otros agentes, comparar los antecedentes de sus reglas con la

historia actual para ver cuáles se satisfacen y finalmente ejecutar en forma conjunta los

consecuentes de aquellas reglas que se verificaron.

Ventajas y limitaciones de los agentes de razonamiento deductivo

Las aproximaciones basadas en la lógica son elegantes y tienen una semántica clara,

ya que los agentes son programados mediante la codificación de fórmulas lógicas.

Sin embargo, estas aproximaciones tienen muchas desventajas. En primer lugar, la

complejidad computacional inherente del proceso de demostración de teoremas hace que los

agentes construidos con este tipo de arquitectura no puedan operar de manera efectiva en

entornos con restricciones de tiempo, ya que, si el entorno cambia durante el proceso de toma

de decisión, las acciones tomadas podrían no ser óptimas. Otro problema radica en la

dificultad de representar las características del entorno mediante fórmulas lógicas, en especial

cuando se trata de entornos complejos y dinámicos.



3.2.2 Agentes de razonamiento práctico

Otra propuesta para la construcción de agentes está inspirada en la forma en que

razonan las personas cuando deben tomar una decisión. Este modelo de toma de decisión se

conoce como razonamiento práctico, que es razonamiento dirigido a acciones.

El razonamiento práctico en los humanos consiste en al menos dos actividades: la

primera es decidir qué circunstancias se quieren lograr, a este proceso se lo llama

deliberación, por eso a este tipo de agentes también se los conoce como agentes deliberativos;

la segunda consiste en decidir cómo se quiere llegar a esas circunstancias, a este proceso se lo

llama planificación. A las circunstancias que un agente ha elegido y con las cuales se ha

comprometido se las llama intenciones.

En el razonamiento práctico, las intenciones dirigen la planificación, ya que para

llevarlas a cabo es necesario decidir cómo hacerlo, y buscar otros cursos de acción en caso de

fallas. Las intenciones persisten hasta que son realizadas con éxito o bien hasta que se cree

que no será posible realizarlas o que la razón por la que se originaron ya no está presente. Las

intenciones restringen la deliberación futura, ya que no se deberían considerar opciones que

son inconsistentes con las intenciones actuales. Por último, las intenciones influyen en las

creencias sobre las cuales se basa el razonamiento futuro, ya que al adoptar una intención se

puede planear el futuro asumiendo que la misma se realizará.

El proceso de toma de decisión de un agente de razonamiento práctico consiste en un

ciclo compuesto de los siguientes pasos:

1. Observar el entorno y actualizar sus creencias, que representan el estado actual del

entorno.

2. Deliberar para decidir qué intenciones cumplir.

3. Planificar para cumplir sus intenciones.

4. Ejecutar el plan.

El proceso de deliberación se lleva a cabo en dos pasos: determinar el conjunto de

opciones disponibles a partir de las creencias e intenciones actuales del agente y luego filtrar

para seleccionar la mejor opción para que el agente se comprometa.

El proceso de planificación consiste en decidir cómo lograr un fin (es decir, una

intención) usando los medios disponibles (es decir, las acciones que se pueden realizar). Un

planificador es un sistema que toma como entrada representaciones de: un objetivo o



intención, el estado actual del entorno o creencias y las acciones disponibles para el agente.

Como salida, el algoritmo de planificación genera un plan, que es el curso de acción que el

agente debe ejecutar para alcanzar el objetivo.

Un punto a destacar es que este tipo de arquitectura también requiere, como el

anterior, alguna representación explícita del conocimiento, es decir, de las creencias, opciones

e intenciones del agente; sin embargo no se requiere que dicha representación sea mediante

fórmulas lógicas.

Un aspecto crítico en este tipo de arquitecturas es que, en entornos dinámicos que

cambian con mucha frecuencia, el agente debería reconsiderar sus intenciones para reaccionar

a los cambios, ya que las mismas podrían dejar de ser válidas o posibles de lograr. Por otra

parte, dado que el proceso de deliberación puede requerir una gran cantidad de tiempo, no

sería efectivo que el agente reconsidere sus intenciones constantemente. El mecanismo que

utiliza un agente para determinar cuándo modificar sus intenciones se conoce como estrategia

de compromiso. Las estrategias de compromiso más comunes son:

Compromiso ciego: el agente mantiene sus intenciones hasta que cree que se han logrado.

Compromiso firme: el agente mantiene sus intenciones hasta que cree que se han logrado

o bien hasta que considera que ya no será posible lograrlas.

Compromiso de mente abierta: el agente mantiene sus intenciones mientras cree que

todavía se pueden lograr.

Arquitectura BDI

La arquitectura deliberativa más citada en la bibliografía es la arquitectura BDI

(Belief, Desire, Intention), la cual hace uso del mecanismo de abstracción mencionado

anteriormente en este capítulo que consiste en atribuir a los agentes nociones mentales

similares a las del ser humano. Esta arquitectura se caracteriza por el hecho de que los agentes

que la implementan están dotados de los estados mentales de creencias, deseos e intenciones.

Las creencias representan el estado del entorno, por ejemplo el valor de una variable, los

valores de una base de datos relacional o expresiones simbólicas del cálculo de predicados.

Los deseos representan los objetivos del agente, es decir, el estado final deseado, que puede

simplemente ser el valor de una variable, un registro, o una expresión lógica. Para alcanzar los

objetivos propuestos a partir de las creencias existentes es necesario definir un mecanismo de



planificación que permita identificar los caminos a seguir, estos planes vinculados a la

consecución de un objetivo constituyen las intenciones del agente.

La arquitectura se basa en la construcción de sistemas de agentes que poseen

estructuras de datos para almacenar las creencias, los deseos y las intenciones

respectivamente. La secuencia de eventos ocurridos en el entorno se implementa como una

cola, es decir, mediante una estructura de datos lineal con comportamiento FIFO (primero en

entrar primero en salir). El ciclo de operación de un agente consiste en:

1. Leer la cola de eventos y devolver una lista de opciones.

2. Seleccionar las opciones que se deben adoptar y añadirlas a una cola de intenciones.

3. Ejecutar todas las intenciones que impliquen la realización de una acción simple.

4. Comprobar si existen nuevos eventos en el entorno e incorporarlos a la cola de eventos.

5. Modificar las estructuras de deseo e intención eliminando los ya satisfechos y los que son

imposibles de alcanzar.

Este modelo teórico no indica cómo desarrollar los procesos de generación o de

selección de opciones de forma suficientemente eficiente como para lograr las respuestas en

un lapso de tiempo adecuado. Por este motivo, las implementaciones de esta arquitectura han

establecido limitaciones para mejorar el rendimiento a niveles prácticos; como por ejemplo,

evitar el uso de disyunciones o implicaciones al definir las creencias e incorporar en los

agentes una librería de planes ya definidos.

Ventajas y limitaciones de los agentes de razonamiento práctico

La principal ventaja de los agentes deliberativos o de razonamiento práctico es que

su modelo de toma de decisiones resulta más natural que el de los agentes de razonamiento

deductivo, por estar basado en el proceso de razonamiento utilizado por los seres humanos.

Por otra parte, los procesos de deliberación y planificación son procesos

computacionales que pueden insumir gran cantidad de tiempo y recursos, por lo cual muchos

investigadores sostienen que los agentes de este tipo no son efectivos para operar en entornos

con restricciones de tiempo.

3.2.3 Agentes reactivos

Las propuestas descriptas anteriormente se caracterizan por utilizar una

representación simbólica del conocimiento, con los inconvenientes que esto tiene asociado,



entre los que se destacan la complejidad de implementar dicha representación y el tiempo de

procesamiento requerido para manipularla. Como alternativa surgieron arquitecturas que se

caracterizan por no estar centradas en un modelo simbólico y por no utilizar razonamiento

simbólico complejo. Dichas arquitecturas son conocidas como arquitecturas reactivas, dado

que tales sistemas simplemente reaccionan al entorno, sin razonar sobre él.

Arquitectura de Subsunción

Un ejemplo típico de arquitectura reactiva es la desarrollada por Roodney Brooks,

conocida como arquitectura de subsunción (Wooldridge, 2005: 90). Esta arquitectura se basa

en la hipótesis de que no es necesario construir un modelo simbólico para obtener un

comportamiento inteligente.

Estas arquitecturas están definidas por dos características. La primera es que la toma

de decisión de un agente se realiza a través de un conjunto de comportamientos, cada uno de

los cuales intenta cumplir una tarea particular. En la implementación de Brooks los módulos

de comportamiento son máquinas de estado finito. Estos módulos no incluyen representación

ni razonamiento de tipo simbólico; sino que generalmente se implementan mediante un

modelo estímulo-respuesta, en el cual se mapea la percepción del estado del entorno

directamente a acciones, tal como se definió en la sección 3.1.1. La segunda característica es

que muchos comportamientos pueden dispararse simultáneamente. Para determinar qué

acción seleccionar en esta situación, los módulos de comportamiento están organizados en

una jerarquía de capas, en la cual las capas superiores representan comportamientos de mayor

nivel de abstracción mientras que las capas inferiores son las que tienen mayor prioridad y

pueden inhibir a las superiores (ver figura 3.3).

Ventajas y limitaciones de los agentes reactivos

Las ventajas de las arquitecturas reactivas son su simplicidad, economía, manejo

computacional y robustez ante fallas.

Sin embargo, este tipo de arquitectura presenta varios problemas aún no resueltos: al

no utilizar modelos del entorno, los agentes deben contar con suficiente información

disponible en su entorno local para poder tomar una acción aceptable; las decisiones, por estar

tomadas en base al estado actual del entorno, son a corto término; los agentes puramente

reactivos no pueden ser diseñados para que aprendan de su experiencia a fin de mejorar su

rendimiento con el tiempo; dado que estos sistemas actúan en respuesta a estímulos del



entorno, es difícil diseñar agentes que cumplan tareas específicas; resulta difícil construir

agentes que contienen muchas capas, debido a la complejidad de la dinámica de las

interacciones entre los distintos módulos de comportamientos.

Figura 3.3: Arquitectura de Subsunción

3.2.4 Agentes híbridos

Las arquitecturas híbridas surgieron ante la necesidad de que un agente tenga

comportamiento reactivo y proactivo. Una alternativa es que el agente esté compuesto de

subsistemas separados que implementen estos tipos de comportamientos diferentes.

Normalmente, en este tipo de arquitectura, los distintos subsistemas están organizados en una

jerarquía de capas que interactúan.

Las arquitecturas en capas se pueden caracterizar en términos de los flujos de

información y de control entre las capas:

Horizontal: cada capa está directamente conectada a la entrada del sensor y a la salida de

acciones, actuando cada capa como un agente que participa en la selección de la acción a

ejecutar (ver figura 3.4).

Vertical: la entrada del sensor y la salida de acciones están conectadas cada una a una

sola capa (puede ser la misma o no). En las arquitecturas verticales de una pasada, una

capa está conectada a la entrada y el control fluye secuencialmente a través de cada capa

hasta la capa final que genera la salida (ver figura 3.5). En las arquitecturas de dos

Capa 3

Capa 2

Capa 0

Capa 1

Sensores Actuadores

Las entradas a los módulos de comportamiento se pueden suprimir

Las salidas de lo módulos de comportamiento se pueden inhibir



pasadas, la información fluye hacia las capas superiores y el control vuelve hacia abajo,

estando la entrada y la salida conectadas a la misma capa (ver figura 3.6).

Figura 3.4: Arquitectura horizontal en capas

Figura 3.5: Arquitectura vertical en capas de

una pasada Figura 3.6: Arquitectura vertical en capas de

dos pasadas

Las arquitecturas horizontales son conceptualmente más simples, se puede

implementar una capa para cada comportamiento distinto y se debe incluir una función

mediadora que determine qué capa tiene el control del agente en cada momento. La

desventaja es que este sistema de control central debe considerar todas las interacciones

posibles entre capas. En las arquitecturas verticales, sean de una o dos pasadas, la complejidad

de las interacciones entre capas es más reducida, pero son menos flexibles y menos tolerantes

a fallas dado que el control debe pasar por todas las capas.

…

Capa 2

Capa 1

Capa n

Entrada de percepciones

Salida de acciones

…

Capa 2

Capa 1

Capa n

Entrada de percepciones

Salida de acciones

…

Capa 2

Capa 1

Capa n

Entrada de

percepciones

Salida de

acciones



TouringMachines

La arquitectura TouringMachines consiste de tres capas horizontales, las cuales

están continuamente sugiriendo qué acción realizar, y existe un sistema de control para

garantizar el correcto funcionamiento del agente.

Las capas que la componen son las siguientes:

Reactiva: respuesta inmediata a cambios del entorno, mediante reglas estímulo-respuesta.

Planificadora: comportamiento proactivo basado en esquemas de planes.

Modeladora: modelo del mundo para anticipar conflictos y generar nuevos objetivos para

la capa planificadora.

Las capas están embebidas en un subsistema de control basado en reglas que pueden

inhibir entradas y salidas, determinando qué capa tiene control sobre el agente.

Figura 3.7: TouringMachines – Arquitectura horizontal en capas

InteRRaP

InteRRaP es una arquitectura vertical de dos pasadas compuesta de tres capas, cada

una de las cuales tiene asociada una base de conocimiento. El propósito de cada capa es

similar al de la capa correspondiente en la arquitectura anterior.

Las capas que la componen son las siguientes:

Comportamiento (reactiva): información del entorno.

Capa Modeladora

Capa Planificadora

Capa Reactiva

Subsistema de percepción

Subsistema de acción

Subsistema De

Control

Entrada de sensor

Salida de acción



Planificación (proactiva): planes y acciones del agente.

Cooperación (interacción social): planes y acciones de otros agentes del entorno.

Este tipo de arquitectura se utiliza mucho en problemas que requieren integrar un

razonamiento deliberativo para la negociación, pero donde la ejecución es independiente del

razonamiento. Por ejemplo: sistemas de robótica, en los cuales los robots ejecutan acciones

continuamente, por lo que el nivel más bajo es reactivo, y al mismo tiempo están integrados

en un sistema multiagente para la consecución de un objetivo conjunto.

Figura 3.8: InteRRaP - Arquitectura vertical de dos pasadas

3.3 Arquitecturas Multiagentes

Los sistemas multiagentes permiten el desarrollo de aplicaciones complejas, en las

que se requiere que varios subsistemas interactúen en forma coordinada integrando sus

objetivos particulares en un objetivo común. Este tipo de sistema se emplea en muchos casos,

como por ejemplo: cuando el problema a resolver está físicamente distribuido, cuando está

definido sobre una red de computadoras o cuando, debido a su complejidad, requiere una

solución distribuida y adaptable ante cambios en la estructura y en el entorno, así como una

Capa de cooperación

Capa de planificación

Capa de comportamiento

Conocimiento social

Conocimiento de planificación

Modelo del entorno

Interface

Entrada de percepciones Salida de acciones



metodología de desarrollo que permita la construcción de un sistema a partir de distintas

unidades autónomas.

En este tipo de arquitecturas, la colaboración entre los componentes del sistema es

fundamental para la resolución del problema y el logro de los objetivos predefinidos. En

general, un sistema multiagente cooperante presenta las siguientes características:

1. Está formado por un conjunto de agentes, cada uno con capacidades propias de

adquisición de datos, comunicación, planificación y actuación.

2. Tiene una tarea común, la cual se puede descomponer en diferentes tareas independientes

para ser ejecutadas en paralelo; el sistema debe ser capaz de asignar a cada uno de sus

componentes una o varias tareas concretas teniendo en cuenta cuál es el objetivo común.

3. Cada agente del sistema tiene un conocimiento limitado acerca del entorno, de la misión

del grupo y de las intenciones de los demás agentes.

4. Cada agente del sistema tiene cierta especialización para realizar determinadas tareas, en

función de lo que conoce, de su capacidad de proceso y de la habilidad requerida.

La distribución de las decisiones entre los distintos componentes del sistema

permite:

1. Mantener la autonomía de cada agente, ya que cada uno decide en función de su propio

entorno las tareas a llevar a cabo.

2. Eliminar la necesidad de que toda la información del sistema se encuentre en un único

agente.

3. Descentralizar la toma de decisiones, obteniendo así mayor robustez ante posibles fallas.

La mayoría de las decisiones deben ser consensuadas entre los agentes, si bien

determinados agentes pueden tomar decisiones que involucran a todos y planificar de

manera coordinada un conjunto de tareas.

4. Llevar a cabo acciones coordinadas, mediante un mecanismo de comunicación entre los

agentes.

5. Organizar dinámicamente la arquitectura de agentes, permitiendo la adaptación de la

arquitectura a los cambios que se produzcan en el entorno en tiempo real.

En un sistema multiagente las formas de interacción entre las distintas clases de

agentes, es decir entre roles, están definidas por las siguientes relaciones:



Relación de conocidos: indica que un agente tiene una representación de otro agente y

conoce su dirección, es la relación mínima entre dos agentes y es el soporte de otras

relaciones.

Relación de comunicación: indica que un agente puede mandar mensajes a otro. La

relación de conocidos es el soporte para el canal de comunicación.

Relación de subordinación: describe la transferencia de una ejecución (tarea) entre dos

agentes. Esta relación puede ser jerárquica o igualitaria. En la primera, algunos agentes

dan órdenes a los demás, controlando y coordinando todas las actividades; en la segunda,

todos los agentes participan de la misma manera en la toma de decisión final.

Relación operativa: representa las dependencias entre tareas relacionadas.

Relación de información: ocurre cuando el conocimiento de un agente depende de otro

agente, por lo que está fundamentado en la confianza que deposita en el otro agente.

Relación de conflicto: indica que los agentes tienen un conflicto por el acceso a los

recursos y que será necesario coordinar las tareas mediante una negociación.

Relación competitiva: se corresponde con una competición entre los agentes y es una

señal de que sus objetivos son incompatibles.

Estas relaciones además pueden ser estáticas o dinámicas; las primeras se

determinan al definir la organización y no cambian con la ejecución, mientras que las

segundas cambian en función de la ejecución. Se pueden dar tres casos:

Relación de subordinación estática o dinámica: en la primera se define qué agente está

subordinado a otro (relación maestro-esclavo); la segunda está basada en una petición de

servicios por parte de un agente, que puede ser aceptada o no por otro agente, lo que

implica que la relación depende de la situación del sistema en cada momento.

Relación operativa estática o dinámica: la relación estática define las dependencias de

las tareas desde un principio; la dinámica distribuye las tareas entre los agentes en función

de su disponibilidad.

Relación de información estática o dinámica: en el primer caso existe una relación de

confianza mutua entre agentes definida estructuralmente; en la relación dinámica un

agente debe demostrar la validez de la información para obtener la confianza de otro

agente.



Los modos de enlace definen cómo están unidos los agentes entre sí y la capacidad

del agente para modificar sus propios roles. Estos enlaces pueden ser fijos, variables o

evolutivos. Los enlaces fijos impiden la reorganización y la adaptación de la organización y

del agente al entorno, por lo que no son útiles para un sistema multiagente; los enlaces

variables permiten una adaptación controlada de los agentes en alguno de sus parámetros,

siendo los más utilizados en sistemas multiagentes; los evolutivos permiten que las relaciones

y los agentes evolucionen sin definir límites.

La distribución de habilidades entre los agentes del sistema depende

fundamentalmente del tipo de problema a resolver. Los casos extremos son: que todos los

agentes tengan todas las habilidades posibles o que cada agente tenga una única habilidad (es

decir, que sean especialistas). La distribución se puede medir utilizando dos índices: el grado

de especialización y el grado de redundancia. El primero evalúa la relación existente entre el

número de habilidades que tiene el agente para un problema dado y el número de habilidades

existentes para ese problema; el segundo evalúa la relación existente entre el número de

agentes que tienen la misma habilidad y el número total de agentes en el sistema. A partir de

estos parámetros pueden identificarse cuatro puntos extremos:

Organización no redundante e hiperespecializada: cada agente sólo tiene una habilidad

y sólo ese agente la posee. Esta organización es típica de una descomposición funcional,

donde cada función es un agente.

Organización redundante y especializada: cada agente sólo tiene una habilidad y todos

los agentes la poseen. Esta organización permite optimizar algunos problemas de

ejecución cuando se utilizan varias máquinas para resolverlos.

Organización redundante y general: cada agente tiene varias habilidades y varios

agentes las poseen. Ésta es la organización típica de los sistemas multiagentes.

Organización no redundante y general: cada agente tiene todas las habilidades y nadie

más que ese agente las posee. En este caso el sistema multiagente pasa a convertirse en un

único agente.

3.4 La arquitectura FIPA

FIPA (Foundation for Intelligent Physical Agents) es una organización cuyo objetivo

es estandarizar los modelos y tecnologías de agentes. La estandarización es necesaria para



lograr la interoperabilidad de los sistemas basados en agentes (facilidad de interconexión e

integración) y su apertura (posibilidad de extensión).

En las especificaciones de FIPA se definen las características que deben cumplir las

plataformas de gestión de sistemas multiagentes. Ejemplos de implementaciones creadas a

partir de este estándar son FIPA OS y JADE.

En relación con la plataforma de agentes, FIPA especifica el comportamiento y la

interfaz que se debe respetar con el fin de permitir la interoperabilidad entre plataformas,

quedando a cargo del desarrollador las decisiones de diseño de los componentes.

FIPA define un modelo de referencia lógico para la creación, destrucción, registro,

localización, comunicación y migración de agentes. La plataforma de agentes es el núcleo del

modelo de referencia y proporciona la infraestructura para el desarrollo y la ejecución de

agentes.

En la figura 3.9 se muestra el conjunto de componentes de una plataforma de

agentes FIPA:

Agente: representa al agente propiamente dicho y sus tareas serán definidas de acuerdo

con el objetivo de la aplicación. Se encuentra dentro de la plataforma de agentes y se

comunica con otros agentes a través de mensajes. Todo agente debe tener un Identificador

de Agente (AID), que permite identificarlo unívocamente dentro del universo de agentes.

Un agente puede estar registrado en un número de direcciones de transporte en las cuales

puede ser contactado. Además, un agente también se relaciona con aplicaciones externas y

puede acceder a componentes de software no-agente, por ejemplo, para incorporar nuevos

servicios, protocolos de comunicación o negociación, algoritmos de seguridad,

herramientas de soporte para la migración, etc. (en la figura, todo esto se representa con el

elemento Software).

Sistema de Gestión de Agentes (Agent Management System - AMS): la función de este

componente es controlar el acceso y uso de la plataforma. Se encarga de la creación y

destrucción de agentes, controla el ciclo de vida de los agentes (cada agente puede estar en

estado iniciado, activo, suspendido o esperando), supervisa los permisos para que nuevos

agentes se registren en la plataforma, controla la movilidad de los agentes y gestiona los

recursos compartidos y el canal de comunicación. Cada agente debe registrarse con el

AMS para obtener un AID válido. El AMS proporciona un servicio de nombres, conocido

como servicio de páginas blancas, el cual asocia el nombre que identifica a un agente de



la plataforma con la dirección de transporte real (número de puerto) en la que se

encuentra. El servicio de nombres es el método básico para buscar un agente dentro de la

plataforma.

Facilitador de Directorio (Directory Facilitator - DF): este componente proporciona un

servicio de páginas amarillas, que complementa al servicio de nombres permitiendo

buscar un agente por sus capacidades y no sólo por su nombre. Los agentes se registran

indicando los servicios que ofrecen. Cuando un agente requiere un servicio en particular,

busca el servicio deseado y obtiene todos los agentes registrados que ofrecen dicho

servicio.

Servicio de Transporte de Mensajes (Message Transport Service – MTS): este

servicio provee un mecanismo para la transferencia de mensajes entre agentes, los que

pueden encontrarse dentro de la misma plataforma o en distintas plataformas. Este

mecanismo consiste en rutear los mensajes ACL (Agent Communication Language)1

desde el agente origen al agente destino. El MTS es provisto a los agentes de una

plataforma dada por una entidad llamada Canal de Comunicación de Agentes (Agent

Communication Channel - ACC). El ACC puede acceder a información provista por otros

servicios de la plataforma, como el AMS y el DF, para llevar a cabo sus tareas de

transporte de mensajes. El modelo de comunicación entre agentes es asíncrono, es decir

que el sistema no se queda bloqueado ante el envío o la recepción de mensajes. Existen

colas de envío y recepción de mensajes, para las cuales deben definirse políticas de

gestión de colas de mensajes.

Plataforma de Agentes (Agent Platform - AP): provee la infraestructura física en la cual

pueden ejecutarse los agentes. Consiste en la/s máquina/s, sistema operativo, software de

soporte de agentes, componentes FIPA (DF, AMS y MTS) y agentes. El concepto de

plataforma no implica que todos los agentes residentes en una plataforma deban estar

ubicados en la misma máquina.

Los servicios del AMS y del DF son suministrados por agentes especializados.

Con respecto a la comunicación entre agentes, cabe destacar que FIPA especifica

cómo debe llevarse a cabo dicha comunicación entre agentes nativos de una plataforma y

1 Ver capítulo 5, sección 5.5.2.



agentes que están fuera de la misma. Sin embargo, los agentes son libres para intercambiar

mensajes directamente por cualquier medio que puedan soportar.

Figura 3.9: Modelo de referencia de Gestión de Agentes de FIPA

3.5 Arquitectura MASIF

MASIF (Mobile Agent System Interoperability Facilities), también conocida como

MAF (Mobile Agent Facility), es una especificación estándar proporcionada por el OMG

(Object Management Group) para sistemas de agentes móviles. El OMG es un grupo de

empresas e instituciones enfocado en la interoperabilidad, reusabilidad y portabilidad de

sistemas distribuidos de componentes de software orientado a objetos.

La especificación MASIF está basada en el estándar CORBA (Common Object

Request Broker Arquitecture). Define interfaces para la transferencia y localización de

agentes en sistemas de agentes, considerando los agentes móviles como objetos CORBA que

AP1 (Plataforma de Agentes)

SMA (Sistema de Gestión

de Agentes)

Agente DF

(Facilitador de Directorio)

MTS (Servicio de Transporte de Mensajes)

Software

AP2 (Plataforma de Agentes)

MTS (Servicio de Transporte de Mensajes)



tienen la posibilidad de ejecutarse y moverse en forma autónoma y asíncrona en sistemas de

ejecución seguros.

La especificación está compuesta de dos interfaces a nivel de sistema de agentes

(figura 3.10):

MAFAgentSystem: se encarga de la gestión de agentes (creación, terminación,

suspensión, transferencia y recepción).

MAFFinder: define operaciones para registrar y localizar agentes y sistemas de agentes.

No hay interfaz unificada para los agentes, los agentes sólo viajan a sistemas de

agentes que soporten su perfil.

Figura 3.10: Modelo Multiagente del estándar MASIF

MAFAgentSystem

Sistema de Agentes

Agentes

MAFFinder

CORBA

MASIF

Sistema de Agentes

Agentes

CORBA

Transferencia de agentes

IIOP


Capítulo 4 Migración de agentes

La principal característica de los agentes móviles, como lo indica su definición1, es

su capacidad para migrar desde un sitio a otro en redes heterogéneas o parcialmente

desconectadas. Durante ese proceso, el agente es transmitido completamente, es decir, como

un conjunto de código, datos y estado de ejecución, y es aquí donde surgen varias cuestiones

relacionadas con la migración que deben tenerse en cuenta, tanto al diseñar agentes móviles

como al elegir una plataforma para el desarrollo y la ejecución de los mismos. Estos aspectos

tienen una incidencia directa sobre el rendimiento del sistema de agentes completo.

En este capítulo se presentará la estructura de un agente móvil y se describirán los

pasos que se realizan para llevar a cabo el proceso de migración. También se abordarán los

distintos tópicos de diseño de la migración de agentes y los factores que influyen en el

rendimiento de los mismos.

4.1 Terminología básica

Los agentes móviles necesitan un ambiente donde ejecutarse. En la bibliografía se

utilizan distintos nombres para hacer referencia a este ambiente, en este trabajo se utilizarán

los términos plataforma o entorno de ejecución, indistintamente. En general, las plataformas

proveen servicios básicos para la comunicación, la gestión, la seguridad y la migración de

agentes.

Existen productos que brindan herramientas para facilitar el desarrollo de agentes,

denominados toolkits de agentes móviles. Actualmente hay varios disponibles, ya sea bajo la

forma de software libre o como productos comerciales. La mayoría de ellos incluye tanto la

plataforma como el toolkit de desarrollo. Se volverá sobre este tema en el capítulo 6, en el que

se describirán algunas de las plataformas existentes.

1 Ver capítulo 2, sección 2.2



A los efectos de la migración, una plataforma se divide lógicamente en lugares que

están ubicados en distintas máquinas, a los cuales en este trabajo se llamará agencias. Es

necesario que sobre cada host en el que se quiera ejecutar agentes móviles exista una agencia

del mismo tipo. Cada host puede albergar varias agencias en paralelo, cada una es identificada

por una URL que le sirve como nombre y es utilizada también para la migración. Se habla de

migración intra-plataforma cuando los agentes se mueven entre agencias asociadas a una

única plataforma, y de migración inter-plataforma cuando migran entre agencias

pertenecientes a distintas plataformas.

En los últimos años, algunos grupos de investigación han comenzado a desarrollar

métodos para conseguir que los agentes móviles sean interoperables, es decir, que agencias de

distinto tipo sean capaces de intercambiar agentes, pero aún no se han obtenido resultados

concretos al respecto.

Un agente tiene ciertos atributos, tales como nombre, agencia origen y propietario.

La agencia origen (llamada en inglés home) es la agencia en la cual el agente fue creado. El

nombre de un agente permite identificarlo unívocamente entre todas las agencias de la

plataforma y es definido por su propietario, que es el usuario que inicia el agente. La

información del propietario es importante para indicar a las agencias foráneas si el agente es

confiable.

La agencia que mantiene el código de un agente móvil se denomina servidor de

código. Generalmente, la agencia origen es el servidor de código, aunque esto no es siempre

es así.

Las agencias son sistemas multiagentes, ya que en una agencia se pueden ejecutar

varios agentes en paralelo. Para permitir esto, se debe contar con algún tipo de planificación.

En la mayoría de los sistemas esta planificación no está programada dentro de la plataforma,

sino que se delega al lenguaje de programación y al sistema operativo; por ejemplo, en los

lenguajes que soportan hilos, es común tener un hilo (thread) para cada agente.

4.2 Estructura de un agente móvil

Un agente móvil está constituido por tres componentes: código, datos y estado de

ejecución.



El código contiene la lógica del agente, es decir, las instrucciones que definen su

comportamiento. Se dice que dos agentes son del mismo tipo si tienen el mismo código. El

código del agente debe estar separado del código de la agencia para que el agente pueda

migrar solo hacia otra agencia. Por otra parte, la agencia en la que se está ejecutando el agente

debe poder acceder al código del mismo, ya sea en la forma de archivos desde el sistema de

archivos local o mediante un flujo de bytes recibido a través de la red.

Los datos del agente, llamados también estado del objeto, son aquellos ítems de

datos que pertenecen al agente y que son movibles, es decir, que pueden ser transferidos a

otras agencias. En los lenguajes orientados a objetos, un agente es una instancia de una clase y

los datos del agente son los valores de sus variables de instancia. Es importante destacar que

no todas las variables utilizadas por un agente forman parte de su estado del objeto, por

ejemplo, aquellas que hacen referencia a objetos que no se pueden mover a otras agencias

porque son compartidos con otros agentes o con la agencia misma (manejadores de archivos,

hilos, interfaz gráfica de usuario, etc.).

El estado de ejecución está comprendido por información que es controlada por el

procesador y por el sistema operativo, a diferencia del estado del objeto, cuyos elementos son

controlados directamente por el agente. La información que constituye el estado de ejecución

depende del toolkit de agentes móviles y del entorno de ejecución subyacente (procesador,

sistema operativo y máquina virtual). En algunos toolkits, por ejemplo, el estado de ejecución

es el contexto del proceso (estado, contador de programa, pila, etc.). En la mayoría de los

toolkits desarrollados en lenguaje Java, en cambio, el agente mismo es responsable de copiar

información acerca de su estado de ejecución actual en su estado del objeto y restaurarla luego

de la migración, debido a que este lenguaje no permite acceder al sistema operativo ni al

procesador para extraer el estado de ejecución de un hilo.

4.3 Ciclo de vida de un agente móvil

Como ya se mencionó1, el estándar FIPA define que los agentes se ejecutan sobre

una plataforma y utilizan las facilidades que esta ofrece para cumplir con su funcionalidad. En

este contexto, un agente móvil posee un ciclo de vida que es manejado por la plataforma. A

continuación se presenta el ciclo de vida de un agente móvil propuesto por FIPA (figura 4.1),




describiendo los posibles estados por los que atraviesa un agente durante su existencia y las

transiciones entre éstos.

Estados

Iniciado: el agente fue creado, pero aún no se ha registrado con el AMS, no tiene un

nombre ni una dirección ni puede comunicarse con otros agentes.

Activo: el agente ya está registrado con el AMS, posee nombre y dirección y puede

acceder a todas las funcionalidades que provee la plataforma.

Suspendido: el hilo de ejecución del agente está detenido y no se está ejecutando ninguna

tarea.

Esperando: el agente está bloqueado, esperando que algo suceda.

Migrando: el agente entra en este estado cuando migra hacia una nueva ubicación

Desconocido: el agente está definitivamente muerto. Su hilo ha terminado la ejecución y

el agente ya no se encuentra registrado en el AMS.

Transiciones

Crear: creación de un nuevo agente que lo coloca en estado iniciado.

Invocar: invocación de un nuevo agente; el agente pasa de estado iniciado a activo.

Destruir: terminación forzosa de un agente; esta transición sólo puede ser iniciada por el

AMS y no puede ser ignorada por el agente, colocándolo en estado desconocido.

Quitar: terminación no obligada del agente (éste puede ignorar la orden), coloca al agente

en estado desconocido.

Suspender: coloca al agente en estado suspendido, puede ser iniciada por un agente o por

el AMS.

Reiniciar: provoca que el agente retorne del estado suspendido, puede ser iniciada

únicamente por el AMS.

Esperar: coloca al agente en estado esperando, puede ser iniciada solamente por un

agente.

Despertar: provoca que el agente pase del estado esperando al estado activo, puede ser

iniciada únicamente por el AMS.

Mover: coloca al agente en estado migrando, puede ser iniciada solamente por un agente.



Ejecutar: provoca que el agente retorne del estado migrando y pase a estado activo,

puede ser iniciada únicamente por el AMS.

Figura 4.1: Ciclo de vida de un agente definido por FIPA

4.4 Proceso de migración de un agente

El comportamiento típico de un agente móvil consiste en migrar desde una agencia a

otra para llevar a cabo sus tareas. Durante el proceso de migración, la agencia en la que reside

el agente, o agencia emisora, y la agencia a la cual desea migrar, o agencia receptora, se

comunican a través de la red para intercambiar datos acerca del agente. Para esto requieren

algún mecanismo de comunicación, que se denomina protocolo de migración. Algunos

sistemas utilizan un simple mecanismo de comunicación asíncrona, mientras que otros

desarrollan complejos protocolos de red sobre TCP/IP.

Si bien los detalles pueden variar de una implementación a otra, Braun y Rossak

(2005: 38) resumen el proceso de migración completo en seis pasos, los cuales de ejecutan en

secuencia, excepto los pasos E3 y R1 que se ejecutan en paralelo (figura 4.2).

Suspendido

Esperando

Activo

Migrando

Iniciado

Esperar

Despertar

Mover

Ejecutar

Reiniciar

Suspender

Invocar

Destruir

Crear

Quitar

Desconocido



Figura 4.2: Proceso de migración de un agente móvil 1

Los primeros tres pasos se ejecutan en la agencia emisora:

E1: Iniciar el proceso de migración y suspender el hilo de ejecución. El proceso de

migración comienza con un comando especial, el comando de migración, mediante el cual

el agente indica su intención de migrar hacia otra agencia, cuyo nombre especifica como

parámetro del comando. La agencia en la que el agente se está ejecutando debe suspender

el hilo de ejecución del mismo y garantizar que ningún hilo hijo siga vivo, a fin de evitar

que los datos y el estado sean modificados posteriormente.

E2: Capturar los datos y el estado de ejecución del agente. El agente es serializado,

para poder ser transmitido a través de la red y reconstruido en la agencia destino. La

serialización consiste en convertir y guardar en un arreglo de bytes planos el estado actual

de todas las variables del agente (sus datos) y también información acerca de su estado de

ejecución, para que sea posible determinar el punto en el cual fue suspendido. El resultado

de este proceso es el agente serializado, que es una secuencia de bytes que representa los

datos y el estado del agente.

1 Figura adaptada de Braun y Rossak (2005: 39)

E1: Iniciar el proceso de migración

E2: Capturar datos y estado del agente

E3: Transferir el agente

R3: Iniciar la ejecución del agente

R2: Deserializar el agente

R1: Recibir el agente

Agencia Emisora Agencia Receptora

Red



E3: Transferir el agente. El agente serializado es transferido hacia la agencia receptora

usando un protocolo de migración, por ejemplo, vía sockets, RPC, Java RMI, CORBA

IIOP, etc.

Los últimos tres pasos son ejecutados en la agencia receptora:

R1: Recibir el agente. El agente serializado se recibe mediante el protocolo de migración.

La agencia receptora determina si el agente puede ser aceptado, verificando si el

propietario y la agencia emisora son conocidos y confiables.

R2: Deserializar el agente. Las variables y el estado de ejecución son restaurados desde

el agente serializado. El resultado de este paso debe ser una copia exacta del agente que

existía en la agencia emisora justo antes de alcanzar el comando de migración.

R3: Iniciar la ejecución del agente en un nuevo hilo. La agencia receptora reanuda la

ejecución del agente en nuevo hilo de control. Cuando se reanuda la ejecución del agente,

se necesita disponer de su código. Existen varias técnicas para recuperar este código, las

mismas se detallarán más adelante en este capítulo.

4.5 Tópicos de diseño de la migración de agentes

Existen varias alternativas de diseño de la migración de agentes. Cada toolkit

implementa su propia técnica de migración. El modelo de movilidad de un toolkit de agentes

móviles describe las principales características de la técnica de migración que éste utiliza.

Según Braun y Rossak (2005: 75), un modelo de movilidad define tres vistas sobre los tópicos

de migración (figura 4.3):

1. Vista del programador: se enfoca en todos aquellos aspectos de la migración que están

relacionados con el programador del agente, principalmente, cómo se inicia la migración

de un agente y cómo se reanuda su ejecución (pasos E1 y R3).

2. Vista del agente: se ocupa de la estrategia de migración, la cual describe qué piezas de

código migran hacia otra agencia y cómo se manejan los datos en cada caso (pasos E2 y

R2).

3. Vista de la red: se encarga de la técnica utilizada para transmitir el agente a través de la

red (pasos E3 y R1).



Figura 4.3: Las tres vistas de un modelo de movilidad1

4.5.1 Vista del programador

Nombrado y direccionamiento

Considera los aspectos relacionados con el nombre del agente y de la agencia, y los

tipos de direcciones que se pueden usar para la migración de agentes.

Todo agente debe tener un nombre único e inmutable que lo identifique durante todo

su tiempo de vida. Este nombre es usado por otros agentes de la agencia para comunicarse con

él y por la agencia misma para controlarlo. En algunos toolkits, el nombre también se usa para

seguir la pista del agente y para la comunicación remota entre agentes que residen en

diferentes agencias.

El nombre de un agente, generalmente, está formado por un nombre simbólico, el

nombre de la agencia origen y el nombre del host en donde reside la misma, para hacerlo

globalmente único. El nombre simbólico puede ser dado explícitamente por el propietario del

agente o implícitamente por la agencia, por ejemplo, una etiqueta acompañada de un número

aleatorio. El protocolo de migración debe incluir el nombre del agente, a fin de que, cuando


Agencia Emisora Agencia Receptora

Red

Vista del usuario

Vista del agente

Vista de la red

E1: Iniciar el proceso de migración

E2: Capturar datos y estado del agente

E3: Transferir el agente

R3: Iniciar la ejecución del agente

R2: Deserializar el agente

R1: Recibir el agente



un agente migra, la agencia receptora pueda verificar si ya tiene registrado un agente con el

mismo nombre.

También la agencia debe tener un nombre único para poder ser identificada. Si el

toolkit de agentes permite solamente una agencia por cada host, entonces se puede usar

directamente el nombre de éste como nombre de la agencia. Sin embargo, si permite tener

más de una agencia en el mismo host, se debe usar un nombre simbólico. Si se cuenta con una

técnica de resolución de nombres similar al servicio de resolución de nombres de dominios de

Internet (DNS), el nombre simbólico de la agencia es suficiente para identificarla; de lo

contrario, el nombre de la agencia debe contener el nombre simbólico y el nombre del host.

Para realizar la migración, se necesita conocer la dirección de red de la agencia.

Generalmente, una conexión de red requiere el nombre del protocolo de red y el número de

puerto hacia el cual se dirige la comunicación. Si el toolkit de agentes provee más de un

protocolo de transmisión, entonces el programador debe especificar el protocolo a utilizar o

bien el mismo toolkit puede seleccionar el más adecuado en cada caso (por ejemplo, puede

haber un protocolo para migración intra-plataforma y otro para migración inter-plataforma).

En caso de que el número de puerto también sea requerido, una opción posible es que el

toolkit utilice un número fijo y que todas las agencias usen el mismo puerto, lo cual no es

conveniente ya que puede haber otra aplicación usando ese puerto. Otra alternativa es que el

puerto sea especificado por el usuario. Por último, la solución implementada por varios

toolkits es la resolución dinámica del número de puerto de acuerdo con el protocolo requerido

y los puertos disponibles.

Creación de agentes

Normalmente, al crearse un agente, éste inicia su ejecución en la agencia actual, es

decir, aquella en la cual el propietario ejecutó el comando de creación. En este caso la agencia

actual es la agencia origen del agente. Otra posibilidad es iniciar el agente directamente en

una agencia remota; en este caso, dicha agencia debe ofrecer una interfaz de comunicación

para soportar el inicio remoto.

Código del agente

Un punto importante a decidir es el lugar desde el cual se debe cargar el código del

agente, tanto al crearse el mismo en su agencia origen como para cargar por demanda en



forma dinámica el código que no está disponible en alguna agencia remota. Tal como se

mencionó en la sección 4.1, a este lugar se lo denomina servidor de código.

En caso de utilizarse el lenguaje Java, se puede agregar en la variable de ambiente

CLASSPATH la ubicación de los archivos de clases del agente. Esto tiene la limitación de

que se deben incluir todas las clases de los agentes que podrían iniciarse en algún momento en

la agencia antes de levantar la agencia completa, ya que la máquina virtual de Java no permite

la modificación de la variable CLASSPATH en tiempo de ejecución. Una opción más flexible

es permitir que el código del agente esté almacenado en cualquier lugar del sistema de

archivos y que su ubicación sea un parámetro del comando de creación del agente, pero no es

fácil implementar esta alternativa para obtener el código en forma remota, ya que

generalmente está prohibido el acceso directo al sistema de archivos de una agencia remota.

La manera más flexible es guardar el código en algún lugar del sistema de archivos donde se

pueda obtener usando algún protocolo estándar de transmisión de red como HTTP o FTP.

Otra característica a definir es el formato con el que se almacenará el código del

agente. Por ejemplo, en el caso de Java, se puede almacenar cada archivo de clase por

separado o utilizar archivos JAR. Esto último permite guardar varios archivos de clase en un

solo archivo, el cual puede ser comprimido y firmado digitalmente.

Datos del agente

Braun y Rossak (2005: 80) distinguen cuatro tipos de datos que un agente móvil puede

utilizar, en función del comportamiento que tiene cada uno de ellos durante la migración del

agente:

Proxy: son datos no móviles que pueden ser accedidos en forma remota. Existen sólo en

la agencia origen del agente y no pueden ser movidos a otras agencias; sin embargo, los

agentes móviles pueden acceder a ellos en forma transparente desde una agencia remota.

En cada agencia hay un objeto proxy que es parte del agente serializado y que es

responsable retransmitir en forma transparente cualquier modificación sobre estos datos a

la agencia origen. Este tipo de datos es útil para el acceso a archivos o a interfaz gráfica de

usuario.

Static: son datos no móviles y que no pueden accederse remotamente. Existen solamente

en una agencia y no se toman en cuenta en el momento de la migración. En Java estos

datos pueden ser marcados como transient de forma tal que no formen parte del agente



serializado. Este tipo de datos es comúnmente usado para archivos y para interfaz gráfica

de usuario.

Moving: son datos móviles, es decir que forman parte del agente serializado, y se

eliminan de la agencia emisora luego de la migración. Este tipo de datos se usa para todas

las variables locales del agente que no son compartidas con otros agentes ni con la

agencia.

Copying: son datos móviles, pero no se eliminan de la agencia emisora luego de la

migración. Una copia de los datos forma parte del agente serializado, para que en la

agencia remota el agente tenga acceso a ellos, pero las modificaciones no se ven en los

datos originales. Este tipo de datos es usado para todas las variables para las cuales el

agente tiene una referencia y que son compartidas con otros agentes o con la agencia.

Migración

Los aspectos relacionados con la migración se pueden dividir en seis ítems:

Iniciador de la migración de un agente: la migración puede ser iniciada por el agente

mismo o por alguna otra entidad, como otro agente o la agencia. Permitir que una

instancia externa decida sobre la migración de un agente se contradice con una

característica importante de estas entidades de software, que es la autonomía1. Sin

embargo, a veces es necesario forzar a un agente a migrar a otro sistema, por ejemplo,

para balancear la carga o para evitar que el mismo sea dañado en caso de que se tenga que

bajar la agencia completa debido a un error grave.

Tipo de movilidad: los toolkits de agentes móviles se pueden distinguir por el tipo de

movilidad que ofrecen al programador. Como ya se explicó anteriormente, cuando un

agente migra suspende su ejecución y se transporta a otra agencia, reanudando la

ejecución en el punto en que se había suspendido. En este contexto, existen dos tipos de

migración, que se diferencian por el transporte de más o menos información del estado de

ejecución:

♦ Migración fuerte: además de los datos del agente, se transporta el estado de ejecución

del proceso (contador de programa, pila, valores de los registros, etc.) al momento de

ejecutarse el comando de migración. En el destino, el agente reanuda su ejecución a




partir de la siguiente instrucción. En los sistemas que soportan migración fuerte, la

migración suele ser completamente transparente para el agente.

♦ Migración débil: se transmiten sólo los datos del agente. En el destino, a diferencia

del caso anterior, el agente no reanuda su ejecución en el punto en el que se había

suspendido sino que la reinicia con los valores de sus datos al momento de ejecutarse

el comando de migración. Por lo general, el agente es inicializado y reiniciado

mediante la invocación de un método determinado, cuyo nombre puede ser fijo o

puede ser definido por el programador en el comando de migración (como parámetro o

en una variable que forme parte del agente serializado). Este tipo de migración es el

utilizado comúnmente por los toolkits de agentes implementados en Java, debido a que

este lenguaje no permite la captura del estado de ejecución de un hilo. El modelo de

seguridad de la arquitectura JVM impide que un programa acceda o manipule

directamente sus punteros, registros y pilas. Cabe mencionar que algunas plataformas

desarrolladas en Java se han ocupado de estudiar mecanismos para soportar movilidad

fuerte. Para lograr este tipo de movilidad, estas plataformas extienden la JVM

modificando su código fuente o modifican el código fuente del agente por medio de un

preprocesador que agrega instrucciones para guardar y restaurar el estado de

ejecución. El riesgo de la primera opción es que se reduce la compatibilidad con

herramientas de terceros o con otras implementaciones de la máquina virtual; el

segundo caso tiene la desventaja de aumentar el tamaño del código del agente

afectando el rendimiento del sistema.

La figura 4.4 ilustra con un sencillo ejemplo el comportamiento de un agente en ambos

tipos de migración. En el ejemplo, el método move representa el comando de migración.

En el caso de migración débil ejemplificado, el agente no reinicia su ejecución en un

método determinado sino que utiliza una variable para salvar su estado antes de migrar, a

fin de poder determinar en qué punto comenzar la ejecución en la agencia destino.



Figura 4.4: Ejecución de código de un agente según el tipo de migración

Entorno de movilidad (o escenario de migración): otro tema relacionado con la

migración es el entorno en el cual se pueden mover los agentes de una plataforma. Por

razones de compatibilidad, no siempre es posible implementar la migración según el

proceso explicado y no todos los escenarios soportan los dos tipos de migración detallados

en el punto anterior. Las posibilidades son las siguientes:

Agencia A

run(){ System.out.println("El agente está en la agencia A"); move (agenciaB); System.out.println("El agente está en la agencia B");

}

Agencia B

run(){ System.out.println("El agente está en la agencia A"); move (agenciaB); System.out.println("El agente está en la agencia B");

}

Migración fuerte

Agencia A

run(){ if (x==0) {

System.out.println("El agente está en la agencia A"); x=1; move (agenciaB);

} else {

System.out.println("El agente está en la agencia B");

} }

Agencia B

run(){ if (x==0) {

System.out.println("El agente está en la agencia A"); x=1; move (agenciaB);

} else {

System.out.println("El agente está en la agencia B");

} }

Migración débil



♦ Migración intra-plataforma: el agente se mueve entre dos agencias que pertenecen a

la misma plataforma, por lo tanto, ambas agencias tienen las mismas interfaces y

además proveen un entorno similar. Cuando los sistemas origen y destino son

compatibles, se dice que se trata de un escenario homogéneo. En este caso, el agente

puede migrar y ejecutarse en la agencia remota sin necesidad de que se modifique su

código. En un escenario homogéneo es posible soportar tanto migración fuerte como

débil.

♦ Migración inter-plataforma: el agente se mueve entre agencias pertenecientes a

distintas plataformas. Se pueden dar dos situaciones: que las agencias correspondan a

dos instancias distintas del mismo tipo de plataforma o que correspondan a dos

plataformas de diferentes tipos. El primer caso presenta un escenario homogéneo, por

lo que no habría que resolver problemas de compatibilidad para implementar la

migración. El segundo caso, en cambio, plantea un escenario heterogéneo, en el que

hay que tratar con la interoperabilidad de las plataformas y con la incompatibilidad de

los sistemas subyacentes para llevar a cabo la migración. En general, las plataformas

existentes en la actualidad no son interoperables, ya sea porque responden a distintos

estándares, porque ofrecen interfaces diferentes para el programador o porque están

desarrolladas en distintos lenguajes de programación. Algunas aplicaciones, por

ejemplo, han resuelto las diferencias en las interfaces mediante software a modo de

wrapper (envoltorio) entre el agente y la plataforma, el cual se encarga de realizar las

traducciones necesarias. La incompatibilidad en los sistemas subyacentes o en los

lenguajes de programación, situaciones en las cuales el código del agente directamente

no se puede ejecutar en la plataforma destino, es aún más difícil de resolver. De las

investigaciones al respecto han surgido algunas propuestas, como las basadas en la

conversión del código del agente al lenguaje soportado en la plataforma destino o en

la regeneración del agente en el destino a partir de un modelo que describe su

estructura en un formato independiente del sistema operativo y de la plataforma, el

cual es transportado en la migración junto con su estado.

Destino de la migración: generalmente el destino de la migración es una agencia remota

cuyo nombre es conocido. Se puede especificar solamente el próximo destino o bien darle

al agente un itinerario completo o ruta a seguir. Esta ruta puede ser definida por el



programador del agente y ser fija (el agente no puede modificarla durante su ejecución) o

ser totalmente flexible, permitiendo al agente definir su propia ruta.

Efecto de la migración: comúnmente, en la migración, el agente se mueve

completamente hacia la agencia remota, por lo cual hay una única instancia del mismo.

Una alternativa es hacer una copia del mismo, la cual se envía a otra agencia y comienza

como si no hubiera existido antes. Otra opción es que el agente sea clonado, en este caso

también se envía una copia a la agencia remota, pero esta copia tiene los mismos datos

que el agente original.

Tratamiento de errores en la migración: este tópico se relaciona con el comportamiento

de la agencia si la migración falla. Esto puede suceder, por ejemplo, porque la agencia

destino no acepta agentes desde la agencia origen, porque ambas agencias usan diferentes

versiones de protocolo de migración, etc. Las acciones a seguir dependen de si el tipo de

movilidad elegido es débil o fuerte. Si el tipo de movilidad es débil, el agente se debe

volver a iniciar en la agencia origen y el error se puede indicar utilizando una variable

local o invocando un método del agente que reciba como parámetro el motivo de la falla.

En cambio, si el tipo de movilidad es fuerte, una buena práctica sería lanzar una

excepción.

4.5.2 Vista del agente

Estrategias de migración

Se conoce como estrategia de migración el tipo de traslado de código que se usa

para la migración del agente. Braun y Rossak (2005: 87) enumeran cuatro estrategias de

migración según el tipo de transmisión, el sitio al que se transmite y la granularidad del

código (figura 4.5).

Una primera aproximación, denominada estrategia push, consiste en transmitir

simultáneamente el agente serializado (datos e información de estado) y el código del mismo

(junto con el código de todos los objetos referenciados). Algunos toolkits no transmiten el

código completo sino que filtran las piezas de código que ya están disponibles en cada

plataforma, por ejemplo, las clases o bibliotecas estándar del lenguaje de programación y el

código del toolkit de agentes. Esta estrategia favorece la autonomía del agente, ya que éste no

necesita conectarse a la agencia origen. También es rápida porque solamente se necesita una

transmisión para el agente completo. Cuando un agente llega al destino, su ejecución



comienza inmediatamente, sin que sea necesario cargar código posteriormente. Sin embargo,

tiene la desventaja de que se transmite código que probablemente nunca se usará. Existen dos

variantes de esta estrategia:

Push-all-to-next: el código se transmite únicamente al próximo al sitio destino.

Push-all-to-all: el código se envía a todas las plataformas que el agente va a visitar y no

únicamente al próximo destino. Por supuesto, para utilizar esta estrategia se necesita

conocer el itinerario del agente de antemano.

En la segunda aproximación, conocida como estrategia pull, no se transmite código

con la transmisión de datos. Después de recibir y deserializar el agente, la agencia destino

comienza a cargar dinámicamente los archivos de código correspondientes a medida que se

requieren. Esta aproximación puede tener peor desempeño que la anterior, porque cada vez

que se necesite una clase se perderá tiempo en abrir una conexión de red y transferirla. Se

puede dividir en:

Pull-per-unit: carga el código dinámicamente utilizando una política “por clase”.

Pull-all-units: carga todos los archivos de clases como un paquete, aún si se necesita

cargar una sola clase.

Figura 4.5: Perspectivas de las estrategias de migración1


Pull-per-unit Pull-all-units

Push-all-to-all

Push-all-to-next

Todos los sitios

Próximo sitio

PULL PUSH

TIPO

DE

TRA

NSM

ISIÓ

N

GRANULARIDAD DEL CÓDIGO

Archivo de clase Paquete de clases



Todos los toolkits de agentes móviles ofrecen al menos una de las estrategias de

migración mencionadas, incluso algunos realizan combinaciones entre ellas.

Transferencia del código

Este tópico se ocupa de las cuestiones concernientes a la reubicación del código del

agente durante el proceso de migración, por lo que está estrechamente relacionado con las

estrategias de migración tratadas en el tópico anterior.

En caso de utilizarse una estrategia push, se debe decidir qué clases enviar a la

agencia destino. De manera general se puede optar entre las siguientes alternativas:

Enviar todas las clases que el agente usará durante su tiempo de vida, es decir, la clase

principal del agente y todas las clases que son usadas por variables, parámetros de

métodos, valores de retorno de métodos y variables locales.

Enviar únicamente aquellas clases para las cuales existe un objeto en el agente serializado,

ya que estas clases son las que se necesitan en el destino para deserializar al agente con

éxito. Sin embargo, esto no incluye las clases que no están siendo usadas en la agencia

actual pero que probablemente sí se requerirán en la próxima agencia.

Agrupar las clases en archivos JAR1, de manera que cuando se requiera una clase que esté

almacenada dentro de un archivo JAR se transmita el archivo completo.

Permitir que el programador tome la decisión de qué clases transferir.

En caso de utilizarse una estrategia pull, se debe determinar el lugar donde la

agencia remota debe buscar las clases a cargar. En la figura 4.6 se muestran las posibilidades

más comunes:

El código ya se encuentra disponible en la agencia destino. Puede estar en un caché local

donde la agencia almacene todos los archivos de código que ya fueron cargados o en el

sistema de archivos local. La técnica de caché es útil para ahorrar tiempo cuando se

cargan los mismos archivos de código frecuentemente, pero tiene la desventaja de que si

cambia el código y el caché no es informado, la agencia puede utilizar código

desactualizado.

1 Esta característica se mencionó en la sección 4.5.1, al tratar el tópico relacionado con el código del agente.



El código se encuentra en otra agencia, generalmente la agencia origen del agente o bien

la última visitada. Por lo tanto, la agencia destino debe solicitar a dicha agencia el envío

del código.

El código es mantenido en un servidor de código independiente, del cual la agencia

destino debe recuperarlo bajo demanda.

Figura 4.6: Transferencia del código del agente durante la migración

4.5.3 Vista de la red

En este punto se consideran los aspectos relacionados con la transmisión de datos.

Se denomina estrategia de transmisión al mecanismo utilizado para transmitir un agente a un

sitio remoto. Dicho mecanismo incluye un protocolo de migración y un protocolo de

transmisión (o protocolo de red).

Protocolo de migración

El protocolo de migración establece las reglas de comunicación para transferir un

agente de una agencia a otra. Suele estar basado en una arquitectura peer-to-peer, en la cual

los agentes pasan directamente de una máquina a otra, para evitar los cuellos de botella que

podría producir una arquitectura centralizada.

Algunos toolkits, implementados en lenguaje Java, usan un protocolo de migración

propietario muy simple basado en RMI. Cada agencia de una plataforma se implementa como

un servidor RMI que provee un método para recibir agentes móviles, el cual es invocado en

forma remota por la agencia que desea enviar un agente. El agente serializado se envía cómo

Origen

Agente

Código

Servidor de Código

Código

Destino

Agente

Código A

C

B



parámetro de dicho método. La desventaja de utilizar RMI es su bajo rendimiento. Por este

motivo, muchos toolkits utilizan otros protocolos de migración más complejos basados en

TCP/IP o HTTP.

Se debe decidir si se utiliza un protocolo de migración con o sin confirmación de

recepción por parte de la agencia destino. La ventaja de usar un protocolo sin confirmación es

su rendimiento, aunque es menos confiable.

Otro aspecto a considerar es si, en caso de ocurrir alguna falla, el protocolo garantiza

que el agente sea transmitido en forma atómica, es decir, se transmite completamente o no se

transmite nada.

Protocolo de transmisión

El protocolo de transmisión es el protocolo de red sobre el cual está construido el

protocolo de migración. Un agente puede ser transferido usando sockets TCP/IP o usando un

nivel de comunicación mayor como RMI, SMTP, HTTP, CORBA, etc.

4.6 Desventajas de las técnicas de migración simples

En la sección anterior se abordaron los distintos tópicos concernientes a la técnica de

migración o modelo de movilidad. Si se utilizan técnicas de migración simples, en lugar de

desarrollar soluciones flexibles, modulares y de mayor rendimiento que optimicen el proceso

de migración, aparecen algunos problemas que opacan las ventajas de los agentes móviles1.

Estos problemas producen alta sobrecarga en la red y aumentan el tiempo de procesamiento

comparado con técnicas cliente-servidor. Se detallan a continuación:

El tamaño del código de un agente es más grande que el de un simple requerimiento

cliente-servidor y causa una sobrecarga fija en cada migración. Enviar código de gran

tamaño hacia agencias remotas sólo se justifica si el tamaño de los resultados a enviar de

regreso se puede reducir considerablemente, realizando filtrado o compresión de los datos.

En algunas ocasiones no se puede evitar enviar código que en el destino nunca será

utilizado. Éste es el caso de la estrategia de migración push-all-to-next. Sin embargo, aún

utilizando estrategias de tipo pull, se podría transmitir código superfluo. Por ejemplo, en

los toolkits desarrollados en Java, por la manera en que está implementada la técnica de

1 Ver capítulo 2, sección 2.7.



serialización de objetos, el código de una clase se transmite si un objeto de ese tipo es

parte del agente serializado, aunque no sea accedido (usado o definido).

Si los datos del agente son transmitidos como una unidad simple, el agente móvil

transportará ítems de datos a todas las agencias de su itinerario aunque en algunas de ellas

éstos no se usen. Por esta razón, el rendimiento de los agentes móviles se ve perjudicado

cuando el número de agencias a recorrer es alto.

El daño ocasionado por estas desventajas se puede atenuar si se consideran modelos

de movilidad más sofisticados. Para ello, se necesita abordar aspectos relacionados con la

optimización del rendimiento de agentes móviles en general, los que se tratan a continuación.

4.7 Rendimiento de los agentes móviles

El rendimiento de los agentes móviles está influenciado por varios factores y, en el

ciclo de vida de un agente móvil típico, se pueden encontrar varias áreas donde es posible

mejorar su rendimiento. Por ejemplo, en las tareas dadas por el usuario, en su ruta o itinerario,

en el tamaño del código o de los datos recolectados, en los parámetros de la red (ancho de

banda y latencia), etc. Braun y Rossak (2005: 102) realizan una clasificación de estos

aspectos, dividiéndolos en: aspectos de runtime (ejecución) y aspectos de transmisión (ver

figura 4.7).

4.7.1 Aspectos de runtime

Aquí se tratan las técnicas con las cuales se puede mejorar el tiempo de ejecución de

un agente.

Formato del código

El formato del código influye en el tamaño del mismo y por lo tanto, influye en su

tiempo de ejecución y, en menor escala, en el tiempo de transmisión. En sistemas

heterogéneos, como los de agentes móviles, el código debe ejecutarse en máquinas que

presentan diferentes arquitecturas. Es por ello que es conveniente enviar el código del agente

en un formato intermedio, independiente de la arquitectura del procesador subyacente. En

cada agencia este código intermedio es interpretado por algún tipo de máquina virtual. Un

ejemplo muy popular de formato de código intermedio son los bytecodes del lenguaje Java;



los toolkits desarrollados en este lenguaje, utilizan este formato para transmitir el código del

agente.

Figura 4.7: Clasificación de tópicos de rendimiento de agentes móviles1

Ejecución de código

Un aspecto que afecta el rendimiento es la arquitectura del hardware subyacente, por

ejemplo, CPU, memoria, carga del sistema, etc. Los parámetros de hardware son

especialmente importantes en el caso de Java porque la máquina virtual por sí misma ocupa

1 Figura adaptada de Braun y Rossak (2005: 103).

RENDIMIENTO DE

AGENTES MÓVILES

ASPECTOS DE

RUNTIME

ASPECTOS DE

TRANSMISIÓN

FORMATO DECÓDIGO

EJECUCIÓN DECÓDIGO

VISTA DEL PROGRAMADOR

VISTA DEL AGENTE

VISTA DE LA RED

FORMATO DE TRANSMISIÓN

FORMATO DE BYTECODE

HARDWARE

AGENCIA

TIPO DE MOVILIDAD

CACHÉ DE CÓDIGO

SERVIDOR DE CÓDIGO

ÍTEMS DE DATOS

LATENCIA

ARQUITECTURA

ITINERARIO

ANCHO DE BANDA

ESTRATEGIA DE MIGRACIÒN



gran cantidad de memoria. Lamentablemente, estos parámetros no pueden ser influenciados

por el agente o por el programador del mismo.

Otro tópico importante para el rendimiento de un sistema de agentes móviles es la

plataforma en la cual se ejecutan. En particular, las plataformas implementadas en lenguaje

Java pueden resolver algunas desventajas de la JVM desarrollando técnicas alternativas.

Algunos autores proponen nuevas técnicas de serialización de objetos, las cuales aceleran el

proceso completo de serialización o producen un objeto serializado de menor tamaño. Ya que

los sistemas de agentes son sistemas multi-hilos y la creación de hilos es costosa en Java, otra

posible mejora es la optimización del manejo de los mismos utilizando un pool de hilos. La

técnica consiste en mantener una especie de estructura o pool de hilos dormidos; cuando se

necesita un nuevo hilo, se reanuda uno existente en el pool y se asocia a la nueva tarea.

Cuando finaliza la tarea se coloca al hilo otra vez en el pool.

4.7.2 Aspectos de transmisión

Se tratan todas las técnicas que influyen sobre la carga de la red y el tiempo de

transmisión utilizado durante la migración del agente. Acorde a las tres vistas de los modelos

de movilidad, se distinguen tres tópicos de optimización.

Vista del programador

Desde el punto de vista del programador del agente, el factor más influyente es qué

tipo de movilidad se ofrece. La movilidad débil es más fácil de ejecutar y otorga mejor

rendimiento en los sistemas basados en Java. En cambio, la movilidad fuerte incrementa el

tamaño del código y el tiempo de transmisión, así como también el tiempo de ejecución.

Otro aspecto concerniente al programador es el itinerario que el agente debe

recorrer. El orden en el cual visita cada agencia es muy importante para aumentar el

rendimiento. Se han desarrollado numerosas estrategias a fin de optimizar esta tarea.

Los tópicos mencionados encuadran dentro de una optimización sobre el nivel

macro del sistema de agente.

Vista del agente

Desde el punto de vista del agente, el rendimiento del mismo está influenciado por

las técnicas de traslado de código y datos; esto se denomina nivel de optimización micro.



El tópico de optimización aquí es la cantidad de sobrecarga que se produce con la

migración de un agente entre dos agencias. El tiempo utilizado para la migración puede no

depender directamente del número de bytes transmitidos, porque en redes con valores de

ancho de banda variables, podría ser más rápido enviar una gran cantidad de bytes a través de

una conexión con alto ancho de banda que enviar un pequeño número de bytes a través de una

conexión con poco ancho de banda.

Las técnicas para optimizar la carga de la red y el tiempo de transmisión se deducen

claramente de las desventajas de la utilización de técnicas de migración simples, las que ya

fueron detalladas anteriormente en este capítulo. Según afirman Braun y Rossak (2005: 108),

no existe una estrategia de migración que funcione bien en todas las situaciones, es decir, una

única estrategia no es capaz de producir menor carga en la red y tiempo de transmisión en

todos los escenarios posibles. Por lo cual, a fin de lograr un mejor rendimiento, sería

conveniente que se pueda elegir dinámicamente la estrategia de migración de acuerdo con el

escenario que se presente. Existen algunos toolkits que ofrecen esta característica.

Otro aspecto a considerar si se utilizan estrategias del tipo pull es la transmisión de

clases. Utilizar un caché de clases mejora el rendimiento del sistema porque previene la

transmisión de unidades de código iguales, este tema ya se explicó previamente en este

capítulo al detallar las distintas opciones de transferencia del código.

En los casos en los que se necesite realizar la descarga de clases, esta tarea se debe

realizar de la manera más rápida posible, es por ello que otro tópico relacionado con el

rendimiento es el lugar donde se mantendrá el código del agente (servidor de código). Las

alternativas utilizadas son: poseer un único servidor de código (generalmente es la agencia

origen) o tener más de uno (los servidores no necesitan estar ubicados en el mismo host). En

este último caso se puede mejorar el rendimiento de la migración, descargando el código de

servidores cercanos a la agencia a la cual se migró, en vez de realizar la descarga desde la

agencia origen. Otra optimización posible es permitir que el código comience a ejecutarse

antes de que la transmisión se haya completado. Por ejemplo, si se utiliza el formato de

archivos JAR para el código, las clases que componen el mismo se pueden ordenar ubicando

al comienzo del archivo aquellas que se necesiten primero.

El último tópico a tratar se relaciona con una de las desventajas de las técnicas de

migración simples tratadas anteriormente y es el manejo de los datos del agente. Se debe

tratar de evitar que éste lleve consigo ítems de datos innecesarios durante el recorrido de su



itinerario. Una técnica es transmitir ítems de datos independientemente del estado del objeto,

es decir, permitir que el agente pueda descargarlos dinámicamente desde la agencia origen

cuando realmente los necesite. Esto es imposible de implementar en los toolkits que utilizan la

técnica de serialización de objetos estándar de Java.

Vista de la red

Desde el punto de vista de la red, se pueden encontrar tres factores que influyen

sobre el rendimiento de los agentes móviles: el ancho de banda, la latencia y la arquitectura de

la red sobre la cual el agente puede operar. El tipo de red, por ejemplo si todas las conexiones

poseen la misma calidad, tiene gran impacto sobre el rendimiento. Por supuesto, ni el agente

ni el programador del mismo pueden influir sobre esos valores, sin embargo es importante que

sean capaces de reaccionar ante cambios en ellos.


Capítulo 5 Comunicación de agentes móviles

Si bien es posible desarrollar aplicaciones distribuidas utilizando un único agente

móvil para realizar determinada tarea o varios agentes móviles que operen en forma

totalmente independiente, es común que las aplicaciones complejas estén basadas en sistemas

multiagentes. Como ya se ha dicho, estos sistemas están compuestos por varios agentes que

interactúan en forma coordinada, integrando sus objetivos particulares en un objetivo común1.

La comunicación es fundamental para llevar a cabo dicha interacción. En los sistemas

multiagentes, la comunicación determina el comportamiento social de los agentes y permite la

negociación y la cooperación entre ellos. Es importante que exista un lenguaje que pueda ser

entendido por todos los agentes presentes en el sistema, ya que, además de datos, los mensajes

que intercambian tienen asociado un contenido semántico.

Al comienzo de este capítulo se tratarán los tópicos referentes a la comunicación de

agentes móviles; luego, se describirán los distintos modelos de comunicación existentes. Otro

tema importante que se abordará y que está estrechamente relacionado con la migración de

agentes, es la comunicación transparente de la ubicación, es decir, las técnicas que utilizan

las plataformas de agentes para permitir que éstos se comuniquen de manera confiable

independientemente de su ubicación actual. Por último, se presentarán los lenguajes de

comunicación de agentes, mencionando algunos estándares.

5.1 Tópicos de comunicación de agentes móviles

La comunicación no es un tema específico de los agentes móviles, sino que

concierne a los agentes de software en general. Sin embargo, la movilidad da origen a algunos

problemas particulares a este tipo de agentes.

Considerando que la principal característica de estas entidades es precisamente su

movilidad, se podría pensar que, cuando un agente móvil necesita comunicarse con un agente




que reside en una agencia remota, puede viajar hacia esa agencia y comunicarse localmente.

Sin embargo, hay situaciones en las cuales la migración es más costosa que la comunicación

remota; por ejemplo, cuando los agentes requieren intercambiar poca cantidad de información

para coordinar sus tareas. La dificultad se presenta cuando el destinatario de un mensaje es un

agente móvil que está viajando por la red, ya que en este caso no es tan simple determinar la

ubicación del mismo en un momento dado. Esto da lugar a los siguientes aspectos

relacionados con la comunicación entre agentes móviles:

Ubicación transparente: debido a que los agentes pueden moverse a través de la red

subyacente en forma autónoma, es difícil predecir la ubicación actual de un agente

específico. La solución más amigable a este problema es brindar al programador un

servicio de ubicación transparente. De esta forma sólo se necesita conocer el nombre del

agente con el cual se desea realizar la comunicación.

Confiabilidad de la comunicación: aún si se conoce la ubicación del agente, la entrega

del mensaje podría causar un error, ya que el agente podría migrar antes de recibirlo. Las

plataformas deberían proveer de algún mecanismo que asegure que todos los mensajes

serán reenviados a la nueva ubicación del agente.

Semántica del modelo de comunicación: suponiendo que el modelo garantiza la entrega

del mensaje a un agente, éste podría recibir el mismo mensaje varias veces. En ciertas

situaciones esto puede ser tolerable, pero si el estado interno del receptor cambió ante la

recepción del primer mensaje, la segunda instancia del mismo mensaje podría causar un

error. Las semánticas de entrega de mensajes posibles son: “al menos una vez” (asegura

que el mensaje es entregado, pero el receptor puede recibir el mismo mensaje varias

veces); “cero ó más veces” (el mensaje puede no ser entregado o entregado posiblemente

más de una vez); “a lo sumo una vez” (se asegura que el mensaje no será entregado más

de una vez, pero puede ocurrir que no sea entregado).

Eficiencia del modelo de comunicación: la eficiencia del modelo de comunicación se ve

influida, principalmente, por la forma en que se actualiza la ubicación del agente cuando

migra de una agencia a otra y por la forma en que se entrega el mensaje, lo cual incluye

ubicar al agente destino y enviar el mensaje a la agencia en la cual éste reside. Cada

modelo de comunicación provee diferentes soluciones para las acciones mencionadas, las

cuales difieren significativamente en términos de sobrecarga de la red. Otra medida de la



eficiencia es cómo escala el modelo si el número de agentes aumenta y si distingue entre

migraciones locales en una subred simple y migraciones en redes de área amplia.

La mayoría de los toolkits de agentes móviles proveen algún tipo de comunicación

local, por la cual agentes que residen en la misma agencia pueden comunicarse; pero

únicamente unos pocos permiten la comunicación global, es decir, que agentes que residen en

distintas agencias, especialmente en diferentes hosts físicos, puedan intercambiar mensajes y

compartir información.

5.2 Clasificación de los modelos de comunicación

Las técnicas de comunicación para agentes móviles se pueden clasificar en dos tipos

de modelos de comunicación: pasaje de mensajes y espacio de información (figura 5.1).

Figura 5.1: Clasificación de modelos de comunicación

5.2.1 Pasaje de mensajes

Este modelo de comunicación permite que los agentes se envíen mensajes unos a

otros. Es un tipo de comunicación directa en la cual el emisor del mensaje debe conocer al

receptor por su nombre y su ubicación actual. No define la estructura ni la semántica del

contenido del mensaje. Este modelo puede ser usado como fundamento para implementar el

intercambio de mensajes de texto, objetos Java o cualquier otra estructura de mensaje acorde

con algún Lenguaje de Comunicación de Agentes (ACL). Los lenguajes para comunicación

entre agentes móviles se tratarán más adelante en este capítulo.

MODELOS DE

COMUNICACIÓN

PASAJE DE MENSAJES

ESPACIO DE INFORMACIÓN

SÍNCRONO / ASÍNCRONO

PIZARRA

ESPACIO DE TUPLAS

PUNTO A PUNTO / MULTIPUNTO



Como parte del modelo de pasaje de mensajes se debe contar con algún tipo de

servicio en el cual los agentes puedan encontrar los nombres de otros agentes y alguna

descripción de los servicios que proveen. Si este servicio no está disponible, la comunicación

sólo se puede realizar entre un grupo de agentes que se conocen unos a otros de antemano.

El pasaje de mensajes se puede realizar en dos formas: punto a punto o multipunto.

En la conexión punto a punto, un agente envía mensajes exactamente a un agente receptor. El

emisor pide a la agencia (en realidad, a un componente de software responsable de proveer

este tipo de comunicación) que entregue el mensaje en el buzón del receptor. Únicamente el

agente receptor debería ser capaz de leer el mensaje. En la otra forma, con comunicación

multipunto, un agente puede enviar un mensaje a un grupo de agentes (multicast) o a todos los

agentes existentes en el sistema (broadcast).

Otro criterio que se necesita establecer para el pasaje de mensajes es si serán

enviados en forma síncrona o asíncrona. Hay tres variantes posibles:

1. Pasaje síncrono de mensajes (parada y espera): el emisor bloquea su ejecución cada

vez que trasmite un mensaje hasta que el receptor le responde. Este esquema de parada y

espera es el más popular y garantiza que el mensaje será entregado; en caso de que esto no

suceda, el emisor será avisado del error. La comunicación síncrona, naturalmente, implica

que ambos agentes (emisor y receptor) permanecerán estáticos durante la comunicación.

2. Pasaje asíncrono de mensajes basado en dos envíos: el emisor no tiene que esperar

hasta que el receptor envíe la respuesta. Este esquema es más flexible y especialmente

útil cuando múltiples agentes interactúan con uno. Para su correcta implementación es

necesario mantener en el emisor un identificador del mensaje enviado para no tener que

bloquear la ejecución actual e ir preguntando en determinados momentos si hay una

respuesta para el mensaje transmitido.

3. Pasaje asíncrono de mensajes basado en un envío: por ser un esquema asíncrono, al

igual que en el esquema anterior, no se bloquea la ejecución. En este caso, el emisor no

retiene el identificador del mensaje y el receptor no tiene que responder. Obviamente, este

esquema es muy útil cuando el agente que transmite un mensaje no espera la pertinente

respuesta.

La mayoría de los toolkits proveen pasaje asíncrono de mensajes, mientras que

algunos proveen ambas formas (síncrona y asíncrona) en paralelo.



5.2.2 Espacio de información

Este modelo provee a todos los agentes un espacio común en donde ellos pueden

intercambiar información, datos y conocimiento, unos con otros. Esta forma de comunicación

es indirecta, porque los agentes no interactúan directamente sino que un agente escribe datos

en el espacio de información y otros agentes pueden leerlos. En algunas implementaciones,

incluso el nombre del agente que ha colocado los datos es desconocido, esto resulta en una

forma de comunicación anónima.

La diferencia más importante de este modelo respecto al anterior es que, con pasaje

de mensajes, el agente emisor tiene la responsabilidad de definir qué información debe ser

enviada. Además, cada agente receptor debe decidir qué información o resultados recibirá de

otros agentes y cómo reaccionará a cada mensaje recibido. Se podría decir que, si se usa el

modelo de comunicación por pasaje de mensajes, el control y el flujo de datos de una

aplicación es más o menos predefinido.

Por el contrario, con el modelo de espacio de información, un agente escribe en el

espacio común los datos que podrían ser de interés para el grupo de agentes. Es

responsabilidad de cada agente revisar el espacio de información y reaccionar ante cualquier

tipo de modificación o datos nuevos. Este modelo de comunicación puede ser definido como

no determinista, porque no está predefinido qué agente procesará la información nueva.

Dentro de este modelo se pueden distinguir dos aproximaciones: pizarra y espacio

de tuplas.

En los sistemas orientados a pizarra, la información es guardada con un

identificador que es especificado por el agente que la deposita y debe ser conocido por los

agentes que la van a leer, de manera que puedan encontrar esta información más tarde.

En la aproximación de espacio de tuplas, los datos se organizan en tuplas, las cuales

se ordenan como colecciones de información. El espacio de tuplas contiene un conjunto o

múltiples conjuntos de tuplas, las cuales están definidas por su contenido más que por su

nombre y pueden ser recuperadas utilizando algún mecanismo de combinación de patrones.

5.3 Comunicación transparente de la ubicación

Algunos toolkits de agentes móviles han implementado técnicas para permitir que

los agentes se comuniquen de manera confiable independientemente de su ubicación actual.



De los modelos de comunicación que se describieron en la sección anterior, el más

utilizado ha sido el pasaje asíncrono de mensajes. Por esto, de aquí en adelante en este

capítulo, se hará referencia exclusivamente a este modelo a menos que se indique lo contrario.

En general, las técnicas de comunicación transparente de la ubicación buscan

solucionar los siguientes puntos:

Seguir la pista del agente, para poder determinar su posición actual en cualquier momento.

Asegurar la entrega de mensajes, enviándolos a la posición actual del agente si éste no se

encuentra en la misma agencia que el agente emisor.

Las técnicas que se describirán a continuación se pueden dividir en aproximaciones

centralizadas y distribuidas, dependiendo del lugar en donde se almacena información sobre

la ubicación de los agentes del sistema (figura 5.2).

Figura 5.2: Algunas técnicas de comunicación transparentes de la ubicación

5.3.1 Servidor Central

Como su nombre lo sugiere, esta aproximación utiliza un único servidor central para

almacenar la ubicación actual de todos los agentes del sistema. Para esto, cada agente debe

avisar al servidor antes de dejar una agencia e informarle su nueva ubicación al llegar a otra

agencia.

Hay dos variantes de esta técnica: que el servidor sea responsable sólo de seguir la

pista de cada agente o también de la entrega de mensajes. En la primera, cuando un agente

Comunicación transparente de

la ubicación

Técnicas centralizadas

Técnicas distribuidas

Servidor Central

Servidor Origen

Broadcast

Punteros de Reenvío

Jerárquicas



desea enviar un mensaje debe solicitar al servidor la ubicación actual del agente destino y

enviar el mensaje directamente a esa agencia. Si el agente está en tránsito o no ha actualizado

su ubicación, el emisor debe reintentar el envío más tarde. En la segunda, todos los mensajes

son enviados al servidor, el cual se encarga de reenviarlos al agente que corresponda. Si el

agente no está registrado, el servidor puede guardar el mensaje y esperar un tiempo

especificado o enviar una notificación de error al emisor.

Esta técnica tiene la desventaja de que cada agente debe contactarse dos veces con el

servidor en cada migración. Además, en la segunda variante, el servidor debe ser contactado

para cada mensaje. Por esto, no es una solución escalable con respecto a la cantidad de

agentes ni de mensajes. Además, como toda solución centralizada, el servidor es un cuello de

botella para el sistema y un único punto de falla.

5.3.2 Servidor Origen

Esta técnica es una extensión de la anterior, en la cual cada agencia registra la

ubicación de los agentes que fueron iniciados en ella. Cada agente debe informar su ubicación

actual a su agencia origen. Cuando un agente desea enviar un mensaje, debe contactarse con

la agencia origen del agente destino, la cual es conocida porque forma parte de los atributos

de un agente.

Como en el caso anterior, el servidor puede ser responsable sólo de responder a

consultas sobre la ubicación de los agentes registrados en él o también de reenviar los

mensajes dirigidos a ellos hacia su ubicación actual.

Es más escalable que la aproximación anterior, excepto cuando un gran número de

agentes se inician en la misma agencia. Además, esta solución también tiene un único punto

de falla y no es válida si la agencia origen de un agente se desconecta de la red cuando el

agente migra.

5.3.3 Punteros de Reenvío

Esta solución, en lugar de mantener centralizada la información sobre la ubicación

de los agentes, consiste en que cada agente, al abandonar una agencia, deje en ella un puntero

a su nueva ubicación. Cada agencia, además de saber qué agentes están residiendo en ella,

debe almacenar la siguiente posición de cada agente que la ha visitado; dicha posición es

actualizada por la agencia al recibir la confirmación de recepción del agente serializado

(ACK) por parte de la agencia a la cual el agente migró. Cuando un agente desea enviar un



mensaje, lo remite a la agencia origen del agente destino. El mensaje es enviado, a partir de la

agencia origen, a través de la cadena de punteros hasta llegar a la ubicación actual del agente.

Para implementar esta técnica hay una serie de cuestiones que se deben tener en

cuenta. En primer lugar, es posible que se genere un ciclo en la cadena de punteros en el caso

de que un agente pase por la misma agencia más de una vez y que ésta reciba los ACK de las

agencias a las cuales el agente migró en orden invertido, quedando desactualizada la

ubicación del mismo. Este problema se puede resolver incorporando a los ACK un contador

que el agente incrementa con cada migración, a fin de poder descartar los mensajes viejos.

Otro inconveniente de esta técnica es que la cadena de punteros puede crecer mucho

si el agente migra muy frecuentemente, lo cual incrementaría el tiempo de entrega de los

mensajes. Hay distintas formas de acortar la cadena, una de ellas es que, luego de un número

predefinido de saltos, el agente informe su ubicación actual a su agencia origen, eliminando

así de la cadena todas las agencias visitadas previamente.

Por otra parte, la técnica no es confiable si la agencia origen se desconecta de la red,

si la cadena se rompe a causa de una falla en una de las agencias que la componen o si el

agente migra tan rápido que no es posible entregarle sus mensajes.

La ventaja de esta aproximación es que reduce la cantidad de mensajes que los

agentes deben enviar para mantener actualizada su ubicación, por lo cual es adecuada cuando

los agentes migran frecuentemente, pero sólo dentro de un área pequeña y a poca cantidad de

agencias.

5.3.4 Broadcast

En las aproximaciones basadas en broadcast, la ubicación de un agente se determina

mediante el envío de mensajes desde una agencia hacia muchas agencias. Estas técnicas

difieren en el tipo de información que se envía mediante broadcast. Una opción es enviar el

mensaje mismo desde la agencia donde se encuentra el agente emisor hacia todas las demás

en la red lógica de agencias, hasta que lo reciba la agencia donde reside el agente destino.

Cuando el tamaño de los mensajes es muy grande, no conviene enviarlos a todas las agencias.

En lugar de eso, se puede enviar sólo una consulta sobre la ubicación del agente destino; la

agencia en la cual reside dicho agente responde informando su dirección y además impide que

el agente migre hasta que haya recibido el mensaje. Otra alternativa, es que los agentes envíen

mensajes broadcast de notificación (acompañados de un timestamp) cada vez que llegan a una



nueva agencia, de manera que todas las agencias conozcan la ubicación de todos los agentes.

En este último caso, en contraste con los dos anteriores, la entrega de mensajes es directa pero

la migración tiene un alto costo al tener que propagarse por toda la red la nueva ubicación de

cada agente.

En general, las aproximaciones basadas en broadcast tienen la ventaja de que no

requieren que una agencia específica almacene la información relacionada con la ubicación de

los agentes ni sea el punto de inicio de una cadena de punteros. Por esto, son útiles cuando no

se puede contar con la conexión permanente de las agencias a la red, como en el caso de redes

peer-to-peer o hosts móviles. Por otra parte, el envío de mensajes broadcast produce una gran

sobrecarga en la red, por lo cual no es adecuado en sistemas a gran escala. Una mejora que se

puede aplicar, en caso de conocerse de antemano el itinerario de un agente, es enviar los

mensajes sólo a las agencias que se encuentran en dicho itinerario (multicast).

5.3.5 Aproximaciones Jerárquicas

Las aproximaciones jerárquicas se basan en una estructura de árbol cuyos nodos

representan agencias. Dicha estructura corresponde con la estructura geográfica de la red, de

manera que las agencias que están próximas geográficamente tienen un ancestro común en el

árbol. Toda agencia que se encuentra en la raíz de un subárbol (es decir, todas excepto las que

están en las hojas), almacena información para alcanzar a todos los agentes que residen en

cualquier agencia de su subárbol.

Una opción, llamada puntero a la hoja, es que cada agencia almacene la ubicación

actual de todos los agentes de su subárbol. Cada vez que un agente migra, se debe actualizar

su ubicación en todas las agencias que están en el camino desde la raíz absoluta del árbol

hasta la agencia donde reside actualmente y en todas las que están en el camino desde la raíz

absoluta hasta la nueva agencia (las agencias comunes a ambos caminos deben modificar la

ubicación del agente, las que están en el camino anterior deben eliminarlo y las que están en

el nuevo, deben agregarlo). La entrega de mensajes es directa. Partiendo de la agencia del

emisor, cada agencia entrega el mensaje a su ancestro, hasta llegar al menor ancestro común

entre el agente emisor y el destino, el cual tiene un puntero a la ubicación actual de este

último.

En otra aproximación, llamada puntero al hijo, cada agencia almacena sólo un

puntero a una agencia del nivel inferior para todos los agentes de su subárbol. En este caso,



cuando un agente migra, no es necesario actualizar las agencias comunes a los caminos entre

la raíz y la agencia actual y entre la raíz y la nueva agencia. Los mensajes, como en el caso

anterior, llegan hasta el menor ancestro común entre el agente emisor y el destino, pero a

partir de allí deben reenviarse de una agencia a otra a lo largo del camino hasta encontrar al

agente.

En general, las aproximaciones jerárquicas son más escalables con respecto al

número de agentes y a la cantidad de migraciones que las aproximaciones centralizadas.

5.4 Componentes del modelo de comunicación

Los componentes básicos de un modelo de comunicación de agentes son (figura

5.3):

Lenguaje de Comunicación: define la estructura de los mensajes para la comunicación

entre agentes.

Lenguaje de Contenido: define el formato de intercambio de conocimiento, utilizado

para representar la información del cuerpo de los mensajes.

Ontología: representa un vocabulario común en un dominio determinado (por ejemplo,

ontología de medicina, ontología de fútbol, etc.). Este vocabulario permite que dos

agentes estén de acuerdo en la interpretación semántica del contenido de los mensajes.

Figura 5.3: Componentes del modelo de comunicación

LENGUAJE DE COMUNICACIÓN

LENGUAJE DE CONTENIDO

ONTOLOGÍA



5.5 Lenguajes de comunicación

La comunicación entre agentes de software se puede implementar utilizando

cualquier lenguaje de programación, aunque no esté específicamente diseñado para ese fin. En

este caso, el programador debe desarrollar las clases, funciones, procedimientos y comandos

necesarios para crear, enviar y recibir los datos en forma de mensajes. En este contexto, se

destacan los siguientes lenguajes:

Lenguajes orientados a objetos como Java, Telescript, etc.

Lenguajes interpretados y procedimentales basados en comandos (scripts): Tcl, Phyton,

Perl, etc.

Otra alternativa, es utilizar algún lenguaje especialmente diseñado para la

comunicación entre agentes (ACL). Estos lenguajes, conocidos como declarativos, están

basados en la teoría de actos del habla. Esta teoría, desarrollada por filósofos y lingüistas para

ayudar a comprender la comunicación humana, sostiene que el lenguaje natural no sólo

expresa sentencias (que pueden ser verdaderas o falsas) sino que permite realizar

declaraciones con carácter de acciones, en el sentido de que pueden cambiar el estado del

entorno de manera análoga a las acciones físicas. A estas declaraciones se las suele llamar

performativas. Las performativas le agregan una intención a los mensajes, por ejemplo,

preguntar, requerir, suscribir, informar, confirmar, rechazar.

Históricamente, la comunicación se realizaba mediante lenguajes propios de cada

implementación. Sin embargo, la intención de dotar a los agentes de un comportamiento

social, cooperativo y comunicativo, condujo a la necesidad de establecer estándares para

facilitar la comunicación. A continuación se mencionan dos estándares que se consideran

relevantes, primero el que representa las bases y después el más utilizado actualmente.

5.5.1 KQML (Knowledge Query and Manipulation Language)

Este lenguaje surgió a principios de los años 90, en el marco del proyecto KSE

(Knowledge Sharing Effort)1, cuyo objetivo era desarrollar protocolos, técnicas, métodos y

herramientas para el intercambio de conocimiento entre sistemas de información autónomos.

1 Organización DARPA (Defense Advanced Research Projects Agency), Estados Unidos.



KQML es un lenguaje de comunicación y protocolo de alto nivel, orientado a

mensajes. Es independiente del protocolo de transporte subyacente (HTTP, TCP/IP, etc.) y del

lenguaje de contenido y la ontología utilizados.

Un mensaje KQML tiene una performativa, que indica la intención del mensaje, y

un número de parámetros especificados como pares atributo-valor.

En la estructura de un mensaje KQML se pueden distinguir los siguientes niveles

(figura 5.4):

Comunicación: incluye los parámetros de comunicación de más bajo nivel, como por

ejemplo, la identidad del emisor y del receptor y un identificador único asociado con la

comunicación.

Mensaje: contiene la performativa asociada al mensaje y parámetros relacionados con el

control de la comunicación y la descripción del contenido; por ejemplo, el lenguaje de

contenido y la ontología asumida.

Contenido: es el contenido real del mensaje, expresado en cualquier lenguaje de

representación. Las implementaciones de los lenguajes no procesan esta parte del mensaje,

sino que lo dejan como responsabilidad al agente.

Figura 5.4: Niveles de un mensaje KQML

En la figura 5.5 se muestra la estructura básica de un mensaje en formato KQML1.

Algunos de los parámetros que constituyen un mensaje son:

:sender: Emisor real del mensaje.

:receiver: Receptor real del mensaje.

1 Las especificaciones completas del lenguaje están disponibles en http://www.cs.umbc.edu/kqml/kqmlspec/spec.html.

COMUNICACIÓN

MENSAJE

CONTENIDO

Mecanismos de la comunicación

Lógica de la comunicación

Contenido de la comunicación



:reply-with: Etiqueta esperada en respuesta al mensaje actual.

:language: Nombre del lenguaje utilizado en :content.

:ontology: Nombre de la ontología supuesta en el parámetro :content.

:content: Información relacionada con la actitud que expresa la performativa.

Figura 5.5: Formato de mensaje KQML

Las performativas asociadas a los mensajes son primitivas del lenguaje. A

continuación se presentan las más comunes, catalogadas de acuerdo con la intención que se

desea comunicar:

Preguntar: evaluate, ask-if, ask-about, ask-one, ask-all.

Reponder: reply, sorry.

Múltiples respuestas: stream-about, stream-all, eos.

Informar: tell, achieve, cancel, untell, unachieve.

Definir capacidades: advertise, subscribe, monitor, import, export.

Otras: register, unregister, forward, broadcast, route, ready.

Cabe destacar que, si bien KQML es independiente del lenguaje de contenido

utilizado en el campo :content del mensaje, está muy asociado a un lenguaje de

representación llamado KIF (Knowledge Interchage Format), que fue desarrollado por el

mismo grupo. KIF es un lenguaje formal basado en lógica de primer orden que permite

describir las propiedades de un dominio y definir relaciones entre los objetos de ese dominio.

(KMQL-performative :sender <valor> :receiver <valor> :reply-with <valor> :languaje <valor> :ontology <valor> :content <valor> …… )



KQML fue una de las primeras iniciativas para el soporte de la interacción social

entre agentes; sin embargo, no se convirtió en el estándar de facto debido a que sus

especificaciones no fueron bien aceptadas. Una de las razones de su rechazo es que, por no

contar con un conjunto de performativas bien restringido, agentes de diferentes sistemas

pueden adoptar dialectos diferentes, impidiendo la interoperabilidad. Otro problema es que no

posee una semántica definida formalmente, de manera que no garantiza que las performativas

sean correctamente interpretadas por todos los agentes. Además, el lenguaje no tiene

performativas que permitan establecer compromisos entre los agentes, lo cual puede ser

importante para la coordinación de sus acciones.

Algunos toolkits de agentes basados en KQML y Java son:

Java Agent Template, Lite (JATLite), Standford Univ.

Java-based Agent Framework for Multi-Agent Systems (JAFMAS), Univ. of Cincinnati.

Jackal, Univ. of Maryland.

5.5.2 FIPA ACL (FIPA Agent Communication Language)

Ya se ha mencionado la organización FIPA y se ha presentado su modelo de

arquitectura estándar1. En relación con la comunicación de agentes, FIPA describe un

lenguaje de comunicación estándar denominado FIPA ACL, el cual fue ampliamente aceptado

en el paradigma de agentes. La sintaxis de este lenguaje es similar a la de KQML y también se

basa en la teoría de actos del habla. Enviar y procesar mensajes equivale a ejecutar acciones

denominadas actos comunicativos (en vez de performativas, como se denominan en KQML),

los cuales permiten representar diferentes intenciones comunicativas. La semántica del

lenguaje se basa en aptitudes mentales (creencias, deseos, intenciones, etc.) y está

formalmente definida mediante lógica modal. Una de las ventajas que posee es que permite

definir nuevas primitivas a partir de un núcleo de primitivas mediante composición.

La estructura de los mensajes es la misma que en KQML. Los atributos de los

mensajes también son muy similares. En la figura 5.6 se muestra la estructura básica de un

mensaje FIPA ACL2.

1 Ver capítulo 3, sección 3.4. 2 Las especificaciones completas del lenguaje están disponibles en http://www.fipa.org/repository/aclspecs.html.



Figura 5.6: Formato de mensaje FIPA ACL

Algunos de los parámetros que constituyen un mensaje son los siguientes:

:sender: identidad del emisor del mensaje.

:receiver: identidad del receptor del mensaje(un agente o una lista de agentes).

:reply-to: indica a quien debe ser enviada la respuesta, en vez de ser enviada al emisor del

mensaje.

:content: contenido del mensaje.

:language: nombre del lenguaje utilizado en :content.

:reply-with: etiqueta esperada en respuesta al mensaje actual.

:ontology: nombre de la ontología supuesta en el parámetro :content.

:protocol: identificador del protocolo de interacción que está utilizando el emisor.

:conversation-id: introduce una expresión que se usa para identificar una secuencia de

actos comunicativos que engloban una conversación.

El único elemento que es obligatorio en todos los mensajes FIPA ACL es el nombre

del acto comunicativo, aunque se espera que la mayoría de los mensajes tengan completos los

campos :sender, :receiver y :content. En el campo :content se puede utilizar cualquier

lenguaje de contenido y ontología. Si un agente no puede, por algún motivo, procesar un

mensaje recibido, puede devolver un mensaje “not-understood”.

Los actos comunicativos se pueden agrupar de acuerdo con el propósito para el cual

se empleen. Los más comunes son:

Negociar: accept-proposal, cfp, propose, reject-proposal.

(acto comunicativo :sender <valor> :receiver <valor> :content <valor> :languaje <valor> :ontology <valor> :conversation-id <valor> …… )



Brindar información: confirm, disconfirm, inform, inform-if, inform-ref.

Requerir información: query-if, query-ref, subscribe.

Ejecutar acciones: agree, cancel, refuse, request, request-when, request-whenever.

Manejar errores: failure, not-understood.

Las conversaciones entre agentes pueden seguir determinados patrones, que se

repiten en muchos casos. Aprovechando estos patrones y su repetición, FIPA ACL definió

protocolos de interacción de alto nivel. Un protocolo es un patrón que se usa para inducir a

una conversación guiada, en la que cada agente sabe qué mensaje enviar y cuáles puede pedir.

Los protocolos de interacción pueden ser complejos, basados en esquemas de negociación o

en teoría de juegos, o más simples, por ejemplo, especificar que si un agente no sabe algo

busca a otro que lo sepa y le pregunta. Un agente indica el nombre del protocolo que desea

utilizar mediante un parámetro en el mensaje. Algunos protocolos básicos definidos por FIPA

son:

Request: un agente pide a otro que realice cierta acción.

Query: un agente pide a otro que le informe sobre algo.

Request-when: un agente pide a otro que realice cierta acción siempre que se cumpla la

precondición especificada.

Contract-net: un agente pide la realización de cierta tarea a un conjunto de agentes, los

cuales pueden negarse u ofrecer una propuesta. El iniciador decide qué propuestas acepta

y cuáles rechaza.

English-auction: modela los patrones de interacción de las subastas inglesas. Varios

agentes participan en una subasta que se inicia con un precio más bajo y luego va

subiendo.

Dutch-auction: modela los patrones de interacción de las subastas holandesas. Es el caso

inverso al anterior, varios agentes participan en una subasta que se inicia con un precio

más alto y luego va bajando.

Propose: un agente propone a una serie de agentes la realización de una tarea y éstos

aceptan o no.

Suscribe: un agente pide ser notificado si se cumple cierta condición.



La semántica del lenguaje FIPA ACL está formalmente definida mediante el

lenguaje SL (Semantic Language), el cual permite representar las creencias (conocimiento

sobre el entorno), los deseos (objetivos), las creencias inciertas y las acciones de los agentes.

Cada mensaje ACL está asociado a dos fórmulas en SL, una define las restricciones que debe

satisfacer el emisor (precondiciones de factibilidad) y la otra define el efecto racional de la

acción, es decir, el propósito del mensaje.

Algunos toolkits de agentes que utilizan FIPA ACL son:

Zeus (British Telecom).

JADE (CSELT).

Grasshopper (IKV++)

FIPA-OS (Emorphia)


Capítulo 6 Plataformas para agentes móviles

Como se definió anteriormente, una plataforma es el ambiente en donde los agentes

pueden ejecutarse1. También se mencionó que muchas veces la plataforma viene acompañada

de una herramienta que facilita la programación de agentes móviles, denominada toolkit de

agentes móviles.

Existe gran variedad de plataformas para agentes móviles, algunas se ajustan a algún

estándar como FIPA o MASIF2, mientras que otras se basan en arquitecturas de agente

propias. Se han implementado en diferentes lenguajes de programación, sin embargo, las más

difundidas tanto en el ámbito académico como en el comercial, son las basadas en el lenguaje

Java, debido a las facilidades que brinda este lenguaje para la migración de código y datos

entre sitios heterogéneos.

En la primera parte de este capítulo se especificarán brevemente las características

más relevantes de algunas plataformas de agentes móviles. Luego se presentará la plataforma

elegida para el desarrollo del caso de aplicación y se justificará la elección. Para finalizar el

capítulo, se detallarán las características de la plataforma escogida, explicando cómo funciona

el entorno de ejecución que provee y cómo debe ser utilizado el toolkit para programar

agentes móviles que se puedan ejecutar en dicho entorno.

6.1 Características de algunas plataformas

Ya se ha mencionado que el lenguaje Java es muy popular para el desarrollo de

plataformas para agentes móviles. Esto se debe, fundamentalmente, a que este lenguaje ofrece

características que facilitan la implementación del soporte para migración de código y datos

de agentes entre sitios heterogéneos. Entre estas características se resaltan: soporte multi-

plataforma, mecanismos de serialización de objetos, carga dinámica de clases, seguridad y

comunicaciones. Sin embargo, aunque Java posee numerosas ventajas para el desarrollo de 1 Ver capítulo 4, sección 4.1. 2 Ver capítulo 3, secciones 3.4 y 3.5.



agentes móviles, no permite transferir el estado de ejecución de un hilo (thread), en

consecuencia, la mayoría de las plataformas para agentes móviles basadas en este lenguaje

sólo soportan movilidad débil1. Existen algunas plataformas que no utilizan el lenguaje Java,

la mayoría de las cuales fueron desarrolladas antes del surgimiento de dicho lenguaje. Los

problemas que surgen con estas plataformas se relacionan con aspectos de portabilidad, por lo

cual no son tan difundidas como las que utilizan Java.

También existen plataformas que proveen soporte para múltiples lenguajes de

programación, es decir, este tipo de plataformas permiten al programador codificar agentes en

el lenguaje que él desee. Además proveen facilidades para que agentes escritos en diferentes

lenguajes interactúen.

A continuación, se detallarán brevemente las características de algunas plataformas

para agentes móviles.

Telescript

Se considera la primera plataforma comercial para el desarrollo de agentes móviles.

Fue diseñada por James E. White en el año 1994, asociado con la empresa General Magic.

Comprende un ambiente de ejecución y un lenguaje de programación dedicado para agentes

móviles, los cuales ya presentaban la mayoría de las características que ofrecen las

plataformas actuales.

Sus principales características son:

Basada en el lenguaje Telescript, un lenguaje propietario orientado a objetos que requiere

un intérprete (máquina virtual Telescript).

Utiliza un protocolo de transporte propio que opera en dos niveles. En el nivel más alto se

encarga de la codificación y decodificación de agentes, mientras que a bajo nivel se ocupa

del transporte de los agentes.

Provee migración fuerte.

Brinda mecanismos de seguridad: autenticación y control de acceso.

El costo de su utilización es relativamente alto debido a la cantidad de memoria que

necesita para su ejecución.

1 Ver capítulo 4, sección 4.5.2.



Telescript fue dejada de lado cuando quedó claro que no iba a ser capaz de competir

con las plataformas basadas en lenguaje Java, momento en el cual General Magic suspendió el

desarrollo de nuevas versiones.

Odyssey

Fue diseñada por General Magic en 1997. En su implementación se mantuvieron todos

los conceptos considerados en el desarrollo de la plataforma mencionada anteriormente

(Telescript), pero utilizando lenguaje Java.


Basada en lenguaje Java.

Permite la utilización de varios protocolos de transporte: Java RMI, DCOM, CORBA

IIOP.

Dispone de un modelo de seguridad.

Proporciona tipo de migración débil.

Aglets

Aglets fue desarrollada por el laboratorio de investigación de IBM en Tokio (IBM

Tokyo Research Laboratory) en el año 1996. Esta empresa fue la responsable de la

distribución de las primeras versiones (1.x), a partir de las versiones 2.x la plataforma se

puede bajar gratuitamente del sitio http://aglets.sourceforge.net/ y también se puede tener

acceso a su código fuente.


Desarrollada en lenguaje Java.

Un agente o aglet refleja el modelo de applet en Java pero con la capacidad adicional de

movilidad propia de un agente móvil, ya que puede ejecutarse autónomamente y modificar

en forma dinámica sus itinerarios.

Brinda un mecanismo de comunicación de pizarra, permitiendo que múltiples agentes

colaboren y compartan información en forma asíncrona.

Utiliza un protocolo de transporte de agentes denominado Protocolo de Transferencia de

Agentes (ATP).

Provee migración débil.



La distribución de la plataforma incluye un tookit denominado Aglets Software

Development Kit (ADSK o Aglets Workbench). También contiene abundante

documentación y ejemplos.

Tiene algunas desventajas, como la simplicidad del modelo de ciclo de vida del agente y

la carencia de soporte para el control de los recursos.

ARA (Agents for Remote Action)

Esta plataforma fue diseñada en el año 1997 por Holger Peineen de la Universidad de

Kaiserlauten en Alemania. La version 1.0 de Ara, tanto los fuentes como los ejecutables, se

pueden obtener gratis para propósitos no comerciales en el sitio: http://www.agss.

informatik.uni-kl.de/Projekte/Ara/index_e.html. La última fecha de actualización del sitio es

21/10/1997.


Está basada en un lenguaje interpretado de scripts de alto nivel desarrollado por Sun

Microsystems en 1987, denominado Tcl/tk (Tool Command Language/tk Toolkit).

Tiene incluidos además otros intérpretes, como MACE (Mobile Agent Code

Environment), que permiten la ejecución de agentes escritos en lenguaje C y C++.

También permite ejecutar agentes escritos en Java (solo versión 1.0.2).

Los agentes móviles son transmitidos usando protocolo TCP.

Dispone de un modelo de seguridad.

Ofrece migración fuerte.

La plataforma solo está disponible para ambientes Unix/Linux.

En el sitio de ARA se publica como trabajo futuro, la posibilidad de hacer la plataforma

portable para sistemas operativos Windows.

SeMoA (Secure Mobile Agents)

Fue desarrollada en el año 1997 por un grupo de investigación del Instituto Fraunhofer

en Alemania. Tanto la plataforma como su código fuente pueden obtenerse gratuitamente en

el sitio http://www.semoa.org.


Desarrollada en lenguaje Java.



Su diseño se enfoca principalmente en todos los aspectos relacionados con la seguridad de

agentes móviles, contemplando la creación y especificación de políticas de seguridad en

forma flexible, detección de agentes maliciosos, protección de agentes contra hosts

maliciosos, etc.

Permite la administración y mantenimiento de la plataforma en forma flexible a través de

GUIs.

Provee un servicio de localización de agentes denominado ATLAS.

Soporta varios protocolos de comunicación de agentes, por ejemplo, FIPA ACL, KQML.

Permite la interoperatividad con otras plataformas (JADE, Aglets y Tracy), permitiendo la

ejecución de agentes implementados para estos entornos de ejecución.

En su sitio se encuentra documentación actualizada y muy completa. En la actualidad se

continúa agregando la implementación de nuevas características a la plataforma.

TACOMA (Tromso And COrnell Moving Agents)

Esta plataforma fue el resultado de un proyecto de investigación realizado en

conjunto en el año 1995 entre la Universidad de Tromso (Noruega) y la Universidad de

Cornell (EE UU). Las últimas actualizaciones se realizaron el 15/04/2002 y se pueden bajar

(fuentes y ejecutables) de su sitio http://www.tacoma.cs.uit.no/.


Implementada en lenguaje C. Permite la ejecución de agentes escritos en lenguaje C,

Tcl/Tk, Perl, Pyton y Scheme.

Desarrollada para ambientes Unix (HP-UX, Solaris, BSD Unix y Linux).

Utiliza TCP como protocolo de transporte.

No incluye mecanismos de seguridad.

Brinda migración débil.

Los desarrollos futuros incluyen transportar a la plataforma hacia otros sistemas

operativos, en particular, hacia ambientes Windows.

NOMADS

Fue desarrollada por un grupo de investigación perteneciente al IHMC (Institute for

Human and Machine Cogniti) de Florida U.S.A. La última actualización (release NOMADS



0.12) está publicada con fecha 28/09/2000 y se puede bajar en forma gratuita del sitio

http://www.ihmc.us:16080/research/projects/Nomads/.



Consiste en un entorno de ejecución denominado Oasis y una nueva implementación de la

JVM de Sun (compatible con ésta) llamada AromaVM, la cual permite capturar el estado

de ejecución de hilos (threads), así como también controlar los recursos consumidos por

éstos.

Brinda migración fuerte.

Apta para ejecutarse en sistemas operativos UNIX/LINUX, Windows NT 4.0 y Windows

2000. Los sistemas Windows 95/98 no son soportados.

Tracy

El proyecto Tracy fue desarrollado por un grupo de investigadores pertenecientes

principalmente a universidades de Alemania y Australia. Los binarios de la plataforma, así

como su documentación y ejemplos pueden descargarse en forma gratuita de su sitio

http://wiki.tracy.informatik.uni-jena.de/mobileagents/tiki-index.php. Los archivos de código

fuente no están disponibles. La última versión disponible es Tracy 1.0.1, publicada con fecha

21/04/2005.



Está implementada como un núcleo de software que provee los servicios básicos para

ejecutar agentes y controlar sus ciclos de vida. Además se pueden agregar “plugins”, éstos

son componentes de software que proveen un servicio que no es obligatorio para correr la

plataforma pero que extienden su funcionalidad.


Implementa comunicación asíncrona por medio de pasaje de mensajes y también permite

que los agentes se comuniquen mediante un modelo de pizarra.

Propone un modelo de migración propio denominado Kalong.

La plataforma se administra a través de una consola (shell) en modo texto. No provee

herramientas gráficas.



JADE (Java Agent DEvelopment Framework)

JADE es un middleware basado en la arquitectura de comunicación igual a igual

(peer-to-peer) que posibilita la implementación y ejecución de aplicaciones multiagentes. Es

un software libre desarrollado en el año 2000 por TILAB (Telecom Italia -

http://www.telecomitalialab.com, anteriormente conocido como CSELT) y cuyo código

fuente es distribuido bajo política Open Source LGPL. Su sitio es http://jade.cselt.it/.



Facilita el desarrollo de sistemas multiagentes brindando una plataforma de agentes

(entorno de ejecución) y un framework de desarrollo (librerías de clases).

Se adapta al estándar FIPA.

Provee un conjunto de herramientas gráficas, las cuales permiten la administración y

monitoreo de las actividades que los agentes realizan durante su ejecución.


Utiliza FIPA ACL como lenguaje de comunicación de agentes.

El modelo de comunicación se basa en pasaje asíncrono de mensajes. La plataforma elige,

en forma transparente para el usuario, el mecanismo de transporte de mensajes más

apropiado en base a la ubicación de los agentes que quieren comunicarse (eventos Java,

RMI, HTTP, IIOP, etc.).

Implementa dentro de la misma plataforma, la gestión de ontologías y la posibilidad de

que el usuario defina lenguajes de contenidos y ontologías propios.

Provee una librería con la implementación de protocolos de interacción listos para ser

usados.

La última versión de la plataforma, hasta el momento de confección de este

documento, es JADE 3.4 y está disponible desde marzo del 2006.

JADE permite además la utilización de “agregados” (en inglés, add-ons), los cuales

son piezas de software adicionales que, si bien no son requeridas para correr la plataforma,

permiten extender su funcionalidad agregando nuevas e interesantes características. Al igual

que JADE, se pueden descargar en forma gratuita desde su sitio. Algunos add-ons que se

pueden mencionar son:



Leap: se utiliza para el desarrollo de aplicaciones de agentes en dispositivos móviles.

Security: sirve para agregar características de seguridad a la plataforma.

Persistence: permite persistir los estados de los agente en bases de datos relacionales.

Migration: posibilita la migración de agentes entre distintas plataformas. Está disponible

a partir de la versión JADE 3.4.

6.2 Elección de la plataforma a utilizar

JADE es la plataforma elegida para la implementación del caso de aplicación

desarrollado en el presente trabajo. Las razones para su elección se basan fundamentalmente

en la facilidad de su utilización y la gran variedad de herramientas gráficas que brinda, con las

cuales se puede obtener una visión detallada de los eventos que están aconteciendo en la

plataforma. Además, el hecho de tener acceso a su código fuente, permite aclarar las posibles

dudas que puedan surgir sobre su funcionamiento y, debido a que está desarrollada en

lenguaje Java, se pueden aprovechar las ventajas de portabilidad que brinda el lenguaje.

Otros aspectos decisivos para la elección de JADE son: su ajuste al estándar FIPA,

lo que permitiría la interoperabilidad con otras plataformas, y la gran disponibilidad de

información y ejemplos, los cuales facilitan su comprensión. La plataforma cuenta con un

sitio web desde el cual se puede obtener toda su documentación, archivos con código fuente y

binarios. Brinda una activa lista de mails ([email protected]) a la cual se pueden

enviar mensajes con consultas, que son respondidas por los mismos desarrolladores de JADE.

Otra característica a destacar es que la plataforma ha estado en continuo desarrollo desde sus

comienzos hasta la actualidad.

6.3 Descripción de la plataforma elegida: JADE

6.3.1 Arquitectura de la plataforma

La arquitectura de la plataforma JADE se ajusta perfectamente a lo que especifica el

estándar FIPA1. Brinda una serie de servicios, de acuerdo con el estándar mencionado, que

abordan todos los aspectos que no forman parte del agente en sí y que son independientes de

la aplicación, como son: servicio de nombres (identificador global único de agente, páginas 1 Ver capítulo 3, sección 3.4.



blancas y páginas amarillas), servicios de codificación, decodificación y transporte de

mensajes y una biblioteca de protocolos de interacción lista para ser usada.

Una plataforma JADE puede estar distribuida en diferentes hosts. En cada uno de

ellos debe haber una JVM. Cada instancia del entorno de ejecución se llama contenedor y

puede albergar diferentes agentes. El conjunto de contenedores activos forman una

plataforma. En cada plataforma debe haber siempre activo un solo contenedor principal, éste

debe ser el primero en ejecutarse y los demás contenedores deben registrarse con él al

comenzar su ejecución. En cada contenedor principal se crean dos agentes especiales según

especifica el estándar FIPA: el AMS (Agent Management System) y el DF (Directory

Facilitator). Estos agentes se inician automáticamente al levantarse la plataforma. En el host

donde reside el contenedor principal, también se lanza el registro de RMI, que es usado

internamente por JADE. A cada plataforma se le asigna un identificador por defecto con la

siguiente estructura:

<nombre_host>:<puerto>/JADE

donde:

- nombre_host: dirección IP (o nombre DNS) del host en el cual está corriendo la

plataforma (es decir, en donde está el contenedor principal).

- puerto: puerto donde se levanta el registro de RMI, por defecto 1099.

Ejemplos de identificadores de plataformas pueden ser: pc:2000/JADE o

200.1.1.23:1099/JADE. Además, JADE permite cambiar ese identificador y utilizar un

nombre simbólico para la plataforma, éste se puede especificar por línea de comandos al

iniciar la plataforma.

En la figura 6.1 se muestra cómo se distribuye una sola plataforma entre varios

hosts.

También puede darse el caso de que se active más de una plataforma. En la figura

6.2 se observa cómo se distribuyen dos plataformas JADE en una red. La plataforma 1 se

encuentra distribuida en tres hosts y la plataforma 2 está en uno solo. Cada contenedor alberga

diferentes agentes, identificados con A1, A2, etc. Dentro del contenedor principal de cada

plataforma se encuentran el AMS y el DF.



Figura 6.1: Una sola plataforma de agentes JADE distribuida entre varios hosts1

Figura 6.2: Dos plataformas JADE distribuidas en una red 2

1 Figura adaptada de JADE Programmer’s Guide (2005: 8). 2 Figura adaptada de JADE Programming for Beginners (2003: 2).

Contenedor 1 Contenedor 2

Contenedor principal

Contenedor principal

RED

A4 A2 A3

A1

AMS DF

A1

AMS DF

PLATAFORMA 2

PLATAFORMA 1

Se registra con

Se registra con

HOST 1 HOST 2 HOST 3

Pila de protocolos de red

JVM JVM JVM

Plataforma JADE distribuida

Contenedor principal Contenedor JADE Contenedor JADE

Agente

Agente

Agente

Agente

Agente

Agente

Agente

Agente

Agente

RMI Registry



6.3.2 Modelo de comunicación

El modelo de comunicación que utiliza JADE es pasaje asíncrono de mensajes

(figura 6.3). La plataforma crea y gestiona una única cola de mensajes privada para cada

agente. En ella deposita los mensajes que le fueron enviados por otros agentes. Cada vez que

se coloca un mensaje en la cola, el agente receptor es avisado. Éste decide en que momento

extraer los mensajes.

Figura 6.3: Modelo de pasaje asíncrono de mensajes de JADE 1

JADE considera todos los componentes del modelo de comunicación2, empleando

como lenguaje de comunicación de agentes FIPA ACL y como lenguaje de contenido SL

(Semantic Language). También implementa dentro de la misma plataforma, la gestión de

ontologías de agentes y la posibilidad de que el usuario defina lenguajes de contenidos y

ontologías propios. Además, provee una librería con la mayoría de los protocolos de

interacción definidos por FIPA y su comportamiento puede ser heredado por medio de

métodos específicos.

Servicio de transporte de mensajes

Para explicar cómo funciona el servicio de trasporte de mensajes en JADE se hará la

distinción entre comunicación intra-plataforma y comunicación inter-plataforma.

1 Figura adaptada de JADE Programming for Beginners (2003: 11). 2 Ver capítulo 5, sección 5.4.

Entorno de ejecución JADE

A1 A2

Prepara el mensaje para A2

Envía el mensaje Deja el mensaje en la cola de mensajes de A2

Obtiene el mensaje de su cola y lo procesa



La comunicación intra-plataforma se lleva a cabo cuando agentes ubicados en la

misma plataforma quieren intercambiar mensajes. Para implementar el servicio de entrega,

JADE utiliza sus propios protocolos internos de transporte de mensajes (IMTPs) eligiendo el

mecanismo de transporte de mensajes más apropiado en base a la ubicación de los agentes que

quieren comunicarse, de manera de minimizar el tiempo de entrega. De acuerdo a esto se

recurre a:

Notificación de eventos: cuando el agente emisor y el agente receptor están ubicados en

el mismo contenedor. En este caso no hace falta que el mensaje sea serializado,

simplemente se clona y la referencia al nuevo objeto se pasa al receptor.

RMI: cuando los agentes residen en diferentes contenedores.

La comunicación inter-plataforma se produce cuando agentes localizados en

distintas plataformas quieren comunicarse. En este caso, la interacción se ejecuta a través del

canal de comunicación de agentes (ACC), el cual está distribuido físicamente entre todos los

contenedores de la plataforma. Cada contenedor puede ser lanzado con uno o más protocolos

de transporte de mensajes (MTPs) y la plataforma es capaz de rutear internamente los

mensajes, seleccionando el mejor MTP para cada situación. Los MTPs también se pueden

activar o desactivar para fines específicos en tiempo de ejecución, como por ejemplo, para

deshabilitar temporalmente un puerto. Los siguientes MTPs están disponibles en JADE:

IIOP MTP basado en el estándar Sun ORB provisto con la JDK.

CORBA IIOP MTP basado en ORBACUS.

MTP basado en el protocolo HTTP.

JADE proporciona, además, dos interfaces que brindan la posibilidad de

implementar nuevos protocolos IMTP o MTP. Por ejemplo, un protocolo alternativo IMTP se

integró al add-on LEAP, mencionado anteriormente en el capítulo. Este nuevo protocolo se

encarga de la comunicación entre contenedores de la misma plataforma, para ambientes

inalámbricos, donde RMI no está disponible.

En la figura 6.4 se muestra la arquitectura del servicio de transporte de mensajes en

JADE, haciendo la distinción entre los protocolos IMTP (dentro de la plataforma) y MTP

(hacia fuera de la plataforma). Esta plataforma brinda un servicio de comunicación

transparente de la ubicación basándose en la técnica de servidor central1 optimizada con el

1 Ver capítulo 5, sección 5.3.1



uso de caché. En cada contenedor existe un caché donde se guardan las referencias a agentes

que residen en otros contenedores. Estas referencias sirven para mapear un GUID1

(identificador global único) en una dirección física y se agregan al caché cada vez que se

envía un mensaje. El contenedor principal, que actúa como servidor central, es el único que

tiene la asociación completa GUID-dirección física para la plataforma entera, y es contactado

por los otros contenedores solamente en caso de falta de caché. Esto sólo sucede la primera

vez que se envía un mensaje a un agente en un contenedor diferente. Con la utilización de este

mecanismo se evita que el contenedor principal se convierta en un “cuello de botella” por

intervenir en toda la comunicación que se realiza en la plataforma.

Figura 6.4: Arquitectura del Servicio de Transporte de Mensajes en JADE 2

6.3.3 Características de un agente JADE

Un agente JADE es autónomo, ya que se implementa como un hilo de ejecución

independiente y decide por sí mismo cuándo leer los mensajes y qué mensajes leer. Puede

entablar varias conversaciones simultáneas y ejecutar varias tareas concurrentes.

Cada agente posee un identificador global único (GUID) (de acuerdo con las

especificaciones FIPA). Éste es una referencia lógica, independiente de la ubicación del

agente, que se usa en los mensajes ACL y es traducido por la plataforma en una dirección

1 Se detallará en la siguiente sección. 2 Figura adaptada de Scalability and Performance of JADE Message Transport System.

AGENTES LOCALES

IMTP

Plataforma (Impl.)

ACC

AGENTES GLOBALES

MTP

Contenedor principal JADE

AMS DF

AGENTES LOCALES

IMTP

Plataforma (Proxy)

CACHE

Contenedor JADE

RMI

ACC

MTP

Agente 2

Agente 1

IIOP HTTP



física; todo esto se realiza de manera transparente para el programador. En JADE este

identificador está representado por la clase jade.core.AID y está compuesto por:

Un nombre global único: por defecto este nombre tiene la estructura:

<nombre>@<id_plataforma>

donde: - nombre: nombre del agente (dado por el programador o desde línea de comandos al lanzar

el agente) en su plataforma origen (donde se creó el agente). Dentro de una plataforma

puede existir un solo agente con este nombre.

- id_plataforma: identificador de la plataforma origen del agente1.

Un nombre de agente válido podría ser, por ejemplo, agente1@pc:1099/JADE.

Un conjunto de direcciones de agente: cada agente hereda las direcciones de transporte de

su plataforma origen.

Un conjunto de traductores (en inglés, resolvers): son agentes que proveen el servicio de

páginas de blancas con el cual el agente está registrado (AMS).

Dentro de JADE un agente se implementa como una clase Java llamada Agent

(ubicada dentro del paquete jade.core) que actúa como una superclase para la creación de

agentes definidos por el programador. De este modo, el agente creado, hereda todas las

capacidades de la clase Agent, tales como mecanismos básicos de interacción con la

plataforma de agentes (registro, configuración, gerenciamiento remoto, etc). Además, a este

agente se le pueden incorporar, a través de un conjunto básico de métodos, comportamientos

(behaviours) específicos de acuerdo con las necesidades y objetivos de la aplicación.

En la figura 6.5 se ilustra la arquitectura interna de un agente JADE genérico. En la

parte superior se encuentran los comportamientos activos del agente, que representarían sus

intenciones o tareas. Cada servicio que el agente provee debe ser implementado como uno o

más comportamientos, éstos pueden ser ejecutados en forma concurrente. Se observa que

JADE permite una variedad de comportamientos en un mismo agente. En la parte inferior

izquierda de la figura se representa la cola privada de mensajes del agente, éste accede a la

misma a través de una combinación de diferentes modos (blocking, polling, timeout y pattern

matching). En el centro del dibujo se ubican: el planificador de comportamientos, el cual es

responsable del orden en que se ejecutarán los mismos, y el administrador del ciclo de vida,

1 Ver sección 6.3.1.



encargado de controlar el estado actual del agente. Finalmente, en la parte derecha de la figura

se encuentran los recursos del agente dependientes de la aplicación. En ese lugar serán

almacenadas, por ejemplo, las creencias y habilidades que el agente vaya adquiriendo durante

la ejecución de la aplicación.

Figura 6.5: Arquitectura interna de un agente JADE

Ciclo de vida

Un agente puede estar en uno de varios estados de acuerdo con el ciclo de vida

especificado por el estándar FIPA1.

En JADE, estos estados se representan como constantes estáticas definidas en la

clase AMSAgentDescription (paquete jade.domain.FIPAAgentManagement). La clase

Agent proporciona métodos públicos que permiten realizar las transiciones entre estados. Por

ejemplo, el método doWait() coloca en estado esperando a un agente que se encuentra en

estado activo, el método doSuspend() pasa al agente desde el estado activo a estado

suspendido, el método doActivate() realiza la transición contraria al método anterior, etc.

Creación

Al crearse un agente, JADE realiza varias acciones automáticamente:

Se llama a su constructor. 1 Ver capítulo 4, sección 4.3

Pattern matching

Blocking

Polling

Timeout

Modos de

acceso

Cola privada de mensajes ACL

Recursos dependientes

de la aplicación

Creencias

Habilidades

Planificador de

comportamientos

Comportamientos activos del agente (intenciones o tareas)

Comportamiento 1

Comportamiento 2

Comportamiento n

…

Administrador del ciclo de vida



Se le crea un identificador global único (GUID).

Se lo registra en el AMS y se lo coloca en estado activo.

Se ejecuta su método setup(). Este método se hereda de la clase Agent, la cual provee

una implementación vacía del mismo. El programador puede sobrescribirlo para otorgar al

agente la funcionalidad que desee.

Finalización

Para detener la ejecución de un agente se debe llamar al método doDelete() de la

clase Agent. La invocación de este método provoca que el agente pase a estado eliminado.

Antes de que esto ocurra se invoca al método takeDown() también de la clase Agent, el cual

puede sobrescribirse para incluir, por ejemplo, tareas de limpieza que deseen realizarse antes

de eliminar al agente.

Envío y recepción de mensajes

Para enviar un mensaje el agente debe crear una instancia de la clase ACLMessage

(contenida en el paquete jade.lang.acl), llenar sus atributos con los valores apropiados y,

finalmente, invocar al método send() de la clase Agent. Para recibir un mensaje, el agente

puede usar los métodos receive()o blockingReceive()también de la clase Agent. Con el

primero, el agente accede a su cola de mensajes sin que se bloquee su ejecución; por el

contrario, con el segundo método el agente se bloquea (se detiene la ejecución de todos sus

comportamientos) esperando la llegada del mensaje requerido.

Como se mencionó en la sección 6.3.2, JADE utiliza el lenguaje de comunicación de

agentes FIPA ACL. Los actos comunicativos definidos por este lenguaje se encuentran

definidos como constantes (REQUEST, INFORM, etc.) en la clase ACLMessage. Cuando se

crea un nuevo mensaje, una de estas constantes debe pasarse como argumento al constructor

de la clase ACLMessage. Esta clase contiene también el método createReply(), que facilita

la elaboración de un mensaje en respuesta a uno recibido. Establece apropiadamente ciertos

atributos del mensaje, como por ejemplo el destinatario y el identificador de la conversación,

dejando que el programador especifique el acto comunicativo y el contenido del mensaje.



6.3.4 Comportamientos

La programación de un agente consiste en definir las tareas que necesita ejecutar.

Cada tarea del agente es una instancia de la clase Behaviours, provista en el paquete

jade.core.behaviours.

En JADE, vienen implementados, dentro del paquete mencionado anteriormente,

diferentes comportamientos listos para ser usados, entre ellos:

Behaviour: comportamiento genérico.

OneShotBehaviour: comportamiento que se ejecuta sólo una vez y de forma

ininterrumpida.

CyclicBehaviour: comportamiento que está siempre ejecutándose. Debe utilizarse

cuidadosamente ya que puede monopolizar el uso de CPU.

TickerBehaviour: comportamiento que se ejecuta periódicamente cada cierto tiempo

dado.

Los comportamientos además se pueden componer y formar comportamientos más

complejos.

La clase Agent posee dos métodos para agregar y eliminar un comportamiento a un

agente: addBehaviour(…) y removeBehaviour(…), respectivamente. Los comportamientos

pueden agregarse o eliminarse en cualquier momento de la vida de un agente; se pueden

agregar en el método setup() o desde cualquier comportamiento, incluso desde otros

agentes.

Un agente sólo puede ejecutar sus comportamientos estando en estado activo, si en

cualquiera de sus comportamientos se invoca al método doWait(), el agente completo y todas

sus actividades se bloquean, no sólo el comportamiento que lo invocó.

El planificador de comportamientos de un agente, mencionado en la sección

anterior, trabaja de modo no apropiativo, es decir que cuando se ejecuta un comportamiento

no puede interrumpirse hasta que termine. Una vez que un comportamiento se selecciona para

su ejecución se invoca su método action() y se ejecuta hasta que devuelve el control, por lo

tanto se recomienda que este método no tenga un tiempo de ejecución alto.

Al finalizar el método action() se invoca al método done(), éste retorna un valor

booleano que indica que el comportamiento ha terminado.



6.3.5 Modelo de movilidad

Debido a que esta tesina se enfoca específicamente en los agentes de tipo móvil, se

detallará a continuación el soporte para movilidad de agentes que brinda la plataforma JADE.

Una característica de JADE es que permite construir agentes móviles que son

capaces de migrar o clonarse entre los contenedores disponibles en la plataforma. La

movilidad o la clonación se consideran como un estado de transición en el ciclo de vida de un

agente, y por lo tanto, al igual que el resto de operaciones dentro del ciclo de vida, pueden ser

iniciadas por el agente mismo o por el AMS. Además, JADE provee una biblioteca (ubicada

en el paquete jade.domain.mobility) que contiene la definición de ontologías para la

movilidad, un vocabulario con una lista de símbolos usados y todas las clases Java que

implementan esas ontologías.

En las primeras versiones de JADE los agentes sólo podían migrar dentro de la

misma plataforma (intra-plataforma). A partir de la versión Jade 3.4 y con la incorporación

del add-on migration ya mencionado, también se permite que los agentes migren entre

plataformas distintas (inter-plataforma). A continuación se explicará como se efectúa la

migración en ambos casos.

Migración intra-plataforma

Existen dos métodos públicos en la clase Agent, doMove() y doClone(), que

permiten que un agente migre o se copie con un nombre diferente (clonarse) en el contenedor

al que desea migrar.

El método doMove() tiene como único parámetro el destino hacia el cual el agente

desea migrar. Éste se representa por una instancia de jade.core.ContainerID, clase que

implementa la interface jade.core.Location y que identifica un contenedor dentro de la

plataforma. Un contenedor se identifica por la concatenación de su nombre, el símbolo “@” y

su dirección de transporte (la dirección de transporte del host donde se encuentra el

contenedor). Los nombres de contenedores deben ser únicos dentro de una plataforma.

El método doClone() también toma como parámetro el destino en donde el agente

desea clonarse, pero además se agrega una cadena que contiene el nombre con el que será

creado el nuevo agente, es decir, el clon.

La interface Location es abstracta, por lo tanto, no se les permite a los agentes de

la aplicación crear sus propias direcciones. En lugar de esto, deben pedir al AMS la lista de



direcciones disponibles y elegir una. Alternativamente, un agente JADE también puede

solicitar al AMS que le diga dónde (en qué contenedor) vive otro agente.

Durante el proceso de migración del agente, se llama al método beforeMove()en el

origen (lugar desde el cual el agente quiere migrar) cuando la operación de migración ha

terminado con éxito, es decir, cuando la instancia del agente móvil en el contenedor destino

está a punto de ser activada y la instancia original del agente está a punto de ser detenida. Por

lo tanto, este método es el lugar apropiado para liberar cualquier recurso local usado por la

instancia original del agente (por ejemplo, cerrar cualquier archivo o interfaz gráfica abiertos).

Además, si estos recursos fueron cerrados de antemano pero la migración falla, se deben abrir

nuevamente. Como una consecuencia inmediata de lo explicado se nota que cualquier

información que el agente deba transportar al nuevo destino tiene que ser seteada antes de

llamar al método doMove(). Por ejemplo, si se modifica un atributo del agente en el método

beforeMove() no tendrá ningún impacto en la instancia del agente en el destino. El método

afterMove() se llama en el contenedor destino, en el momento en que el agente llega y se le

comunica su identidad (pero antes de que el planificador de comportamientos sea reiniciado).

Para la clonación del agente, JADE facilita un par de métodos que actúan de manera

similar a los anteriores, estos métodos son beforeClone() y afterClone().

Los cuatro métodos mencionados arriba están definidos en la clase Agent y se

implementan vacíos. Si el programador lo necesita, puede sobrescribir estos métodos

proporcionando la implementación deseada.

Migración inter-plataforma

Como se mencionó, la migración inter-plataforma se realiza a través del add-on

migration. Este servicio permite la migración de agentes desde una plataforma a otra

transportándolos dentro de mensajes FIPA ACL. Los mensajes son intercambiados por los

AMSs de las plataformas involucradas siguiendo las reglas impuestas por alguno de los

protocolos de interacción FIPA. El mensaje ACL se construye en la plataforma origen

siguiendo una ontología especial, de manera tal que la plataforma destino pueda usar esa

información para restaurar la ejecución del agente e informar a la plataforma origen si la

migración se realizó con éxito o no. Una ventaja de utilizar mensajes ACL para transportar

agentes de una plataforma a otra es que no se necesita usar un canal de comunicación extra

entre plataformas.



El modo en que un agente especifica que desea migrar a otra plataforma es similar al

de la migración intra-plataforma. Se debe invocar al método doMove(), pero colocando como

parámetro una instancia de jade.core.PlatformID, clase que implementa la interface

jade.core.Location, al igual que la clase ContainerID utilizada para la migración intra-

plataforma. El constructor de la clase PlatformID, recibe como argumento el identificador

global único del agente AMS de la plataforma a la cual se desea migrar (instancia de la clase

jade.core.AID).

La versión disponible de este servicio de movilidad inter-plataforma (1.0) es muy

simple. En la documentación aparecen como características a implementar en versiones

futuras, el agregado de mecanismos de seguridad y control de acceso y la posibilidad de

brindar más estrategias de migración. La estrategia disponible actualmente se tratará a

continuación.

Estrategias de migración

En el capítulo 4 se precisó que la estrategia de migración se refiere al tipo de

traslado de código que se usa para la migración del agente y se hizo la distinción entre

estrategias de tipo push y estrategias de tipo pull1.

JADE utiliza distintas estrategias de migración según la movilidad se realice intra-

plataforma o inter-plataforma. En el primer caso, se utiliza una estrategia de tipo pull. Cuando

el agente migra, únicamente sus datos son enviados desde el contenedor origen al destino; los

archivos de código del agente son transferidos bajo demanda cuando éste los necesita. En el

segundo caso, cuando la migración se realiza entre plataformas, la estrategia proporcionada es

de tipo push. Cuando el agente migra se transmiten al destino todos los datos y el código

necesario para que se pueda ejecutar.

Migración de datos

La plataforma JADE aprovecha la técnica de serialización de objetos estándar

proporcionada por el lenguaje Java. Todos los datos que deban migrar con el agente deberán

ser serializables. Por otro lado, si se quiere que algún dato no se envíe, debe ser marcado

como transient.




Tipo de movilidad

Debido a que JADE está basada en el lenguaje Java, el tipo de migración que ofrece

es débil.

6.3.6 Requerimientos de software

El único requerimiento de software para ejecutar la plataforma JADE es tener

disponible el ambiente runtime de Java versión 1.4 o superior. Además, si se desea utilizar

algún add-on adicional, se deben chequear sus requerimientos específicos. Por ejemplo, para

utilizar el add-on migration se necesita usar una versión del runtime Java 1.5.

6.3.7 Ejecución de la plataforma

Al descargar la plataforma del sitio de JADE se obtiene un archivo comprimido

(zip), al descomprimirlo se genera un árbol de directorios cuya raíz es la carpeta jade. Dentro

de esta última existe un subdirectorio lib que contiene los archivos JAR que deberán ser

seteados en la variable de ambiente CLASSPATH. Una vez que dicha variable está

correctamente seteada, se debe utilizar el siguiente comando para lanzar el contenedor

principal de la plataforma: java jade.Boot [opciones]

Existen múltiples opciones que se pueden especificar por línea de comandos al

iniciar la plataforma, por ejemplo: –name permite colocar un nombre a la plataforma, -port

permite especificar un puerto diferente al puerto por defecto. Una lista completa de estos

argumentos se puede obtener del documento administratorsguide.pdf disponible en el sitio de

JADE.

Un nuevo contenedor se puede lanzar de la siguiente manera:

java jade.Boot –container [opciones]

También se pueden lanzar agentes desde línea de comandos, especificando:

java jade.Boot –container [opciones] [lista_de_agentes]

en donde: lista_de_agentes = Nombre_agente ":" Nombre_clase ("(" Lista_argumentos ")")



Por ejemplo, especificar Agente1:MiClaseAgente(hola 555), crea el agente con

nombre Agente1, cuya implementación está dada por la clase java MiClaseAgente y al cual se

le pasa una lista con dos argumentos: la cadena “hola” y la cadena “555”.

6.3.8 Principales herramientas gráficas

JADE brinda una serie de herramientas gráficas que sirven para monitorear y

administrar agentes dentro de la plataforma. Cada herramienta está implementada como un

agente, por lo tanto, tiene las mismas capacidades (comunicación, ciclo de vida, etc.) que

cualquier otro agente dentro de la plataforma. Las clases que proveen esta funcionalidad están

incluidas dentro del paquete jade.tools.

RMA (Remote Monitoring Agent)

Es una consola gráfica para la administración y el control de la plataforma que

permite:

Monitorear y controlar todos los contenedores (locales y remotos) que componen la

plataforma.

Administrar el ciclo de vida de agentes (crear, matar, migrar, clonar, suspender, restaurar

agentes).

Crear y enviar un mensaje a un agente determinado.

Lanzar las demás herramientas gráficas.

Supervisar plataformas remotas que cumplen con el estándar FIPA (solo operaciones de

lectura).

Este agente se puede lanzar desde la línea de comandos con java jade.Boot –gui

o como cualquier otro agente con jade.Boot myrma:jade.tools.rma.rma.

En la figura 6.6 se muestra la interfaz del RMA, las plataformas aparecen denotadas

con un ícono de carpetas amarillas, los contenedores como carpetas verdes y dentro de los

contenedores se muestran los agentes.

DummyAgent

Esta herramienta brinda la posibilidad de inspeccionar los mensajes que son

intercambiados entre agentes. Permite editar, construir y enviar mensajes ACL a agentes, así

como también mantener una lista de todos los mensajes enviados y recibidos. Esta lista puede



ser examinada por el usuario, pudiendo mirar cada mensaje en detalle. La lista de mensajes se

puede guardar en disco para ser recuperada más tarde.

El DummyAgent se puede lanzar desde la interfaz del RMA (menú Tools) o desde la

línea de comandos: java jade.Boot theDummy:jade.tools.DummyAgent.DummyAgent.

Una pantalla a modo de ejemplo se puede observar en la figura 6.7.

Figura 6.6: Interfaz del RMA 1

DF (Directory Facilitator) GUI

Es una utilidad que permite al usuario interactuar con el agente DF y posibilita:

Registrar y desregistrar agentes.

Ver las descripciones de agentes registrados.

Modificar la descripción de agentes registrados.

Buscar agentes que brindan un determinado servicio.

Federar el DF con instancias de otros DFs y crear una red de dominios y subdominios de

páginas amarillas. 1 Figura tomada de JADE administrator’s guide (2005: 26)



Esta herramienta puede ser lanzada desde la interfaz del RMA accediendo al menú

Tools. Internamente, esta acción provoca que se envíe un mensaje ACL al agente DF (que se

inicia automáticamente al levantar la plataforma) pidiéndole que muestre su GUI. Por lo tanto,

la interfaz del DF se puede mostrar solamente en el host donde se inició la plataforma (donde

se localiza el contenedor principal). En la figura 6.8 se muestra la interfaz desplegada.

Figura 6.7: Interfaz del DummyAgent 1

Sniffer Agent

El “sniffer”, es un agente que tiene la característica de “husmear”, es decir, de

mostrar los mensajes que se intercambian en la plataforma JADE. El usuario puede decidir

qué agente o grupo de agentes observar. El agente sniffer sigue la pista de cada mensaje

dirigido hacia/desde cualquier agente y muestra en su interfaz todo el intercambio realizado.

1 Figura tomada de JADE administrator’s guide (2005: 30)



Los mensajes se pueden visualizar o almacenar en un medio persistente para recuperarlos

posteriormente.

Esta utilidad se puede lanzar directamente desde la interfaz del RMA (menú Tools)

o desde línea de comandos con: java jade.Boot sniffer:jade.tools.sniffer.Sniffer.

En la figura 6.9 se muestra un ejemplo de su interfaz.

Figura 6.8: Interfaz del Directory Facilitator 1

Introspector Agent

Esta herramienta permite supervisar y controlar el ciclo de vida de un agente y los

mensajes que intercambia, así como también la cola de mensajes enviados y recibidos por el

mismo. Además posibilita monitorear su cola de comportamientos.




Se puede iniciar desde el RMA (menú Tools) o desde línea de comandos con: java

jade.Boot introspector:jade.tools.introspector.Introspector.

Una pantalla de ejemplo de la interfaz del agente introspector se muestra en la figura

6.10.

Figura 6.9: Interfaz del Sniffer Agent 1

6.3.9 Ventajas de la utilización de JADE

Según Bellifemine (2003), JADE es un middleware que facilita el desarrollo de

aplicaciones. Varias empresas ya lo están utilizando en diferentes dominios de aplicación

como la administración de flotas, subastas, turismo, etc. A continuación se describen las

ventajas que ofrece JADE para el desarrollo de aplicaciones:

Aplicaciones distribuidas compuestas de entidades autónomas: JADE simplifica el

desarrollo de aplicaciones distribuidas compuestas de entidades autónomas que necesitan

comunicarse y colaborar para lograr el funcionamiento del sistema completo. Para ello

ofrece un framework que esconde toda la complejidad de la arquitectura distribuida, de




forma tal que los desarrolladores de aplicaciones, se puedan concentrar solo en la lógica

de la aplicación en lugar de prestar atención a los problemas del middleware, como

descubrir y contactar las entidades del sistema.

Figura 6.10: Interfaz del Introspector Agent 1

Negociación y coordinación: JADE simplifica el desarrollo de aplicaciones que

requieren negociación y coordinación entre un conjunto de agentes que viven en un

ambiente en donde los recursos y la lógica del mando están distribuidos. La plataforma

brinda un conjunto de librerías de software fáciles de usar por los desarrolladores de

aplicaciones que permiten por un lado, la comunicación de igual a igual (peer-to-peer)

entre las entidades autónomas y por otro lado, posibilita la utilización de protocolos de

interacción (por ejemplo, ofrece la implementación de patrones de interacción entre las

entidades).

Proactividad: los agentes JADE controlan sus propios hilos de ejecución y, en

consecuencia, ellos pueden programarse para comenzar la ejecución de acciones sin la




intervención humana basándose en objetivos y cambios de estado. Esta característica,

denominada proactividad1, hace de JADE un ambiente adecuado para la realización de

aplicaciones en tiempo real, por ejemplo, para la automatización de una planta industrial,

control de tráfico y administración de redes de comunicación.

Aplicaciones multipartidarias: las arquitecturas de igual a igual son más eficientes que

las arquitecturas cliente-servidor para desarrollar aplicaciones multipartidarias, ya que el

servidor puede ocasionar un cuello de botella y hacer fracasar al sistema entero. La

característica de los agentes JADE de proporcionar y consumir servicios, quita cualquier

necesidad de distinguir entre cliente y servidor. Los agentes JADE permiten a los clientes

comunicarse entre sí sin la intervención de un servidor central. Además, el hecho de que la

inteligencia, la información y el control están distribuidos, permite la realización de

aplicaciones en donde el dominio está distribuido entre todos los agentes, dado que cada

agente es capaz, y está autorizado a realizar, sólo un subconjunto de las acciones de la

aplicación.

Interoperabilidad: JADE cumple con las especificaciones de FIPA que habilitan la

interoperabilidad extremo a extremo (end-to-end) entre agentes de diferentes plataformas.

Sistema abierto: JADE es un proyecto Open Source que abarca las contribuciones y

colaboraciones de la comunidad de usuarios. Esto permite a usuarios y desarrolladores de

la plataforma contribuir con sugerencias y nuevos códigos que garantizan la apertura y

utilidad de las APIs. Para evitar el desorden, la mesa directiva de JADE controla

formalmente su evolución en todo lo que se refiere a incorporación de nuevas APIs y

funcionalidades.

Versatilidad: JADE proporciona un conjunto homogéneo de APIs que son

independientes de la red subyacente y la versión de Java utilizada. Mantiene las mismas

APIs para los ambientes J2EE, J2SE y J2ME. Esta característica permite a los

desarrolladores reutilizar el mismo código de la aplicación para una PC, un PDA o un

teléfono móvil con Java.

Aplicaciones sencillas de usar y mover: las APIs de JADE son fáciles de aprender a

utilizar. La plataforma se diseñó para simplificar el manejo de comunicación y transporte

de mensajes haciendo transparente para el desarrollador la administración de las capas de




comunicación usadas para enviar un mensaje de un agente a otro. Mediante esta

característica, JADE reduce el tiempo de desarrollo de la aplicación con respecto al

tiempo necesario para desarrollar la misma aplicación usando sólo las librerías normales

de Java.


Capítulo 7 Caso de aplicación

En este capítulo se presenta el desarrollo de una aplicación basada en agentes

móviles, con el fin de plasmar en un caso práctico los conceptos teóricos tratados en los

capítulos anteriores. Se pretende proponer la utilización de una metodología de análisis y

diseño de sistemas multiagentes que resulte clara y sencilla de aplicar para los programadores

que no tengan experiencia en este tipo de desarrollos.

En primer lugar se describe en forma general la aplicación desarrollada, luego se

presenta la metodología seguida y, finalmente, se exponen los resultados obtenidos en las

fases de análisis y diseño de la aplicación. Estos resultados incluyen la identificación de los

tipos de agentes presentes en el sistema, sus responsabilidades y las interacciones entre los

agentes y los recursos externos y entre los agentes y sus pares.

7.1 Presentación de la aplicación

Como se mencionó en el capítulo 2, uno de los principales dominios de aplicación

de los agentes móviles es el de recuperación de información. Se elige este dominio para el

desarrollo del caso práctico con el fin de poder probar y mostrar las características más

representativas de este tipo de agentes. Se plantea, entonces, un escenario de naturaleza

distribuida en el cual los agentes móviles constituyen una solución apropiada, flexible y

eficiente, y que además permite efectuar las pruebas correspondientes con los recursos

disponibles individuales y en el entorno académico.

El escenario consiste en una empresa o institución que cuenta con una red de área

local mediante la cual los usuarios necesitan compartir documentos de distinto tipo que se

encuentran distribuidos. En este contexto, el principal objetivo de la aplicación es permitir la

búsqueda de documentos heterogéneos distribuidos en una red de área local, a partir de la

especificación de un patrón de texto. Se desea explotar las características de los agentes



móviles a fin de optimizar el rendimiento de las búsquedas y de brindar servicios adicionales

según las preferencias del usuario.

La aplicación tendrá una interfaz gráfica que permitirá al usuario ingresar la palabra

o frase a buscar y en la cual se mostrarán los resultados obtenidos. Los resultados consistirán

en una lista de URLs pertenecientes a los documentos en los que se encontró el patrón. El

usuario también podrá especificar como parámetro de búsqueda una fecha mínima de última

modificación o una relevancia mínima, que es un porcentaje relacionado con la cantidad de

apariciones del patrón en el documento.

La aplicación ofrecerá la posibilidad de abrir los documentos siempre que el usuario

cuente con los permisos requeridos y que se encuentre instalado el programa asociado al tipo

de documento.

El usuario podrá suscribirse para ser notificado cuando se modifiquen documentos

referentes a la búsqueda realizada o aparezcan nuevos. En caso de estar suscripto, si el usuario

sale de la aplicación e incluso se desconecta de la red, recibirá las novedades al ingresar

nuevamente.

Este caso práctico permite reflejar, entre otras, las siguientes características del

paradigma de agentes móviles:

Movilidad: dado que en el problema planteado las fuentes de información no están

centralizadas, la utilización de agentes móviles para realizar las búsquedas constituye una

solución natural, ya que los agentes pueden viajar de una máquina a otra buscando en

forma local los documentos requeridos, aplicar los filtros necesarios y luego enviar los

resultados al usuario que los solicitó. Además, es una solución escalable, ya que la

incorporación de una nueva máquina a la red simplemente implicará para los agentes una

máquina más a visitar.

Autonomía: cada agente encargado de efectuar una búsqueda realizará su propio

recorrido y decidirá en qué momento debe dar por finalizada la búsqueda.

Reactividad: el sistema debe reaccionar ante un destino inalcanzable y también detectar

cuando se conectan o desconectan máquinas en la red, a fin de agregarlas o eliminarlas de

los recorridos de búsqueda. Por otra parte, debe ser capaz de detectar cambios o

incorporación de nuevos documentos que tengan relación con las suscripciones de los

usuarios para recibir novedades.



Proactividad: el sistema debe ser capaz de notificar sobre novedades pendientes a un

usuario que se conecta nuevamente a la red, sin esperar que éste tome la iniciativa.

Además, el sistema debe detectar la muerte de un agente que está realizando una

búsqueda, a fin de reemplazarlo automáticamente y completar la tarea en las máquinas

restantes, en forma transparente para el usuario.

Cómputo asíncrono: el sistema debe recolectar las novedades referidas a una suscripción

y conservar los mensajes en caso de que el usuario no esté conectado para recibirlas, a fin

de entregárselos cuando se conecte nuevamente.

Comportamiento social: para lograr un mejor desempeño, las distintas tareas a llevar a

cabo serán realizadas por distintos tipos de agentes, los cuales deberán comunicarse y

cooperar para cumplir con los requerimientos en forma conjunta.

7.2 Metodologías para el desarrollo de sistemas multiagentes

Existen varias metodologías para el desarrollo de sistemas multiagentes. Casi todas

ellas adaptan un modelo orientado a objetos, generalmente el Proceso Unificado, definiendo

algunas actividades específicas para tratar las características particulares de los agentes (ANA

MAS, 2005: 148).

Las metodologías para el análisis y diseño de sistemas basados en agentes se pueden

dividir en dos grupos: las que están basadas en el desarrollo orientado a objetos y las que

adaptan técnicas de ingeniería del conocimiento, aprovechándolas para modelar

características cognitivas de los agentes (Wooldridge, 2005: 226). A modo de ejemplo se

pueden citar, dentro del primer grupo, las siguientes metodologías:

AAII/BDI: está basada en el modelo BDI (Creencias, Deseos, Intenciones) mencionado

en el capítulo 3. Provee un modelo externo, en el que se identifican los agentes y sus

interacciones, y un modelo interno, que describe el comportamiento de cada uno de los

agentes.

Gaia: considera un sistema basado en agentes como una sociedad u organización que

consta de una colección de roles, los cuales interactúan siguiendo determinados patrones.

Los agentes se definen como una agregación de roles.

MaSE: adopta el paradigma de orientación a objetos y considera los agentes como una

especialización de los objetos, que consiste en los aspectos de coordinación y



comportamiento proactivo de los agentes. Al igual que Gaia, parte de la identificación de

roles para la definición de las clases de agentes.

Message/Ingenias: Message integra varias metodologías y considera cinco puntos de

vista para el modelado de un sistema multiagente: agente, organización, entorno, tareas y

objetivos, interacciones. Los elementos que modelan el sistema se describen utilizando

meta-modelos. Una extensión de estos meta-modelos es la metodología Ingenias, la cual

cuenta con un conjunto de herramientas de soporte construido sobre dichos meta-modelos,

el Ingenias Development Kit.

Y dentro del segundo grupo:

MAS-CommonKADS: se basa en la metodología de desarrollo de sistemas de gestión del

conocimiento CommonKADS. Incorpora los aspectos de distribución e interacción de

agentes, que no están presentes en los sistemas expertos por ser de naturaleza centralizada.

No es objeto de la presente tesina estudiar las distintas metodologías. Se puede

encontrar más información al respecto en (ANA MAS, 2005), (Wooldridge, 2005), (Gómez

Sanz, 2003), (Giret-Insfrán-Pastor-Cernuzzi, 2000).

Algunos investigadores argumentan que la aproximación predominante, que consiste

en desarrollar metodologías para sistemas multiagentes adaptando las desarrolladas para

análisis y diseño orientado a objetos, tiene varias desventajas (Wooldridge, 2005: 232).

Principalmente, dado que los objetos y los agentes proveen abstracciones distintas, deben ser

tratados en diferentes niveles; además, hay ciertos aspectos de los agentes, como la

proactividad, la reactividad, la cooperación y la negociación, que no pueden ser representados

mediante modelos de objetos.

La metodología elegida para el desarrollo de la aplicación es el resultado de un

trabajo en conjunto entre integrantes de la Escuela de Ingeniería y Ciencias de la Universidad

de Murdoch en Australia y del laboratorio de Telecom en Italia. Brinda esencialmente una

guía para el análisis y diseño de sistemas multiagentes, dando la oportunidad de agregar o

quitar componentes según se desee de acuerdo con el dominio específico del problema. La

fase de análisis es más genérica, mientras que la fase de diseño se enfoca específicamente en

las construcciones provistas por la plataforma JADE. Las fases de análisis de requerimientos e

implementación y pruebas, no están formalizadas en esta metodología, sin embargo ofrece

algunas recomendaciones a tomar en cuenta.



Esta metodología no procura ampliar o extender las técnicas orientadas a objetos, en

vez de esto, se enfoca específicamente en los agentes y en las abstracciones proporcionadas

por el paradigma de agentes. Además, combina una aproximación top-down y bottom-up para

poder integrar el sistema multiagente con las capacidades de los sistemas ya existentes

(sistemas heredados).

Cabe aclarar que, si bien se ha tomado como guía esta metodología, la misma no se

ha seguido estrictamente. En algunos casos se han tomado decisiones basadas en

interpretaciones propias y también se han realizado ciertos ajustes que se consideraron

convenientes. Además, ha sido necesario considerar aspectos relativos a la movilidad de los

agentes, que no están especificados en la metodología elegida debido a que la misma está

orientada a los agentes en general y no toma en cuenta las particularidades de los agentes

móviles.

7.3 Análisis y diseño de la aplicación

7.3.1 Fase de Análisis

Paso 1: Definición de casos de uso

La identificación de casos de uso se utiliza para capturar los requerimientos

funcionales del sistema.

De acuerdo con la presentación de la aplicación realizada al comienzo del capítulo

surgen los siguientes (ver figura 7.1):

1. Solicitar búsqueda de documentos

2. Cancelar búsqueda de documentos

3. Registrar suscripción para recibir novedades referentes a una búsqueda

4. Cancelar suscripción a novedades

5. Obtener resultados de una búsqueda

6. Abrir documento resultante

Paso 2: Identificación inicial de tipos de agentes

Este paso involucra la identificación de los principales tipos de agentes y la

construcción del primer diagrama de agentes. Para esto, se aplican las siguientes reglas:



Agregar un tipo de agente por cada usuario/dispositivo.

Agregar un tipo de agente por recurso.

En este caso se identifican los siguientes tipos de agentes: un agente de interfaz que

estará ubicado en cada nodo donde la aplicación esté disponible y que se encargará de toda la

interacción con el usuario, un agente de búsqueda que se moverá por los nodos de la red

buscando documentos que cumplan con la solicitud del usuario y un agente de novedades que

recorrerá los nodos de la red en busca de nuevos documentos que satisfagan una suscripción.

Estos dos últimos tipos de agentes operarán sobre los documentos distribuidos en la red, los

cuales constituyen el recurso de información del sistema.

Figura 7.1: Diagrama de casos de uso

La figura 7.2 muestra el diagrama de agentes. Los tipos de agentes se representan

con óvalos, los recursos con rectángulos, el usuario con la figura de una persona y cualquier

tipo de interacción con flechas.



Figura 7.2: Diagrama de agentes

Paso 3: Identificación de responsabilidades

En este paso se determinan de manera intuitiva las principales responsabilidades de

cada tipo de agente identificado en el paso anterior. Las responsabilidades se derivan de los

casos de uso detallados en el paso 1.

A continuación se encuentra la tabla de responsabilidades obtenida.

Tipo de Agente Responsabilidades

Agente de Interfaz

(estático)

Permitir al usuario especificar una solicitud de búsqueda

Atender solicitudes de cancelación de búsqueda del usuario

Permitir al usuario suscribirse para recibir novedades

Atender pedidos de cancelación de suscripciones

Presentar resultados de la búsqueda al usuario

Permitir abrir un documento

Agente de búsqueda

(móvil)

Moverse a cada nodo de la red realizando búsquedas de

documentos en base a un requerimiento

Agente de novedades

(móvil)


novedades en base a suscripciones



Paso 4: Identificación de conocidos

En este paso se identifican los enlaces de comunicación entre agentes que necesitan

interactuar. En algunas metodologías a estos enlaces se los denomina relaciones de

conocidos.

El agente de interfaz necesita entregar las solicitudes del usuario al agente de

búsqueda. Éste último debe entregar los resultados de la búsqueda al agente de interfaz del

cual recibió el requerimiento. De manera análoga, el agente de interfaz necesita interactuar

con el agente de novedades para satisfacer las suscripciones del usuario.

Se incorporan nuevas responsabilidades para la interacción entre estos tipos de

agentes, denotadas en la tabla a continuación con letra cursiva.


Agente de Interfaz

(estático)







Entregar solicitud del usuario al agente de búsqueda

Entregar pedido de suscripción para recibir novedades al

agente de novedades

Recibir resultados enviados por el agente de búsqueda

Recibir resultados enviados por el agente de novedades

Enviar cancelación de solicitud al agente de búsqueda

Informar cancelación de suscripción al agente de novedades

Agente de búsqueda

(móvil)


documentos en base a un requerimiento

Recibir solicitud de búsqueda del agente de interfaz

Entregar lista de documentos que satisfacen un pedido de

búsqueda al agente de interfaz



(continuación)


Agente de novedades

(móvil)


novedades en base a suscripciones

Recibir solicitud de novedades del agente de interfaz

Enviar lista de documentos incorporados o modificados

recientemente que satisfacen una solicitud de novedades al

agente de interfaz

En la figura 7.3 se muestra el nuevo diagrama de agentes incluyendo las relaciones de

conocidos.

Figura 7.3: Diagrama de agentes (refinamiento 1)



Paso 5: Refinamiento de agentes

En este paso se refina el conjunto inicial de tipos de agentes obtenido en el paso 2.

Se pueden descubrir nuevos tipos de agentes en base a la información de soporte que

necesitan los agentes para cumplir con sus responsabilidades, a la forma en que se dan a

conocer los agentes entre sí o a la necesidad de contar con una entidad que realice tareas de

administración.

Si bien la metodología no lo especifica, en este punto también se considera necesario

determinar en qué momento serán creados los agentes que componen la aplicación.

El agente de interfaz se creará en el momento en que el usuario inicie la aplicación.

Con respecto a los agentes de búsqueda y de novedades, se consideran dos opciones: tener un

número fijo de agentes de cada tipo creados esperando recibir solicitudes o bien que se creen

en el momento en que surge la necesidad y que dejen de existir una vez cumplido el

requerimiento. Para evitar tener agentes ociosos en el sistema, se decide elegir la segunda

opción. La responsabilidad de creación de estos agentes se atribuye a un nuevo tipo de agente,

que se denominará administrador.

Refinamiento del agente de búsqueda

Cuando el usuario solicita una búsqueda, el agente de interfaz envía la solicitud al

agente administrador para que cree un nuevo agente de búsqueda móvil. Este último recorre

los nodos de la red, buscando y procesando los documentos hasta encontrar el conjunto de

resultados que cumplan con la solicitud. Finalmente, envía la respuesta al agente de interfaz.

Si el usuario cancela la búsqueda, el agente de interfaz envía la cancelación al agente

administrador para que elimine el agente de búsqueda creado.

A fin de mejorar el rendimiento de la aplicación, se decide mantener un índice de

documentos en cada host para disminuir el tiempo de búsqueda. Para realizar esta tarea surge

un nuevo tipo de agente, al que se denominará indexador. El agente de búsqueda utilizará el

índice generado por el agente indexador para buscar en cada host los documentos requeridos,

por lo que deberá existir un agente de este tipo en cada host donde se desee compartir

documentos.



Refinamiento del agente de novedades

Aprovechando que se utilizará una plataforma que, por ser compatible con FIPA,

brinda el servicio de páginas amarillas a través de un agente DF, se resuelve utilizar este

servicio para llevar a cabo la interacción entre los agentes de interfaz y de novedades.

Cuando el agente de interfaz recibe un pedido de suscripción por parte del usuario,

se registra en el DF indicando los parámetros de la suscripción. Por otra parte, el agente

indexador, al detectar cambios en el índice, avisa al agente administrador que hay novedades.

El agente administrador crea un agente de novedades y le indica el lugar en donde se

produjeron los cambios. El agente de novedades migra hacia ese lugar y pide al DF los

agentes de interfaz que están suscriptos para recibir novedades sobre documentos nuevos o

modificados. Para cada suscripción, busca si hay novedades que la satisfagan y envía los

resultados al agente de interfaz correspondiente. Si el usuario cancela la suscripción, el agente

de interfaz debe anular la suscripción en el DF.

Se actualiza a continuación la tabla de responsabilidades, destacándose en letra

cursiva los nuevos tipos de agentes y las nuevas responsabilidades de los tipos ya existentes.


Agente de interfaz

(estático)







Recibir resultados enviados por el agente de búsqueda

Recibir resultados enviados por el agente de novedades

Registrarse en el DF para recibir novedades relacionadas con

una suscripción

Desregistrarse del DF cuando el usuario cancela la suscripción

Enviar solicitud de búsqueda al agente administrador

Enviar cancelación de búsqueda al agente administrador



(continuación)


Agente de búsqueda

(móvil)

Moverse a cada nodo de la red y buscar en el índice los

documentos que cumplan con la solicitud

Entregar lista de documentos que satisfacen un pedido de

búsqueda al agente de interfaz.

Agente de novedades

(móvil)

Moverse al nodo de la red en el que aparecieron novedades

Solicitar al DF los pedidos de suscripción registrados y, para

cada suscripción , buscar en el índice

Enviar lista de documentos incorporados o modificados

recientemente que satisfacen una solicitud de novedades al

agente de interfaz

Agente administrador

(estático)

Recibir pedido de búsqueda de parte del agente de interfaz

Recibir aviso de novedades de parte del agente indexador

Crear agente de búsqueda, especificando la solicitud de

búsqueda a procesar


(estático)

Crear agente de novedades

Recibir cancelación de búsqueda de parte del agente de interfaz

Eliminar agente de búsqueda cancelada

Agente indexador

(estático)

Crear y mantener el índice

Avisar de cambios en el índice al agente administrador

En la figura 7.4 se presenta el diagrama de agentes refinado.



Figura 7.4: Diagrama de agentes (refinamiento 2)

Paso 6: Información de despliegue de agentes

La información de despliegue de agentes permite visualizar en un diagrama cómo se

distribuyen físicamente los agentes en los hosts de la red (figura 7.5).

Figura 7.5: Diagrama de despliegue de agentes

Agente de

interfaz

Agente indexador

Agente de

búsqueda

Agente de

novedades

Agente admin..

DF

Agente de

búsqueda

Agente de

novedades

Nodo de la red Nodo donde residen los servicios de la plataforma

Agente estático Agente móvil

Agente de

interfaz

Agente indexador



7.3.2 Fase de Diseño

Debido a que en la fase de diseño se toma como base la tabla de responsabilidades

obtenida en el análisis, se transcribe a continuación la tabla final con las responsabilidades

numeradas de manera de poder hacer referencia a ellas en los siguientes pasos. Se incluyen

algunas responsabilidades nuevas, que no surgieron en la fase de análisis por ser de un mayor

nivel de detalle.


Agente de interfaz

(estático)

1. Permitir al usuario especificar una solicitud de búsqueda

2. Atender solicitudes de cancelación de búsqueda del usuario

3. Permitir al usuario suscribirse para recibir novedades

4. Atender pedidos de cancelación de suscripciones

5. Presentar resultados de la búsqueda al usuario

6. Permitir abrir un documento

7. Recibir resultados enviados por el agente de búsqueda

8. Recibir resultados enviados por el agente de novedades

9. Registrarse en el DF para recibir novedades relacionadas a una

suscripción

10. Desregistrarse del DF cuando el usuario cancela la suscripción

11. Enviar solicitud de búsqueda al agente administrador

12. Enviar cancelación de búsqueda al agente administrador

13. Recibir aviso de fin de búsqueda por parte del agente de

búsqueda

Agente de búsqueda

(móvil)

1. Moverse a cada nodo de la red

2. Al llegar a cada host, buscar en el índice los documentos que

cumplan con la solicitud

3. Entregar lista de documentos que satisfacen un pedido de

búsqueda al agente de interfaz

4. Enviar aviso de búsqueda finalizada

5. Recibir confirmación de recepción de fin de búsqueda

6. Solicitar ubicación del índice al agente indexador

7. Recibir ubicación del índice



(continuación)


Agente de novedades

(móvil)

1. Moverse al nodo de la red en el que aparecieron novedades

2. Solicitar al DF los pedidos de suscripción registrados

3. Para cada suscripción buscar en el índice

4. Enviar lista de documentos incorporados o modificados

recientemente que satisfacen una solicitud de novedades al agente

de interfaz

5. Solicitar ubicación del índice al agente indexador

6. Recibir ubicación del índice


(estático)

1. Recibir pedido de búsqueda de parte del agente de interfaz

2. Recibir aviso de novedades de parte del agente indexador

3. Crear agente de búsqueda, especificando la solicitud de

búsqueda a procesar

4. Crear agente de novedades

5. Recibir cancelación de búsqueda de parte del agente de interfaz

6. Eliminar agente de búsqueda cancelada

7. Recibir aviso de fin de búsqueda por parte del agente de

búsqueda

8. Confirmar recepción de aviso de fin de búsqueda

Agente indexador

(estático)

1. Crear y mantener el índice

2. Avisar de cambios en el índice al agente administrador

3. Recibir pedido de ubicación del índice

4. Informar ubicación del índice

Paso 1: División o combinación de agentes

En este paso se determina si es necesario combinar o dividir los tipos de agentes

identificados en la fase de análisis. Se debe considerar la combinación de dos o más tipos de

agentes en uno con el fin de evitar la duplicación de datos o la duplicación de código para



acceder a los recursos. Por otra parte, es necesaria la división de un tipo de agente si sus

funciones deben llevarse a cabo en diferentes máquinas, ya que cada agente está situado en

una sola máquina, excepto los agentes móviles, que realizan sus tareas migrando a través de la

red. También se debe considerar la división para evitar tener agentes demasiado grandes y

complejos, aunque tampoco es eficiente tener gran cantidad de agentes simples, debido a que

esto incrementa el intercambio de mensajes.

En este caso, el agente de búsqueda y el agente de novedades acceden al mismo

recurso, el índice creado por el agente indexador. Se decide crear una generalización de estos

tipos de agentes, denominada agente experto, para no duplicar el código que efectúa la

búsqueda en el índice. Sin embargo, no se combinan los dos tipos de agentes en uno solo

debido a que su comportamiento es diferente, ya que el agente de búsqueda migra por toda la

red para satisfacer una única solicitud mientras que el agente de novedades migra solamente

al host donde se produjeron cambios y procesa todas las suscripciones registradas en el DF.

Paso 2: Especificación de interacciones

En este paso se describen, para cada tipo de agente, las interacciones asociadas a las

responsabilidades que corresponden a relaciones de conocidos con otros agentes.

Las interacciones entre los agentes de la aplicación se llevarán a cabo mediante el

intercambio de mensajes ACL (Lenguaje de Comunicación de Agentes) que cumplen con las

especificaciones FIPA, cuya implementación es proporcionada por la plataforma JADE (clase

ACLMessage). Para cada mensaje, se seleccionará alguna de las performativas ofrecidas por

JADE.

Debido a que las interacciones en las que participa cada agente serán implementadas

en comportamientos diferentes, los cuales se ejecutarán concurrentemente, es necesario

especificar plantillas de mensajes adecuadas para recibir los mensajes entrantes. El uso de

plantillas es el mecanismo provisto por JADE para permitir que los agentes sean capaces de

clasificar los mensajes recibidos, de manera que cada comportamiento pueda filtrar sólo

aquellos mensajes que le corresponde procesar.

En la siguiente tabla se listan los mensajes asociados a las interacciones en las que

participa cada tipo de agente. En cada fila se detalla:

Nombre descriptivo de la interacción



Responsabilidad que originó la interacción (número de responsabilidad en la tabla

anterior)

Rol del agente: emisor o receptor del mensaje

Performativa del mensaje

Tipo de agente que cumple el rol contrario

Para los mensajes enviados: condición que ocasiona la emisión del mensaje

Para los mensajes recibidos: plantilla de mensajes

Agente de interfaz

Interacción Resp Rol Perf. Con Condición/Plantilla

Solicitar una búsqueda 11 E Request Agente

admin.

El usuario solicita

una búsqueda

Cancelar una búsqueda 12 E Request Agente

admin.

El usuario cancela

una búsqueda

Recibir resultado de una

búsqueda

7 R Inform Agente de

búsqueda

perf. = inform

Recibir novedades 8 R Inform Agente de

novedades

perf. = inform

Recibir fin de búsqueda 13 R Inform Agente de

búsqueda

perf. = inform

Agente de búsqueda


Entregar resultados 3 E Inform Agente de

interfaz

Al finalizar la

búsqueda en cada

nodo

Informar fin de búsqueda 4 E Inform Agente

admin. /

Agente de

interfaz

Transcurrido cierto

tiempo sin tener

nodos a donde

migrar



(continuación) Agente de búsqueda


Solicitar ubicación del

índice

6 E Request Agente

indexador

Al llegar a un nodo

de la red

Recibir confirmación de

recepción de fin de

búsqueda

5 R Confirm Agente

admin.

emisor = agente

administrador y

perf. = confirm

Recibir ubicación del

índice

7 R Inform Agente

indexador

emisor = agente

indexador y

perf. = inform

Agente de novedades


Entregar novedades 4 E Inform Agente de

interfaz

Encuentra

novedades para una

suscripción

Solicitar ubicación del

índice

5 E Request Agente

indexador

Al llegar al nodo

donde se detectaron

cambios

Recibir ubicación del

índice

6 R Inform Agente

indexador

emisor = agente

indexador y

perf. = inform



Confirmar recepción de

fin de búsqueda

8 E Confirm Agente de

búsqueda

Se recibe un

mensaje de fin de

búsqueda

Recibir pedido de

búsqueda

1 R Request Agente de

interfaz

emisor ≠ AMS (*)



(continuación) Agente administrador


Recibir aviso de

novedades

2 R Inform Agente

indexador

emisor ≠ AMS (*)

Recibir cancelación de

búsqueda

5 R Inform Agente de

interfaz

emisor ≠ AMS (*)

Recibir fin de búsqueda 7 R Inform Agente de

búsqueda

emisor ≠ AMS (*)

Agente indexador

Interacción Resp Rol Perf. Con Cuando

Enviar aviso de novedades 2 E Inform Agente

admin.

Se detectan

cambios en el

índice generado

Informar ubicación del

índice

4 E Inform Agente de

búsqueda /

Agente de

novedades

Al recibir pedido de

ubicación del índice

Recibir pedido de

ubicación del índice

3 R Request Agente de

búsqueda /

Agente de

novedades

perf. = request

(*) Las interacciones con el agente AMS (Agent Management System) se detallarán más adelante en

esta sección.

Convenciones de nombres

Es necesario establecer una convención de nombres a fin de que los agentes puedan

intercambiar mensajes. El agente administrador tendrá un nombre predefinido y conocido por

todos los agentes. A fin de que el usuario pueda ingresar a la aplicación desde cualquier

máquina y conserve las suscripciones a novedades realizadas anteriormente, el agente de



interfaz tendrá el nombre con el que el usuario inició la sesión en el sistema operativo. Para

los agentes de búsqueda y de novedades se utilizará una etiqueta seguida de un número

aleatorio. Estos agentes necesitan ser conocidos sólo por el agente administrador que, por ser

su creador, puede almacenar su nombre para usarlo en futuras comunicaciones. Para los

agentes indexadores se utilizará una etiqueta seguida del nombre del host en donde se crean,

dado que necesitan ser conocidos por los agentes de búsqueda y novedades en el momento

que estos llegan al host.

Interacción con el DF

Para la comunicación con el agente DF (Directory Facilitator), en lugar de mensajes

ACL, se utilizará un servicio de la plataforma que ofrece un conjunto de métodos para

registrar, modificar, desregistrar y buscar en el DF.

Se listan en la siguiente tabla las interacciones con el agente DF.

Agente de interfaz

Interacción Resp Método Con Condición

Registrarse en el DF 9 Register Agente

DF

El usuario se

suscribe para

recibir novedades

Desregistrarse del DF 10 Deregister Agente

DF

El usuario cancela

su suscripción

Agente de novedades

Interacción Resp Método Con Condición

Solicitar suscripciones al

DF

2 Search Agente

DF

Al llegar al nodo

donde se detectaron

cambios

Interacción con el AMS

Algunas responsabilidades tienen asociada una interacción con el AMS (Agent

Management System) de la plataforma.



En la fase de análisis se determinó que el agente de búsqueda debe recorrer la red

para cumplir su tarea, sin precisar cómo obtendrá información acerca de los hosts disponibles

y su dirección para armar su itinerario. Para esto, se utilizará un servicio provisto por JADE

(implementado por la clase AMSSubscriber) que permite a un agente suscribirse para recibir

notificaciones sobre eventos ocurridos en la plataforma e instalar manejadores para los

eventos en los que el agente está interesado. En el momento en que un agente se suscribe, el

AMS lo informa sobre el estado actual de la plataforma (contenedores y agentes existentes).

De esta manera, el agente de búsqueda, al suscribirse, podrá saber cuáles son los contenedores

existentes en la plataforma, y luego será notificado cada vez que se agregue o elimine un

contenedor.

También se aprovechará este servicio de la plataforma para detectar si un agente de

búsqueda falla mientras está realizando su recorrido, por ejemplo, si se apaga la máquina en la

que está buscando. El agente administrador se suscribirá con el AMS e instalará manejadores

para los eventos de migración y muerte de agentes. De esta manera, podrá ir almacenando el

recorrido de todos los agentes de búsqueda creados y, si uno de ellos muere, creará un nuevo

agente de búsqueda para reemplazarlo indicándole los contenedores ya visitados, para que no

se repita la búsqueda en ellos. Por otra parte, el agente administrador debe solicitar al AMS la

eliminación de un agente de búsqueda cuando el usuario cancela la búsqueda que lo originó.

La siguiente tabla muestra, para cada tipo de agente, los mensajes intercambiados

con el AMS, indicando los manejadores de eventos instalados para las notificaciones

recibidas.

Agente de búsqueda

Interacción Resp. Rol Perf. Con Condición /

Manejador

Suscribirse a eventos de la

plataforma

8 E Subscribe AMS Al iniciarse

Atender eventos de la

plataforma

9 R Inform AMS Added-container

Removed-container



(continuación) Agente administrador

Interacción Resp. Rol Perf. Con Condición /

Manejador

Suscribirse a eventos de la

plataforma

9 E Subscribe AMS Al iniciarse

Atender eventos de la

plataforma

10 R Inform AMS Moved-agent

Dead-agent

Paso 3: Registro y búsqueda en el catálogo de páginas amarillas

En este paso se formalizan las convenciones de nombre y los servicios a

registrar/buscar en el catálogo de páginas amarillas, que en JADE es mantenido por el DF. Se

utiliza la forma de diagramas de clase, como lo sugiere la metodología.

Figura 7.6: Registro y búsqueda en el DF

Paso 4: Interacciones agente-recurso

En la fase de análisis se identificaron los agentes que necesitan interactuar con

recursos externos para ejecutar sus tareas. En el diagrama de la figura 7.4 se representaron los

siguientes recursos:

Agente de

Interfaz

InterfazSD: ServiceDescription

Type = Suscripción novedades

InterfazProp: Properties

textoSuscripcion = <textoSuscripcion>

registra

Agente de

Novedades

NovedadesSD: ServiceDescription

Type = Suscripción novedades

NovedadesProp: Properties

textoSuscripcion = <textoSuscripcion>

busca



Índice: se trata de un recurso pasivo, en el sentido de que su estado es modificado

únicamente por el agente que lo controla, el indexador. Para la creación y actualización

del índice, así como también para realizar las búsquedas se utilizarán clases provistas por

una herramienta denominada Lucene1 que brinda esta capacidad. Debido a que el índice

puede ser accedido por varios agentes en forma concurrente, podrían existir problemas de

bloqueos, sin embargo, esto no sucede ya que Lucene sincroniza sus clases para evitar

estos inconvenientes.

Documentos en una LAN: representa un recurso activo, ya que su estado cambia sin la

intervención del agente que lo utiliza, el indexador. Por lo tanto, es necesario establecer un

mecanismo para detectar los cambios en el recurso y actuar en consecuencia. En este caso,

se utilizará un mecanismo de sondeo, el agente indexador actualizará el índice

transcurrido un período de tiempo parametrizable, y, si detecta que algún documento se

agregó o modificó, notificará al agente administrador para que envíe un agente de

novedades.

Paso 5: Interacciones agente-usuario

La interacción con el usuario será llevada a cabo por el agente de interfaz. El mismo

contará con una interfaz gráfica de usuario (GUI) implementada mediante la biblioteca

gráfica Swing de Java. La GUI capturará los eventos del usuario y avisará al agente de

interfaz para que actúe en consecuencia. Por otro lado, cuando el agente de interfaz reciba

información para el usuario, notificará a la GUI para que se actualice. Todo esto se consigue

heredando el comportamiento de las clases provistas por JADE en su paquete jade.gui las

cuales utilizan el mismo modelo de notificación de eventos del lenguaje Java.

Paso 6: Comportamientos internos de los agentes

Adoptando la arquitectura de agente básica proporcionada por Jade, las tareas que

cada tipo de agente debe realizar serán organizadas en comportamientos (clase Behaviour).

Dichas tareas se desprenden de las responsabilidades identificadas en la fase de análisis. Se

debe decidir qué tipo de comportamiento es adecuado en cada caso, dependiendo de si la tarea

debe ejecutarse por única vez, periódicamente, cíclicamente, etc., a fin de extender la clase de

JADE que corresponda.

1 Ver apéndice A



A continuación se describen los comportamientos identificados para cada tipo de

agente:

Agente de interfaz

Comportamiento Descripción

Manejar Mensajes Recibidos

CyclicBehaviour.

Recibe los mensajes enviados por los agentes de

búsqueda y de novedades. Según el contenido de cada

mensaje, notifica a la GUI para que muestre los

resultados de una búsqueda, habilite una nueva

búsqueda o avise al usuario que se recibieron

novedades para una suscripción.

Responsabilidades asociadas: 5, 7, 8, 13.

Agente de búsqueda


AMS Listener Buscador

(CyclicBehaviour,

extiende a AMSSubscriber)

Maneja las notificaciones enviadas por el AMS sobre

eventos added-container (contenedor agregado) y

removed-container (contenedor eliminado),

actualizando el itinerario del agente.

Responsabilidades asociadas: 8, 9.

Recorrer Contenedores

(CyclicBehaviour)

Provoca la migración del agente al siguiente

contenedor del itinerario. Al llegar a destino, solicita

al agente indexador local la ubicación del índice,

efectúa la búsqueda y envía los resultados al agente de

interfaz. Transcurrido cierto tiempo sin tener

contenedores para visitar, envía un aviso de fin de

búsqueda al agente administrador y al de interfaz, y

luego el agente se elimina.

Responsabilidades asociadas: 1, 2, 3, 4, 5, 6, 7.



(continuación) Agente de novedades


Solicitar Suscripciones al DF

(OneShotBehaviour)

Se ejecuta al llegar al contenedor donde hubo cambios

en el índice. Solicita al agente indexador local la

ubicación del índice y busca en el DF los agentes de

interfaz suscriptos para recibir novedades. Para cada

suscripción, efectúa la búsqueda y envía los

resultados.

Responsabilidades asociadas: 1, 2, 3, 4, 5, 6.



AMS Listener Administrador

(CyclicBehaviour, extiende a

AMSSubscriber)

Maneja las notificaciones enviadas por el AMS sobre

eventos moved-agent (migración de agente) y dead-

agent (agente muerto). Cada vez que un agente de

búsqueda migra, actualiza en una tabla su recorrido. Si

un agente de búsqueda se muere, crea un nuevo agente

para reemplazarlo y le indica los contenedores ya

recorridos.

Responsabilidades asociadas: 9, 10

Recibir Mensajes

(CyclicBehaviour)

Se bloquea esperando mensajes de otros agentes

(excepto los del AMS), se ejecuta en un hilo dedicado

para no bloquear al agente completo. Según el

contenido del mensaje, realiza las siguientes tareas:

crea un agente de búsqueda, crea un agente de

novedades, elimina un agente de búsqueda de la tabla

donde almacena los recorridos, mata un agente de

búsqueda.

Responsabilidades asociadas: 1, 2, 3, 4, 5, 6, 7, 8.



(continuación) Agente indexador


Indexar Archivos

(TickerBehaviour)

Actualiza el índice de documentos periódicamente. Si

detecta un documento nuevo o modificado desde la

última actualización, avisa al agente administrador.


Recibir Mensajes Indexador

(CyclicBehaviour)

Se bloquea esperando mensajes de otros agentes, se

ejecuta en un hilo dedicado para no bloquear al agente

completo. Responde los mensajes que solicitan la

ubicación del índice.


Se podrá observar que todos los comportamientos generan acciones en respuesta a

algún estímulo. Los agentes no utilizan un modelo simbólico del entorno, no aprenden de su

experiencia y la planificación de sus comportamientos es llevada a cabo por la plataforma.

Estas características permiten clasificarlos dentro de la categoría de agentes con arquitectura

reactiva. No obstante, se almacenará cierta información histórica con el fin de producir una

conducta proactiva en determinadas circunstancias, por ejemplo, lanzar un agente que

complete una búsqueda cuando muere el agente que la inició.

Paso 7: Definición de una ontología

Cuando los agentes de un sistema interactúan, intercambian información acerca de

entidades concretas o abstractas existentes en el entorno en el cual los agentes residen. Estas

entidades se denominan conceptos, y las relaciones entre ellas se conocen como predicados.

Un tipo particular de entidad son las acciones que los agentes pueden realizar.

Una forma de expresar una ontología, es decir, el conjunto de conceptos, predicados

y acciones de agentes, es mediante diagramas de clases UML.

En este caso se distinguen dos conceptos principales, que representan los parámetros

de búsqueda y los resultados de las búsquedas. Para toda la comunicación entre los agentes se

utilizan descriptores de acciones.



Acción Descripción

Buscar

(Parámetros parámetros)

Crea un agente de búsqueda con los parámetros dados

Cancelar Cancela una búsqueda eliminando el agente

correspondiente

Resultados

Entrega los resultados de una búsqueda

Novedades Entrega resultados referidos a una suscripción a

novedades

Fin Informa la finalización de una búsqueda

AvisoNovedades Crea un agente de novedades, indicándole el host donde

se detectaron cambios en el índice

Índice Retorna la ubicación del índice

Figura 7.7: Ontología de la aplicación

<<concepto>> Parámetros

String textoBuscado boolean buscarPorRelevancia float relevanciaMinima Date fechaMinima

<<concepto>> Resultados

String url float relevancia Date fecha



7.4 Diagramas de clases


Capítulo 8 Conclusiones

Al comenzar la investigación sobre agentes de software, nos llamó la atención la

gran variedad de tipos de agentes que existen1, así como también su utilización en diversos

dominios de aplicación, desde un simple agente que organiza una reunión para los empleados

de una empresa, hasta complejos sistemas de agentes que se encargan de monitorear el

tránsito aéreo. Esto nos llevó a acotar nuestra investigación y a enfocar nuestro estudio en un

tipo particular de estas entidades: agentes de software móviles.

La tecnología de agentes móviles constituye una poderosa herramienta al momento

de desarrollar aplicaciones distribuidas, favoreciendo el procesamiento en paralelo, la

comunicación punto a punto, el cómputo asíncrono y la reducción del tráfico de red,

características que pudimos comprobar en el caso práctico implementado. Sin embargo,

presenta algunas limitaciones, como la obligatoriedad de contar con una instancia de la

plataforma de agentes en cada nodo. Este requisito repercute sobre el rendimiento del sistema,

ya que, en particular si se utilizan plataformas implementadas en lenguaje Java, además de la

JVM se debe disponer de la plataforma en todos los nodos a los cuales el agente necesite

viajar. Creemos que esta desventaja se solucionará en el futuro, cuando las distintas

plataformas consigan la interoperabilidad adaptándose en forma estricta a los estándares

existentes, de manera tal que, teniendo una sola plataforma instalada, se podría ejecutar en

ella cualquier aplicación basada en agentes. Actualmente, se están realizando grandes

esfuerzos dentro de la comunidad de desarrolladores de agentes móviles en este sentido, y ya

existen plataformas que permiten ejecutar agentes desarrollados para otro tipo de plataforma.

Por otra parte, consideramos que desarrollar una aplicación con agentes móviles

requiere de un esfuerzo importante que no se justifica en todos los escenarios, para

aplicaciones pequeñas es posible que el beneficio obtenido sea mínimo, comparado con el

esfuerzo dedicado. Si bien las plataformas resuelven gran parte del trabajo, pueden surgir

dificultades relacionadas con la movilidad, la planificación de los comportamientos, la




comunicación y coordinación entre agentes. Además, resulta difícil realizar las pruebas y la

depuración de los programas, debido principalmente a la migración y al entorno no

determinista.

Una limitación que se nos presentó en la búsqueda de información teórica fue la falta

de bibliografía disponible en el país. Por otro lado, la información que se puede obtener de

Internet es amplia y variada, pero no siempre es confiable y en general los temas no están

tratados con suficiente profundidad.

Por último, queremos resaltar que la elección de la plataforma JADE nos facilitó en

gran medida el desarrollo del caso de aplicación. La posibilidad de acceder a su código fuente,

además de su abundante documentación y la respuesta a nuestras consultas por parte de sus

desarrolladores a través de su lista de mails, fueron de gran ayuda para la realización de

trabajo.

Finalizada esta tesina, consideramos haber cumplido con los objetivos planteados.

Los resultados del estudio que hemos llevado a cabo y que hemos desarrollado en los

capítulos precedentes ofrecen una aproximación a la teoría de agentes móviles y su

comparación con otros paradigmas de cómputo distribuido, una explicación detallada del

proceso de migración y de los aspectos de la comunicación entre agentes relacionados con la

movilidad y un ejemplo completo de desarrollo de una aplicación basada en agentes móviles,

desde el análisis hasta la implementación. La documentación de las fases de análisis y diseño

del ejemplo puede servir como una guía de los posibles pasos a seguir para realizar una

aplicación de este tipo, considerando que, si bien existen varias metodologías para el análisis

y diseño de sistemas basados en agentes, no encontramos una que se enfoque específicamente

en el desarrollo de agentes móviles y tampoco un ejemplo completo que muestre cómo llevar

la teoría a la práctica.

Antes de finalizar este capítulo que constituye el cierre de esta tesina, creemos

importante enunciar algunas extensiones que podrían implementarse para ampliar la

funcionalidad de la aplicación práctica. Se podrían considerar en el futuro, entre otros, los

siguientes trabajos:

Proveer a la aplicación de un marco de seguridad acorde a fin de evitar posibles ataques

de agentes maliciosos. Es necesario implementar mecanismos tales como autenticación,

encriptación y firmas digitales para crear un ambiente de ejecución de agentes móviles

completamente seguro.



Dotar a los agentes de búsqueda de algún tipo de razonamiento a fin de que puedan

optimizar sus itinerarios en base al historial de búsquedas realizadas anteriormente.

Además, sería interesante utilizar en algún dominio de aplicación que lo requiera, el

agregado migration provisto por JADE que brinda la posibilidad de migración de agentes

inter-plataforma.


Glosario

ACL (Agent Communication Language): lenguaje especialmente diseñado para la

comunicación entre agentes de software.

API: librería de clases del lenguaje Java.

Broadcast: del inglés, difusión o distribución amplia, término utilizado en telecomunicación

para referirse a una emisión de amplia distribución.

CORBA (Common Object Request Broker Architecture): estándar para la distribución de

objetos. Su sitio web es http://www.omg.org/technology/corba/.

DNS (Domain Name System): sistema que convierte los nombres (alfabéticos) de los

dominios de los host conectados a Internet a direcciones IP (numéricos).

FTP (File Transfer Protocol): protocolo que permite la transferencia de archivos entre cliente

y servidor.

HTML (Lenguaje de Marcado de HiperTexto): lenguaje informático utilizado para crear

documentos hipertexto.

HTTP (Hyper Text Transfer Protocol): protocolo de transferencia de hipertextos. Es un

protocolo de comunicaciones no orientado a la conexión entre el servidor y el navegador

(cliente).

IIOP (Internet Inter-ORB Protocol): protocolo normativo para la informática distribuida en

internet.



JAR: formato de archivo utilizado para empaquetar varios archivos en un solo. La

herramienta para manejar este tipo de archivos forma parte estándar del API de la plataforma

Java.

JDK (Java Development Kit): paquete de software de la empresa Sun Microsystems que

incluye un kit de herramientas básicas para escribir, probar y depurar aplicaciones Java y

applets.

JVM (Java Virtual Machine): intérprete necesario para poder correr programas escritos en

lenguaje Java.

LAN (Local Area Network): red de comunicaciones de datos que conecta computadoras y

dispositivos periféricos en un área física limitada.

Multicast: mensaje que se envía a múltiples dispositivos de la red desde un servidor.

P2P (peer-to-peer): comunicación bilateral exclusiva entre dos personas a través de Internet

para el intercambio de información en general y de archivos en particular (ej, programa

eMule).

RMI (Remote Method Invocation): protocolo distribuido de objetos de la plataforma del

lenguaje Java

SMTP (Simple Mail Transfer Protocol): protocolo de red basado en texto utilizado para el

intercambio de mensajes de correo electrónico entre ordenadores y/o distintos dispositivos.

SOAP (Simple Object Access Protocol): protocolo basado en XML que permite que objetos

en un servidor remoto puedan ser utilizados como objetos locales.

TCP/IP (Transmission Control Protocol/Internet Protocol): protocolo que rige todas las

comunicaciones entre todas las computadoras en Internet. IP, es la especificación que



determina hacia dónde son encaminados los paquetes de datos, en función de su dirección de

destino. TCP, se asegura de que los paquetes lleguen correctamente a su destino.

Timestamp: marca de tiempo, fecha y hora.

UML (Unified Modeling Language): lenguaje estándar que permite modelar, construir y

documentar los elementos que forman un sistema software orientado a objetos.

URL (Uniform Resource Locator): dirección de un sitio o de una fuente, normalmente un

directorio o un archivo, ubicado en el World Wide Web.

XML (eXtensible Markup Language): metalenguaje para definir otros lenguajes de etiquetas

estructurados. Conjunto de reglas, guías y convenciones para la definición de etiquetas

semánticas (marcas y atributos).


APÉNDICE A Lucene

Lucene (http://lucene.apache.org) es un librería (API) para recuperación de

información (Information Retrieval) que permite agregar capacidades de indexación y

búsqueda a las aplicaciones. Está escrito en lenguaje java, es open-source y su distribución

es libre. Forma parte de la popular familia de proyectos Jakarta Apache.

Las clases que provee permiten crear índices, para luego realizar las búsquedas sobre

los mismos.

Formatos de archivos soportados

Lucene puede indexar cualquier dato que pueda ser convertido a formato de texto,

por lo tanto puede procesar archivos de texto comunes, documentos Microsoft Word, pdf,

HTML o cualquier otro formato del cual se pueda extraer información textual. Cabe destacar

que para algunos formatos, es necesario agregar librerías extras para lograr que Lucene pueda

trabajar con ellos.

Información acerca del índice

El índice que se construye está compuesto por dos archivos pequeños (con nombre

deletable y segments) que indican como acceder al índice y por un archivo binario con

extensión cfs, que mantiene los datos indexados. La ubicación en la cual Lucene almacenará

el índice puede ser elegida. Además se puede optar por crear el índice una vez y luego

actualizarlo o crearlo nuevamente cada vez que indexa. Otra posibilidad que brinda esta

herramienta es la de poder buscar en el índice al mismo tiempo que se está actualizando el

mismo.

Relevancia de resultados

Cuando se realiza una consulta al índice, Lucene realiza un cálculo (score) para cada

documento y obtiene para el mismo un valor numérico de relevancia. Para realizar el

mencionado cálculo utiliza una compleja fórmula matemática basada en la frecuencia de



aparición del texto buscado en el documento, el número de palabras que componen el texto

buscado que figuran en el documento, etc1. La colección de resultados que retorna está

ordenada según la relevancia obtenida.

Rendimiento

De acuerdo a pruebas realizadas, Lucene presenta características de buen

rendimiento y escalabilidad:

Indexa aproximadamente 30MB/minuto en una computadora Pentium 2.8 GHz.

El tamaño del índice es aproximadamente el 10% del tamaño del texto indexado.

Especificación de búsquedas

Lucene permite realizar búsquedas de palabras o frases. La especificación del texto

no distingue entre letras mayúsculas y minúsculas. En el patrón a buscar pueden utilizarse

combinaciones de conjunciones, disyunciones, negaciones, comodines, etc., de esta manera se

pueden especificar búsquedas mas complejas2.

1 Ver (Gospodnetic y Hatcher, 2004: 78) para observar la fórmula utilizada o profundizar acerca del cálculo de relevancia. 2 Ver (Gospodnetic y Hatcher, 2004: 74)


APÉNDICE B Instructivo de la aplicación

Requerimientos de software

Para ejecutar la aplicación Buscadocs se necesita tener disponible:

El ambiente runtime de Java versión 1.4 o superior.

La plataforma de agentes JADE versión 3.41. En el CD entregado se incluyeron los jars de

la plataforma (Base64.jar, http.jar, iiop.jar, jade.jar y jadeTools.jar)

dentro de la carpeta lib.

La librería de clases Lucene versión 1.4.3. (lucene-1.4.3.jar). Además, se debe tener

disponible, un agregado que posibilita la búsqueda de documentos en formato pdf

(PDFBox-0.7.2.jar). Los dos jars mencionados también se proveen en el cd dentro de la

carpeta lib.

Requerimientos de hardware

Como la aplicación desarrollada realiza la búsqueda de documentos distribuidos, se

necesita computadoras conectadas en red con requerimiento mínimo de 128 Mb. de RAM.

Configuración y ejecución

Tanto la plataforma JADE como la aplicación no requieren de instalación,

simplemente se necesita copiar los archivos jar correspondientes y dejarlos accesibles. En

todos los hosts en los que se desee ejecutar la aplicación se debe copiar la carpeta lib del CD

dentro de la carpeta en donde se desee mantener la aplicación. De ahora en adelante se hará

referencia a dicha carpeta como carpeta de instalación.

1 Ver detalles sobre la obtención de la plataforma y sus requerimientos de software en capítulo 6, secciones 6.3.6 y 6.3.7.



Se debe elegir un host en el que residirá la plataforma principal. Este host no

necesita tener características especiales, puede ser cualquier nodo de la red.

En el host elegido, se debe copiar la carpeta plataforma dentro de la carpeta de

instalación (quedará ubicada al mismo nivel que la carpeta lib copiada anteriormente).

Luego se deben configurar los parámetros de la aplicación modificando el archivo

config.ini ubicado dentro de la carpeta plataforma. Allí se debe colocar el número de

puerto en donde se desea correr la plataforma, si no se especifica ningún valor se tomará por

defecto el puerto 1099.

Finalmente, para iniciar la aplicación, se debe ejecutar el archivo plataforma.bat

ubicado dentro de la carpeta plataforma. Se mostrará la interfaz del agente RMA de JADE,

desde allí se podrá monitorear y administrar gráficamente el sistema de agentes completo1.

Se debe tener en cuenta que la plataforma principal debe ser la primera en

ejecutarse, ya que en ella residirá el contenedor principal y los demás contenedores que se

creen se unirán a éste.

En cada computadora que se desee dejar accesible para las búsquedas de

documentos se deberá ejecutar la aplicación Buscadocs. Para ello, se debe copiar la carpeta

buscadocs dentro de la carpeta de instalación.

Se deben especificar en el archivo de configuración config_index.ini, ubicado

dentro de la carpeta buscadocs, los siguientes parámetros:

host: se debe colocar el nombre o la IP del host en donde está corriendo la plataforma

principal.

puerto: número de puerto en donde se está ejecutando la plataforma principal.

directorio: carpeta del disco en donde se desea alojar el índice de los documentos.

localidad: path en donde residen los documentos sobre los cuales desea realizar las

búsquedas (si desea buscar en todo el disco puede especificar por ej. C:\).

fecha: última fecha en que se realizó la indexación en formato ddMMaaaahhmmss (ej.

18122006183040 indica fecha 18/12/2006, hora 18 con 30 minutos y 40 segundos. En el

momento de la instalación debería colocarse la fecha actual. En las sucesivas indexaciones

la aplicación actualizará automáticamente este parámetro.




tiempo: tiempo en milisegundos transcurrido entre una indexación y la próxima a

realizarse. Asignar un valor pequeño para este parámetro ocasionará que el índice se

actualice frecuentemente, por el contrario, si el valor es grande se reindexará cada

períodos de tiempo mas prolongados.

Una vez finalizada la configuración, se debe ejecutar indexdocs.bat. Se recomienda

incluir la ejecución de este bat dentro de las tareas de inicio de la computadora, con el fin de

tener la máquina siempre accesible para las búsquedas y también de mantener el índice

actualizado.

Para levantar la interfaz que permite realizar las búsquedas de documentos, se debe

ejecutar el archivo buscadocs.bat ubicado en la carpeta buscadocs. Se recomienda crear un

acceso directo a este archivo, de manera de facilitar el acceso del usuario a la aplicación.

Instructivo de uso

Realizar búsquedas

Se podrán realizar búsquedas por contenido en archivos de los cuales se pueda

obtener información textual, por ejemplo: documentos de Word, planillas de cálculo, archivos

HTML, PDF, etc.

Escriba el texto a buscar en el cuadro de texto identificado con el Nº 1 en la figura

7.7. La especificación del texto no distingue entre letras mayúsculas y minúsculas. En la

siguiente tabla se muestran ejemplos de los tipos de expresiones de búsqueda que soporta la

aplicación.

Expresión de búsqueda Documentos que contienen…

Agente El término agente

agente tesis El término agente o el término tesis

+agente +tesis El término agente y el término tesis

+agente –tesis El término agente y no contiene el

término tesis

“Agentes de software móviles” Exactamente la frase “Agentes de

software móviles”

tesis* Términos que comienzan con tesis



En el momento de realizar una búsqueda puede elegir si desea recibir novedades

sobre el texto buscado, es decir, si quiere ser notificado sobre futuras incorporaciones o

modificaciones de documentos que contengan el texto buscado. En caso de que desee

suscribirse, marque la casilla Desea recibir novedades?. Observe que en la lista de la derecha,

mostrada en la figura con el Nº 5, aparecerá el texto con el que se suscribió.

Además, debe elegir entre dos opciones que fijarán la manera en que los resultados

serán filtrados: relevancia o fecha. En el primer caso, seleccione la opción Relevancia e

ingrese en el cuadro mostrado en la figura 7.7 con el Nº 2 el porcentaje deseado (valor

numérico entre 0 y 100). Este porcentaje será tomado como valor mínimo al momento de

filtrar. Por ejemplo, si se ingresa 80, se retornarán los resultados que tuvieron una relevancia

de 80 o superior. Si en cambio, desea obtener resultados filtrados por fecha, elija la opción

Fecha y complete en el cuadro, mostrado en la figura 7.7 con el Nº 3, la fecha deseada

respetando el formato dd/mm/aa. En este caso, se mostrarán en los resultados aquellos

documentos con fecha de modificación posterior a la fecha ingresada.

Una vez seleccionadas las opciones de búsqueda, presione el botón Buscar para

iniciar la operación.

Figura 8.1: Interfaz de la aplicación



Cancelación de una búsqueda

Se puede cancelar una búsqueda iniciada previamente presionando el botón

Cancelar. En ese momento se volverá a habilitar el botón Buscar, dejando la interfaz

disponible para realizar una nueva búsqueda.

Visualización de resultados

Los resultados de una búsqueda se recibirán en forma parcial hasta que finalice la

misma. En ese momento se mostrará una leyenda que indicará el fin de la tarea. Los

resultados se mostrarán en la tabla situada en la parte inferior de la pantalla (mostrada en la

figura 7.7 con en Nº 4). Las filas de la tabla se podrán ordenar haciendo click con el mouse

sobre el encabezado de cada columna. Se puede seleccionar orden ascendente, descendente o

sin orden, en este último caso se mostrarán los resultados en el orden que fueron recibidos.

Para visualizar un documento en particular, haga doble clic sobre el nombre del documento;

este se abrirá siempre que exista un programa asociado al tipo de documento, en caso

contrario se mostrará un mensaje de error. En la figura 7.8 se observa como se muestra la

interfaz luego de la recepción de resultados.

Figura 8.2: Visualización de resultados de una búsqueda



Aviso y visualización de novedades

Si se encuentra suscripto para recibir novedades, se le mostrará un aviso cada vez

que haya nuevas incorporaciones, como se observa en la figura 7.9. Las novedades se pueden

visualizar haciendo doble click con el mouse sobre el texto con el cual se suscribió, ubicado

en la lista que aparece sobre la derecha de la pantalla. Las novedades se muestran de manera

similar a los resultados, es decir en una tabla cuyas filas pueden ordenarse como se detalló en

el apartado anterior.

Figura 8.3: Aviso de recepción de novedades

Quitar una suscripción a novedades

Si no se desea seguir recibiendo notificaciones sobre novedades, se puede quitar una

suscripción seleccionándola en la lista de la derecha, haciendo un click con el mouse sobre la

suscripción que desea quitar, y luego, presionando el botón Quitar suscrip..

Salida de la aplicación

Para abandonar la aplicación seleccione en el menú la opción Archivo y luego, Salir,

o directamente cierre la ventana.


APÉNDICE C Mails a lista de JADE

Este apéndice contiene los mails enviados con consultas a los desarrolladores de JADE

y sus respectivas respuestas.

Consulta

From: [email protected] [mailto:[email protected]] On Behalf Of Marcia Silvana Stippi Sent: mercoledì 25 gennaio 2006 12.50 To: [email protected] Subject: [jade-develop] Exception to shutdown JADE Hi !!! My problem is that when I want to shut down the platform I obtain following exception: Exception while removing reference: java.lang.InterruptedException java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at sun.java2d.Disposer.run(Disposer.java:100) at java.lang.Thread.run(Thread.java:534) AWT blocker activation interrupted: java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:429) at sun.awt.AWTAutoShutdown.activateBlockerThread(AWTAutoShutdown.java:309) at sun.awt.AWTAutoShutdown.setToolkitBusy(AWTAutoShutdown.java:226) at sun.awt.AWTAutoShutdown.notifyToolkitThreadBusy(AWTAutoShutdown.java:118) at sun.awt.windows.WToolkit.eventLoop(Native Method) at sun.awt.windows.WToolkit.run(WToolkit.java:262) at java.lang.Thread.run(Thread.java:534) 24-ene-2006 17:42:07 jade.core.Runtime$1 run INFO: JADE is closing down now. Somebody knows what happens? Greetings. Marcia.



Respuesta

De: Caire Giovanni <[email protected]> Enviado el: Miércoles, 25 de Enero de 2006 03:13:07 p.m. Para: Marcia Silvana Stippi <[email protected]>, [email protected] Asunto: RE: [jade-develop] Exception to shutdown JADE Hi, This exception depends on some problem in Swing. Honestly speaking I cannot say more. In any case don't worry about it. Bye. Giovanni.

Consulta

From: [email protected] [mailto:[email protected]] On Behalf Of Marcia Silvana Stippi Sent: venerdì 12 maggio 2006 13.24 To: [email protected] Subject: [jade-develop] Containers in different operating systems Hi! I need to know if is it possible to run within the same platform 2 containers in different operating systems. For example, if I have the Main-container raised in Windows, can I raise another container in Linux and obtain that an agent migrates between these containers? On the other hand, I have understood that in JADE the migration is within the same platform; that is to say, if I have two Main-Container, I cannot cause that the agents migrate between these two containers, is it true? Thank you very much. Greetings. Marcia.

Respuesta

De: Caire Giovanni <[email protected]> Enviado el: Lunes, 15 de Mayo de 2006 12:51:56 p.m. Para: "Marcia Silvana Stippi" <[email protected]>, <[email protected]> Asunto: RE: [jade-develop] Containers in different operating systems Hi, Yes it is possible due to the fact that Java is an operating system independent language. As for the second question, since JADE3.4 the new inter-platform migration service allows agents moving between different JADE platforms too. Look at the documentation included in the add-on for details. Bye. Giovanni.



Consulta

From: Marcia Silvana Stippi <[email protected]> Sent: Lunes, 05 de Junio de 2006 01:15:32 p.m. To: [email protected] Subject: [jade-develop] migration inter-platform in JADE Hi !!! I have a consultation with respect to migration of agents JADE; I know since one becomes in networks LAN, migrates knowing IP and port the destiny, but how it does in networks WAN? It must have a Web server raised in the destiny? Law in paper that for the migration Inter-platform in JADE the protocol can be chosen to use, HTTP, iiop, etc., is this certain? If somebody has an inter-platform migration example or some paper that I can watch I will thank for it. Thank you very much. Greetings. Marcia.

Respuesta

De: Joan Ametller <[email protected]> Enviado el: Lunes, 05 de Junio de 2006 02:39:57 p.m. Para: Marcia Silvana Stippi <[email protected]> CC: [email protected] Asunto: Re: [jade-develop] migration inter-platform in JADE Hi, I will start asking your last question. Inter-platform migration add-on sends agents using, as a transport mechanism, the ACL Messages. This implies that the underlying protocol transporting agents is the MTP you have currently installed. In case you have multiple MTPs installed in your platform, how do you select which one will be used to send the message ? Well, the PlatformID needed to specify the destination platform is built using the AID of the destination AMS agent. You can add to this AID the transport address of the destination platform corresponding to the MTP that you want use. So the question is yes, you can use any MTP by simply specifying the correct transport address in the AMS AID used to build the destination PlatformID. About your first qüestion, this is an old problem. There is no mechanism like DNS in the agent's world providing a matching between agent AIDs and transport addresses of the platforms. If your MTP mandates that transport addresses are built using the destination IP, you must know it or implement a mechanism (for instance, by means of an agent, DF, ...) providing translation facilities. Regards.



Consulta

From: [email protected] [mailto:[email protected]] On Behalf Of Marcia Silvana Stippi Sent: lunedì 17 luglio 2006 14.54 To: [email protected] Cc: [email protected] Subject: [jade-develop] Question on AMS and ACC Hi Jaders !!! I have some consultations on the AMS and about the ACC. 1) In my application when an agent detects certain conditions need to say to him to the AMS that a new agent creates. I can do this sending a message to the AMS? If this is not possible... that another form I can create an agent without having to program a single agent so that makes that task ??? (it would be like having an agent single administrator for that!!!) 2)I found inconsistency between the information of some papers that I find of the JADE site: Law in "programmersguide" of JADE the following: "The Message Transport System, also called Agent Communication Channel (ACC), is the software component controlling all the exchange of messages within the platform, including messages to/from remote platforms" In another paper "Scalability and Performance of JADE Message Transport System" law that: "...ACC (Agent Communication Channel) that provides the Message Transport Service for FIPA ACL messages delivery between agents living into different agent platforms." .... "FIPA does not define nor require a specific protocol for intra-platform message delivery and each implementation can choose any IMTP (Internal Message Transport Protocol)." After seeing this I do not have left clear if the ACC is solely for communication Inter-platform... and also it would wish to know if the "Message Transport System" and the ACC are the same. They could indicate to me some to paper in where can find the correct information about this? Thank you very much, greetings. Marcia.

Respuesta

De: Caire Giovanni <[email protected]> Enviado el: Miércoles, 19 de Julio de 2006 07:03:28 a.m. Para: "Marcia Silvana Stippi" <[email protected]> CC: <[email protected]> Asunto: RE: [jade-develop] Question on AMS and ACC Hi, I'm not sure I have understood your problem. I assume you need to request the AMS to create a new Agent when a certain condition is met. If this is the case you can do that by sending a REQUEST message to the AMS requesting the CreateAgent action of the JADEManagementOntology (package jade.domain.JADEAgentManagement). The request must use the FIPA-SL language (jade.content.lang.sl.SLCodec) and must be in the scope of a fipa-request protocol.



You can find an example of how to request actions to the AMS in the GetAvailableLocationsBehaviour included in the examples.mobile package. As for the ACC and MTS it's just a matter of namings: you can see things as follows (I'm not a guru of FIPA specs and therefore I may say something not completely correct though) MTS = The system responsible for delivering messages (regardless of where receivers live) ACC = FIPA term indicating that part of the MTS responsible for delivering messages across different platforms. Bye. Giovanni

Consulta

From: [email protected] [mailto:[email protected]] On Behalf Of Marcia Silvana Stippi Sent: venerdì 11 agosto 2006 15.19 To: [email protected] Subject: [jade-develop] migration and RMI Hi Jaders!!! We are doing a project on mobile agents and we are particularly interested in how is migration performed in Jade platform (in low level). We read that Jade uses RMI to perform migration within the platform, and we want to know if RMI is used only to find the address of the target container (by using the rmiregistry) or if it is used to call a remote object method at the target container (instead of moving to it). In last case, could it be considered "migration"? Our question arose when reading the article "Agent Migration over FIPA ACL Messages" of Sergi Robles, which says: ... "JADE also provides mobility between containers. For this reason, if the agency is distributed in various machines, agents can move between them. However, accepting this type of mobility as migration could be considered a mistake. "Satellite" containers are highly dependent on the principal and many operations carried out by the agents within them end up passing through the central node. Furthermore, the connections between them (carried out by RMI) must be permanent, as if not, many errors due to the loss of link may be generated. As we can see, using this type of mobility as a typical migration ends up making mobile agent systems' scalability disappear because a certain type of operations is centralized in a single node. However, it may be very useful to use the diagram of containers to distribute the processing of agencies that have to bear a heavy load or to isolate some agency types within a single agency for security reasons." ... Is the main container a bottle neck? We know that there is an add-on (Inter-Platform Mobility Service) for Jade 3.4 which provides inter-platform mobility by sending the agents within ACL messages. The question is, this version uses the same system for migration within the platform or it continues to use RMI like in previous versions? Greetings... Carla Capart Marcia Stippi UNPSJB. Argentina



Respuesta

De: Caire Giovanni <[email protected]> Enviado el: Lunes, 21 de Agosto de 2006 12:38:36 p.m. Para: "Marcia Silvana Stippi" <[email protected]>, <[email protected]> Asunto: RE: [jade-develop] migration and RMI Hi, Let me try to clarify. 1) A JADE platform is composed of a set of containers. 2) Containers within a platform communicate using RMI. Why do containers have to communicate? In many cases: e.g. to transfer a message sent by agent A living in container C1 to agent B living in container C2, or when a container starts up to register with the Main Container, or when the AMS creates a new agent in a remote container... NOTE that Containers are RMI remote objects, while agents are NOT! 3) Different platforms communicates according to the FIPA specification. The latter only defines how to transport ACL messages between different platforms 4) Intra-platform mobility is when an agent moves between two containers of the same platform. 5) Inter-platform mobility is when an agent moves from a container belonging to platform A to another container belonging to a second platform B 6) In both cases it is real mobility as both the code and the status of the moving agent are transferred from the source container to the destination container. 7) In the case of intra-platform mobility the agent is serialized and then transferred invoking via RMI a remote method of the destination container. As a result the moving agent is deserialized on the destination container and it continues its execution from the exact point where it was interrupted on the source container. 8) In the case of inter-platform mobility, of course it is not possible to transfer the moving agent invoking a remote method (as happens between containers in the same platform) as different platforms can only exchange ACL messages --> The agent is serialized, the serialized agent is inserted into an ACL Message and that message is delivered to the AMS of the destination platform. The latter will extract the serialized agent from the message, deserialize it and restart its execution. Bye. Giovanni.

Consulta

From: [email protected] [mailto:[email protected]] On Behalf Of Marcia Silvana Stippi Sent: venerdì 27 ottobre 2006 2.39 To: [email protected] Subject: [jade-develop] run an agent on a existing container in a machine Hi Jaders!!! My doubt is the following one:



In an Intranet I have several raised containers one by machine; in each container there are agents running. I want that a user can run an agent (who has GUI) and that this agent sends itself on the existing container in the machine. Try to from within do it of an application. I proved the example inprocess and I investigated the classes Runtime and AgentContainer, but I did not find the way to make what I need, that is to say, detect as it is the container that exists in a machine to be able to send to the agent within him. On the other hand, I cannot either make it from line of commands, because with the option -container with himself unite me to the platform but creating a NEW container that is what nondesire. Somebody has some idea of like doing it? Thank you very much Greetings. Marcia.

Respuesta

De: Caire Giovanni <[email protected]> Enviado el: Martes, 31 de Octubre de 2006 09:57:06 a.m. Para: "Marcia Silvana Stippi" <[email protected]>, <[email protected]> Asunto: RE: [jade-develop] run an agent on a existing container in a machine Hi, I'm not sure I have understood what you are trying to do. If you need to create an agent locally and then move it to a container running on a remote machine, then you just have to call the doMove() method of the Agent class specifying the ContainerID of the destination container. Look at the examples.mobile.MobileAgent for an example. Bye. Giovanni.

Consulta

From: [email protected] [mailto:[email protected]] On Behalf Of Marcia Silvana Stippi Sent: lunedì 6 novembre 2006 17.02 To: [email protected] Subject: [jade-develop] Questions about AMSSubscriber behaviour Hi, we have some questions about the jade.domain.introspection.AMSSubscriber behaviour. We have an agent which, in its setup method, subscribes to the AMS to be notified about platform events and installs handlers for AddedContainer and RemovedContainer events. When testing the agent, we found out that it receives notifications about events occurred before the subscription message was sent and even before the agent was born, is that right or are we doing something wrong? (In particular, it receives notifications about the containers that have been added to the platform and have not been removed yet). What we need to confirm is: when an agent subscribes, the AMS notifies it about all the containers that already exist in the platform at that moment? We also noticed that sometimes the AMS sends notifications for the same event more than once, in which situations could happen this?



One last question: when does the AMS send a "meta-reset-events" notification? We hope somebody can help us, thanks! Bye... Carla Capart Marcia Stippi

Respuesta

De: Caire Giovanni <[email protected]> Enviado el: Martes, 07 de Noviembre de 2006 08:45:38 a.m. Para: "Marcia Silvana Stippi" <[email protected]>, <[email protected]> Asunto: RE: [jade-develop] Questions about AMSSubscriber behaviour Hi, When an agent subscribes to the AMS the AMS notifies it about the current situation: all containers and all agents existing in the platform at the time the subscription message is processed by the AMS. The meta-reset-event indicates that all information about containers and agents must be considered obsolete and therefore not valid anymore. It is sent in two situations: - As soon as an agent subscribes to the AMS (to reset any previous information) - When the main container recovers after a fault (see the Main Replication service in the administrator's guide). As for events sent more than once, this should never happen (unless a meta-reset event is sent in between). Can you be more specific about the situation in which you experience this duplication? Bye Giovanni

Consulta

From: [email protected] [mailto:[email protected]] On Behalf Of Marcia Silvana Stippi Sent: domenica 12 novembre 2006 1.10 To: [email protected] Cc: [email protected] Subject: RE: [jade-develop] run an agent on a existing container in a machine Hi, thanks for you help!!! My problem is that I cannot send a message to the AMS because I am within an application that is not an agent, thus I cannot use the method send. There is some way to send a message to the AMS that is not from an agent? Greetings...Bye Marcia.



Respuestas

De: Caire Giovanni <[email protected]> Enviado el: Lunes, 13 de Noviembre de 2006 02:18:55 p.m. Para: "Marcia Silvana Stippi" <[email protected]>, <[email protected]> CC: <[email protected]> Asunto: RE: [jade-develop] run an agent on a existing container in a machine Look at the jade.wrapper and jade.wrapper.gateway packages (javadoc and programmers guide). Bye Giovanni. From: "[email protected]" <[email protected]> To: Marcia Silvana Stippi <[email protected]> CC: jade-develop <[email protected]> Subject: RE: [jade-develop] run an agent on a existing container in a machine Date: Fri, 10 Nov 2006 15:47:27 -0700 Hello, about this question -- What I need is to create a new agent on a container that already exists in host. This message http://avalon.tilab.com/pipermail/jade-develop/2006q4/009630.html has some code which you can use to launch an agent, I think. Hope this helps, Robert Dodier


Bibliografía

Libros:

ANA MAS (2005). Agentes Software y Sistemas Multiagente: Conceptos, Arquitecturas y Aplicaciones. Pearson Educación S.A. España. 2005.

BRAUN, Peter y ROSSAK, Wilhelm (2005). Mobile agents. Basic concepts, mobility models, & the Tracy Toolkit. Elsevier Inc. USA. 2005. GOSPODNETIC, Otis y HATCHER, Erik (2004). Lucene in Action. Manning Publications. Canadá. 2004. TANENBAUM, Andrew S. y VAN STEEN, Maarten (2002). Distributed Systems Principles and Paradigms. Prentice Hall. USA. 2002. WOOLDRIDGE, Michael (2005). An introduction to Multiagent Systems. John Wiley & Sons Ltd. England. 2005.

Trabajos publicados en Internet:

ÁLVAREZ, Ángel Alonso, VILLAR FLECHA, José Ramón, BENAVIDES CUELLAR, Carmen, GARCÍA RODRÍGUEZ, Isaías y RODRÍGUEZ SEDANO, Francisco Jesús (2001). Experiencia en el desarrollo de un sistema multiagente. XXII Jornadas de Automática. España. 2001. URL: http://www.cea-ifac.es/actividades/jornadas/XXII/documentos/B_01_CI.pdf. Última fecha de acceso: 31/05/2006. AMETLLER, Joan y JORDI CUCURULL, Juan. Inter-Platform Mobility Service HOWTO. España. URL: http://jade.cselt.it/doc/ Inter-Platform Mobility Service HOWTO.htm. Última fecha de acceso: 27/06/2006. AYRES DE MORAIS E SILVA, Leonardo (2003). Estudo e Desenvolvimento de Sistemas Multiagentes usando JADE: Java Agent Development framework. Monografia de Conclusão de Curso. Brasil. 2003. Última fecha de acceso: 19/01/2006.



BELLIFEMINE, F., CAIRE, G., POGGI, A. y RIMASSA, G (2003). JADE a white paper. Septiembre 2003. URL: http://exp.telecomitalialab.com/articolo.asp. Última fecha de acceso: 26/12/2005. CAIRE, Giovanni, VAN AART, Chris, PELS, Ruurd, BERGENTI, Federico. Creating and Using Ontologies in Agent Communication. Última fecha de acceso: 19/01/2006. CANTÚ, Francisco Javier. Agentes autónomos. URL: http://www-cia.mty.itesm.mx/~fcantu/sisaut/autonomos.html. Última fecha de acceso: 24/06/2005. CORTESE, E., QUARTA, F., VITAGLIONE, F. Scalability and Performance of JADE Message Transport System. Telecom Italia LAB. URL: http://jade.cselt.it/doc/Scalability and performance of JADE STM.pdf. Última fecha de acceso: 04/07/2006. CUESTA MORALES, Pedro. Sistemas multiagente. Departamento de Informática. Universidad de Vigo. España. URL: http://trevinca.ei.uvigo.es/~pcuesta/sm/. Última fecha de acceso: 29/04/2005. CHEVALIER DUEÑAS, Griselda Alejandra (2000). Agentes móviles para la recuperación personalizada de información. Tesis Licenciatura en Sistemas Computacionales. Universidad de las Américas-Puebla. México. 2000. URL http://www.udlap.mx/~tesis/navegacion/carrera_lis.html. Última fecha de acceso: 21/04/2005. DE GROOT, David R.A. (2004). Cross-Platform Generative Agent Migration. An Agent Factory Approach. Tesis de Maestría. Intelligent Interactive Distributed Systems. Computer Systems Section. Department of Computer Science. Faculty of Sciences. Vrije Universiteit Ámsterdam. The Netherlands. Enero 2004. EXPOSITO, Jose A., AMETLLER, Joan y ROBLES, Sergi (2003). How to use the new HTTP MTP with JADE. Octubre 2003. URL: http://jade.cselt.it/doc/How to use the new HTTP MTP with JADE.htm. Última fecha de acceso: 27/06/2006. FRANKLIN, Stan y GRAESSER, Art (1996). Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents. Third International Workshop on Agent Theories, Architectures, and Languages. Springer-Verlag. 1996. URL: http://www.msci.memphis.edu/~franklin/AgentProg.html. Última fecha de acceso: 23/06/2005.



GARIJO, Francisco (2002). Tecnología de agentes: Experiencias y perspectivas para el desarrollo de nuevos servicios y aplicaciones. Boletic Nº 24, España, Noviembre - Diciembre 2002. URL: http://www.astic.es/nr/astic/boletic-todos/boletic24/artimono5.pdf. Última fecha de acceso: 04/08/2006. GIRET, Adriana, INSFRÁN, Emilio y PASTOR LUCA, Oscar (2000). OO-METHOD para el desarrollo de Sistemas de Agentes. España. 2000. URL: http://www.aepia.dsic.upv.es/ Última fecha de acceso: 04/08/2006 GÓMEZ LABRADOR, Ramón M. (1999). Agentes móviles y Corba. Departamento de Lenguajes y Sistemas Informáticos. Universidad de Sevilla. España. Febrero 1999. URL: http://www.informatica.us.es/~ramon/tesis/CORBA/Seminario-MASIF/. Última fecha de acceso: 24/06/2005. GÓMEZ SANZ, Jorge J. (2003). Metodologías para el desarrollo de sistemas multiagente. Revista Iberoamericana de Inteligencia Artificial. Nº 18, pp. 51-63. España. 2003. Última fecha de acceso: 17/06/2005. HOWER ,Chad Z. (2005). Mobile Agents - Software on the move. Julio 2005. URL: http://www.codeproject.com/gen/design/MobileAgents.asp. Última fecha de acceso: 31/05/2006. LUCK, Michael, MC.BURNEY, Peter, SHEHORY, Onn, WILLMOTT, Steve and the AgentLink Community (2005). Agent Technology Roadmap. A Roadmap for Agent Based Computing. 2005. URL: http://www.agentlink.org/roadmap/index.html. Última fecha de acceso: 31/05/2006. NIKRAZ , Magid, CAIRE, Giovanni y BAHRI, Parisa A. (2006). A Methodology for the Analysis and Design of Multi-Agent Systems using JADE. International Journal of Computer Systems Science & Engineering. Mayo 2006. URL: http://jade.cselt.it/doc/JADE_methodology_website_version.pdf. Última fecha de acceso: 27/06/2006. RIGOTTI, Guillermo. Infraestructura de comunicación para sistemas de agentes móviles. UNICEN. Facultad de Ciencias Exactas. ISISTAN. Argentina. URL: http://www.spc.org.pe/clei2004/es/skin.php?menu=70&source=html/303/index.html. Última fecha de acceso: 31/05/2006. ROSAS OLIVOS, Erika (2005). Agentes móviles. Sistemas distribuidos. Junio 2005. URL: http://www.inf.utfsm.cl/~rmonge/sd/trabajos/rosas-agentes.pdf Última fecha de acceso: 31/05/2006.



SANZ, Jorge Gómez y MESTRAS, Juan Pavón (2001). Análisis y diseño de sistemas multiagente. Dep. Sistemas Informáticos y Programación .Universidad Complutense Madrid. España. 2001. URL: http://grasia.fdi.ucm.es/jpavon/agentes/admas.pdf Última fecha de acceso: 17/06/2005. SUNDSTED, Todd (1998). Agents on the move. Artículo How-To Java. Enero 1998. URL: http://www.javaworld.com/javaworld/jw-07-1998/jw-07-howto.html. Última fecha de acceso: 25/08/2006. SUNDSTED, Todd (1998). Agents talking to agents. Artículo How-To Java. Enero 1998. URL: http://www.javaworld.com/javaworld/jw-09-1998/jw-09-howto.html. Última fecha de acceso: 25/08/2006. VIDAL ROJAS, Juan Carlos. Agentes móviles de recuperación de la información en la web. Chile. URL: http://www.dcc.uchile.cl/~jcvidal/Agentes/AgentesWeb.html. Última fecha de acceso: 03/05/2006. YÁGÜEZ, Javier. Arquitecturas y Middleware de Comunicaciones. Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software. Facultad de Informática. Universidad Politécnica de Madrid. España. URL: halley.ls.fi.upm.es/~jyaguez/pdfs/Agentes.pdf. Última fecha de acceso: 25/08/2006. Sitios de internet: European Commission's IST-funded Coordination Action for Agent-Based Computing. URL: http://www.agentlink.org FIPA: Foundation for Intelligent Physical Agents. URL: http://www.fipa.org/ INGENIAS: Metodología para el desarrollo de sistemas multiagentes. URL: http://grasia.fdi.ucm.es/ingenias/Spain/index.php JADE: Java Agent Development framework. URL: http://jade.cselt.it/ LUCENE: API que permite agregar capacidades de búsqueda a las aplicaciones. URL: http://lucene.apache.org/ Portal de agentes y sistemas multiagente. Universidad de Vigo. URL: http://agentes.ei.uvigo.es TRACY: toolkit para la ejecución de agentes de software. URL: www.mobile-agents.org

Agentes de software móviles: un paradigma alternativo para … · 2011. 6. 2. · 2.5.1 Los...

Documents

Transcript of Agentes de software móviles: un paradigma alternativo para … · 2011. 6. 2. · 2.5.1 Los...