Skip to content

New Website

This Page is no longer maintained or updated.

Please update your bookmarks to

www.sebastianrodriguez.com.ar

Holons and Agents

Holonic Multi-Agent Systems are being the subject of more and more research. However, in the research community a recurrent question comes to mind: How are holons related to agents?

Most certainly, different answers to this question can be given according to how holons are seen. However I will try to define the difference (if any) between Agents and mine view of Holons.

Holons are, by definition, composed of other holons while agents are not necessarily composed of other agents. This does not mean that agents can not be composed of agents, but that “agents are atomic entities” is the general assumption. Indeed, as pointed out by Gasser, almost all the proposals for agent architectures have not addressed the general problem of how to treat collections of “agents” as higher-order entities, for example, how to treat organizations as agents. Holonic MAS represent an attempt to tackle this problem.

The idea of holonic agents, or simply holons, has been in the mind of researchers for a long while now. Ferber discusses about individual and collective agents; Marcenac uses intermidiate agents to detect earthquakes; Correa proposed recursive or intermidiate agent between the reactive (lower level) and cognitive (upper level) agents; etc. All of these are only examples of the how researchers have called these “aggregated” entities, that are composed of lower level agents.

So, if holons and agents are so close, why introduce a new term for them? Well, holons simply ensure the correct interpretation. When we say holon, we know immediately that the entity is composed of other holons and is a part of a higher super-holon.

We must yet make the difference between how holons are seen in Holonic Manufacturing Systems and in Holonic Multi-Agent Systems. Schillo points out clear differences between two views of holons:

  • Modelling recursion of agent grouping is an integral part of holonic multi-agent systems. Depending on the complexity of the tasks at hand, holonic agents can engage in complex nested structures of arbitrary depth. This is not the case for holonic manufacturing systems, in which a holon is usually composed of a simple physical entity (production unit) and a software controller assigned to this entity.
  • Holonic manufacturing systems make no assumption about the internal architecture of a holon, it is only required to act as the control unit. However, for holonic multi-agent systems the holon is required to possess agent properties \citep{wooldridge95}
  • The holons in holonic multi-agent systems are not required to coordinate the work of a physical resource, but instead may coordinate the work of several information agents that only exist virtually. For instance, information agents may collaborate for the increase of efficiency, to combine competencies or resources, to resolve bottlenecks, etc.
  • Holonic manufacturing systems use a market metaphor to design inter-holon coordination. Research on holonic multi-agent systems is also concerned with choosing long-term partners as well as researching the diversity of possible organizational structures.

Even with these differences between MAS and Manufacturing Systems views of holons, many of the models proposed for Holonic Manufacturing Systems (HMS), can be adapted to HMAS.

Holons and Agents are in fact from a MAS point of view the same type of entities. The term holon is only a way of making explicit the composition of agents into higher level agents.

See also Hierarchical MAS and Holnic MAS.

This post is an adaptation of a section in my Ph.D. Thesis - please refer to the thesis for bibliography.

Tagged , , ,

SIWN keynote presentation

I’ve added to the publications section the slides of my keynote presentation. I know it is not a publication at all, but I wanted to make the presentation available, so I have to put it somewhere, right?

Tagged ,

SIWN Congress

So the SIWN 2008 conference is over. It was a great event! I had the chance to meet a lot of VERY interesting people. It offered me the possibility to meet researchers from other fields not necessarily associated with MAS research however with topics, concerns and interests similar to mine.

A great number of possible research colaborations (and friends!) emerged from this conference, so… what else can I ask from a conference?

I also want to congratulate Professor Tianfield for the great organization in this conference, everythings went better than expected.

Tagged ,

Keynote talk at 2008 SIWN Congress

I’ve been invited to give a keynote speech at the 2008 SIWN Congress in Glasgow, UK - 22-24 July 2008.

I will be presenting an organizational metamodel for Holonic MultiAgent Systems and self-organization mechanisms for HMAS.

I hope to see you there!

Tagged ,

Create a zip distribution of a netbeans rcp with maven

The nbm-plugin lets you compile and cluster netbeans modules and suites. It’s pretty simple to get it up and running. However, the nbm plugin does not support a “zip-distribution” goal.

This can be achieved using the assembly plugin. It will gather all launchers, config files and the modules and zip them.

So let imagine we have an application where the suite is called “mysuite”. In the suite we’ll have to configure the assembly plugin, add the following to your pom.xml:

 
  ....
 
                maven-assembly-plugin
 
                        src/main/assembly/distribution.xml

Create a assembly descriptor in src/main/assembly named distribution.xml :

<!--?xml version="1.0" encoding="UTF-8"?-->
 
    bin
 
zip
 
        <!-- Launchers -->
 
            ${netbeans.install}/harness/launchers/app.sh
            bin/
            ${project.name}
 
            ${netbeans.install}/harness/launchers/app.exe
            bin/
            ${project.name}.exe
 
            ${netbeans.install}/harness/launchers/app_w.exe
            bin/
            ${project.name}_w.exe
 
        <!-- etc directory stuff -->
 
            ${netbeans.install}/harness/etc/app.conf
            etc/
            ${project.name}.conf
 
            src/main/assembly/netbeans/mysuite.clusters
            etc/
            ${project.name}.clusters
 
        <!-- Your app's cluster-->
 
            ${project.build.directory}/netbeans_clusters/${project.name}
            mysuite
 
                **/**
 
        <!-- netbeans' platform-->
 
            ${netbeans.install}/platform8
            platform8
 
                **/**

In this descriptor I’m assuming your suite’s name is the same as your project’s name and you defined a property “netbeans.install” that points to installation directory of netbeans. I am using netbeans 6.1, if you are using 6.0 you will have to change plaform8 for platform7 in the last part of the assembly descriptor.

In line 31 we copy a file that you should create and include the clusters of your application. For this example the file should only contain one line with the name of our suite (mysuite).

After you create the mysuite.clusters files in the right place, you are all set. To create your zip distribution you simply run:

$mvn clean install nbm:cluster assembly:assembly

If everything works fine you should find a “mysuite-1.0-SNAPSHOT-bin.zip” file in your target directory. Now you can copy that file anywhere you what, unzip it and run you RCP application.

Of course your “netbeans.install” property could be defined using profiles if you are using Continuum or any other CI server.

I hope this was useful. Happy coding.

Tagged , ,

Building a netbeans RCP web service client with maven

Recently I tried netbeans RCP platform for the first time. I’ve been working with eclipse RCP for a couple of years now, but a friend recommended it to me so thought why not give it a try?

It all worked fine so let’s spice it a little bit!!

Now I want to build my netbeans RCPs with maven. After a little googling I found the nbm plugin. After a few minor complications understanding where to put each thing according to the “maven way” and the new plugin, it all worked fine.

The idea is to build an RCP client for a web service application. The application is a traditional web service, developed as usual with maven and cxf. The java code for the client was generated using the cxf plugin for maven (wsclient). You create some tests, no problem. Even a new project including only the wsclient artifact as dependency and everything runs smoothly.

So now I want to use all that from a netbeans RCP. So I included my wsclient artifact as a dependency on my main module, launched my suite and… an exception?!? java.lang.ClassNotFoundException: javax.xml.ws.Service

This error only is present when using netbeans 6.0. If you move to 6.1 it all works perfectly.

Tagged , ,

Primeros pasos con Madkit

Introducción

Este tutorial esta destinado a aquellos que desean dar sus primeros pasos con MadKit. Es verdad que ya están los tutoriales propios a MadKit, el solo problema es que la mayoría de los documentos están en Ingles, y algunos en Francés.

En este documento no voy a entrar en detalles sobre que son los agentes o los sistemas multi-agentes (SMA). Para una (muy) buena discusión sobre el tema recomiendo libro de Jacques Ferber.

Este tutorial supone ciertos conocimientos previos:

  • Agentes
  • Java: No es necesario ser un experto en el tema para seguir el tutorial (de hecho, yo estoy muy lejos de serlo). Pero un comprensión básica de como compilar el código, que es el CLASSPATH, etc. son necesarios.
  • Madkit: Nada, justamente la idea es que nunca trabajaste con Madkit. Si ya desarrollaste sistemas con MadKit, este tutorial te va a parecer demasiado simple. Pero si estas a la busqueda de otros temas en madkit que no encontraste, mandame un mail… en una de esas puedo ayudar.

Instalación

En el momento de la ultima versión oficial es la 4 (hace apenas unos días). Existen varias formas de instalar Madkit:

  • Red: esta es la forma mas recomendada. Las razones son diversas, una de las primeras es que podes mantener la instalación al día. Supongo que la segunda es que podes instalar madkit por partes. Es decir, seleccionar los plugins que necesitas e instalarlos, sin necesidad de descargar todo un zip de mas de 20 Mb. Claro, el problema mas importe es que hace falta un conexión a internet pero supongo que se estas leyendo esto, no es tu problema ;).
  • Zip: También podes descargar un Zip e instalar apartir de este archivo. Este método también te permite mantener tu instalación al día. Pero cada vez hace falta descargar mas de 20 Mb., lo cual no es siempre evidente.
  • Fuentes: Madkit esta bajo GPL. Por lo tanto podes obtener las fuentes del madkit del cvs de sourceforge y compilarlas.

Para compilar las fuentes podes utilizar Apache Ant.
Sea cual sea el método que elijas, están descriptos en detalle en  la documentación del Plugin Manager
En el resto de este documento voy a considerar que el directorio de base de la instalación de Madkit es $MADKIT

Principios de MadKit

MadKit es una plataforma para la implementación de Sistemas Multi-Agentes. Esta basada sobre el modelo AGR de Ferber y Gutknecht. AGR en un modelo organizacional basado sobre los principios de Agente, Grupo y Rol.

Este documento no intenta ser una introducción a AGR, ni a los modelos organizacionales para los SMA. Pero vamos a describir solamente las bases para poder comprender el funcionamiento del SMA que vamos a desarrollar y el porque de ciertas elecciones.

El modelo AGR

El modelo AGR esta basado en las nociones de Agente, Grupo y Rol.

AGR Model
Agente
Es una entidad capaz de comunicar atreves de los roles que juegan en los diferentes grupos
Grupo
Role

Estructura general de la Plataforma

La arquitectura general de la plataforma puede ser representada de la forma siguiente (imagen del MadKit Development Guide)

MadKit Architecture

El componente principal es el Kernel (o micro-kernel). El kernel provee soporte para:

Control de grupos y roles locales
Manejo del ciclo de vida de los Agentes
Despacho de Mensajes locales

Implementación de Agentes en Madkit

La clase de base para un agente en Madkit es el AbstractAgent. Esta clase ofrece las primitivas básicas de comunicación (enviar y recibir mensajes), gestión de grupos y roles, etc.

La segunda clase importante es Agent. A diferencia de la primera, esta clase contiene un Thread para la ejecución del agente.

Todo agente en Madkit es una extensión de una de estas dos clases (para ser estrictos, todos son extensiones de AbstractAgent).

Para no discutir “en el aire” de agentes, grupos, etc. Vamos a utilizar el clásico ejemplo de Madkit…. NO.. no es el “hola mundo”… sino el “PingPong”. El código original fue escrito por Olivier Gutknecht.

El código completo se encuentra en $MADKIT/plugins/demos/src/madkit/demos/PingPong.java. Por ahora vamos a (re-)desarrollar el mismo agente poco a poco para introducir el funcionamiento de un agente en madkit.

Antes de comenzar a implementar nuestro agente, veamos que queremos que haga. Vamos a simular un partido de ping-pong entre dos agentes. Para ello, vamos a crear un grupo y un rol para que los agentes puedan “encontrarse”. Una vez que tengamos dos agentes dispuestos a jugar, vamos a intercambiar mensajes entre ellos para simular el envío de la pelota.

Ciclo de vida de un agente

Para nuestro ejemplo, vamos a utilizar la clase Agent, que dará a nuestro agente su propio thread de ejecución. Aunque podríamos utilizar AbstractAgent, esto demandaría la creación de un Scheduler para su ejecución (Tema de otro documento, algún día).

El ciclo de vida de un agente (usando la clase ), requiere la implementación de tres metodos. El primero es el método activate() que es llamado en el momento de la inicialización del agente. El segundo es live() donde se define el comportamiento del agente. El tercero es end() llamado a la finalización del agente.

De estos tres metodos, solo live() es obligatorio (si queremos que nuestro agente haga algo). Los otros dos (activate y end) tienen una implementación (vacía) por “default” en AbstractAgent.

Preparemos entonces nuestra clase para PingPong.

import madkit.kernel.*;
 
public class PingPong extends Agent{
 
public void activate(){}
public void live(){}
public void end(){}
}

Este código nos da una “carcasa” vacía para implementar nuestro agente. Ahora tenemos que completarla.

Gestión de grupos y Roles

Un modelo organisational

Madkit es una plataforma para implementa modelos Organizacionales. Y por ello el medio de contacto de los agentes son los roles que juegan en los grupos a los que pertenecen.

Para que nuestro agente pingpong pueda encontrar un otro jugador nos hace falta crear un grupo.  En Madkit, los grupos y los roles son definidos usando “Strings” (cadenas de caracteres). Atención: el grupo “MiGrupo” no es el mismo que “Migrupo”. Los Strings son sensibles a las mayúsculas y minúsculas!

Para crear un grupo podemos usar dos metodos:

int createGroup(boolean d, String g, String desc, GroupIdentifier gi)
Este método cuenta con 4 parametros. El primero (boolean d) indica si grupo es distribuido o no. Madkit permite la interconexión de kernels en red. Este parametro indica al kernel si deseamos que los otros kernels de la red sean notificados de los cambios en el grupo (creación / eliminación de roles, etc). Mas adelante veremos un poco mas de la distribución en red. Un dato importante: Todas las operaciones que vamos a ver (envío de mensajes, pedido de roles, etc) son transparentes para el agente. El segundo parametro es el grupo que deseamos crear. El tercero (String desc) es una descripción del grupo. Y el cuarto es un objeto que implementa un medio de seguridad para el ingreso al grupo (mas de esto luego).

Por ejemplo para nuestro agente PingPong vamos a usar

createGroup(true, “ping-pong”, null, null)
Esto creara un grupo distribuido llamado “ping-pong”, sin descripción y sin control de acceso.

El segundo método que podemos usar es:

int createGroup(boolean d, String c, String g, String desc, GroupIdentifier gi)

En este método agregamos un parametro (String c) que indica la comunidad en la que queremos crear el grupo. Una comunidad es un “grupo de grupos”. De hecho, cuando usamos createGroup(true, “ping-pong”, null, null), nuestro grupo ping-pong es creado en la comunidad “public” de Madkit. Las comunidades son utilizadas principalmente para crear espacio separados para diferentes aplicaciones, evitando así que dos aplicaciones usen el mismo nombre de grupo para cosas diferentes. No voy a entrar mas en detalle sobre las comunidades ahora. Por ahora considerenlas como espacios separados.
Volvamos a nuestro ejemplo de PingPong y preparemos nuestro agente para comenzar a jugar.

import madkit.kernel.*;
 
public class PingPong extends Agent{
 
private boolean creator=false;
 
public void activate(){
println("PingPong agent test");
println("Buscando el grupo ping-pong");
if (isGroup("ping-pong"))
{
println ("Existe, me uno");
creator=false;
}
else
{
println ("No existe, voy a crearlo");
createGroup(true,"ping-pong",null,null);
creator=true;
}
requestRole("ping-pong","player",null);
}
 
public void live(){}
public void end(){}
}

Veamos que hay de nuevo en nuestro método activate(). El primer método que encontramos es println(). Este método envía un String a el Output Writer de Madkit. Este writer no es siempre el System.out. Madkit nos permite definir el writer que deseemos. Es preferible de utilizar println() que System.out.println().

Veamos ahora los metodos relacionados con los grupos. El primero es isGroup(), este método nos indica si existe un grupo “ping-pong”. Nuestro agente verifica si el grupo existe (linea 10) y si no crea uno. Para crear un grupo usamos el método createGroup().
Una vez que el agente creo el grupo, vamos a solicitar el rol “player” (linea 21). El método requestRole tiene el formato siguiente.

int requestRole(String g, String r, Object id)

Los dos primeros parametros son el grupo y el role que deseamos. El tercer parametro es un identificador que sera pasado al GroupIdentifier definido para el grupo en la creación (cuarto parametro del createGroup de la linea 18). Como en la creación del grupo pasamos null como GroupIdentifier, podemos pasar null en requestRole.
Bueno, ya tenemos nuestro agente listo para comunicar con otro. Ahora podemos comenzar el desarrollo del comportamiento de nuestro agente.
Este comportamiento es programado en la clase live() del agente. Lo primero que tenemos que hacer es esperar que otro agente tome el role “player” en grupo “ping-pong”.
Veamos como modificamos nuestro método live para agregar este comportamiento

import madkit.kernel.*;
 
public class PingPong extends Agent{
 
private boolean creator=false;
private AgentAddress other=null;
 
public void activate(){
println("PingPong agent test");
println("Buscando el grupo ping-pong");
if (isGroup("ping-pong"))
{
println ("Existe, me uno");
creator=false;
}
else
{
println ("No existe, voy a crearlo");
createGroup(true,"ping-pong",null,null);
creator=true;
}
requestRole("ping-pong","player",null);
}
 
public void live(){
println("Buscando a otro jugador...");
do
{
exitImmediatlyOnKill();
pause(100);
AgentAddress[] v = getAgentsWithRole("ping-pong","player");
for (int i=0; i &lt; v.length; i++)
{
AgentAddress agent = v[i];
if (! agent.equals(getAddress()))
other = agent;
}
}
while (other == null);
println("Other is :"+other);
 
//A terminar (mas adelante)
}
public void end(){}
}

Esta, por ahora primera, parte del live va esperar que otro agente tome el rol “player”. Detallemos un poco mas.
Primero, en la linea 6, agregamos una variable de tipo AgentAddress que va a contener la dirección del otro agente. La AgentAddress es un identificador único que el kernel asigna a cada agente sobre la plataforma. Con esta dirección podemos enviar un mesaje a un agente particular. Luego en el método live() agregamos un bucle con el que vamos a esperar al otro agente. Mientras no haya otro agente con el rol “player” (other==null) esperamos.

El método exitImmediatlyOnKill(); es utilizado para asegurar que el thread del agente sea terminado correctamente (ligado a un problema en java y no a madkit). Es importante que cada vez que haya un bucle se agregue este método.

El método pause() va a detener la ejecución del agente por el tiempo indicado por el parametro (tiempo en milisegundos).

Luego vamos a recuperar las direcciones de todos los agentes con el rol “player” en grupo “ping-pong” (linea 31) usando el método getAgentsWithRole(). Este método devuelve las direcciones de todos los agentes con el rol indicado. Existe una variación de este método que va devolver uno solo de los agentes con el rol buscado. El método es el siguiente

getAgentWithRole(String g, String r)
La dirección del agente devuelto por el método es seleccionado al azar por la plataforma.
Volviendo a nuestro código, una vez que las direcciones son recuperadas iteramos para compararlas con la dirección de nuestro agente (obtenida con getAddress() en la linea 35)
Una vez que encontremos un segundo jugador, podemos comenzar a comunicar con el.

Primitivas de comunicación

La comunicación en madkit se hace atreves de mensajes. La clase de base para todos los mensajes en Madkit es la clase Message. Esta clase contiene únicamente el emisor, el receptor y el momento de creación del mensaje. Estos valores son accesible con los metodos getSender(), getReceiver() y getCreationDate(), respectivamente.

Los diferentes tipos de mensajes existentes en Madkit heritan de esta clase.

Las clases de mesajes más utilizadas en madkit son:

  • StringMessage: permite enviar como contenido del mesaje una cadena de caracteres (String de java).
  • ObjectMessage: permite encapsular un objeto serializable.
  • XMLMessage: el contenido es un documento XML

Para implementar un nuevo tipo de mensaje, solo debe heritar de la clase Message.

Envio de mensajes

En este punto ya hemos preparado el código para encontrar un segundo agente. Una vez que lo hayamos encontrado debemos comunicar con el. Veamos como modificamos el código para realizar esto.

import madkit.kernel.*;public class PingPong extends Agent{
private boolean creator=false;
 
private AgentAddress other=null;
public void activate(){
 
println("PingPong agent test");
 
println("Buscando el grupo ping-pong");
 
if (isGroup("ping-pong"))
 
{
 
println ("Existe, me uno");
 
creator=false;
 
}
 
else
 
{
 
println ("No existe, voy a crearlo");
 
createGroup(true,"ping-pong",null,null);
 
creator=true;
 
}
 
requestRole("ping-pong","player",null);
 
}
public void live(){
 
println("Buscando a otro jugador...");
 
do
 
{
 
exitImmediatlyOnKill();
 
pause(100);
 
AgentAddress[] v = getAgentsWithRole("ping-pong","player");
 
for (int i=0; i &lt; v.length; i++)
 
{
 
AgentAddress agent = v[i];
 
if (! agent.equals(getAddress()))
 
other = agent;
 
}
 
}
 
while (other == null);
 
println("Other is :"+other);
// Si no soy el creador del grupo, envio la pelota primero.
 
if (! creator)
 
sendMessage(other, new StringMessage("Ball"));
for (int i = 5; i &gt; 0; i--)
 
{
 
Message m = waitNextMessage();
 
if(! m.getSender().equals(other))
 
{
 
while(true)
 
{
 
exitImmediatlyOnKill();
 
Message m2 = waitNextMessage(1000);
 
if(m2==null)
 
{
 
other = m.getSender();
 
i=5;
 
println("El otro jugador se fue !!");
 
println("Encontre un nuevo jugador "+other);
 
break;
 
}
 
else
 
if(m2.getSender().equals(other))
 
break;
 
}
 
}
 
StringMessage ans = (StringMessage) m;
 
println("GEE ! Mi Turno..."+ m.getCreationDate());
 
pause(1000);
 
sendMessage(other, new StringMessage(ans.getString()));
 
}
 
}
 
public void end(){
 
println("Bye Bye !!");
 
println ("Agente PingPong Terminado");
 
}
 
}

Si nuestro agente no es el creador del grupo, le enviamos un mensaje (que contiene un String de java) para iniciar la comunicacion (linea 44). Para ello usamos el método sendMessage()
El primer parametro es la dirección de el otro agente (contenida en other en nuestro código). El segundo es el mensaje (StringMessage en nuestro caso).
Existen varias variaciones de este método, permitiendo definir el role y el grupo sin necesidad de buscar antes la AgentAddress, etc. Existe también el método broadcastMessage() que nos permite enviar un mensaje a todos los agentes con un rol en particular.

Recepción de Mensajes

Una vez que enviamos el primer mensaje (si no es el creador del grupo), vamos a esperar una respuesta. Para ello usamos el método waitNextMessage() (linea 48). Este método va a detener la ejecución del agente hasta que reciba un mensaje. Es un método muy útil, pero también peligroso. Si el agente no recibe un mesaje, quedara bloqueado indefinidamente. Si no estamos seguros que vamos a recibir un mensaje, es mejor usar la variación de este método que nos permite definir un timeout (linea 54). El timeout es definido en milisegundos. En caso que el timeout expire, el método devuelve null. Por ellos siempre debemos controlar que el mensaje no sea null.

Este método esta disponible solo en los agentes que heritan de Agent. Además de waitNextMessage() existe una versión no bloqueante llamada nextMessage()- El método devuelve el primer mensaje disponible o null si no hay ninguno.

Cada Agente enviara el mismo mensaje 5 veces y luego terminará su comportamiento (en términos de java, saldrá del metodo live(). Para indicar el fin del agente, agregamos en el método end() dos mensajes.

Con esto hemos terminado nuestro Agente!!!!

Como ven desarrollar un SMA en Madkit no es nada complicado. Ahora solo nos queda ver como vamos a lanzar y ejecutar nuestro agente.

Lanzar agentes

Como ya mencionamos antes, los agentes en madkit se ejecutan sobre el Kernel. En esta sección vamos a preparar una clase simple para lanzar nuestro agente PingPong.

Esta clase, que llamaremos SMA, no tiene interfaz gráfica. Sin embargo es posible de crear nuestra propia interface y adaptarla a las necesidades de nuestra aplicación. Como pueden ver con el Desktop (el mejor ejemplo de una interfaz para el kernel) practicamente nada es imposible como interfaz.

Pasemos al código:

import madkit.kernel.*;
public class SMA{
private Kernel miKernel=null;
public SMA(){
 
miKernel=new Kernel("Mi PingPong Kernel");
PingPong p1=new PingPong();
 
System.out.println("Lanzando el primer agente");
 
miKernel.launchAgent(p1, "PingPong1", miKernel, false);
PingPong p2=new PingPong();
 
System.out.println("Lanzando el Segundo agente");
 
miKernel.launchAgent(p2, "PingPong2", miKernel, false);
}
public static void main (String args[]){
 
new SMA();
 
}
}

Primero, declaramos una variable miKernel de tipo Kernel (madkit.kernel.Kernel). El constructor de nuestra clase creamos el objeto (linea 8). El parametro es un String que define el nombre que deseamos para nuestro kernel. Existen otros constructores disponible descriptos en la javadoc de madkit.

Luego, vamos a lanzar un agente de tipo PingPong (linea 12) con el método launchAgent():

launchAgent(AbstractAgent agente, String nombre , Object creador, boolean tieneGUI)

El primer parametro es el agente que deseamos lanzar. El segundo es el nombre con el que deseamos identificar al agente (útil solo para los humanos - no tiene influencia en el comportamiento del agente). El tercero es el objeto creador del agente. Este objeto es usados para implementar una cierta “seguridad”. Solo el creador del agente puede demandar a “matarlo”. El cuarto es un boolean que indica al kernel si el agente tiene o no una interfaz gráfica.
Los agentes también pueden lanzar otros agentes. Para ellos usamos el método:

launchAgent(AbstractAgent agente, String nombre , boolean tieneGUI)

Solo el parametro creador no es utiliza ya que ya sabemos que es el agente que llama el método quien es el creador del nuevo agente.

Finalmente, como dijimos, también pordemos matar agentes. Para ellos usamos el método:

killAgent(AbstractAgent agente)

El método requiere para una referencia al agente. Se deseamos matar un agente que creamos, debemos guardar una referencia al agente para hacerlo.
Muy bien, listo!!!!… Ahora solo falta compilar y lanzar la clase SMA…
javac -cp $MADKIT/lib/madkitkernel.java:. SMA.java
java -cp $MADKIT/lib/madkitkernel.java:. SMA
Si todo salio bien deberiamos ver algo como los siguiente:

        -----------------------------------------------------

MadKit/Aalaadin

by MadKit Team (c) 1997-2005

version: 4.1.1 - Arpeggios

-----------------------------------------------------

Please file bug reports on the madkit forum @ http://www.madkit.org

<Mi PingPong Kernel> : MadKit Agent microKernel desktop:K1129949651639 is up and running
Lanzando el primer agente
Lanzando el Segundo agente
<Mi PingPong Kernel> : [PingPong1] PingPong agent test
<Mi PingPong Kernel> : [PingPong1] Buscando el grupo ping-pong
<Mi PingPong Kernel> : [PingPong1] No existe, voy a crearlo
<Mi PingPong Kernel> : [PingPong1] Buscando a otro jugador...
<Mi PingPong Kernel> : [PingPong2] PingPong agent test
<Mi PingPong Kernel> : [PingPong2] Buscando el grupo ping-pong
<Mi PingPong Kernel> : [PingPong2] Existe, me uno
<Mi PingPong Kernel> : [PingPong2] Buscando a otro jugador...
<Mi PingPong Kernel> : [PingPong1] Other is :PingPong2,3@desktop:1639
<Mi PingPong Kernel> : [PingPong2] Other is :PingPong1,2@desktop:1639
<Mi PingPong Kernel> : [PingPong1] GEE ! Mi Turno...Sat Oct 22 04:54:11 CEST 2005
<Mi PingPong Kernel> : [PingPong2] GEE ! Mi Turno...Sat Oct 22 04:54:12 CEST 2005
<Mi PingPong Kernel> : [PingPong1] GEE ! Mi Turno...Sat Oct 22 04:54:13 CEST 2005
<Mi PingPong Kernel> : [PingPong2] GEE ! Mi Turno...Sat Oct 22 04:54:14 CEST 2005
<Mi PingPong Kernel> : [PingPong1] GEE ! Mi Turno...Sat Oct 22 04:54:15 CEST 2005
<Mi PingPong Kernel> : [PingPong2] GEE ! Mi Turno...Sat Oct 22 04:54:16 CEST 2005
<Mi PingPong Kernel> : [PingPong1] GEE ! Mi Turno...Sat Oct 22 04:54:17 CEST 2005
<Mi PingPong Kernel> : [PingPong2] GEE ! Mi Turno...Sat Oct 22 04:54:18 CEST 2005
<Mi PingPong Kernel> : [PingPong1] GEE ! Mi Turno...Sat Oct 22 04:54:19 CEST 2005
<Mi PingPong Kernel> : [PingPong1] Bye Bye !!
<Mi PingPong Kernel> : [PingPong1] Agente PingPong Terminado
<Mi PingPong Kernel> : [PingPong2] GEE ! Mi Turno...Sat Oct 22 04:54:20 CEST 2005
<Mi PingPong Kernel> : [PingPong2] Bye Bye !!
<Mi PingPong Kernel> : [PingPong2] Agente PingPong Terminado

Últimas Remarcas

Este documento describe un agente simple, la idea principal es de dar una introducción progresiva a el ciclo de vida, funcionamiento y los método disponibles para el desarrollo de agentes.

En el futuro espero poder preparar introducciones un poco mas avanzadas a madkit. Si tenes alguna sugerencia sobre el tema para otros tutorial, no dudes en hacermelas llegar.

Tagged , , ,

A great thesis on HMAS

A friend of mine defended his Ph.D. Thesis on MAS simulation. He covers several interesting field like Holonic Multi-Agent Systems, Agent-Oriented Software Engineering, Complex systems, Organizational approach and Multilevel simulation.

If you are interested in these subjects you should take a look.

Nicolas’ Home page and his Ph.D. Thesis

Abstract

The work, presented in this PhD thesis, is concerned with the study of complex systems and aims at providing a full set of abstractions and the associated methodological guidelines for the analysis, design, implementation and simulation of Holonic MultiAgent Systems (HMAS). HMAS offers a promising software engineering approach for developing complex open software systems. This kind of systems consists in self-similar structures called holons. A set of holons may be seen, depending on the level of observation, as a unique entity or as a group of holons in interaction. A complex system is made up of a large number of parts that have many interactions. In such systems, the behavior of the whole cannot be directly understood only by knowing the behavior of the parts and their interactions. Complex systems often exhibit a hierarchical structure. The foundation of this thesis consist in exploiting the intrinsic hierarchical structure of complex systems to analyse and decompose them. In order to conceive modular and reusable models, an organizational approach is adopted. The principle of the analysis is based on the identification of a hierarchy of organizations, which the global behavior may represent the system under the chosen perspective. The behaviors of the system are recursively decomposed into a set of interacting sub-behaviors, each of these latter being in turn decomposed until we reach some lowest level of elementary sub-behaviors. At a given level, the composed behavior is modeled using an organization, and the associated sub-behaviors using roles. This hierarchical organization structure is then mapped to an holarchy (hierarchy of holons) in charge of its execution. The concepts presented are then used to study the issues related to the multilevel multiagent simulation. The resulting model is finally applied to the pedestrians simulation in virtual urban environment.

Tagged