Agentes Inteligentes: JADE

Juan Fco. Garamendi Bragado

Programa de Doctorado: Informática y Modelización Matemática
Universidad Rey Juan Carlos

Abril 2004
Índice
1. Introducción 1

2. Tecnología 1
2.1. Topología: Cliente-Servidor frente a Peer-to-peer . . . . . . . . 1
2.1.1. Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . 1
2.1.2. Peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.3. Híbridas . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. FIPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. JADE 3
3.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. LEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Programación de Agentes en JADE . . . . . . . . . . . . . . . 7
3.3.1. Comportamientos . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Comunicación . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Entorno de ejecución . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Interfaz RMA . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Agente Dummy . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3. Interfaz DF . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.4. Agente Sniffer . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.5. Agente Instrospector . . . . . . . . . . . . . . . . . . . 14

4. Razones para el uso de JADE 15

i
1. Introducción
JADE (Java Agent DEvelopment Framework) es un middleware que pro-
porciona tanto un entorno de desarrollo como un entorno de ejecución para
la realización y mantenimiento de sistemas multiagente.
El entorno de desarrollo está formado por una serie de librerías en Java
que permiten la implementación de agentes de manera limpia e independiente
de la plataforma sobre la que se va a ejecutar.
El entorno de ejecución permite a los agentes vivir y comunicarse entre
ellos. Está realizado enteramente en Java y proporciona una serie de her-
ramientas que permiten al desarrollador controlar y depurar a los agentes en
tiempo real.
Este trabajo es una síntesis de los artículos presentes en las referencias y
de la experiencia del autor en el entorno de ejecución y pretende proporcionar
una visión de JADE. En ningún momento se quiere que sea un manual de
programación ni un manual de las herramientas gráficas, para ello está la
documentación que proporciona JADE: http://sharon.cselt.it/projects/jade/
donde también se encontrará la última versión del entorno.
El trabajo se divide en tres partes. La primera ("Tecnología") muestra
la tecnología sobre la que se asienta JADE. La segunda ("JADE")explica
la arquitectura de JADE y los entornos de desarrollo junto con el entorno de
ejecución y por último, a modo de conclusión se dan unas ventajas del uso de
JADE para el desarrollo de sistemas multiagente ("Razones para el uso
de JADE").

2. Tecnología
2.1. Topología: Cliente-Servidor frente a Peer-to-peer
2.1.1. Cliente-Servidor
El modelo cliente-servidor está basado en una clara distinción de actua-
ciones a seguir entre los nodos denominados cliente y los denominados servi-
dor. Los nodos servidor ofrecen servicios y recursos pero no pueden tomar la
iniciativa en la comunicación. Por el contrario, los nodos cliente son los que
toman la iniciativa, acceden y usan los servicios que ofrecen los servidores.
Los clientes pueden comunicarse con los servidores pero no pueden co-
municarse directamente con otros clientes, y los servidores no pueden comu-
nicarse con los clientes hasta que estos establecen la comunicación. Por esta
razón, los clientes deben conocer de la existencia de los servidores pero no
necesitan saber nada de otros clientes.

1
2.1.2. Peer-to-peer
En el modelo peer-to-peer (P2P), los nodos no toman ningún tipo de
tarea en concreto, es decir, un nodo puede actuar de cliente como de servidor.
Cada nodo puede iniciar la comunicación con otro nodo, pedir un servicio
o ser requerido para un servicio. En el modelo P2P es necesario que los
nodos tengan mecanismos para conocer la existencia de otros nodos y de los
servicios que ofrecen, esto es lo que se denomina recursos de páginas blancas
y páginas amarillas.

2.1.3. Híbridas
En la arquitectura P2P, el hecho de no existir ningún nodo de referencia
dificulta la localización de nodos activos. La arquitectura híbrida alivia esta
situación ya que debe existir algún nodo que proporcione ciertos servicios, y
entre ellos el de búsqueda.

(a) Cliente servidor (b) Peer to Peer

(c) Híbrida

Figura 1: Diferentes arquitecturas de redes.

2
2.2. FIPA
FIPA (Foundation for Intelligent Physical Agents) es una organización
que se encarga de desarrollar especificaciones estándar para los sistemas basa-
dos en agentes. Con esto se pretende facilitar la interconexión entre platafor-
mas de diferentes empresas y organizaciones. El objetivo de FIPA es definir la
interoperabilidad entre los sistemas basados en agentes, dejando fuera la im-
plementación interna. Define el modelo de una plataforma basada en agentes,
el conjunto de servicios que debe proveer y la interface entre los servicios.

3. JADE
JADE es un middleware desarrollado por TILAB para el desarrollo de
aplicaciones distribuidas multiagente. JADE proporciona tanto el entorno de
desarrollo para la creación de aplicaciones basadas en agentes como el entorno
de ejecución.
JADE presenta las siguientes características:

P2P: Arquitectura peer-to-peer, cada agente puede tomar la iniciativa

en una comunicación o bien responder a peticiones que le hagan otros
agentes.

Interoperabilidad: JADE cumple con las especificaciones FIPA, por lo

que los agentes desarrollados en JADE pueden interactuar con otros
agentes que no tienen porque estar desarrollados con JADE, aunque si
deben seguir las especificaciones FIPA.

Portabilidad La API que proporciona JADE es independientemente de

la red sobre la que va a operar, así como de la versión de Java utilizada,
teniendo la misma API para J2EE, J2SE y J2ME.

Intuitiva: JADE se ha desarrollado para ofrecer una API fácil de apren-

der y sencilla de manejar.

Los agentes JADE tienen nombres únicos y se permite a cada agente descubrir
a otros agentes y comunicarse con ellos mediante comunicaciones punto a
punto. Los agentes proporcionan servicios, cada agente puede buscar a otros
dependiendo de los servicios que proporcionen otros agentes.
La comunicación entre agentes se lleva a cabo a través de mensajes asín-
cronos, es decir, el agente que envía el mensaje y el destinatario del mensaje
no tienen porqué estar disponibles al mismo tiempo. Es más, el destinatario
no tiene porqué existir en ese instante. Los mensajes se pueden enviar a un

3
agente en concreto o se pueden enviar a agentes que se desconocen pero se
sabe que poseen unas ciertas características. JADE proporciona mecanismos
de seguridad, ya que habrá agentes a los que no se les esté permitido comu-
nicarse con otros agentes, de manera que una aplicación puede verificar la
identidad del receptor y del agente que envía el mensaje y no dejar realizar
actuaciones no permitidas para un determinado agente. La estructura de los
mensajes se basa en el lenguaje ACL (Agent Communication Lenguaje) que
ha sido definido por la FIPA.
JADE también permite a los agentes cambiar de Host (en J2SE). Un
agente puede interrumpir en un momento dado su ejecución, migrar a otro
host (sin necesidad de que el código esté previamente en el host destino)
y continuar la ejecución en el mismo punto en el que la interrumpió. Esto
permite un balanceo de carga ya que permite a los agentes migrar hosts
menos cargados.
El entorno de ejecución proporciona un marco donde poder ejecutar los
agentes y herramientas gráficas para su monitorización y depuración.

3.1. Arquitectura
Los agentes JADE necesitan del entorno de ejecución donde poder "vivir".
Cada instancia del entorno de ejecución se denomina contenedor (contain-
er). Al conjunto de los contenedores se le denomina plataforma (platform) y
proporciona una capa que oculta a los agentes (y al desarrollador) el entorno
donde se ha decidido ejecutar la aplicación.
En cada plataforma debe existir un contenedor especial denominado con-
tenedor principal (main container). La principal diferencia del contenedor
principal respecto al resto de contenedores es que alberga dos agentes espe-
ciales:

AMS (Agent Management System): Este agente proporciona el servi-

cio de nombres asegurando que cada agente en la plataforma disponga
de un nombre único. También representa la autoridad, es posible crear y
matar agentes en contenedores remotos requeriendoselo al agente AMS.

DF (Directory Facilitator): Proporciona el servicio de Páginas Amar-

illas. Gracias al agente DF, un agente puede encontrar otros agentes
que provean los servicios necesarios para lograr sus objetivos.

La arquitectura se puede observar en la figura 2, donde aparecen dos

plataformas diferentes (platform1 y platform2), cada una con sus contene-
dores principales y contenedores normales.

4
 Figura 2: Esquema de distribución de los containers y las plataformas.

3.2. LEAP
Los agentes escritos en JADE pueden ejecutarse en entornos móviles co-
mo teléfonos o PDAs integrando las redes inalámbricas junto con las redes
convencionales. El problema es que JADE no puede correr en pequeños dis-
positivos debido a diversas razones:
Espacio: La memoria necesaria para el entorno de ejecución es de
varios megas.

Version del JDK: JADE necesita el JDK 1.4 o posterior, mientras

que la mayoría de los dispositivos solo soportan PJava (Personal Java)
o bien MIDP.

Características propias de las redes inalámbricas: Como son IP

dinámicas, conectividad intermitente o bajo ancho de banda, hace que
JADE no sea lo apropiado.
Para ello surge LEAP (Lightweight Extensible Agent Platform) que permite
ejecutar agentes JADE en dispositivos móviles y/o conectados a través de

5
redes inalámbricas.
Los container del entorno de ejecución de JADE-LEAP se dividen en dos
partes, un FrontEnd, que se ejecuta en el dispositivo móvil, y un BackEnd,
que se ejecuta en un servidor de la red fija, como se muestra en la figura 3.

Figura 3: Ejecución de dos agentes en dispositivos móviles y su arquitectura

vista en el RMA.
Este tipo de arquitectura ofrece una serie de ventajas:
El FrontEnd necesitará los recursos minimos.
La IP del dispositivo móvil va a permanecer oculta a otros containers.
Se va a permitir un control en la conexión entre el BackEnd y el Fron-
tEnd, de manera que si se produce una desconexión, entre el dispositivo
móvil y la red, no se va a producir una perdida de mensajes.
La cantidad de bytes transmitidos en la red inalámbrica es menor.
El tiempo de carga del programa es menor.
Aunque como contrapartida, no podremos crear agentes móviles.
Si ejecutamos el ejemplo que nos viene con el entorno JADE-LEAP (nece-
sitamos tener el kit de desarrollo Wireless Toolkit de Java, ya que propor-
ciona un emulador de dispositivos móviles) en el emulador proporcionado
por el WTK (Wireless Toolkit) podremos ver en la interfaz gráfica (figura 5)
del RMA los containers creados, los FrontEnd y los BackEnds lanzados. El
ejemplo proporcionado es una aplicación chat, en el que las personas pueden
chatear con sus telefonos móviles.

6
 Figura 4: Emuladores donde están corriendo agentes JADE.

3.3. Programación de Agentes en JADE

JADE ofrece al desarrollador las siguientes funciones y ventajas:

Ejecución distribuida.

Interfaz gráfica para monitorización y depuración de agentes, incluyen-

do los que se encuentran en hosts remotos.

Creación de agentes móviles.

Ejecución de actividades en paralelo, según el paradigma de behaviours.

Cumple con las especificaciones FIPA.

Intercambio de mensajes ACL entre agentes.

Registro automático de agentes (via AMS).

Servicio de nombres.

El kit de desarrollo proporcionado por JADE cuenta con las clases nece-
sarias para la creación de agentes. Un agente simplemente es una clase que
hereda de la clase jade.core.Agent. Existen dos métodos que hay que ree-
scribir:

7
Figura 5: Ejecución de dos agentes en dispositivos móviles y su arquitectura
vista en el RMA.

setup(): En este método se deben definir las inicializaciones corre-

spondientes a nuestro agente ya que se invoca nada mas comenzar la
ejecución de este.

takeDown(): Este método es invocado cuando se da por finalizada la

ejecución del agente por lo que se debe realizar las tareas de limpieza
de memoria. Se da por finalizado la ejecución de un agente cuando se
llama al método doDelete().

JADE facilita mecanismos para el desarrollo de los objetivos que deben

alcanzar los agentes: Los comportamientos (behaviours) y la comunicación
entre los agentes (junto con el servicio de páginas amarillas) proporcionan
los recursos necesarios para programar un sistema multiagente. El esquema
básico de un agente lo tenemos en la figura 6, que representa el flujo de
control de un agente básico: Inicialización, realización de la tarea y limpieza
y finalización.

8
Figura 6: Flujo de ejecución de un agente básico en JADE. Los métodos
setup(), y takedown() del agente deben se rescritos, así como action() y done()
de cada comportamiento.

3.3.1. Comportamientos
Un comportamiento es un conjunto de acciones que debe tomar el agente
para lograr su objetivo. Los comportamientos se implementan como un objeto
de la clase jade.core.behaviours.Behaviour. Los objetos Behaviour describen
pequeñas tareas que debe realizar el agente ejecutándose según un planifi-
cador que se encuentra implementado en la clase Agent. El planificador va eje-
cutando según una política round-robin los objetos behaviour que se encuen-
tran en una cola FIFO, existiendo dos métodos, addBehaviour(behaviourObjebct)
y removeBehaviour(behaviourObject), que permiten gestionar la entrada y
salida de los objetos behaviour en la cola del planificador.
Los objetos behaviour tienen dos métodos que se deben reescribir, action()
y done(). El método action() es en donde se deben desarrollar las tareas que
debe realizar el agente, mientras que el método done() es llamado cuando
action() finaliza. El planificador va ejecutando uno a uno los métodos action()
de la cola y cuando el método action() de un objeto finaliza se llama al

9
método done(), este debe retornar un booleano, si retorna true, el objeto es
sacado fuera del planificador ya que se da por concluida su tarea, mientras
que si retorna false se vuelve a planificar.
Si en algún momento de la ejecución del método action() se requiere
esperar por la llegada de un mensaje, existe el método block() para mandar
a una cola de bloqueados cuando el método action() finaliza (no cuando
se llama a block()). Cuando se produce la llegada de un mensaje, todos los
objetos en la cola de bloqueados se planifican y deben comprobar si el mensaje
llegado es para ellos o no. En caso de que un objeto no sea el destinatario
del mensaje debe volver a bloquearse.
Es importante que los métodos action() sean cortos, de esta forma se
permite un cierto grado de paralelismo. Si se necesita realizar una tarea que
va a requerir un largo periodo de tiempo, entonces el desarrollador deberá
dividir la tarea en subtareas y cada una de ellas implementarla mediante un
objeto behaviour. Con el fin de ayudar en esta labor, JADE proporciona una
jerarquía de clases Behaviour, que nos permitirán hasta simular Máquinas de
Estados Finitos.

Clase SimpleBehaviour: Representa un comportamiento atómico.

Clase OneShotBehaviour: Representa un comportamiento que se

debe ejecutar solo una vez, por eso, su método done() retorna true, si
no es redefinido.

Clase CyclicBehaviour: Representa un comportamiento que debe

ejecutarse una serie de veces. El método done, si no es redefinido, de-
vuelve false.

Clase CompositeBehaviour: Esta clase se compone de diferentes

sub-behaviours que se pueden ejecutar siguiendo diferentes políticas de
planificación. Las diferentes políticas vienen determinadas por la sub-
clase elegida, SequentialBehaviour, ParallelBehaviour y FSMBehavior.

Clase SequentialBehaviour: Esta clase deriva de CompositeBe-

haviour y ejecuta sub-behaviours de forma secuencial, y termina cuando
todos los métodos action() han terminado.

Clase ParallelBehaviour: Esta clase deriva de CompositeBehaviour

y ejecuta los sub-behaviours de manera concurrente. En el constructor
de la clase se puede especificar cuando se desea que acabe la ejecución:
cuando todos los sub-behaviours lo han hecho, cuando uno termine, o
cuando un número especificado lo logre.

10
 Clase FSMBehaviour: Esta clase permite definir una Máquina de
Estados Finita mediante sub-behaviours. Cada sub-comportamiento
representa un estado de la máquina, y las transiciones se van producien-
do según la salida de dichos estados. La finalización se alcanza cuando
se termine de ejecutar algún sub-behaviour que se haya registrado como
estado final.

Clase SenderBehaviour: Encapsula la acción de envío de un men-

saje ACL. Este mensaje se le debe especificar en el constructor.

Clase ReceiverBehaviour: Encapsula la acción de recepción de un

mensaje ACL. Termina cuando se recibe el mensaje o cuando pasa una
cierta cantidad de tiempo especificada en el constructor.

Clase WakerBehaviour: Implementa un comportamiento OneShot

que se ejecuta justo después de que se haya pasado un tiempo especi-
ficado.

3.3.2. Comunicación
La comunicación entre los agentes es una de las mas importantes car-
acterísticas que aporta JADE. Se basa en un modelo de paso de mensajes
asíncrono. Cada agente tiene un buzón en el cual se van almacenando los
mensajes enviados por otros agentes. Cuando llega un mensaje nuevo, se le
notifica al agente que lo ha recibido para que lo procese.
Los mensajes intercambiados entre los agentes siguen un formato concreto
que ha sido definido por la FIPA denominado ACL. El formato ACL define
los diversos campos que debe constar un mensaje:

sender: El remitente del mensaje.

receivers: La lista de destinatarios.

performative: El objetivo de la comunicación. El remitente debe in-

dicar si la intención de la comunicación que se va a establecer es comu-
nicar un suceso al destinatario (INFORM ), solicitar que el destinatario
realice una acción determinada (REQUEST ), preguntar por una condi-
ción (QUERY-IF ), o establecer una comunicación algo mas compleja
(CFP1 , PROPOSE, ACCEPT_PROPOSAL, REJECT_PROPOSAL)

content: El contenido del mensaje.

1
Call For Proposal

11
 language: El tipo de sintaxis utilizado en content.

ontology: El diccionario de símbolos usados en content.

Campos de control usados para controlar conversaciones concurrentes

y timeouts.

Los mensajes son implementados como objetos de la clase jade.lang.acl.ACLMessage

y proporciona métodos get y set para acceder a los diversos campos de un
mensaje.

3.4. Entorno de ejecución

La característica mas importante del entorno de ejecución es la interfaz
gráfica que proporciona, desde la que podemos controlar y depurar los agentes
existentes. Todas las herramientas han sido desarrolladas como agentes y
siguen sus mismas reglas.

3.4.1. Interfaz RMA

El agente RMA (Remote Monitoring Agent) permite controlar al resto de
agentes en una plataforma. Provee una interfaz gráfica (figura 5) que facilita
las funciones de monitorización y control. Solo puede existir un agente RMA
por container, aunque puede haber varios por plataforma.
La interfaz gráfica permite las siguientes acciones, todas ellas llevadas a
cabo a través de un sistema de menús:

Terminar la ejecución del agente RMA (se invoca al método doDelete()).

Terminar con la ejecución del agente RMA y de todos los agentes del
container donde se encuentre RMA.

Terminar con la ejecución de la plataforma en la que se encuentra.

Comenzar un nuevo agente.

Terminar con la ejecución agentes. La terminación se realiza interna-

mente llamando al método doDelete().

Detener la ejecución de los agentes. Internamente se realiza una llamada

al método doSuspend.

Continuar la ejecución de agentes suspendidos. Los pone en estado

Activo y llama al método doActivate().

12
 Mandar un mensaje (formato ACL) a agentes seleccionados. Esta fun-
ción se realiza mediante un cuadro de diálogo en el cual se tendrán que
rellenar los campos del mensaje.

Migrar un agente de un contenedor a otro.

Clonar un agente, introduciendo el nombre del nuevo agente y el con-

tainer donde se encontrará.

3.4.2. Agente Dummy

Figura 7: Interfaz gráfica del agente Dummy.

El agente Dummy (figura 7) permite interactuar con otros agentes. Pro-

porciona un interfaz gráfico que nos permite construir mensajes ACL, man-
darlos, almacenarlos (también los que nos envíen a nuestro agente Dummy),
y verlos en detalle.

3.4.3. Interfaz DF
El agente DF, Directory Facilitator, proporciona también una interfaz
gráfica, figura 8. Este Agente es el que provee los servicios de Páginas Amar-
illas. A través de la interfaz gráfica se pueden ver descripciones de los agentes
registrados, registrar y quitar agentes, buscar descripciones y modificarlas.

13
 Figura 8: Interfaz gráfica del agente DF.

A través de la GUI también podemos combinar nuestro DF con otros DF y

crear dominios y subdominios de páginas amarillas.

3.4.4. Agente Sniffer

Gracias al agente Sniffer (figura 9) se pueden monitorizar todos los men-
sajes que un agente, o un grupo de ellos, intercambian. Existen opciones para
poder monitorizar mensajes con un performative exclusivo.

3.4.5. Agente Instrospector

Permite monitorizar la ejecución de un agente, y los mensajes intercam-
biados por este. También permite la monitorización de sus comportamientos

14
 Figura 9: Interfaz gráfica del agente sniffer.

y la ejecución paso a paso de estos.

4. Razones para el uso de JADE

Una pregunta que puede surgir es el por qué de usar JADE para desarrol-
lar sistemas multiagente. La razón fundamental es porque es un middleware
que oculta una arquitectura distribuida donde va a residir la aplicación, per-
mitiendo al desarrollador centrarse solo en el aspecto lógico dejando de lado
el desarrollo de las comunicaciones entre los diferentes hosts. En [2] se da
además una de razones por las que es aconsejable usar JADE:

JADE simplifica la comunicación y la cooperación entre los agentes,

que tienen de forma distribuida la lógica de control para alcanzar el
objetivo de la aplicación.

Los agentes JADE pueden controlar su propio ciclo de vida, y pueden

15
 Figura 10: Interfaz gráfica del agente introspector.

ser programados para que dejen de funcionar o empiecen a hacerlo

dependiendo del estado del sistema y de la función que debe realizar el
agente.

JADE cumple con la especificación de FIPA, luego puede comunicarse

con agentes realizados en otros entornos que sigan FIPA.

Es código abierto. Multitud de personas colaboran en la realización y

mantenimiento de JADE. La evolución de JADE es controlada por el
JADE Governing Board, para que su crecimiento no se realice de forma
desordenada.

Los agentes JADE pueden correr en las diferentes versiones de Java:

J2EE, J2SE y J2ME.

El API proporcionado por JADE es intuitivo, fácil de aprender y sen-

cillo de usar, haciendo que el desarrollo se produzca de manera mas
rápida que si no se utilizase.
Por estas características, los principales campos de aplicación son:

16
 Aplicaciones móviles: Facilita la búsqueda y procesamiento de la
información.

Internet: Desarrollo de aplicaciones P2P.

Referencias
[1] G. Caire. "JADE Tutorial: JADE programming for Beginners". CSELT
S.p.A. y TILab S.p.A.. Disponible en [6].

[2] F. Bellifemine, G. Caire, A. Poggi, G. Rimassa. "JADE, a White Paper".

EXP- Volume3 - n3- September 2003. Disponible en [6].

[3] F. Bellifemine, G. Caire, T. trucco, G. Rimassa. "JADE Administrator’s

guide". CSELT S.p.A. y TILab S.p.A.. Disponible en [6].

[4] F. Bellifemine, G. Caire, T. trucco, G. Rimassa. "JADE Programmer’s

GUIDE". CSELT S.p.A. y TILab S.p.A.. Disponible en [6].

[5] G. Caire. "LEAP User Guide". TILab S.p.A.. Disponible en [6].

[6] Sitio Web de JADE. http://jade.tilab.com

17