Um Estudo sobre Mobilidade em Sistemas Distribuídos

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
1.1
1.2
1.3
1.4
2
2.1
2.2
2.3
2.3.1
2.3.2
2.3.3
2.4
3
3.1
3.2
3.3
3.4
4
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.2
4.2.1
4.2.2
4.2.3
4.3
4.4
5
5.1
5.2
6
INTRODUÇÃO .................................................................................................................................7
TEMA .............................................................................................................................................. 7
MOTIVAÇÃO .................................................................................................................................... 7
OBJETIVOS ...................................................................................................................................... 9
ESTRUTURA DO TEXTO ................................................................................................................... 9
MOBILIDADE ................................................................................................................................ 10
CONCEITOS ................................................................................................................................... 10
MECANISMOS ................................................................................................................................ 11
PARADIGMAS PARA MOBILIDADE................................................................................................... 14
Avaliação Remota......................................................................................................................... 15
Código em Demanda .................................................................................................................... 15
Agentes Móveis............................................................................................................................. 16
CONCLUSÕES ................................................................................................................................ 16
MOBILIDADE EM OBJETOS E AGENTES.............................................................................. 17
PARADIGMA ORIENTADO À OBJETOS ............................................................................................ 17
PARADIGMA ORIENTADO A AGENTES ............................................................................................ 18
AGENTES MÓVEIS ......................................................................................................................... 20
CONCLUSÕES ................................................................................................................................ 23
TECNOLOGIAS PARA SUPORTE À MOBILIDADE .............................................................. 24
FERRAMENTAS PARA SUPORTE À MOBILIDADE .............................................................................. 24
Java .............................................................................................................................................. 24
Obliq............................................................................................................................................. 25
Oz Distribuído .............................................................................................................................. 26
CORBA ......................................................................................................................................... 27
AMBIENTES QUE PERMITEM EXPLORAR MOBILIDADE .................................................................... 30
Voyager ........................................................................................................................................ 30
Aglets ............................................................................................................................................ 33
Concordia..................................................................................................................................... 35
APLICAÇÕES .................................................................................................................................. 37
CONCLUSÕES ................................................................................................................................ 38
ANÁLISE COMPARATIVA DAS TECNOLOGIAS QUE SUPORTAM MOBILIDADE .....40
ANÁLISE COMPARATIVA DAS FERRAMENTAS ................................................................................. 40
CONCLUSÕES ................................................................................................................................ 44
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
compreender o 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
Proactive
Reactive
Remote
Cloning
Proactive
Code
shipping
Stand-alone
code
Reactive
Synchronous
Asynchronous
Imediate
Deferred
Code
fragment
Synchronous
Asynchronous
Imediate
Deferred
Code
fetching
Data space
management
Stand-alone
code
Re-binding
Asynchronous
Imediate
Binding removal
Network reference
Synchronous
Deferred
Code
fragment
Synchronous
Asynchronous
By copy
Imediate
By Move
Deferred
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-se 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 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 necessitase 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 acopladas outras 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 baseada em 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 procedimento em 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 primeiraclasse 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 (stateawareness) 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 infraestrutura 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 garante que 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 InterORB 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 mensagens como
se ela estivesse localmente. Sendo assim, no Voyager, esta classe "esconde" o fato de
estar remota. É importante salientar que fora do contexto Voyager, uma classe remota
não esconde o fato de estar remota. Para simplificar, este trabalho denomina classes
que controlam instâncias remotas como classes remotas. Voyager permite um objeto
comunicar-se com uma instância de uma classe remota através de referências virtuais.
Mensagens enviadas para referências virtuais são automaticamente repassadas para a
instância da classe remota. Se uma mensagem retorna um valor, o objeto receptor envia
o valor de retorno para a referência virtual, que retorna este valor para o emissor.
Após a criação de uma classe remota, pode-se construir instâncias remotamente,
mesmo se o código da classe não exista na máquina remota; enviar mensagens para
instâncias remotas usando uma sintaxe Java regular; conectar instâncias remotas
existentes em outros programas; mover instâncias remotas para outros programas,
mesmo se o código da classe não esteja no programa destino e construir instâncias
remotas persistentes.
Depois de criar uma classe remota, pode-se criar instâncias remotas da classe original
(objetos remotos). As instâncias remotas podem residir no programa corrente ou num
programa diferente, e uma referência virtual para a instância remota é criada no
programa corrente. Para construir uma instância remota de uma classe, dá-se ao
construtor de classes virtuais o endereço do programa destino onde a instância remota
deve residir. Se o código original da classe para a instância remota não existir no
programa destino, Voyager carrega automaticamente o código da classe original no
programa destino.
Neste ponto nota-se que Voyager suporta o paradigma de Código em Demanda.
32
Quando um objeto remoto é criado, é automaticamente atribuído a ele um identificador
global único, que identifica o objeto em todos os programas da rede. Opcionalmente,
pode-se atribuir um alias para um objeto remoto durante a criação. O identificador ou o
alias podem ser usados para localizar ou conectar o objeto em qualquer ponto da rede.
Um objeto remoto pode ser referenciado por qualquer número de referência virtual.
Para criar uma nova referência virtual e associa-la com o objeto remoto existente, devese fornecer o endereço do programa onde o objeto remoto existente reside e o seu alias
para o método VObject.forObjectAt( ).
Quanto à mobilidade, pode-se mover qualquer objeto serializado de um programa para
outro enviando a mensagem moveTo( ) para o objeto via refêrencia remota, fornecendo o
endereço do programa destino como parâmetro. Mobilidade é a habilidade de mover-se
independentemente de um dispositivo para outro através da rede [GLA 98].
Uma mensagem pode ser enviada para um objeto mesmo que o objeto tenha-se movido
de um programa para outro, simplesmente enviando a mensagem para o objeto no
último endereço conhecido. Quando a mensagem não localiza o objeto destino, a
mensagem procura por um retransmissor representando o objeto. Se um retransmissor é
localizado, este envia a mensagem para o objeto na nova localização. O valor retornado
é marcado como a nova localização do objeto remoto, para que a referencia virtual possa
atualizar a localização do objeto. Após isto, mensagens são enviadas diretamente para a
nova localização do objeto, sem necessitar do retransmissor.
Mobilidade é útil porque os objetos que trocam grande número de mensagens podem
ser movidos para junto um do outro, reduzindo assim o tráfego na rede. Um programa
pode mover objetos dentro de um dispositivo móvel. Assim o programa pode
permanecer com o dispositivo depois de ele ser desconectado da rede.
Analisando o texto até o momento, observa-se que Voyager também pode dar suporte ao
desenvolvimento através do paradigma de Avaliação Remota. Sendo assim, os objetos
podem mover-se para onde está o recurso.
Voyager também suporta agentes móveis. A filosofia do Voyager é que o agente é
simplesmente uma espécie especial de objeto que pode mover-se independentemente,
podendo continuar sua execução ao se mover, e no entanto comportar-se exatamente
como qualquer outro objeto. Um agente é um tipo especial de objeto pois ele tem
autonomia, isto é, ele é um objeto que pode existir mesmo sem ter uma referência para
ele. Um agente autônomo pode ser programado para satisfazer uma ou mais metas,
mesmo se, ao mover-se, perder contato com seu criador.
Neste ponto fica claro 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 agente em Voyager suporta, além da autonomia, mobilidade. Além disso, um agente
tem todas as características de um objeto simples: pode ser atribuído um alias,
referências virtuais, comunicação com objetos remotos, etc. Sendo assim, um agente
pode mover-se de um programa para outro. Mas, diferentemente de objetos simples, um
agente pode mover-se de forma autônoma.
33
Através dos agentes, nota-se que Voyager também suporta o desenvolvimento de
aplicações através do paradigma de Agentes Móveis. Além disso, pode implementar
uma mobilidade forte através da migração destes agentes.
Existem várias vantagens em usar agentes móveis em Voyager:
•
Se uma tarefa tem que ser desempenhada independentemente do computador que a
inicializou, um agente pode ser criado para desempenhar esta tarefa. Ele pode
mover-se dentro da rede e completar a tarefa num programa remoto;
•
Se um programa precisa enviar um grande número de mensagens a objeto em
programas remotos, um agente pode ser construído para visitar cada programa e
enviar mensagens localmente;
•
Para particionar um programa e tê-lo executando em paralelo, o processamento pode
ser distribuído por vários agentes que migram para programas remotos e se
comunicam para atingir a meta final. Se um objeto remoto precisa ser monitorado
periodicamente, ter um agente que o encontra e o monitora localmente é mais
eficiente que monitorá-lo através da rede.
Voyager suporta persistência. Um objeto persistente tem uma cópia backup na base de
dados, chamada VoyagerDb, e é automaticamente recuperado se o seu programa
termina inesperadamente.
Maiores informações a respeito da tecnologia Voyager pode ser encontrada em [OBJ 97]
e [OBJ 98].
4.2.2 Aglets
Aglets [IBM 97] são objetos Java com a capacidade de se mover de uma máquina para
outra em uma rede, levando consigo o código de programa e o estado dos objetos que
compõe o Aglet. Este é um agente móvel porque suporta a idéia de execução autônoma
e rota dinâmica de seu etinerário. A biblioteca de classes de um Aglet tem os seguintes
objetivos:
• fornecer um modelo simples de programação utilizando agentes móveis, sem no
entanto implicar em modificação na JVM ou em código nativo;
• disponibilizar mecanismos de comunicação poderosos e dinâmicos que
permitam agentes se comunicarem com outros agentes;
• projetar uma arquitetura de agentes móveis que permita extensibilidade e
reusabilidade;
• obter uma arquitetura altamente coerente com o modelo tecnológico Web/Java.
A biblioteca Aglets/API (J-AAPI - Java Aglet Application Programming Interface) é
uma proposta padrão para criar Aglets. Contém métodos para inicialização, mensagens,
movimento, ativação/desativação, etc. Plataformas escritas com estas bibliotecas podem
ser escritas e executadas em qualquer computador que suporte a interface para Aglet. O
modelo define um conjunto de abstrações e de comportamento necessários para que a
tecnologia de agentes móveis seja usada na Internet. As principais abstrações do modelo
34
são o Aglet, o contexto, o procurador, a mensagem, o itinerário e o identificador, como é
visto a seguir:
• Aglet - é o elemento básico da biblioteca e consiste em um objeto Java móvel
autônomo (pois possui sua própria thread de execução) e reativo pois pode
responder a mensagem externas.
• Contexto (context) - é um objeto estacionário que provê um ambiente para
manutenção e gerenciamento de aglets em execução.
• Procurador (proxy) - é um objeto que representa um Aglet, e tem por objetivo
fornecer transparência de localidade e proteção a métodos públicos.
• Mensagem (message) - é um objeto transmitido entre Aglets, permitindo passagem
de mensagens síncronas e assíncronas, usados para colaboração e troca de
informações.
• Itinerário (itinerary) - é o plano de viagem do Aglet. Isto provê uma conveniente
abstração de padrões de viagens e rota.
• Identificador (identifier) - cada aglet possui um único e global identificador que é
imutável durante todo seu ciclo de vida.
O modelo Aglet provê comportamentos essenciais com relação a um agente tais como:
criação, clonagem, envio, retirada, desativação, ativação, liberação, mensagem e
nomeação [LAN 97].
A criação de um Aglet coloca ele no contexto. Ao novo Aglet é atribuído um
identificador, inserido no contexto e inicializado. O Aglet começa a execução assim que
ele seja inicializado com sucesso. A clonagem produz uma cópia quase idêntica do
Aglet original no mesmo contexto. Somente há diferença na atribuição do identificador
e o fato da execução reiniciar em um novo Aglet. Com isto, a thread em execução não é
clonada. O envio de um Aglet de um contexto para outro remove ele do contexto
corrente e insere dentro do contexto destino, onde a execução da thread é reinicializada.
Sendo assim, embora Java suporte mobilidade fraca, a biblioteca Aglet suporta
mobilidade forte através de migração, pois como colocado no parágrafo acima, o envio
de um Aglet tira ele de um contexto e o coloca em outro. Além disso, o contexto pode
ser considerado o ambiente computacional que dá suporte à mobilidade dos agentes em
Aglet. A entidade base do Aglet é o agente.
A retirada de um Aglet remove ele do contexto corrente e o insere dentro do contexto ao
qual a retirada foi requisitada. A desativação de um Aglet remove temporariamente do
contexto corrente e o coloca em um armazenamento secundário. A ativação restaura o
Aglet para o contexto corrente. A liberação de um Aglet pára a execução corrente e o
remove do contexto corrente. Mensagens entre Aglet envolvem envio, recebimento e
parada de mensagens síncronas bem como assíncronas. O mecanismo de nomeação
automático atribui um identificador imutável para um novo Aglet.
Voyager utiliza o protocolo ATP (Agente Transfer Protocol), abordado no Capítulo 3,
para a comunicação e transferência de agentes entre os contextos.
35
Quanto a segurança dos agentes, o Modelo de Segurança Aglet provê vários framework
para segurança em Aglet. Como Aglets são objetos Java que podem migrar de uma
máquina para outra, eles tem um potencial de acesso para todos os recursos da máquina.
Eles também confiam na segurança do interpretador Java para sua própria execução.
Assim, segurança em Aglet e segurança em Java andam juntas.
Maiores informações sobre Aglet podem ser encontradas em [IBM 97] , [OSH 98] e
[LAN 97].
4.2.3 Concordia
O Concordia [WONG 97] [CAS 98], concebido pela Mitsubishi constitui-se de um
framework para o desenvolvimento e gerenciamento de aplicações de agentes móveis.
O Concordia compreende múltiplos componentes, todos escritos em Java, na qual são
combinados para prover um ambiente para aplicações distribuídas. Este sistema é
simples, e requer somente uma implementação padrão do servidor Concordia, feito em
cima da máquina virtual Java, e seu ambiente é composto de um servidor e um conjunto
de agentes. O agente é também um programa Java que é gerenciado pelo servidor
Concordia. Cada agente está associado a um usuário particular e carrega uma
especificação que contém o caminho de migração e o método a ser executado em cada
máquina. Nota-se que a entidade base do Concordia é o agente.
Quanto a arquitetura do sistema, cada nodo num sistema Concordia consiste em um
servidor Concordia e provê serviços básicos para criação, migração, execução,
comunicação e administração de agentes móveis. O servidor pode ser executado em uma
ou mais máquinas virtuais Java. A figura 4.5 mostra como é formada a arquitetura do
Concordia [WON 97].
Java Virtual Machine
Security
Manager
Administration
Manager
Agents
Persistent
Manager
Event
Manager
remote queue
managers
Conduit
Manager
Queue
Manager
remote conduit
servers
Corporate
DB server
FIGURA 4.5 - Arquitetura do Concordia
36
O Servidor Concordia é um componente completo, instalado e executando em uma
rede Concordia. O servidor é o ambiente computacional necessário para a computação,
permitindo que à mobilidade seja explorada através das estruturas contidas dentro do
ambiente.
O Gerenciador de Agentes provê a infra-estrutura de comunicação que permite aos
agentes serem transmitidos e recebidos pelos nodos da rede. Além disso, gerencia o
ciclo de vida do agente, provê suporte à mobilidade e interface para administração
(inclusive remota) dos serviços do servidor Concordia.
À mobilidade do agente é transparente para os usuários do sistema. A viagem do agente
é descrita através de um itinerário. Este é composto de múltiplos destinos. Cada destino
descreve a localização do agente na viagem e o trabalho que o agente realiza nesta
localização. A localização pode ser definida pela identificação da máquina na rede e o
trabalho através dos métodos manipulados pelo agente.
O Concordia usa uma infra-estrutura similar a Java para mobilidade dos agentes.
Durante a viagem de um agente através da rede, seu byte code e o byte code de alguns
objetos são carregados via uma classe especial chamada ClassLoader. Neste pacote, o
byte code contém uma estrutura de dados que viaja com o agente. Durante a
deserialização do agente, o byte code para o agente e suas classes podem ser
recuperadas e usadas para inicializar uma nova copia do agente.
Pode-se notar que Concordia permite uma mobilidade fraca do tipo autônoma,
semelhante a Java, pois permite que os programas sejam carregados dinâmicamente pela
rede, através do ClassLoader.
Concordia dá suporte a duas formas de comunicação inter-agente: eventos assíncronos
distribuídos e colaboração entre agentes. Eventos assíncronos distribuídos são
escalonados e gerenciados pelo Gerenciador de Eventos, enquanto a colaboração entre
agentes requer que o programador da aplicação agente especifique um objeto
AgentGroup através da utilização da biblioteca de classes Concordia. A colaboração
entre agentes permite a interação entre agentes, colaboração num grupo (agentes podem
enviar eventos para outros agentes ou para aplicação pai).
Persistência em agentes é um requisito que assegura recuperação do agente em caso de
falha. A persistência é oferecida através do Gerenciador de Armazenamento
Persistente, permitindo a reinicialização do agente quando ocorrer uma falha ou até
mesmo a reinicialização do servidor Concordia. A implementação do Gerenciador de
Armazenamento Persistente é baseada na serialização de objetos Java.
Agentes em Concordia são móveis e sua mobilidade pode extender-se tanto em redes
locais como na Internet. O Gerenciador de Filas é responsável pelo controle de
prioridades na execução de agentes, e também pela migração de agentes, garantindo um
nível de tolerância a falhas através do armazenamento do agente antes de transmití-lo
(store-and-forward).
O modelo de segurança Concórdia provê suporte para dois tipos de proteção: (1)
proteção contra agentes com origem falsificada e (2) proteção dos recursos do servidor
contra acessos não autorizados. Agentes são protegidos contra falsidade quando são
armazenados no sistema cliente e quando são armazenados na base de dados persistente.
Esta proteção é feita através de criptografia. Sendo assim, garante a proteção do agente
37
no armazenamento e na migração, além de autenticar a origem do agente. O
Gerenciador de Segurança gerencia os recursos de proteção. A cada agente é atribuído
uma identificação, permitindo ao agente acessar os recursos.
A administração do sistema Concordia é feita pelo Gerenciador de Administração.
Este inicializa e termina os servidores do sistema de agentes. Ele também gerencia a
troca de política de segurança entre os agentes e os servidores fazendo uma requisição
do comportamento do agente ou do servidor para o Gerenciador de Seguraça. Além
disso, monitora o comportamento dos agentes através da rede, provêndo estatísticas
sobre isto.
O Gerenciador de Diretório permite aos agentes móveis localizar os servidores de
aplicação para interação. O sistema pode ser configurado para incluir um ou mais
gerenciador de diretórios. Além disso, registra os serviços de aplicações disponíveis na
rede e disponibiliza uma operação de lookup para os agentes que estão a procura de
serviços para interagir.
As Pontes de Serviço possibilitam que os agentes e/ou aplicações acrescentem serviços
ao servidor Concordia, aumentando a funcionalidade e a interação do servidor com os
agentes.
Em Concordia fica muito claro a concepção de um ambiente computacional, assim
como em Java. Este ambiente, além de permitir mobilidade, oferece segurança, acessos
autorizados, confiança etc.
Maiores Informações sobre Concordia podem ser encontradas nos textos [WONG 97] e
[CAS 98].
4.3 Aplicações
São várias as aplicações que podem ser desenvolvidas
mobilidade. Entre elas:
utilizando tecnologia de
• Recuperação de informações distribuídas - estas informações são recuperadas de
acordo com algum critério específico. O informação a ser recuperada pode ser
definida estaticamente ou dinâmicamente durante o processo de recuperação. Sendo
assim, um agente, por exemplo, pode ser encarregado de viajar pela rede, obtendo as
informações a serem recuperadas;
• Serviços avançados de telecomunicações - o suporte e o gerenciamento de serviços
como vídeo conferência, telemarketing, etc, requerem mecanismos de reconfiguração
dinâmica e customização do uso. O uso de mobilidade permite o desenvolvimento
destes serviços. Por exemplo, uma aplicação que gerencia a sinalização, o sinal e
apresentação de um serviço de vídeo conferência pode ser despachado pelos usuários
através de um agente;
• Controle e configuração de dispositivos remotos - a tecnologia de código móvel
pode ser usada para projetar e implementar componentes de monitoramento que estão
localizados nos dispositivos a serem monitorados e transmitir eventos que
representem a evolução do estado do dispositivo. O estudo de caso do gerenciamento
de uma rede é apresentado em [FUG 98];
38
• Gerenciamento de Workflow - o workflow define que atividades devem ser
carregadas para serem cumpridas em uma determinada tarefa bem como de que
maneira, onde e quando estas atividades envolvem cada parte. Código móvel pode
ser usado para prover suporte à mobilidade de atividades que encapsulem suas
definições e seu estado. Por exemplo, um componente móvel pode encapsular um
documento texto que suporta várias versões. O componente gerência a informação
sobre o estado do documento, que operações foram feitas, e qual o próximo passo
para revisão;
• Comércio Eletrônico - aplicações de comércio eletrônico permitem usuários
desenvolver aplicações comerciais através da rede. Uma transação pode envolver
negociação com entidades remotas e requisição de informações. Portanto, é desejável
que o componente móvel da aplicação sé forneça informações relevantes para o
negócio. Aplicações deste tipo podem ser implementadas com a tecnologia de
agentes móveis.
4.4 Conclusões
Este capítulo apresentou as tecnologias usadas para desenvolver sistemas que suportem
mobilidade, bem como as aplicações que podem ser desenvolvidas. Foram apresentadas
as linguagens Java, Obliq e Oz Distribuído. Estas foram apresentadas com o objetivo de
mostrar alternativas, a nível de linguagem, para o desenvolvimento de aplicações que
exploram mobilidade. O texto [THO 97] apresenta uma comparação de várias
linguagens que implementam código móvel.
Além disso, foi apresentado CORBA, Voyager, Aglets e Concordia. Estes podem ser
considerados middleware para o desenvolvimento de aplicações que permitem
mobilidade. É importante destacar o aspecto de contribuição de CORBA, já que ele por
si só não permite mobilidade. Como ele é usado para implementar objetos distribuídos,
vários conceitos de CORBA são usados em outros middleware para o desenvolvimento
de aplicações. Também foi apresentado alguns exemplos de aplicações onde à
mobilidade pode ser aplicada.
Este capítulo procurou também destacar, nas tecnologias, aspectos que permitissem
classifica-las conforme a proposta de [FUG 98], apresentada no capítulo 2.
Relembrando, esta proposta aborda uma estrutura conceitual para compreender código
móvel, apresentando 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. Tanto os
mecanismos quanto os paradigmas foram destacados nas tecnologias apresentadas neste
capítulo.
Pode-se concluir também as várias vantagens no desenvolvimento de sistemas que
permitem mobilidade. Destacam-se:
•
possibilidade de operações desconectadas, permitindo que a computação seja
realizada mesmo quando não se está conectado na rede;
•
diminuição do tráfego da rede, aproximando a entidade computacional do recurso;
39
•
possibilidade de coleta de estatísticas e dados sobre a rede e/ou funcionamento de
aplicações distribuídas;
•
personificação de uma transação ou cliente, permitindo que informações específicas
sejam coletadas.
Observando as várias vantagens e possibilidades de desenvolvimento de aplicações,
nota-se que elas estão mais de acordo com o desenvolvimento utilizando agentes
móveis, devido a suas características, já destacadas no capítulo 3. Por isto, a grande
maioria das tecnologias que permitem mobilidade suportam o desenvolvimento de
aplicações através de agentes móveis ou são especificamente para este tipo de aplicação.
O capítulo 5 apresenta uma comparação das diversas tecnologias apresentadas
relacionando-as aos conceitos e paradigmas apresentados no capítulo 2.
40
5 Análise Comparativa das Tecnologias que Suportam
Mobilidade
Este capítulo apresenta uma análise comparativa das tecnologias apresentadas no
Capítulo 4, tendo como base a proposta de organização da área de mobilidade
apresentada no texto [FUG 98], descrita no capítulo 2.
A análise será dividida em duas tabelas que comparam aspectos de mobilidade. A
primeira (Tabela 1), compara algumas ferramentas que permitem implementar
ambientes para explorar mobilidade. A segunda, Tabela 2, faz comparações ambientes
que permitem desenvolver aplicações com mobilidade.
5.1 Análise comparativa das ferramentas
TABELA 1 - Ferramentas para suporte à mobilidade
Ferramentas
Características
Entidade computacional base objeto
Java
Obliq OZ dist. CORBA
X
X
X
X
Permite Objetos Distribuídos
X
X
X
X
Permite implementar mobilidade
X
X
X
Mobilidade através de objetos móveis
X
X
X
X
X
X
X
X
X
X
X
Entidade computacional base agente
Mobilidade através de agentes móveis
Explora mobilidade forte
Explora mobilidade fraca
X
Paradigma de Avaliação Remota
Paradigma de Código em Demanda
X
X
Paradigma de Agentes Móveis
Possui ambiente computacional
X
Mecanismos de serialização de objetos
X
Mecanismos de segurança
X
X
41
Com relação a Tabela 1, observa-se que todas as ferramentas tem como entidade
computacional base o objeto. Mesmo que permitam implementar agentes, a concepção
base é o objeto.
Todas as ferramentas permitem o desenvolvimento de aplicações usando objetos
distribuídos, mas somente Java, Obliq e Oz Distribuído permitem implementar algum
tipo de mobilidade, através de objetos móveis. CORBA não suporta em sua essência
mobilidade, embora tenha servido de inspiração para várias outras tecnologias que
suportam mobilidade. Um exemplo disto é o fato de Voyager suportar integração com
CORBA, além de ter em sua implementação uma base ORB.
Quanto ao tipo de mobilidade, Java explora mobilidade fraca, do tipo autônoma, pois
permite que os programas sejam carregados dinâmicamente pela rede, através do
ClassLoader. Já Obliq e OZ Distribuído permitem mobilidade forte. 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. Por outro lado, OZ
suporta mobilidade forte através da migração do tipo proativa, onde a unidade migrante
determina quando migrar. CORBA, como "não permite" mobilidade, não pode ser
classificada.
Quanto aos paradigmas suportados, Java suporta Código em Demanda, sendo que
Obliq, OZ Distribuído e CORBA suportam o paradigma de Avaliação Remota. Um
exemplo de Código em Demanda na linguagem Java é o Applet, pois este é buscado em
um site remoto para ser executado localmente. Em Obliq, o conhecimento vai para onde
está o recurso e depois retorna ao site requisitante. Já em OZ, a construção do grafo da
linguagem e do grafo de distribuição permitem ligações dinâmicas com o proxy, o
gerenciador e o content-edge.
Para explorar mobilidade, uma ferramenta deve possuir um ambiente computacional que
de suporte para que as entidades possam executar, além de permitir segurança. 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. O ambiente
computacional de Obliq é representado na sua máquina de execução. Já em OZ, seu
ambiente computacional é a Oz Virtual Machine que, como em Java, é portável,
podendo executar tanto em Unix como em Windows.
Todas as ferramentas oferecem algum tipo de segurança. Em Java, a segurança foi
preocupação desde a sua criação, garantindo que regras de acesso sejam sempre
respeitadas. Muitos recursos que requerem controle de acesso dinâmico são controlados
por um monitor chamado SecurityManager. Em Obliq, a segurança é garantida pelo
escopo léxico da linguagem que oculta valores chamados externamente. Além disso, o
sistema de execução assegura que o escopo seja cumprido. OZ tem um modelo simples
para tolerância a falhas, suportando somente falha no site, não suportando falha na rede.
42
TABELA 2 - Ambientes para explorar mobilidade
Ambientes
Características
Voyager Aglet Concordia
Entidade computacional base objeto
X
Entidade computacional base agente
X
X
X
Possui ambiente computacional
X
X
X
Suporta desenvolvimento em Java
X
X
X
Permite implementar mobilidade
X
X
X
Mobilidade através de objetos móveis
X
Mobilidade através de agentes móveis
X
X
X
Explora mobilidade forte
X
X
Explora mobilidade fraca
X
Paradigma de Avaliação Remota
X
Paradigma de Código em Demanda
X
Paradigma de Agentes Móveis
X
X
X
Mecanismos de serialização de objetos
X
X
X
Mecanismos de transporte e interação de agentes
X
X
X
X
Mecanismos para controle de prioridade
X
Permite implementar persistência
X
Mecanismos de segurança
X
X
X
X
A Tabela 2 compara ambientes que permitem o desenvolvimento de aplicações que
suportam mobilidade. Observando a Tabela, nota-se que Voyager tem um ambiente bem
mais completo que Aglet e Concordia.
Quanto a entidade computacional base, somente Voyager suporta objetos e agentes
móveis, pois neste ambiente, um agente é considerado um objeto, mas com autonomia.
Aglet e Concordia suportam somente agentes móveis.
Todos os ambientes possuem um ambiente computacional. Este fato é natural, pois para
dar suporte a execução das entidades computacionais distribuídas, mesmo que não
suporte mobilidade, cada máquina envolvida na distribuição deve suportar o ambiente
computacional necessário para que as entidades possam ser executadas. Um exemplo é a
máquina virtual Java. Para que um programa Java execute, é necessário que a máquina
virtual esteja presente. A questão do ambiente computacional é essencial para permitir
43
mobilidade. O que pode ser uma limitação, pois a entidade computacional só pode
mover-se para uma máquina onde o ambiente esteja presente ou que possa ser
inicializado.
Uma questão interessante, é que todos os ambientes suportam desenvolvimento em Java
(até porque são desenvolvidos em Java). Isto vem destacar o papel de Java como
linguagem principal para implementar mobilidade. O artigo [THO 97] destaca que Java
é a linguagem mais importante para desenvolvimento de aplicações que suportem
mobilidade, por ser portável e segura. Neste artigo encontra-se a descrição de algumas
linguagens para comparações quanto à mobilidade. Java é a linguagem que mereceu
maior atenção quanto a descrição e comparação.
Todos os ambientes permitem implementar mobilidade. Voyager suporta mobilidade
fraca e forte. A primeira é caracterizada, assim como Java, pela capacidade de carregar
classes para dentro de uma máquina virtual em tempo de execução. Sendo assim, o
código para uma determinada tarefa pode ser carregado a medida que for necessário para
a computação. À mobilidade forte é caracterizada pelo suporte a agentes móveis, pois
eles devem levar consigo sua “consciência”, isto é, ocorre uma espécie de migração,
embora eles possam construir esta “consciência” durante seu tempo de vida carregando
classes em tempo de execução. Aglet suporta mobilidade forte através de migração, pois
o envio de um Aglet tira ele de um contexto e o coloca em outro. Já Concordia permite
uma mobilidade fraca do tipo autônoma, semelhante a Java, pois permite que os
programas sejam carregados dinâmicamente pela rede, isto é, durante a viagem de um
agente através da rede, seu byte code e byte code de alguns objetos são carregados
através da classe ClassLoader.
Quanto aos paradigmas, Voyager suporta todos os tipos de paradigmas estudados, isto
é, Código em Demanda, Avaliação Remota e Agentes Móveis. O primeiro paradigma é
caracterizado pelo fato de Voyager permitir criar instâncias remotas de uma classe,
sendo que se o código original da classe para a instância remota não existir no programa
destino, Voyager carrega automaticamente o código da classe original para este. A
Avaliação Remota é caracterizada em Voyager porque este permite que os objetos
movam-se para onde está o recurso. O paradigma de Agentes Móveis é caracterizado
pelo fato de Voyager suportar agentes móveis. Como Aglet e Concordia suportam
somente agentes móveis, permitem desenvolver aplicações através do paradigma de
Agentes Móveis.
Voyager, Aglet e Concordia contém mecanismos de segurança. Como todos são
baseados em Java, herdam as características de segurança e portabilidade de Java, além
de mecanismos específicos de cada ambiente. Em Voyager a segurança é mantida
através do Voyager Security Manager, que restringe as operações de objetos estranhos
dentro do ambiente. Em Aglet, a segurança é mantida através do modelo de segurança
Java, isto é, através do interpretador e da máquina virtual Java. Em Concordia, existe o
Gerenciador de Segurança que gerencia os recursos de proteção.
44
5.2 Conclusões
Este capítulo apresentou uma análise comparativa das tecnologias apresentadas neste
texto (Capítulo 4). Esta análise foi feita tendo como base a taxonomia apresentada no
texto [FUG 98], descrita no capítulo 2. A análise foi dividida em duas tabelas. A Tabela
1 procurou comparar aspectos de mobilidade em ferramentas que serviram como base
para implementação de ambientes que permitem explorar mobilidade. A Tabela 2
comparou aspectos de mobilidade nestes ambientes.
Na Tabela 1, foram comparadas as ferramentas Java, Obliq e Oz distribuído, que são
linguagens de programação, e CORBA. Procurou-se nestas estudar aspectos referentes a
entidade computacional base da ferramenta, suporte a objetos distribuídos, suporte a
implementação de mobilidade através de objetos e/ou agentes móveis, tipo de
mobilidade explorada (forte ou fraca), paradigma suportado (Avaliação Remota, Código
em Demanda e Agentes Móveis), ambiente computacional para suporte à computação e
mecanismos de segurança.
Na Tabela 2 foram comparados os ambientas Voyager, Aglet e Concordia. Comparou-se
aspectos considerados importantes (alguns semelhantes aos analisados quanto as
ferramentas) com relação a ambientes que suportam mobilidade, tais como entidade
computacional base, presença de ambiente computacional, suporte a desenvolvimento
em Java, mobilidade através de objetos e/ou agentes móveis, tipo de mobilidade,
paradigma suportado e mecanismos de segurança.
É 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 onde a sua
computação está sendo desenvolvida, pois a aplicação deve abstrair aspectos de
localização do usuário. Como a computação é distribuída através da rede, a integridade
desta computação deve ser preservada, portanto a segurança é um fator muito
importante.
Todos os aspectos, em cada Tabela, foram comentados e observados como ocorre nas
ferramentas/ambientes analisados. Pode-se concluir que entidade computacional base,
ambiente computacional, tipo de mobilidade e paradigma suportado são aspectos
importantes a serem levados em consideração na necessidade de escolha da
ferramenta/ambiente para desenvolvimento de aplicações que suportam mobilidade.
O capítulo 6 apresenta as conclusões do trabalho.
45
6 Conclusão
Este trabalho apresentou um estudo sobre mobilidade em sistemas distribuídos. Foi
apresentado que os estudos sobre mobilidade intensificaram-se com o uso cada vez
maior de aplicações que utilizam a Internet, podendo-se assim explorar mobilidade
através de redes heterogêneas, conectadas por diferentes links de comunicação e
distantes uma das outras. Estas aplicações, geralmente são construídas utilizando-se
objetos e/ou agentes. Sendo assim, no âmbito deste trabalho, um dos fatores principais
no desenvolvimento destas aplicações diz respeito à mobilidade destas entidades.
O Capítulo 2 apresentou os fundamentos que envolvem os estudos em mobilidade,
necessários para compreender o universo que envolve as aplicações que utilizam
mobilidade. O conceito de mobilidade ainda não é consenso entre a comunidade
científica, embora sejam unânimes em que a entidade envolvida na computação deve ter
o potencial de deslocar-se entre o sistema distribuído, podendo mover-se de um
ambiente computacional para outro. Além disso, o Capítulo apresentou uma taxionomia
proposta em [FUG 98], envolvendo conceitos e paradigmas, buscando a compreensão
das abordagens baseadas em código móvel.
O Capítulo 3 apresentou aspectos de mobilidade em sistemas distribuídos, orientação a
objetos, orientação a gentes e agentes móveis. 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. Sendo assim, a conclusão mais importante deste Capítulo é 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.
No Capítulo 4 foi apresentada algumas tecnologias usadas para desenvolver sistemas
que suportem mobilidade, procurando sempre destacar aspectos que permitissem
classificá-las bem como as aplicações que podem ser desenvolvidas. Foram
apresentadas as linguagens Java, Obliq e Oz Distribuído como ferramentas que
permitem implementar mobilidade. Além disso, foi apresentado CORBA destacando
seu aspecto de contribuição para área de mobilidade, onde vários de seus conceitos são
usados em outros middleware para o desenvolvimento de aplicações. Também foram
apresentados alguns exemplos de aplicações onde à mobilidade pode ser aplicada.
A maior contribuição do Capítulo 4 foi a identificação das várias vantagens no
desenvolvimento de sistemas que permitem mobilidade, tais como: possibilidade de
operações desconectadas; diminuição do tráfego da rede, aproximando a entidade
computacional do recurso; possibilidade de coleta de estatísticas e dados sobre a rede
e/ou funcionamento de aplicações distribuídas; personificação de uma transação ou
cliente, permitindo que informações específicas sejam coletadas. Através destas
vantagens, observou-se que elas podem ser alcançadas usando agentes móveis,
podendo-se concluir então a grande importância da mobilidade dos agentes, pois muitas
tecnologias que permitem mobilidade suportam o desenvolvimento de aplicações
através de agentes móveis ou são especificamente para este tipo de aplicação.
46
Finalmente, o Capítulo 5 apresentou uma análise comparativa das tecnologias
apresentadas no Capítulo 4. Esta análise foi feita tendo como base a taxonomia
apresentada no texto [FUG 98], descrita no capítulo 2. A análise foi dividida em duas
tabelas. A Tabela 1 procurou comparar aspectos de mobilidade em ferramentas que
serviram como base para implementação de ambientes que permitem explorar
mobilidade. Foram comparadas as ferramentas Java, Obliq e Oz Distribuído, que são
linguagens de programação, e CORBA. Na Tabela 2, foram comparados os ambientas
Voyager, Aglet e Concordia. Comparou-se aspectos considerados importantes (alguns
semelhantes aos analisados quanto as ferramentas) com relação a ambientes que
suportam mobilidade, tais como entidade computacional base, presença de ambiente
computacional, suporte a desenvolvimento em Java, mobilidade através de objetos e/ou
agentes móveis, tipo de mobilidade, paradigma suportado e mecanismos de segurança.
A principal contribuição deste capítulo foi a observação de características semelhantes
em ferramentas/ambientes que exploram mobilidade.
Pode-se concluir com este trabalho:
• os estudos em mobilidade são promissores e necessários, uma vez que as aplicações
distribuídas utilizam cada vez mais a Internet;
• o texto [FUG 98] procurou organizar a área de mobilidade, sendo que a taxonomia
apresentada não é dita como “completamente correta”, necessitando ainda muitos
estudos e revisões;
• a linguagem Java pode ser considerada como a principal linguagem para suporte à
mobilidade, uma vez que vários ambientes computacionais são baseados em Java,
como foi visto neste texto;
• para ser considerada uma ferramenta ou ambiente que permite implementar
mobilidade, a entidade computacional base deve ter o potencial de deslocar-se
através dos sistemas distribuídos;
• entre os ambientes Voyager, Aglet e Concordia, o primeiro é o mais completo de
todos, pois suporta todas as características analisados no Capítulo5, Tabela 2;
• características como suporte à mobilidade através de objetos e agentes móveis,
presença de ambiente computacional e mecanismos de segurança parecem ser
características desejadas em ambientes que permitem explorar mobilidade.
• para explorar mobilidade, é desejável que a tecnologia apresente características como
ambiente computacional, suporte a objetos e agentes, suporte a Java, suporte a
mobilidade forte e fraca, mecanismos de serialização de objetos, mecanismos de
segurança, mecanismos de transporte e interação das entidades base, mecanismos
para controle de prioridade e persistência.
Trabalhos futuros poderão aperfeiçoar os estudos referentes a ambientes que permitam
mobilidade, como a identificação de características que devem estar presentes nestes
ambientes para que à mobilidade possa ser aplicada de forma genérica, isto é, que o
ambiente suporte mobilidade independentemente do paradigma computacional
utilizado. Na verdade, o Oz Distribuído seria um precursor desta forma de exploração
de mobilidade.
47
Bibliografia
[AMA 97]
AMANDI, Anília. Programação de Agentes orientada a Objetos.
Porto Alegre: CPGCC da UFRGS, 1997. 208p. Tese de
Doutorado.
[BAR 98]
BARBOSA, Jorge L. V. Paradigmas de desenvolvimento de
Sistemas Computacionais. Porto Alegre: CPGCC - II - UFRGS,
1998. 49p. Trabalho Individual II.
[BAU 97]
BAUMANN, J.; HOHL, F.; et al. Communication concepts for
mobile agent systems. First International Workshop on Mobile
Agents. Proceedings... Berlin, Germany, April, 1997.
[CAS 98]
CASTILLO, A.; KAWAGUCHI, M. et al. Concordia as Enabling
technology for cooperative Information Gathering.
Mitsubishi Eletric ITA, USA, 1998.
[CAR 97]
CARZANIGA, A.; PICCO, G.; VIGNA, G. Designing distributed
applications with a mobile code paradigm. 19th International
Conference on Software Engineering. Proceedings... Boston,
may 1997.
[CAR 95]
CARDELLI, L. A Language with Distributed Scope. Proceedings...
pág. 286-297. ACM Press, 1997. Disponível em
http://www.research.digital.com/SRC/personal/luca_cardelli/obliq/
[CUG 96]
CUGOLA, G.; GHEZZI, C.; PICCO, G. P.;VIGNA, G. Analyzing
Mobile Code Languagens. Mobile Object Systems. Second
Internationa Workshop, MOS’96. Proceedings... Linz, Austria,
july 1996. Lecture Notes.
[CHE 96]
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.
[DÖM 97]
DÖMEL, P.; LINGNAU, A.; DROBNIK, O. Mobile Agent
Interaction in Heterogeneous Environments. Mobile Object
Systems.
Second
Internationa
Workshop,
MOS’96.
Proceedings... Linz, Austria, july 1996. Lecture Notes.
[FIN 94]
FININ, T.; FRITZON, R.; et al. KQML as na Agente
Communication Language. Third International Conference on
Information and Knowledge Managemente (CIKM’94).
Proceedings... ACM Press, November, 1994.
[FLE 98]
FLEISCHHAUER, L. Agentes. agosto, 1998. Disponível em
http://www.eps.ufsc.br/disserta97/amaral/cap3.htm
48
[FUG 98]
FUGGETTA, A.; PICCO, G. P.; VIGNA, G. Understanding Code
Mobily. IEEE Transactions on Software Engineering. Vol.24,
num. 5, May 1998.
[GLA 98]
GLASS, Graham. ObjectSpace Voyager - The Agente ORB for Java.
Worldwide Computing and its Applications (WWCA’98).
Second International Conference. Proceedings... Tsukuba,
Japan, march, 1998.
[IBM 98]
Industrial and Business Machine corp. The Aglet Homepage.
Disponível em http://www.trl.ibm.co.jp/aglets/
[KNA 96]
KNABE, F.; Na Overview of mobile agente programming. Fifth
LOMAPS workshop on Analysis and Verification of Multiple
Agent Languages. Proceedings... Stockholm, Sweden, june
1996. Lecture Notes
[LAN 97]
LANGE, Danny; OSHIMA, Mitsuru; et al. Aglets: programming
Mobile Agents in Java. Worldwide Computing and its
Applications
(WWCA’97).
International
Conference.
Proceedings... Tsukuba, Japan, march, 1997.
[OBJ 98]
ObjectSpace Voyager Core Tecnology
http://www.objectspace.com
2.0
Disponível
em
[OBJ 97]
ObjectSpace Voyager Core Tecnology 1.0.
http://www.objectspace.com
Disponível
em
[OMG 95]
Object
Management
http://www.omg.org/corba/
[ORF 96]
R. Orfali, D. Hankey, J. Edwards, The Essential Distributeds
Objects Survival Guide, John Wiley & Sons, Inc.1996.
[OSH 98]
OSHIMA, M. ; LANGE, D. Mobile Agentes with Java: The Aglet
API. Disponível em
[ROY 97]
ROY, Peter et al. Mobile Objects in Distributed Oz. ACM
Transactions on Programming Languages and Systems.
Proceedings... New York, v.19, n.5, p.804-851, september
1997.
[ROY 98]
ROY, Peter. et al. Three moves are not as bad as fire. January,
1998. Tecnical Report.
[RUM 96]
RUMBAUGH, James; et al.; Modelagem e Projetos baseados em
Objetos. Editora Campus, Rio de Janeiro, 1996.
[SUN 96]
Sun Microsystems. The Source for Java tecnology. Disponível em
http://java.sun.com/
[THO 97]
THORN, T. Programming Languages for Mobile Code. INRIA
Tecnical Report 3134, France, Mar 1997
Group.
Disponível
em
49
[WON 97]
WONG, D.; PACIOREK, N.; WALSH, T.; et al. Concordia: na
Infrastructure for Collaborating Mobile Agents. First
International Workshop on Mobile Agents. Proceedings...
Berlin, Germany, April, 1997.