Manuel Bouzas RegueraJuan Sequeiros AmeijeiraSilvia González Escuredo

Grupo Avia

La comunicación entre agentes responden a un patrón de losespecificados por FIPA, denominados protocolos. Cada unode estos protocolos establece el intercambio básico demensajes que existe entre dos agentes para un tipo deconversación.

Protocolos de comunicación JADE define dos roles, el queinicia la conversación y el que es objeto de la misma (rolInitiator y rol Responder).

JADE proporciona unas clases de comportamientoprediseñadas para ambos roles. Estas clases se encuentran enel paquete jade.proto.

El paquete jade.proto agrupa todas las clases que, en formade comportamientos, facilitan la implementación de losprotocolos de comunicación definidos por FIPA.

Se agrupan dentro del paquete en cuatro parejas de clasesprincipales .

A mayores de estas cuatro clases existen otras subclases queañaden valores a las principales o que las simplifican.

3.6.1 El paquete jade.proto (cont.)

Comportamientos Protocolos FIPA

AchieveREInitiator

AchieveREResponder

o SimpleAchieveREInitiator

o SimpleAchieveREResponder

o IteratedAchieveREInitiator

o SSIteratedAchieveREResponder

FIPA-Request

FIPA-Query

FIPA-Recruiting

FIPA-Request-When

FIPA-Brokering

ContractNetInitiator

ContractNetResponder

o SSContractNetResponder

FIPA-Contract-Net

SubscriptionInitiator

SubscriptionResponder

FIPA-Subscribe

FIPA-Request-Whenever

ProposeInitiator

ProposeResponderFIPA-Propose

Las acciones de los agentes en los protocolos FIPA se puedereducir simplemente a una máquina de estados finitos, y estees el tipo de comportamiento indicado para representardichas máquinas.

ejemplo :

Pedro: Juan, ¿Tienes hora?

Juan: Sí, un segundo.

Juan mira el reloj.

Juan: Son las seis en punto.

Esta conversación sigue el modelo del protocolo FIPA-Request, es decir, hay una petición del agente Initiator y unaaceptación y respuesta del agente Responder

La acciones que se realizan en cada estado se definen mediante los manejadores (Handlers),mientras que los mensajes se preparan mediante los preparadores (Prepares). La siguiente figura muestra dicho

funcionamiento

con claridad.

Un manejador es un comportamiento que seiniciará al entrar en el estado al que esté asociado.Existen dos formas de implementar un manejador:

• 1.Sobrecarga de métodos handle:

Cada comportamiento tiene una serie de métodoshandle con la forma: handleInform, handleRequest, etc.Cada uno de ellos será invocado cuando se reciba eltipo de mensaje correspondiente.

protected void handleInform(ACLMessageinform) {

System.out.println(“Inform recibido”);}

2. Registrar manejadores propios: Se podrán registrar comportamientos para que actúen como manejadores. El registro se hará a través de los métodos registerHandler que tienen la forma: registerHandleInform, registerHandleRequest, etc. En caso de registrar un comportamiento como manejador, el sistema ignorará las sobrecargas de los métodos handler y se limitará a iniciar los comportamientos registrados.

Mensajes asociados a preformativas: Hay ciertosmanejadores que serán iniciados cada vez que llegue unmensaje con determinada preformativa, pero siempreque ese mensaje llegue según lo esperado por elprotocolo FIPA que corresponda.

Manejadores AllResponses: Serán lanzados cuando sereciban todas las respuestas al primer mensaje enviadopor el iniciador o cuando se supere el tiempo de espera,indicado en el campo reply-by de ese mensaje inicial.Proporciona acceso a todos los mensajes recibidos. Seencuentra en todos los iniciadores.

Manejadores AllResultNotifications: Serán lanzadoscuando se reciban todas las respuestas finales o cuandose supere el tiempo de espera, indicado en el camporeply-by de ese mensaje inicial. Proporciona acceso atodos los mensajes recibidos. Solamente se encuentraen el iniciador AchieveRE y en el ContractNet.

Manejador OutOfSequence: Este es el manejador que seencarga de actuar en el caso de que el mensaje recibidono se corresponda con el esperado según los protocoloFIPA. Es decir, funcionará con las excepciones

Un preparador lo que hace es preparar un mensajepara ser enviado, por lo que son iniciados antes deenviar un mensaje del tipo al que estén asociados

La característica principal de los mensajes en FIPA-ACL es que cada uno de ellos representa un actocomunicativo, El estándar FIPA especifica para cadaacto comunicativo:

• Precondiciones de Viabilidad (FeasibilityPreconditions)

• Efecto Razonable (Rational Effect)

Conjunto de clases AchieveRE:

• AchieveREInitiator

• AchieveREResponder

• SimpleAchieveREInitiator

• SimpleAchieveREResponder

• IteratedAchieveREInitiator

• SSIteratedAchieveREResponder

La sesión de cada protocolo con un respondedor dadoterminará si:

• El iniciador envía al respondedor un mensaje explicito CANCELen lugar del siguiente mensaje de iniciación.

• El respondedor responde negativamente con REFUSE,NOT_UNDERSTOOD o FAILURE.

• El respondedor incluye una bandera de terminación a lanotificación de resultado INFORM. Esta bandera de terminaciónpuede detectarse usando el método isSessionTerminated().

Algunos de los protocolos que implementala clase AchieveRE son:

• FIPA-Request

• FIPA-Query

Este protocolo permite a un agente solicitar a otro larealización de una acción y está identificado en el parámetrodel protocolo del mensaje con el valor fipa-request.

Los mensajes que se intercambian son:

• Request, la petición.

• Agree, si acepta la petición o refuse si la rechaza.

• En caso de que el mensaje anterior fuera un agree: Failure siocurrió algún error en el proceso, inform-done si se realizócorrectamente e inform-result si además se tiene quecomunicar el resultado.

Ejemplo

Este protocolo permite a un agente solicitar a otro un objetoo una comprobación que devuelva un valor de verdad, y enfunción de que tipo de petición sea será un Query-if(comprobación de verdad) o un Query-ref (cuando sepregunta por algún objeto).

Los mensajes que se intercambian son los siguientes:

• Query-If o Query-Ref, la solicitud.

• Agree si se acepta o refuse si se rechaza.

• Si se aceptó: Failure si ocurrió algún error en el proceso,Inform-T/F con la respuesta si la consulta era un Query-If oInform-Result si la consulta fue un Query-Ref.

Ejemplo

Las clases ContractNet implementan elcomportamiento del protocolo del mismo nombre:

• Funcionamiento

• Los mensajes que se intercambian son:

1. CFP (Call For Proposal)

2. Los respondedores pueden enviar un Refuse,un Not-Understood o un Propose

3. El iniciador envía Reject-Proposal o unAccept-Proposal.

4. Los respondedores envían un Failure ,unInform-Done, o un Inform-Result.

El agente iniciador (ContractNetInitiator) posee dosmétodos importantes:

• handlePropose

• handleAllResponses

Y el agente respondedor posee los métodos:

• handleAcceptProposal

• handleRejectProposal

Ejemplo

Implementa un comportamiento que consiste en que eliniciador le pide permiso al respondedor para realizar unaacción, y si éste acepta la realiza y si no, no. Los mensajesintercambiados en la ejecución de este protocolo son:

• Propose, con la propuesta de acción por parte deliniciador.

• Un Reject-Proposal o un Accept-Proposal en función desi acepta la propuesta o no.

La clase del respondedor (ProposeResponder) no dispone de métodos handle, solamente dispone de un prepareResponse() que maneja la respuesta al Propose recibido, un registerPrepareResponse(), un createMessageTemplate() y algunos métodos reset().

Ejemplo.

El iniciador le solicita al respondedor permiso parasuscribirse, el respondedor procesa esa solicitud yla acepta o la rehecha. Si la acepta envía unmensaje con las condiciones de suscripción, y lohace de forma continua hasta que sufre un fallo yenvía un failure o hasta que el iniciador cancela elenvío.

Ejemplo

Los mensajes que se intercambian son:

• Subscribe, solicitando la suscripción.

• El respondedor envía un Refuse si no acepta la propuesta de

suscripción, un Agree si la acepta y un Not-Understood si

hubo algún fallo.

• Si la aceptó, después envía un Inform-Result con las

condiciones que establezca para la suscripción.

• Para detener el envío, o bien sufre un fallo el respondedor y

envía un Failure o bien envía un Cancel el iniciador.

• Si el proceso se detuvo porque el iniciador envió un Cancel, el

respondedor manda un Inform-Done si todo se realizó

exitosamente, o un Failure si algo no funcionó correctamente.

Ejemplo