PROGRAMA INSTITUCIONAL DE BOLSAS DE

INICIAÇÃO CIENTÍFICA - PIBIC/CNPq-FA-UEM

CNPq
RELATÓRIO FINAL UEM

PERÍODO DE ABRANGÊNCIA DO PROGRAMA: 1º/08/2009 a 31/07/2010

1. BOLSISTA: Helio Henrique Lopes Costa Monte Alto

2. ORIENTADOR: Profª. Drª. Elisa Hatsue Moriya Huzita 3. DEPARTAMENTO: Departamento

de Informática

4. CO-ORIENTADOR: Profª. Drª. Tânia Fátima Calvi Tait 5. DEPARTAMENTO: Departamento

de Informática

6. TÍTULO DO PROJETO: ESTUDO DE MOBILIDADE DE AGENTES EM APLICAÇÕES SENSÍVEIS AO

CONTEXTO

7. RELATÓRIO CONTENDO OS RESULTADOS DA PESQUISA

8. COMPROVANTE DE APRESENTAÇÃO DOS RESULTADOS DA PESQUISA EM EVENTOS CIENTÍFICOS

Foi submetido resumo no EAIC-2010.

9. COMPROVANTE DE PUBLICAÇÃO, COM A PARTICIPAÇÃO DOS BOLSISTAS, EM PERIÓDICOS

INDEXADOS E/OU COM CORPO EDITORIAL.

10. AVALIAÇÃO DO ORIENTADOR SOBRE O DESEMPENHO DO BOLSISTA NO PROJETO.

O acadêmico teve um excelente desempenho.

11. AVALIAÇÃO DO ORIENTADOR SOBRE O PROGRAMA INSTITUCIONAL DE BOLSAS DE INICIAÇÃO

CIENTÍFICA.

É uma excelente oportunidade para iniciar o acadêmico em atividades de pesquisa. Possibilita contacto
com membros participantes de projeto de pesquisa, muitas vezes com diferentes experiências,
proporcionando um meio fértil para aprender e também desenvolver o espírito crítico. Isto contribui na
formação pessoal e profissional do acadêmico.

12. AVALIAÇÃO DO ACADÊMICO SOBRE O PROGRAMA INSTITUCIONAL DE BOLSAS DE INICIAÇÃO

CIENTÍFICA.

Foi encontrada, durante o desenvolvimento deste trabalho, uma grande oportunidade para investigar e
assimilar novos conhecimentos e produzir resultados satisfatórios. O conhecimento extra adquirido, quer
técnico como de equipe, será de grande valia para a formação pessoal e profissional. A bolsa constitui-se
em um importante fator motivador para os trabalhos desenvolvidos e, também, de apoio financeiro para os
acadêmicos.
UNIVERSIDADE ESTADUAL DE MARINGÁ
PROGRAMA INSTITUCIONAL DE BOLSAS DE INICIAÇÃO CIENTÍFICA –
PIBIC/CNPq – Fundação Araucária – UEM
DEPARTAMENTO DE INFORMÁTICA
ORIENTADORA : Profa. Dra. Elisa Hatsue Moriya Huzita
CO-ORIENTADORA: Profa. Dra. Tânia Fátima Calvi Tait
BOLSISTA: Helio Henrique Lopes Costa Monte Alto

ESTUDO DE MOBILIDADE DE AGENTES EM APLICAÇÕES SENSÍVEIS AO

CONTEXTO

Maringá, 31 de agosto de 2010.

1
UNIVERSIDADE ESTADUAL DE MARINGÁ
PROGRAMA INSTITUCIONAL DE BOLSAS DE INICIAÇÃO CIENTÍFICA –
PIBIC/CNPq – Fundação Araucária – UEM
DEPARTAMENTO DE INFORMÁTICA
ORIENTADORA : Profa. Dra. Elisa Hatsue Moriya Huzita
CO-ORIENTADORA: Profa. Dra. Tânia Fátima Calvi Tait
BOLSISTA: Helio Henrique Lopes Costa Monte Alto

ESTUDO DE MOBILIDADE DE AGENTES EM APLICAÇÕES SENSÍVEIS AO

CONTEXTO

Relatório contendo os resultados

finais do projeto de iniciação
científica vinculado ao
PIBIC/CNPq- Fundação Araucária -
UEM.

Maringá, 31 de agosto de 2010.

2
Resumo

Os avanços tecnológicos e o crescente volume de conhecimento digital oferecem

a oportunidade para serviços digitais mais sofisticados. Aliado a isto, as organizações
estão se tornando, cada vez mais, geograficamente dispersas levando à distribuição dos
negócios, dos recursos e das pessoas. Assim, o acesso aos recursos, às informações e
aos serviços, bem como o estabelecimento de comunicação entre as partes envolvidas
na construção de aplicações, demandam por técnicas e ambientes de desenvolvimento
distribuído de software. A utilização de agentes para o desenvolvimento de sistemas
complexos é importante e tem recebido atenção de desenvolvedores de software. Em
particular, devido à sua natureza autonômica e ativa, os agentes móveis podem oferecer
apoio à decisão de aplicações sensíveis ao contexto. Este trabalho tem por objetivo
estudar agentes móveis, buscando mecanismos adequados para se definir/estabelecer a
interação em uma infraestrutura de construção de agentes, com foco em aplicações
sensíveis a contexto.

Palavras-Chave: Mobilidade, Agentes de Software, Aplicações Sensíveis ao Contexto.

3
1. Introdução
Atualmente, estamos vivenciando um uso sem precedentes da Internet e de
tecnologias de comunicação e computação em aplicações comerciais, governamentais,
educacionais e, também, das áreas de saúde e de defesa. Ainda, avanços tecnológicos e
o crescente volume de conhecimento digital oferecem o acesso a serviços digitais mais
sofisticados. Devido a tais avanços, é possível observar que não apenas as organizações,
mas também as pessoas, os recursos e os negócios estão se tornando cada vez mais
geograficamente distribuídas. Assim também ocorre com o desenvolvimento de
software. Desta forma, a colaboração entre as pessoas envolvidas em um ambiente
distribuído de desenvolvimento de software torna-se imperativa.
Para o apoio à colaboração destas equipes, é necessário que haja um ambiente o
qual trate de questões próprias da distribuição, como a acessibilidade aos recursos e às
informações, liberação de serviços e a comunicação entre as partes na construção de
aplicações. O suporte a este ambiente requer uma infraestrutura mais complexa, que
pode se valer do apoio oferecido pelo paradigma de agentes de software.
Porém, muitas vezes a ação de um único agente não é suficiente, sendo
necessário que haja uma estrutura para que vários agentes coexistam e trabalhem de
forma cooperativa. Tais agentes compõem um sistema multiagente, e encapsulam
funcionalidades específicas e oferecem serviços para troca de informações com outros
agentes. Em outras palavras, formam uma sociedade de agentes onde há a interação
mútua entre os agentes assim como há a interações deles com o ambiente, levando a um
comportamento global.
A abordagem multiagente vem sendo considerada adequada para lidar com
sistemas que são compostos de muitos elementos provavelmente distribuídos e
desenvolvidos por equipes diferentes, e que precisam interagir. Para lidar com essa
distribuição, agentes móveis têm se destacado, pois são vistos como programas
autônomos com a habilidade de se transportar entre os nós de uma rede sob seu
controle, carregando consigo os dados e o estado da execução para reassumir a
execução no seu local de destino.
Graças à maturidade alcançada por especificações propostas pela FIPA
(Foundation for Intelligent Pysical Agents), várias plataformas têm sido desenvolvidas e
disponibilizadas. Dentre estas as mais conhecidas são; JADE, FIPA-OS e Zeus. Todas
elas oferecem uma infraestrutura com recursos que auxiliam o desenvolvedor na tarefa
4
de implementar agentes e, assim, aumentar a qualidade, a confiabilidade e a
interoperabilidade de aplicações baseadas em agentes. Para este trabalho é utilizada a
plataforma JADE, pois facilita de fato a implementação de agentes uma vez que
possuem vários recursos prontos, como bibliotecas de classes e padrões pré-definidos
que atendem às especificações da FIPA.
Outro ponto importante em relação à colaboração entre as pessoas envolvidas
em um ambiente distribuído é o fato de que, para que todos os membros de uma equipe
virtual atuem de forma coordenada e colaborativa, o ideal é que estejam inseridos em
um ambiente capaz de perceber o contexto no qual está inserido, um ambiente que seja
sensível ao seu contexto.
Ser sensível a contexto (do inglês context-aware) se refere à adaptação do
comportamento de uma aplicação como uma função do ambiente em questão. Em outras
palavras, uma aplicação sensível a contexto pode também utilizar atributos não
diretamente associados às atividades sendo realizadas para modelar o seu
comportamento, como locais físicos, os dispositivos utilizados, a largura de banda de
rede e os perfis dos usuários. Context-aware systems, ou sistemas sensíveis a contexto,
podem perceber estas informações referentes ao ambiente e utilizá-las para interpretar
os eventos que ocorrem nestes.
Os sistemas sensíveis ao contexto, em conjunto com agentes móveis, fazem
parte também do domínio dos sistemas ubíquos (pervasivos). Tais sistemas são
constituídos de dispositivos heterogêneos interconectados de modo a tornar a interação
humano-computador natural e transparente. Assim, é possível que quase tudo possa se
tornar um nó em um sistema distribuído.
Outra aplicação de grande utilidade para agentes móveis sensíveis ao contexto é
a computação móvel, que permite ao usuário se mover pelo ambiente enquanto
trabalha, tendo sempre em mãos o mesmo ambiente, as mesmas aplicações e os mesmos
dados, independente do dispositivo a ser usado.
Para uma infraestrutura oferecer suporte à percepção de contexto esta deve
apoiar o auto-ajuste à mudança de contexto, os pontos de acesso, auto-organização e
reconfiguração de serviços e usuários, de modo que estes possam ser coordenados
inteligentemente e agir em harmonia. Tal modelo de software pode ser baseado sobre o
paradigma de agentes (Titkov, 2005).
Assim, as características presentes em agentes e a possibilidade de explorá-las
no desenvolvimento de aplicações complexas no contexto do desenvolvimento

5
distribuído de software, motivaram a execução do presente projeto que tem por
finalidade estudar agentes móveis e mecanismos de interação entre agentes, que possam
ser adotados no projeto de sistemas sensíveis a contexto.

6
Objetivos

Encontra-se em desenvolvimento na Universidade Estadual de Maringá o projeto

de pesquisa “Suporte à Percepção e ao Contexto em Ambientes de Desenvolvimento
Distribuído de Software” (Huzita, 2008), que tem por objetivo construir um ADDS, o
DiSEN (Distributed Software Engineering eNvironment).
Este trabalho encontra-se relacionado a este grupo de pesquisa, e tem por
objetivo geral investigar mecanismos de interação e mobilidade de agentes no
desenvolvimento aplicações sensíveis ao contexto.
Para que a meta proposta seja alcançada, foi realizada a divisão do objetivo geral
em três objetivos específicos:
• Aprofundar conhecimentos sobre a tecnologia de agentes,
particularmente no que se refere à mobilidade e protocolos de interação;
• Explorar recursos avançados oferecidos pelo JADE para implementação
de agentes móveis;
• Explorar o impacto do uso de agentes móveis em aplicações context
awareness;

2. Desenvolvimento ( Materiais e Métodos)

Principais Conceitos

Os conceitos básicos adotados por este trabalho são:

Agentes de Software: Um agente de software pode ser considerado como sendo
uma entidade de software capaz de executar tarefas de forma autônoma, reagindo aos
estímulos do ambiente no qual está inserido, tomando suas próprias iniciativas e
interagindo com outras entidades (Oliveira, 2000).
Contexto: É qualquer informação que caracteriza a situação de uma entidade,
onde uma entidade pode ser uma pessoa, lugar ou objeto considerados relevantes para a
interação entre um usuário e uma aplicação, incluindo o próprio usuário e aplicação. O
contexto é tipicamente a localização, a identidade, e o estado das pessoas, grupos e
objetos físicos e computacionais (Dey e Abowd, 2000).
Sistemas Distribuídos: sistema no qual os componentes de hardware ou de
software alocados em computadores em rede comunicam e coordenam suas ações
apenas por meio de envio de mensagens (Colouris et al, 2001).

7
Mobilidade

O estudo sobre mobilidade, assim como o de agentes de software, é uma área

relativamente nova e, portanto, as pesquisas que envolvem mobilidade definem o termo
de diversas formas diferentes, sendo grande parte delas relacionadas à mobilidade do
código (Fuggetta et at, 1998)(Carzaniga et al, 1997) e em agentes móveis (Chess et al,
1996):
• Código Móvel: capacidade de trocar dinamicamente as ligações entre os
fragmentos de código e o local onde o código é executado.
• Agentes móveis são programas que podem ser disparados de um
computador cliente e transportados para um computador remoto para ser
executado (Chess et al, 1996);
• Mobilidade: é a habilidade de se mover independentemente de um
dispositivo para outro por meio da rede (Glass, 1998);
O presente trabalho se concentra no estudo da mobilidade por meio de agentes
de software.

Agentes Móveis

De acordo com definições encontradas na literatura, agentes móveis possuem as

mesmas propriedades que agentes não móveis possuem, como as que são descritas por
Wooldridge (1995):
• Autonomia: capacidade de um agente atuar sem a direta intervenção
humana e externa, e possuir algum controle sobre suas ações e seu estado
interno.
• Habilidade social: citada por outros autores também por
comunicabilidade, habilidade social é a capacidade de um agente
interagir com outros agentes (e outras entidades) por meio de algum tipo
de linguagem de comunicação.
• Reatividade: capacidade de perceber o seu ambiente e responder de modo
adequado e no tempo certo às mudanças que nele ocorrem, podendo este
ambiente ser o mundo físico, um usuário interagindo por meio de uma

8
 interface gráfica, uma coleção de outros agentes, Internet, ou ainda, todos
eles combinados.
• Pró-atividade: capacidade dos agentes não apenas em responder aos
estímulos do ambiente, mas também em exibir o comportamento dirigido
por objetivos, tomando iniciativas.
Porém, além destas propriedades, possuem também a propriedade de
mobilidade, que segundo o mesmo autor, pode ser descrita como a capacidade de
movimentar-se de uma máquina para outra por meio do ambiente computacional.
Portanto, agentes móveis são agentes capazes de interagir com outras entidades, de
reagir aos estímulos do ambiente, ao mesmo tempo em que possuem a capacidade de se
movimentar entre máquinas para cumprir suas tarefas.
Do ponto de vista de sistemas distribuídos, segundo Bellifemine (2007), um
agente móvel é um programa com um identificador único e que possui a capacidade de
mover o seu código, seus dados e seu estado entre máquinas que estejam conectadas por
uma rede. Para que isso seja possível, os agentes devem ser capazes de suspender a sua
execução em qualquer momento e continuar uma vez que estejam em outro local.
Segundo o mesmo autor, conforme a Figura 01, agentes móveis consistem em
três principais partes:
• Código: o código se trata do aspecto do agente que é executado quando
ocorre a sua migração para outra máquina. No caso mais simples existe
uma única execução a ser feita.
• Estado: o estado trata dos dados do ambiente de execução do agente,
inclusive o contador de programa e a pilha de execução referente ao
código sendo executado.
• Dados: os dados consistem nas variáveis utilizadas pelos agentes, de
fontes como conhecimento ou identificadores de arquivos.

9
 Figura 01. Estrutura básica de um agente. Adaptado de Bellifemine (2007).

Dentro deste escopo, pode-se falar em Sistema de Agentes Móveis (MAS, do

inglês Mobile Agent System): é uma plataforma de software a qual define mecanismos
de mobilidade e comunicação entre agentes de software. Em Sistemas de Agentes
Móveis, dois tipos primários de migração podem ser distinguidos: forte e fraca
(Tanenbaum e Van Steen, 2001)(Brown e Rossak, 2005)(Bellifemine, 2007).
A migração forte é mais complexa, pois a execução do agente é congelada para
então ocorrer a migração, em seguida ela continua no novo local a partir da próxima
instrução do código. Isto requer técnicas para lidar com o armazenamento e a proteção
do estado do agente durante o processo de migração, fato que impõe sua complexidade,
pois em sua implementação é necessário o acesso a parâmetros internos da execução do
agente, o que pode ser dependente da arquitetura do sistema operacional em que se
encontra.
Já a migração fraca não envia para o novo local o estado do agente, se tornando
muito mais simples, pois o agente sempre reinicia a partir do início do seu código. Se
for necessário manter algum tipo de estado, este tipo de migração requer que o código
do agente seja implementado como uma máquina de estados finitos.
Lange e Oshima (1999) apresentam sete razões principais para a utilização de
agentes móveis:
• Agentes móveis evitam que a rede fique sobrecarregada. Um sistema
distribuído depende, normalmente, de protocolos de comunicação para
cumprir uma dada tarefa, e isto resulta em um excesso de tráfego.
Agentes móveis permitem que partes de uma comunicação sejam

10
 empacotadas em um local, para então serem disparadas para outro local,
onde as interações ocorrerão.
• Agentes móveis superam a latência da rede. Em sistemas de tempo real,
como robôs em processos de fabricação, existe a necessidade de
responder em tempo real às mudanças em seus ambientes. Para tais
sistemas, a latência da rede não é aceitável. Agentes móveis oferecem
uma solução, pois eles podem ser expedidos a partir de uma central de
controle para agir localmente e executar as instruções diretamente.
• Agentes móveis encapsulam protocolos. Quando os dados são trocados
em um sistema distribuído, cada local possui o uma implementação dos
protocolos necessários para o envio dos dados do código de saída e para
interpretar os dados de entrada. Os protocolos evoluem para acomodar
novos requisitos de eficiência ou de segurança, portanto é difícil atualizar
o código do protocolo de forma correta. Como resultado, os protocolos
muitas vezes se tornam um problema legado. Agentes móveis, por outro
lado, podem se mover
para locais remotos para estabelecer canais de comunicação baseados em
protocolos padrões.
• Agentes móveis são capazes de executar assincronamente e
autonomamente. Os dispositivos móveis muitas vezes dependem de
conexões de rede caras ou frágeis. As tarefas que exigem uma conexão
continuamente aberta entre um dispositivo móvel e uma rede fixa são,
provavelmente, nem economicamente nem tecnicamente viável. Para
resolver este problema, as tarefas podem ser incorporadas em agentes
móveis, que podem então ser enviados pela rede. Depois de serem
expedidos, os agentes tornam-se independentes do processo que os criou
e podem operar de forma assíncrona e autônoma. O dispositivo móvel
pode ligar mais tarde para recolher o agente.
• Agentes podem perceber o seu ambiente de execução e reagir
autonomamente a mudanças. Múltiplos agentes móveis têm a capacidade
única de distribuir-se entre os anfitriões na rede para manter a
configuração ideal para resolver um problema particular.

11
 • Eles são naturalmente heterogêneos. Computação em rede é
fundamentalmente heterogênea, muitas vezes, tanto em quesito de
hardware quanto de software. Como agentes móveis são programas
rodados em máquinas e independentes da camada de transporte, são
ideais para tratar com heterogeneidade, uma vez que dependem apenas
do seu ambiente de execução.
• A capacidade dos agentes para reagir dinamicamente a situações
desfavoráveis e eventos torna mais fácil a construção de sistemas mais
robustos e tolerantes a falhas. Por exemplo, se uma máquina está sendo
desligada, todos os agentes em execução são avisados, podendo migrar e
continuar a sua operação em outro local da rede.
Apesar das várias vantagens apresentadas pelas razões descritas acima, é
possível traçar algumas desvantagens da implementação de agentes móveis
(Bellifemine, 2007):
• Escalabilidade e desempenho: apesar dos agentes reduzirem a carga da
rede, eles também tendem a aumentar o processamento.
• Portabilidade e padronização: agentes móveis heterogêneos não
conseguem se comunicar se não seguirem padrões de comunicação.
Necessitam de padrões para que seja possível migrarem entre diferentes
plataformas.
• Segurança: O uso de agentes móveis pode acarretar problemas de
segurança. Qualquer código móvel pode trazer um perigo potencial se
não for cuidadosamente autenticado antes de sua invocação.
Quanto à segurança, pode-se diferenciar duas áreas: segurança do host, no que se
refere à proteção da plataforma contra agentes maliciosos; e segurança do código, que
trata da proteção do agente contra plataformas maliciosas. Jansen e Karygiannis (2000)
citam algumas possíveis formas de ataque:
• Masquerading: um agente se apodera da identidade de outro para ter
acesso a recursos ou dados, ou um host assume uma identidade falsa para
capturar agentes;
• Denegação de serviço: agentes podem consumir ou corromper recursos
fornecidos por um host para impedir que outros agentes tenham acesso a
eles, ou um host pode rejeitar as requisições por serviço;

12
 • Acesso não autorizado: os agentes podem procurar por falhas de
segurança e ganhar acesso a informações ou recursos não permitidos a
eles. Isto pode ser feito por um agente que interfere nas tarefas de outros
para ganhar acesso a dados.
Uma das principais vantagens da utilização de agentes móveis sobre os
paradigmas de comunicação mais usados atualmente, como o cliente/servidor, é a
possibilidade de um agente ser despachado do cliente e, a partir daí, trabalhar de forma
autônoma e independente do cliente. Isto possibilita que o cliente se desconecte após o
envio das requisições. Em uma rede inalâmbrica, onde há maior probabilidade de falhas
de conexão, e com a utilização de dispositivo móvel com poucos recursos como cliente,
tal situação de interrupção de conexão é desejável (Figura 02). Isso torna o paradigma
de agentes móveis melhor do que outros paradigmas que requerem conexão contínua
entre cliente e servidor, no que tange à tolerância a falhas em conexões mais instáveis e
lentas.

Figura 02. Modelo de agentes móveis em uma conexão cliente/servidor. (Adaptado de Spyrou et
al, 2004)

Comparação entre paradigmas de comunicação para sistemas

distribuídos

Além do paradigma de agentes móveis, existem outros dois paradigmas de

comunicação bastante conhecidos e adotados. Um deles é o paradigma cliente/servidor,
que é o mais largamente usado atualmente para as mais diversas situações em
computação distribuída. O outro é a avaliação remota, que possui algumas
características similares à mobilidade de agentes, pois inclui o conceito de código
móvel.

Cliente/servidor
Segundo Puliato et al (1999), a tarefa do servidor nesse paradigma é apenas a
execução de procedimentos de recuperação e armazenamento de dados, deixando ao
13
cliente a tarefa de processar os dados. Uma das maiores vantagens desse modelo é a
segurança, devido às restrições na forma como se acessa os dados, já que o servidor
disponibiliza ao usuário apenas os métodos definidos no projeto do sistema. A baixa
flexibilidade para a geração de novas operações, no entanto, implica numa carga
desnecessária para o servidor e para o sistema de comunicação.
Alguns modelos que procuram estender o modelo cliente/servidor para a
incorporação de agentes de software vêm sendo propostos. Tais extensões têm como
objetivo criar modelos adequados para a utilização em computação móvel com rede
inalâmbrica. Alguns exemplos são: cliente/agente/servidor e
cliente/interceptador/servidor.

• Cliente/agente/servidor: baseia-se na alocação de agentes estacionários

entre cliente e servidor com o objetivo de minimizar as consequências de problemas de
conexão em redes inalâmbricas e da limitação de recursos de dispositivos portáteis.
Como mostra a Figura 03, o agente se põe ao lado do servidor, podendo atuar como
representante do dispositivo cliente ou estar relacionado a algum serviço ou aplicação
em particular. Tal agente é também chamado de proxy. O problema desse modelo é que
não é possível manter operações no dispositivo cliente durante fases de conexão. Dessa
forma, apenas as operações que ocorrem diretamente no servidor podem ser otimizadas
(Spyrou et al, 2004). Apesar disto, este é o modelo mais indicado para clientes com
poucos recursos computacionais, pois não se faz necessária a permanência de um agente
no lado do cliente.

Figura 03. Modelo cliente/agente/servidor. (Adaptado de Spyrou et al, 2004)

• Cliente/interceptador/servidor: neste modelo, acrescenta-se um agente ao

lado do cliente (Figura 04). Portanto, tal modelo é mais apropriado quando o dispositivo
cliente possui capacidades computacionais suficientes para a execução do agente.
Também permite que o agente do lado do servidor execute parte das tarefas, podendo
haver interrupções de conexão sem que haja pausa em todas as operações envolvidas

14
com a interação em rede. Outra vantagem é que os dois agentes podem se comunicar
entre si a fim de aperfeiçoar o protocolo e a transmissão de dados, e também dividir
tarefas entre eles de acordo com as condições do ambiente (Spyrou et al, 2004). Além
disso, o agente do lado do servidor pode ser implementado como um agente móvel que
é despachado do cliente, podendo este realizar operações onde são necessárias
interações com outros dispositivos. Uma variante deste esquema é o modelo ponto a
ponto (do inglês, peer to peer), onde todos os dispositivos são, ao mesmo tempo,
clientes e servidores.

Figura 04. Modelo cliente/interceptador/servidor. (Adaptado de Spyrou et al, 2004)

Avaliação remota
Nesse modelo, o servidor receberá, junto às requisições de processamento, o
código necessário para efetuar as operações. Dessa forma, todo o processamento é
realizado no servidor, minimizando os recursos computacionais requeridos no
dispositivo cliente. Isto torna a avaliação remota um paradigma bastante atraente
quando deseja-se trabalhar com dispositivos móveis com baixa capacidade de
processamento e/ou armazenamento. Contudo, a demora na abertura de uma sessão
torna o custo inicial maior que em cliente/servidor, apesar do retorno dos resultados na
avaliação remota ser mais rápido em dispositivos com baixo poder computacional.

De fato, em uma rede inalâmbrica com transações de tamanhos medianos,

utilizando-se o modelo cliente/agente/servidor há um ganho de desempenho de cerca de
10% sobre o paradigma cliente/servidor comum (Spyrou et al, 2004). Além disso, o
modelo cliente/servidor mais usado atualmente, onde não há a utilização de agentes,
oferece flexibilidade, escalabilidade e robustez limitados. Tal problema é exacerbado
em redes sem fio, que possuem conexão mais lenta e instável do que redes cabeadas.
Em consultas em bancos de dados, as vantagens da utilização de agentes móveis
são ainda mais visíveis. Em conexões seguindo o modelo cliente/servidor, o cliente

15
geralmente necessita baixar informações do sistema gerenciador de banco de dados, o
que leva um tempo inicial considerável. Utilizando agentes móveis, um agente pode ser
disparado do cliente diretamente para o servidor de banco de dados, onde ele poderá
realizar as consultas diretamente, para então retornar os resultados ao cliente. Assim,
além do agente móvel possibilitar que a conexão seja interrompida durante a consulta,
há um ganho de tempo considerável por não ser necessário baixar drivers e outras
informações necessárias para a realização de consultas no banco de dados.
A única limitação que o paradigma de agentes móveis cria, nesse contexto, é o
fato de que, a cada requisição de transação com o banco de dados, um agente deve ser
enviado ao servidor. De qualquer modo, de acordo com experimentos realizados por
Spyrou et al (2004), os ganhos em desempenho são de cerca de 25% sobre a utilização
de conexão cliente/servidor comum.
Agentes móveis podem também ser usados em conjunto com as extensões do
paradigma cliente/servidor apresentadas. Nestes modelos, deve ser feita uma
configuração para cada aplicação diferente, resultando em configurações estáticas.
Utilizando agentes móveis, é possível permitir configuração dinâmica.
No modelo cliente/agente/servidor, pode-se considerar o esquema já citado
anteriormente, onde um agente é disparado do cliente para o servidor, onde ele irá
"estacionar" e então realizar as operações requisitadas. O conceito continua sendo o
mesmo do modelo c/a/s, porém aqui o agente (proxy) do lado do servidor é criado
dinamicamente de acordo com o cliente com que está lidando. Tal esquema se mostra
muito eficiente nos casos em que o cliente solicita várias consultas consecutivas com o
mesmo servidor de banco de dados. Outro benefício é que o agente, uma vez enviado ao
servidor, pode percorrer outros hosts pela rede antes de retornar ao cliente.
No caso do modelo cliente/interceptador/servidor, também há a possibilidade de
incorporar agentes móveis. Quando há uma requisição, dois agentes são criados no
cliente. Um dos agentes, que chamamos de client-side agent, permanece no cliente,
enquanto o outro, o server-side agent, é disparado para o servidor. Ao "estacionar" no
servidor, o server-side agent pode realizar suas operações e, sempre que necessário, se
comunicar via troca de mensagens com o client-side agent. Isso possibilita que a
comunicação possa ser feita tanto via mensagens quanto via migração de agentes,
tornando a comunicação ainda mais flexível.

16
Mecanismos de Mobilidade

Fuggetta et al (1998) classificam os mecanismos de mobilidade conforme a

Figura 05. Segundo o autor, os mecanismos de mobilidade são divididos levando em
conta o gerenciamento do código e do estado de execução, e a realocação de recursos e
reconfiguração das ligações existentes com o agente móvel.
Para a realocação de recursos, é necessário haver um gerenciamento do espaço
de dados (do inglês, data space management). A estratégia para gerenciar os recursos e
os dados envolvidos na transferência de código pode variar de sistema para sistema.
Uma primeira estratégia abordada é a remoção das ligações (do inglês, binding
removal). A unidade de execução migra para outro local, porém as ligações são
descartadas.
Outra estratégia é chamada de referência na rede (do inglês, network reference).
Quando um recurso não é transferível, como um recurso de hardware, por exemplo, a
ligação na unidade de execução com o recurso é modificada para referenciar o recurso
no ambiente computacional fonte depois que a unidade de execução tenha alcançado o
ambiente computacional destino.

Figura 05. Mecanismos de Mobilidade (Adaptado de Fuggetta et al, 1998).

17
 A estratégia de religação (do inglês, re-binding), pode ocorrer quando no
ambiente computacional remoto há um recurso do mesmo tipo que é referenciado na
unidade de execução original. Desta forma, a ligação com o recurso no ambiente
computacional fonte é desfeita, e é criada uma nova ligação apontando para o recurso
no ambiente computacional destino.
Na estratégia por cópia é criada uma cópia do recurso existente no ambiente
computacional original, e a ligação é modificada para referenciar a cópia, que é então
transferida junto com a unidade de execução para o ambiente computacional destino.
A última estratégia é a estratégia por movimento, na qual o recurso é transferido
de forma conjunta com a unidade de execução para o ambiente computacional destino.
Porém, a ligação com o ambiente computacional fonte não é desfeita.
Quanto ao gerenciamento do código e do estado de execução, conforme descrito
anteriormente, a migração pode ocorrer de forma forte, na qual o estado da execução do
ambiente é também transferido para o novo local, ou de forma fraca, na qual o estado
não é transferido, e a execução do agente no novo local se inicia do começo do código.
Para a migração forte, existem dois mecanismos: o de migração (do inglês,
migration) e o de clone remoto (do inglês, remote cloning). No mecanismo de
migração, é suspendida a execução de um agente, que é transmitido para o ambiente
computacional destino para retomar sua execução. A migração pode ser proativa (do
inglês, proactive) ou reativa (do inglês, reactive). Na primeira, o tempo em que ocorre e
o destino da migração são determinados pela unidade de execução que está migrando.
Na segunda, a migração é acionada por outras unidades de execução que tenham alguma
espécie de ligação com a unidade de execução que está migrando.
O mecanismo de clone remoto cria uma cópia da sua unidade de execução no
ambiente remoto. A unidade de execução não é isolada do ambiente computacional
origem. Da mesma forma que no mecanismo de migração, o clone remoto pode ser
proativo ou reativo.
A principal diferença entre esses dois mecanismos é a continuidade ou não da
execução do agente no local de origem. Na migração, o agente se transporta para um
novo local, implicando que as tarefas que estavam sendo executadas sejam
interrompidas e retomadas no destino. Já na clonagem remota, após o processo de
clonagem ter ocorrido, o agente original continua sendo executado no seu local de
origem, ao mesmo tempo em que um novo agente, clone do original, é executado de
forma independente do primeiro no local de destino.

18
 Já para a migração fraca existem mecanismos que têm a capacidade de transferir
seu código por meio de ambientes computacionais e de se ligar dinamicamente com
uma unidade de execução ativa ou criar uma nova unidade de execução no ambiente
remoto para a execução. Estes mecanismos podem ser classificados de diversas formas:
de acordo com a direção da transferência do código, com a natureza do código movido,
com o tipo de sincronização envolvido e o momento em que o código é executado no
ambiente remoto.
Segundo a direção do código a ser transferido, uma unidade de execução pode
trazer (do inglês, fetching) o código para ser executado, ou pode levar (do inglês,
shipping) o código para outro ambiente. Em ambos os casos (fetching ou shipping), o
código a ser transferido é autônomo (do inglês, stand-alone code) ou fragmentado (do
inglês, code fragment).
No primeiro caso, é criada uma unidade de execução no destino para executar o
código que está chegando ao ambiente. No segundo caso, a unidade de execução que
está chegando ao ambiente deve se ligar com alguma unidade que esteja executando o
código ou que eventualmente o tenha executado.
Além disso, tanto no código autônomo como no código fragmentado, estes
mecanismos ainda podem ser classificados em síncronos (do inglês, synchronous) ou
assíncronos (do inglês, asynchronous). Essa classificação depende da unidade de
execução que solicita a migração, que pode ficar suspensa ou não até que o código seja
executado. No modo assíncrono, a execução do código transferido pode ser imediata,
sendo executado logo que recebido pelo destino, ou postergada, de forma a esperar
alguma condição ser satisfeita para iniciar a execução no ambiente destino.
A clonagem de agentes se diferencia da migração pelo fato de o agente na
origem não ser excluído do ambiente de execução. Assim, quando um agente é clonado,
é conveniente que ele nunca retorne à origem, ao contrário do que costuma ocorrer na
migração.
Foram encontradas duas aplicações para clone remoto de agentes. A primeira
trata da distribuição de agentes entre diversos hosts. Nesse caso, um agente modelo
permanece numa central e, sempre que requisitado, ele é clonado, e o seu clone é
enviado ao host que necessita deste agente. Tal técnica pode ser muito útil quando a
execução dos agentes não é iniciada logo ao iniciar o sistema, mas sim no decorrer de
sua execução. Também torna possível que os novos agentes criados possuam
características, como valores de variáveis, atualizadas. Em outras palavras, cada vez que

19
uma cópia de um agente adquire um novo conhecimento ou propriedade de importância
geral, é possível que tais modificações sejam salvas no agente de origem para que os
novos agentes criados incorporem tais características.
Outra aplicação para clonagem de agentes é para tratamento de overload em
sistemas distribuídos que possuam um sistema multiagente (Shehory et al, 1998). Dois
tipos de overload podem ocorrer: quando o agente está sobrecarregado ou quando a
máquina está sobrecarregada. No primeiro caso, um agente está encarregado de tantas
tarefas que acaba gerando um gargalo. Uma possível solução é que tal agente crie um
clone de si mesmo, delegando parte de suas tarefas para o novo agente. O clone pode
tanto ser executado na mesma máquina quanto em uma máquina remota, já que o
objetivo é simplesmente dividir tarefas. É possível implementar o agente de forma que,
ao atingir a condição de overload, o agente analise sua carga atual e estime sua carga
futura, e analise também a carga de seu host e dos outros hosts disponíveis, a fim de
decidir onde o seu clone será executado. A divisão de tarefas e a decisão sobre onde o
clone será executado faz com que esta técnica seja difícil de implementar, embora seja
uma solução que possivelmente melhore o desempenho na execução de tarefas
complexas em um sistema distribuído.
No caso em que detecta-se que a máquina esteja sobrecarregada, a clonagem de
agentes pode ser, da mesma maneira, utilizada para divisão de tarefas com novos
agentes que serão executados em hosts remotos. Caso haja dificuldade na divisão de
tarefas, pode ser mais conveniente utilizar migração, onde o agente percebe a
sobrecarga de seu host e migra para uma máquina remota, retornando, posteriormente,
apenas os resultados de suas operações à origem.

Sistemas Sensíveis ao Contexto

Dey e Abowd (2000) apresentam o conceito de que um sistema é sensível ao

contexto se este utiliza contexto para prover informações relevantes e/ou serviços para o
usuário, no qual a relevância depende da tarefa do usuário. Uma vez que temos
informações do ambiente, é possível formar um raciocínio a partir deste contexto, de
forma a enriquecer a aplicação, trazendo recursos como a adaptabilidade do ambiente e
a assistência às tarefas em desenvolvimento.
Um conceito importante em relação a contexto é a percepção. Enquanto que
contexto é composto por informações que caracterizam elementos dentro de um sistema,

20
a percepção baseia-se no conhecimento, na compreensão das atividades dos outros, que
por si provê um contexto para as suas próprias atividades. Por percepção, portanto,
entende-se o conhecimento e a compreensão do que ocorre dentro e fora de um grupo,
que sejam relevantes para o desenvolvimento das atividades dos seus participantes no
desempenho de seus diferentes papéis, de forma que possa ser entendido como o
entendimento das atividades dos outros (Vieira, 2008) (Dourish e Belloti, 1992).
Porém, perceber e processar informações de contexto não é uma tarefa trivial.
Existem requisitos básicos a serem observados na construção de sistemas sensíveis ao
contexto, que são: aquisição, representação, processamento, armazenamento, uso
(percepção, assistência e adaptação) e compartilhamento (com políticas de segurança e
privacidade). (Vieira et al, 2006).
Para tais sistemas sensíveis ao contexto, cuja preocupação é perceber e processar
as informações de contexto de um ambiente, o paradigma de agentes de software é
indicado, uma vez que o uso de sistemas multiagente é interessante por sua capacidade
de operar de forma paralela com outras partes da aplicação.
Há duas aplicações que vem sendo alvo de interesse em sistemas de agentes
móveis e sensíveis ao contexto: computação ubíqua/pervasiva e computação móvel.
Um sistema pervasivo é aquele em que quase tudo em um ambiente físico pode
se tornar um nó em um sistema distribuído. Isto é possível graças à evolução
tecnológica que torna os dispositivos cada vez menores, sendo possível que
computadores sejam encontrados acoplados a diversos objetos, como carros,
refrigeradores, objetos pessoais, e até mesmo em sistemas de iluminação, ventilação e
aquecimento de ambientes. Junto a recursos de redes inalâmbricas, é também possível
que tais dispositivos estejam conectados, possibilitando a comunicação entre eles a fim
de alcançar objetivos em comum.
O seguinte cenário, adaptado de Braun e Rossak (2005), pode ser tomado como
exemplo: seu refrigerador informará ao seu smartphone quando houver escassez de
determinado tipo de alimento. Seu smartphone irá lhe avisar disto e, no supermercado,
irá interagir com o carrinho de compras e com o local do supermercado onde você se
encontra, afim de detectar possíveis itens que estejam sendo esquecidos. Ainda no
supermercado, sua camiseta irá detectar se seu batimento cardíaco ou sua pressão
sanguínea estão muito altos e, caso positivo, irá contatar seu smarphone para que lhe
advirta caso você tenha colocado muitas batatas chips e bolachas recheadas no carrinho.

21
 Todas essas interações vão requerer, no mínimo, que os dispositivos envolvidos
estejam conectados a uma rede inalâmbrica. Isto significa que tais transações serão
caracterizadas por banda estreita e baixa confiabilidade, isto é, há alta possibilidade de
que haja falhas na conexão. A partir disso pode-se observar um ponto muito forte na
utilização de agentes móveis para a implementação de sistemas pervasivos, já que estes
agentes têm como características a capacidade de evitar sobrecarga na rede e a
capacidade de reagirem dinamicamente a situações desfavoráveis, tornando-os
tolerantes a falhas.
Segundo Zaslavsky (2004), sistemas pervasivos necessitam também estar cientes
de seus ambientes e recursos disponíveis (isto é, devem estar cientes do contexto),
devem ter a capacidade de detectar mudanças no ambiente (mudanças no contexto) e
devem ser capazes de adaptar suas funcionalidades e comportamento às mudanças. A
utilização do paradigma de agentes móveis para a implementação de tais requisitos é
atraente e promissora por ser possível o compartilhamento e delegação de sobrecarga de
informação com entidades que podem, de forma diligente, inteligente e incansável,
realizar tarefas que só poderiam ser realizadas por usuários do sistema. Em outras
palavras, pode-se dizer que agentes móveis no mundo pervasivo virtual têm
comportamento análogo a pessoas no mundo real. Eles devem ser móveis e inteligentes
e devem usar os recursos disponíveis dinamicamente e tomar decisões de acordo com a
situação.
A computação móvel é outro tipo de aplicação que pode se beneficiar do
paradigma de agentes móveis e dos sistemas sensíveis ao contexto. Em um sistema que
utiliza computação móvel, o usuário pode se locomover enquanto trabalha,
possibilitando que ele se autentique no sistema a partir de diferentes tipos de sistemas
computacionais (por exemplo, em um determinado momento ele pode estar utilizando o
sistema a partir da LAN de sua empresa, e depois ele pode estar em casa utilizando o
mesmo sistema através de uma rede com conexão ISDN discada). É interessante
também que seja apresentado ao usuário sempre o mesmo ambiente, as mesmas
aplicações e os mesmos dados, não importando de onde ou de qual dispositivo ele esteja
utilizando o sistema (Braun e Rossak, 2005). Isso permite construir sistemas que
proporcionam ao usuário facilidade de uso e adaptação.
Aplicações que utilizam computação móvel também podem ser implementadas
como parte de um sistema pervasivo, já que pode-se considerar que o usuário possua um
dispositivo móvel, como um smartphone (como foi exemplificado anteriomente), e que

22
tal dispositivo interaja com um sistema pervasivo instalado no ambiente físico no qual o
usuário se encontra.
Enfim, levando em consideração que o paradigma de agentes móveis aceita,
como conceito básico, computação distribuída, e que suas vantagens tornam possível a
redução da complexidade na construção de sistemas sensíveis ao contexto, pode-se
chegar a um cenário onde a utilização de agentes móveis complementa a eficácia de um
sistema que gerencia equipes distribuídas geograficamente. Como tal sistema requer
sensibilidade ao contexto, é possível implementar um subsistema pervasivo local onde o
contexto capturado reflete no contexto do sistema como um todo. Isso poderia facilitar a
cooperação entre as equipes que se encontram geograficamente distantes, já que podem
existir informações que são muito naturais ao usuário, mas que podem ser de extrema
importância para uma eficaz cooperação entre equipes distribuídas. Estas informações
poderiam ser capturadas por dispositivos conectados a um sistema pervasivo que esteja
inserido no ambiente de trabalho físico de uma equipe local. Um exemplo desse tipo de
informação é a frequência da presença dos membros da equipe no local de trabalho. É
possível, através da computação móvel e ubíqua, que algum dispositivo detecte a
presença de um membro da equipe no local de trabalho e, em outro momento, consiga
estimar em que horário tal pessoa estará presente com base no que foi detectado
anteriormente. Tal informação passa, então, a fazer parte do contexto do sistema como
um todo.

JADE

A plataforma JADE (Java Agent Development Enviroment)(2009)(Bellifemine,

2007) é uma plataforma que oferece suporte à criação e ao gerenciamento de agentes de
software, implementada de acordo com as especificações da FIPA (Foundation for
Intelligent Physical Agents)(2009). A FIPA é uma organização relacionada à Sociedade
de Computação da IEEE (Institute of Electrical and Electronic Engineers, 2007). Ela
possui uma série de especificações que representam uma coleção de padrões que
pretendem promover a interoperabilidade de agentes heterogêneos e dos serviços que
eles podem representar.
JADE tem uma plataforma de serviços chamado de Mobility Agent Service, que
implementa mobilidade intra-plataforma. Isto permite que sejam criados agentes de
software com a capacidade de se mover entre diversos locais que possuam recipientes

23
da plataforma JADE. Esse mecanismo, no entanto, não permite que os agentes se
mudem para locais que possuam recipientes de outras plataformas. Um recipiente são os
processos que permitem a execução da plataforma JADE e todos os serviços necessários
para a hospedagem de agentes em execução. Dentro da execução de uma plataforma,
podem haver vários recipientes diferentes, e a locomoção de um agente entre estes
recipientes de uma mesma plataforma é também considerada mobilidade.
Em JADE, a capacidade de locomoção de um agente é controlada simplesmente
por meio do método doMove() na classe Agent:
void doMove(Location destination);
O parâmetro destino (do inglês, destination) deve ser um objeto que implementa
uma interface chamada Location, a qual indica para qual recipiente o agente será
movido. Na plataforma JADE existem duas classes que implementam essa interface. A
primeira é a classe ContainerId, usada para especificar que o destino do agente vai ser
um recipiente dentro da mesma plataforma onde está atualmente em execução. A
segunda é PlatformID, usada para indicar que o destino do agente é o recipiente
principal de uma plataforma diferente, quando estiver sendo utilizado o IPMS.
Uma vez invocado, o método doMove() inicia o processo de mover o agente para
o recipiente destino que foi especificado. A maioria das classes necessárias para a
realização deste processo é encontrada no jade.core.mobility da biblioteca JADE. A
primeira alteração que ocorre ao invocar o método doMove() é a mudança de estado do
agente de Ativo para Trânsito, fazendo com que o agente interrompa as suas atividades
e as suspenda enquanto a plataforma trata de migrá-lo.
Os estados do ciclo de vida de um agente são descritos conforme a Figura 06.

24
 Figura 06. Ciclo de vida de um agente definido pela FIPA (FIPA, 2009).

• AP_INITIATED. A instância da classe Agent foi criada, porém ainda não

foi registrada, não possui nome ou endereço e não pode se comunicar
com outros agentes (Inicializada).
• AP_ACTIVE. O agente está registrado, possui nome formal, endereço e
tem acesso a todas as funcionalidades do JADE (Ativa).
• AP_SUSPENDED. O agente está interrompido. Sua thread está suspensa
e nenhum comportamento está sendo executado (Suspensa).
• AP_WAITING. O agente está bloqueado, esperando por alguma coisa,
como algum processo do qual ele depende (Em espera).
• AP_DELETED. O agente está deletado ou encerrado e não se encontra
mais registrado (Desconhecido).
• AP_TRANSIT. Um agente móvel entra neste estado enquanto estiver
migrando para uma nova localização (Em Trânsito).
• AP_COPY. Esse estado é usado internamente pelo JADE para agentes
que foram clonados.
• AP_GONE. Esse estado é usado internamente pelo JADE quando um
agente móvel migrou para outra localização e se encontra em um estado
estável.
Os usuários podem especificar as operações que são disparadas quando o
processo de mobilidade é iniciado, a fim de, por exemplo, salvar o estado do
agente. Estas operações são implementadas pela substituição do método da classe
Agent:
void beforeMove()
Em contrapartida, existe um método chamado afterMove(), o qual é especificado
para executar as operações que devem ser executados logo após o agente se mover para
o novo local, e antes que ele recupere o seu estado ativo no local destino.
A migração de um agente deve incluir, pelo menos, a transmissão de seu código
e dados e, possivelmente, também o seu estado. Em JADE, os agentes modelam seu

25
estado de execução como dados internos do agente. Desta forma, só é necessário
transferir o código e dados. Os dados do agente estão contidos no objeto Java que
representa o agente. Transmitir este objeto, juntamente com seu código, será suficiente
para restaurar o agente no destino.
Como visto anteriormente, além de mover-se, um agente pode se clonar em
outro recipiente. JADE fornece também um mecanismo de clonagem que transfere uma
cópia de um agente existente usando o método:
public void doClone(Location destination, String newName)
O parâmetro de destino é usado, como no método doMove(), para indicar o
recipiente em que o clone do agente atual será criado. O parâmetro newName indica o
nome a ser usado para criar o identificador de agente (AID, do inglês Agent ID) do
agente clone. O processo de clonagem em si é o mesmo da mobilidade, tirando o fato de
que o agente original não é encerrado, resultando, desta forma, em dois agentes iguais,
com execução semelhante em todos os sentidos, exceto as suas identidades.
O Inter-Platform Mobility Service (IPMS, Serviço de Mobilidade Inter-
Plataformas) do JADE é um plugin que foi criado para fornecer a mobilidade entre
plataformas diferentes para agentes implementados em JADE, o que não é possível por
meio do Mobility Agent Service.
O IPMS foi especificamente projetado para ser o mais transparente possível para
o programador do agente, garantindo que a migração inter-plataformas seja tão simples
quanto a migração intra-plataforma. Para tanto, foi considerada a especificação FIPA
Agent Management Support for Mobility Specification (do inglês, Especificação FIPA
de Apoio à Gestão da Mobilidade).
O mecanismo central da IPMS é a movimentação de agentes entre plataformas
usando mensagens FIPA-ACL, implementadas segundo especificações da FIPA, como
o meio de transporte. Essas mensagens são enviadas entre a os agentes responsáveis
pelo gerenciamento das plataformas das extremidades do processo de
migração. Algumas alterações foram feitas com a especificação FIPA original, de forma
que uma ontologia define duas ações. A primeira delas representa o movimento de
código do agente e instância, o segundo representa a ativação do agente, uma vez que a
migração está completa.
Ambas as ações, movimentar-se e ativar-se, são realizadas usando o padrão de
protocolo de interação proposto pela FIPA. Em cada caso, uma mensagem de

26
solicitação é enviada para a plataforma de destino com uma mensagem Inform (do
inglês, informar) ou uma mensagem de falha esperada como uma resposta.

Figura 07. Protocolo de Solicitação de Mobilidade FIPA (Bellifemine, 2007).

Como ilustrado na Figura 07, no protocolo de solicitação de mobilidade FIPA, o

agente iniciador (à esquerda) envia uma solicitação para mover para sua plataforma.
Uma vez que for recebida a mensagem Inform, o agente iniciador envia uma solicitação
para mover a mensagem contendo o código do agente e os dados para a plataforma
destino especificada (à direita). Se a plataforma de destino extrai, com sucesso, do
agente a mensagem de solicitação, uma mensagem Inform é devolvida para a plataforma
de origem. Quando recebida, esta mensagem Inform aciona a plataforma de origem para
encerrar o agente iniciador e enviar uma solicitação para iniciar a execução na
plataforma de destino, iniciando o agente. Se alguma coisa falhar, o estado do agente na
plataforma de origem é restaurado e uma presença residual do agente na plataforma de
destino é removida.

Mecanismo de Comunicação JADE

O paradigma de comunicação entre agentes na plataforma JADE é baseado na

transmissão de mensagens assíncronas, de forma que cada agente possui uma espécie de
“caixa de entrada” (fila de mensagens do agente) onde são armazenadas as mensagens
enviadas por outros agentes em tempo de execução.
Cada mensagem é implementada pela classe ACLMessage (disponível em
jade.lang.acl.ACLMessage) e possui os seguintes campos:
• Remetente da mensagem.

27
 • A lista de destinatários.
• A ação da comunicação, que indica qual é a intenção do remetente ao
enviar a mensagem. Podem ser: REQUEST (o remetente quer que o
destinatário faça algo), INFORM (o remetente quer que o destinatário
fique ciente de algo), PROPOSE ou CFP (Call For Proposal) (caso o
remetente queira iniciar uma negociação).
• O conteúdo, que possui a real informação a ser trocada pela mensagem.
• Linguagem, indicando qual sintaxe utilizar.
• Ontologia, indicando o vocabulário de símbolos usados no conteúdo.
Além de outros campos, usados para o controle de várias conversações
concorrentes e para especificar um tempo para receber uma resposta.
Para realizar o envio de uma mensagem para outro agente, basta preencher as
informações dos campos da classe ACLMessage e ao final invocar o método send(),
como no exemplo ilustrado na Figura 08. Para o agente receber uma mensagem que está
em sua fila de mensagens, basta este invocar o método receive(). Caso não existam
mensagens, o retorno é nulo.

Figura 08. Exemplo de uma mensagem ACL.

O mecanismo de transporte das mensagens é adaptativo, pois é capaz de realizar

a adaptação para cada situação de forma transparente, escolhendo o melhor protocolo de
comunicação disponível. O pivô para a escolha do protocolo adequado é a localização
do agente receptor da mensagem, por exemplo: caso o receptor esteja no mesmo
recipiente que o emissor, a transmissão da mensagem é como um evento na aplicação e
é direcionada para a fila de mensagens do receptor; caso o receptor esteja na mesma
plataforma, mas em outro recipiente, a mensagem é passada via RMI (Remote Method
Invocation, JAVA, 2009); e, caso o receptor esteja em outra plataforma, a mensagem é
transmitida por meio do protocolo IIOP (Internet Inter-ORB Protocol, IIOP, 1999).

28
3. Resultados e Discussões
Estudo de caso

O estudo de caso realizado considerou um cenário de um sistema multiagente

com agentes móveis inseridos em um sistema sensível ao contexto. Tal cenário
procurou incorporar as principais situações/aplicações sobre as quais agentes móveis
podem agir para realizar parte das regras de negócio do sistema. Além disso, deseja-se
que as vantagens do uso de agentes móveis para essas aplicações sejam ressaltadas.
O sistema base tomado para a realização deste estudo é o sistema de uma
biblioteca inteligente. Nela agentes interagem e se movem através de terminais,
dispositivos pessoais dos usuários, servidores de banco de dados locais e remotos e um
servidor central onde são armazenadas as informações de contexto e de onde são
disparados os agentes móveis.
As principais interações envolvem o acesso do usuário ao sistema para a
realização de reserva de itens. De um modo geral, no domínio de bibliotecas, o usuário
reserva ou solicita um item, que então será encaminhado para a bancada da biblioteca
para efetivo empréstimo. Dessa maneira, o usuário pode realizar busca e reserva de
livros a partir de um terminal da biblioteca ou de um dispositivo pessoal (como um
laptop ou smartphone) conectado à rede inalâmbrica da biblioteca.
A partir dessa funcionalidade, foram desenvolvidos cenários que detalham o
envolvimento dos agentes móveis, suas interações e suas ações de captura e reação ao
contexto.

Cenário 1:
O usuário requisita, através da plataforma de agentes instalada em seu
dispositivo, a operação de busca de itens. Um agente no servidor central recebe a
requisição e envia o agente Ag1 para o dispositivo cliente. Ag1, ao estacionar no
dispositivo, terá suas credenciais confirmadas pela plataforma, recebendo permissão de
agir no dispositivo. Ag1 exibe ao usuário uma interface de busca de itens da biblioteca.
Os dados exibidos são recebidos do servidor de banco de dados mais próximo, porém
nem todos os dados referentes aos itens pesquisados são baixados, apenas as
informações essenciais para que o usuário encontre o que deseja. O usuário escolhe o
item que deseja reservar. O agente aceita a requisição e se move para o servidor de

29
banco de dados, onde realiza as operações requisitadas. Após o término de suas ações, o
agente retorna uma mensagem de sucesso ao dispositivo do usuário.
Caso a reserva tenha sido feita para o mesmo dia, o agente retorna à central,
onde entra em contato com o agente responsável pelo gerenciamento de entrega e
deslocamento de itens para que este tome suas providências para que o item reservado
seja encaminhado ao balcão da bibliotecária, onde o usuário pode, efetivamente, realizar
o empréstimo. Após o término de suas operações para este usuário, Ag1 pode ser
destruído ou usado em outra operação.

Discussão:
O agente consegue realizar as operações com sucesso e evitando ao máximo
falhas provenientes de uma conexão instável, já que após o envio da requisição de
empréstimo não há a necessidade de conexão contínua com o cliente. No entanto, não
há o tratamento do caso em que o item que se deseja reservar não esteja disponível, e
muito menos uma maneira inteligente de lidar com isto para uma melhor interação com
o usuário.
Outro problema, que é inerente da utilização de agentes em dispositivos
heterogêneos, é a necessidade de instalação de uma plataforma de agentes, como a
plataforma JADE. Existem alguns obstáculos quanto a esta questão, como a
compatibilidade, a segurança da plataforma e a dificuldade de instalação e configuração.
Quanto à compatibilidade, uma possível solução é utilizar uma plataforma de
agentes implementada em Java. Desse modo, basta que haja uma máquina virtual Java
sendo executada embaixo da plataforma de agentes. A plataforma JADE atende muito
bem a estes requisitos, já que é totalmente implementada em Java.
A instalação e configuração são pontos mais críticos, pois a dificuldade em
realizá-las pode fazer com que o usuário desista de utilizar os recursos do sistema.
Portanto, a melhor solução é que seja disponibilizado aos usuários um pacote de
instalação que seja fácil de executar e que realize as configurações necessárias sem a
intervenção do usuário. Além disso, dentre as configurações é conveniente que a
plataforma aceite apenas agentes certificados pelo sistema, para manter o dispositivo do
usuário livre de ataques de agentes maliciosos.

Cenário 2:

30
 Da mesma maneira que no cenário 1, um agente Ag1 é disparado ao dispositivo
do usuário. O usuário encontra o item que procura através da interface oferecida pelo
agente e submete a solicitação. O agente então verifica se o item pedido encontra-se
disponível para empréstimo/reserva. Caso positivo, Ag1 salta para o servidor de banco
de dados e realiza as operações necessárias.
Caso seja percebido que aquele item não esteja disponível no momento, o agente
informa este fato ao usuário e retorna ao servidor central, levando consigo o fato de que
o usuário atendido solicitou um item que se encontra indisponível. Estacionado no
servidor central, o agente adiciona esta informação à base de conhecimento ou contacta
o agente responsável por isto. Dessa maneira, tal fato passa a fazer parte do contexto
atual do sistema, e Ag1 pode ser destruído ou usado para outro atendimento.
Em paralelo a esse processo, existem outros agentes encarregados de dar suporte
a outras operações que ocorrem na biblioteca. Um ou mais agentes sensores, por
exemplo, monitoram as devoluções e demais incrementos de estoque de itens.
Chamaremos um desses agentes de Ag2. A cada novo registro de disponibilidade que
Ag2 detecta, Ag2 envia à central o fato de que um novo item acabou de chegar. Isto
pode ser feito tanto via mensagem quanto através de um agente móvel mensageiro. No
servidor central, o novo fato é adicionado ao contexto atual através de um agente
encarregado desta tarefa.
Dessa forma, em determinado momento o item anteriormente detectado como
indisponível por Ag1 é acrescentado à coleção e torna-se disponível. Ag2, então, trata
de realizar sua tarefa de informar tal fato à central. Na central, onde se localiza a base de
conhecimento que define o contexto, um agente Ag3 raciocina sobre o contexto,
buscando tomar as melhores decisões possíveis. Com a adição do fato recém-chegado
de Ag2, Ag3 percebe que o item solicitado pelo cliente de Ag1 agora se encontra
disponível. Através de seu mecanismo de raciocínio, Ag3 pede a um agente Ag4 que
verifique se o usuário mencionado ainda se encontra nos estabelecimentos da biblioteca.
Ag4 realiza sua busca e adiciona o novo fato à base de conhecimento. Se o fato
detectado indicar que o usuário ainda se encontra na biblioteca, Ag3 pode tomar a
decisão de enviar um agente Ag5 para o dispositivo do usuário. Ag5 irá estacionar no
dispositivo que o usuário estiver usando, irá lhe avisar que o item antes solicitado agora
se encontra disponível, e irá lhe oferecer uma interface para confirmação da reserva do
item. Caso a reserva seja confirmada, Ag5 realizará a mesma ação que Ag1, migrando

31
para o servidor de banco de dados e realizando as operações necessárias para a
efetivação da reserva. Em seguida, Ag5 retorna uma mensagem de sucesso ao usuário.
Ainda, se a solicitação de reserva tiver sido feita para o mesmo dia, Ag5 (ou
Ag1, caso o item tenha sido encontrado inicialmente disponível) avisará que o item se
encontrará em breve no balcão da bibliotecária, e solicitará a entrega na central, de
maneira similar ao que é feito no cenário 1.

Discussão:
O cenário 2 apresenta uma evolução do cenário 1 pois, além de tratar do caso em
que o item procurado encontra-se indisponível, ainda adiciona tal fato ao contexto,
possibilitando que decisões inteligentes sejam tomadas, como a de avisar ao usuário
sobre a chegada do item desejado. Além disso, os agentes interagem entre si e agem de
acordo com o contexto, retratando bem as vantagens e aplicações de sistemas
multiagente inseridos em um sistema sensível ao contexto.
O cenário 1 foi implementado utilizando-se o framework JADE para fins
experimentais. Também foram feitos testes com os recursos de clonagem de agentes. Os
experimentos mostram que construir agentes móveis é viável para aplicações
distribuídas, e a elaboração e estudo do cenário 2 mostra como agentes de software
podem representar papéis crucias em sistemas sensíveis ao contexto.

32
Resultados Obtidos

Os estudos realizados mostraram que, apesar de ser uma área recente, a

mobilidade é um assunto interessante e importante para a construção de aplicações
distribuídas e inteligentes, como sistemas pervasivos e sistemas de desenvolvimento
distribuído de software, uma vez que trata de mecanismos para compartilhar
informações e operações entre os diversos pontos da rede do sistema.
A utilização de agentes móveis em sistemas distribuídos sensíveis ao contexto é
muito promissora, pois uma vez que existem pessoas e máquinas interagindo por meio
da rede, é possível que o conhecimento seja formado a partir do processamento de
informações de contexto capturadas por agentes móveis que, se locomovendo pelos
diversos nós da rede, podem coletar estas informações e tomar decisões a partir do
contexto. Isto permite ao sistema o processamento das informações de contexto não
apenas de forma local, mas de forma a abranger o sistema como um todo.
Para tanto, as diferentes formas de se realizar a mobilidade dos agentes de
software proporcionam alternativas para solucionar os problemas. Considerando a
migração e a clonagem, por exemplo, é possível utilizar essas duas alternativas para
resolver diferentes tarefas do sistema. Se uma tarefa iniciada não precisa ser executada
em algum local específico, a transferência da execução desta tarefa para um nó mais
ocioso da rede é interessante. Por outro lado, caso exista uma tarefa que necessite ser
executada em vários locais da rede, a clonagem de agentes pode resolver esse problema.
Ainda, pode-se adaptar sistemas que utilizam paradigmas tradicionais, como o
cliente/servidor, para que integrem sistemas de agentes móveis, o que pode melhorar
consideravelmente o desempenho de determinadas operações, além de possibilitar uma
recuperação mais eficiente quando há falhas de conexão durante o processamento.

4. Conclusões
Na construção de aplicações voltadas para o desenvolvimento distribuído de
software, é imprescindível que haja suporte à colaboração entre os indivíduos que
interagem por meio do ambiente. Para isso, é importante que informações referentes
diretamente e indiretamente às atividades sendo desenvolvidas em cada local sejam
coletadas e processadas, para que possam auxiliar a aplicação a tratar os eventos que
ocorrem internamente a ela.

33
 Para tanto, a utilização de agentes de software móveis pode oferecer uma
solução para o problema, uma vez que podem usufruir tanto de características comuns
de agentes, como reatividade e pró-atividade, para realizar tarefas relacionadas ao
tratamento de contexto, como podem se utilizar da sua mobilidade para visitar
diferentes nós da rede para buscar em outros locais novas informações que sejam
relevantes para o cumprimento de seus objetivos.
Para que exista essa mobilidade, é necessário que haja mecanismos que abordem
como o código a ser executado será transferido de um local para outro, e como os dados
utilizados durante a execução do código e o estado da execução no momento anterior à
migração serão salvos e transmitidos. Além disso, devem ser especificados o papel e o
conhecimento do agente em relação ao sistema, incluindo a interação com outros
agentes e a execução de ações que visam a cumprir seu trabalho no ambiente
distribuído.
Outro ponto importante a ser considerado se refere às vantagens e riscos da
utilização de agentes móveis. Tais agente são extremamente eficientes em sistemas
distribuídos cujos nós estejam conectados a uma rede inalâmbrica, pois não requerem
conexão contínua entre cliente e servidor, além de se portarem muito bem durante falhas
de conexão, devido a suas capacidades de reagirem a situações desfavoráveis. Porém,
um sistema multiagente com agentes móveis deve ser cuidadosamente projetado, pois
agentes móveis são alvos fáceis de agentes maliciosos, o que compromete a segurança
do sistema.
Agentes de software, móveis ou não, são naturalmente interativos (Perini et al,
2002), e para tanto devem poder comunicar-se entre si. Com a mobilidade dos agentes,
podem ocorrer momentos em que agentes heterogêneos entre si necessitem trocar
informações. Para tanto, é importante que as especificações da FIPA sejam observadas,
de forma a manter padrões durante o desenvolvimento de agentes, independentemente
de sua implementação. A plataforma JADE é baseada nas especificações da FIPA, e
possui implementado um serviço que oferece suporte tanto à migração quanto à
clonagem de agentes móveis entre diferentes pontos da rede na qual se encontram
recipientes da plataforma, além de diversos serviços, como os que dão suporte à
comunicação entre agentes e ao ciclo de vida dos agentes.

34
Bibliografia

Bellifemine, F., Caire G., Greenwod, D. P. A. Developing multi-agents systems

with JADE. West Sussex: John Wiley & Sons, 2007.
Braun, P., Rossak, W. Mobile Agents: Basic Concepts, Mobility Models, & The
Tracy Toolkit. Morgan Kaufmann Publishers and dpunkt.verlag, 2005.
Carzaniga, A., Picco, G., Vigna, G. Designing distributed applications with
a mobile code paradigm. 19th International Conference on Software Engineering.
Proceedings... Boston, may 1997.
Chess, D.; Harrison, C.; Kershenbaum, A. Mobile agents: are they a good
idea? Mobile Object Systems. Second Internationa Workshop, MOS’96.
Proceedings... Linz, Austria, july 1996. Lecture Notes.
Coulouris, G.; Dollimore, J.; Kindberg, T. “Distributed Systems: Concepts and
Designs”. Addison-Wesley, 3ª Edição, 2001.
Danny B. Lange and Mitsuru Oshima. Seven Good Reasons for Mobile Agents.
COMMUNICATIONS OF THE ACM, March 1999/Vol. 42, No. 3, pg. 88/89.
Dey, A. K., Aboud, G. D., 2000, "Towards a Better Understanding of Context
and Context- Awareness". In Proceedings of the CHI 2000 Workshop on The What,
Who, Where, When, and How of Context-Awareness, The Hague, Netherlands.
Dourish, P. and Belloti, V. Awareness and Coordination in Shared Workspaces.
In Proceedings of the ACM Conference on Computer-Supported Cooperative Work
CSCW'92, Toronto, Ontario, ACM Press, New York, pp.107-114. 1992.
FIPA Web Site, disponível em “http://www.fipa.org.br”, 2009.
Fuggetta, A.; Picco, G. P.; Vigna, G. Understanding Code Mobily. IEEE
Transactions on Software Engineering. Vol.24, num. 5, May 1998.
Glass, Graham. ObjectSpace Voyager - The Agente ORB for Java. Worldwide
Computing and its Applications (WWCA’98). Second International Conference.
Proceedings... Tsukuba, Japan, march, 1998.
Huzita, E. H. M. “Suporte à Percepção e ao Contexto em Ambientes de
Desenvolvimento Distribuído de Software”. Projeto de pesquisa em andamento,
Universidade Estadual de Maringá. Departamento de Informática, 2008.
IEEE, and ISO/IEC. Systems and Software Engineering - Recommended
Practice for Architectural Description of Software-Intensive Systems. Julho, 2007.
ISO/IEC 42010 IEEE Std 1471-2000 First edition, c1–24.

35
 IIOP OMG Internet Inter-ORB Protocol Specification, Common Object Request
Broker Architecture 2.2. ObjectManagement Group, 1999.
JADE Web Site, disponível em “http://jade.tilab.com/”, 2009.
Jansen, W., Karygiannis, T. Nist special publication 800-19 - Mobile Agent
Security, National Institute of Standards and Technology, 2000.
Oliveira, H. M. de. “Técnicas para Projeto e Implementação de Agentes de
Software”. Trabalho de Graduação – Curso de Ciência da Computação – Departamento
de Informática – Universidade Estadual de Maringá – UEM – Maringá, 2000.
Perini, A., Susi, A., Giunchiglia, F. Designing Coordination Among Human and
Software Agents. Reporte Técnico. Universidade de Trento, Trento, Itália, 2002.
Puliato, A., Riccobene, S., Scarpa, M.. An analytical comparison of the client-
server, remote evaluation and mobile agents paradigms. In Proceedings of the Third
International Symposium on Mobile Agents, página 278. IEEE Computer Society,
1999.
Shehory, O., Sycara, K., Chalasani, P., Jha, S. Agent cloning: an approach to
agent mobility and resource allocation. IEEE Communications Magazine, 36(7):58–67,
1998.
Spyrou, C., Samaras, G., Pitoura, E., Evripidou, P. Mobile agents for wireless
computing: the convergence of wireless computational models with mobile-agent
technologies. Mobile Networks and Applications , 9(5):517#528, 2004.
Tanenbaum, A.S. and Van Steen, M. Distributed Systems: Principles and
Paradigms. Prentice Hall PTR, Upper Saddle River, NJ, 2001.
Titkov, L. Agent-Based Framework to Support Location-Aware Services and
Manage Privacy for Nomadic Users. PhD Thesis. 2005. WQueen Mary College
University of London of Eletronic Engineering. 2005.
Vieira, V. A domain-independent framework for designing context-sensitive
systems. Tese de Doutoramento, CIn Universidade Federal de Pernambuco, Recife,
Pernambuco, 2008.
Vieira V., Souza D., Salgado, A. C., Tedesco, P., Uso e Representação de
Contexto em Sistemas Computacionais. In: Cesar A. C. Teixeira; Clever Ricardo G. de
Farias; Jair C. Leite; Raquel O. Prates. (Org.). Tópicos em Sistemas Interativos e
Colaborativos. São Carlos: UFSCAR, 2006, p. 127-166.
Wooldridge, M., Jennings, N. R. Intelligent Agents: Theory and Practice. Texto
submetido para Knowledge Engineering Review, Reino Unido, 1995.

36
 Zaslavsky, A. Mobile Agents: Can They Assist with Context Awareness?.
Proceedings of the 2004 IEEE International Conference on Mobile Data Management
(MDM’04). 2004.

37