domingo, 24 de febrero de 2008

FIPA parte 2

Continuando con la especificación FIPA, terminare de detallar alguno de los puntos mas importantes para luego ver como esta se encuentra implementada en JADE.

El Directorio Facilitador (DF) proporciona un servicio de paginas amarillas al resto de los agentes. Cualquier plataforma de agentes FIPA tiene que tener al menos un DF. Los agentes usan el DF para registrar sus servicios o para obtener los servicios de los demás agentes.

Los DF’s pueden registrarse entre ellos. De la misma forma, los componentes AMS y ACC también pueden registrarse con un DF. Todos los DF’s tienen un nombre por defecto que empieza por ”df ”.

Las acciones de gestión que soporta son:

  • register: Petición de registro de los servicios de un agente.
  • search: Petición de búsqueda de agentes que proporcionen determinados servicios.
  • deregister: Petición de borrado de los servicios registrados de un agente.
  • modify: Petición de modificación de los servicios registrados de un agente

Solo un Agent Management System (AMS) puede existir en una plataforma de agentes FIPA. Este es responsable de gestionar las operaciones de su plataforma tales como la creación de agentes, borrado de agentes, decidir si un agente puede registrarse en la plataforma y supervisar la migración de los agentes a/desde la plataforma.

El AMS es la autoridad en toda la plataforma. Puede solicitar a un agente que finalice su ejecución (quit) e incluso obligarle a finalizar.

El AMS gestiona una lista con todos los agentes que se encuentran en la plataforma. En la lista se encuentran las identificaciones GUID de los agentes asociadas a sus direcciones en la plataforma. Para que un agente resida en la plataforma tiene que registrarse con el AMS.

Todos los AMS tienen un nombre por defecto que empieza con “ams”. Las acciones de gestión que tiene que soportar cualquier AMS son:

  • register-agent: Petición de registro de un agente.
  • deregister-agent: Petición de borrar del registro a un agente.
  • modify-agent: Petición de modificación del registro de un agente.
  • query-platform-profile: Petición del perfil de la plataforma.
  • authenticate: Petición de autentificar la identidad de un agente creado en la plataforma.
  • search-agent: Petición de búsqueda de la dirección de un agente.

Existe una acción de gestión para movilidad que también tiene que soportar cualquier AMS:

  • move: Petición de transferencia/migración de un agente.

Además de las acciones de gestión intercambiadas entre el AMS y los agentes en la plataforma, el AMS puede proporcionar a la plataforma la realización de las siguientes operaciones:

  • suspend agent: Suspender o parar la ejecución de una agente.
  • terminate agent: Finalizar la ejecución de un agente.
  • create agent: Crear un agente.
  • resume agent execution: Continuar con la ejecución de un agente suspendido.
  • invoke agent: Empezar la ejecución de un agente recién creado.
  • execute agent: Ejecutar un agente después de moverse.
  • resource management: Gestionar los recursos.

Existe una acción de gestión que tienen que soportar los agentes utilizados por el AMS:

  • quit: Petición de terminación de un agente, la cual finaliza la ejecución del agente que recibe la solicitud.

El ACC proporciona el encaminamiento de mensajes entre agentes de diferentes plataformas FIPA. Todos los agentes FIPA tienen acceso al menos a un ACC. Únicamente mensajes dirigidos a agentes pueden ser enviados a un ACC.

El encaminamiento de mensajes entre diferentes plataformas requiere un protocolo de interoperabilidad por defecto (especificándose el protocolo de transporte, codificación y direccionamiento). Este protocolo es IIOP.

La acción de gestión que soporta es:

  • forward: Petición de envió de un mensaje desde un agente a otro.

Esta acción no debe de interpretarse como el mecanismo por defecto para enviar mensajes entre los agentes de la misma plataforma. Estos podrán comunicarse empleando el método interno (IPMT) que se haya implementado en la plataforma.

Dentro del Agent Plataform (AP) el ciclo de vida de los agentes FIPA esta caracterizado por:

  • Definir los posibles estados y transiciones de un agente independientemente del tipo de implementación de la plataforma.
  • Cada agente es físicamente gestionado en una plataforma. Si el agente es estacionario, su ciclo de vida siempre será en la misma plataforma.
  • Cada agente descrito con el modelo de ciclo de vida es asumido como una instancia con nombre propio y único que se ejecuta de forma independientemente.
  • Cada agente solo puede encontrase en un estado en una única plataforma al mismo tiempo.

El ciclo de vida de los agentes se representa mediante estados y transiciones, los cuales se muestran en la siguiente figura:

Únicamente los agentes móviles pueden entrar en el estado “transit”. Esto asegura que los agentes estacionarios ejecuten todas sus instrucciones en el nodo donde fueron invocados.

Las acciones para pasar los agentes de un estado a otro son:

  • Create: Creación de un nuevo agente.
  • Invoke: Invocación o activación de un nuevo agente una vez inicializado.
  • Destroy: Se fuerza la terminación de un agente. Esta acción solo puede ser iniciada por el AMS y no puede ser ignorada.
  • Quit: Se solicita la terminación de un agente. El agente puede ignorar la acción.
  • Suspend: Pone a un agente en el estado de suspendido. Esta acción puede ser iniciada por el propio agente o por el AMS.
  • Resume: Saca a un agente del estado suspendido. Esta acción solo puede ser iniciada por el AMS.
  • Wait: Pone a un agente en el estado de espera. Esta acción solo puede ser iniciada por el propio agente.
  • Wake up: Saca a un agente del estado de espera. Esta acción solo puede ser iniciada por el AMS.

Las siguientes acciones solo son usadas por los agentes móviles:

  • Move: Pone a un agente en el estado de transición. Esta acción solo puede ser iniciada por el propio agente.
  • Execute: Saca al agente del estado

La plataforma en la cual se creo un agente se denomina la Home Agent Platform (HAP) de dicho agente. La responsabilidad del HAP es garantizar la identidad del agente en sus relaciones con otros agentes y plataformas. El estándar FIPA requiere que cada agente tenga un HAP que responda por el ante el resto de la comunidad de agentes. Por tal motivo:

Es necesario que a partir del análisis del GUID de un agente pueda obtenerse la dirección IIOP-URL del HAP.

Es necesario que el HAP pueda autentificar la identidad del agente en la plataforma. Para ello, el AMS del HAP soporta la acción “authenticate”.

El AMS del HAP de un agente es responsable de guardar la dirección de dicho agente. Por otro lado, el agente tiene la responsabilidad de asegurar que la dirección guardada por el AMS sea valida. Un agente siempre debe registrarse en su HAP. El nombre de un agente (GUID) es el mismo durante toda su existencia.

Un agente puede registrarse en una plataforma si se cumple alguna de las siguientes condiciones:

  • El agente se creo en la plataforma.
  • El agente migro a la plataforma. Ambas plataformas, HAP y destino, tienen que soportar movilidad de agentes.
  • El agente se registra dinámicamente en una plataforma diferente a su HAP como agente local. Ambas plataformas tienen que soportar registro dinámico.

Al registrarse un agente se facilita al AMS la siguiente información:

  • El identificador global y único del agente (GUID).
  • La dirección local del agente.

El agente se registra en el AMS mediante la acción “register-agent”.

Un agente tiene dos opciones cuando desea contactarse (enviar un mensaje) con otro agente de una plataforma diferente:

  • Puede solicitar que el ACC de su plataforma envié el mensaje al ACC y agente de la otra plataforma.
  • Puede contactarse directamente con el ACC de la otra plataforma y enviarle el mensaje.

Es necesario el GUID del agente destino para poder contactar con el. El mensaje se enviara al HAP del agente destino y a partir de aquí se hará llegar a dicho agente. Alternativamente, si se desea enviar el mensaje directamente al agente o a una plataforma (distinta del HAP) donde el agente se registro dinámicamente, entonces se deberá indicar además del GUID la dirección destino.

Aun quedan puntos pendientes por ver de la especificación, pero ya que con lo visto hasta ahora podemos comenzar a ver los primeros códigos de ejemplo en JADE….pero eso será para el próximo post.

No hay comentarios: