ARQUITETURA DE SISTEMAS DISTRIBUIDOS (22)

Prévia do material em texto

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
INSTITUTO DE INFORMÁTICA
CURSO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
Um Estudo sobre Mobilidade
em Sistemas Distribuídos
por
DÉBORA NICE FERRARI
T.I. 780 CPGCC-UFRGS
Trabalho Individual II
Prof. Dr. Cláudio Fernando Resin Geyer
Orientador
Porto Alegre, fevereiro de 1999
2
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
Reitora: Profa. Wrana Panizzi
Pró-Reitora de Pós-graduação: Profa. Lorena Holzmann da Silva
Diretor do instituto de Informática: Philipe Oliver Navaux
Coordenador do CPGCC: Carla Freitas
Bibliotecária-Chefe do Instituto de Informática: Zita Prates de Oliveira
3
 Sumário
SUMÁRIO................................................................ ................................ ................................ ................... 3
LISTA DE FIGURAS................................................................ ................................ ................................ .4
LISTA DE TABELAS ................................................................ ................................ ................................ 5
RESUMO ................................................................ ................................ ................................ .................... 6
ABSTRACT ................................................................ ................................ ................................ ................ 6
1 INTRODUÇÃO................................................................ ................................ ................................ .7
1.1 TEMA ................................................................ ................................ ................................ .............. 7
1.2 MOTIVAÇÃO................................................................ ................................ ................................ ....7
1.3 OBJETIVOS ................................................................ ................................ ................................ ...... 9
1.4 ESTRUTURA DO TEXTO ................................................................ ................................ ................... 9
2 MOBILIDADE................................................................ ................................ ................................ 10
2.1 CONCEITOS ................................................................ ................................ ................................ ...10
2.2 MECANISMOS ................................................................ ................................ ................................ 11
2.3 PARADIGMAS PARA MOBILIDADE................................................................ ................................ ...14
2.3.1 Avaliação Remota................................................................ ................................ ......................... 15
2.3.2 Código em Demanda ................................................................ ................................ .................... 15
2.3.3 Agentes Móveis................................................................ ................................ ............................. 16
2.4 CONCLUSÕES ................................................................ ................................ ................................ 16
3 MOBILIDADE EM OBJETOS E AGENTES................................................................ .............. 17
3.1 PARADIGMA ORIENTADO À OBJETOS ................................................................ ............................ 17
3.2 PARADIGMA ORIENTADO A AGENTES................................................................ ............................ 18
3.3 AGENTES MÓVEIS ................................................................ ................................ ......................... 20
3.4 CONCLUSÕES ................................................................ ................................ ................................ 23
4 TECNOLOGIAS PARA SUPORTE À MOBILIDADE .............................................................. 24
4.1 FERRAMENTAS PARA SUPORTE À MOBILIDADE ................................................................ .............. 24
4.1.1 Java ................................................................ ................................ ................................ .............. 24
4.1.2 Obliq................................................................ ................................ ................................ ............. 25
4.1.3 Oz Distribuído ................................................................ ................................ .............................. 26
4.1.4 CORBA ................................................................ ................................ ................................ ......... 27
4.2 AMBIENTES QUE PERMITEM EXPLORAR MOBILIDADE ................................................................ ....30
4.2.1 Voyager ................................................................ ................................ ................................ ........ 30
4.2.2 Aglets ................................................................ ................................ ................................ ............ 33
4.2.3 Concordia................................................................ ................................ ................................ .....35
4.3 APLICAÇÕES................................................................ ................................ ................................ ..37
4.4 CONCLUSÕES ................................................................ ................................ ................................ 38
5 ANÁLISE COMPARATIVA DAS TECNOLOGIAS QUE SUPORTAM MOBILIDADE .....40
5.1 ANÁLISE COMPARATIVA DAS FERRAMENTAS................................................................ ................. 40
5.2 CONCLUSÕES ................................................................ ................................ ................................ 44
6 CONCLUSÃO ................................................................ ................................ ................................ .45
BIBLIOGRAFIA ................................................................ ................................ ................................ ...... 47
4
Lista de Figuras
FIGURA 2.1 - Mecanismos de Mobilidade 13
FIGURA 4.1 - Arquitetura de Gerenciamento de Objetos (OMA) 29
FIGURA 4.2 - Objeto Voyager 32
FIGURA 4.3 - Criação de um programa Voyager 32
FIGURA 4.5 - Arquitetura do Concordia 35
5
Lista de Tabelas
TABELA 1 - Ferramentas para suporte à mobilidade 42
TABELA 2 - Ambientes para explorar mobilidade 44
6
Resumo
O número de aplicações distribuídas criadas para serem usadas na Internet aumentou
consideravelmente nos últimos anos. Uma das mais complexas questões nestas
aplicações diz respeito à mobilidade das entidades envolvidas na computação
distribuída. Neste texto define-se mobilidade como a capacidade das entidades
computacional deslocar-se de um ambiente para outro, através do sistema distribuído.
Os estudos sobre mobilidade intensificaram-se com o uso em grande escala da Internet.
Atualmente, a maioria das aplicações de mobilidade são desenvolvidas utilizando ou
baseando-se nos paradigmas de orientação a objetos ou de agentes. Pode-se observar
que estes dois paradigmas, estão cada vez mais presentes no desenvolvimento de
aplicações para Internet.
Considerando os aspectos acima mencionados e o interesse crescente da comunidade
científica com relação à mobilidade, este trabalho procura estudar aspectos referente à
mobilidade em sistemas distribuídos envolvendo agentes e objetos. Neste texto são
abordados assuntos importantes como os fundamentos que envolvem os estudos em
mobilidade,resultados dos estudos envolvendo mobilidade em objetos e agentes,
tecnologias e aplicações para suporte à mobilidade. Apresenta-se também uma análise
comparativa referente à mobilidade dos sistemas distribuídos apresentados neste
trabalho.
Palavras-chave: Orientação a Objetos, Agentes Móveis, Mobilidade, Sistemas
Distribuídos.
Abstract
 In the last few years, the number of Internet-based distributed applications increased
meaningfully. One of the most complex issues involving these applications are related
to entity mobility. This text defines mobility as the capacity of an computational entity
to relocate itself from an environment to another one, through the distributed system.
Research on mobility had been intensified with the Internet large-scale use. Currently,
the majority of mobility applications is developed using or being based on
object oriented or agents paradigms. Note that these two paradigms are even more
present in the development of applications for Internet.
Considering the aspects mentioned above and the scientific community increasing
interest with relation to mobility, in this work are presented mobility aspects in
distributed systems involving agents and objects. These aspects include: the
fundamental concepts of mobility research, results of studies involving mobility in
objects and agents, technologies and applications for mobility support. An comparative
analysis related to mobility in distributed systems is also presented in this work.
Keyword: Objects, Mobile Agents, Mobility, Distributed Systems.
7
1 Introdução
1.1
 
Tema
O paradigma orientado a objetos e o paradigma de agentes são interesses constantes da
comunidade científica, principalmente em ambientes distribuídos. Sendo assim,
surgiram modelos para computação distribuída de objetos e agentes. Uma das mais
complicadas questões envolvendo ambientes distribuídos com estas características diz
respeito à mobilidade nesses dois paradigmas. O texto [GLA 98] define mobilidade
como a habilidade de mover-se independentemente de um dispositivo para outro através
da rede. Como é visto no capítulo 2, vários conceitos sobre mobilidade são encontrados
na literatura. O tema deste trabalho é o estudo da mobilidade em sistemas distribuídos,
principalmente envolvendo objetos e agentes.
1.2
 
Motivação
A rápida disseminação de microcomputadores e estações de trabalho, o aumento nas
suas capacidades de processamento, e o surgimento de redes de comunicação com
grande largura de banda, têm levado ao desenvolvimento cada vez maior de aplicações
distribuídas. Os sistemas distribuídos apresentam várias características que são objetos
de constante pesquisa na busca de soluções, tais como: afastamento, concorrência,
ausência de estado global, ocorrência de falhas parciais, assincronismo,
heterogeneidade, autonomia e mobilidade.
Diversos modelos de arquitetura distribuída têm sido desenvolvidos com o objetivo de
oferecer conceitos que auxiliem o tratamento das características de distribuição citadas
acima. A característica de heterogeneidade, presente em grande parte destes modelos,
impõe a necessidade de especificações abertas, com interfaces padronizadas e públicas,
levando ao desenvolvimento de middlewares abertos.
Um middleware é uma camada de software, residente acima do sistema operacional e da
camada de comunicação, que oferece abstrações de alto nível, com objetivo de facilitar a
programação distribuída. As abstrações oferecidas fornecem uma visão uniforme na
utilização de recursos heterogêneos existentes nas camadas de sistema operacional e
redes[OMG 95].
Ambientes de sistemas abertos permitem aos usuários escolherem entre um grupo de
computadores e tecnologias, aqueles que se adequam a suas necessidades. Esses
sistemas oferecem também uma crescente interoperabilidade, escalabilidade e
portabilidade. A interoperabilidade permite que sistemas diferentes convivam juntos. Já
a portabilidade permite que um software desenvolvido em uma plataforma possa
executar em outra com adaptações mínimas. A escalabilidade permite que novos
recursos, tanto hardware quanto software, sejam adicionados ao sistema a medida que
há necessidade de novos recursos ou de aumento do poder de processamento.
Juntamente com estes adventos quanto aos sistemas distribuídos, surgiram várias frentes
de pesquisas para que as organizações pudessem explorar ao máximo os sistemas
8
distribuídos. Dentre estas linhas de pesquisa, este texto destaca à mobilidade em
sistemas distribuídos como sendo a principal motivação para este trabalho. O estudo
sobre mobilidade abrange tanto aspectos conceituais, quanto sistemas e linguagens.
A orientação a objetos tornou-se um dos principais padrões no desenvolvimento de
sistemas. As linguagens orientadas a objeto tentam propor a diminuição da distância
semântica existente entre a modelagem computacional e o mundo real. Neste sentido,
surgem os objetos e suas diversas características (herança, polimorfismo,
encapsulamento, etc). Desta forma, a orientação a objetos tenta alcançar um nível de
abstração que aproxima a programação de computadores à forma usual do homem
interagir com o mundo.
Da mesma forma, nos últimos anos vem crescendo o interesse dos cientistas da
computação pelo paradigma orientado a agentes. O desenvolvimento orientado a agentes
possui uma forte relação com o desenvolvimento orientado a objetos. O conceito de
agentes introduz consciência no universo inanimado dos objetos. Esta é uma das
contribuições do paradigma orientado a agentes [BAR 98].
Tanto objetos como agentes são amplamente usados pela comunidade científica em
ambientes distribuídos. Sendo assim, surgiram modelos para computação distribuída de
objetos e agentes. Um dos fatores principais nestes ambientes diz respeito à mobilidade
destas entidades.
Os estudos sobre mobilidade intensificaram-se com o uso em grande escala da Internet.
Embora à mobilidade não seja uma concepção nova, pois redes locais já usam uma
formas de mobilidade como migração, a Internet trouxe a possibilidade de explorar
mobilidade através de redes heterogêneas, conectadas por diferentes links de
comunicação e distantes uma das outras.
Atualmente, a maioria das aplicações são desenvolvidas utilizando ou baseando-se na
orientação a objetos. Da mesma forma, várias aplicações, principalmente na área de
Informática na Educação e Inteligência Artificial, são desenvolvidas usando como
entidade base o agente. O que pode-se observar é que estas duas entidades, objetos e
agentes, estão cada vez mais presentes no desenvolvimento de aplicações para serem
usadas na Internet. Talvez o que tenha auxiliado muito para que isto acontecesse é o uso
cada vez maior da linguagem Java [SUN 96], como linguagem de programação destas
aplicações.
É importante observar que a exploração da mobilidade envolve muito a questão da
localização. Uma premissa básica é que o usuário não necessita saber, se assim o
quiser, onde a sua computação está sendo desenvolvida, pois a aplicação deve abstrair
aspectos de localização do usuário. Outra questão importante em mobilidade é a
segurança. Como a computação é distribuída através da rede, a integridade desta
computação deve ser preservada. No desenvolvimento de aplicações que suportem
mobilidade, a tolerância a falhas e segurança da computação deve sempre estar presente.
Além destes aspectos, à mobilidade traz novos desafios ao desenvolvimento de
aplicações distribuídas, como pensar à mobilidade durante o projeto de software. Para
suportar mobilidade de forma transparente para o usuário, a noção de ambiente
computacional deve estar presente. Este ambiente será elemento principal no suporte à
mobilidade das entidades envolvidas.
9
Considerando os aspectos acima mencionados e o interesse crescente da comunidade
científica com relação à mobilidade em ambientes distribuídos, este trabalho procura
compreendero estado da arte e os problemas relacionados à mobilidade em sistemas
distribuídos.
1.3 Objetivos
O objetivo geral deste trabalho consiste em estudar os aspectos relacionados à
mobilidade de objetos e agentes em ambientes distribuídos.
Como objetivos específicos podem ser destacados:
• Pesquisar conceitos relacionados à mobilidade;
• Pesquisar o estado da arte relacionado à mobilidade em sistemas distribuídos,
em especial envolvendo objetos e agentes;
• Estudar tecnologias para o desenvolvimento de aplicações que suportem
mobilidade;
• Identificar características necessárias para que uma tecnologia de apoio ao
desenvolvimento de aplicações que suportem mobilidade.
1.4 Estrutura do Texto
Este texto é composto de seis capítulos. O capítulo 2 descreve os fundamentos que
envolvem os estudos em mobilidade. O capítulo 3 apresenta o resultado dos estudos
envolvendo mobilidade em sistemas distribuídos. Além disso, será apresentado,
brevemente, os fundamentos dos paradigmas orientado a agentes e orientado a objetos.
No capítulo 4 são apresentadas algumas tecnologias e aplicações para suporte à
mobilidade. Merece destaque neste capítulo Voyager [OBJ 97] [OBJ 98]. No capítulo 5
é feita uma comparação referente à mobilidade em sistemas distribuídos apresentadas
neste trabalho. Finalmente, o capítulo 6 contém as conclusões deste trabalho.
10
2 Mobilidade
Este capítulo descreve os fundamentos que envolvem os estudos de mobilidade. As
seções contêm os conceitos necessários para compreender o universo que envolve as
aplicações que utilizam mobilidade. A seção 2.1 analisa conceitos relacionados à
mobilidade conforme vários autores. A seção 2.2 descreve os mecanismos que permitem
explorar mobilidade. A seção 2.3 explora aspectos relacionados aos paradigmas que
exploram mobilidade. Finalmente, a Seção 2.4 faz uma síntese das demais seções
concluindo o capítulo.
2.1
 
Conceitos
Por ser uma área de pesquisa relativamente nova, as pesquisas que envolvem
mobilidade conceituam este termo de várias formas. A maioria refere-se à mobilidade
através do termos código móvel (mobile code) [FUG 98] [CAR 97] [THO 97] [CUG
96] e agentes móveis (mobile agent) [DÖM 97] [CHE 96] [KNA 96] . Estes termos são
conceituados de diferentes formas por diferentes pesquisadores:
• Mobilidade é a habilidade de mover-se independentemente de um dispositivo para
outro através da rede [GLA 98];
• Código móvel pode ser definido como a capacidade de dinamicamente trocar as
ligações entre os fragmentos de código e a localização onde o código é executado
[CUG 98] [FUG 98] [CAR 97];
• Código móvel é um software que viaja através de redes heterogêneas, atravessando
vários domínios, sendo que é automaticamente executado quando chega em seu
destino [THO 97];
• Agentes móveis são programas que podem ser disparados de um computador cliente
e transportado para um computador remoto para ser executado [CHE 96];
• Agentes móveis são programas que podem se mover através de uma rede de
computadores conforme queiram seus usuários [DÖM 96];
• Agentes móveis são programas “inteligentes” que podem ser transmitidos entre os
diversos computadores de um sistema distribuído [KNA 96].
Observando os itens acima, pode-se notar um elemento presente em todos os conceitos:
o deslocamento das entidades envolvidas (objetos ou agentes). Sendo assim, pode-se
dizer que mobilidade é a ca pacidade das entidades envolvidas na computação
deslocarem-se através de um sistema distribuído.
Mobilidade não é uma concepção nova, embora sua aplicação na Internet seja. Um
exemplo é a migração, pois migrar processos ou objetos é uma forma de mobilidade,
que já é usada em pequena escala. As pesquisas em mobilidade vem crescendo muito
atualmente devido principalmente a possibilidade de explorar código móvel em grande
escala através da Internet, onde as redes interligadas são heterogêneas e gerenciadas por
organizações diferentes.
11
2.2 Mecanismos
Tecnologias que exploram mobilidade devem prover mecanismos que suportem o
deslocamento de suas entidades. Estes mecanismos necessitam de uma estrutura
computacional que suporte à mobilidade. Sendo assim, a concepção de um ambiente
computacional (Computational Environment) deve ser introduzida para suportar os
diversos mecanismos necessários à mobilidade. Um ambiente computacional retêm a
identidade do nodo onde está localizado dando suporte para que as aplicações tenham a
capacidade de recolocar dinamicamente seus componentes em diferentes ambientes
computacionais. Um exemplo de ambiente computacional é a máquina virtual Java
(Java Virtual Machine).
O texto [FUG 98] trata mobilidade através do termo código móvel. O texto também
destaca que um ambiente computacional é uma espécie de “container” para as entidades
envolvidas na computação, chamadas componentes. Estes podem ser unidades de
execução ou recursos. Unidade de execução representa a entidade básica da linguagem,
um objeto por exemplo, através de um fluxo seqüencial da computação. Uma unidade
de execução é composta pelo segmento de código, que contém a descrição estática do
comportamento da computação, e um estado. Recursos representam entidades que
podem ser compartilhadas por múltiplas unidades de execução, como uma variável do
sistema operacional por exemplo.
A princípio, cada unidade de execução pode mover-se independentemente. Em alguns
sistemas que exploram código móvel, o código e o estado da unidade de execução
podem estar em diferentes ambientes computacionais. À mobilidade é determinada pela
característica do sistema. Por exemplo, em Java é possível mover somente o código de
um Applet [SUN 96]. Já em Java Aglet [LAN 97], tanto o código quanto o estado são
movidos.
Podem ser identificadas duas formas de mobilidade [FUG 98]: mobilidade forte e
mobilidade fraca.
Mobilidade forte permite que a unidade de execução possa mover seu código e o estado
da computação para diferentes ambientes computacionais. Neste caso, a execução é
suspensa, transmitida para o ambiente computacional destino, e sua execução é
retomada. Mobilidade fraca permite transferir código de um ambiente computacional
para outro. O código pode conter alguns dados inicializados, mas o estado da unidade de
execução não é movido. A figura 2.1 apresenta uma classificação dos mecanismos de
mobilidade [FUG 98].
12
Mobility
mechanisms
Code and
execution state
management
Strong
mobility
Weake
mobility
Migration
Remote
Cloning
Proactive
Reactive
Proactive
Reactive
Code
shipping
Stand-alone
code
Synchronous
Asynchronous
Imediate
Deferred
Code
fragment
Synchronous
Asynchronous
Imediate
Deferred
Stand-alone
code
Synchronous
Asynchronous
Imediate
Deferred
Code
fragment
Synchronous
Asynchronous
Imediate
Deferred
Code
fetching
Data space
management
Binding removal
Network reference
Re-binding
By copy
By Move
FIGURA 2.1 - Mecanismos de Mobilidade
Mobilidade forte pode ser explorada através de dois mecanismos: migração (migration)
e clone remoto (remote cloning). O mecanismo de migração suspende a execução de
uma unidade de execução, transmite para o ambiente computacional destino e retoma
sua execução. A migração pode ser proativa (proactive) ou reativa (reactive). Na
primeira, o tempo e o destino da migração são determinadas pela unidade de execução
migrante. Na segunda, a migração é acionada por diferentes unidades de execução que
tenham alguma espécie de ligação com a unidade de execução migrante. O mecanismo
de clone remoto cria uma cópia da unidade de execução no ambiente computacional
remoto. A unidade de execução não é isolada do ambiente computacional origem. Como
na migração, o clone remoto pode ser proativo ou reativo.
Mecanismos que suportam mobilidade fraca têm a capacidade de transferir código
através de ambientes computacionais e ligar-sedinamicamente 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 acordo com a direção da
transferência do código, a natureza do código movido, a sincronização envolvida e o
momento em que o código é executado no ambiente remoto.
Conforme a direção do código a ser transferido, uma unidade de execução pode trazer
(fetching) o código para ser dinamicamente ligado e/ou executado, ou pode levar
(shipping) o código para outro ambiente computacional. Nos dois casos, o código a ser
transferido pode ser um código autônomo (stand-alone code) ou fragmentado (code
13
fragment). No primeiro caso, no ambiente computacional destino é criada uma unidade
de execução para executar o código que chega. No segundo caso, a unidade de execução
deve ligar-se com um contexto que esteja executando o código ou que eventualmente o
tenha executado. Além disso, tanto no código autônomo como no fragmentado, estes
mecanismos podem ser síncronos (synchronous) ou assíncronos (asynchronous),
dependendo se a unidade de execução que solicita a transferência fica 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 (imediate), isto é, o código é executado logo que recebido ou
postergada (deferred), isto é, espera alguma condição ser satisfeita para iniciar a
execução.
Após a migração de uma unidade de execução para um novo ambiente computacional,
sua ligação com os recursos que acessa deve ser reorganizada. Por exemplo, a unidade
de execução pode necessitar acessar um arquivo, portanto, ela deve estar apta a acessar
este arquivo mesmo que este esteja em outro local. Isto pode envolver novas ligações ou
sempre migrar alguns recursos necessários a computação junto com a unidade de
execução, dependendo da natureza do recurso e da aplicação. Por isto é necessário o
gerenciamento do espaço de dados.
Os recursos podem ser transferíveis ou não-transferíveis através da rede. Por exemplo,
um recurso do tipo arquivo pode ser transferível mas um recurso do tipo impressora não.
Recursos transferíveis podem ser marcados como livres ou fixos. O primeiro pode
migrar para outro ambiente computacional, enquanto que o último deve sempre
permanecer associado ao ambiente computacional.
Na reorganização dos recursos, duas classes de problemas devem ser analisados quando
uma unidade de execução desloca-se através da rede: realocação de recursos e
reconfiguração das ligações. Para isto deve ter um gerenciamento do espaço de dados
(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. Os mecanismos mais
usados são:
• remoção das ligações (binding removal) - quando a unidade de execução migra, as
ligações são simplesmente descartadas. Pode-se observar que esta estratégia
geralmente é usada quando há migração da entidade envolvida na computação,
portanto, num tipo de mobilidade forte;
• referência na rede (network reference)- quando um recurso é não transferível, 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. Referência na rede geralmente é usada
quando à mobilidade forte é explorada, através do clone remoto;
• re-ligação (re-binding) - no ambiente computacional remoto há um recurso do
mesmo tipo que é referenciado na unidade de execução que chega. Sendo assim, a
ligação com o recurso no ambiente computacional fonte é desfeita, e uma nova
ligação apontando para o recurso no ambiente computacional destino é criada. Esta
estratégia é usada quando à mobilidade fraca é explorada, na forma de levar ou trazer
código fragmentado;
14
• por cópia (by copy)- uma copia do recurso é criada, e a ligação é modificada para
referenciar a cópia e esta é transferida junto com a unidade de execução para o
ambiente computacional destino. Pode-se observar que o mecanismo por cópia é
associado ao clone remoto, portanto explorando uma mobilidade forte;
• por movimento (by move)- o recurso é transferido junto com a unidade de execução
para o ambiente computacional destino mas a ligação com o ambiente computacional
fonte não é desfeita. Esta estratégia é usada em aplicações que exploram mobilidade
fraca.
2.3 Paradigmas para mobilidade
Abordagens tradicionais para projeto de software não são suficientes quando necessita-
se projetar aplicações distribuídas em larga escala que exploram código móvel e
reconfiguração dinâmica dos componentes do software. Neste caso, a distribuição dos
componentes para diferentes ambientes deve ser pensada durante o projeto de software.
Também deve-se considerar os aspectos que diferenciam a interação entre componentes
locais em ambientes remotos. Dentre esses aspectos cita-se uma maior latência de
comunicação, maior tempo para acesso a memória não local, mais pontos de falha e
necessidade de utilização de mecanismos para controle de concorrência e sincronização.
Portanto, é importante identificar paradigmas para projeto de sistemas distribuídos
explorando código móvel. Além disso, deve-se identificar a tecnologia mais adequada
para implementação do paradigma. Os paradigmas apresentados a seguir podem ser
vistos como um guia de referência para o projeto de aplicações distribuídas que
comportam mobilidade. Antes de introduzir os paradigmas, é necessário apresentar
algumas concepções básicas que abstraem as entidades envolvidas no sistema como
arquivos, variáveis, código executável ou processos. As abstrações básicas são as
seguintes [CAR 97]:
• Componentes - são os elementos que compõem a arquitetura. Podem estar dividos
em :
• componente recurso: é o componente embutido na arquitetura que representa
dados passivos ou dispositivos físicos;
• componente computacional: representa o fluxo de controle da computação. É
caracterizado por um estado e ligações com outros componentes;
• Interações - são eventos que envolvem dois ou mais componentes. Por exemplo, uma
mensagem trocada entre dois componentes computacionais pode ser considerada
como uma interação entre eles;
• Sites - são os ambientes de execução. Eles suportam a execução dos componentes
computacionais. Sites tem ligados a si a noção de localização [FUG 98]. Interações
entre componentes no mesmo site são consideradas pouco expressivas se
relacionadas com interações em sites diferentes, pois como os recursos estão locais,
as interações acontecem de forma mais rápida e sem problemas de latência da rede,
acesso aos recursos, tempo de acesso, etc.
15
O paradigma é descrito em termos de padrões de interações que definem a re-colocação
e a coordenação entre componentes necessários para realizar um serviço.
Conforme [FUG 98], são três os principais paradigmas que exploram código móvel:
Avaliação Remota, Código em Demanda e Agentes Móveis. Estes paradigmas são
caracterizados pela localização dos componentes antes e depois da execução dos
serviços, pelo componente computacional que é responsável para execução do código e
onde a computação acontece.
Paradigmas para código móvel tem explicitamente a noção de localização. Assim, é
possível modelar, a nível de projeto, custos para interações entre componentes. Em
geral, conforme [FUG 98], interações entre componentes que compartilham a mesma
localização tem um custo considerado negligenciável quando comparado a interações
entre sites através da rede. A escolha do paradigma a ser explorado deve ser pensado
caso a caso, de acordo com o tipo de aplicação.
2.3.1 Avaliação Remota
De acordo com o paradigma de Avaliação Remota, um componente de um sistema
que suporta mobilidade pode invocar serviços providos por outros componentes, que
estão distribuídos pelos nodos da rede,através do fornecimento dos dados necessários
para desenvolver o serviço bem como o código que descreve como o serviço é feito.
Avaliação Remota pode ser explicada da seguinte forma: um componente A, no site A ,
sabe (conhecimento) como realizar uma determinada tarefa (serviço) mas não tem os
recursos necessários para que ela seja feita. Estes recursos estão localizados em outro
site (site B). Conseqüentemente, A envia o conhecimento de como fazer o serviço para o
componente computacional localizado no site remoto. O componente B realiza o serviço
utilizando os recursos nele contidos. Após a execução, há novamente uma interação
entre os dois componentes para enviar o resultado da computação de volta para A.
Este paradigma é semelhante a abordagem cliente-servidor, onde os serviços são
executados em um servidor que contém os recursos e o conhecimento necessário para
executar uma tarefa. A semelhança pode ser verdadeira se todos os recursos, e a forma
de manipulação destes, estão ligados a um servidor da rede. No paradigma de
Avaliação Remota, o “cliente” sabe como executar uma tarefa, mas o recurso pode
encontrar-se em outro computador da rede. Neste caso, o conhecimento é transmitido
para onde está o recurso, sendo que no computador destino pode existir somente o
recurso em si, mas não o conhecimento necessário para manipulá-lo.
2.3.2 Código em Demanda
Na abordagem de Código em Demanda, o código que descreve o comportamento de
um componente em um sistema que suporta mobilidade pode ser buscado em um site
remoto para ser executado localmente. Exemplificando este paradigma, um componente
A tem acesso aos recursos localizados no Site A mas não tem o conhecimento de como
manipular estes recursos. Portanto, A interage com o componente B no Site B,
requisitando o conhecimento para acessar o recurso. Uma segunda interação acontece
16
quando B envia o conhecimento para A e este realiza a computação (abordagem
contraria a Avaliação Remota).
2.3.3 Agentes Móveis
No paradigma Agentes Móveis, onde os agentes são considerados unidades de execução
[CUG 96], todo o componente computacional é movido para o site remoto, inclusive o
seu estado, o código e alguns recursos necessários para o desenvolvimento da tarefa.
Para exemplificar, um componente A é dono do conhecimento, que esta no Site A, para
realizar alguns serviços. Só que em um determinado momento da execução, ele
necessita de alguns recursos que estão no Site B. Então A migra para o Site B
carregando o conhecimento necessário para executar uma tarefa. Ao mover-se para o
site remoto, A completa o serviço neste site. Este paradigma é diferentes dos outros
paradigmas, pois nestes o foco é a transferência de código entre componentes enquanto
que no paradigma de agentes móveis o código e o estado da computação são movidos
para o site remoto (migração).
2.4 Conclusões
Este Capítulo descreveu os fundamentos que envolvem os estudos em mobilidade,
necessários para compreender o universo que envolve as aplicações que utilizam
mobilidade. Pode-se observar que o conceito de mobilidade não é consenso entre a
comunidade científica que se dedica a estudar o assunto. Vários autores entendem
mobilidade de forma diferenciada, embora sejam unânime em um aspecto: o
deslocamento da entidade envolvida na computação móvel. Desta forma, pode-se dizer
que mobilidade, como o próprio nome diz, pressupõe que a entidade base da
computação possa mover-se de um ambiente computacional para outro.
O texto [FUG 98] apresenta uma estrutura conceitual para compreender código móvel.
O texto tem várias contribuições. Entre elas, um conjunto de termos e conceitos para
compreender e comparar as abordagens baseadas na noção de código móvel, através de
mecanismos e paradigmas que auxiliam o desenvolvimento de aplicações para código
móvel. Além disso, apresenta algumas tecnologias que suportam mobilidade e algumas
aplicações.
A capítulo 3 aborda aspectos de mobilidade em sistemas distribuídos.
17
3 Mobilidade em Objetos e Agentes
A maioria das tecnologias distribuídas que suportam mobilidade são construídas a partir
do paradigma orientado a agente. Como em alguns ambientes um agente é considerado
um objeto especial [OBJ 97] [OBJ 98], os conceitos da orientação a objetos são
amplamente utilizados por tecnologias que suportam mobilidade. Sendo assim, este
Capítulo apresenta aspectos relacionados à mobilidade em sistemas distribuídos,
especialmente envolvendo objetos e agentes. Para isto, são abordados aspectos
referentes a orientação a objetos, orientação a agentes e agentes móveis. A seção 3.1
aborda o paradigma orientado a objetos. A seção 3.2 apresenta o paradigma orientado a
agentes. A Seção 3.3 apresenta aspectos referentes a agentes móveis. Finalmente, a
seção 3.4 apresenta as conclusões do capítulo.
3.1
 
Paradigma Orientado à Objetos
O objetivo desta seção é “lembrar” vários aspectos relacionados à objetos que são
importantes para entender porque mobilidade é explorada usando objetos e agentes.
Além disso, em tecnologias como Voyager [OBJ 97], um agente é visto como um objeto
especial. Desta forma, os conceitos da orientação à objetos são muito utilizados no que
se refere a agentes. Amandi no texto [AMA 97], diz que observando as definições de
objeto e de agente, vê-se que existem características em comuns entre estas entidades e
entre sistemas multi-agentes e sistemas orientado à objetos.
Segundo [AMA 97], objetos são representações de entidades físicas ou abstratas do
mundo real, que pertencem ao contexto do sistema a ser projetado. Este possui como
características fundamentais: os atributos, os métodos e as mensagens. Conceitos
importantes relacionados com o paradigma orientado a objetos, tais como: mensagem,
encapsulamento, classe, instância, herança, associação dinâmica, polimorfismo e
reusabilidade devem ser observados em tecnologias que exploram mobilidade em
objetos. Estes conceitos podem ser encontrados, de forma descritiva, no livro de James
Rumbaugh ([RUM 96]), um clássico da orientação a objetos.
Outra característica importante é a concorrência. Quanto a concorrência em objetos,
existem dois tipos naturais:
• Concorrência intra-objetos - a concorrência surge da existência de vários acessos
concorrentes a um mesmo objeto, que pode implicar a execução concorrente de
métodos de um mesmo objeto;
• Concorrência inter-objetos - a forma de concorrência mais natural, que está
associada ao fato de vários objetos poderem executar simultaneamente.
Havendo concorrência, deve haver sincronização. Em objetos, é necessário sincronizar
os vários objetos, no caso de concorrência inter-objetos e as várias threads em um
objetos, no caso de concorrência intra-objetos.
A comunicação entre objetos pode ser feita de duas formas: síncrona e assíncrona. Na
síncrona, após o envio de uma mensagem a um objeto, a execução do emissor fica
suspensa enquanto não houver retorno por parte do receptor. Num contexto concorrente,
18
deve-se tomar precauções para evitar que o emissor de uma mensagem fique
indefinidamente bloqueado caso não receba resposta. Este tipo de problema levou a
utilização de mecanismos de mensagens assíncronas. Neste caso, o emissor ao enviar
uma mensagem ao um objeto não fica bloqueado, podendo seguir sua execução.
A associação entre concorrência e paralelismo é bastante natural, pois a concorrência
pode ser visto como paralelismo lógico entre tarefas. Embora sejam conceitos
independentes, na prática a diferença entre os dois torna-se difuso, pois cada vez mais os
sistemas concorrentes apoiam-se em sistemas paralelos. Isto acontece porque grande
parte dos conceitos associados a concorrência tem correspondência nos sistemas
paralelos: mecanismos de troca de mensagens, mecanismos de sincronização, etc.
Sendo assim, a passagem de um modelo de objetos concorrente para um modelo de
objetos paralelo é relativamente natural,pois o objeto como unidade de execução
concorrente assegura a localidade em termos de código e dados (encapsulamento). Além
disso, a troca de mensagens permite grande liberdade em termos de implementações em
ambientes paralelos.
Com referência a objetos distribuídos, pode-se dizer que um objeto distribuído é uma
espécie de código que pode “viver” em qualquer lugar de uma rede. Eles são uma
espécie de pacotes com código independente que podem ser acessados por clientes
remotos via invocação de métodos. O cliente não precisa saber em que lugar, na rede, o
objeto distribuído reside. Os objetos podem ser executados em sistemas operacionais
diferentes e podem trocar mensagens com outros objetos em qualquer parte da rede
[ORF 96].
Existe recentemente uma tendência de se construir sistemas computacionais abertos
utilizando objetos distribuídos. Estes possuem as mesmas características principais dos
objetos das linguagens de programação: encapsulamento, polimorfismo e herança,
tendo, dessa forma, as mesmas principais vantagens: fácil reusabilidade, manutenção e
depuração, só para citar algumas.
3.2 Paradigma Orientado a Agentes
A comunidade científica têm proposto uma variedade de definições, cada qual tentando
explicar o seu uso da palavra “agente”. Essas definições vão de um nível elementar até
um nível mais elaborado. Pesquisadores inventaram também novos termos para
referenciar seus agentes, tais como: agentes inteligentes, interfaces inteligentes,
interfaces adaptativas, knowbots, softbots, userbots, taskbots, personal agentes e
network agentes.
Durante o estudo, observou-se que não há uma definição unificada e universal a respeito
do termo "agente". Vários pesquisadores salientam a dificuldade para criação de uma
definição de agente. Amandi em [AMA 97] afirma que um agente representa uma
entidade computacional com um comportamento autônomo, que pode comunicar-se
com outros agentes com o fim de participar na realização de uma tarefa. Os agentes
podem auxiliar outros agentes e usuários de diferentes formas: eles ocultam a
complexidade de tarefas difíceis, podem treinar ou ensinar, ajudam em diferentes
colaborações, monitoram eventos e procedimentos, etc. Um sistema multiagentes é
19
definido por um conjunto de agentes que colaboram entre si para cumprir com as
responsabilidades do sistema.
Um agente deve apresentar algumas propriedades. Elas definem qual é a classificação
do agente, ou seja, um agente inteligente, reativo, capaz de aprender, etc. Propriedades
de agentes correspondem a características de um sistema que são resultados diretos da
arquitetura do sistema ou são níveis de operação que existem sobre a arquitetura que
tem um efeito no comportamento global do sistema. Por arquitetura se entende a porção
do sistema que fornece e gerência os recursos primitivos de um agente [FLE 98]. Para
que o sistema seja considerado agente, ele não necessita apresentar todas as
propriedades mas algumas delas são recomendáveis. Algumas propriedades são:
• Autonomia - é a capacidade de perseguir uma agenda independentemente de seu
usuário. Isso requer aspectos de ação periódica, execução espontânea e iniciativa, em
que o agente precisa ser capaz de tomar ações preemptivas (optativas) e
independentes que eventualmente beneficiarão o usuário [FLE 98]. Em outras
palavras, a autonomia permite ao agente ter algum tipo de controle sobre suas ações
e estado interno.
• Mobilidade - conforme [FLE 98], é a habilidade para mover-se de uma localização
para outra, enquanto preservam seu estado interno.
• Comunicabilidade - é a capacidade de trocar informações com outras entidades
(agentes, humanos, objetos, seu ambiente) [FLE 98]. Nas interfaces entre os agentes,
é necessário decidir que tipo de declaração os agentes serão capazes de gerar e
compreender. Obviamente, o projeto da interface é cuidadosamente relatado para o
projeto da arquitetura de todo o sistema. Há ainda um outro problema na
comunicação que é a interpretação e significado das declarações do agente. Um
termo pode ter diferentes significados para diferentes agentes, o que é chamado de
conflito. Diferentes termos podem, entretanto, ter significado similar, o que significa
uma correspondência.
• Aprendizagem - agentes são capazes de examinar o ambiente externo (por
exemplo, a Web) e o "sucesso" de ações prévias levam condições similares, e
adaptam suas ações para melhorar a probabilidade de atingir prosperamente suas
metas.
• Reatividade - um agente está inserido em um ambiente que pode ser o mundo
físico, um usuário via uma interface gráfica, uma coleção de agentes, a Internet, ou
talvez todos esse combinados. A reatividade é a capacidade de um agente responder
de uma maneira oportuna à mudanças que ocorre nele e no ambiente.
• Iniciativa - Possuir iniciativa é a habilidade de exibir comportamento direcionado
ao objetivo, oportunístico e que não reage simplesmente ao seu ambiente.
• Sociabilidade - significa interagir com outros agentes (e possivelmente humanos)
através de algum tipo de linguagem para comunicação de agente.
• Racionalidade - é a suposição de que um agente atuará para atingir seus objetivos,
e não atuará de modo que impeça que seu objetivo seja alcançado - pelo menos até
onde sua opinião permitir.
20
• Percepção - os agentes sentem o mundo e geram conhecimentos acessíveis para
processar o que a razão está dizendo para perceber no mundo.
• Cooperação - agentes inteligentes precisam ter um "espírito" cooperativo para
existir e ter sucesso em "sistemas orientados a agentes". O que se quer é que agentes
inteligentes trabalhem juntos para que possam executar tarefas mutuamente
benéficas mais complexas .
Dentro das propriedades, tem-se observado que os agentes as possuem em níveis. Por
exemplo: a autonomia de um agente é demonstrada diferentemente de agente para
agente, o que leva a considerar que os agentes apresentam níveis de propriedades. Da
mesma forma que as definições de agente ainda não estão estabelecidas pelo meio
científico de forma homogênea, as propriedades também apresentam esta característica.
As definições das propriedades parecem ser mais convergentes, porém oferecem
margem à várias interpretações. Dependendo das característica que um agente apresenta
ele pode ser classificado em categorias distintas de agentes.
Para poder dizer que um agente é desta ou daquela forma, é necessário que o agente
atenda algumas características peculiares. Por exemplo, para um agente ser considerado
um agente móvel, ele precisa possuir a propriedade de mobilidade. Algumas
classificações de agentes, como agentes inteligentes, agentes autônomos, agentes
reativos, etc, podem ser encontradas no texto [FLE 98].
3.3 Agentes Móveis
Agentes móveis são programas que podem ser disparados em um computador e
enviados para executar em um computador remoto. Chegando no computador remoto
ele apresenta suas “credenciais” e obtêm acesso aos serviços locais e aos dados [LAN
97]. É uma tecnologia emergente que promete tornar sistemas distribuídos mais fáceis
de projetar, implementar e manter. Agentes móveis não estão restritos aos sistemas em
que iniciaram sua execução, pois eles têm a habilidade de se transportar de um sistema
para outro através de uma rede. Este recurso permite a um agente móvel mover-se para o
sistema que possui um objeto com o qual o agente deseja interagir, obtendo a vantagem
de residir na mesma máquina ou rede do objeto.
Agentes móveis podem oferecer um paradigma uniforme para objetos distribuídos,
englobando passagem de mensagens síncronas e assíncronas, passagem de objetos e
objetos móveis e estacionários. Além de suportar os serviços existentes em uma rede,
agentes móveis também tornam possíveis novos serviços e novas oportunidades de
negócios. Características como cooperação, autonomia e representatividade foram
herdadas da própria origem de agentes, entretanto, foram acopladasoutras a fim de
suprir as necessidades exigidas para o bom funcionamento de modelos que utiliza o
paradigma de agentes móveis, tais como objetos passantes, assincronismo, interação
local, operações sem conexão e execução paralela. Estas características são definidas
como [LAN 97]:
• Objetos passantes - quando um agente móvel é transferido, todo o objeto é movido,
ou seja, o código, os dados, o itinerário para chegar ao servidor necessário, o estado
de execução, etc;
21
• Assincronismo - o agente móvel possui sua própria thread de execução e esse não
precisa ser executado sincronamente;
• Interação local - o agente móvel interage com outros agentes móveis ou objetos
estacionários locais. Se necessário, um agente mensageiro é enviado para facilitar a
interação com agentes remotos;
• Operações sem conexão - o agente móvel pode executar tarefas mesmo com a
conexão fechada. Quando se faz necessário transferência de agentes, aguarda-se até
que a conexão seja restabelecida;
• Execução paralela - múltiplos agentes podem ser disparados para diferentes
servidores a fim de executar tarefas em paralelo.
 Apesar de conter semelhanças entre esse novo paradigma e outros métodos de despacho
remoto, os agentes móveis primam por segurança, uma característica fracamente
explorada em sistemas antigos. Isso deve-se, principalmente, ao fato dos sistemas
anteriores não terem sido projetados para utilização em redes geograficamente
distribuídas, sem opções, que hoje fazem parte do cotidiano, como o uso de cartões de
crédito em algum tipo de comércio eletrônico. A nível de segurança os agentes móveis
realizam tarefas relacionadas à autenticação de usuário/servidor e autorização de
serviços no servidor. Aplicações que utilizam os conceitos de agentes seguem o
paradígma atual de funções/procedimentos ou Orientação a Objetos como paradígma de
implementação.
 A aplicação cliente é um ambiente de interação com o usuário que utiliza os conceitos
de agentes móveis. Além disso, essa aplicação tem interface com o ambiente agente.
Logo, quando as tarefas são executadas, o ambiente agente de execução envia o agente
móvel, através do subsistema de mensagens. No servidor, ocorre a ação contrária: o
agente é recebido através do subsistema de mensagem e é encaminhado ao ambiente
agente de execução, que deve ser compatível com o ambiente do cliente. Daí, as tarefas
são realizadas a nível de aplicação servidora e se necessário, um agente mensageiro é
disparado.
 Segundo [LAN 97], agentes móveis apresentam uma série de vantagens como:
• Redução do tráfego da rede - Sistemas distribuídos demandam um grande volume
de comunicação (interação) para realizar uma determinada tarefa, principalmente
quando há restrições de segurança envolvidos. Agentes móveis permitem reduzir o
tráfego da rede, pois permitem despachar tarefas que podem executar suas interações
localmente. Agentes móveis podem ainda reduzir o tráfego de dados da rede, pois
permitem mover o processamento para o local onde os dados estão armazenados ao
invés de transferir os dados para depois processá-los. O princípio é simples: "Mover
o processamento para os dados ao invés de mover os dados para o local de
processamento".
• Oculta a latência da rede - Sistemas críticos necessitam de respostas em tempo real
para mudanças no ambiente. O controle desses sistemas através de uma rede
substancialmente grande ocasiona uma latência inaceitável. Agentes móveis
oferece uma solução, pois podem ser enviados pelo controlador central para
realizarem suas tarefas localmente.
22
• Encapsulamento de protocolo - Cada máquina em um sistema distribuído possui
seu próprio código necessário para implementar a transferência de dados. Porém,
novos requisitos de segurança e eficiência demandam mudanças no protocolo que
podem ocasionar problemas na manutenção do código existente. Agentes móveis,
por outro lado, podem mover-se para máquinas remotas a fim de estabelecer canais
de comunicação baseados em protocolos proprietários.
• Execução assíncrona e autônoma - Tarefas podem ser embutidas em agentes
móveis que podem ser enviados pela rede. Após serem enviados, os agentes são
autônomos e independentes da criação de processo, podendo executar
assincronamente. Este recurso é útil principalmente porque um dispositivo móvel
(ex. laptops) pode se reconectar na rede para coletar o agente mais tarde.
• Adaptação dinâmica - Agentes móveis possuem a habilidade de perceber
mudanças no ambiente de execução e reagir autonomamente. Múltiplos agentes
podem interagir entre si e se distribuir pela rede, de modo a manter uma
configuração ótima para resolver um problema em particular.
• Independência de plataforma - Redes de computadores, geralmente são
heterogêneas, tanto na perspectiva de hardware como a de software. Agentes móveis
são independentes da máquina e também da rede, sendo dependentes somente do seu
ambiente de execução, não dificultando a integração de sistemas. Mas é necessário
que o ambiente de execução do agente esteja disponível para um determinado
hardware ou software.
• Robustez e tolerância a falhas - A habilidade dos agentes móveis de reagirem
dinamicamente a situações e eventos desfavoráveis torna fácil a construção de
sistemas distribuídos robustos e tolerantes a falhas. Por exemplo, se uma máquina
está para ser desligada, todos os agentes em execução na máquina podem ser
advertidos para que possam ser enviados e continuar suas tarefas em outra máquina
da rede.
Para comunicação entre os agentes, merece destaque o Protocolo de Transferência de
Agentes (ATP - Agent Transfer Protocol). Este é um protocolo a nível de aplicação para
sistemas distribuídos baseados em agentes. Enquanto agentes móveis podem ser
programados em diferentes linguagens e para diferentes plataformas, através de uma
máquina virtual e de bibliotecas, o ATP oferece a oportunidade de manejar agentes
móveis através de uma forma geral e uniforme.
Uma máquina que suporta agentes tem um serviço de agente baseado em ATP, que é um
componente capaz de enviar e receber agentes de um computador remoto via protocolo
ATP. O serviço de agente é identificado por um endereço único, independente da
plataforma específica de agente suportada pela máquina. Uma máquina pode rodar
múltiplos serviços de agentes. Além disso, uma mensagem ATP carrega informações
suficientes para identificar a plataforma de agente específica, na máquina receptora, e
um gerenciador ATP é chamado para gerenciar a mensagem.
O protocolo ATP é baseado no paradigma de requisição/resposta entre serviços ATP.
Um serviço ATP A estabelece uma conexão com um serviço ATP B, e envia uma
requisição para B esperando uma resposta. ATP/0.1 pode ser obtido no endereço
http://www.trl.ibm.co.jp/aglets/ e faz parte do IBM Aglets Workbench.
23
Além disso, para que os agentes possam se comunicar com outros agentes distribuídos
através da rede, é desejável que eles se comuniquem através de um protocolo comum.
Desta forma, existe um esforço da comunidade científica no sentido de normalizar a
linguagem de comunicação entre os agentes. Uma proposta é a linguagem KQML
(Knowledge Query Manipulation Language) [FIN 94] e um outro para a representação e
intercâmbio do conhecimento adquirido pelos agentes através do formato KIF
(Knowledge Interchange Format). Estes padrões são importantes para haver um
consenso no desenvolvimento de aplicações com suporte a agentes móveis.
A linguagem Java viabilizou a concepção de diversos sistemas experimentais de agentes
móveis. Numerosos sistemas estão atualmente em desenvolvimento ou já
comercializados tais como: Voyager [OBJ 97] [OBJ 98], Aglets [LAN 97] e Concordia
[WONG 97] [CAS 98]. Estes são apresentados no capítulo 4. Os sistemas citados acima
possuem muitas características em comum, como a utilização da máquina virtual Java
padrão, mecanismos de serialização de objetos e arquitetura baseadaem servidor.
Contudo, os mecanismos de transporte de agentes e interação variam
consideravelmente. Estas diferenças são apresentadas no capítulo 5.
3.4 Conclusões
Este capítulo apresentou aspectos de mobilidade em sistemas distribuídos,
especialmente envolvendo objetos e agentes. Como a maioria das aplicações
distribuídas que suportam mobilidade são construídas a partir do paradigma orientado a
agente e algumas aplicações consideram o agente um objeto especial, os conceitos da
orientação a objetos são amplamente utilizados por tecnologias que suportam
mobilidade.
Pode-se concluir que não há diferença entre objetos e agentes móveis que justifiquem
um estudo separado destas duas entidades. A filosofia da orientação a objetos é
absorvida pela orientação a agentes, portanto, um agente pode ser considerado um
objeto, mas com autonomia, isto é, pode-se dizer que um agente é uma evolução do
objeto. Um exemplo do uso deste conceito é Voyager [OBJ 97] [OBJ 98]. Esta é uma
tecnologia promissora para desenvolvimento de aplicações com suporte à mobilidade
que considera agente um objeto especial, isto é, que tem autonomia.
O Capítulo 4 apresenta as tecnologias usadas para implementar mobilidade e algumas
aplicações que utilizam mobilidade.
24
4 Tecnologias para Suporte à Mobilidade
Este capítulo apresenta algumas ferramentas usadas para desenvolver sistemas que
suportem mobilidade e alguns ambientes que permitem explorar mobilidade. A seção
4.1 apresenta as ferramentas para suporte à mobilidade, tais como Java [SUN 96], Obliq
[CAR 95] e Oz Distribuído [ROY 97], que são linguagens de programação que
permitem implementar mobilidade. Além disso apresenta CORBA [OMG 95],
destacando sua contribuição para exploração da mobilidade. A seção 4.2 apresenta
alguns ambientes que suportam mobilidade, tais como Voyager[OBJ 97] [OBJ 98],
Aglets [OSH 98] e Concordia [WON 97]. A seção 4.3 apresenta alguns exemplos de
aplicações onde à mobilidade pode ser aplicada. Finalmente, a seção 4.4 apresenta as
conclusões do capítulo.
4.1
 
Ferramentas para suporte à mobilidade
4.1.1 Java
Java [SUN 96] é uma linguagem orienta a objetos, baseada em classes, criada pela Sun
Microsystems, com ênfase em portabilidade e segurança. O compilador Java transforma
programas fontes em uma linguagem independente de plataforma chamada Java Byte
Code. Este é interpretado pela Java Virtual Machine (JVM) - a implementação do
ambiente computacional Java. Através da rede, a carga das classes é feita através do
ClassLoader. Este é invocado pela JVM quando, na execução de um código corrente,
uma classe que ainda não foi carregada é referenciada. O ClassLoader busca a classe
correspondente, possivelmente de uma máquina remota, e carrega na JVM. Neste
ponto, o código correspondente é executado.
Java foi criada com a concepção de segurança, essencial em um sistema distribuído,
garantindo que regras de acesso sejam sempre respeitadas. Muitos recursos que
requerem controle de acesso dinâmico, como um sistema de arquivo ou um acesso a
rede, são controlados por um monitor chamado SecurityManager.
Um dos fatores de sucesso de Java é o seu uso na Internet. Browsers suportam JVM e
carregam classes chamadas Applet. Estas podem ser carregadas em páginas HTML
permitindo acesso a pequenas aplicações. Sendo assim, um Applet é um tipo de
aplicação em menor escala para executar em um Web Browser. Toda Applet é criada a
partir de uma subclasse da classe Applet. Esta hierarquia determina muito do que a
Applet não pode fazer. Uma Applet executada pela internet é considerada, por default,
código não confiável.
Sendo assim, pode-se concluir que Java possui uma estrutura computacional própria,
que consiste em seu ambiente computacional, isto é, a máquina virtual Java. Através
desta, Java provê suporte aos mecanismos da linguagem que permitem implementar
mobilidade. A sua entidade computacional é o objeto. Além disso, Java explora
mobilidade fraca, do tipo autônoma, pois permite que os programas sejam carregados
dinâmicamente pela rede, através do ClassLoader. Com estas características, Java é a
25
linguagem mais usada para implementar mobilidade. Ainda pode-se observar que
aplicações móveis desenvolvidas através do paradigma de Código em Demanda podem
ser desenvolvidas utilizando Java. Um exemplo do uso deste paradigma em Java é o
Applet, pois este é buscado em um site remoto para ser executado localmente.
Maiores informações sobre a linguagem Java pode ser encontrado em [SUN 96].
4.1.2 Obliq
Obliq [CAR 95] da DEC System Research Center, é uma linguagem com um escopo
léxico, é dinamicamente tipada, baseada em protótipo, projetada para computação
distribuída orientada a objeto. A computação é transparente da rede, isto é, não tem
nenhuma dependência de localização quanto a computação, mas a distribuição é
gerenciada explicitamente à nível de linguagem.
A linguagem tem três principais características:
• A migração de um objetos pode ser programada com a combinação de transmissão
fechada (como se fosse uma caixa preta), apelidos (outro nome para um objeto) e
objeto clone (cópia do objeto). Depois da migração, operações no objeto original
são redirecionadas para o site remoto e executadas nele. A migração pode ser
serializada através das primitivas serialized e protected para que o estado do objeto
não possa trocar durante a chamada migrate.
• Obliq pertence a uma classe de linguagens orientada a objetos chamada “baseada em
protótipo”. Nestas linguagens não existem classes e objetos são criados por cópia
(clone) de objetos existentes (os protótipos);
• Obliq é tipada dinamicamente. Erros com relação aos tipos da linguagem são
descobertos claramente e propagados para o site origem.
São quatro as operações básicas em um objeto: seleção/invocação, atualização, clone e
apelido.
Na seleção/invocação, quando o valor de um objeto é selecionado, este valor é
transmitido através da rede para o site que selecionou. Quando o método de um objeto
remoto é invocado, os argumentos são transmitidos através da rede para o site remoto, o
resultado é realizado no computador remoto, e o valor final é retornado para o site que
invocou.
Na atualização, quando um objeto remoto é atualizado, um valor é transmitido através
da rede para o objeto remoto.
Pode-se notar neste ponto que Obliq suporta o paradigma de Avaliação Remota, pois o
conhecimento vai para onde está o recurso e depois retorna ao site requisitante.
No Clone, uma cópia do objeto é criada, mas a estrutura dos valores é compartilhada.
Por exemplo, os elementos de um vetor são compartilhados entre o clone e o objeto
original. No apelido, atributos podem ser redirecionados para atributos em outros
objetos. Apelidos são usados para criar procuradores.
26
Objetos podem ser protegidos através da palavra protected. Interfaces seguras podem ser
construídas através do uso do mecanismo de proteção e procuradores. Para tratar acessos
concorrentes, Obliq suporta objetos serializados. Um objeto é serializado se mais de
uma thread pode acessar o objeto. Isto é feito usando mecanismos de exclusão mutua,
que é adquirido quando um dos métodos é invocado e solto quando retorna do método.
O escopo léxico oculta valores chamados externamente e o sistema de execução
assegura que o escopo seja cumprido. Comunicações entre servidores independentes são
mediadas através de uma variável global compartilhada contendo o nome do servidor
(endereço IP da máquina por exemplo), permitindo servidores importar e exportar
valores. Para um procedimento ser executado em um servidor distante, o nome do
servidor é solicitado para a máquina de execução (execution engine) receber o
procedimento. Máquina de execução implementa um tipo de ambiente de execução,
permitindo execução remota de procedimentos. Uma thread, que é a unidade de
execução Obliq, pode requisitar a execução de um procedimentoem uma máquina de
execução remota. O código para o procedimento é enviado para a máquina destino e
executada nela em uma nova thread. As referências do objeto local usadas pelo
procedimento são automaticamente transformados em referências para rede.
Sendo assim, Obliq suporta mobilidade forte, tanto através de migração quanto através
de clone remoto. No primeiro caso o gerenciamento do espaço de dados se dá através da
remoção das ligações e no segundo através de referências na rede e por cópia. Além
disso, a máquina de execução Obliq oferece um ambiente computacional propício a
exploração da mobilidade e sua entidade base é o objeto.
Maiores informações sobre Obliq pode ser encontrado em [CAR 95].
4.1.3 Oz Distribuído
A linguagem Oz distribuída [ROY 97] é uma linguagem projetada para processamento
simbólico concorrente. O Oz integra vários paradigmas de programação, incluindo
orientação a objetos, funcional e restrições lógicas, em um único modelo.
A semântica distribuída estende a semântica da linguagem através do controle da
mobilidade. Mobilidade em OZ é a habilidade que uma entidade stateful, que pode
mudar seu estado, tem de migrar entre os sites ou de permanecer estacionária entre os
sites, dependendo das intenções do programamador [ROY 97].
A construção do Oz distribuído tem quatro características essenciais [ROY97]: (1) é
uma linguagem concorrente; (2) tem um fluxo de dados sincronizado. Threads são
bloqueadas quando um dado é requisitado por ela mas ainda não está disponível. Este
bloqueio é transparente do ponto de vista da thread; (3) tem procedimentos de primeira-
classe com escopo léxico; (4) tem informação de estados (state-aware), distinguindo
dados stateless (não mudam seus estados e são replicados entre os sites ) e stateful.
A linguagem satisfaz a semântica centralizada garantindo a transparência na rede. Este
requisito requer mecanismo como um espaço de computação compartilhado (shared
computation space) e concorrência (concurrency). O primeiro provê a ilusão de uma
grande memória comum (espaço de endereçamento para as entidades) para todos os
dados. Além disto, um programa que executa em muitos sites deve se comportar da
27
mesma maneira quando executado em um site. Portanto, outro mecanismo necessário é
a concorrência, isto é, várias computações ativas devem coexistir independentemente.
São usados dois mecanismos para identificar a rede: informação de estado (state-
awareness) e controle da mobilidade (mobility control). O sistema deve distinguir
entre estas duas formas de dados através de uma informação de estado. Para dados
stateful, é necessário um controle maior da localização. Para isto surge o controle da
mobilidade. Entidades móveis migram para sites remotos invocando estes. Isto é
implementado usando um protocolo para mobilidade [ROY 98].
Pode-se observar neste ponto que OZ Distribuído pode suportar mobilidade forte através
da migração do tipo proativa, onde a unidade migrante determina quando migrar. Sua
entidade base é o objeto. Seu ambiente computacional é a Oz Virtual Machine que,
como em Java, é portável, podendo executar tanto em Unix como em Windows.
A meta do projeto de distribuição é não impedir a implementação centralizada, para isto,
o espaço de computação pode ser representado em termos de dois grafos: o grafo para
linguagem, onde não existe a noção de site e o grafo de distribuição, que faz
explicitamente a noção de site.
A execução distribuída é feita em dois passos: no primeiro passo o espaço
computacional é modelado em um grafo chamado grafo da linguagem. O segundo passo
é estender o grafo da linguagem para o grafo de distribuição, com a noção de site,
introduzindo um conjunto finito de site e colocando em cada nodo o grafo da linguagem
com o site. Se um nodo é referenciado por um nodo em outro site, ele é mapeado para
um conjunto de nodos no grafo de distribuição. Este conjunto é chamado de estrutura de
acesso do nodo o riginal. Uma estrutra de acesso consiste em um conjunto de nodos
globais, um chamado procurador (proxy) pelo site e outro de gerenciador por toda a
estrutura.
As células tem ponteiro para os dados (content-edge), que são conhecidos somente por
um procurador. Os procuradores geralmente não conhecem onde o ponteiro para os
dados está localizado. Se procurador quer fazer uma operação de troca e não tem o
ponteiro para os dados, este deve perguntar ao gerenciador. Isto diminui a latência da
rede.
OZ tem um modelo simples para tolerância a falhas. A detecção de falhas deve
realmente informar ao programador se e onde a falha ocorreu. O modelo suporta
somente falha no site, não suportando falha na rede. Cada espécie de falhas torna-se
visível somente a um procurador, quando este tenta fazer uma operação na célula e
descobre que ocorreu uma falha. O procurador tem então um nodo falho e algumas
mensagens para este são ignoradas. Excepcionalmente é criada uma thread que
inicicializa as operações na célula.
Maiores informações sobre o modelo de programação do Oz distribuído podem ser
encontrados em [ROY 98] e [ROY 97].
4.1.4 CORBA
A organização OMG (Object Management Group) estabeleceu a arquitetura CORBA
(Common Object Request Broker Architecture) [OMG 95] como uma forma de
28
especificar um middleware aberto composto de objetos distribuídos. O objetivo primário
é alcançar sistemas baseados em objetos em ambientes distribuídos heterogêneos com
características de reusabilidade, portabilidade e interoperabilidade.
Em 1990, a OMG criou o OMA (Object Management Architecture) com o objetivo de
fomentar o crescimento de tecnologias baseadas em objetos e fornecer uma infra-
estrutura conceitual para todas especificações OMG. O OMA é composto por quatro
elementos principais: ORB (Object Request Broker), Serviços de Objetos, Facilidades
Comuns e Objetos de Aplicação. Para este texto, o elemento que merece destaque é o
ORB. Este habilita os objetos enviarem e receberem requisições e, da mesma maneira,
receberem respostas a suas requisições, de forma transparente em um sistema
distribuído. O ORB é a base para a construção de aplicações, utilizando objetos
distribuídos, que possuam características de interoperabilidade entre aplicações em
ambientes heterogêneos ou homogêneos.
A Figura 4.1 dá uma idéia geral da estrutura e dos elementos que compõe o OMA.
 FIGURA 4.1 - Arquitetura de Gerenciamento de Objetos (OMA)
O principal objetivo de se definir uma arquitetura comum para ORB's é para se obter a
interoperabilidade entre diferentes implementações. A grande diversidade dessas
implementações mostra que fazê-las interoperar não será tarefa simples, bem como não
foi interconectar redes distintas com diferentes protocolos, por isso, este último vem
sendo usado como modelo para se alcançar o objetivo, a interoperabilidade.
Objetos clientes requisitam serviços às implementações de objetos através de um ORB.
O ORB é responsável por todos os mecanismos requeridos para encontrar o objeto,
preparar a implementação de objeto para receber a requisição, e executar a requisição. O
cliente vê a requisição de forma independente de onde o objeto está localizado, qual
linguagem de programação ele foi implementado, ou qualquer outro aspecto que não
está refletido na interface do objeto.
O primeiro requisito para se obter a interoperabilidade é definir um modelo de alto nível
para que suas diferenças sejam disfarçadas. No caso do ORB esse modelo é uma IDL
(Interface Definition Language). CORBA utiliza a OMG IDL como uma forma de
descrever interfaces, isto é, de especificar um contrato entre os objetos. OMG IDL é
uma linguagem puramente declarativa baseada em C++. E por ser definida
independentemente do ORB, permite que clientes e implementações se comuniquem
transpassando vários ORB's distintos preservando a semântica dos pedidos de forma
transparente para clientes e implementações. Isso garanteque os componentes em
29
CORBA sejam auto-documentáveis, permitindo que diferentes objetos, escritos em
diferentes linguagens, possam interoperar através das redes e de sistemas operacionais
[ORF 96].
Para fazer uma requisição, um cliente pode usar a Interface de Invocação Dinâmica (DII
- Dynamic Invocation Interface) ou um Stub de IDL. Para algumas poucas e
determinadas funções, um cliente pode interagir diretamente com a interface do ORB.
O fato de permitir tanto a invocação dinâmica quanto a estática, torna CORBA bastante
flexível. A invocação estática possui uma série de vantagens sobre a invocação dinâmica
[ORF 96]: é mais fácil de programar, faz verificação de tipos mais robusta, executa mais
rápido e é auto-documentável. Já a invocação dinâmica permite a adição de novos
serviços às implementações de objetos sem alterações nos clientes. Dessa forma, os
clientes podem descobrir em tempo de execução quais são os serviços oferecidos.
A invocação dinâmica é possível através dos serviços do Repositório de Interfaces. Um
Repositório de Interfaces é uma base de dados que contém interfaces OMG IDL, e seus
serviços basicamente permitem o acesso, armazenagem e atualização dessas interfaces.
Ao receber uma requisição, o ORB localiza o código da implementação transmite
parâmetros e transfere o controle para a implementação do objeto. Quando a requisição
é completada, o controle e os valores de saída são retornados ao cliente. De forma
parecida ao que ocorre na requisição de um cliente, o ORB pode invocar a
implementação de objeto através de um Esqueleto de IDL Estático ou Dinâmico. A
Interface de Esqueleto de IDL Dinâmica (DSI - Dynamic Skeleton Interface) é uma
forma de se enviar requisições de um ORB para uma implementação de objetos que não
possui informações sobre a implementação do objeto em tempo de compilação.
Para executar a requisição, a implementação de objeto pode obter alguns serviços do
ORB através do Adaptador de Objetos. O Adaptador de Objetos se situa no topo dos
serviços de comunicação do Núcleo de ORB. Ele fornece o ambiente para instanciar
objetos, atribuir referências de objetos, e passar requisições a eles. Com um adaptador
de objetos, é possível a uma implementação de objeto ter acesso a um serviço
independentemente se ele está implementado no Núcleo de ORB — se o Núcleo de
ORB oferecer o serviço, o adaptador simplesmente fornece uma interface para ele, caso
contrário, o adaptador deve implementá-lo no topo do Núcleo de ORB.
Para localizar e ativar implementações de objetos, um ORB se utiliza de Repositórios de
Implementações. Esses repositórios servem adicionalmente para armazenar informações
adicionais associadas com implementações de ORBs, tais como, informações de
depuração, controles administrativos, segurança, dentre outras.
A especificação de interfaces de objetos obrigatoriamente em OMG IDL, garante a
portabilidade dos objetos através de diferentes linguagens, ferramentas, sistemas
operacionais e redes. Entretanto, a característica de interoperabilidade entre objetos só
foi coberta na versão 2.0 do CORBA, introduzida em dezembro de 1994.
O protocolo entre ORBs genérico (GIOP - Generic Inter-ORB Protocol) especifica uma
sintaxe de transferência padrão e um conjunto de formatos de mensagens para
comunicação entre ORBs. O protocolo entre ORBs para Internet (IIOP - Internet Inter-
ORB Protocol) especifica como mensagens GIOP são trocadas usando conexões
TCP/IP. Ele especifica um protocolo de interoperabilidade padrão para Internet.
30
O ORB, por si só, não executa todas as tarefas necessárias para os objetos
interoperarem. Ele só fornece os mecanismos básicos. Outros serviços - como serviço
de nomes, de controle de concorrência, de tempo - necessários são oferecidos por
objetos com interface IDL, que a OMG vem padronizando para os objetos de aplicação
poderem utilizar.
Analisando as características CORBA, pode-se observar que suporta o paradigma de
Avaliação Remota, pois através do ORB, objetos podem enviar requisições e receber
suas respostas. CORBA é usado para o desenvolvimento de aplicações que envolvem
objetos distribuídos, isto é, não suporta em sua essência mobilidade. O papel de
CORBA na mobilidade, e também neste texto, advém do fato de que esta tecnologia
serviu de inspiração para várias outras tecnologias que suportam mobilidade. Voyager
[OBJ 97] [OBJ 98], que será visto a seguir, é um exemplo de tecnologia que
implementa mobilidade e que usa uma plataforma ORB, além de permitir integração
com CORBA.
Maiores informações a respeito da tecnologia CORBA pode se encontrada nas
referências [OMG 95] e [ORF 96].
4.2 Ambientes que permitem explorar mobilidade
4.2.1 Voyager
Conforme [GLA 98], ObjectSpace VoyagerTM Core Technology - Voyager [OBJ 97]
[OBJ 98] - consiste de uma plataforma ORB implementado em Java e com suporte a
agentes. É uma plataforma que integra computação distribuída com tecnologia de
agentes, suportando objetos móveis e agentes autônomos. Permite que objetos e agentes
possam enviar mensagens padrão Java para um agente mesmo sem saber sua localização
atual. Além disso, também inclui um conjunto de serviços que implementa, de forma
transparente, persistência, comunicação em grupo e serviço básico de diretório.
Uma das habilidades de Java é carregar classes na máquina virtual em tempo de
execução. Isto habilita uma infra-estrutura para usar objetos móveis e agentes
autônomos bem como ferramentas para construção de sistemas distribuídos. Tem
sintaxe própria para construir, enviar mensagens e mover objetos e agentes e permite
implementar persistência distribuída. Desta forma, Voyager provê suporte para
mobilidade de objetos e agentes, utilizando o modelo de objetos Java.
Voyager permite integração com CORBA desde 1997. Um pacote adicional Java
permite ao Voyager criar uma interface para ser usada em um cliente ou servidor
CORBA. Sem modificação do código, por exemplo, pode-se exportar algumas classes
Java para servidores CORBA, gerando automaticamente IDL para ser usada pela
implementação CORBA.
Redes de computadores são, geralmente, compostas de hardware e sistema operacional
diferentes. Sistemas usando ORBs freqüentemente necessitam código binário em
separado para cada plataforma. Isto aumenta o tempo de desenvolvimento e
complexidade para manutenção do sistema. Como Voyager é implementado em Java,
31
portanto portável, as aplicações são escritas somente uma vez, podendo executar em
cima de qualquer arquitetura que suporte Java.
Resursos em sistemas distribuídos necessitam ser usados sabiamente. Quando uma
máquina está sobrecarregada, parte da carga deve ser levada para uma máquina que não
esteja sobrecarregada. O desenvolvimento somente com ORBs não auxilia aos
programadores resolverem este problema [GLA 98]. Em Voyager, objetos e agentes
móveis podem ser usados para encapsular processamento e migrar através da rede,
levando a carga de trabalho com eles. Sendo assim, voyager permite balanceamento
dinâmico de carga.
Um objeto Voyager é um componente de software que tem um conjunto bem definido
de funções e dados encapsulados.
Quando um programa Voyager inicia, ele automaticamente cria threads que provêem
algum serviço, como garbage collection e verificação do tráfego da rede. Cada
programa Voyager tem um endereço na rede consistindo no nome da máquina e o
número da porta de comunicação, que é um inteiro único para a máquina. Números de
portas são alocados aleatoriamente para os programas. Isto é suficiente para clientes
comunicarem-se com objetos remotos, criar e lançar agentes através da rede. Contudo,
se um programa pode ser endereçado por outro programa, pode-se atribuir um número
de porta conhecido para o programa em inicialização.
Uma classe controla instâncias remotas se sua instância pode ser criada fora do espaço
de endereçamento local do programa e se esta instância pode receber