Protocolos de comunicación<br />Manuel Bouzas Reguera<br />Juan Sequeiros Ameijeira<br />Silvia González Escuredo<br />Gru...
Protocolos de comunicación<br />La comunicación entre agentes responden a un patrón de los especificados por FIPA, denomin...
3.6.1 El paquete jade.proto<br />El paquete jade.protoagrupa todas las clases que, en forma de comportamientos, facilitan ...
3.6.1 El paquete jade.proto (cont.)<br />
Las acciones de los agentes en los protocolos FIPA se puede reducir simplemente a una máquina de estados finitos, y este e...
3.6.1 El paquete jade.proto (cont.)<br />
La acciones que se realizan en cada estado se definen mediante los manejadores (Handlers), mientras que los mensajes se pr...
3.6.1.1 Manejadores (handle y registerHandler)<br />Un manejador es un comportamiento que se iniciará al entrar en el esta...
<ul><li>2. Registrar manejadores propios: Se podrán registrar comportamientos para que actúen como manejadores. El registr...
Mensajes asociados a preformativas: Hay ciertos manejadores que serán iniciados cada vez que llegue un mensaje con determi...
Manejadores AllResultNotifications: Serán lanzados cuando se reciban todas las respuestas finales o cuando se supere el ti...
3.6.1.2 Preparadores (prepare y registerPrepare)<br />Un preparador lo que hace es preparar un mensaje para ser enviado, p...
El almacén de datos guarda todos los mensajes que se envían o reciben durante todo el proceso de comunicación, es decir, a...
3.6.2 AchieveRE<br />La característica principal de los mensajes en FIPA-ACL es que cada uno de ellos representa un acto c...
Efecto Razonable (RationalEffect)</li></li></ul><li>3.6.2 AchieveRE<br />Conjunto de clases AchieveRE:<br /><ul><li>Achiev...
AchieveREResponder
SimpleAchieveREInitiator
SimpleAchieveREResponder
IteratedAchieveREInitiator
SSIteratedAchieveREResponder</li></ul>La sesión de cada protocolo con un respondedor dado terminará si: <br /><ul><li>El i...
El respondedor responde negativamente con REFUSE, NOT_UNDERSTOOD o FAILURE.
El respondedor incluye una bandera de terminación a la notificación de resultado INFORM. Esta bandera de terminación puede...
FIPA-Query</li></li></ul><li> 3.6.2 FIPA-Request<br />Este protocolo permite a un agente solicitar a otro la realización d...
Agree, si acepta la petición o refuse si la rechaza.
Upcoming SlideShare
Loading in …5
×

Sma presentacion

453 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
453
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sma presentacion

  1. 1. Protocolos de comunicación<br />Manuel Bouzas Reguera<br />Juan Sequeiros Ameijeira<br />Silvia González Escuredo<br />Grupo Avia<br />
  2. 2. Protocolos de comunicación<br />La comunicación entre agentes responden a un patrón de los especificados por FIPA, denominados protocolos. Cada uno de estos protocolos establece el intercambio básico de mensajes que existe entre dos agentes para un tipo de conversación.<br />Protocolos de comunicación JADE define dos roles, el que inicia la conversación y el que es objeto de la misma (rol Initiator y rol Responder).<br />JADE proporciona unas clases de comportamiento prediseñadas para ambos roles. Estas clases se encuentran en el paquete jade.proto.<br />
  3. 3. 3.6.1 El paquete jade.proto<br />El paquete jade.protoagrupa todas las clases que, en forma de comportamientos, facilitan la implementación de los protocolos de comunicación definidos por FIPA. <br />Se agrupan dentro del paquete en cuatro parejas de clases principales .<br />A mayores de estas cuatro clases existen otras subclases que añaden valores a las principales o que las simplifican.<br />
  4. 4. 3.6.1 El paquete jade.proto (cont.)<br />
  5. 5. Las acciones de los agentes en los protocolos FIPA se puede reducir simplemente a una máquina de estados finitos, y este es el tipo de comportamiento indicado para representar dichas máquinas.<br />ejemplo :<br />Pedro: Juan, ¿Tienes hora?<br />Juan: Sí, un segundo.<br />Juan mira el reloj.<br />Juan: Son las seis en punto.<br />Esta conversación sigue el modelo del protocolo FIPA-Request, es decir, hay una petición del agente Initiator y una aceptación y respuesta del agente Responder<br />3.6.1 El paquete jade.proto (cont.)<br />
  6. 6. 3.6.1 El paquete jade.proto (cont.)<br />
  7. 7. 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 <br /> funcionamiento<br /> con claridad.<br />3.6.1 El paquete jade.proto (cont.)<br />
  8. 8. 3.6.1.1 Manejadores (handle y registerHandler)<br />Un manejador es un comportamiento que se iniciará al entrar en el estado al que esté asociado. Existen dos formas de implementar un manejador:<br /><ul><li>1.Sobrecarga de métodos handle:</li></ul>Cada comportamiento tiene una serie de métodos handle con la forma: handleInform, handleRequest, etc. Cada uno de ellos será invocado cuando se reciba el tipo de mensaje correspondiente.<br />
  9. 9. <ul><li>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. </li></ul>3.6.1.1 Manejadores (handle y registerHandler)(cont.)<br />
  10. 10. Mensajes asociados a preformativas: Hay ciertos manejadores que serán iniciados cada vez que llegue un mensaje con determinada preformativa, pero siempre que ese mensaje llegue según lo esperado por el protocolo FIPA que corresponda.<br />Manejadores AllResponses: Serán lanzados cuando se reciban todas las respuestas al primer mensaje enviado por 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. Se encuentra en todos los iniciadores.<br />3.6.1.1 Manejadores (handle y registerHandler)(cont.)<br />
  11. 11. Manejadores AllResultNotifications: Serán lanzados cuando se reciban todas las respuestas finales 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. Solamente se encuentra en el iniciador AchieveRE y en el ContractNet.<br />Manejador OutOfSequence: Este es el manejador que se encarga de actuar en el caso de que el mensaje recibido no se corresponda con el esperado según los protocolo FIPA. Es decir, funcionará con las excepciones<br />3.6.1.1 Manejadores (handle y registerHandler)(cont.)<br />
  12. 12. 3.6.1.2 Preparadores (prepare y registerPrepare)<br />Un preparador lo que hace es preparar un mensaje para ser enviado, por lo que son iniciados antes de enviar un mensaje del tipo al que estén asociados<br />En el caso de registrar comportamientos habrá que guardar en el almacén de datos y con una clave determinada el mensaje que se desea enviar. <br />Se deber tener mucho cuidado a la hora de rellenar los campos de los mensajes, pues el hecho de dejar vacío un campo puede interrumpir todo el protocolo<br />
  13. 13. El almacén de datos guarda todos los mensajes que se envían o reciben durante todo el proceso de comunicación, es decir, a lo largo de la ejecución de un protocolo.<br />3.6.1.3 El almacén de datos<br />
  14. 14. 3.6.2 AchieveRE<br />La característica principal de los mensajes en FIPA-ACL es que cada uno de ellos representa un acto comunicativo, El estándar FIPA especifica para cada acto comunicativo: <br /><ul><li>Precondiciones de Viabilidad (FeasibilityPreconditions)
  15. 15. Efecto Razonable (RationalEffect)</li></li></ul><li>3.6.2 AchieveRE<br />Conjunto de clases AchieveRE:<br /><ul><li>AchieveREInitiator
  16. 16. AchieveREResponder
  17. 17. SimpleAchieveREInitiator
  18. 18. SimpleAchieveREResponder
  19. 19. IteratedAchieveREInitiator
  20. 20. SSIteratedAchieveREResponder</li></ul>La sesión de cada protocolo con un respondedor dado terminará si: <br /><ul><li>El iniciador envía al respondedor un mensaje explicito CANCEL en lugar del siguiente mensaje de iniciación.
  21. 21. El respondedor responde negativamente con REFUSE, NOT_UNDERSTOOD o FAILURE.
  22. 22. El respondedor incluye una bandera de terminación a la notificación de resultado INFORM. Esta bandera de terminación puede detectarse usando el método isSessionTerminated().</li></li></ul><li>3.6.2 AchieveRE<br />Algunos de los protocolos que implementa la clase AchieveRE son:<br /><ul><li>FIPA-Request
  23. 23. FIPA-Query</li></li></ul><li> 3.6.2 FIPA-Request<br />Este protocolo permite a un agente solicitar a otro la realización de una acción y está identificado en el parámetro del protocolo del mensaje con el valor fipa-request.<br />Los mensajes que se intercambian son: <br /><ul><li>Request, la petición.
  24. 24. Agree, si acepta la petición o refuse si la rechaza.
  25. 25. En caso de que el mensaje anterior fuera un agree: Failure si ocurrió algún error en el proceso, inform-done si se realizó correctamente e inform-result si además se tiene que comunicar el resultado.</li></ul>Ejemplo<br />
  26. 26. 3.6.2 FIPA-Query<br />Este protocolo permite a un agente solicitar a otro un objeto o una comprobación que devuelva un valor de verdad, y en función de que tipo de petición sea será un Query-if (comprobación de verdad) o un Query-ref (cuando se pregunta por algún objeto).<br />Los mensajes que se intercambian son los siguientes: <br /><ul><li>Query-If o Query-Ref, la solicitud.
  27. 27. Agree si se acepta o refuse si se rechaza.
  28. 28. 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 o Inform-Result si la consulta fue un Query-Ref. </li></ul>Ejemplo<br />
  29. 29. 3.6.3 ContractNet<br />Las clases ContractNet implementan el comportamiento del protocolo del mismo nombre: <br /><ul><li>Funcionamiento
  30. 30. Los mensajes que se intercambian son:</li></ul>CFP (CallForProposal)<br />Los respondedores pueden enviar un Refuse, un Not-Understood o un Propose<br />El iniciador evalúa propuestas envía Reject-Proposal o un Accept-Proposal.<br />Los respondedores envían un Failure ,un Inform-Done, o un Inform-Result.<br />
  31. 31. 3.6.3 ContractNet<br />El agente iniciador (ContractNetInitiator) posee dos métodos importantes:<br /><ul><li>handlePropose
  32. 32. handleAllResponses</li></ul>Y el agente respondedor posee los métodos: <br /><ul><li>handleAcceptProposal
  33. 33. handleRejectProposal</li></ul>Ejemplo<br />
  34. 34. 3.6.4 Protocolo FIPA-Propose<br />Implementa un comportamiento que consiste en que el iniciador le pide permiso al respondedor para realizar una acción, y si éste acepta la realiza y si no, no. Los mensajes intercambiados en la ejecución de este protocolo son:<br /><ul><li>Propose, con la propuesta de acción por parte del iniciador.
  35. 35. Un Reject-Proposal o un Accept-Proposal en función de si acepta la propuesta o no. </li></li></ul><li>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().<br />Ejemplo.<br /> 3.6.4 Protocolo FIPA-Propose (cont.)<br />
  36. 36. El iniciador le solicita al respondedor permiso para suscribirse, el respondedor procesa esa solicitud y la acepta o la rehecha. Si la acepta envía un mensaje con las condiciones de suscripción, y lo hace de forma continua hasta que sufre un fallo y envía un failure o hasta que el iniciador cancela el envío.<br />Ejemplo<br />3.6.5 Protocolo FIPA-Subscription<br />
  37. 37. 3.6.5Protocolo FIPA-Subscription (cont.)<br /> Los mensajes que se intercambian son: <br /><ul><li>Subscribe, solicitando la suscripción.
  38. 38. 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.
  39. 39. Si la aceptó, después envía un Inform-Result con las condiciones que establezca para la suscripción.
  40. 40. 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.
  41. 41. 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.</li></ul>Ejemplo<br />

×