RETSINA Plataforma de Agentes CCM MAS Framework

1. RETSINAPlataforma de Agentes CCMMAS Framework Equipe do Curso de ES para SMA {lucena, furtado, choren, viviane}@inf.puc-rio.br

2. RETSINA(Reusable Environment for Task Structured Intelligent Network Agents) Katia Sycara et al. Carnegie Mellon University - EUA

3. O que é RETSINA? • Uma infra-estrutura que oferece um conjunto de tipos de agentes que podem ser adaptados para implementar soluções para domínios específicos • Propósitos • Oferecer módulos re-utilizáveis: comunicação, planejamento, agendamento e monitoramento • Implementar sistemas como sociedades de entidades que respondem a pedidos de execução de tarefas Laboratório de Engenharia de Software (LES) – PUC-Rio

4. Requisitos • Ambientes abertos e dinâmicos • Agentes / serviços nem sempre existirão • Localização dos agentes mudam • Mobilidade • Balanceamento de carga • Identidade dos agentes pode mudar • Não se pode antever seu nome • Não se pode antever o vocabulário usado para descrevê-lo Laboratório de Engenharia de Software (LES) – PUC-Rio

5. Outros Requisitos • Deve-se assumir que existe redundância de serviços • Fornecedores múltiplos / competidores • Diferenças nos parâmetros do serviço • Velocidade • Preço • Segurança • Reputação Laboratório de Engenharia de Software (LES) – PUC-Rio

6. A Arquitetura dos Agentes RETSINA Laboratório de Engenharia de Software (LES) – PUC-Rio

7. A Arquitetura dos Agentes RETSINA • 4 threads paralelas • Communicator • Para comunicação com outros agentes • Planner • Relaciona entradas "sensoriais" e "crenças" a possíveis planos de ação • Scheduler • Agenda planos "habilitados" para execução • Executor Monitor • Executa um plano agendado • Gerencia a execução dos planos (p. ex. troca por plano com maior prioridade) Laboratório de Engenharia de Software (LES) – PUC-Rio

8. A Infra-estrutura RETSINA Laboratório de Engenharia de Software (LES) – PUC-Rio

9. A Infra-estrutura RETSINA • Ambiente de operação • Representam os computadores, sistema operacional, infra-estrutura de rede, etc • Devem ser totalmente transparentes para os agentes • RETSINA exite em Java, C++ / para Windows, Linux e SunOS • Infraestrutura de comunicação • Representam os canais de comunicação entre agentes (camada de transporte) • Prevê o uso de canais síncronos e assíncronos • RETSINA usa os agentes Communicator Laboratório de Engenharia de Software (LES) – PUC-Rio

10. A Infra-estrutura RETSINA • Infra-estrutura de linguagem • Representam a linguagem usada nas mensagens trocadas pelos agentes (FIPA ACL, KQML, etc) • Deve ser modular e alterável • RETSINA oferece KQML • Serviços de gerenciamento • Representam serviços de instalação de agentes, monitoramento de balanceamento de carga, log, etc • Auxiliam o processo de inicialização dos agentes • RETSINA oferece os serviços Logger, Activity Visualizer e Launcher Laboratório de Engenharia de Software (LES) – PUC-Rio

11. A Infra-estrutura RETSINA • Medidas de performance • Servem para otimizar a distribuição de tarefas entre os agentes • Muito baseado em algoritmos de tempo de resposta • RETSINA não oferece suporte a performance • Segurança • Lida com os problemas de segurança do sistema • Oferece uma interface para comunicação com Autoridades de Certificação (?) • RETSINA sabe falar SSL Laboratório de Engenharia de Software (LES) – PUC-Rio

12. A Infra-estrutura RETSINA • Mapeamento de nomes a locais de agentes • Serve para permitir a busca de um agente pelo seu nome • RETSINA oferece o ANS (Agent Naming Service) que permite a atualização dinâmica da localização dos agentes • Mapeamento das funcionalidades dos agentes • Serve para permitir a busca de um agente por sua funcionalidade • RETSINA oferece o A-Match Laboratório de Engenharia de Software (LES) – PUC-Rio

13. A Infra-estrutura RETSINA • Interoperação • Serve para fazer a ligação entre um agente e a infra-estrutura RETSINA • Funciona como um broker entre o agente qualquer e o modelo da arquitetura • Deve ser desenvolvida pelo programador do agente • RETSINA oferece os Agentes "Middle" Laboratório de Engenharia de Software (LES) – PUC-Rio

14. A Arquitetura Funcional do RETSINA Laboratório de Engenharia de Software (LES) – PUC-Rio

15. Agentes de Interface • Requisitam entrada do usuário do sistema multi-agentes • Apresentam resultados aos usuários • Freqüentemente são implementados como uma parte do agente de tarefa • Podem representar um device Laboratório de Engenharia de Software (LES) – PUC-Rio

16. Agentes de Tarefa • Sabem o que fazer e como fazê-lo • Responsáveis por delegar tarefas • Podem requisitar a ajuda de outros agentes de tarefa Laboratório de Engenharia de Software (LES) – PUC-Rio

17. Agentes “Middle” • Agentes de infra-estrutura que ajudam na escalabilidade do sistema • Serviços mais comuns • Serviço de nomes (white pages) • Matchmaker (yellow pages) • Broker Laboratório de Engenharia de Software (LES) – PUC-Rio

18. RETSINA Matchmaker • Permitem que os agentes encontrem uns aos outros • Pela funcionalidade, disponibilidade, etc • Sem saber quem o onde o agente requisitado possa estar • Permite a reconfiguração dinâmica do sistema • Ajuda a manter a escalabilidade do sistema • RETSINA oferece o A-Match http://www-2.cs.cmu.edu/~softagents/a-match/index.html Laboratório de Engenharia de Software (LES) – PUC-Rio

19. O Processo de Matching do A-Match Laboratório de Engenharia de Software (LES) – PUC-Rio

20. Agentes de Informação • Fazem a interface com as fontes de informação no sistema • Normalmente ficam na fronteira entre o sistema e fontes de dados externas • Representam dados e eventos Laboratório de Engenharia de Software (LES) – PUC-Rio

21. Concluindo... • RETSINA é uma infra-estrutura para o desenvolvimento de sistemas multi-agentes • É fechado – não está disponível para download e testes • Katia Sycara • katia@cs.cmu.edu Laboratório de Engenharia de Software (LES) – PUC-Rio

22. Plataforma de Agentes CCM(ADM – Agent Deplyment Model) Fábio Melo LES

23. O que é a Plataforma de Agentes CCM? • Uma plataforma para a implementação de sistemas multi-agentes baseado no CCM (CORBA Compoment Model) • Propósito • Componentização dos agentes • Uso da infra-estrutura CORBA Laboratório de Engenharia de Software (LES) – PUC-Rio

24. O CORBA Component Model • Introduz o conceito de componente (core) e define suas interfaces • Define 4 portas: facetas, receptáculos, fontes de eventos e leitores de eventos Laboratório de Engenharia de Software (LES) – PUC-Rio

25. O CCM • Facetas • Definem as possíveis interfaces que o componente expõe para os demais componentes da aplicação • Um componente deve ter uma referência principal e pode ter diversas facetas que dão suporte a diferentes interfaces e são encaradas como referências distintas ao componente Laboratório de Engenharia de Software (LES) – PUC-Rio

26. O CCM • Receptáculo • Define o ponto de relacionamento estático entre componentes • Assim, um receptáculo permite que um componente declare a sua dependência a uma referência Laboratório de Engenharia de Software (LES) – PUC-Rio

27. O CCM • Fontes e Leitores de Eventos • Implementam o mecanismo de interação publish-subscribe • Um componente é uma fonte de eventos quando declara seu interesse de publicar (para mais de um destino) ou emitir (para um único destino) um evento • Um componente é um leitor de eventos quando tem o interesse em ser notificado quando um determinado evento ocorreu • Fontes e leitores devem estar conectados Laboratório de Engenharia de Software (LES) – PUC-Rio

28. A Plataforma de Agentes CCM (ADM) • Baseado no CCM • Sua definição de agente • Um agente é uma entidade que, em algum ponto da execução do sistema, pode fazer atividades, responder a alguns eventos e gerar alguns eventos novos Laboratório de Engenharia de Software (LES) – PUC-Rio

29. O Agente é uma Entidade • Precisa de uma identidade (auto-representação) no sistema • O componente core é o responsável por ser o núcleo do agente • Armazena a referência principal do agente, seus atributos e gerencia seu estado • É responsável ainda pelo reasoning do agente, tratamento de mensagens e gerenciamento de planos Laboratório de Engenharia de Software (LES) – PUC-Rio

30. O Agente faz Atividades • Atividades são implementadas por planos de ação (componentes plano) • Deve-se definir componentes que serão os planos dos agentes • Estes componentes serão ligados ao core do agente através dos receptáculos Laboratório de Engenharia de Software (LES) – PUC-Rio

31. O Agente responde e gera Eventos • As interfaces usadas para o envio e a recepção de eventos (mensagens) são as fontes e os leitores • Já modelam interações assíncronas por natureza (derivado do modelo CORBA) • Faz a ligação direta entre agentes que se comunicam Laboratório de Engenharia de Software (LES) – PUC-Rio

32. Os Componentes Não-agentes • Os componentes não-agentes (recursos/objetos) do sistema são implementados diretamente como interfaces ou struts (do CCM) • -- FALAR MAIS AQUI Laboratório de Engenharia de Software (LES) – PUC-Rio

33. Generalizando para Organizações • O modelo apresentado serve para implementar um único agente • Uma organização é implementada como um agente • O core identifica a organização • Os agentes da organização estão em seus receptáculos • A comunicação entre agentes dentro de uma mesma organização é feita diretamente entre suas fontes e leitores • A comunicação entre agentes de organizações diferentes é feita através das fontes e leitores da organização Laboratório de Engenharia de Software (LES) – PUC-Rio

34. Vantagens do uso de CCM • Re-uso • Por exemplo de planos já que são implementados como componentes isolados • Adaptação dinâmica • Um agente pode se adaptar ao incluir ou remover planos de seus receptáculos • Modelo de comunicação • Publish-subscribe que é assíncrono e não impõe uma linguagem de comunicação Laboratório de Engenharia de Software (LES) – PUC-Rio

35. Outras Vantagens • Características inerentes do CCM • Segurança • Persistência • Gerenciamento de transações • Funções administrativas feitas pelo modelo • Registro • Localização Laboratório de Engenharia de Software (LES) – PUC-Rio

36. Exemplo de Implementação usando ADM • Sistema de marketplace • Rodadas de negociação • Anúncio de produtos • Formação de grupos • Lances • Completar ou desistir da negociação • Modelado com o ANote • Diagramas de Agente, Planejamento, Interação e Ontologia mapeados para o ADM Laboratório de Engenharia de Software (LES) – PUC-Rio

37. Exemplo de Implementação usando ADM • Classes de Agentes implementadas como especializações do componente core • Planos implementados como especializações do componente plano • Interações implementados como fontes e leitores • Recursos implementados como interfaces ou struts • Organizações implementados como agentes Laboratório de Engenharia de Software (LES) – PUC-Rio

38. Exemplo de Implementação usando ADM Laboratório de Engenharia de Software (LES) – PUC-Rio

39. Exemplo de Implementação usando ADM Laboratório de Engenharia de Software (LES) – PUC-Rio

40. Exemplo de Implementação usando ADM Laboratório de Engenharia de Software (LES) – PUC-Rio

41. Exemplo de Implementação usando ADM Laboratório de Engenharia de Software (LES) – PUC-Rio

42. Exemplo de Implementação usando ADM • Componente core  extensão da interface IAgent • Cria todas as características do agente como start up, instanciação de planos e envio de mensagens Laboratório de Engenharia de Software (LES) – PUC-Rio

43. Exemplo de Implementação usando ADM • Componente plano  extensão da interface IPlan • Definicção do método que implementa o plano • Deve ter uma referência para o componente core de todos os agentes que podem executá-lo Laboratório de Engenharia de Software (LES) – PUC-Rio

44. Exemplo de Implementação usando ADM • Mensagem  evento • Recurso  struct (ou interface) Laboratório de Engenharia de Software (LES) – PUC-Rio

45. Concluindo... • O ADM é uma plataforma para o desenvolvimento de sistemas multi-agentes • Implementa o modelo CCM • Um agente • Componente core • Componentes planos • Fontes e leitores de envetos • Uma organização • Como um agente • Recursos (itens não-agentes) • Interfaces ou struts Laboratório de Engenharia de Software (LES) – PUC-Rio

46. MAS Framework José Alberto Sardinha LEARN

47. O que é MAS Framework? • Um framework orientado a objetos para a construção de aplicações baseadas em agentes • Sistemas multi-agentes em ambiente distribuídos • Propósitos • Acelera o desenvolvimento de aplicações • Faz re-uso de código • Reduz a complexidade de desenvolvimento de sistemas baseados em agentes Laboratório de Engenharia de Software (LES) – PUC-Rio

48. Motivação • Inicialmente o MAS Framework foi desenvolvido influenciado pela metodologia GAIA • Definição de papéis de agentes • Divisão entre protocolos de interação e serviços • Evoluiu para um framework de agentes distribuídos de propósito geral • Papéis/tipos de agentes definidos através de herança • Infra-estrutura de comunicação baseada no IBM TSpaces Laboratório de Engenharia de Software (LES) – PUC-Rio

49. O MAS Framework • É composto por • Uma classe abstrata • Agent • Duas classes públicas • AgentCommunicationLayer • ProcessMessageThread • Quatro interfaces • AgentInterface • InteractionProtocols • AgentMessage • AgentBlackboardInfo Laboratório de Engenharia de Software (LES) – PUC-Rio

50. O MAS Framework Laboratório de Engenharia de Software (LES) – PUC-Rio