Seminario 5 deko ferreira

323 visualizaciones

Publicado el

Publicado en: Empresariales
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
323
En SlideShare
0
De insertados
0
Número de insertados
5
Acciones
Compartido
0
Descargas
4
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Seminario 5 deko ferreira

  1. 1. PROTOCOLOS DE COMUNICACION<br />Adrián Ferreira García<br />Diego Rodríguez González<br />Grupo Avia<br />
  2. 2. Protocolos de comunicación<br />La comunicación entre agentes responde 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 />El Protocolo de comunicación JADE se define mediante dos roles, el que inicia la conversación y el que es destino 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. 3.6.1 El Paquete jade.proto (cont.)<br />Las acciones de los agentes dentro de los protocolos FIPA se puede reducir simplemente al funcionamiento de una máquina de estados finitos.<br />Este seria el típico comportamiento utilizado para representar dichas máquinas:<br />(Iniciador) - Pedro: Juan, ¿Tienes hora?<br />(Respondedor) - Juan: Sí, un segundo.<br />(Respondedor) - Juan mira el reloj.<br />(Respondedor) - 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 />
  6. 6. 3.6.1 El paquete jade.proto (cont.)<br />
  7. 7. 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 concretan mediante los preparadores (Prepares).<br />La siguiente figura muestra dicho funcionamiento con claridad:<br />
  8. 8. 3.6.1 El paquete jade.proto (cont.)<br />
  9. 9. 3.6.1.1 Manejadores (Handle y registerHandler)<br />Un manejador es una manera de tratar determinadas situaciones, que se iniciaran en determinado momento y en funcion del estado al que esté asociado. <br />Existen dos formas de implementar un manejador:<br />1. Sobrecarga de métodos handle: <br />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 />
  10. 10. 3.6.1.1 Manejadores (Handle y registerHandler)<br />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 registrerHandler, que son de la forma:<br />registerHanderInform<br />registreHandlerRequest<br />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.<br />
  11. 11. 3.6.1.1 Manejadores (handler y registerHandler)(Tipos)<br />Mensajes asociados a formas predeterminadas: Hay ciertos manejadores que serán iniciados cada vez que llegue un mensaje con determinado patrón, 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 />
  12. 12. 3.6.1.1 Manejadores (handler y registerHandler)(Tipos)<br />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 patrón esperado según el protocolo FIPA, excepciones principalmente.<br />
  13. 13. 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 inicializados 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. <br />El hecho de dejar vacío un campo puede interrumpir todo el protocolo<br />
  14. 14. 3.6.1.3 El almacén de datos<br />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 />Cada clase define un conjunto de constantes que servirán de clave para acceder a un tipo de mensajes determinado.<br />Registrar el mensaje de respuesta (Response)<br />ACLMessage response = new ACLMessage(ACLMessage.ACCEPT_PROPOSAL); this.getDataStore().put(ProposeResponder.RESPONSE_KEY, response);<br />Obtener el mensaje Propose recibido<br />ACLMessage propose = (ACLMessage) this.getDataStore().get(ACLMessage.PROPOSE_KEY);<br />
  15. 15. 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.<br />El estándar FIPA especifica para cada acto comunicativo: <br /><ul><li>Precondiciones de Viabilidad (FeasibilityPreconditions)
  16. 16. Efecto Razonable (RationalEffect)</li></li></ul><li>3.6.2 AchieveRE<br />Conjunto de clases AchieveRE:<br /><ul><li>AchieveREInitiator
  17. 17. AchieveREResponder
  18. 18. SimpleAchieveREInitiator
  19. 19. SimpleAchieveREResponder
  20. 20. IteratedAchieveREInitiator
  21. 21. 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.
  22. 22. El respondedor responde de forma negativa con REFUSE, NOT_UNDERSTOOD o FAILURE.
  23. 23. 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
  24. 24. FIPA-Query</li></li></ul><li>3.6.2.1 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 FIFA-request.<br />Los mensajes que se intercambian son: <br /><ul><li>Request, la petición.
  25. 25. Agree, si acepta la petición o Refuse si la rechaza.
  26. 26. En caso de que el mensaje anterior fuera un Agree:
  27. 27. Failure si ocurrió algún error en el proceso.
  28. 28. Inform-done si se realizó correctamente.
  29. 29. inform-result si además se tiene que comunicar el resultado.</li></ul>Ejemplo<br />
  30. 30. 3.6.2.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.
  31. 31. Agree si se acepta o refuse si se rechaza.
  32. 32. Si se aceptó:
  33. 33. Failure si ocurrió algún error en el proceso
  34. 34. Inform-T/F con la respuesta si la consulta era un Query-If
  35. 35. Inform-Result si la consulta fue un Query-Ref. </li></ul>Ejemplo<br />
  36. 36. 3.6.3 ContractNet<br />Las clases ContractNet implementan el comportamiento del protocolo del mismo nombre: <br /><ul><li>Funcionamiento
  37. 37. 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 y envía Reject-Proposal o un Accept-Proposal.<br />Los respondedores envían un Failure o bien Inform-Done, o Inform-Result.<br />
  38. 38. 3.6.3 ContractNet<br />El agente iniciador (ContractNetInitiator) posee dos métodos importantes:<br /><ul><li>handlePropose
  39. 39. handleAllResponses</li></ul>Y el agente respondedor posee los métodos: <br /><ul><li>handleAcceptProposal
  40. 40. handleRejectProposal</li></ul>Ejemplo<br />
  41. 41. 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, pudiendo realizarse o no en caso de aceptacion.<br /> 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.
  42. 42. Un Reject-Proposal o un Accept-Proposal en función de si acepta la propuesta o no. </li></li></ul><li>3.6.4 Protocolo FIPA-Propose (cont.)<br />La clase del respondedor (proposeResponder) no dispone de métodos handler, solamente dispone de un prepareResponse() que maneja la respuesta al Propose recibido, un registerPrepareResponse(), un createMessageTemplate() y algunos métodos reset().<br />Ejemplo.<br />
  43. 43. 3.6.5 Protocolo FIPA-Subscription<br />El iniciador le solicita al respondedor permiso para suscribirse, el respondedor procesa esa solicitud y la acepta o la rechaza. 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 />
  44. 44. 3.6.5 Protocolo FIPA-Subscription (cont.)<br /> Los mensajes que se intercambian son: <br /><ul><li>Subscribe, solicitando la suscripción.
  45. 45. 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.
  46. 46. Si la aceptó, después envía un Inform-Result con las condiciones que establezca para la suscripción.
  47. 47. 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.
  48. 48. 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 />

×