um sistema para compartilhamento de arquivos …silveira/ine602200/artigos/tcc_igoribas.pdf ·...
TRANSCRIPT
UNIVERSIDADE FEDERAL DE PELOTAS
INSTITUTO DE FÍSICA E MATEMÁTICA
DEPARTAMENTO DE MATEMÁTICA, ESTATÍSTICA E COMPUTAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
UM SISTEMA PARA COMPARTILHAMENTO DE ARQUIVOS EM REDES P2P
UTILIZANDO UMA ABORDAGEM MULTIAGENTES
por
IGOR KOTH RIBAS
Monografia apresentada ao Curso de Bacharelado em Ciência da Computação da
Universidade Fededral de Pelotas como requisito parcial à obtenção do título de Bacharel
em Ciência da Computação.
Prof. Dr. Ricardo Azambuja Silveira Orientador
Pelotas, março de 2003.
II
Este trabalho é dedicado aos meus pais, que nunca
mediram esforços para me proporcionar uma
educação de qualidade. Agradeço o meu orientador,
por acreditar na minha capacidade de desenvolver
este trabalho. Também agradeço a todos os
professores e colegas por estes quatro anos de
convivência. E para finalizar, agradeço a todos os
meus verdadeiros amigos e todo mundo que sempre
me deu uma força. Valeu!
III
Sumário Lista de Abreviaturas ...................................................................................V
Lista de Figuras...........................................................................................VI
Lista de Tabelas ........................................................................................ VII
Resumo ....................................................................................................VIII
Abstract ....................................................................................................... IX
1 Introdução.................................................................................... 10
1.1 Motivação ....................................................................................................... 11 1.2 Objetivos ......................................................................................................... 13 2 Compartilhamento de Arquivos em Redes de Computadores 16
2.1 Introdução ....................................................................................................... 16 2.2 Modelo cliente-servidor .................................................................................. 17 2.3 Modelo P2P..................................................................................................... 18 2.3.1 Modelo P2P puro ............................................................................................ 19 2.3.2 Modelo P2P com servidor de registro de pontos ............................................ 19 2.3.3 Modelo P2P com servidores de registro de pontos e consulta........................ 20 2.4 Modelo P2P e compartilhamento de arquivos ................................................ 21 2.5 Exemplo de aplicações P2P para compartilhamento de arquivos................... 23 3 Inteligência Artificial Distribuída.............................................. 24
3.1 Definição de agentes ....................................................................................... 24 3.2 Resolução distribuída de problemas e sistemas multiagentes......................... 27 3.3 Considerações sobre sistemas multiagentes.................................................... 28 3.3.1 Classificação de sistemas multiagentes .......................................................... 28 3.3.2 Sistemas multiagentes homogêneos e heterogêneos....................................... 28 3.3.3 Métodos de coordenação................................................................................. 28 3.4 Comunicação em sistemas multiagentes......................................................... 30 3.5 Ferramentas para construção de sistemas multiagentes.................................. 35 4 FIPA e FIPA-OS.......................................................................... 37
4.1 Introdução ....................................................................................................... 37 4.2 Arquitetura Abstrata FIPA.............................................................................. 38 4.2.1 Serviços........................................................................................................... 39 4.1.1.1 Serviço diretório de agente – ADS ................................................................. 40 4.2.1.2 Serviço diretório de serviços – SDS ............................................................... 41 4.2.1.3 Serviço transporte de mensagens – MTS........................................................ 41
IV
4.3 Gerenciamento de Agentes ............................................................................. 42 4.3.1 Identificação de agentes.................................................................................. 43 4.3.2 Facilitador de diretório – DF........................................................................... 44 4.3.3 Sistema de gerenciamento de agentes – MAS ................................................ 45 4.3.4 Serviço de transporte de mensagens – MTS................................................... 45 4.3.4.1 Envelope ......................................................................................................... 46 4.3.4.2 Carga útil......................................................................................................... 47 4.3.4.3 Canal de comunicação de agente – ACC........................................................ 47 4.4 A linguagem de comunicação de agentes – ACL ........................................... 49 4.4.1 Estrutura da mensagem FIPA ACL ................................................................ 49 4.4.2 Atos de comunicação ...................................................................................... 51 4.4.3 Linguagem de conteúdo.................................................................................. 52 4.4.4 Protocolos de interação................................................................................... 53 4.5 Transporte de mensagens de agente................................................................ 55 4.5.1 IIOP................................................................................................................. 55 4.5.2 WAP................................................................................................................ 55 4.5.3 HTTP............................................................................................................... 56 4.6 FIPA-OS ......................................................................................................... 56 4.6.1 Distribuição FIPA-OS..................................................................................... 57 4.6.2 Componentes FIPA-OS .................................................................................. 58 4.6.2.1 Implementação do agente ............................................................................... 58 4.6.2.2 Estrutura de agente JESS - JESS Agent Shell ................................................. 58 4.6.2.3 Estrutura de agente - Agent Shell .................................................................... 59 4.6.2.4 Gerenciador de tarefas .................................................................................... 59 4.6.2.5 Gerenciador de conversações – CM ............................................................... 61 4.6.2.6 Serviço de Transporte de Mensagem - MTS .................................................. 61 4.6.2.7 Protocolos de transporte de mensagens - MTP............................................... 62 4.6.3 Configuração e execução do ambiente FIPA-OS ........................................... 63 5 Sistema de Compartilhamento de Arquivos para FIPA-OS... 65
5.1 Visão geral ...................................................................................................... 65 5.2 Descrição dos agentes ..................................................................................... 65 5.2.1 File Finder Agent – FFA................................................................................. 66 5.2.1.1 Modelo interno do FFA .................................................................................. 68 5.2.1.2 Interação interface gráfica – FFA ................................................................... 69 5.2.2 Shared Folders Manager Agent – SFMA........................................................ 70 5.2.2.1 Modelo interno do SFMA............................................................................... 72 5.2.2.2 Interação interface gráfica – SFMA................................................................ 74 5.3 Modelo de organização do sistema de compartilhamento de arquivos........... 75 5.4 O modelo de troca de mensagens.................................................................... 76 5.5 Execução do sistema ....................................................................................... 78 6 Conclusão ..................................................................................... 79
7 Bibliografia................................................................................... 82
V
Lista de Abreviaturas ACC Agent Communication Channel ACL Agent Communication Language ADE Agent-Directory-Entry ADS Agent-Directory-Service AI Artificial Intelligence AID Agent Identification AMS Agent Management System AP Agent Platform CCL Constraint Choice Language CCL Constraint Choice Language CSP Constraint Satisfaction Problem DAI Distributed Artificial Intelligence DARPA Defense Advanced Research Projects Agency DF Directory Facilitator DPS Distributed Problem Solving DS Distributed Systems FFA File Finder Agent FIPA Foundation for Intelligent Physical Agents FIPA-OS Foundation for Intelligent Physical Agents Open Systems FTP File Transfer Protocol HTTP HyperText Transfer Protocol IIOP Internet InterORB Protocol JESS Java Expert System Shell JVM Java Virtual Machine KIF Knowledge Interchange Format KIF Knowledge Interchange Format KQML Knowledge Query and Manipulation Language MAS Multiagent Systems MTP Message Transport Protocol MTS Message-Transport-Service OMG Object Management Group P2P Point-to-point RDF Resource Description Framework RDF Resource Description Framework RMI Remote Method Invocation SDS Service-Directory-Service SFMA Shared Folders Manager Agent SL Semantic Language SL Semantic Language SMS Short Message Service SMTP Simple Mail Transfer Protocol TCP/IP Transport Control Protocol / Internet Protocol TM Task Manager WAP Wireless Application Protocol
VI
Lista de Figuras FIGURA 1 – Exemplo de comunicação em um modelo cliente-servidor. ....................... 18 FIGURA 2 – Modelo P2P puro. ....................................................................................... 19 FIGURA 3 – Modelo P2P com servidor de registro de pontos. ....................................... 20 FIGURA 4 – Modelo P2P com servidores de registro de pontos e procura. .................... 21 FIGURA 5 – Modelo físico do sistema de compartilhamento de arquivos P2P. ............. 22 FIGURA 6 – Modelo lógico do sistema de compartilhamento de arquivos P2P. ............ 22 FIGURA 7 – Classificação da DAI .................................................................................. 27 FIGURA 8 – Classificação de tipos de coordenação de agentes. ..................................... 29 FIGURA 9 – Exemplo de modelo de camadas para comunicação de agentes. ................ 34 FIGURA 10 – Modelo de serviços da arquitetura abstrata FIPA. .................................... 39 FIGURA 11 – Representação de uma Entrada de Diretório de Agente – ADE. .............. 41 FIGURA 12 – Modelo de gerenciamento de agentes FIPA. ............................................ 43 FIGURA 13 – Transformação de uma mensagem em mensagem de transporte.............. 46 FIGURA 14 – Formas de comunicação entre agentes de plataformas diferentes. ........... 48 FIGURA 15 – Visão geral dos componentes FIPA-OS.................................................... 58 FIGURA 16 – Composição lógica do modelo de camadas do MTS do FIPA-OS. .......... 62 FIGURA 17 – Interface gráfica do AgentLoader. ............................................................ 64 FIGURA 18 – Interface gráfica do agent FFA. ................................................................ 67 FIGURA 19 – Modelo interno do FFA............................................................................. 68 FIGURA 20 – Interação interface gráfica – FFA. ............................................................ 70 FIGURA 21 – Interface gráfica do SFMA. ...................................................................... 72 FIGURA 22 – Modelo interno do SFMA. ........................................................................ 73 FIGURA 23 – Interação interface gráfica – SFMA.......................................................... 75 FIGURA 24 – Modelo de troca de mensagens. ................................................................ 76
VII
Lista de Tabelas
TABELA 1– Todos os parâmetros de uma mensagem FIPA ACL. ................................. 49 TABELA 2 – Performativas FIPA.................................................................................... 51 TABELA 3 – Protocolos Padrão de Interação FIPA. ....................................................... 54 TABELA 4 – Pacotes FIPA-OS. ...................................................................................... 57 TABELA 5 – Eventos tratados por um TM...................................................................... 60
VIII
Resumo
O termo redes ponto-a-ponto (P2P) refere-se a um modelo de redes de
computadores baseado em sistemas e aplicações que empregam recursos distribuídos para
executar uma função de forma descentralizada. Atualmente, um tipo muito popular de
aplicação P2P é o sistema para compartilhamento de arquivos. O rápido crescimento da
Internet colabora para novos lançamentos de aplicações para redes de compartilhamento
de arquivos.
Apesar de inúmeras aplicações para compartilhamento de arquivos tornarem-se
disponíveis a cada dia, poucas destas novas aplicações apresentam alguma novidade no
que se refere à abordagem de desenvolvimento. O comportamento cooperativo que os
sistemas de compartilhamento arquivos em redes de computadores apresentam já é por si
só uma justificativa para utilizar uma abordagem de desenvolvimento multiagentes para
estes sistemas.
Este trabalho tem por objetivo apresentar um sistema para compartilhamento de
arquivos em redes P2P utilizando uma abordagem multiagentes com o auxílio da
ferramenta de desenvolvimento de agentes FIPA-OS (Foundation for Intelligent Physical
Agents Open Systems).
Palavras-chave: Sistemas Multiagentes, Sistemas Distribuídos, Compartilhamento de
Arquivos, FIPA, P2P.
IX
Abstract
The term peer-to-peer (P2P) refers to a computer network model based on
systems and applications that use distributed resources in a descentralized way. Actually,
a very popular type of P2P application is the file-sharing system. The fast Internet
growing contributes with new releases of applications for file-sharing networks.
Despite of many file-sharing applications became available every day, just a
few of then introduces something new in which refers to the development approach. The
computer network file-sharing systems cooperative behavior for itself justifies the use of
a multiagent development approach for those systems.
The goal of this work is to introduce a P2P network file-sharing system using a
multiagent approach, supported by the agent development toolkit FIPA-OS (Foundation
for Intelligent Physical Agents Open Systems).
Keywords: Multiagent Systems, Distributed Systems, File-Sharing, FIPA, P2P.
10
1 Introdução
Em um mundo onde a Internet é cada vez mais popular, soluções baseadas em
redes ponto-a-ponto (peer-to-peer – P2P) estão cada vez mais em evidência [ORA 2001].
Existem várias definições para o modelo de comunicação P2P. o termo P2P refere-se a
uma classe de sistemas e aplicações que empregam recursos distribuídos para executar
uma função de forma descentralizada [MIL 2002].
Muito se tem falado atualmente deste modelo de interligação de redes de
computadores, dando a idéia para muitos que este modelo é uma tecnologia recente. A
área de Sistemas Distribuídos (Distributed Systems – DS) [COU 94] já utiliza este
modelo de pontos (também chamados nodos) altamente acoplados, para
compartilhamento de recursos computacionais como forma de aumentar o desempenho
na resolução de problemas complexos. Dois computadores ligados um ao outro também é
um exemplo muito simples de rede P2P. A nomenclatura P2P é recente, o modelo ponto-
a-ponto não.
Grande parte da mídia em torno do modelo P2P se deve ao fato do sucesso de
softwares para compartilhamento de arquivos através da Internet que utilizam o modelo
P2P de comunicação. Com a rápida expansão da Internet e com o custo cada vez menor
das redes de alta velocidade, os usuários de redes de computadores têm cada vez mais
acesso a uma gigantesca quantidade de informação. Essa informação pode ser acessada
em tempo real, como é o caso das rádios de música que existem na Internet, entretanto
grande parte desta informação ainda é fornecida na forma de arquivos. Por isso é
necessário um serviço de rede que se encarregue de encontrar a informação na forma de
arquivos. Os sistemas de compartilhamento de arquivos via Internet utilizando o modelo
P2P surgiram para resolver este problema.
Um sistema de compartilhamento de arquivos que utiliza o modelo P2P consiste
basicamente de um número variável de nodos (hosts da rede) que disponibilizam uma
quantidade limitada de seus arquivos para outros nodos da rede. Qualquer nodo da rede é
acessível por todos os nodos, de forma direta. A comunicação direta entre os nodos da
11
rede tem a vantagem de evitar possíveis pontos de gargalo (bottleneck) que são comuns
em sistemas centralizados.
Uma característica comum a todos os sistemas P2P para compartilhamento de
arquivos é a existência de um modelo de comunicação de rede que, no nível de aplicação,
define uma rede virtual com seus próprios mecanismos de roteamento de dados [RIP
2002]. A topologia desta rede virtual e os mecanismos de roteamento de dados definem
de forma significativa propriedades da aplicação tais como: desempenho, segurança e
anonimato do usuário. A topologia também define os custos em termos de recursos
operacionais.
Outra característica marcante é que estes sistemas são formados por uma
configuração de ambiente definidos por uma arquitetura distribuída, diferentes de outras
formas de compartilhamento de arquivos, que são definidos por uma arquitetura
centralizada.
O conjunto de características de sistemas que utilizam o modelo P2P para
compartilhamento de arquivos aponta para o desenvolvimento destes sistemas com o
auxílio de recursos da Inteligência Artificial. A forma cooperativa com que cada nodo do
sistema se comporta e as interações entre cada nodo, através de negociações, concessões,
propostas e consultas pode ser modelada através de uma abordagem de desenvolvimento
de software orientado a agentes [BIG 2001].
Este trabalho situa-se no contexto de Sistemas Distribuídos, mais
especificamente na abordagem de Inteligência Artificial Distribuída (Distributed
Artificial Intelligence – DAI) [FER 99] e contempla a utilização de sistemas multiagentes
(Multiagent Systems – MAS) [SYC 98] interconectados pela Internet como instrumento
para compartilhar arquivos.
A seguir, serão discutidos as motivações e objetivos desta monografia.
1.1 Motivação
À medida que redes de computadores se tornam cada vez mais comuns e mais
pessoas têm acesso a essa tecnologia, é natural que sistemas de informática tornem-se
cada vez mais interligados, utilizando a abordagem distribuída. Sistemas distribuídos
12
estão se tornando a principal forma de troca e armazenamento de arquivos. Como
conseqüência, algum tipo de suporte para interação com usuário, coordenação e
integração de informações de sistemas heterogêneos torna-se essencial.
Uma grande motivação para utilização de sistemas P2P é a forma como a
Internet é organizada. O modelo de endereçamento utilizado na Internet é o de número IP
(Internet Protocol) de 32 bits, chamado Ipv4. O número fixo de endereços possíveis
(chamados endereços IP) com esse modelo é, teoricamente, 4.294.967.296, mas na
prática esse número é menor porque alguns endereços IP são reservados e não podem ser
usados.
Com o já citado fato da crescente popularização da Internet, cada vez mais
computadores são adicionados à rede e a quantidade limitada de endereços IP começou a
causar grandes transtornos, pois cada computador na rede deve ter um endereço IP
distinto. Para contornar esse problema, os endereços IP da maioria dos computadores
conectados a rede começou a ser atribuído de forma dinâmica, técnica conhecida por
endereçamento por IP dinâmico [TAN 97]. O endereço IP dinâmico é atribuído por um
servidor DHCP (Dynamic Host Configuration Protocol). A desvantagem dessa técnica é
que o computador que tiver seu endereço IP atribuído por DHCP nem sempre vai possuir
o mesmo endereço IP. O endereço IP pode mudar a cada vez que esse computador se
conecta a rede (por isso é chamado de endereço IP dinâmico).
Caso um usuário de uma rede deseje transferir um arquivo de um computador
remoto para o seu computador, basta o usuário saber o endereço IP do computador
remoto e o número da porta de serviço [TAN 97] para transferir o arquivo. Só que caso o
endereço IP do computador remoto seja atribuído de forma dinâmica, não há como o
usuário ter certeza do número do endereço IP do computador remoto.
No sistema de compartilhamento de arquivos através de rede P2P que este
trabalho propõe, esse problema não ocorre porque o usuário não precisa saber o endereço
IP do computador que possui o arquivo que ele deseja transferir. Na verdade, devido ao
modelo de organização do sistema, o usuário não precisa saber qual computador possui o
arquivo. O usuário deve fornecer somente o nome do arquivo para o sistema e o próprio
sistema se encarrega dos mecanismos de consulta e procura de arquivos. Essa
13
transparência de localização é uma importante característica dos sistemas de
compartilhamento de arquivos P2P.
O processo estabelecido nas consultas e requisições por arquivos entre os nodos
do sistema deve ser feito de forma coordenada. Este processo normalmente segue um
protocolo bem definido de troca de mensagens, com o objetivo de negociar uma
transferência de arquivo. Uma abordagem natural para resolução deste tipo de problema é
a abordagem multiagente [FER 99]. Um sistema multiagentes pode ser definido como um
sistema composto por um conjunto de entidades especializadas, chamadas agentes, que se
comunicam para atingir um objetivo, que pode ser global ou individual [ATT 2000]. É
justamente esta característica de comunicação, para estabelecer compromissos de
cooperação ou para negociações, que tornam a abordagem multiagentes ideal para
modelar sistemas de compartilhamento de arquivos P2P. Cada agente representa um nodo
do sistema, que estabelece um vínculo de cooperação (transferência de arquivo) através
da negociação por troca de mensagens.
Ambientes para desenvolvimento e modelagem de agentes de software
encontram-se atualmente em um estado avançado de desenvolvimento. Ferramentas
como ZEUS [ZEU 2002] e FIPA-OS [FIPA 2002p] são largamente utilizadas no meio
acadêmico em todo o mundo. Ambas são totalmente desenvolvidas em Java. Java é muito
utilizada no desenvolvimento deste tipo de ferramenta devido às facilidades que esta
linguagem de programação oferece para contornar dificuldades que surgem em
desenvolver sistemas distribuídos. O FIPA-OS ainda possui a vantagem de seguir um
conjunto de especificações para interoperação de sistemas multiagentes chamada FIPA.
Estas especificações fornecem meios para que qualquer sistema multiagente
implementado com ferramentas compatíveis com estas especificações possam
interoperar.
1.2 Objetivos
A partir do que foi descrito até agora, em especial a motivação, é possível
destacar os principais objetivos que este trabalho pretende atingir. O objetivo deste
trabalho é implementar e apresentar um software para compartilhamento de arquivos em
14
rede, utilizando o modelo P2P de conectividade. Para que este objetivo geral seja
alcançado, alguns objetivos específicos foram estabelecidos:
− propor uma arquitetura de sociedade de agentes que possa ser aplicada na
implementação do sistema de compartilhamento de arquivos;
− organizar esta arquitetura de forma que cada agente represente um nodo
do sistema;
− propor um modelo de agentes que represente de forma adequada as
funções de cada nodo do sistema, tais como: gerência, consulta e transferência
de arquivos através da rede;
− propor a utilização de mecanismos de comunicação e cooperação entre os
agentes do sistema, para viabilizar a execução das funções do sistema;
− contribuir para a popularização da utilização da abordagem multiagente
para desenvolvimento de software.
Para que estes objetivos sejam alcançados, o trabalho apresentado nesta
monografia baseia-se na hipótese de que um sistema de compartilhamento de arquivos
P2P pode ser implementado a partir de agentes organizados em um sistema multiagentes.
Cada agente representa um nodo do sistema, que troca informações e coopera com outros
agentes, usando para tal uma linguagem de comunicação. Além disso, cada agente possui
uma tarefa bem definida e cada tarefa é dividida em outras tarefas mais simples, com o
objetivo de tornar o sistema o mais modular possível. É através da interação entre os
agentes que um arquivo é transferido de um local habitado por um agente para outro.
Esta monografia está organizada da seguinte forma. O capítulo 2 faz uma breve
introdução aos principais modelos de conectividade de redes de computadores. Logo em
seguida, o capítulo 3 apresenta as principais abordagens da Inteligência Artificial para
resolução de problemas distribuídos. O capítulo 4 apresenta as especificações de
arquitetura de sistemas multiagentes FIPA (Foundation for Intelligent Physical Agents) e
a ferramenta FIPA-OS (Foundation for Intelligent Physical Agents Open Systems),
baseada nestas especificações. No capítulo 5, é descrito o sistema de compartilhamento
15
de arquivos desenvolvido baseado nos conceitos descritos nos capítulos anteriores e,
finalmente, no capítulo 6 é apresentada a conclusão do trabalho.
16
2 Compartilhamento de Arquivos em Redes de Computadores
Este capítulo apresenta uma breve introdução aos dois tipos básicos de rede de
computadores do ponto de vista da maneira com que dados são compartilhados: ponto-a-
ponto (peer-to-peer – P2P) e cliente-servidor.
2.1 Introdução
A informatização é um processo irreversível. Em todos os lugares ela se faz
presente, mesmo fora do ambiente explícito da informática. Escolas, agências de turismo,
hospitais e até mesmo residências, só para citar alguns exemplos, estão cada vez mais
informatizados. E muito do sucesso desse processo se deve as redes de computadores. É
raro encontrar um lugar onde não se encontra uma rede de computadores. Por exemplo,
em toda área urbana é possível encontrar um caixa eletrônico de banco. Todas esses
caixas eletrônicos estão interligados a uma rede de uma central bancária. As redes
surgiram da necessidade de troca e compartilhamento de informações de forma rápida e
barata. O melhor exemplo de sucesso das redes de computadores se chama Internet. Com
a Internet, o conceito de rede de computadores rápida e barata para troca e
compartilhamento de informações é levado ao extremo: através dela é possível receber as
principais matérias de um jornal localizado a milhares de quilômetros de distância em
questão de segundos, com o custo de uma ligação telefônica local.
Atualmente, a Internet oferece para seus usuários um grande número de
serviços. É possível encontrar aplicações para quase todas as necessidades. Como a
demanda por aplicações de Internet é muito grande, devido ao fato de existir atualmente
dezenas de milhões de usuários, é grande o aumento de aplicações cada vez mais
específicas. Por exemplo, se há alguns anos existiam poucos programas para
comunicação online de usuários, hoje em dia existe programas específicos para e-mail,
17
mensagens instantâneas, bate-papo (chat). Estes programas podem ser mais específicos
ainda. Por exemplo, existem programas de mensagens instantâneas de texto, outro para
voz, outro para vídeo. O que é possível concluir é que cada vez mais os usuários da
Internet procuram por soluções específicas para problemas.
Um exemplo de aplicação muito utilizada na Internet são programas para
transferência de arquivos. Este tipo de serviço é tão utilizado que existem protocolos
específicos apenas para esta tarefa, como o File Transfer Protocol – FTP, por exemplo. O
modelo de serviço FTP consiste de um servidor de arquivos, chamado servidor FTP que
disponibiliza diretórios do sistema operacional hospedeiro para escrita e/ou leitura.
Usuários que desejam acessar os diretórios do servidor FTP precisam de um programa
cliente FTP, além de uma conta de acesso no servidor FTP. O cliente FTP fornece a
interface para acessar o servidor FTP. A interface consiste de ferramentas para acessar o
servidor FTP a partir de um endereço de rede, um serviço de login no servidor FTP, além
da interface para os comandos do protocolo FTP para criar, copiar, apagar e renomear
arquivos, por exemplo. O modelo de serviço FTP é um exemplo clássico do modelo
cliente-servidor [TOR 2001].
2.2 Modelo cliente-servidor
O modelo cliente-servidor consiste de um cliente, que é um processo que inicia
uma atividade, e um servidor, que é um processo que aguarda requisições de ações de
clientes, executando estas ações a medida do possível. É um modelo que possui uma
organização centralizada, devido ao fato de um servidor concentrar várias conexões de
clientes. Voltando ao exemplo do servidor FTP, um cliente A pode se conectar a este
servidor, transferir um arquivo “xyz” para o servidor FTP e fechar a conexão. Um outro
cliente B pode então se conectar ao mesmo servidor FTP, transferir o arquivo “xyz” para
o seu computador e fechar a conexão. A figura 1 ilustra esta situação. O que aconteceu na
prática é que o arquivo “xyz” foi transferido do cliente A para o cliente B através do
servidor FTP.
18
FIGURA 1 – Exemplo de comunicação em um modelo cliente-servidor.
O servidor FTP do exemplo anterior poderia não fazer parte da transferência de
arquivo se o cliente A estivesse conectado diretamente ao cliente B. Neste caso, ambos
computadores conectados poderiam estabelecer regras para funcionarem tanto como
cliente quanto servidor. Este modelo descentralizado é chamado modelo ponto-a-ponto
(peer-to-peer – P2P) [ORA 2001]. O modelo P2P é descrito com detalhes na próxima
seção.
2.3 Modelo P2P
O modelo P2P consiste na interconexão o direta entre duas máquinas, visando o
compartilhamento de arquivos e/ou serviços. Esta é uma definição clássica [ORA 2001],
que estipula que os nós da rede devem estabelecer suas conexões de forma independente
e descentralizada, cada um deles desempenhando as funções de cliente e servidor.
A grande vantagem do modelo P2P em relação ao modelo cliente-servidor é a
pouca dependência de um servidor para centralizar conexões. Na verdade, alguns
modelos P2P não utilizam nenhum tipo de servidor. Existem três tipos de modelo P2P
[DRE 2001]:
19
− Modelo P2P puro.
− Modelo P2P com servidor de registro de pontos.
− Modelo P2P com servidores de registro de pontos e consulta.
2.3.1 Modelo P2P puro
No modelo P2P puro, cada ponto da conexão estabelece sua própria política de
conexão, diferente do modelo cliente-servidor onde o servidor dita as regras. Cada ponto
pode fazer requisições de serviço para o outro ponto, transferir dados de e para outro
ponto, ou seja, cada ponto funciona como cliente e servidor. A grande desvantagem deste
modelo é que como descobrir outros pontos na rede. Como não existe um servidor para
concentrar pontos, o usuário deve conhecer o endereço do ponto que deseja se conectar.
A figura 2 ilustra o modelo P2P puro.
FIGURA 2 – Modelo P2P puro.
2.3.2 Modelo P2P com servidor de registro de pontos
Para solucionar o problema encontrado no modelo anterior, este novo modelo
possui um servidor com uma tabela com todos os pontos conectados e seus respectivos
endereços de rede. Quando um novo ponto se conecta da rede P2P, ele deve primeiro
20
registra-se no servidor de pontos. A partir deste momento, o novo ponto pode receber
informações sobre os endereços de todos os pontos da rede P2P. Um grande problema
deste modelo (e do modelo anterior) é que um usuário deve visitar cada ponto da rede
P2P a procura da informação desejada. A figura 3 ilustra o modelo P2P de registro de
pontos.
FIGURA 3 – Modelo P2P com servidor de registro de pontos.
2.3.3 Modelo P2P com servidores de registro de pontos e consulta
O modelo P2P com servidores de registro de pontos e consulta oferece um
serviço de consulta de serviços oferecidos por cada ponto que não existe nos dois
modelos anteriores. O servidor de consulta armazena informações sobre estes serviços e
cada ponto da rede P2P pode consultá-lo. Todos os pontos da rede que oferecem algum
tipo de serviço devem atualizar suas informações de serviço no servidor de consultas
constantemente. A figura 4 ilustra este modelo.
21
FIGURA 4 – Modelo P2P com servidores de registro de pontos e procura.
2.4 Modelo P2P e compartilhamento de arquivos
Uma das formas mais comuns de uso do modelo P2P é para compartilhamento
de arquivos. Em uma rede P2P de compartilhamento de arquivos, cada usuário (ou ponto)
da rede compartilha fisicamente um determinado número de arquivos. Todos os usuários
da rede podem acessar estes arquivos. Normalmente os programas para acessar uma rede
P2P para compartilhamento de arquivos possuem uma interface pela qual é possível fazer
consultas sobre disponibilidade de um arquivo. Os resultados da consulta são mostrados
pela interface ao usuário que pode então acessar esses arquivos. Este tipo de serviço
oferece transparência de localização do arquivo ao usuário. O sistema como um todo
funciona logicamente como um grande repositório de arquivos acessível a todos usuários.
A figura 5 ilustra o modelo físico do sistema e a figura 6 ilustra o modelo lógico.
22
FIGURA 5 – Modelo físico do sistema de compartilhamento de arquivos P2P.
FIGURA 6 – Modelo lógico do sistema de compartilhamento de arquivos P2P.
23
2.5 Exemplo de aplicações P2P para compartilhamento de arquivos
No final dos anos 90, surgiram na Internet vários softwares de
compartilhamento de arquivos que utilizavam o modelo P2P. Esta seção faz uma breve
explicação de dois dos mais populares:
− Napster: O Napster [NAP 2002] foi o primeiro software com tecnologia
P2P para compartilhamento de arquivos que fez sucesso. No auge de seu uso,
chegou a incrível marca de 30 milhões de usuários. Era utilizado para
compartilhar arquivos de música. Utilizava o modelo P2P com servidores de
registro de pontos e consultas. Um servidor registrava todos usuários online. Ao
se registrar no sistema, o software do usuário enviava para o servidor uma lista
com todos os arquivos de música compartilhados. Para fazer uma pesquisa
sobre um arquivo específico, era enviada uma consulta ao servidor que
retornava uma lista de usuários online com o arquivo. A partir daí era possível
transferir o arquivo.
− Kazaa: O Kazaa [KAZ 2002] é muito semelhante ao Napster, mas possui
a vantagem de compartilhar qualquer tipo de arquivo. O usuário escolhe uma
lista de diretórios que deseja compartilhar e se registra no sistema com um nome
de usuário. É possível fazer pesquisas sobre tipos de arquivos específicos ou
pesquisas de arquivos de um usuário. O Kazaa é um dos programas P2P mais
utilizados atualmente.
24
3 Inteligência Artificial Distribuída
Sistemas de Inteligência Artificial Distribuída (Distributed Artificial
Intelligence – DAI) [FER 99] [RIC 94] podem ser definidos como sistemas cooperativos
onde um conjunto de entidades, denominados agentes, atuam em conjunto para
solucionar um problema. A DAI é uma sub-área da Inteligência Artificial (Artificial
Intelligence – AI) [RIC 94] que estuda problemas que também são comuns à área de
Sistemas Distribuídos (Distributed Systems – DS) [COU 94]. Estes sistemas utilizam uma
abordagem de solução de problemas baseada no comportamento das sociedades humanas,
em contraposição à abordagem clássica da AI, centrada no comportamento do ser
humano como indivíduo, ou seja, a DAI concentra-se em sistemas de agentes enquanto
que a AI estuda o agente propriamente dito. Sua ênfase de estudo está nas ações e
interações da sociedade, utilizando para isso métodos clássicos de AI como representação
de conhecimento e métodos de inferência.
Esta abordagem é útil porque, para alguns problemas complexos, que exigem
um alto grau de poder processamento, a única possibilidade de solução é através de um
sistema distribuído. A DAI pode ser considerada então uma evolução da AI clássica.
3.1 Definição de agentes
Atualmente existem diversas definições para o termo agente. Agentes podem ser
descritos como “componentes ativos e persistentes que percebem, tomam decisões, atuam
e se comunicam” [HUH 98]. Baseado em sua funcionalidade, um agente pode ser
definido como: “uma entidade conceitual envolvida na análise, estruturação e
implementação do processo de resolver um problema complexo” [ATT 2000]. Outra
definição para agente pode ser “um sistema encapsulado, que está situado em um
ambiente e é capaz de executar ações flexíveis e autônomas neste ambiente de forma a
alcançar seus objetivos” [WOO 97].
25
Executar ações em um ambiente significa que os agentes não são figuras
passivas e sim, a origem das ações de seu ambiente. As ações são tomadas baseadas no
domínio de conhecimento do agente, determinado seu comportamento. De uma forma
metafórica, os seres humanos são os exemplos mais óbvios de agentes que habitam o
planeta terra, mas não são os únicos. Animais, empresas, governos também são bons
exemplos de agentes.
Ainda utilizando a metáfora do planeta terra como exemplo de ambiente de
agentes, existe uma clara distinção entre agentes racionais e irracionais, ou como são
classificados em DAI, agentes cognitivos e reativos, respectivamente. Dos inúmeros seres
que habitam a terra, o ser humano se destaca por sua excepcional capacidade de se
adaptar ao mundo em que vive. O ambiente planeta terra está sempre mudando, seja por
eventos aleatórios da natureza, seja por atos de seus agentes. Um agente percebe estas
mudanças e executa ações baseadas em sua percepção do mundo para atingir um estado
de equilíbrio, ou objetivo. Por exemplo, no caso de um funcionário de uma empresa que
quer ir de sua casa para o local de trabalho de carro. O funcionário ao sair de casa
percebe que há um excessivo tráfego de carros na estrada que o leva até seu local de
trabalho e, para evitar um possível atraso, resolve ir de metrô. Neste exemplo, o agente
funcionário, com o objetivo de ir ao trabalho, percebe que há um congestionamento de
carros na sua rua. O funcionário deste exemplo é um típico caso de um agente cognitivo.
Um agente pode ser dito cognitivo se ele tenta atingir seus objetivos baseado em suas
crenças sobre o ambiente em que vive. Um agente cognitivo em nível de software pode
ser definido como “um agente que contém não apenas dados e métodos procedimentais,
mas sim uma base de conhecimento do qual é possível inferir novos conhecimentos”
[ATT 2000].
Os agentes reativos diferenciam-se dos agentes cognitivos pelo fato de não
agirem deliberadamente e sim devido a eventos externos, ou seja, apenas reagem a
situações, por isso o nome reativo. Por este motivo um agente reativo é mais simples que
um agente cognitivo e por si só não realiza modificações significativas no ambiente onde
atua. Um comportamento complexo inteligente emerge de um conjunto de muitos agentes
reativos. Utilizando mais uma vez o planeta terra com exemplo de ambiente, a
organização de uma sociedade de abelhas representa bem uma sociedade de agentes
26
reativos. Uma abelha sozinha parece não fazer mudanças no meio que habita, mas é um
fato que a polinização, tarefa vital para a reprodução das plantas é um exemplo de
comportamento complexo que emerge de ações em conjunto.
Existe uma série de atributos que definem o comportamento de um agente [BIG
2001][STO 97][WOO 94]. Dependendo da forma de implementação do agente, estes
atributos podem estar presentes em maior ou menor grau, mas sempre estarão presentes.
Entre estes atributos, destacam – se:
− Adaptabilidade: Um agente pode mudar seu comportamento para melhor
se adaptar a seu ambiente.
− Autonomia: Capacidade de o agente operar sem intervenção direta de um
usuário, e também possuir um certo controle sobre suas ações.
− Interatividade: Interação entre agentes ou de agentes com os usuários
através de uma linguagem de comunicação de agentes.
− Mobilidade: Um agente pode ser capaz de migrar de uma plataforma para
outra.
− Pró-atividade: Agentes devem ser capazes de planejar seus atos e não
simplesmente reagir a estímulos externos.
− Racionalidade: Entre diversas opções de ações a disposição de um agente
em um determinado momento, ele deve ser capaz de escolher a que julgar
melhor.
− Reatividade: Agentes percebem os estímulos externos e respondem com
uma ação respeitando seu comportamento.
− Sociabilidade: Define se um agente é cooperativo (benevolente, altruísta)
ou competitivo (egoísta).
Muitos destes aspectos só são válidos de analisar em um contesto de sociedade
de agentes, ou sistema de agentes. A próxima seção deste capítulo mostra como agentes
são organizados em uma sociedade.
27
3.2 Resolução distribuída de problemas e sistemas multiagentes
A DAI divide-se em duas grandes áreas de estudo: a Resolução Distribuída de
Problemas (Distributed Problem Solving – DPS) e Sistemas Multiagentes (Multiagent
Systems – MAS) [STO 97] como mostra a figura 7 [STO 97].
FIGURA 7 – Classificação da DAI
Na DPS os agentes possuem por objetivo comum a resolução de um problema
pré-determinado. Os agentes são projetados para resolver à apenas este problema
especificamente e, para resolvê-lo, é necessário cooperação, já que cada agente possui
apenas uma visão parcial do problema. Esta cooperação caracteriza-se basicamente por
compartilhamento de conhecimento sobre o problema e sobre o processo de obter uma
solução. A dinâmica de coordenação de ações dos agentes é determinada durante o
projeto do sistema.
Os MASs, por sua vez, não são projetados baseados em um problema
específico, e sim em dois aspectos: a construção do sistema através de múltiplos agentes
independentes e dos mecanismos de coordenação do comportamento destes agentes. Um
agente independente é aquele que possui seus próprios interesses, ou objetivos.
Os MASs são a base do trabalho proposto nesta monografia e devido a esse
motivo eles serão explicados com maiores detalhes a partir de agora.
28
3.3 Considerações sobre sistemas multiagentes
Os MAS são considerados uma nova abordagem para solução de problemas em
AI. A abordagem MAS provê meios para construção de sistemas complexos compostos
por múltiplos agentes e mecanismos para coordenação do comportamento dos agentes do
sistema [STO 97].
3.3.1 Classificação de sistemas multiagentes
Segundo [STO 97], os sistemas de Inteligência Artificial Distribuída podem ser
classificados utilizando os seguintes critérios:
- Sistema homogêneo ou heterogêneo.
- Método de coordenação (cooperativo ou competitivo).
- Formas de comunicação (quadro negro ou mensagens, comunicação em
baixo-nível ou alto-nível).
3.3.2 Sistemas multiagentes homogêneos e heterogêneos
Os MAS podem ser classificados também quanto ao tipo dos agentes que
pertencem ao sistema, ou seja, um MAS pode ser classificados como homogêneo ou
heterogêneo. Um MAS é considerado homogêneo é se todos os agentes pertencentes ao
sistema são do mesmo tipo, ou seja, todos os agentes deste sistema possuem a mesma
estrutura interna, o que incluí objetivos, domínio do conhecimento e ações, além de
deliberarem suas ações através dos mesmos procedimentos. Em um MAS heterogêneo os
agentes podem ser dos mais diversos tipos, o que torna este tipo de sistema muito mais
complexo que um MAS homogêneo. Esta diversidade de agentes apresenta-se em muitas
formas, desde agentes com objetivos diferentes até reações diferentes para os mesmos
tipos de estímulos.
3.3.3 Métodos de coordenação
29
A diversidade dos agentes em um MAS heterogêneo implica em agentes com
objetivos diferentes, algumas vezes conflitantes. Por este motivo, podem existir agentes
cooperativos e agentes competitivos. Agentes cooperativos ajudam-se uns aos outros para
atingirem seus respectivos objetivos. Por outro lado, agentes competitivos não ajudam
outros agentes, e estão interessados apenas em atingir seu próprio objetivo. A figura 8
mostra uma classificação para coordenação de agentes.
FIGURA 8 – Classificação de tipos de coordenação de agentes.
A cooperação em MAS surgiu da seguinte pergunta: Por quê utilizar apenas um
agente para realizar um serviço se é possível utilizar vários trabalhando juntos para
concluir a tarefa? Com vários agentes trabalhando em conjunto é possível pensar em um
MAS com agentes menos complexos, utilizando uma estratégia de projeto do tipo dividir
para conquistar.
A coordenação de um conjunto de agentes não é uma tarefa trivial. Para uma
coordenação ter sucesso, é necessário haver um planejamento das ações do sistema. Em
um planejamento centralizado, um agente, que possui uma visão geral do problema, é
responsável em dar ordens para os outros agentes do grupo para atingirem uma solução
30
do problema em conjunto. No modelo distribuído, também conhecido por modelo
organizado em equipes, cada equipe se compromete a atingir uma meta para alcançar o
objetivo. Os agentes trocam mensagens para saber do progresso das outras equipes, o que
estabelece uma relação de comprometimento entre agentes.
Em contraposição ao agente cooperativo existe o agente competitivo. A idéia
baseia-se no fato de que um agente quer sempre o melhor para si, o que ocasionará
conflitos com outros agentes. Agentes com maior inteligência e com maior conhecimento
específico sobre uma determinada tarefa possuem maiores chances de sucesso em fazer
valer a sua vontade em um MAS. Quando agentes conflitantes interagem entre si, é
necessário haver um processo de negociação para que eles possam tentar atingir uma
ação de consenso para tingir seus respectivos objetivos. Quando não ocorre o consenso,
os agentes precisam entrar em um acordo através de concessões e propostas de acordo.
A distinção entra agentes cooperativos e competitivos na prática, é uma tarefa
difícil. Em aplicações reais, faz sentido agentes cooperativos que possuem objetivos
comuns se ajudarem, mas é difícil imaginar a situação em que agentes com objetivos
diferentes e/ou conflitantes cooperem entre si. Para alguns autores [KOR 92], agentes são
sempre competitivos (egoístas), baseado na idéia que agentes cooperam não para ajudar
uns aos outros e sim para atingir o seu próprio objetivo.
3.4 Comunicação em sistemas multiagentes
Algumas abordagens para MAS consideram agentes como partes especiais do
ambiente, o que torna a comunicação entre agentes simplesmente uma pequena parte da
interação dos agentes com o ambiente. Apesar de ser considerada uma “pequena” parte
dos processos de interação de um MAS, a comunicação entre agentes é um assunto
bastante complexo.
3.4.1 Atos da fala
A Teoria dos Atos da Fala desenvolvida por John Searle [SEA 70] é a base de
quase todos protocolos de comunicação de agentes. Para a lógica proposicional, um
31
enunciado verbal é sempre considerado verdadeiro ou falso. Na Teoria dos Atos da Fala,
este enunciado pode ter vários significados. Enunciados que não podem ser classificados
como verdadeiros ou falsos são chamadas “performativas”. Esta teoria, basicamente,
apresenta o papel da linguagem como ação, decompondo o ato da fala em três tipos de
ação:
- Locução, que é o meio físico da expressão ou forma de expressão. Ex:
voz.
- Ilocução, que é a intenção passada do locutor para o ouvinte.
- Perlocução, que é a ação decorrente da ilocução, ou conseqüência do ato
da ilocução.
Em uma sociedade humana, por exemplo, uma afirmação de um operário de
uma fábrica do tipo “estou cansado” pode indicar não só a interpretação direta do ato
locucionário (informar como o operário se sente), como também pode ser interpretado de
forma indireta (pedido de ajuda a um outro operário qualquer para ajudá-lo em sua
tarefa). Percebe-se que a ilocução é uma característica subjetiva, porque a intenção da
locução depende de que a interpreta. A perlocução depende que como a locução foi
interpretada. Já em um MAS, esta subjetividade é elimina devido às mensagens
normalmente explicitarem a ação ilocucionária para evitar ambigüidades de interpretação.
A classificação das performativas [SEA 70] é dada a seguir:
- Assertivas ou Representativas: O locutor comunica que acredita na
verdade do enunciado, ou seja, é a performativa utilizada para a constatação de
um fato. Ex: Asserção, conclusão.
- Comissivas: O locutor se compromete com a realização de uma ação
futura, ou seja, é a performativa utilizada para comprometimentos. Ex:
Promessa, ameaça.
- Declarativas: O locutor altera imediatamente o estado do seu ambiente, ou
seja, é a performativa utilizada para afirmar fatos. Ex: Declaração de guerra.
32
- Diretivas: O locutor tem por intenção fazer com que o ouvinte realize uma
ação, ou seja, é a performativa utilizada para solicitações. Ex: Ordem, pergunta,
permissão, proibição, requisição.
- Expressivas: O locutor expressa um estado psicológico, ou seja, é a
performativa utilizada para expressar emoções.
Em suma, a Teoria dos Atos da Fala é usada em MAS para definir os tipos de
mensagens por meio da força da ilocução, que restringe a semântica da comunicação. A
ação desejada pelo locutor é definida sem ambigüidades, facilitando o projeto de MAS.
3.4.2 Modelo de comunicação
Em todos os tipos de MAS, especialmente os heterogêneos, deve haver um
conjunto de linguagens e protocolos para interação entre agentes. Esta seja talvez uma
das maiores dificuldades encontradas por quem está desenvolvendo um MAS. Como
agentes com representações internas diferentes, criados em tempos diferentes e operando
em ambientes diferentes podem se comunicar e coordenar suas ações efetivamente? Um
modelo de cinco camadas é adotado para representação da comunicação entre agentes
como objetivo de incentivar o desenvolvimento de protocolos específicos para cada
camada. Este modelo de camadas é um modelo geral, que não precisa ser seguido para
implementação de um MAS, porém o seu uso é aconselhável para facilitar futuras
mudanças de protocolos. As cinco camadas de comunicação são:
- Linguagem de Conteúdo: É a linguagem utilizada para representar o
conhecimento que será utilizado como conteúdo de uma mensagem. Exemplos:
Knowledge Interchange Format – KIF, Semantic Language – SL, Constraint
Choice Language – CCL, Resource Description Framework – RDF.
- Linguagem de Comunicação: É o protocolo utilizado para representação
da linguagem de comunicação baseada em atos da fala, formada por um
conjunto de tipos de mensagem e descrições dos efeitos das mensagens sobre os
agentes que a enviam e sobre os que a recebem. Atualmente as duas linguagens
33
de comunicação mais utilizadas são o Knowledge Query and Manipulation
Language – KQML e o Foundation for Intelligent Physical Agents - Agent
Communication Language – FIPA ACL.
- Métodos de Comunicação: A forma como os agentes se comunicam, que
pode ser através de quadro-negro, federação de agentes, mensagens diretas e
difusão de mensagens.
- Transporte de Mensagens: Protocolo utilizado para transporte de uma
mensagem de um agente para o outro. Os protocolos mais utilizados nessa
camada são: HyperText Transfer Protocol – HTTP, Internet InterORB Protocol
– IIOP, Remote Method Invocation – RMI, Simple Mail Transfer Protocol –
SMTP.
- Mecanismo de Transporte: Define o protocolo de rede utilizado para a
comunicação entre agentes. Normalmente é utilizado o Transport Control
Protocol / Internet Protocol – TCP/IP, mas com a popularização de dispositivos
como palmtops e telefones celulares, protocolos para comunicação sem fio
como o Short Message Service - SMS e Wireless Application Protocol - WAP
também podem ser utilizados.
A figura 9 ilustra um exemplo de modelo de cinco camadas para comunicação
de agentes.
34
FIGURA 9 – Exemplo de modelo de camadas para comunicação de agentes.
KIF é a mais conhecida linguagem de conteúdo de mensagens. Ela foi
desenvolvida para o intercâmbio de conhecimento entre agentes, baseada na lógica de
predicados. Sua sintaxe é muito parecida com a da linguagem de programação List
Processing – LISP, mas KIF não é utilizada para esse fim e sim para representar
conhecimento. SL é muito utilizado no padrão FIPA (ver capítulo 4), assim como CCL e
RDF.
A linguagem de comunicação KQML fornece uma infra-estrutura (framework)
para programas e agentes trocarem informações e conhecimento. Foi desenvolvida pela
Defense Advanced Research Projects Agency - DARPA. KQML define formatos e
protocolos para tratamento de mensagens entre agentes. KQML não define o conteúdo
das mensagens, mas sim as operações de consultas e manipulação na base de
conhecimento dos agentes e provê uma arquitetura básica para agentes compartilharem
conhecimento e informações através de um tipo especial de agente conhecido por agente
facilitador. As mensagens em KQML são chamadas performativas, devido ao termo
utilizado na Teoria dos Atos da Fala.
35
A linguagem FIPA ACL, assim como o KQML, baseia-se nas ações da fala. Sua
especificação [FIP 2002g] consiste de um conjunto de mensagens e descrições dos efeitos
destas mensagens. A sintaxe FIPA ACL é muito parecida com a KQML. As
performativas KQML são chamadas em FIPA ACL de primitivas de comunicação, ou
ações comunicativas.
Agentes podem se comunicar utilizando diversos métodos. O método do
quadro-negro permite a um grupo de agentes um meio comum para comunicação.
Agentes escrevem e lêem mensagens em um meio compartilhado (quadro-negro) O
conhecimento neste sistema é compartilhado por todos os agentes, o que torna esse
método útil quando o sistema é cooperativo. O sistema de agentes federados é útil quando
o sistema possui muitos agentes e uma organização hierárquica é a melhor solução. Neste
sistema, uma agente A que deseja enviar uma mensagem para um agente B não a envia
diretamente e sim para um agente facilitador, hierarquicamente superior, que se
responsabiliza pelo envio da mensagem. Este agente facilitador encontra o destinatário da
mensagem através do envio de mensagens para outros agentes facilitadores. O método da
mensagem direta, como o próprio nome já informa, um agente envia a mensagem
diretamente para outro agente, enquanto que no método da difusão, a mensagem é
enviada para um grupo de agentes.
Os protocolo de transporte de mensagens e mecanismos de transporte tratam do
transporte de mensagens no nível de protocolos de rede e a explicação detalhada destes
protocolos foge ao escopo desta monografia.
3.5 Ferramentas para construção de sistemas multiagentes
Para finalizar este capítulo, a seguir é feita uma breve descrição de ferramentas
para desenvolvimento de agentes [BIG 2001]. A maioria destas ferramentas é baseada em
Java. Java é com certeza a linguagem de programação mais utilizada no desenvolvimento
orientada a agente, mas não é a única. Os ambientes de desenvolvimento, ferramentas e
frameworks são descritos a seguir:
36
− AgentBuilder, Reticular Systems: é um conjunto integrado de ferramentas
para construção de software que utilizam agentes inteligentes. Consiste em
ferramentas de construção e de um sistema de ambiente de execução. Entre as
ferramentas, destacam-se: gerenciador de processo de desenvolvimento,
analisador de domínio de operações do agente, ferramentas de projeto e
desenvolvimento de redes de comunicação de agentes, mecanismos para definir
comportamento e meios para depurar erros.
− Aglets, IBM: São agentes autônomos e móveis baseados em Java. Os
aglets são livres para viajar entre servidores que rodam o servidor aglet, e pode
seguir um roteiro de viagem. Um processo aglet pode ser suspenso, deportado
para outro sistema hospedeiro aglet, e reiniciado.
− FIPA-OS: Iniciativa do grupo NortelNetworks para desenvolvimento de
agentes baseados em Java compatíveis com as especificações FIPA (ver
capítulo 4).
− Java Agent Template Lite – JATLite: Desenvolvido pela Universidade de
Stanford, utiliza uma arquitetura de camadas para construção de MAS.
− Java Expert System Shell – JESS: é uma implementação Java do ambiente
baseados em regras CLIPS que foi desenvolvido pelos Laboratórios Sandia
National. Não é um ambiente de agentes, mas provê um sistema de regras de
inferência em Java.
− SAIC Afterburner: Framework para agentes autônomos desenvolvidos em
Java que utilizam a linguagem de comunicação KQML.
− Voyager, ObjectSpace: É um Object Request Broker – ORB (ver capítulo
4) que utiliza agentes desenvolvidos em Java. Os agentes Voyager são
autônomos e móveis, mas não são inteligentes.
− ZEUS: Ferramenta para construção de agentes da BritishTelecom, é um
framework para o desenvolvimento de agentes colaborativos, baseados em
autonomia e cooperação.
37
4 FIPA e FIPA-OS
Este capítulo apresenta a Foundation for Intelligent Physical Agents – FIPA,
fundação que cria padrões para desenvolvimentos de agentes e Sistemas Multiagentes,
além do Foundation for Intelligent Physical Agents Open Systems – FIPA-OS, uma
plataforma de desenvolvimentos de Sistemas de Multiagentes que segue totalmente aos
padrões FIPA.
4.1 Introdução
A FIPA é uma organização internacional sem fins lucrativos criada em
dezembro de 1996 como o objetivo de criar padrões e expandir o uso da tecnologia de
agentes inteligentes, através de especificações para a interoperabilidade entre sistemas de
agentes e aplicações baseadas em agentes. Existem várias empresas e universidades que
colaboram com a FIPA, e todos os resultados das atividades da fundação estão
disponíveis para avaliação. Atualmente a fundação possui mais de 50 membros de 11
países diferentes
Para fins de identificação, as especificações FIPA recebem identificadores
formais e informais. Um identificador de especificação formal é formado pela palavra
“FIPA” concatenada com o número decimal que representa a especificação. Por exemplo,
o identificador formal da especificação de arquitetura abstrata FIPA é “FIPA00001”. O
identificador de especificação informal é formado por um sufixo que representa o estágio
de desenvolvimento concatenado com o número decimal que representa a especificação.
Por exemplo, a especificação FIPA no estágio de desenvolvimento standard de
gerenciamento de agentes recebe o identificador informal “SC00023”. A letra “C” no
sufixo é de component (componente).
As próximas seções descrevem as principais especificações FIPA. Ao final de
cada seção há uma referência à especificação FIPA utilizada para descrevê-la.
38
4.2 Arquitetura Abstrata FIPA
A arquitetura abstrata FIPA define em um nível abstrato como dois agentes se
localizam e trocam mensagens. Um agente antes de enviar quaisquer mensagens a outros
agentes deve registrar-se no sistema. Agentes registrados em diferentes sistemas podem
trocar mensagens. Para que isso seja possível, deve existir um grau elevado de
interoperabilidade entre estes sistemas.
Para aumentar o grau de interoperabilidade entre diferentes sistemas de agentes,
a arquitetura FIPA especifica padrões para a implementação das características comuns a
todos os sistemas de agentes, aumentando também o grau de abstração da arquitetura. A
idéia básica é que cada arquitetura concreta baseada na arquitetura abstrata FIPA é livre
para escolher com que linguagem de comunicação os agentes irão se comunicar ou qual
será o protocolo de transporte de mensagens e, mesmo assim, os sistemas poderão
interoperar porque foram baseadas na mesma arquitetura. É claro que para tornar isso
possível, deve haver meios para converter os diferentes tipos de protocolos e linguagens
utilizadas em cada arquitetura concreta.
A arquitetura abstrata FIPA é composta por uma série de elementos. Muitos
deles tratam de interoperabilidade de sistemas de agentes. Uma arquitetura concreta, que
segue o padrão FIPA, deve possuir obrigatoriamente os seguintes elementos:
- Um modelo de registro e consulta de serviços disponíveis para os agentes
e para outros serviços.
- Interoperabilidade de transporte de mensagens entre agentes.
- Suporte para várias formas de representação de ACL.
- Suporte para várias formas de linguagem de conteúdo.
- Suporte para múltiplas representações de serviços de diretório.
Existem outros elementos que não são definidos na arquitetura abstrata FIPA,
como por exemplo, o ciclo de vida de uma agente e, mesmo assim, são obrigatórios em
uma arquitetura concreta compatível com o padrão FIPA. O ciclo de vida de um agente,
ou estados de operação de um agente, depende muito do sistema do qual o agente está
inserido, o que dificulta muito a abstração deste tipo de elemento. Porém é indispensável
39
que em uma arquitetura concreta os agentes possuam uma descrição de seus estados
internos.
Alguns elementos da arquitetura abstrata FIPA são considerados opcionais em
termos de implementação em uma arquitetura concreta. Elementos da arquitetura abstrata
FIPA que são definidos em uma arquitetura concreta são ditos “realizados”. Uma
arquitetura concreta pode realizar todos ou parte dos elementos da arquitetura abstrata
FIPA.
4.2.1 Serviços
Um serviço pode ser definido como “um conjunto coerente de mecanismos que
suportam a operação de agentes e outros serviços” [FIP 2002a]. A interoperação entre
agentes se baseia no uso de serviços.
A arquitetura abstrata FIPA não define como devem ser implementados os
serviços, o que significa que eles podem ser agentes, procedimentos ou funções de
linguagem de programação ou interfaces do tipo encontradas em Java ou C++. No caso
de ser implementado através de um agente (agente de serviço), ele não terá autonomia
para recusar-se a oferecer o serviço. A figura 10 mostra o modelo se serviços da
arquitetura abstrata FIPA.
FIGURA 10 – Modelo de serviços da arquitetura abstrata FIPA.
Quando um agente é inicializado, é oferecida a ele uma raiz de serviços
(Service-Root – SR). O SR consiste de um conjunto de serviços, cada um localizado em
40
uma entrada de diretório de serviço (Service-Directory-Entry – SDE). Uma analogia
válida para um SR é um diretório raiz de sistema de arquivos de um sistema operacional
enquanto que cada SDE equivale a um arquivo.
Entre as várias SDE de um SR, obrigatoriamente deve haver ao menos uma para
cada um dos seguintes serviços:
- Serviço de Diretório de Agente (Agent-Directory-Service – ADS).
- Serviço de Diretório de Serviços (Service-Directory-Service – SDS).
- Serviço de Transporte de Mensagens (Message-Transport-Service –
MTS).
4.1.1.1 Serviço diretório de agente – ADS
O ADS armazena descrições de agentes. Cada descrição de agente fica
armazenada em uma entrada de diretório de agente (Agent-Directory-Entry – ADE). A
principal função do ADS é servir como um ponto de referência para agentes procurarem
outros agentes. Cada ADE é formada por uma tupla com os seguintes atributos:
- Nome do agente (agent-name): É o nome pelo qual o agente é conhecido
no sistema. Este nome deve ser único no sistema.
- Localizador do agente (agent-locator): Contém informações sobre como
se comunicar com o agente, conhecidas como descrições de transporte.
- Atributos de descrição do agente, tais como: serviços oferecidos, custo de
uso, restrições de uso e etc.
Os atributos de nome e localizador do agente são obrigatórios enquanto que os
atributos de descrição são opcionais. A figura 11 ilustra um exemplo de uma ADE.
41
FIGURA 11 – Representação de uma Entrada de Diretório de Agente – ADE.
4.2.1.2 Serviço diretório de serviços – SDS
Os registros e localização de serviços são feitos no SDS. Todos os serviços
registrados no SDS possuem uma descrição de serviço associada. Exemplos de serviços
são: MTS e ADS. Um SDS de uma implementação da arquitetura abstrata FIPA pode
oferecer o seguinte conjunto de ações:
- Registrar: Um serviço registra uma descrição de serviço em uma SDE do
SDS.
- Desregistrar: Um serviço desregistra uma SDE de um SDS.
- Procurar: Um serviço ou agente pode procurar por SDEs em um SDS.
- Modificar: Um serviço pode modificar ema SDE registrada em um SDS.
4.2.1.3 Serviço transporte de mensagens – MTS
O MTS é responsável entrega de mensagens. O MTS é um dos elementos
obrigatórios da arquitetura abstrata FIPA. O MTS provê suporte para quatro tipos de
ação:
- Amarração de Transporte (bind-transport-action): Um agente utiliza esta
ação de um MTS para criar um vínculo com um determinado tipo (protocolo) de
transporte para o envio e recepção de mensagens.
42
- Desamarração de Transporte (unbind-transport-action): É a ação inversa à
Amarração de Transporte. Um agente utiliza esta ação de um MTS para
terminar o vínculo de transporte para envio e recepção de mensagens.
- Enviar Mensagens (send-message-action): Um agente utiliza esta ação do
MTS para enviar mensagens de transporte para outros agentes
- Entrega de Mensagem (deliver-message-action): Um MTS utiliza esta
ação para entregar mensagens para agentes.
A arquitetura abstrata FIPA é descrita em [FIP 2002a].
4.3 Gerenciamento de Agentes
O modelo FIPA de gerenciamento de agentes especifica todas as regras de
criação, registro, localização, comunicação, migração e finalização de agentes. A figura
12 ilustra esse modelo. Ele é constituído dos seguintes componentes lógicos:
- Agente: Utiliza o mesmo conceito de agente do capítulo 2. O
gerenciamento de agentes independe de como o agente foi implementado
internamente, deixando o programador livre para implementar o agente da
forma mais adequada ao sistema. Todos agentes possuem uma identificação
(Agent Identification – AID) única no sistema.
- Plataforma de Agente (Agent Platform – AP): É a infra-estrutura em que
os agentes são desenvolvidos, ou seja, é o conjunto de componentes físicos e
lógicos utilizados no desenvolvimento dos agentes, composto por:
• Microcomputador – uma plataforma de agente não precisa
necessariamente estar localizada no mesmo microcomputador. FIPA
especifica meios para distribuição de AP entre vários microcomputadores.
• Sistema operacional – deve ter suporte a multitarefa e possuir
protocolos de rede.
• Software para desenvolvimento de agentes – deve ser compatível
com o sistema operacional.
• Componentes - DF, AMS, MTS e agentes.
43
- Facilitador de Diretórios (Directory Facilitator – DF): É utilizado
principalmente para consulta sobre serviços oferecidos por outros agentes, o que
torna seu funcionamento análogo às páginas amarelas de uma lista telefônica. O
DF faz parte da concretização do ADS da arquitetura abstrata FIPA.
- Sistema de Gerenciamento de Agentes (Agent Management System –
AMS): É utilizado principalmente para consulta de AIDs, ou seja, é análogo em
funcionamento às páginas brancas de uma lista telefônica. O AMS faz parte da
concretização do ADS da arquitetura abstrata FIPA.
- Serviço de Transporte de Mensagens (Message Transport Service – MTS):
Responsável pelo transporte de mensagens na AP ou entra APs.
- Software: Esta classe inclui todas as funções, procedimentos e programas
executáveis externos (software não-agente) acessados por um agente.
FIGURA 12 – Modelo de gerenciamento de agentes FIPA.
4.3.1 Identificação de agentes
Para fins de identificação, cada agente possui um identificador de agente, ou
AID é uma tupla composta dos seguintes valores:
44
- Nome (name): Identificador do agente, é único no sistema. É composto
pela concatenação do nome do agente + @ + endereço da plataforma
(normalmente no formato umdominio.com).
- Endereços (addresses): É uma lista com todos os endereços que o agente
utiliza para receber mensagens. É a concretização do localizador do agente, da
arquitetura abstrata FIPA.
- Resolvedores (resolvers): É uma lista de resolvedores de nomes de
agentes.
Um resolvedor é um serviço fornecido por um agente especial (normalmente o
AMS) que mapeia nomes de agentes com seus respectivos endereços de transporte. O seu
funcionamento é análogo ao de um Domain Name Server – DNS em uma rede TCP/IP.
4.3.2 Facilitador de diretório – DF
Para tornar públicos os seus serviços, um agente precisa registrar em um DF. É
permitido a um agente, além de registrar e consultar, modificar e desregistrar seus
serviços de um DF. Os DFs são componentes opcionais de uma AP, o que significa que
podem não existir nenhum DF em uma AP. No outro extremo, podem haver vários DFs
em uma mesma AP. Neste caso, os DF são organizados em federação. A AID do DF é
única, reservada e parecida com:
( agent-identifier :name [email protected] :addresses (sequence umdominio_transport_address)) onde umdominio é um nome de domínio qualquer.
Um DF pode registra-se em outros DF. Quando vários DFs registram-se uns aos
outros é criado uma estrutura federada de DFs. Um agente sempre consulta o DF local
quando procura por um serviço. Se o serviço não se encontra no DF local, este DF pode
propagar a consulta em todos os DFs que possui registrado.
45
4.3.3 Sistema de gerenciamento de agentes – MAS
O AMS funciona basicamente como um controlador de uso e acesso da AP e é
único nesta plataforma. Um agente só é considerado como parte de uma AP depois de
registrar-se no AMS. Ele mantém uma lista com AID de todos os agentes registrados. A
AID do AMS é única, reservada e parecida com:
( agent-identifier :name [email protected] :addresses (sequence umdominio_transport_address)) onde umdominio é um nome de domínio qualquer.
Além do registro de agentes, um AMS deve suportar funções para desregistrar,
modificar e procurar agentes além de oferecer uma função para obter descrições de
agentes.
Um agente pode modificar sua descrição no AMS se obtiver autorização do
mesmo, procurar por descrições de outros agentes e desregistrar-se do AMS, que
significa terminar o seu ciclo de vida na AP.
0utra função do AMS é fornecer meios para a AP criar, executar, invocar,
suspender, terminar, reiniciar agentes além de gerenciar recursos da plataforma.
4.3.4 Serviço de transporte de mensagens – MTS
O MTS é responsável pelo roteamento de mensagens de agentes para AP local
ou para APs remotas. Todos os agentes registrados no AMS têm acesso à pelo menos um
MTS. Um agente acessa MTSs de APs remotas através de um canal de comunicação de
agente (Agent Communication Channel – ACC). O nome mensagem é utilizado no nível
de comunicação de agentes. Ao chegar em um MTS, a mensagem é transformada em uma
mensagem de transporte. A figura 13 ilustra o processo de transformação de uma
mensagem em mensagem de transporte.
46
FIGURA 13 – Transformação de uma mensagem em mensagem de transporte.
Uma mensagem de transporte é composta por duas partes:
- Envelope (envelop): Representa informações de transporte como, por
exemplo, endereço de transporte do destinatário.
- Carga Útil (payload): É o conteúdo da mensagem, no formato de uma
Agent Communication Language – ACL.
Observa-se que uma mensagem FIPA é análoga uma carta de correio
convencional. O envelope carrega informações de transporte tais como: remetente e
destinatário enquanto que o conteúdo da carta descreve a mensagem.
4.3.4.1 Envelope
Um envelope carrega as informações necessárias para transportar uma
mensagem para seu destino. Ele é composto por diversos parâmetros, sendo que quatro
deles são obrigatórios:
47
- to: Parâmetro que contém o(s) endereço(s) de transporte do(s) agente(s)
destinatário(s) da mensagem.
- from: O(s) endereço(s) de transporte do agente remetente da mensagem.
- date: Data e hora do envio da mensagem pelo remetente.
- acl-representation: O nome do tipo de sintaxe utilizada para representar a
mensagem ACL.
4.3.4.2 Carga útil
A carga útil é na verdade a mensagem representada em ACL. As mensagens
ACL são codificadas antes de serem transportadas. O tipo de codificação ACL, também
chamada sintaxe de representação ACL pode ser um dos três tipos a seguir:
- Representação Bit-Efficient: É usada quando o tamanho da mensagem é
crítico, como por exemplo, em aplicações que utilizam o protocolo de transporte
de rede WAP. A especificação [FIP 2002j] descreve a representação de
mensagens ACL por Bit-Efficient.
- Representação String: Descreve a mensagem em texto American Standard
Code for Information Exchange - ASCII. A grande vantagem desta
representação é que a mensagem pode ser facilmente compreendida, já que é
escrita em texto puro. A especificação [FIP 2002k] descreve a representação de
mensagens ACL por String.
- Representação XML: Utilizada a sintaxe XML para descrever a
mensagem. A especificação [FIP 2002l] descreve a representação de mensagens
ACL por XML.
4.3.4.3 Canal de comunicação de agente – ACC
A ACC é a entidade do MTS responsável pelo envio de mensagens para agentes
de APs remotas. Um agente pode enviar mensagens para agentes de outras APs de três
formas diferentes:
48
- Envio Indireto: É a forma mais comum de envio de mensagens entre
diferentes plataformas. Um agente envia a mensagem através do ACC do MTS
local que se encarrega do roteamento da mensagem.
- Envio Por ACC Remoto: O agente envia a mensagem para o ACC do
agente remoto. Para que isso seja possível, o agente remetente da mensagem
precisa ter acesso à interface do protocolo de transporte do ACC remoto.
- Envio Direto: O agente envia a mensagem diretamente para o agente
remoto, sem o intermédio de um ACC. Todo o tratamento de envio e recepção
da mensagem, tais como: transferência, endereçamento e tratamento de erros
devem ser feitos pelos agentes que participam da conversação.
A figura 14 ilustra as três formas de envio de mensagem.
FIGURA 14 – Formas de comunicação entre agentes de plataformas diferentes.
Uma mensagem pode ter um ou mais destinatários. Cada destinatário pode ter
um ou mais endereços de transporte. Neste caso, o ACC utiliza o primeiro endereço de
transporte da lista de endereços de transporte da descrição do agente. Se o endereço de
transporte escolhido falhar, ele tentará enviar para o próximo endereço de transporte da
lista e assim sucessivamente, até encontrar um endereço de transporte válido ou, caso
contrário, enviar ao remete uma mensagem de falha. As mensagens recebidas por todos
os destinatários são idênticas, ou seja, todas possuem o mesmo envelope e carga útil.
O gerenciamento de agentes é descrito em [FIP 2002f].
49
4.4 A linguagem de comunicação de agentes – ACL
A ACL foi desenvolvida com o objetivo de permitir a agentes uma comunicação
em alto nível de abstração. Mensagens ACL são trocadas entre agentes, em um processo
chamado interação. Cada uma destas mensagens possui uma estrutura básica, além de um
significado explícito, definido por uma performativa e um conteúdo representado em uma
linguagem de conteúdo. Cada um destes aspectos será descrito nas próximas seções.
4.4.1 Estrutura da mensagem FIPA ACL
Uma mensagem FIPA ACL, ou carga útil de uma mensagem possui diversos
parâmetros, mas apenas o parâmetro performative é obrigatório. A tabela 1 mostra a lista
de todos os parâmetros FIPA ACL. A interpretação de cada um destes parâmetros fica a
cargo dos agentes participantes da conversação. Outros parâmetros podem ser criados e
utilizados, mas o nome destes novos parâmetros deve ter o prefixo “x-“ para manter a
compatibilidade com o padrão FIPA.
TABELA 1– Todos os parâmetros de uma mensagem FIPA ACL.
Categoria do parâmetro Parâmetro Tipo do ato comunicativo performative
Participante da conversação sender
receiver reply-to
Conteúdo da mensagem content
Descrição do conteúdo language encoding ontology
Controle da conversação
protocol conversation-id
reply-with in-reply-to reply-by
O parâmetro performative define a qual ato de comunicação à mensagem se
refere. Uma descrição completa dos atos de comunicação pode ser encontrada na seção
4.4.2.
50
Os parâmetros sender e receiver denotam o nome dos agentes remetente e
destinatário(s), respectivamente. É possível enviar mensagens anônimas através da
anulação do parâmetro sender. Também é possível enviar uma mensagem para vários
destinatários através da atribuição de uma lista de nomes de agentes em receiver. O
parâmetro reply-to indica o nome do agente para qual uma resposta à mensagem deve ser
enviada.
O conteúdo das mensagens ACL é encontrado no parâmetro content. O
significado do conteúdo da mensagem deve ser interpretado pelo receptor da mensagem,
com o auxílio dos parâmetros de descrição de conteúdo. O parâmetro language denota a
linguagem utilizada para descrever o conteúdo da mensagem e pode ser omitido se o
receptor da mensagem tem conhecimento da linguagem utilizada. O parâmetro encoding
indica a codificação utilizada no conteúdo da mensagem. Se este parâmetro for nulo, a
codificação utilizada deve estar presente no envelope da mensagem. O parâmetro
ontology é utilizado para a interpretação da simbologia utilizada no conteúdo da
mensagem. Normalmente, agentes em uma conversação possuem uma ontologia em
comum e por este motivo este parâmetro normalmente não é utilizado.
O protocolo de geração de mensagens ACL é definido no parâmetro protocol.
Para que um agente envolvido em diversas conversações simultâneas possa distinguir
cada uma das conversações, utiliza-se o parâmetro conversation-id. Este identificador de
conversação é único no sistema e o padrão FIPA recomenda que ele seja formado pelo
nome do agente remetente da mensagem mais um número inteiro qualquer.
Os parâmetros reply-with e in-reply-to são utilizados para indicar que a
mensagem é uma resposta a um determinado tópico entre várias conversações
simultâneas. Por exemplo, quando uma agente envia uma mensagem ACL com o
parâmetro reply-with contendo uma expressão “x“, este agente vai entender que as
mensagens recebidas com o parâmetro in-reply-to com a expressão “x” são resposta à
mensagem enviada originalmente. O parâmetro reply-by indica o tempo ou data em que o
agente remetente da mensagem ACL deseja receber uma resposta à mensagem. A
definição de o que é considerado tempo fica a cargo dos agentes envolvidos na
conversação.
51
Maiores informações sobre a especificação FIPA para estrutura de mensagens
ACL podem ser encontradas em [FIP 2002h].
4.4.2 Atos de comunicação
Os atos de comunicação ACL são baseados na Teoria dos Atos da Fala descrita
no capítulo 2. São utilizados para determinar a ação que o agente esta tentando expressar
através da mensagem ACL. Em termos de mensagem ACL, os atos de comunicação são
chamados performativas. Cada performativa possui um significado e a utilização de uma
performativa para imprimir uma ação com significado diferente da estabelecida pelo
padrão FIPA não é proibido, apenas fortemente desaconselhável por motivos de
interoperabilidade. A tabela 2 mostra todas as performativas definidas pelo padrão FIPA.
Cada performativa possui um conteúdo associado, normalmente valores ação e/ou
proposição (expressão verbal), que são utilizados pelo receptor da mensagem ACL para
entender o contexto da mensagem.
TABELA 2 – Performativas FIPA.
Performativa Significado do ato Accept Proposal Aceitação da proposta de execução da ação
desde que a proposição seja respeitada Agree Concordância em executar a ação, desde
que a proposição seja respeitada Call For Proposal Solicita propostas de outros agentes para a
execução da ação Cancel Informa ao um agente que a execução da
ação deve ser cancelada Confirm Utilizada como resposta de confirmação a
uma proposição Disconfirm Utilizada como resposta de desconfirmação
a uma proposição Failure Informa a um agente que a tentativa de
execução da ação falhou e um motivo para falha
Inform Informa a um agente que a proposição verdadeira.
Inform If Informa a um agente quando a proposição é ou não verdadeira
52
Performativa Significado do ato
Inform Ref Solicita a descrição sobre um objeto de referência
Not-Understood Informa a um agente que a performativa recebida não foi entendida devido a um
motivo
Propagate
A mensagem embutida na mensagem original recebida deve ser propagada para
um grupo pré-estabelecido de agentes respeitando um limite para a propagação
Propose Envia uma proposta para um agente executar uma ação
Proxy
O agente remetente da mensagem deseja que o receptor selecione agentes que
obedeçam a um critério e envie uma nova mensagem embutida na mensagem original
para todos os agentes selecionados, respeitando um limite para a propagação
Query-If Pergunta a um agente se a proposição é ou não verdadeira
Query-Ref Pergunta a um agente sobre um objeto a partir de uma descrição
Refuse Recusa em executar a ação, explicando o motivo
Reject Proposal Rejeição de uma proposta recebida, explicando o motivo
Request Requisita a um agente para a execução de uma ação
Request When Requisita a um agente para executar uma ação quando uma proposição for verdadeira
Request Whenever Requisita a um agente para executar uma
ação sempre que uma proposição for verdadeira
Subscribe Para manter o agente informado sobre alterações no objeto referenciado
Maiores informações sobre a especificação FIPA para a biblioteca de atos de
comunicação podem ser encontradas em [FIP 2002g].
4.4.3 Linguagem de conteúdo
O conteúdo de uma mensagem ACL é a representação do que se quer
comunicar. A interpretação do conteúdo da mensagem depende principalmente de uma
53
ontologia comum sobre um domínio de discurso entre os agentes participantes da
conversação e de uma linguagem de representação de conteúdo compartilhada.
Atualmente, o padrão FIPA possui especificações para quatro tipos de linguagens de
conteúdo:
- Semantic Language – SL: Utiliza proposições lógicas para expressar
atitudes mentais e ações do agente. A especificação SL [FIP 2002b] se encontra
no estágio de desenvolvimento padrão.
- Constraint Choice Language – CCL: Permite a comunicação entre agentes
em aplicações que exigem trocas sobre múltiplas escolhas inter-relacionadas.
Baseada na representação de problemas de escolha como problemas do tipo
Constraint Satisfaction Problem - CSP. A especificação CCL [FIP 2002c] se
encontra no estágio experimental de desenvolvimento.
- Knowledge Interchange Format – KIF: A linguagem KIF possui
semântica declarativa, o que facilita a compreensão das expressões. Esta
semântica é baseada na idéia de concepção do mundo em termos de objetos e
suas relações. A especificação KIF [FIP 2002d] se encontra no estágio
experimental de desenvolvimento.
- Resource Description Framework – RDF: Baseado no modelo entidade-
relacionamento e sintaxe derivada da eXtensible Markup Language - XML. A
especificação RDF [FIP 2002e] se encontra no estágio experimental de
desenvolvimento.
4.4.4 Protocolos de interação
Todas as conversações entre agentes apresentam um padrão de trocas de
mensagens, onde em determinadas ocasiões um tipo de mensagem específico é esperado.
A esse padrão de trocas de mensagens dá-se o nome Protocolos de Interação.
É claro que nem todas as trocas de mensagens seguem um determinado padrão,
mas o uso destes padrões é encorajado para aumentar o reuso de protocolos de interação,
além de prover padrões de interação entre agentes testados, que podem ser úteis em
54
vários aspectos de sistemas baseados em agentes. A tabela 3 resume os principais
protocolos de interação. Todos eles são especificações FIPA do tipo standard.
TABELA 3 – Protocolos Padrão de Interação FIPA.
Performativas Envolvidas Protocolo de Interação Iniciante Participante
Especificação FIPA
Request request refuse, agree, failure e inform FIPA00026
Query query-if e query-ref refuse, agree, failure e inform FIPA00027
Request When request-when refuse, agree, failure e inform FIPA00028
Contract-Net call for proposal, accept-proposal e
reject-proposal
refuse, propose, failure e inform FIPA00029
Iterated Contract-Net
call for proposal, accept-proposal e reject-proposal,
refuse, propose, failure e inform FIPA00030
Brokering proxy refuse, agree, failure e inform FIPA00033
Recruiting proxy refuse, agree, failure e inform FIPA00034
Subscribe subscribe refuse, agree, inform e failure FIPA00035
Propose propose accept -proposal e reject-proposal FIPA00036
Além dos protocolos de interação da tabela 3, FIPA especifica dois protocolos
experimentais chamados English Auction (especificação FIPA00031) e Dutch Auction
(especificação FIPA00032). Estes protocolos descrevem trocas de mensagens em leilões,
ou seja, um agente oferece um produto por um preço enquanto que outros agentes
envolvidos na conversação fazem suas ofertas. A diferença entre os dois é que no English
Auction, o preço do produto é mínimo e vai aumentado conforme as ofertas, enquanto
que no Dutch Auction, o preço do produto é máximo, caindo gradativamente até um
agente adquiri-lo. Estes protocolos de interação são muito utilizados em MAS que
simulam comércio eletrônico
55
4.5 Transporte de mensagens de agente
O transporte de mensagens em uma AP ou entre APs é realizado pelo MTS,
através do ACC, como foi descrito na seção 4.3.4. Para que este transporte seja possível,
deve existir protocolos de rede apropriados para roteamento de mensagens. O protocolo
de transporte utilizado em um MAS é chamado Message Transport Protocol – MTP.
FIPA possui especificações para três tipos de MTPs: IIOP, WAP e HTTP.
4.5.1 IIOP
O Object Management Group – OMG é uma organização com mais de 800
membros em todo mundo, que tem por objetivo criar padrões para computação
distribuída. Esta organização especifica padrões para comunicação entre ORBs. Um
Object Request Broker – ORB é uma espécie de tradutor universal para comunicação
entre objetos distribuídos. Ele serve como um intermediário na comunicação entre
objetos remotos. Os ORBs se encontram distribuídos por toda a rede. O padrão definido
pelo OMG para comunicação entre ORBs é chamado Internet Inter-ORB Protocol –
IIOP. Ele é baseado na especificação Commom Object Request Broker Architecture –
CORBA.
A especificação [FIP 2002m] descreve o protocolo de transporte HTTP com
detalhes.
4.5.2 WAP
WAP não é só um protocolo de comunicação, é também um ambiente de
aplicações. É uma tecnologia padrão para aplicações distribuídas, com plataformas
heterogêneas. É muito parecida com as tecnologias HTML e HTTP, com a vantagem de
ser otimizada para aplicações que rodam em plataformas com baixa largura de banda,
pouca memória e poucos recursos visuais, como o Personal Digital Assistant - PDA,
telefones celulares, pagers ou outros dispositivos eletrônicos portáteis.
A especificação [FIP 2002n] descreve o protocolo de transporte WAP
detalhadamente.
56
4.5.3 HTTP
O avanço do uso da Internet tornou o HTTP um dos protocolos mais populares
do mundo. Ele é famoso por ser o protocolo utilizado em conjunto com a linguagem
HTML para visualizar páginas da Internet. Mas o também pode ser usado de forma
genérica para comunicação entre ACCs em sistemas baseados em agentes.
A troca de mensagens é feita da seguinte forma: uma agente remetente faz uma
requisição HTTP e recebe uma resposta HTTP. Tanto a requisição quanto a resposta
HTTP é composta por uma linha de requisição (ou resposta), cabeçalho e corpo.
A linha de requisição (ou resposta) deve conter o método (POST), identificador
de recurso (Uniform Resource Identifier - URI) e versão (HTTP/1.1) da requisição. O
cabeçalho deve conter informações sobre interpretação da mensagem, como por exemplo,
tipo e tamanho do conteúdo da mensagem. O corpo da mensagem contém a mensagem
em si, ou seja, o envelope e a carga útil.
A especificação [FIP 2002o] descreve o protocolo de transporte HTTP com
detalhes.
4.6 FIPA-OS
A Nortel Networks, empresa com sede em Harlow, Inglaterra foi responsável
pela criação do FIPA Open Source ou FIPA-OS, uma ferramenta para desenvolvimento
de agentes que implementa todos os elementos obrigatórios do padrão FIPA. Segundo a
Nortel Networks: “a primeira meta do FIPA-OS é reduzir as atuais barreiras para adoção
da tecnologia FIPA através da suplementação dos documentos de especificações FIPA
com código-fonte aberto. Ele visa a qualidade e funcionalidade do seu código-fonte, que
irá evoluir com sua popularização, oferecendo um benefício mútuo para todos os usuários
e permitindo o progresso do paradigma orientado à agentes”. Em um software de código
aberto, o código-fonte é oferecido ao usuário juntamente com os arquivos executáveis. O
código-fonte é livre e sua licença de uso não proíbe os usuários de modificá-lo ou
distribuí-lo. Com isso, os usuários podem utilizar arquivos executáveis personalizados ao
invés dos originais.
57
FIPA-OS é totalmente desenvolvido com tecnologia Java, portanto ao invés de
arquivos executáveis, esta ferramenta é composta por uma coleção de arquivos de classe
que são interpretados por uma Java Virtual Machine – JVM. Os arquivos de classes
representam todos os elementos obrigatórios do padrão FIPA, além de alguns elementos
opcionais. A versão atual do FIPA-OS é a 2.1.0 e toda as considerações a respeito do
FIPA-OS nesta monografia se referem a essa versão.
4.6.1 Distribuição FIPA-OS
Como foi descrito na seção anterior, o FIPA-OS foi desenvolvido com
tecnologia Java. Ele é distribuído na forma de pacotes. Pacotes são coleções de classes
Java que, normalmente, compartilham alguma característica comum. A tabela 4 descreve
cada um dos nove pacotes da distribuição FIPA-OS:
TABELA 4 – Pacotes FIPA-OS.
Pacote Descrição
fipaos.agent Contém as classes que implementam os
elementos obrigatórios do padrão FIPA de um agente.
fipaos.comm Contém as classes que implementam a
comunicação e transporte de mensagens na plataforma.
fipaos.fipa Contém as classes utilizadas
especificamente pelo FIPA-OS, ou seja, classes para gerenciamento interno.
fipaos.ont Contém classes de ontologia.
fipaos.parser Contém classes com parsers de linguagens.
fipaos.platform Contém classes utilizadas pela plataforma, que não são componentes de agente.
fipaos.skill Contém classes para prover habilidades para os agentes.
fipaos.tool Contém classes para teste e depuração.
fipaos.util Contém classes úteis para a construção de agentes, mas que não são obrigatórias no
padrão FIPA.
58
4.6.2 Componentes FIPA-OS
Além dos componentes obrigatórios do padrão FIPA, o FIPA-OS possui
componentes adicionais para o gerenciamento da plataforma de agentes. A figura 15
apresenta uma visão geral destes componentes.
FIGURA 15 – Visão geral dos componentes FIPA-OS.
4.6.2.1 Implementação do agente
O FIPA-OS fornece um modelo chamado Agent Shell para a construção de
agentes. Um novo agente implementado com o FIPA-OS deve derivar da classe
FIPAOSAgent, que fornece métodos para registro com a plataforma, envio de
mensagens, configuração de tarefas (Tasks) e finalização do agente.
4.6.2.2 Estrutura de agente JESS - JESS Agent Shell
O Java Expert System Shell – JESS é uma ferramenta para desenvolvimento de
sistemas especialistas. Um sistema especialista é um conjunto de regras elaboradas a
partir de um conjunto de fatos, que são executadas quando um conjunto de pré-condições
é satisfeito. A estrutura de agente JESS fornece uma interface para o JESS, permitindo
que agentes possam ter uma base de conhecimento e capacidade deliberativa. A estrutura
59
de agente JESS é implementada na classe JessAgent, que é uma classe derivada da
classe FIPAOSAgent (mais informações na próxima seção).
4.6.2.3 Estrutura de agente - Agent Shell
A classe FIPAOSAgent fornece a estrutura básica para implementação de um
agente através da especialização (derivação) desta classe. Uma classe derivada de
FIPAOSAgent trata automaticamente de todas as inicializações dos componentes
centrais do FIPA-OS. A estrutura de agente fornece a seguinte funcionalidade:
− Envio de mensagens: Através do método forward() da classe
FIPAOSAgent ou Task. Essa mensagem é passada para o CM através do
sendMessage().
− Métodos para encontrar informações sobre o agente, tais como: AID e
estado, por exemplo.
− Métodos para registro na plataforma: O registro como os agentes AMS e
DF são feitos pelos métodos registerWithAMS() e
registerWithDF(), respectivamente.
− Configuração de tarefas: Provê acesso direto a classe TaskManager. A
próxima seção mostra detalhes sobre tarefas e gerenciamento de tarefas.
− Finalização de agente: Provê o método shutdown(), que finaliza o
agente na plataforma, disponibilizando seu recursos.
4.6.2.4 Gerenciador de tarefas
Para facilitar o desenvolvimento de agentes, o FIPA-OS introduziu o conceito
de tarefas. Uma tarefa encapsula parte da funcionalidade de um agente em uma classe
chamada Task. Dessa forma, o comportamento funcional de um agente pode ser dividido
em pequenas partes. Há diversas vantagens nesta abordagem:
− Tarefas são reusáveis por outros agentes.
60
− Torna mais fácil isolar e encontrar erros de programação, devido ao fato
do uso de tarefas incentivar a programação modular.
− Tarefas são executadas em linhas de execução paralelas (threads),
permitindo que os agentes possam executar várias tarefas simultaneamente.
O Gerenciador de Tarefas – Task Manager - TM é responsável pela coordenação
das tarefas de um agente. Ele é um objeto que possui um conjunto de referências para
todas tarefas ativas de um agente. O processo de coordenação de tarefas do TM é baseado
em eventos. Os eventos são enfileirados e processados um por vez pelo TM. A tabela 5
descreve os principais eventos que um TM processa.
TABELA 5 – Eventos tratados por um TM.
Evento Descrição
InitialisedEvent Indica que uma Task foi inicializada (através do método startTask()).
ConversationUpdateEvent Indica o recebimento de uma mensagem
por uma Task envolvida em uma conversação.
ChilDoneEvent Indica que uma classe-filha de uma Task
completou sua execução.
ChilDoneWithResultEvent Indica que uma classe-filha de uma Task completou sua execução e produziu um
resultado.
ChilTimeoutEvent
Indica que o tempo de execução de uma classe-filha de uma Task acabou e deve ser finalizada mesmo antes de completar
sua execução.
ChildFailureEvent Indica que ocorreu uma exceção na classe-
filha de uma Task.
Uma nova Task é criada a partir do método newTask() do TM ou de outra
Task. No segundo caso, a nova Task é chamada filha, ou classe-filha da primeira
Task.
61
Mensagens podem ser enviadas a partir de uma Task. Todas as conversações
iniciadas a partir de uma Task são associadas a esta Task pelo TM, para garantir que as
mensagens recebidas nesta conversação sejam repassadas para a Task correta.
4.6.2.5 Gerenciador de conversações – CM
Todas as mensagens trocadas entre agentes fazem parte de uma conversação. O
Gerenciador de Conversações – Conversation Manager – CM é responsável por agrupar
as mensagens de uma conversação. Também é responsabilidade do CM assegurar que
ambos os lados de uma conversação utilizem o mesmo protocolo de conversação.
4.6.2.6 Serviço de Transporte de Mensagem - MTS
A descrição geral do funcionamento de um Serviço de Transporte de Mensagem
- MTS se encontra na seção 4.3.4. O MTS do FIPA-OS é organizado em um modelo de
camadas de serviços. A figura 16 ilustra como é composto o modelo de camadas.
As mensagens enviadas por um agente chegam no MTS e sofrem modificações
à medida que elas passam de uma camada superior para uma inferior, até chegarem na
camada do Protocolo de Transporte de Mensagem - MTP. O protocolo MTP utilizado
para transportar a mensagem vai depender se essa mensagem destina-se à AP local ou a
uma AP remota. No caso da AP local, a mensagem é enviada para o agente de destino
passando pelas mesmas camadas de serviços, só que na ordem contrária. Se a mensagem
destina-se a uma AP remota, as camadas de serviços pela qual a mensagem deverá passar
vão depender de como o MTS remoto é implementado.
62
FIGURA 16 – Composição lógica do modelo de camadas do MTS do FIPA-OS.
As duas principais vantagens em adotar esse modelo são:
− Dividir a funcionalidade do MTS em pequenos módulos independentes
(serviços), que podem ser testados individualmente.
− Facilitar a introdução de novos serviços.
Os serviços mais comuns encontrados em cada uma das camadas são serviços
de parser e de-parser de linguagens de conteúdo.
4.6.2.7 Protocolos de transporte de mensagens - MTP
Um protocolo de transporte de mensagens (Messages Transport Protocol -
MTP) é que fornece os mecanismos para o transporte físico de mensagens entre agentes.
O FIPA-OS divide estes protocolos em dois tipos: Internos e Externos.
63
− MTPs Internos: São os MTPs encarregados de transportar mensagens
entre agentes de uma mesma AP. Para essa tarefa, o FIPA-OS utiliza o
Remote Method Invocation – RMI. O RMI é uma implementação da empresa
Sun, que faz parte da distribuição Java 2 Standard Edition. Como a utilização
do RMI se restringe ao Java, ela é eficiente para agentes implementados em
Java e não pode ser utilizada em agentes implementados em outra linguagem
de programação. Por estes dois motivos o RMI foi escolhido como MTP
interno padrão do FIPA-OS.
− MTPs Externos: São os MTPs encarregados de transportar mensagens
entre agentes de AP diferentes.Para essa tarefa, o FIPA-OS utiliza o IIOP
(seção 4.5.1). O IIOP possui a vantagem de ser potencialmente interoperável
com quaisquer agentes escritos em linguagens que suportem as especificações
CORBA (seção 4.5.1). Por este motivo, o IIOP foi escolhido como MTP
externo padrão do FIPA-OS.
4.6.3 Configuração e execução do ambiente FIPA-OS
Antes de executar o FIPA-OS, é necessário configurá-lo. O FIPA-OS é
distribuído com um script de configuração chamado SetupFIPAOS. Este script confira
um diretório de instalação para as classes FIPA-OS além de criar alguns arquivos de
configuração da plataforma chamados perfis (profiles). Estes arquivos são:
− acc.profile: Informações de configuração sobre o ACC da plataforma
local.
− default.profile: É um perfil padrão para agentes sem perfis definidos.
− loader.profile: Descreve os tipos de agentes que o AgentLoader pode
inicializar.
− platform.profile: Informações de configuração da plataforma, tais como:
nome da plataforma, localização do AMS e localização de outros perfis.
64
Só após a correta configuração do FIPA-OS é possível utilizá-lo. O script
StartFIPAOS inicializa todos os serviços necessários para executar agentes FIPA-OS, tais
como: RMI, IIOP, DF e AMS, além de executar o AgentLoader. O AgentLoader (figura
17) é uma interface gráfica que fornece meios de inicializar e finalizar agentes. Apesar de
agentes FIPA-OS poderem ser inicializados de outras formas, é extremamente
aconselhável inicializar agentes apenas através do AgentLoader.
FIGURA 17 – Interface gráfica do AgentLoader.
65
5 Sistema de Compartilhamento de Arquivos para FIPA-OS
Neste capítulo será descrito um sistema de compartilhamento de arquivos
desenvolvido com o FIPA-OS. A funcionalidade deste sistema é baseada nos softwares
de compartilhamento de arquivos descritos no capítulo 2.
5.1 Visão geral
Utilizando a abordagem de desenvolvimento de sistemas multiagentes com a
ferramenta FIPA-OS, foi desenvolvido um software para compartilhar arquivos em uma
AP ou entre APs. Ele é composto de duas partes: uma responsável pelo compartilhamento
e transmissão de arquivos e outra pelo consulta, requisição e conseqüentemente, recepção
de arquivos. O usuário utiliza uma interface gráfica gerenciar estes processos. O sistema
roda no ambiente FIPA-OS, e é inicializado a partir do AgentLoader (ver capítulo 4) ou
através de um arquivo de script, caso a máquina que irá rodar o software na tenha uma
instalação do FIPA-OS.
5.2 Descrição dos agentes
Os agentes utilizados no sistema desenvolvido são reativos, ou seja, apenas
respondem a estímulos externos e não possuem uma base de conhecimento. Essa
abordagem foi escolhida devido ao comportamento do sistema ser do tipo consulta –
resposta. O comportamento consulta – resposta é definido por um sistema com elementos
ativos, que dão início aos processos do sistema, e os elementos passivos, que despertam
para ações através de um estímulo externo. Os elementos ativos no sistema de
compartilhamento de arquivos desenvolvido são as consultas e as transferências de
arquivos, enquanto que são considerados elementos passivos as respostas às consultas. Os
elementos ativos e passivos do sistema de compartilhamento de arquivos desenvolvido
66
são incorporados por dois tipos de agentes, chamados FFA e SFMA. Os FMAs e SFMAs
são descritos com maior nível de detalhes à seguir.
Para consulta, foi desenvolvido um agente chamado File Finder Agent – FFA.
Ele é responsável por fazer consultas por arquivos em todas as plataformas acessíveis.
Também é responsabilidade do FFA tratar das tarefas de recebimento do arquivo na
plataforma local, tais como: definir um diretório de chegada de arquivos, gravar o
arquivo recebido no diretório de chegada, além do recebimento do arquivo propriamente
dito.
Arquivos que se encontram em todas as plataformas acessíveis por um FFA só
podem ser encontrados se estiverem sendo compartilhados da forma adequada. Para
compartilhar os arquivos, foi desenvolvido um agente chamado Shared Files Manager
Agent – SFMA. Sua função é informar, quando solicitado, se um arquivo se encontra ou
não compartilhado pela plataforma. Além disso, ele é responsável pelo envio de arquivos
para outras plataformas.
5.2.1 File Finder Agent – FFA
Como já foi descrito anteriormente, a principal função do FFA é encontrar
arquivos em APs rodando pelo menos um SFMA. O FFA fornece uma interface gráfica
para facilitar a interação do usuário com o agente. É nesta interface que são fornecidos o
nome dos arquivos que se deseja encontrar e transferir. A interface também fornece
meios para visualizar informações gerais dos arquivos encontrados em uma consulta, tais
como: nome, tamanho e identificador do agente SFMA que compartilha o arquivo.
A funcionalidade do agente FFA é definida através de quatro tipos de ações:
− Consultar a existência do arquivo no sistema.
− Caso o arquivo exista, requerer a transferência do arquivo.
− Transferir o arquivo.
− Cancelar a transferência do arquivo.
Para consultar sobre a disponibilidade de um arquivo, o usuário fornece à
interface gráfica do FFA o nome do arquivo desejado, através do campo de texto de
consulta (figura 18) e confirma a consulta através do botão de consulta. A partir deste
momento, o FFA vai começar um processo de busca nos DFs do sistema por serviços de
67
compartilhamento de arquivo. Ao término desta busca, o agente FFA receberá uma lista
com descrições de todos agentes SFMA registrados no sistema até então. Com a ajuda
desta lista, o agente FFA enviará mensagem de consulta sobre o arquivo desejado para
cada agente SFMA da lista. O resultado da busca é mostrado na janela de arquivos
encontrados.
FIGURA 18 – Interface gráfica do agent FFA.
Para começar um processo de transferência de arquivo, o usuário seleciona o
arquivo na janela de arquivos encontrados e confirma o início do processo no botão de
transferência de arquivo. O início do processo consiste do envio de uma mensagem de
requisição de transferência de arquivo para o agente SFMA que compartilha o arquivo.
Após uma troca de mensagens de inicialização, o processo de transferência do arquivo é
estabelecido. O progresso desta transferência pode ser acompanhado na interface gráfica,
na janela de andamento de transferências de arquivo. A qualquer momento, uma
transferência de arquivo pode ser interrompida. Para fazer isso, o usuário deve selecionar
a transferência que deseja cancelar na janela de andamento de transferências de arquivo e
68
confirma o cancelamento no botão de cancelamento de transferência. Quando um
cancelamento de transferência é sinalizado para um FFA, ele envia uma mensagem de
cancelamento de transferência para o SFMA participante do processo.
5.2.1.1 Modelo interno do FFA
As ações de um FFA foram descritas de uma forma abstrata na seção anterior.
Nesta seção será descrito como estas ações foram implementadas no FFA com a ajuda da
ferramenta FIPA-OS. O modelo interno do FFA é ilustrado na figura 19.
FIGURA 19 – Modelo interno do FFA.
Um agente FIPA-OS é derivado de uma classe abstrata para descrição de
agentes chamada FIPAOSAgent. O FFA deriva desta classe. A funcionalidade do FFA
descrita na seção anterior foi implementada com o uso de Tasks. As Tasks (ver capítulo
3) são classes FIPA-OS utilizadas para descrição de tarefas realizadas por agentes. As
Tasks desenvolvidas para utilização do agente FFA são:
− FileQueryTask: Define a tarefa de consultar um SFMA específico
sobre a existência do arquivo desejado. Ela é realizada através do envio de uma
mensagem de consulta para o SFMA e espera por uma mensagem que informa a
existência ou não do arquivo. Esta tarefa possui um tempo fixo para ser
concluída. Se ao final do tempo o FFA não obtiver nenhuma resposta do SFMA
consultado, a tarefa será concluída sem resultados.
69
− FileQueryAllTask: Define a tarefa de consultar todos os SFMAs
encontrados pelo FFA. Para isso, cria várias tarefas FileQueryTask, uma
para cada SFMA consultado. Esta tarefa também possui um tempo fixo para ser
concluída.
− FileRequestTask: Define a tarefa de requisitar a um SFMA a
transferência de um arquivo. Ela é realizada através do envio de uma mensagem
de requisição de transferência de arquivo. Esta é a única ação executada por
essa tarefa.
− ReceiveFileTask: Defina a tarefa de receber os pacotes com dados
do arquivo requerido. Ela é iniciada pela IdleTask do FFA após este receber
uma mensagem informativa que sinaliza o início do recebimento do arquivo. A
primeira mensagem que ReceiveFileTask recebe é uma mensagem
informativa com conteúdo relativo aos parâmetros da transmissão, tais como:
número de pacotes de dados em que o arquivo será dividido para transmissão e
tamanho destes pacotes. Pacotes são partes de arquivos que estão anexadas ao
conteúdo da mensagem. As mensagens informativas seguintes já contêm os
dados do arquivo e uma informação sobre número de seqüência do pacote. Para
cada uma destas mensagens que é processada com sucesso, o FFA envia uma
mensagem de confirmação para o SFMA emissor. Uma mensagem de
desconfirmação poderá ser enviada caso o pacote que chegar não possua o
número de seqüência adequado. Uma tarefa ReceiveFileTask é finalizada
após receber o último pacote ou via intervenção do usuário, com o
cancelamento da transferência do arquivo.
5.2.1.2 Interação interface gráfica – FFA
A interação entre interface gráfica e agente FFA é feita através de eventos. O
agente FFA é registrado como ouvinte dos eventos da interface gráfica. A interface
dispara três tipos de eventos relativos à transferência de arquivos:
− FileQueryEvent: Evento disparado quando o usuário confirma o
nome do arquivo consultado através do botão de consulta,
70
− FileRequestEvent: Evento disparado quando o usuário confirma a
requisição de transferência de arquivo através da escolha do arquivo na janela
de resultados da consulta seguido da confirmação no botão de transferência de
arquivo.
− FileTransferCancelEvent: Evento disparado quando o usuário
solicita o cancelamento de uma transferência de arquivos em curso, através da
seleção da respectiva barra de progresso de transferência de arquivos seguido da
confirmação no botão de cancelamento de transferência.
A figura 20 mostra as interações entre a interface gráfica e o FFA.
FIGURA 20 – Interação interface gráfica – FFA.
5.2.2 Shared Folders Manager Agent – SFMA
O SFMA é um pouco menos complexo que o FFA principalmente por não ser
um agente ativo no sistema. Sua tarefa é informar, quando consultado, a existência ou
71
não de determinados arquivos. Também é responsável por transmitir arquivos para FFAs
que os requisitarem.
A funcionalidade do SFMA divide-se entre quatro tipos de ações:
− Adicionar e remover diretórios do compartilhamento.
− Responder sobre a existência ou não, no compartilhamento, do arquivo
consultado.
− Caso o arquivo se encontre compartilhado, transmiti-lo ou não,
dependendo da situação.
− Cancelar uma transferência em curso.
Através do SFMA um usuário pode selecionar diretórios do sistema operacional
da máquina que pertence à plataforma do SFMA para compartilhamento, através de uma
interface gráfica. Todos os arquivos dos diretórios selecionados serão compartilhados,
mas apenas arquivos. Se existir um outro diretório dentro de um diretório previamente
selecionado para compartilhamento, o primeiro deve ser selecionado manualmente,
através da janela de seleção de diretórios para compartilhamento (figura 21). Este
procedimento é utilizado para todos os diretórios escolhidos para compartilhamento.
72
FIGURA 21 – Interface gráfica do SFMA.
Toda vez que um diretório é adicionado ao compartilhamento, o SFMA
adiciona a uma lista de arquivos compartilhados referências a todos os arquivos contidos
neste diretório. É esta lista que o SFMA utiliza como base de pesquisa de consultas feitas
por FMAs. Os nomes dos novos arquivos compartilhados são mostrados em uma janela
de avisos da interface gráfica.
5.2.2.1 Modelo interno do SFMA
A implementação das ações realizadas pelo SFMA,é descrita a seguir. O modelo
interno do SFMA é ilustrado na figura 22.
73
FIGURA 22 – Modelo interno do SFMA.
Novamente, a exemplo do FFA, foram utilizadas Tasks para a implementação
das ações do SFMA. Foram utilizadas três Tasks na implementação do SFMA:
− FileQueryResponseTask: Define a tarefa de responder a uma
consulta por disponibilidade de um arquivo feita por um FFA, A resposta, que é
enviada em uma mensagem informativa, depende se o arquivo encontra-se ou
não na lista de arquivos compartilhados do SFMA. A resposta (sim ou não) está
no conteúdo da mensagem informativa. Esta tarefa é finalizada logo após o
envio da resposta.
− FileRequestResponseTask: Define a tarefa de responder a uma
requisição de transferência de arquivos feita por um FFA. O tipo da mensagem
de resposta depende se o SFMA concorda ou não em transferir o arquivo. Se
concordar, o SFMA envia uma mensagem de concordância e inicia uma tarefa
SendFileTask, senão envia uma mensagem de recusa. Esta tarefa é
finalizada logo após estes procedimentos.
− SendFileTask: Define a tarefa de transmissão do arquivo para o FFA.
Ela é iniciada pela FileRequestTask. A primeira ação desta tarefa é enviar
uma mensagem informativa com informações sobre os parâmetros da
transmissão, tais como: número de pacotes de dados em que o arquivo será
dividido para transmissão e tamanho destes pacotes. As mensagens seguintes
são mensagens informativas com os dados empacotados e com o número de
74
seqüência. Após enviar o último pacote, SendFileTask fica esperando uma
mensagem informativa de fim de transmissão. Quando esta mensagem chega, a
tarefa é finalizada. Se esta mensagem não chegar, a SendFileTask será
finalizada após um tempo pré-determinado.
5.2.2.2 Interação interface gráfica – SFMA
Assim como o FFA, o SFMA também possui uma interface gráfica com o
usuário baseada em eventos. O agente SFMA é registrado como ouvinte dos eventos da
interface gráfica. A interface dispara dois tipos de eventos relativos à transferência de
arquivos:
− SharedFoldersListUpdatedEvent: Evento disparado quando o
usuário adiciona ou remove um diretório na lista de diretórios compartilhados.
− FileTransferCancelEvent: É o mesmos evento utilizado pela
interface gráfica do FFA e é utilizado de forma análoga. É disparado quando o
usuário solicita o cancelamento de uma transferência de arquivos em curso,
através da seleção da respectiva barra de progresso de transferência de arquivos
seguido da confirmação no botão de cancelamento de transferência.
A figura 23 mostra as interações entre a interface gráfica e o SFMA.
75
FIGURA 23 – Interação interface gráfica – SFMA.
5.3 Modelo de organização do sistema de compartilhamento de arquivos
O sistema é organizado na forma de um MAS heterogêneo. Além dos agentes
sempre presentes na plataforma FIPA-OS como o AMS e o DF, o sistema é composto por
agentes FFA e SFMA. Não há uma restrição lógica ao número de agentes FFA e SFMA
em uma mesma máquina de uma plataforma, porém existe uma restrição física, porque os
agentes consumem recursos de sistema, principalmente os agentes FIPA-OS que são
desenvolvidos em Java e por isso necessitam de uma JVM para serem interpretados. De
qualquer forma, para procurar arquivos em plataformas remotas, é necessário pelo menos
carregar um agente FFA e para compartilhar arquivos de uma plataforma é necessário
pelo menos um agente SFMA.
Ao serem executados, os agentes FFA e SFMA automaticamente registram seus
serviços no DF local. O DF local pode estar registrado em outros DFs remotos, criando
uma estrutura federada. Quando um FFA faz uma consulta de disponibilidade de um
arquivo, inicialmente o DF local procura por serviços de SFMA registrados localmente,
isto é, nele mesmo. Em seguida, faz uma busca em todos os DFs nele registrado. O
resultado é passado para o FFA.
76
5.4 O modelo de troca de mensagens
Para executar suas tarefas, os FFAs e SFMAs estão constantemente trocando
mensagens. Estas mensagens representam os atos de comunicação definidos em [FIP
2002g] e são utilizadas conforme mostra a figura 24.
FIGURA 24 – Modelo de troca de mensagens.
77
O modelo de troca de mensagens define o protocolo de interação entre os
agentes FFA e SFMA. O modelo ilustrado na figura 24 não mostra as mensagens de
cancelamento de transferência porque estas podem acontecer a qualquer momento da
conversação. Também não mostra as mensagens do tipo not-understood, devido ao
mesmo motivo. O que é importante saber é que quando uma mensagem com conteúdo de
cancelamento de transferência ou do tipo not-understood ocorrer, o processo de
conversação será finalizado.
A ação de consulta começa com o envio, por parte FFA, de uma mensagem
query-if para o SFMA, que responde com uma mensagem inform-if. O conteúdo da
mensagem queri-if é uma string “Have file?” e uma lista de descrições de arquivos
encontrados. É importante observar que strings são utilizadas nesse sistema para
representar atos da locução da fala (ver capítulo 3). A mensagem inform-if pode ter como
conteúdo a string “Yes” e uma lista de arquivos com o nome consultado ou a string
“No”.
A ação de requisição, que só começa se a ação de consulta teve sucesso, isto é,
se encontrou algum resultado, consiste do envio por parte do FFA de uma mensagem
request para o SFMA, que responde com uma mensagem agree, se concordar em
começar a ação de transferência de arquivo ou responde com uma mensagem refuse, caso
contrário. O conteúdo da mensagem request é a string “Transfer file” juntamente com a
descrição do arquivo. Tanto as mensagens agree e refuse têm como conteúdo a descrição
do arquivo, mas a mensagem refuse também possui uma string com o motivo da recusa.
Se o SFMA aceitar a requisição de transferência de arquivo do FFA, o processo
de transferência do arquivo poderá começar. O SFMA envia para o FFA uma mensagem
inform-if, que têm por conteúdo uma string “File transfer start” e duas informações, uma
indicam o número total de pacotes e outra que sinaliza o tamanho de cada pacote. Se o
FFA receber esta mensagem, enviará como resposta uma mensagem confirm, que tem por
conteúdo uma string “Send next, que indica que o FFA está pronto para receber uma
próxima parte do arquivo. Como resposta a mensagem de confirm recebida, o SFMA
envia uma outra mensagem inform-if com os dados do arquivo. Este processo se repete
até o FFA enviar uma mensagem inform-if que tenha por conteúdo uma string “Transfer
78
done” que sinaliza que o FFA recebeu todos os pacotes. Este é o fim da transferência de
arquivo com sucesso
O processo de transferência do arquivo pode ser cancelado a qualquer momento
por qualquer uma das partes envolvidas no processo.
5.5 Execução do sistema
Para que o sistema possa ser utilizado, é necessário que a plataforma seja
inicializada. Isto pode ser feito através do script StartFIPAOS da instalação do FIPA-
OS. Com uma plataforma inicializada, é possível que agentes FFAs e SFMAs registrem-
se à essa plataforma.
Os scripts startFFA e startSFMA carregam os protocolos e classes Java
necessárias para a execução dos agentes FFA e SFMA, respectivamente. Estes scripts
inicializam os serviços de registro RMI e IIOP necessários para o transporte de
mensagens. Após este inicialização, o arquivo com o perfil da plataforma é carregado. É
neste arquivo que deve conter as informações sobre o endereço do AMS para que o
agente FFA ou SFMA possa registrar-se na plataforma.
Quando o script startFFA é executado, o FFA tenta registrar-se ao AMS
local e o seus serviços no DF local. Se estas duas tentativas de registro tiverem sucesso, a
interface gráfica do FFA será carregada e o usuário poderá fazer consulta por
disponibilidade de arquivos em todos os SFMA registrados na plataforma.
O processo de execução do SFMA ocorre de forma semelhante, exceto que o
script de inicialização é startSFMA Quando um SFMA se registra na plataforma, ele
estará apto a disponibilizar arquivos para todos os FFAs registrados na plataforma e,
eventualmente, em outras plataformas.
79
6 Conclusão
Ao concluir este trabalho, cabe ressaltar como foi a preparação para começar todo
o processo de desenvolvimento do sistema de compartilhamento de arquivos P2P
apresentado nesta monografia. Na fase de elaboração, uma série de problemas foi
encontrada, e uma abordagem para resolução de cada um destes problemas foi escolhida.
A seguir são listados os principais problemas encontrados e quais as soluções encontradas
para resolver estes problemas:
− O desenvolvimento de aplicações de sistemas distribuídos em grandes
redes exige, devido à complexidade e características, tais como distribuição
física dos elementos e heterogeneidade de plataformas que dão suporte a estas
aplicações, ferramentas de desenvolvimento compatíveis com estas
necessidades.
− No caso específico de uma aplicação para compartilhamento de arquivos
em uma rede de computadores, um grande problema é como projetar a aplicação
de forma que esta possa trabalhar com os diversos sistemas operacionais
existentes e a linguagem de programação Java resolveu este problema. O acesso
a arquivos e recursos do sistema operacional é abstraído em classes, que são
interpretadas por uma máquina virtual Java adequada ao sistema operacional
utilizado.
− Outro problema era como encontrar e acessar os vários hosts de uma rede
de computadores para utilizar o serviço de compartilhamento de arquivos. A
organização destes hosts em plataformas habitada por agentes que fornecem o
serviço de compartilhamento de arquivos, isto é, um sistema multiagentes, foi
uma forma intuitiva de resolver este problema.
− Para implementação do sistema multiagente, era necessária uma
ferramenta que fornecesse a infra-estrutura adequada para o desenvolvimento de
agentes. A ferramenta para desenvolvimento de agentes FIPA-OS atendeu a
80
essa necessidade, além de possuir duas características importantes: é totalmente
desenvolvida em Java e segue as especificações FIPA.
Após escolher a abordagem para o desenvolvimento, foi possível tentar alcançar o
objetivo traçado no início do desenvolvimento do trabalho. O objetivo geral era
desenvolver um sistema de compartilhamentos de arquivos P2P utilizando uma
abordagem multiagentes. Para tanto, foram estabelecidos como objetivos específicos
propor uma arquitetura de sociedade de agentes que possa ser aplicada na implementação
do sistema de compartilhamento de arquivos, um modelo de agentes que represente de
forma adequada às funções de cada nodo do sistema, tais como: gerência, consulta e
transferência de arquivos através da rede, a utilização de mecanismos de comunicação e
cooperação entre os agentes do sistema, para viabilizar a execução das funções do
sistema, organizar esta arquitetura de forma que cada agente represente um nodo do
sistema e contribuir para o a popularização da utilização da abordagem multiagente para
desenvolvimento de software.
Apesar destes objetivos terem sido alcançados, muitos outros aperfeiçoamentos
poderiam ter sido feitos. Estes aperfeiçoamentos aumentariam a usabilidade do sistema,
mas fugiam um pouco ao escopo da motivação do trabalho e, por isso, não foram
implementados. Cabe ressaltar também as principais contribuições específicas realizadas
neste trabalho:
− A apresentação de uma abordagem multiagentes para desenvolvimento de
aplicações P2P para compartilhamento de arquivos.
− O estabelecimento de um modelo de agentes para troca de arquivos em uma
rede de computadores.
− A proposição de um modelo de coordenação dos agentes adequados à tarefa
de compartilhar e transferir arquivos em uma rede de computadores.
Com base nas contribuições específicas citadas acima, espera-se que este trabalho
sirva de incentivo para o desenvolvimento de novos sistemas para compartilhamento de
arquivos que utilizem a abordagem multiagentes e que estes sistemas venham a se tornar
81
o padrão para este tipo de aplicação, já que eles podem apresentar características que os
sistemas mais populares dos dias de hoje, como o Kazaa [KAA 2002], não apresentam,
tais como: capacidade de coordenação, aprendizagem, cooperação e comportamento
inteligente.
Para finalizar, uma lista dos aperfeiçoamentos que aumentariam muito a
usabilidade do sistema desenvolvido é mostrada a seguir:
− Aprimoramento da cooperação entra agentes com a adição de meios de um
agente buscar um mesmo arquivo de vários outros agentes.
− Oferecer suporte a restabelecimento de transferência de arquivos perdidas.
− Desenvolvimento de uma agente com uma base de conhecimento de
localização dos arquivos no sistema, para acelerar a consulta de arquivos.
82
7 Bibliografia
[ATT 2000] ATTOUI, A. & INGRAM, S. Real-Time and Multi-Agent Systems. Chambery: Springer Verlag, 2000.
[BIG 2001] BIGUS, J.P. & BIGUS, J. Constructing Intelligent Agents Using Java.
New York: John Wiley & Sons, Inc, 2001. [COU 94] COULOURIS, G & DOLLIMORE, J & KINDBERG, T. Distributed
Systems – Concepts and Design. London: Addison-Wesley, 1994. [DRE 2001] DREAMTECH SOFTWARE TEAM. Peer-to-Peer Application
Development – Cracking The Code. New York: Hungry Minds Inc, 2001.
[FER 99] FERBER, J. Multi-Agent Systems: An Introduction to Distributed
Artificial Intelligence. USA: Addison-Wesley Pub Co, 1999. [FIP 2002a] FIPA. Abstract Architecture Specification. Foundation for Intelligent
Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002b] FIPA. SL Content Language Specification. Foundation for Intelligent
Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002c] FIPA. CCL Content Language Specification. Foundation for Intelligent
Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002d] FIPA. KIF Content Language Specification. Foundation for Intelligent
Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002e] FIPA. RDF Content Language Specification. Foundation for Intelligent
Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002f] FIPA. Agent Management Specification. Foundation for Intelligent
Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
83
[FIP 2002g] FIPA. Communicative Act Library Specification. Foundation for Intelligent Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002h] FIPA. ACL Message Structure Specification. Foundation for Intelligent
Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002i] FIPA. Agent Message Transport Service Specification. Foundation for
Intelligent Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002j] FIPA. ACL Message Representation in Bit-Efficient Encoding
Specification. Foundation for Intelligent Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002k] FIPA. ACL Message Representation in String Specification.
Foundation for Intelligent Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002l] FIPA. ACL Message Representation in XML Specification. Foundation
for Intelligent Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002m] FIPA. Agent Message Transport Protocol for IIOP Specification.
Foundation for Intelligent Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002n] FIPA. Agent Message Transport Protocol for WAP Specification.
Foundation for Intelligent Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIP 2002o] FIPA. Agent Message Transport Protocol for HTTP Specification.
Foundation for Intelligent Physical Agents, 2000. Disponível em <http://www.fipa.org/specs/fipa00070/>. Acesso em: 10 de set.2002.
[FIPA 2002p] FIPA-OS. Foundation for Intelligent Physical Agents Open Source.
Nortel Networks Corporation. Disponível em <http://fipa-os.sourceforge.net/>. Acesso em: 18 de set.2002.
[HUH 98] HUHNS, M.N. & SINGH, M.P. & GASSER, L. Readings in Agents.
Morgan Kaufmann Publishers, 1998. [KAZ 2002] KAZAA. Sharman Networks Ltd. Disponível em
<http://www.kazaa.com/>. Acesso em: 30 de out.2002.
84
[MIL 2002] MILOJICIC, D.S. & KALOGERAKI, V. & LUKOSE, R. &
NAGARAJA, K. & PRUYNE, J. & RICHARD, B. & ROLLINS, S. & XU, Z. Peer-to-Peer Computing. Palo Alto: HP Laboratories, 2002.
[NAP 2002] NAPSTER. Roxio Inc. Disponível em <http://www.napster.com/>. Acesso
em: 30 de out.2002. [ORA 2001] ORAN, A. Peer-to-Peer: Harnessing the Power of Disruptive
Technologies. USA: O’Reilly & Associates, 2001. [RIC 94] RICH, E. & KNIGHT, K. Inteligência Artificial. São Paulo: McGraw-
Hill, 1994. [RIP 2002] RIPEANU, M. Peer-to-Peer Architecture Case Study - Gnutella
Network. Proceedings of the First International Conference on Peer-to-Peer Computing, 2002.
[SEA 70] SEARLE, J.R. Speech Acts: An Essay in the Philosophy of Language.
Cambridge: Cambridge University Press, 1970. [STO 97] STONE, P & VELOSO, M.M. Multiagent Systems: A Survey from a
Machine Learning Perspective. Technical Report. Pittsburgh: Carnegie Mellon University, 1997.
[SUB 2000] SUBRAHMANIAN, V.S. & BONATTI, P. & DIX, J. & EITER, T. &
OZCAN, F. Heterogeneous Agent Systems. USA: MIT Press, 2000. [SYC 98] SYCARA, K.P. Multiagent Systems. AI Magazine. Disponível em
<http://www.aaai.org/Library/Magazine/Vol19/19-02/vol19-02.html>. Acesso em: 01/01/2003.
[TAN 97] TANENBAUN, A.S. Redes de Computadores. Rio de Janeiro: Campus,
1997. [TOR 2001] TORRES, G. Redes de Computadores: Curso Completo. Rio de
Janeiro: Axcel Books, 2001. [WEI 2000] WEISS, G. Multiagent Systems: A Modern Approach to Distributed
Artificial Intelligence. USA: MIT Press, 2000. [WOO 95] WOOLDRIDGE, M. & JENNINGS, N.R. Intelligent Agents: Theory
and Practice. Knowledge Engineering Review, Vol. 10, No. 2. Cambridge: Cambridge University Press, 1995.
85
[WOO 97] WOOLDRIDGE, M. Agent-Based Software Engineering. IEEE Proceedings. Software Engineering 144(1), pag.26-27, 1997.
[ZEU 2002] ZEUS. The ZEUS Agent Building Tool-Kit. British
Telecommunications. Disponível em
<http://more.btexact.com/projects/agents.htm>. Acesso em: 13/11/2002.