Arquitetura para o Reuso de Ações em Sistemas Multi-Agentes

Transcrição

1 Título: Arquitetura para Reuso de Ações em Sistemas Multi-Agentes Aluno: Mauro Monteiro Silva Orientador: Ricardo Choren Nível: Mestrado Programa de Pós-Graduação: Programa de Mestrado em Sistema e Computação do IME/RJ mauro@de9.ime.eb.br choren@de9.ime.eb.br Ano de Ingresso: 2004 Previsão para Conclusão: dezembro/2005 Aprovação da Proposta de Dissertação: março/2005 Resumo. O objetivo desse artigo é propor uma arquitetura para sistemas Multi-Agentes (SMA), onde haja um desacoplamento entre os agentes e ações. Um outro objetivo a ser alcançado é a definição de uma organização interna para agente que suporte a arquitetura proposta, pois o agente deve ter mecanismos que façam a busca e instanciação correta de ações. Através dessa abordagem, espera-se aumentar o nível de reuso nos SMA, mantendo a arquitetura em conformidade com a especificação FIPA-OS. Palavras-Chaves. Sistemas Multi-Agentes, Arquiteturas, Web Services, SOA, Reuso.

2 Arquitetura para o Reuso de Ações em Sistemas Multi-Agentes Mauro Monteiro Silva, Ricardo Choren SE/9 Seção de Engenharia de Sistemas e Computação Instituto Militar de Engenharia Rio de Janeiro {mauro, choren}@de9.ime.eb.br Abstract. The aim of this paper is to propose an architecture for Multi-Agent System (MAS), where agents and actions are uncoupled. The other aim to be achieved is to define an internal agent organisation which supports this architecture. This is necessary because agents must have mechanisms that allow them to find and execute plans and actions in a correct way. With this approach, we are trying to increase the reusability level on MAS, keeping this architecture in compliance with FIPA-OS architecture. Resumo. O objetivo desse artigo é propor uma arquitetura para sistemas Multi- Agentes (SMA), onde haja um desacoplamento entre os agentes e ações. Um outro objetivo a ser alcançado é a definição de uma organização interna para agente que suporte a arquitetura proposta, pois o agente deve ter mecanismos que façam a busca e instanciação correta de ações. Através dessa abordagem, espera-se aumentar o nível de reuso nos SMA, mantendo a arquitetura em conformidade com a especificação FIPA-OS. 1. Caracterização do Problema Para facilitar o desenvolvimento de sistemas Multi-Agentes, muitas arquiteturas e ferramentas foram propostas. Dentre essas se pode destacar: ambiente JADE [Bellifemine et. al., 2005] que é baseado na especificação FIPA-OS [Silva, 2003], ZEUS [Nwana et. al., 1999] e RETSINA [Sycara et. al., 2003]. Todas elas apresentam características que escondem os detalhes técnicos dos desenvolvedores, porém, elas não consideram o reuso de ações implementadas pelos agentes, pois as ações estão fortemente ligadas a eles. 2. Fundamentação Teórica O presente trabalho se fundamenta, principalmente, em conhecimentos existentes em duas abordagens. A primeira é a baseada em Sistemas Multi-Agentes e a segunda é baseada na Arquitetura Orientada a Serviços (SOA). As duas são descritas sucintamente abaixo. 2.1 Sistemas Multi-Agentes A abordagem conhecida como Sistemas Multi-Agentes (SMA) é utilizada no desenvolvimento de sistemas distribuídos complexos. A abstração chave utilizada é os agentes de software, que podem interagir com outros agentes gerando os SMA. Essa abordagem pode reduzir o custo e a complexidade associados ao desenvolvimento de sistemas distribuídos [Jennings and Wooldridge, 1999]. Ainda existe muita controvérsia a respeito da definição exata sobre o que vem a ser um agente de software. Contudo, um grande número de pesquisadores considera a seguinte definição útil: Um agente é um sistema de computador encapsulado que está

3 situado em algum ambiente e que é capaz de ser flexível e de ter ações autônomas que permitem atingir os seus objetivos de projeto [Jennings and Wooldridge, 1999]. 2.2 Arquitetura Orientada a Serviço Essa abordagem define uma arquitetura conceitual cujo principal aspecto é a separação entre a implementação do serviço da sua interface. Devido essa separação, o consumidor não precisa conhecer informações relacionadas à implementação física do serviço, necessitando apenas, conhecer informações referentes ao contrato de utilização desse. A partir dessas informações, o Consumidor, baseado no paradigma localizar, ligar, executar, pode utilizar o serviço. Dentre os principais benefícios dessa abordagem se pode destacar [McGovern et. al., 2003]: baixo acoplamento, transparência na localização dos serviços e aumento da interoperabilidade. O primeiro é conseguido através do uso de contratos e amarrações. Já o segundo permite que o consumidor só conheça a localização do serviço ao interpretar o contrato deste. Por último, a interoperabilidade permite que diferentes plataformas sejam utilizadas em uma mesma aplicação. 3. Caracterização da Contribuição Para permitir que sistemas Multi-Agentes aumentem o reuso de ações, acredita-se que a arquitetura deva encorajar os desenvolvedores a implementarem seus agentes com esse objetivo. Por isso, nossa proposta consiste em criar uma arquitetura orientada a serviços para SMA, com a criação de repositórios de ações que permitam aos agentes compartilhálas de forma transparente. Apesar do desacoplamento entre os agentes e as ações, as características que identificam os agentes continuam intrínsecas as eles. Ou seja, os agentes continuam tendo a capacidade de reagir ao ambiente, buscar seus objetivos, executar ações, etc. Agora, porém, os agentes não terão o conhecimento prévio da localização das ações. Com isso, permite-se alterar a implementação das ações, mantendo-se a sua interface, sem que isso provoque alterações nos SMA. Para atingir esses objetivos, os agentes devem ter mecanismos que permitam descobrir e executar ações existentes nos repositórios. Ou seja, antes de executar uma ação o agente deve verificar se a ação desejada está disponível e onde ela se encontra. Após isso, o agente deve se ligar à ação e executá-la. A correta seqüência das ações será dada pelo plano que o agente está executando. Na próxima subseção serão introduzidos detalhes da arquitetura externa. Após, introduz-se a organização interna do agente. Por último, descreve-se as contribuições esperadas dessa arquitetura. 3.1 Arquitetura externa A arquitetura proposta será orientada a serviços, pois divide os agentes em seus serviços (ações), cujas interações são governadas por contratos baseados em mensagens. Os agentes não implementarão diretamente as ações, ao invés disso, essas estarão disponíveis em repositórios. Os detalhes da busca das ações devem ser transparentes para os agentes, pois a localização da ação é uma funcionalidade que deve ser oferecida pela própria arquitetura. A arquitetura deve prover registros onde os contratos serão armazenados e mecanismos que permitam aos agentes descobrirem esses contratos.

4 O agente deve se anunciar ao entrar em uma sociedade para que os outros agentes possam saber de sua existência. Para isso, a arquitetura disponibiliza uma entidade, em conformidade com a especificação FIPA, que é responsável pelo registro do agente e pela sua publicação para os demais membros da sociedade. Durante esse registro, o agente recebe o endereço de um facilitador, chamado de Action Discoverer (AD), que é o responsável pela busca de ações. Esse facilitador conhece a localização dos registros de serviços cuja atualização é responsabilidade externa. A partir desse momento, o agente pode interagir com outros agentes e buscar seus objetivos. Então, quando for preciso executar uma ação, ele deve enviar uma mensagem para o facilitador AD informando a interface e a semântica da ação. Com essas informações, o AD irá verificar se a ação desejada foi publicada nos registros de serviços de seu conhecimento. Caso a ação não seja encontrada nos registros, o AD pode se comunicar com facilitadores de outros ambientes em busca da ação desejada. O AD pode retornar dois resultados possíveis: uma mensagem de falha ou uma lista com os contratos existentes para ação procurada. O resultado é enviado de volta para o agente solicitante através de uma mensagem. Ele escolhe qual ação será utilizada e realiza sua chamada. O critério que será utilizado para escolha da ação será baseado na proximidade dessa, pois a intenção é reduzir o tráfego na rede. Ou seja, será escolhida a ação mais próxima do agente. A figura 1 demonstra a arquitetura proposta. Agent 1 Service semantic Services Registry Agent 2 Agent 3 Request service, Semantic and Result wsdl Action Discoverer (AD)... SOAP + HTTP/SSL Agent Container (FIFA compliance) Services Registry Web Services RMI-IIOP SOAP RMI RMI-IIOP Java, C++, C#, VB, etc.. J2EE Web Services CORBA Fig. 1: Arquitetura para o reuso de ações 3.2 Organização Interna Para atingir seus objetivos, os agentes devem executar planos que descrevem a seqüência de ações necessárias. Então, os agentes devem possuir uma base interna de planos (Plan Library) onde estes serão armazenados. Para escolher um plano, a estrutura interna do agente providencia um componente chamado Planner que é o responsável pela pesquisa na base interna do agente. O plano encontrado é retornado para um outro componente chamado de Co-Ordination Engine (CE) que é responsável pela instanciação e execução do plano. Durante a execução do plano, ações devem ser executadas. Então, o componente CE envia mensagens para o facilitador AD solicitando o contrato de uma determinada ação. Ao receber a mensagem com a resposta da busca, o agente escolhe qual contrato deve ser utilizado. O contrato escolhido é enviado para o Action Scheduler (AS) que é um hot spot proposto.

5 Todos os detalhes necessários para interpretar o contrato, bem como para localizar, amarrar e executar a ação ficam encapsulados no AS. Ou seja, o componente CE não precisa conhecer esses detalhes para conseguir executar a ação. Ao término da execução, o resultado é enviado para o CE. Toda a comunicação entre a organização interna do agente e o ambiente externo ocorre através do Mailbox Manager (MBM). A figura 2 ilustra a arquitetura proposta. Communication Channel Action Scheduler (AS) Co-Ordination Engine Mail Box Manager Planner Gets plan Plan Library Internal Agent Organisation Fig. 2: Organização interna do Agente 3.3 Contribuições Esperadas As contribuições esperadas são: aumento da reusabilidade, extensibilidade e confiabilidade. O aumento da reusabilidade é conseqüência da redução do acoplamento entre o agente e as ações e da criação de mecanismos que garantam a transparência da localização da ação. Ao atingir esse primeiro objetivo, espera-se como conseqüência, um aumento no nível de extensibilidade do SMA. Permitindo que os agentes executem novas ações através da utilização do paradigma localizar, ligar e executar. Uma outra conseqüência indireta é o aumento no nível de confiabilidade, pois ao implementar as ações fora dos agentes, regras podem ser definidas para garantir a qualidade das ações publicadas. 4. Metodologia e Estado Atual do Trabalho A metodologia utilizada consiste em estudar as arquiteturas propostas para SMA, tendo a especificação definida pela FIPA como referência, estudar os conceitos existentes na abordagem SOA, bem como, a tecnologia utilizada para sua implementação, Serviços Web. No estágio atual da pesquisa já se tem definido um esboço da arquitetura, sendo ainda necessário um maior detalhamento. Ainda é necessário estudar SOA e Web Services, bem como estudar o ambiente de desenvolvimento JADE. 5. Trabalhos relacionados Existem várias arquiteturas disponíveis. A FIPA-OS propõe três serviços básicos [Ulieru, Cobzaru and Norrie, 2001]: o AMS (Agent Management System), o DF (Directory Facilitator) e ACC (Agent Communication Channel). O AMS é responsável pelo gerenciamento dos outros agentes. O DF provê serviço de Paginas Amarelas e o ACC usa as informações disponibilizadas pelo AMS para habilitar a comunicação entre agentes. Durante a execução do agente, ele deve adicionar comportamentos que implementam os passos necessários para atingir os seus objetivos. O agente tem um conhecimento prévio da existência dos comportamentos e, ao adicioná-los, cada comportamento se refere a um agente. Com isso, cria-se uma forte ligação entre o agente e os comportamentos, o que não permite que outros agentes utilizem comportamentos existentes sem redundá-los.

6 O ambiente ZEUS é formado por um conjunto de componentes que são organizados em três grupos ou bibliotecas [Nwana et. al., 1999]: biblioteca de componente de agentes, ferramentas para construção de agentes e um conjunto de utilitário que compreende nameserver, facilitadores e agentes de visualização. No ZEUS as ações externas são implementadas por classes que estendem a classe ZeusExternal e, que são informadas como argumento na chamada do agente. Ou seja, os agentes têm um conhecimento prévio da existência das ações, criando uma forte ligação entre eles. O que induz o desenvolvedor a redundar ações entre sistemas diferentes. A arquitetura de agente RETSINA [Sycara et. al., 2003] implementa a Rede de Tarefas Hierárquicas (Hierarchical Task Network), planejando, monitorando e executando através de três threads paralelas enquanto uma quarta thread, o comunicador, provê uma forma do agente se comunicar com ambiente. Nessa arquitetura, os agentes possuem uma base interna de planos, com as respectivas ações. A escolha do plano é orientada pelo objetivo a ser alcançado. Ou seja, o agente, a partir de um determinado objetivo, escolhe um plano, as ações desse plano são habilitadas e agendadas, uma vez que as ações estão internas aos agentes. 6. Validação dos Resultados O desenvolvimento da arquitetura proposta consistirá na extensão dos componentes da arquitetura FIPA-OS, cuja implementação será feita na ferramenta JADE. Com isso, os desenvolvedores poderão utilizar as facilidades descritas de forma transparente. Para validar o reuso das ações, serão criados dois estudos de caso: o primeiro será desenvolvido utilizando a ferramenta JADE, onde as ações serão implementadas através da criação de behaviours. O segundo utilizará a arquitetura proposta, com a publicação das ações em repositórios distribuídos. Através desses dois estudos de caso, poder-se-á comparar as vantagens e desvantagens de cada abordagem, bem como verificar qual delas facilita mais o reuso de ações e seus desempenhos. 7. Referências Bibliográficas Jennings, N. R. and Wooldridge M. (1999) Agent-Oriented Software Engineering. In 9 th European Workshop on Modelling Autonomous Agents in a Multi-Agent World. Bellifemine, F., Caire, G., Trucco, T. and Rimassa, G. (2005) JADE Programmer s Guide, JADE 3.3. Silva, L., (2003) Estudo e Desenvolvimento de Sistemas Multi-agentes usando JADE. Nwana H. S., Ndumu D. T., Lee, L. C. and Collis J. C. (1999) ZEUS: A Toolkit for Building Distributed Multi-Agent Systems, in Third International Conference on Autonomous Agents. Sycara, K., Giampapa, J. A., Langley, B., Paolucci, M. (2003) The Retsina MAS, a case study McGovern, J., Sameer, T., Stevens, M., Mathew, S. (2003) Java Web Services Architecture. Morgan Kaufmann Publishers. Ulieru, M., Cobzaru, M. and Norrie, D. (2001) A FIPA-OS Based Multi-Agent Architecture for Global supply Chain Applications, in Intelligent Processing and Manufacturing of Materials.