UNIVERSIDADE DO VALE DO RIO DOS SINOS

CINCIAS EXATAS E TECNOLGICAS

PROGRAMA INTERDISCIPLINAR DE PS-GRADUAO EM
COMPUTAO APLICADA

HoloGo : Um Modelo de Mobilidade de Cdigo

Orientado ao Holoparadigma

por
Gustavo Lermen

Prof. Dr. Jorge Luis Victria Barbosa

Orientador

Dissertao submetida avaliao

como requisito parcial para a obteno do grau de
Mestre em Computao Aplicada

So Leopoldo, janeiro de 2007

Ficha catalogrfica elaborada pela Biblioteca da

Universidade do Vale do Rio dos Sinos

L616h

Lermen, Gustavo
HoloGo: um modelo de mobilidade de cdigo orientado ao
holoparadigma / por Gustavo Lermen. -- 2007.
91 f. : il. ; 30cm.

Dissertao (mestrado) -- Universidade do Vale do Rio

dos Sinos,
Programa de Ps-Graduao em Computao Aplicada,
2007.
Orientao: Prof. Dr. Jorge Luis Victria Barbosa,
Cincias Exatas
e Tecnolgicas.
1. Computao mvel. 2. Mobilidade forte de cdigo. 3. Linguagem
de programao. 4. Holoparadigma. I. Ttulo.

CDU 004.75.057.5

Catalogao na Publicao:
Bibliotecria Eliete Mari Doncato Brasil - CRB 10/1184

Todas as coisas so difceis antes de se tornarem fceis

John Norley

Agradecimentos
Ao meu orientador Prof. Dr. Jorge Lus Victria Barbosa pela motivao e empenho
durante o curso.
Aos meus pais, Aloir Lermen e Lisete Lermen, pela pacincia, apoio e dedicao
que foram imprescindveis durante o andamento do curso.
A minha namorada Luciana Ribeiro Freitas, pelo amor, amizade e pacincia nos
momentos em que estive ausente.
Aos meus amigos e colegas do Mobilab: Ccero Raupp Rolim (Baboo), Darci Levis,
Slon Rabello, Rodrigo Hahn, Renato Costa e Fabiane Cristine Dillemburg.
A todos meus colegas de curso e a todos, que de alguma forma, contriburam para a
realizao deste trabalho.
A Hewlet-Packard Computdores (HP) pela bolsa de mestrado e incentivo financeiro.

Resumo
A rpida popularizao de dispositivos computacionais cada vez mais poderosos
est trazendo a computao mvel para um grande nmero de pessoas. Na medida em que
os dispositivos ganham mais poder computacional, diferentes aplicaes podem ser
desenvolvidas de modo a atender as necessidades de um nmero cada vez maior de
usurios. Esta evoluo, entretanto, no livre de desafios. Com o aumento do nmero de
usurios, a demanda por customizao torna-se uma questo chave. Entre as solues que
oferecem a customizao encontra-se a mobilidade de cdigo. Neste sentido esta
dissertao apresenta um modelo de mobilidade forte de cdigo orientado ao
Holoparadigma. At ento somente a mobilidade lgica era suportada, estando
mobilidade de cdigo apenas na especificao. Este modelo chamado HoloGo e foi
desenvolvido tendo como base a HoloVM, uma mquina virtual com suporte a blackboards
e programao concorrente. A validao deste modelo ocorreu atravs da implementao
de um prottipo que foi utilizado no desenvolvimento de aplicaes que utilizam
mobilidade de cdigo. Neste contexto a principal contribuio deste trabalho consiste da
adio da funcionalidade de mobilidade forte de cdigo ao ambiente do Holoparadigma.

Palavras chave: Mobilidade forte de cdigo, linguagens de programao, mquinas

virtuais, computao mvel.

6
TITLE: HOLOGO : A STRONG CODE MOBILITY MODEL FOCUSED ON THE
HOLOPARADIGM

Abstract
The rapid popularization of increasingly powerful computational devices is setting
the mobile computing into daily life of a great number of people. As devices evolve along
with its computational power, many applications can be developed in order to accomplish
the different needs of a growing number of users. This evolution, however, it is not free of
challenges. As the number of users increase, the need of customization becomes a major
concern. Among the solutions that offer customization to software applications is code
mobility. In this way, this dissertation presents a strong code mobility model focused in the
Holoparadigm. Until now only logical mobility was provided, being the code mobility only
in the specification. This model is called HoloGo and was developed on top of HoloVM, a
virtual machine with blackboards and concurrent programming support. HoloGo was
validated through the implementation of a prototype used in the development of
applications that use code mobility. In this context, the main contribution of this work
comprises the addition of strong code mobility support in the Holoparadigm environment.

Keywords: Strong code mobility, programming languages, virtual machines, mobile

computing.

Sumrio
1.Introduo ...........................................................................................................................................12

1.1 Contextualizao............................................................................................................. 12
1.2 Definio do Problema................................................................................................... 13
1.3 Objetivos ......................................................................................................................... 14
1.4 Metodologia .................................................................................................................... 15
1.5 Organizao da Dissertao ........................................................................................... 15
2.Mobilidade de Cdigo........................................................................................................................16

2.1 Framework para Mobilidade de Cdigo ....................................................................... 17

2.2 Paradigmas de Projeto de Mobilidade de Cdigo......................................................... 23
2.2.1 Remote Evaluation (REV) ...................................................................................... 25
2.2.2 Code on Demand (COD)......................................................................................... 25
2.2.3 Mobile Agent (MA) ................................................................................................. 25
2.2.4 Discusso ................................................................................................................. 26
2.3 Sistemas de Cdigo Mvel............................................................................................. 27
2.3.1 Voyager .................................................................................................................... 28
2.3.2 Java........................................................................................................................... 28
2.3.3 Java Aglets ............................................................................................................... 29
2.3.4 JavaGo...................................................................................................................... 30
2.3.5 JADE ........................................................................................................................ 30
2.3.6 Jini ............................................................................................................................ 31
2.3.7 Code ....................................................................................................................... 31
2.3.8 Obliq......................................................................................................................... 32
2.3.9 .NET ......................................................................................................................... 33
2.3.10 LIME ...................................................................................................................... 34
2.4 Sistemas Ubquos............................................................................................................ 35
2.4.1 Aura .......................................................................................................................... 35
2.4.2 One.World................................................................................................................ 37
2.4.3 Mobile Gaia ............................................................................................................. 39
2.4.4 ISAM........................................................................................................................ 41
2.5 Concluso ........................................................................................................................ 43
3.Holoparadigma ...................................................................................................................................45

3.1 Conceitos Bsicos........................................................................................................... 45

3.2 HoloVM........................................................................................................................... 49
3.3 Modelo de Execuo Distribuda................................................................................... 50
3.3.1 History Server.......................................................................................................... 50
3.3.2 Holo Naming System .............................................................................................. 52
3.4 Concluso ........................................................................................................................ 54
4.HoloGo Mobilidade de Cdigo na HoloVM................................................................................56

4.1 Modelo Proposto............................................................................................................. 56

4.2 Modificaes Realizadas na HoloVM........................................................................... 61
4.3 Concluso ........................................................................................................................ 65
5.Aspectos de Implementao..............................................................................................................67

5.1 Descrio do Prottipo ................................................................................................... 67

8
5.2 Funcionalidades Introduzidas no Ambiente.................................................................. 69
5.3 Resultados Experimentais .............................................................................................. 71
5.4 Concluso ........................................................................................................................ 73
6.Aplicaes ............................................................................................................................................75

6.1 Ganho de Desempenho................................................................................................... 75

6.2 Gerenciamento de Rede.................................................................................................. 77
6.3 Computao Ubqua ....................................................................................................... 80
6.4 Concluso ........................................................................................................................ 83
7.Consideraes Finais..........................................................................................................................84
Referncias Bibliogrficas....................................................................................................................87

Lista de Abreviaturas
ANSI:
API:
COD:
CLR
DNS:
DSM:
FIPA:
GPS:
HNS:
HOLO:
HS:
HVM:
IP:
ISAM:
JADE:
JVM:
KS:
MCS:
MA:
NAT:
PDA:
PHOLO:
RFID:
REV:
SELIC:
SQL:
SNMP:
TDS:
TCP:
UDP:
URI:
XML:

American National Standards Institute

Application Programming Interface
Code on Demand
Common Language Runtime
Domain Name System.
Distributed Shared Memory
Foundation for Intelligent Physical Agents
Global Positioning System
Holo Naming System
Holoparadigma
History Server
Holo Virtual Machine
Internet Protocol
Infra-estrutura de Suporte a Aplicaes Mveis Pervasivas
Java Agent Development Framework
Java Virtual Machine
Knowledge Source
Mobile Code System
Mobile Agent
Network Address Translator
Personal Digital Assistant
Pervasive Holoparadigm
Radio Frequency Identification
Remote Evaluation
Servidor de Localizao e Informao de Contexto
Structured Query Language
Simple Network Management Protocol
True Distributed System
Transmission Control Protocol
User Datagram Protocol
Uniform Resource Identifier
Extended Markup Language

10

Lista de Figuras
Figura 2.1 - Modelo de um sistema de cdigo mvel............................................................. 18
Figura 2.2 - Estrutura interna de uma unidade de execuo................................................... 19
Figura 2.3 - Taxonomia da Mobilidade de Cdigo................................................................. 21
Figura 2.4 - Arquitetura do Aura.............................................................................................. 37
Figura 2.5 - Arquitetura do one.world ..................................................................................... 38
Figura 2.6 - Arquitetura do Mobile Gaia................................................................................. 41
Figura 2.7 - Arquitetura do ISAM............................................................................................ 42
Figura 3.1 - Tipos de Entes....................................................................................................... 46
Figura 3.2 - Mobilidade no Holoparadigma ............................................................................ 47
Figura 3.3 - rvore de Entes (HoloTree)................................................................................. 48
Figura 3.4 - Funcionamento do HS.......................................................................................... 51
Figura 3.5 - Representao do funcionamento do HNS ......................................................... 54
Figura 4.1 - Sistema de Cdigo Mvel tendo a HoloVM como ambiente computacional... 56
Figura 4.2 - Estrutura interna de um ente. ............................................................................... 57
Figura 4.3 - Passos realizados no momento de uma mobilidade de cdigo.......................... 58
Figura 4.4 - Cpia da Constant Pool em uma mobilidade de cdigo .................................... 60
Figura 4.5 - Mobilidade de cdigo em um ente composto ..................................................... 61
Figura 4.6 - Diagrama descrevendo as principais classes envolvidas ................................... 62
Figura 4.7 - Formato da mensagem utilizada para enviar um ente ........................................ 62
Figura 4.8 - Cdigo original da instruo move ...................................................................... 63
Figura 4.9 - Cdigo da instruo move modificado ................................................................ 64
Figura 5.1 - Diagrama de seqncia de uma mobilidade de cdigo ...................................... 68
Figura 5.2 - Cdigo fonte de um ente holder .......................................................................... 69
Figura 5.3 - Configurao utilizada no experimento .............................................................. 72
Figura 5.4 - Tempo de envio .................................................................................................... 73
Figura 6.1 - Trecho de cdigo fonte da aplicao focada em ganho de desempenho........... 75
Figura 6.2 - Tempo de execuo X Nmero de mquinas ..................................................... 77
Figura 6.3 - Cdigo fonte da aplicao de gerenciamento ..................................................... 78
Figura 6.4 - Ambiente utilizado para testar a aplicao de gerenciamento de rede.............. 79
Figura 6.5 - Integrao com servidor de localizao SELIC.................................................. 81
Figura 6.6 - Cdigo fonte da aplicao ubqua ....................................................................... 82

Lista de Tabelas
Tabela 2.1 - Resumo dos paradigmas de desenvolvimento de mobilidade de cdigo.......... 27
Tabela 5.1 - Comandos adicionados Hololinguagem .......................................................... 70
Tabela 5.2 - Tempos de serializao e deserializao ............................................................ 71
Tabela 5.3 - Tempo de envio de um ente................................................................................. 72
Tabela 6.1 - Tempo de execuo X Nmero de mquinas..................................................... 77
Tabela 6.2 - Contedo do vetor aps o ente percorrer o ambiente ........................................ 80

1. Introduo
1.1 Contextualizao
Atualmente a popularizao de dispositivos computacionais cada vez menores e
com maior poder computacional est fazendo com que a computao mvel, antes apenas
acessvel a poucas pessoas, esteja se tornando bastante popular. Dispositivos como PDAs
(Personnal Digital Assistant), computadores portteis, celulares esto tornando-se cada vez
mais poderosos computacionalmente ao mesmo tempo em que se tornam acessveis a um
maior nmero de pessoas tornando possvel que a computao atue em cada vez mais reas
a um custo cada vez menor. Aliado a este avano dos dispositivos, tecnologias de software
emergem de modo a aproveitar as novas possibilidades motivadas por este avano. Novos
protocolos de rede sem fio, como Bluetooth [9] e o IEEE 802.11b/g [46] fazem com que
estes dispositivos possam conectar-se de modo a aumentar ainda mais suas funcionalidades.
Esta disseminao da computao, entretanto, no est livre de desafios. Na medida
em que os dispositivos evoluem, os desenvolvedores de software devem adaptar-se a esta
nova realidade atravs do desenvolvimento de aplicaes que venham a explorar estas
novas tecnologias ao mesmo tempo suprindo as necessidades cada vez mais especficas de
um nmero cada vez maior de usurios. medida que o nmero de usurios cresce,
questes referentes escalabilidade tornam-se uma preocupao. Uma das propostas que
vem ao encontro da soluo deste problema a mobilidade de cdigo. A mobilidade de
cdigo propicia o desenvolvimento de programas mveis que tem a habilidade de trocar de
dispositivos durante sua execuo de modo a suprir a necessidade de uma grande gama de
aplicaes.
A mobilidade de cdigo no um conceito novo. O termo cdigo mvel tem sido
utilizado na literatura de acordo com as seguintes definies [42]:
O termo cdigo mvel pode ser utilizado para descrever qualquer programa
que pode ser enviado sem modificaes para uma coleo heterognea de
dispositivos e executado com uma semntica semelhante em cada um deles;

13
Cdigo mvel pode ser visto como uma abordagem onde programas so
considerados documentos e consequentemente possam ser acessados,
transmitidos e executados como qualquer outro documento;
Agentes mveis so objetos que contm cdigo e que podem ser
transmitidos entre dispositivos participantes de uma arquitetura distribuda.
Neste trabalho, cdigo mvel ser visto como um software que capaz de viajar por
uma rede heterognea e executar automaticamente no dispositivo de destino. Esta
caracterizao genrica o suficiente para englobar a maioria das utilizaes de cdigo
mvel e, ao mesmo tempo precisa o suficiente para destacar as principais caractersticas
desta tcnica. Ela exclui, por exemplo, situaes onde um cdigo carregado de um disco
compartilhado ou obtido manualmente atravs da Internet.

1.2 Definio do Problema

Um ambiente altamente dinmico composto por dispositivos mveis demanda que
aplicaes sejam adaptativas por natureza. Neste sentido torna-se interessante a obteno de
novos elementos lgicos em tempo de execuo, obtendo de maneira dinmica as
funcionalidades para atender as demandas do ambiente. Estas aplicaes devem ser
sensveis ao contexto, ou seja, elas devem adaptar-se as constantes mudanas deste tipo de
ambiente de uma maneira transparente para o usurio final.
Outro problema inerente a este tipo de ambiente refere-se heterogeneidade do
mesmo. Uma grande variedade de dispositivos mveis interage utilizando diferentes tipos
de rede de comunicao. Conexes temporrias entre dispositivos e perdas repentinas de
conexo so uma realidade em um ambiente mvel. Uma aplicao mvel deve aproveitar
os recursos disponveis neste ambiente da melhor forma possvel alm de lidar com as
adversidades impostas. Neste sentido a forma de composio e programao da aplicao
torna-se uma questo importante. A maioria das solues existentes utiliza-se de
paradigmas j consagrados para implementar suas solues. Entretanto estes paradigmas
foram concebidos com aplicaes que executam em um nico nodo em mente. Solues
utilizando estes paradigmas no podem ser diretamente aplicadas em um ambiente

14
altamente heterogneo e dinmico. Neste trabalho esta questo abordada atravs da
utilizao de mobilidade de cdigo.
Atravs da utilizao de mobilidade de cdigo uma forma mais flexvel de sistema
distribudo obtida, onde a localizao das computaes no precisa ser conhecida de
antemo.

Dentre as principais vantagens deste modelo destacam-se a eficincia,

simplicidade e flexibilidade [42].

Estas questes motivam o desenvolvimento de novas abstraes para programao
bem como a implementao do respectivo suporte. Neste trabalho uma abstrao ser
proposta atravs da utilizao do Holoparadigma [4] (de maneira abreviada Holo) e
materializada atravs da implementao na HoloVM [23], que a mquina virtual que
executa byte code Holo. Atualmente o Holoparadigma oferece uma abstrao intuitiva para
a modelagem de ambientes mveis. Atravs de sua utilizao possvel criar uma
modelagem mais fiel do mundo real. Utilizando diretivas de mobilidade do prprio
paradigma possvel manter o ambiente coerente com o mundo real. Esta abordagem
aplica-se tanto para ambientes fixos (prdios, salas, computadores, etc.) quanto para
elementos mveis (laptops, PDAs, celulares, etc.). At ento, o ambiente de execuo
utilizado no suportava a mobilidade de cdigo para o desenvolvimento de aplicaes,
suprimindo assim um grande potencial do Holoparadigma.

1.3 Objetivos
Este trabalho tem como objetivo especificar, implementar e validar um sistema de
mobilidade de cdigo para o Holoparadigma. Com este objetivo geral em mente, os
seguintes objetivos especficos podem ser citados:
Especificar e implementar um modelo de mobilidade de cdigo;
Introduzir este modelo no Holoparadigma, atravs de sua integrao com a
HoloVM e com o ambiente de execuo distribudo;
Validar este modelo atravs da implementao de aplicaes sintticas que
utilizem mobilidade de cdigo.

15

1.4 Metodologia
Visando cumprir os objetivos propostos uma metodologia foi definida para o
cumprimento das tarefas desta proposta. Inicialmente um estudo de sistemas de cdigo
mvel foi realizado de modo a identificar suas principais caractersticas. Este estudo visou
verificar como a mobilidade de cdigo disponibilizada por estes sistemas.
Aps a realizao deste estudo foi realizado um levantamento dos requisitos
necessrios para a implementao de mobilidade de cdigo no Holoparadigma. Esta etapa
englobou um estudo da HoloVM de modo a identificar que partes dela necessitam ser
modificadas. A fase seguinte compreendeu a implementao de um prottipo inicial que
fornece mobilidade de cdigo para programas que executam byte code Holo. Tendo este
prottipo implementado, foram desenvolvidas aplicaes sintticas com o objetivo de
validar o modelo proposto e tambm identificar que pontos devem ser melhorados.

1.5 Organizao da Dissertao

O restante deste trabalho est estruturado da seguinte forma. No captulo seguinte
ser apresentado o conceito de mobilidade de cdigo atravs da descrio de um framework
metodolgico e terminolgico juntamente com paradigmas de desenvolvimento de software
que utilizam mobilidade de cdigo. Ainda neste captulo sero apresentados sistemas que
utilizam mobilidade de cdigo. No Captulo 3 ser apresentado o Holoparadigma,
juntamente com a HoloVM e o ambiente de execuo distribudo. O modelo proposto
apresentado no Captulo 4. O Captulo 5 apresenta aspectos especficos de implementao
juntamente com resultados iniciais. Aplicaes desenvolvidas, e que utilizam o modelo de
mobilidade forte de cdigo desenvolvido so apresentadas no Captulo 6. A concluso
juntamente com trabalhos futuros apresentada no Captulo 7.

16

2. Mobilidade de Cdigo
Atualmente as redes de computadores esto evoluindo de maneira rpida e esta
evoluo acontece em diferentes frentes. Alm do tamanho das redes que cresce
rapidamente, por exemplo, a Internet, isso tambm acontece com a velocidade das
conexes. Este aumento no tamanho e desempenho das redes de computadores pode ser
visto como uma causa e tambm como um efeito de um importante fenmeno: as redes
esto se tornando ubquas [16], ou seja, alm de serem um recurso acessvel a um grande
nmero de pessoas, a conectividade disponibilizada por elas pode ser explorada
independente da localizao fsica do usurio. Neste cenrio o usurio pode movimentar-se
por diferentes locais e ainda manter-se conectado, possibilitando que uma nova gama de
aplicaes seja desenvolvida visando aproveitar este avano.
Esta evoluo, entretanto no livre de obstculos e novos problemas devem ser
resolvidos. Com este crescimento acelerado a escalabilidade torna-se uma preocupao.
Algoritmos propostos com pequenas redes em mente no podem ser aplicados diretamente
a uma rede de escala maior como a Internet. Outro problema surge das conexes sem fio.
Nestes ambientes o usurio livre para se locomover gerando uma mudana dinmica na
topologia da rede, o que pode ocasionar a perda temporria ou permanente da conexo.
Outra questo relevante que aparece neste cenrio a difuso de servios de rede para
grandes segmentos da sociedade. Esta difuso requer que os servios oferecidos possam ser
customizados, de modo a suprir as necessidades de diferentes usurios. Outra necessidade,
ocasionada pela mudana constante na infra-estrutura de comunicao subjacente, que as
redes sejam flexveis de modo a se adaptarem de maneira rpida e eficaz. Diversas
tentativas de resolver estes problemas baseiam-se em tecnologias bem estabelecidas. Estas
tecnologias so adaptadas a esta nova realidade visando fornecer customizao e
flexibilidade. Muitas destas tecnologias, como CORBA [35] utilizam o paradigma
cliente/servidor. Entretanto autores [21] [32] sugerem que uma abordagem utilizando
mobilidade de cdigo seja mais adequada a um ambiente desprovido de flexibilidade e
customizao como o descrito anteriormente. Neste trabalho um modelo que aborda a
mobilidade de cdigo proposto de modo a resolver este problema. Na prxima seo so

17
apresentados conceitos envolvendo mobilidade de cdigo que sero utilizados no restante
do trabalho.

2.1 Framework para Mobilidade de Cdigo

A mobilidade de cdigo no um conceito novo. Diversas tecnologias utilizam
implicitamente o conceito de mobilidade de cdigo. Dentre estas se pode citar o Postscript
[42], que uma linguagem de descrio de pginas que se destaca por ser uma linguagem
de programao baseada em pilha. Ao enviar um documento para uma impressora
Postscript, o que est sendo enviado um programa que descreve as pginas a serem
impressas. A impressora, ao receber o programa, executa-o de modo a realizar a impresso.
Este exemplo demonstra uma das principais motivaes da mobilidade de cdigo, pois a
descrio algortmica de uma imagem complexa, por exemplo, pode ser enviada de maneira
compacta e genrica para diversas impressoras, independente de sua resoluo ou esquema
de cores. Outra tecnologia que utiliza mobilidade de cdigo refere-se a banco de dados
[18]. O tamanho de uma base de dados pode tornar invivel a sua transmisso por inteiro
para uma estao cliente. Neste sentido, qualquer operao em uma base de dados deste
tipo deve ser comunicada e executada no servidor. Atualmente a maioria dos bancos de
dados comerciais suporta a linguagem SQL (Structured Query Language) para acesso a
bases de dados. Esta linguagem oferece uma notao compacta para expressar operaes
complexas em mltiplas relaes de uma base de dados.
Informalmente a mobilidade de cdigo pode ser definida como a modificao de
maneira dinmica da ligao de fragmentos de cdigo com o local onde eles executam
[21]. Devido a grande quantidade de pesquisas ocorrendo paralelamente a respeito de
mobilidade de cdigo, um framework metodolgico e terminolgico sugerido [21]. O
restante deste trabalho adota o conceito de Sistema de Cdigo Mvel (Mobile Code System
- MCS) [21]. Este modelo, apresentado na Figura 2.1, se diferencia de sistemas distribudos
tradicionais (True Distributed Systems TDS) por no fornecer a transparncia de
localizao, ou seja, o software executando ciente de sua localizao juntamente com a
localizao dos recursos que ele utiliza. O conceito de ambiente computacional
introduzido. O ambiente computacional pode ser visto como uma camada de software
executando acima do sistema operacional cuja responsabilidade gerenciar a execuo dos

18
componentes e tambm dos recursos que estes utilizam. Estes recursos podem estar
localizados no mesmo ambiente computacional ou em um ambiente remoto, sendo
acessados atravs da rede.

Figura 2.1 - Modelo de um sistema de cdigo mvel

Dentre as principais caractersticas destes sistemas destacam-se a escalabilidade e a

maior autonomia oferecida ao desenvolvedor. A escalabilidade ressaltada, pois neste
modelo a mobilidade de cdigo explorada em nvel de Internet. A autonomia ocorre, pois
de responsabilidade do programador definir quando a mobilidade ir ocorrer, ao contrrio
de sistemas distribudos tradicionais onde a mobilidade ocorre de maneira transparente ao
desenvolvedor.
Neste modelo cada ambiente computacional possui uma ou mais unidades de
execuo juntamente com recursos necessrios para a execuo. Uma unidade de execuo
pode ser vista como a representao de um fluxo de execuo como, por exemplo, um
processo Unix ou uma thread em um ambiente multithreaded. Os recursos podem estar
localizados no prprio ambiente computacional ou em um ambiente computacional
localizado em outro host. Um recurso localizado em um host remoto acessado atravs da
rede.
Cada unidade de execuo composta por um segmento de cdigo, um espao de
dados juntamente com o estado de execuo. A estrutura de uma unidade de execuo
descrita na Figura 2.2.

19

Figura 2.2 - Estrutura interna de uma unidade de execuo

Como mostrado na Figura 2.2, um recurso local a um ambiente computacional pode

ser compartilhado entre unidades de execuo. Diferentes maneiras, apresentadas mais
adiante, so propostas para gerenciar os recursos utilizados por um ambiente
computacional.
Na literatura so apresentados dois tipos de mobilidade de cdigo. A mobilidade
forte e a mobilidade fraca [21] [32] [24]. Na mobilidade forte, o cdigo de uma unidade de
execuo movido juntamente com seu estado de execuo para um ambiente
computacional diferente. Na mobilidade fraca, somente o cdigo movido e, em alguns
casos, dados necessrios para inicializao da execuo no ambiente remoto so movidos
junto. O suporte mobilidade forte pode ocorrer atravs de duas abordagens: migrao e
clonagem remota. Na migrao a execuo em uma unidade de execuo interrompida,
seu estado de execuo armazenado juntamente com o cdigo e ento migrado para outro
ambiente computacional. Na abordagem que utiliza clonagem remota, a unidade de
execuo continua executando em seu ambiente computacional enquanto ela clonada para
outro ambiente computacional. Tanto a abordagem que utiliza migrao quanto a
abordagem que utiliza clonagem remota podem ser pr-ativas ou reativas. Em uma
abordagem pr-ativa, a prpria unidade de execuo que decide quando a migrao ou a
clonagem remota ir ocorrer. Contrastando com a abordagem pr-ativa, na abordagem
reativa a deciso de quando a migrao ou a clonagem remota ir ocorrer no feita pela
unidade de execuo. Nesta abordagem o que gera a mobilidade outra unidade de
execuo que geralmente possui algum tipo de relacionamento com a unidade de execuo

20
que contm o cdigo a ser movido. Um cenrio possvel para uma abordagem reativa seria
uma unidade de execuo atuando como uma entidade gerenciadora das demais unidades
de execuo.
Tanto a abordagem pr-ativa quanto a abordagem reativa podem executar a
mobilidade de cdigo de maneira sncrona ou assncrona. Em uma abordagem sncrona o
cdigo executado no momento de sua chegada ao ambiente de destino. Em uma
abordagem assncrona o cdigo pode vir a ser executado somente quando alguma condio
for satisfeita.
Mecanismos que suportam mobilidade de cdigo fraca possuem a capacidade de
transferir cdigo entre ambientes computacionais ligando o cdigo movido de maneira
dinmica no novo ambiente computacional ou fazendo com que o cdigo movido se torne o
segmento de cdigo do novo ambiente computacional. Tais mecanismos podem ser
classificados de acordo com a direo do cdigo sendo transferido, a natureza do cdigo
sendo movido, o tipo de sincronizao envolvido e o momento em que o cdigo movido
ser executado no ambiente computacional de destino. Quanto direo do cdigo sendo
transferido, uma unidade de execuo pode executar uma busca de cdigo ou executar o
envio de cdigo para outro ambiente computacional. O cdigo pode ainda ser transferido de
maneira isolada, neste caso instanciando uma nova unidade de execuo no ambiente de
destino, ou pode ser enviado apenas na forma de fragmento que ter que ser ligado para
uma execuo no ambiente computacional de destino. Estes mecanismos ainda podem ser
sncronos ou assncronos. Em uma abordagem sncrona a unidade de execuo que
requisita o cdigo suspende sua execuo at que o cdigo requisitado esteja disponvel.
Alternativamente, na abordagem assncrona, a unidade de execuo no suspende a
execuo.
Ao migrar de um ambiente computacional para outro, uma unidade de execuo
deve rearranjar seu espao de dados a fim de continuar sua execuo no ambiente
computacional de destino. Diferentes solues so propostas para realizar esta nova
configurao. Algumas envolvem a remoo da ligao com o recurso envolvido enquanto
outras envolvem a criao de uma referncia atravs da rede para o ambiente
computacional onde se encontra o recurso. Dependendo ainda do tipo do recurso, este pode

21
ser migrado juntamente com a unidade de execuo para o novo ambiente computacional.
Outra possibilidade ainda a remoo do recurso sendo utilizado caso nenhuma das
alternativas seja possvel de ser aplicada. A Figura 2.3 mostra na forma de uma taxonomia
os conceitos apresentados at agora.

Figura 2.3 - Taxonomia da Mobilidade de Cdigo [21]

A mobilidade de cdigo, embora no sendo um conceito novo, continua sendo

bastante utilizada em diversas reas. A crescente popularizao de dispositivos cada vez
menores e com maior poder computacional vem abrindo um leque de possibilidades em
termos de computao at pouco tempo atrs no imaginada.

Dentre as principais

utilizaes da mobilidade de cdigo, pode-se citar:

Distribuio de carga: uma unidade de execuo pode migrar de um
ambiente computacional que est sobrecarregado para um ambiente que
esteja ocioso visando um melhor aproveitamento;
Tolerncia falhas: uma unidade de execuo pode migrar de um ambiente
computacional que possa estar tendo problemas e continuar sua execuo em
um ambiente sem falhas;

22
Compartilhamento de recursos: mesmo no sendo disponibilizado em um
ambiente computacional, um recurso especfico pode ser aproveitado por
uma unidade de execuo atravs da migrao da mesma para um ambiente
computacional que possua o recurso requisitado. Como exemplo de recurso
especfico pode-se citar uma impressora ou uma base de dados;
Localidade no acesso aos dados: ao necessitar de um dado uma unidade de
execuo pode se mover para o ambiente computacional que possua o dado;
Computao mvel: uma unidade de execuo pode se mover de um
computador de mesa para um computador porttil como um notebook ou um
PDA. Este tipo de mobilidade se aplica a semntica siga-me da computao
ubqua [3]. Uma das formas de se obter um sistema ubquo atravs da
implementao de plataformas virtuais, como mquinas virtuais, que
possibilitem a mobilidade de cdigo. Esta mobilidade de cdigo tornaria
possvel que o cdigo seguisse o usurio para onde ele fosse;
Customizao de servios: diferentes usurios requerem diferentes tipos de
servios disponibilizados. Na medida em que o nmero de usurios cresce,
uma demanda maior por servios personalizados se faz necessria. Neste
sentido a mobilidade de cdigo pode atuar como um agente facilitador neste
processo;
Insero dinmica de novos protocolos de procura de hosts ou dispositivos:
dispositivos mveis, apesar de um poder computacional cada vez mais
elevado, muitas vezes possuem capacidades limitadas de armazenamento.
Neste sentido interessante que estes dispositivos possuam instalado
somente

os

componentes

extremamente

necessrios

para

seu

funcionamento. Ao necessitar de um novo componente o dispositivo o

obteria de maneira dinmica. Ao final de sua execuo o componente pode
inclusive descartar este componente liberando assim mais recursos para
outras aplicaes.

23

2.2 Paradigmas de Projeto de Mobilidade de Cdigo

Nesta seo sero apresentados paradigmas de desenvolvimento de aplicaes
distribudas que utilizam mobilidade de cdigo. Questes especficas de linguagens ou
tecnologias de mobilidade de cdigo sero abstradas. A inteno apresentar, em um nvel
alto de abstrao, questes referentes ao projeto destas aplicaes distribudas de modo a
oferecer diretivas que possam vir a ser utilizadas no desenvolvimento de aplicaes
distribudas que utilizem mobilidade de cdigo. Assim como os benefcios da orientao a
objeto como maior legibilidade e reutilizao podem ser aplicados utilizando-se uma
linguagem no orientada a objetos, os paradigmas apresentados nesta seo podem ser
aplicados independente da linguagem ou tecnologia de mobilidade de cdigo utilizada.
Na fase de projeto de uma aplicao distribuda, normalmente questes referentes
interao entre os componentes so consideradas independentes da localizao deles. A
localizao, nestes casos, tratada apenas como uma questo de implementao. Em alguns
casos, detalhes de localizao so definidos pelo programador na fase de implementao.
Em outros casos, a localizao abstrada por uma camada de middleware. CORBA, por
exemplo, um middleware que esconde de maneira intencional do programador a
localizao dos componentes do sistema. Neste middleware no h distino entre
componentes situados no mesmo ambiente computacional e componentes situados em
ambientes diferentes. Esta, entretanto, no a nica abordagem possvel para projetar uma
aplicao distribuda. Existem casos onde o conceito de localizao, recursos e migrao de
componentes para outros ambientes computacionais devem ser levados em considerao j
na fase de projeto. Em alguns casos a interao entre componentes que residem no mesmo
ambiente computacional ser muito diferente da interao entre componentes que residem
em ambientes diferentes se forem levadas em conta questes como latncia da rede, falhas
parciais no link de comunicao, acesso a memria, concorrncia e at mesmo diferentes
capacidades computacionais entre os ambientes computacionais envolvidos. A abstrao
destas questes pode levar a resultados inesperados quanto ao desempenho e confiabilidade
do sistema [27].
No restante desta seo, sero abordados paradigmas de projeto aplicados a uma
classe de aplicaes nas quais os conceitos de mobilidade e localizao tm um papel

24
fundamental que podem vir a modificar a estrutura conceitual da aplicao concebida
durante a fase de projeto [24]. Antes de entrar em detalhes nos paradigmas propriamente
ditos sero introduzidas algumas abstraes utilizadas no restante da seo para definir os
paradigmas:
Componentes: so considerados os elementos da arquitetura. Podem ser
subdivididos em recursos e unidades de execuo. Recursos compreendem
elementos representando dados passivos ou dispositivos fsicos como
arquivos, impressoras ou ainda uma interface de rede. Uma unidade de
execuo corresponde a um fluxo de execuo como uma thread ou um
processo. So caracterizados por possurem um estado que contm dados
privados, o estado de sua execuo bem como referncias para os recursos
utilizados. Podem ser vistos tambm como o know-how necessrio para a
execuo do servio;
Interaes: so eventos que envolvem dois ou mais componentes. Uma
mensagem trocada entre duas unidades de execuo, por exemplo, uma
interao;
Locais: so ambientes computacionais. Eles hospedam componentes e
provem suporte para a execuo de unidades de execuo.
Atualmente o paradigma mais utilizado em aplicaes distribudas o clienteservidor. Neste modelo o cliente envia uma requisio de servio ao servidor, este processa
a requisio enviando de volta para o cliente somente a resposta do servio. Tanto a
computao quanto os recursos necessrios para execut-la esto localizados no servidor.
Neste contexto, trs paradigmas [21] [24] que exploram mobilidade de cdigo e que
estendem o paradigma cliente-servidor sero apresentados. Estes paradigmas sero
diferenciados de acordo com a localizao dos componentes antes e depois do cdigo ser
executado, qual componente executa o cdigo e onde a computao realizada. Os
paradigmas apresentados sero os seguintes: remote evaluation (REV), code on demand
(COD) e mobile agent (MA) . Com o objetivo de obter um melhor entendimento destes
paradigmas ser considerado um cenrio onde um ambiente computacional A localizado no

25
local La necessita do resultado de um servio. Neste cenrio ainda existe outro ambiente
computacional B localizado no local Lb que estar envolvido no processo de execuo do
servio.

2.2.1 Remote Evaluation (REV)

Neste paradigma um componente possui o know-how para executar o servio, mas
no possui os recursos necessrios para a execuo dele. Desta maneira ele envia o seu
know-how para um componente situado em um ambiente remoto. Este componente executa
o servio baseado no know-how recebido e envia a resposta para o componente que iniciou
a transao. Aps a execuo do servio, o componente que o executou possui alm dos
recursos que ele j possua o know-how enviado pelo componente que requisitou o servio.
Dentro do contexto do cenrio descrito anteriormente, o componente A, localizado no local
La envia o cdigo a ser executado para o componente B no local Lb. Aps a execuo, o
componente B possui alm dos recursos necessrios para a execuo do servio, o cdigo
representando o know-how recebido do componente A.

2.2.2 Code on Demand (COD)

Neste paradigma o componente possui os recursos necessrios para a execuo do
servio, mas no possui o know-how necessrio para a execuo dele. Sendo assim ele,
atravs de uma interao com outro componente, requisita que este o envie o know-how
necessrio para a execuo do servio. Aps a execuo do servio o componente que o
requisitou possui os recursos e o know-how enviado pelo outro componente. No contexto
do cenrio exemplo, o componente A localizado no local La possui apenas os recursos
necessrios, mas no possui o know-how. Sabendo que o componente B possui o know-how
necessrio para a execuo do servio, o componente A requisita que este o envie. Aps a
execuo do servio o componente A possui alm dos recursos o know-how recebido do
componente B.

2.2.3 Mobile Agent (MA)

Neste paradigma o componente possui o know-how necessrio para a execuo do
servio e possui apenas alguns recursos. Sendo assim o componente executa em seu local

26
at quando puder. Quando um recurso no estiver disponvel, o componente migra ento
para outro local onde ele possa continuar sua execuo. Fazendo uma analogia com o
cenrio de exemplo, o componente A inicia sua execuo em seu ambiente e, em certo
ponto da execuo ele migra para outro local mais apropriado para continuar a sua
execuo. Neste paradigma, diferentemente dos paradigmas REV e COD, no somente o
cdigo que migra. Ao migrar de um local para outro o componente pode levar junto
consigo resultados intermedirios computados ainda no local de partida.

2.2.4 Discusso
Tendo apresentado estes paradigmas de desenvolvimento, sumarizados na Tabela
2.1, cabe ressaltar que estes no so os nicos. Outros paradigmas de desenvolvimento
podem ser utilizados em aplicaes que utilizam mobilidade de cdigo. Ao se projetar uma
aplicao que vir a utilizar mobilidade de cdigo, diversas questes devem ser analisadas
de modo a escolher o melhor paradigma. At mesmo mais de um paradigma pode ser
utilizado na mesma aplicao. Dependendo dos requisitos da aplicao um paradigma pode
ser mais adequado que outro. Se uma aplicao, por exemplo, necessita utilizar pouca
largura de banda, o paradigma MA em uma primeira anlise parece ser o mais adequado.
Da mesma maneira se uma aplicao necessita executar em um ambiente com memria
limitada, o paradigma COD uma boa opo dado que o cdigo obtido somente no
momento de sua execuo podendo inclusive vir a ser descartado aps a mesma, liberando
os recursos utilizados.
Todos os paradigmas apresentados explicitam o conceito de local. Esta abstrao
introduzida no nvel de arquitetura a fim de levar em conta na hora da modelagem da
aplicao a localizao dos componentes. A maioria dos paradigmas utilizados atualmente,
ao contrrio dos paradigmas apresentados, no explora o conceito de mobilidade no
podendo assim aproveitar os benefcios oferecidos.

27
Tabela 2.1 - Resumo dos paradigmas de desenvolvimento de mobilidade de cdigo [24]

Uma vez escolhido o paradigma a ser utilizado, outra escolha que os

desenvolvedores devem fazer qual tecnologia dever ser utilizada na implementao do
sistema. Mesmo as tecnologias disponveis sendo na maioria das vezes ortogonais com
relao ao paradigma escolhido, muitas vezes tecnologias especficas so mais apropriadas
a determinados paradigmas. Como exemplo pode-se citar a utilizao de um sistema de
cdigo mvel baseado em mobilidade fraca para programar um sistema utilizando o
paradigma de agente mvel (MA).

Neste cenrio, ao mover um componente de um

ambiente computacional para outro, de responsabilidade do programador criar as

estruturas de dados necessrias para manter o estado de execuo do componente (agente)
durante a migrao. Neste sentido o programador quem teria que armazenar, enviar e por
fim restaurar o estado corrente de execuo do agente no ambiente destino. Se, ao invs de
utilizar um sistema de cdigo mvel baseado em mobilidade fraca, fosse utilizado um
sistema baseado em mobilidade forte, a migrao do componente se restringiria a apenas
uma instruo.

2.3 Sistemas de Cdigo Mvel

Tendo apresentado nas sees anteriores os tipos de mobilidade de cdigo
juntamente com um modelo conceitual, nesta seo sero apresentados sistemas que

28
utilizam mobilidade de cdigo. Estes sistemas sero classificados de acordo com os
conceitos apresentados anteriormente. Em alguns destes sistemas, mais precisamente os
sistemas ubquos, a mobilidade de cdigo vista apenas como uma pequena parte do
sistema. Embora no sendo o objetivo fim destes sistemas, ela ainda assim tem um papel
fundamental na obteno das funcionalidades oferecidas.

2.3.1 Voyager
Desenvolvido pela empresa Recursion Software Inc, Voyager [44] uma plataforma
que integra de maneira simples o desenvolvimento de agentes mveis a aplicaes
distribudas. Voyager oferece suporte a objetos mveis, tornando possvel que objetos se
movam at o lugar onde tenham que realizar suas tarefas e retornem com os resultados.
Alm deste suporte, Voyager tambm oferece um framework para agentes autnomos. Uma
de suas principais caractersticas a facilidade de utilizao, simplificando o
desenvolvimento de aplicaes que utilizam de alguma forma a mobilidade de cdigo, seja
ela forte ou fraca.
O framework disponibilizado pela plataforma Voyager implementado na
linguagem Java e permite que, atravs de uma nica mensagem, um objeto seja movido de
uma mquina virtual para outra mesmo se este objeto esteja sendo utilizado por outros
clientes no momento. Mesmo com uma falha parcial ou total da rede, agentes Voyager
podem continuar sua execuo em clientes remotos. Adicionalmente agentes Voyager
podem implantar cdigo em sistemas que estejam executando sem a necessidade de parar a
execuo destes. Mais informaes podem ser encontradas em [44] e [34].

2.3.2 Java
Desenvolvida pela empresa Sun Microsystems, Java [25] uma linguagem de
programao orientada a objetos com construes semelhantes ao C++. Foi concebida
desde o incio para ser uma linguagem simples, portvel, de fcil aprendizado e de
propsito geral. Atualmente a linguagem Java encontra-se na verso 1.5 e desde seu
lanamento em 1995 muitas funcionalidades foram acrescentadas linguagem.

29
O compilador Java traduz programas escritos em Java para uma linguagem
intermediria, independente de plataforma chamada Java byte code. Este byte code por sua
vez interpretado pela mquina virtual Java JVM. Uma das caractersticas mais fortes da
linguagem Java sua portabilidade. Devido a sua arquitetura, um programa compilado em
Java pode executar em qualquer sistema operacional que possua uma mquina virtual
implementada. Sendo assim um programa escrito em Java, uma vez compilado, pode ser
executado por qualquer mquina virtual Java.
A mquina virtual Java tem a capacidade de carregar, em tempo de execuo, o
cdigo (byte code) necessrio para execuo. Quando a mquina virtual est executando
um byte code e encontra um nome de classe no resolvido, ela pode carregar de maneira
dinmica (atravs do class loader) o cdigo necessrio. Este cdigo pode estar localizado
na mesma mquina ou em uma mquina remota. Adicionalmente, o carregamento dinmico
de cdigo pode ser explicitado pela aplicao. A execuo do cdigo carregado pode ser
imediata ou atrasada. Em ambos os casos o cdigo sempre executado do incio, ou seja,
no existe tratamento para o estado de execuo, caracterizando assim a mobilidade de
cdigo oferecida como fraca.
Encaixando a linguagem Java no modelo de mobilidade de cdigo descrito na seo
anterior, tem-se que o ambiente computacional a JVM e a unidade de execuo o cdigo
Java que ela executa.

2.3.3 Java Aglets

Aglets [30] um SDK (Software Development Kit) desenvolvido pelo IBM Tokyo
Research Laboratory no Japo. um sistema de agentes mveis desenvolvido em Java
onde os agentes so denominados aglets. Cada agente neste sistema uma thread Java
executando em uma mquina virtual Java. O ambiente de execuo oferecido atravs de
um componente, chamado Tahiti server [20]. este componente quem suporta a execuo,
disponibiliza mecanismos para a mobilidade dos agentes e implementa mecanismos de
segurana.
A mobilidade oferecida por este sistema fraca, pois o estado de execuo dos
agentes no movido junto com eles. Ao mover-se de um ambiente computacional para

30
outro o agente suspende a thread que ele est executando, e migra para outro ambiente
computacional sem levar consigo seu estado de execuo, reiniciando sua execuo ao
chegar ao ambiente de destino [12].

2.3.4 JavaGo
Este sistema foi desenvolvido em Java e oferece suporte mobilidade forte. Para
oferecer a mobilidade forte JavaGo [39] utiliza um pr-processador que modifica em tempo
de compilao o cdigo fonte gerado. As modificaes realizadas pelo pr-processador
possibilitam ao JavaGo capturar o estado de execuo do agente antes de envi-lo a um
computador remoto.
Estas transformaes possibilitam que o programador possa escolher inclusive que
parte da pilha de execuo deve ser migrada. A migrao do agente ocorre atravs de uma
nica instruo, o que simplifica em muito o desenvolvimento de programas que o utilizam.
Outro sistema, baseado no JavaGo, denominado JavaGoX [38], a fim de tambm
oferecer suporte mobilidade forte, realiza uma transformao no byte code gerado pelo
compilador.

2.3.5 JADE
JADE [19] (Java Agent Development Framework) um framework desenvolvido e
suportado pela CSELT da Universidade de Parma na Itlia que objetiva facilitar o
desenvolvimento de aplicaes multi-agentes. JADE pode ser considerado um middleware
que implementa uma plataforma para o desenvolvimento de agentes. Sua implementao
segue as especificaes da FIPA1 (Foundation for Intelligent Physical Agents). Em JADE
toda a comunicao entre os agentes ocorre atravs de troca de mensagens.
JADE foi escrito em Java devido s caractersticas particulares da linguagem [6],
principalmente pela facilidade de utilizao da linguagem em ambientes heterogneos
distribudos. JADE disponibiliza tanto classes prontas para serem utilizadas quanto

http://www.fipa.org

31
interfaces abstratas as quais o desenvolvedor pode utilizar como base de implementao de
acordo com suas necessidades.
Utilizando o modelo de mobilidade de cdigo descrito na seo anterior tem-se que
JADE encaixa-se no paradigma de agentes mveis. Adicionalmente, em JADE, o ambiente
de execuo dado por uma instncia de uma mquina virtual Java e cada agente uma
thread Java. Na sua verso mais recente, modificaes foram realizadas no framework
visando aumentar o grau de segurana dos sistemas desenvolvidos [20]. JADE suporta
tanto a migrao quanto a clonagem de agentes.

2.3.6 Jini
Jini [28] [48] uma tecnologia desenvolvida pela empresa Sun Microsystems que
assume uma rede em constante mudana tanto em termos dos componentes que compe a
rede quanto na maneira como eles interagem. Esta tecnologia permite que desenvolvedores
criem servios centrados na rede.
A tecnologia Jini desenvolvida em Java e a mobilidade de cdigo acontece quando
um objeto necessita de um determinado servio. Com o objetivo de adquirir este servio o
objeto realiza uma busca na rede e o servio enviado para o objeto na forma de byte code
Java. Sendo assim, a principal funcionalidade da mobilidade de cdigo na tecnologia Jini
a customizao nos servios oferecidos. A fim de ser localizado por clientes, o servio
registra-se em um lookup server que onde ele ser localizado.
A tecnologia Jini, em conjunto com a capacidade da linguagem Java de mover
cdigo de maneira segura possibilita que o sistema represente uma forma automtica de
rede onde servios e clientes podem ser adicionados ou removidos a qualquer momento. Da
mesma maneira servios existentes podem ser modificados ou incrementados de maneira
simples.

2.3.7 Code
O sistema Code [37] foi desenvolvido a partir do conhecimento agregado pela
construo de aplicaes na rea de gerenciamento de redes baseadas em agentes mveis.

32
Este sistema disponibiliza mobilidade fraca. Ao migrar de um ambiente para outro um
agente preserva seus atributos, mas seu estado de execuo perdido. Cada agente neste
sistema uma thread Java.
Alm da semntica reativa de instanciao de classes disponibilizada pela mquina
virtual Java, este sistema ainda oferece uma semntica pr-ativa onde as classes so
previamente enviadas ao nodo de destino antes de serem efetivamente requisitadas pelo
class loader daquele nodo. Esta semntica tem por objetivo contemplar os casos em que o
link de conexo entre origem e destino no permanente, caracterstica muito comum em
dispositivos mveis como PDAs e laptops.
A unidade de migrao neste sistema dada por um grupo de classes. Uma API
especfica oferecida para a construo de grupos. Classes podem ser adicionadas a um
grupo individualmente ou de forma coletiva atravs da resoluo de dependncias. Cada
grupo possui duas classes especiais: Handler que responsvel pelo desempacotamento das
classes que compe o grupo no nodo destino e Root que responsvel por iniciar a
execuo das threads.
O contexto de execuo de um nodo encapsulado por um servidor denominado
Server. Cada um destes servidores possui um espao de classes compartilhado no qual a
aplicao pode publicar suas classes possibilitando que demais nodos do sistema possam
realizar instalaes pr-ativas ou reativas das classes publicadas

2.3.8 Obliq
Obliq [42] [11] uma linguagem interpretada, fracamente tipada, baseada em
objetos desenvolvida no DEC System Research Center. Obliq possibilita a execuo remota
de procedimentos atravs de execution engines que fazem o papel do ambiente
computacional. A unidade de execuo em Obliq representada por uma thread. Esta
unidade de execuo pode requisitar a execuo remota de um procedimento. Ao efetuar
esta requisio a unidade de execuo suspende sua execuo e envia o cdigo para o
ambiente remoto. Ao chegar ao ambiente remoto uma nova unidade de execuo
instanciada para executar o cdigo enviado. A unidade de execuo que enviou o cdigo

33
continua suspensa at que a execuo remota termine. Desta maneira a mobilidade
oferecida por Obliq fraca com suporte ao envio de cdigo de maneira sncrona.
Objetos em Obliq so considerados recursos fixos transferveis. Durante todo seu
ciclo de vida eles so ligados ao ambiente computacional que os criou. Mesmo havendo
uma migrao de um objeto para outro ambiente computacional, este continua acessando os
recursos de seu ambiente original atravs de referncias de rede. Estas referncias so
criadas e tratadas automaticamente no momento de uma migrao.

2.3.9 .NET
Com conceitos similares plataforma Java, .NET [15] uma plataforma de
software que disponibiliza diversas funcionalidades para o desenvolvimento de aplicaes
distribudas. No ncleo da plataforma .NET encontra-se o .NET framework. Este
framework quem prov a estrutura bsica para o resto da plataforma e tambm unifica o
modelo de programao entre as diversas linguagens suportadas. Alm da estrutura bsica,
o .NET framework disponibiliza tambm uma mquina virtual responsvel pelos servios
de gerenciamento de memria, gerenciamento de threads, compilao bem como
gerenciamento de cdigo fonte. Esta mquina virtual tambm chamada de CLR (Common
Language Runtime). Alm dos servios citados, o CLR tambm quem oferece a
interoperabilidade entre as linguagens de programao que compe a plataforma .NET
atravs da definio de uma linguagem intermediria chamada MSIL (Microsoft
Intermediate Language) e de um formato nico de arquivo executvel. Todas as linguagens
que compem a plataforma geram o executvel de acordo com este formato. Desta maneira
arquivos executveis gerados por diferentes linguagens podem ser integrados facilmente. A
linguagem MSIL similar ao byte code Java pois uma linguagem baseada em pilha com
um rico conjunto de instrues.
Outro aspecto importante da plataforma .NET que, assim como na linguagem
Java, o CLR disponibiliza junto consigo uma biblioteca com diversas funes para
tratamento de janelas em ambientes grficos, integrao com diversos bancos de dados,
entrada e sada, threads, suporte a XML entre outras.

34
O sucesso da linguagem Java no desenvolvimento de sistemas que utilizam
mobilidade de cdigo se deve principalmente s funcionalidades que disponibilizam blocos
bsicos de construo para este tipo de sistema. A plataforma. NET, da mesma maneira,
disponibiliza funcionalidades semelhantes tais como suporte concorrncia, serializao de
objetos, carregamento de cdigo e reflexo. Sendo assim, o tipo de mobilidade de cdigo
suportado pela plataforma .NET similar mobilidade de cdigo suportada pela linguagem
Java. Esta mobilidade considerada fraca, pois o estado de execuo no mantido na
ocorrncia de uma migrao de um objeto.
Atualmente, em comparao com a linguagem Java, no so encontrados muitos
sistemas que utilizam mobilidade de cdigo baseados na plataforma .NET. A plataforma
.NET assemelha-se em diversos pontos com o sistema Code descrito na seo 2.3.7. No
entanto alguns pontos especficos ainda podem ser explorados na plataforma .NET [15].
Um ponto que chama a ateno a possibilidade de implementao de mobilidade forte
atravs da utilizao de meta dados que podem ser embutidos no arquivo executvel. Outro
trabalho envolvendo mobilidade de cdigo utilizando .NET pode ser encontrado em [33].

2.3.10 LIME
LIME [1] um middleware voltado ao desenvolvimento de aplicaes que
requerem mobilidade fsica de hosts, mobilidade lgica de agentes ou ambos. O projeto de
LIME inspirado no fato de que um dos maiores problemas ao se projetar uma aplicao
distribuda que utiliza mobilidade de cdigo pode ser visto como um problema de
coordenao [22]. Adicionalmente os autores afirmam que para lidar com este tipo de
problema, a disponibilidade de abstraes para lidar e explorar um contexto que muda de
maneira dinmica fundamental.
A perspectiva de coordenao adotada por LIME baseada no modelo proposto em
[14], onde um espao de tuplas global e persistente acessvel por todas as entidades que
compem o sistema. Em LIME este espao de tuplas redefinido de modo que cada agente
mvel possua mltiplos espaos de tuplas compartilhados com os demais agentes. Este
compartilhamento obtido estendendo-se o espao de tuplas de cada agente de modo a
armazenar as tuplas dos demais agentes.

35
O conjunto de tuplas compartilhadas muda durante o tempo devido a aes dos
agentes nas mesmas. Outra razo para uma possvel modificao no espao de tuplas dada
pela entrada ou sada de novos agentes neste espao. O resultado desta abordagem um
contexto gerencivel de maneira transparente expressado atravs das modificaes
ocorridas no espao de tuplas percebido pelos agentes. Desta maneira o comportamento dos
agentes alterado tanto pela disponibilidade de novos dados quanto pela reao a
mudanas no contexto.
interessante notar que a mobilidade no manipulada diretamente em LIME. No
existem construes para o disparo de mobilidade, seja ela de agentes ou de hosts. Ao invs
disso, o efeito da migrao obtido de maneira indireta atravs das mudanas observadas
no contexto do ambiente. Esta deciso de projeto mantm o modelo mais genrico e, ao
mesmo tempo, permite diferentes instanciaes do modelo baseado em diferentes noes de
conectividade.

2.4 Sistemas Ubquos

Embora no sejam sistemas de mobilidade de cdigo propriamente ditos, cabe
ressaltar que a mobilidade de cdigo uma questo presente em diversos sistemas ubquos.
A computao ubqua pode utilizar os trs paradigmas de mobilidade de cdigo descritos
na seo 2.2 para a implementao da semntica siga-me (follow me), tambm descrita em
[3].

2.4.1 Aura
Desenvolvido na Universidade de Carnegie Mellon, Aura [41] uma arquitetura
que tem como caracterstica chave ser orientada as tarefas dos usurios. Entre os desafios
centrais da arquitetura deste sistema encontram-se dois objetivos: maximizar a utilizao de
recursos disponveis e minimizar a distrao do usurio.
Este sistema utiliza o conceito de que o usurio possui uma aura pessoal que se
encarrega de obter os recursos necessrios a partir do ambiente para que o usurio consiga
executar suas tarefas. Entre exemplos de possveis tarefas pode-se citar a escrita de um
artigo, a preparao de uma apresentao ou at mesmo a compra de uma casa.

36
A fim de disponibilizar esta funcionalidade a arquitetura do sistema Aura necessita
de funcionalidades que devem ser implementadas tanto em nvel de sistema quanto em
nvel de aplicao. Nesta arquitetura apresentado o conceito de placeholder que auxilia
na tarefa de obter o maior nmero de informaes possvel a respeito do usurio. Entre as
informaes que ele armazena podem estar a aplicao que o usurio est executando,
informaes pessoais e intenes.
A arquitetura do Aura, apresentada na Figura 2.4, composta por quatro tipos de
componentes:
Task Manager, tambm chamado de Prism, responsvel por personificar o
conceito de aura pessoal do usurio. Este componente responsvel pelo
gerenciamento de tarefas como a mudana de ambiente por parte do usurio,
mudana do prprio ambiente, mudana de tarefa e mudana de contexto;
Context Observer, responsvel por obter informaes relevantes a respeito
do contexto fsico e report-las para o Prism e para o Environment Manager;
Environment Manager, considerado o ponto de entrada do sistema. Este
componente sabe quais entidades esto disponveis no sistema, que servios
elas oferecem e onde podem ser encontradas. Este componente tambm
possui mecanismos que implementam acesso distribudo a arquivos;
Suppliers, responsveis por prover os servios abstratos que compem as
tarefas, tais como edio de texto, vdeo, etc.

37

Figura 2.4 - Arquitetura do Aura [41]

A comunicao entre estes componentes ocorre atravs de um componente chamado

Connector. Diferentes tipos de connectors so disponibilizados para comunicao entre os
elementos bem como connectors especficos dependendo do tipo de utilizao.
A mobilidade de cdigo em Aura se d atravs dos componentes descritos
anteriormente. Em um exemplo hipottico, um usurio est editando um texto em sua casa
e decide ir para seu escritrio. Ao perceber a sada do usurio, Aura automaticamente salva
seu trabalho, mantendo os aplicativos envolvidos na seo de trabalho do usurio no
mesmo estado em que eles estavam no momento em que ele saiu de casa. Caso o usurio
estivesse assistindo a um vdeo por exemplo, ao chegar ao seu escritrio encontraria o
vdeo parado no mesmo instante de tempo. Os arquivos sendo utilizados pelo usurio
tambm seriam enviados para o ambiente do escritrio. Todos os recursos necessrios para
que isto acontea so tratados por Aura, no necessitando nenhuma interveno por parte
do usurio.

2.4.2 One.World
One.world [26] uma arquitetura que disponibiliza um framework abrangente e
integrado para o desenvolvimento de aplicaes pervasivas. O principal objetivo facilitar
o desenvolvimento de aplicaes que se adaptam de maneira automtica a ambientes em
constante mudana. A fim de facilitar esta adaptao, one.world oferece aos
desenvolvedores servios que auxiliam no gerenciamento destas mudanas.

38
Todos os dados em one.world so representados por tuplas, a fim de definir um
modelo de dados comum para todas as aplicaes objetivando simplificar o
compartilhamento de dados. Este modelo de dados comum facilita a tarefa de uma
aplicao ao procurar por algum dado especfico no ambiente.
Quatro servios fundamentais so oferecidos em one.world: uma mquina virtual,
servio de tuplas, eventos assncronos e ambientes. A Figura 2.5 mostra a arquitetura de
one.world onde aparecem ambientes representados por retngulos juntamente com
componentes e espaos de tuplas.

Figura 2.5 - Arquitetura do one.world [26]

Todo o cdigo em one.world executado em uma mquina virtual, mais

precisamente a mquina virtual Java (JVM). Um dos motivos do uso desta mquina virtual
a heterogeneidade inerente a um ambiente pervasivo. Em um ambiente como este os
desenvolvedores no tem como prever todo o tipo de dispositivo a aplicao ir executar.
Utilizando uma mquina virtual, uma camada de abstrao inserida de modo a fazer com
que as aplicaes consigam executar em qualquer dispositivo que possua uma mquina
virtual. O espao de tuplas, como dito anteriormente, fornece um modelo de dados
homogneo que simplifica o compartilhamento de dados. Toda a comunicao em
one.world, seja ela local ou remota, feita atravs de eventos assncronos. Estes eventos

39
servem para notificar as aplicaes de maneira explcita a respeito das mudanas em seu
contexto. Ambientes so os principais componentes da estrutura de one.world. Podendo ser
comparados com processos em sistemas operacionais, ambientes hospedam aplicaes em
execuo isolando umas das outras. Eles tambm servem como containers para dados
persistentes oferecendo armazenamento associativo de tuplas de modo que aplicaes
podem ser agrupadas juntamente com seus dados. Adicionalmente, ambientes ainda podem
ser aninhados tornando fcil tanto a composio quanto a extenso de aplicaes. Um
ambiente externo tem controle completo de seus ambientes internos. Esta construo
facilita que usurios/desenvolvedores modifiquem o comportamento de suas aplicaes
sem ter que mudar a aplicao em si.
Os demais servios disponibilizados em one.world, como migrao de cdigo e
descoberta de servios, so construdos com base nos servios fundamentais apresentados
anteriormente. A migrao de cdigo em one.world move ou copia um ambiente para um
dispositivo diferente. Esta migrao, ao contrrio da migrao de processos tradicionais,
no ocorre de maneira transparente e o estado da aplicao migrada se limita ao ambiente
sendo migrado. Durante a migrao one.world anula as referncias a recursos que esto
fora do ambiente. Esta prtica, segundo o autor [26] aceitvel, pois as aplicaes em
one.world so concebidas com mudanas constantes em mente.
A mobilidade de cdigo em one.world considerada fraca, pois o estado que
movido no processo de migrao se limita ao ambiente sendo migrado. Esta deciso evita
dependncias residuais e requer conectividade entre os dispositivos somente durante a
migrao.

2.4.3 Mobile Gaia

Desenvolvido pela University of Illinois at Urbaba-Champaign, Mobile Gaia [13]
um middleware orientado a servios que integra recursos de diferentes tipos. Este
middleware disponibiliza funes para a criao e manuteno de colees de dispositivos,
compartilhamento de recursos, possibilitando assim uma integrao de maneira
transparente.

40
Mobile Gaia tambm disponibiliza um framework para o desenvolvimento de
aplicaes tendo uma coleo subjacente em mente. Este framework decompe a aplicao
em componentes menores que podem executar em diferentes membros da coleo. Seu
principal objetivo que aplicaes que utilizem esta coleo sejam desenvolvidas atravs
de uma interface comum de programao.
Entre os servios disponibilizados por Mobile Gaia esto os servios de descoberta
de dispositivos, manuteno da coleo de dispositivos, compartilhamento de recursos, bem
como um servio de comunicao entre os dispositivos que fazem parte da coleo. Esta
coleo tambm chamada de active space.
Os servios em Mobile Gaia so decompostos em componentes possibilitando que
somente os componentes necessrios a determinado servio sejam carregados no
middleware reduzindo assim o consumo de memria e bateria dos dispositivos envolvidos.
A fim de obter esta estrutura de componentes, unidades independentes de servios so
identificadas e agrupadas de modo a se obter o servio desejado. Um servio de
localizao, por exemplo, composto do servio de sensores, servio de modelo espacial e
de adaptadores de localizao.
Os servios em Mobile Gaia so apresentados em dois papis: cliente e
coordenador. Quando um dispositivo coordenador de uma coleo, seus servios possuem
responsabilidades adicionais, como integrar servios similares em dispositivos que fazem
parte da coleo, gerenciar os servios em todos os dispositivos entre outros. O servio de
localizao em um dispositivo coordenador, por exemplo, adquire informaes sensoriais
de todos os dispositivos de sua coleo.
Quando um dispositivo coordenador de uma coleo, os componentes necessrios
para a implementao de um determinado servio so carregados de maneira dinmica para
o middleware. De maneira similar, caso o componente coordenador mude seu papel para
cliente, os componentes previamente carregados no middleware so descarregados e os
componentes do novo coordenador so carregados. Esta carga e descarga automtica de
servios feita pelo framework de implantao de servios. Quando um dispositivo muda
de papel (de coordenador para cliente por exemplo), o gerenciador de colees informa ao

41
framework de implantao de servios esta mudana e este toma as medidas necessrias,
descarregando do middleware os servios do coordenador antigo e carregando os servios
requeridos pelo novo coordenador. A Figura 2.6 mostra a arquitetura do Mobile Gaia.

Figura 2.6 - Arquitetura do Mobile Gaia [13]

A mobilidade de cdigo em Mobile Gaia acontece em nvel de componentes. So os

componentes bsicos de servio que so movidos entre dispositivos, definindo assim a
granulosidade da mobilidade. Enquadrando a mobilidade disponibilizada por Mobile Gaia
no framework apresentado na Seo 2.1, tem-se que a mobilidade fraca pois o estado de
execuo dos componentes no mantido quando estes so carregados no middleware. o
framework de implantao de servios quem envia o servio (cdigo) necessrio para os
dispositivos, realizando assim uma abordagem de code shipping.

2.4.4 ISAM
ISAM [47] uma arquitetura de software concebida para lidar com a
implementao e execuo de aplicaes pervasivas. Desenvolvido por pesquisadores de
universidades do sul do Brasil (UFRGS, UFSM, UFPEL e UNISINOS), tem como um dos
objetivos principais prover uma adaptao colaborativa entre a aplicao (programa) e o
ambiente de execuo (middleware).

42
A arquitetura proposta organizada em camadas com nveis diferenciados de
abstrao buscando a manuteno da qualidade dos servios oferecidos ao usurio mvel
atravs do conceito de adaptao. Uma viso geral desta arquitetura pode ser vista na
Figura 2.7.

Figura 2.7 - Arquitetura do ISAM [47]

A camada superior da arquitetura composta pela aplicao mvel distribuda. A

construo desta aplicao baseada em abstraes do Holoparadigma, as quais permitem
expressar mobilidade, acrescidas de novas abstraes para expressar adaptabilidade
providas pelo ISAMAdapt [2]. A camada inferior, por sua vez, composta por tecnologias
utilizadas em sistemas distribudos existentes, como sistemas operacionais e a mquina
virtual Java, por exemplo.
Na camada intermediria encontram-se trs nveis de abstrao que formam o
ncleo funcional da arquitetura ISAM. O primeiro nvel composto por dois mdulos de
servio aplicao: o escalonamento que considerado um componente chave da
adaptao na arquitetura e o ambiente virtual do usurio, que composto pelos elementos
que integram a interface de interao do usurio mvel com o sistema. este mdulo que
permite que uma aplicao sendo executada em uma localizao possa ser instanciada e
continuar sua execuo em outro local sem interrupo suportando desta maneira o
desenvolvimento de aplicaes que seguem a semntica siga-me.

43
O segundo nvel responsvel pelo contexto da aplicao que determinado atravs
de informaes de quem, quando, o que est sendo realizado e com o que est sendo
realizado. A tarefa de obter estes dados do mdulo de monitoramento que atua tanto na
parte mvel quanto na parte fixa da rede.
No terceiro nvel da camada intermediria esto os servios bsicos do ambiente de
execuo ISAM que prov funcionalidade necessria para o segundo nvel, cobrindo
diversos aspectos como migrao de cdigo, replicao otimista e localizao. Neste
sentido, nesta camada que a mobilidade de cdigo tratada dentro da arquitetura de
ISAM.

2.5 Concluso
Atualmente, dentro do contexto da computao distribuda, a mobilidade vem se
afirmando cada vez mais como uma forte tendncia. Dentre os principais fatores que
contribuem para este fato esto o grande poder computacional de dispositivos cada vez
menores juntamente com novas tecnologias que emergem visando aproveitar este novo
cenrio.
Neste captulo o conceito de mobilidade de cdigo foi analisado do ponto de vista
do desenvolvimento de software. Este conceito mesmo no sendo recente, tem atrado
ateno da comunidade cientfica. Inicialmente um framework foi descrito juntamente com
uma taxonomia onde as questes que envolvem a mobilidade de cdigo foram expostas. Na
seo seguinte os paradigmas de desenvolvimento de software voltados mobilidade de
cdigo foram apresentados juntamente com uma breve discusso envolvendo a utilizao
dos mesmos no desenvolvimento de aplicaes.
No final do captulo foram apresentados sistemas que utilizam algum tipo de
mobilidade de cdigo. Entre estes sistemas destacam-se duas linguagens/plataformas de
programao bastante utilizadas atualmente que so Java e .NET.
A idia deste captulo foi introduzir de maneira sucinta o conceito de mobilidade de
cdigo enfatizando as questes relevantes dentro do contexto do desenvolvimento de
software. No prximo captulo ser apresentado o Holoparadigma, a HoloVM que a

44
mquina virtual onde os programas que utilizam byte code Holo executam e tambm o
ambiente de execuo distribudo. O restante deste trabalho est focado na introduo do
suporte mobilidade de cdigo na HoloVM.

45

3. Holoparadigma
Neste captulo sero apresentados os conceitos do Holoparadigma, um modelo
multiparadigma que estimula a explorao automtica de paralelismo e distribuio
juntamente com uma descrio detalhada da HoloVM. A HoloVM uma mquina virtual
desenvolvida com o propsito de oferecer suporte execuo de programas que exploram
os conceitos oferecidos pelo Holoparadigma. O Holoparadigma ser apresentado dentro do
contexto do projeto PHolo (Pervasive Holoparadigm). Este projeto foi concebido com o
objetivo de fornecer suporte computao ubqua no Holoparadigma.
Com o intuito de agregar a funcionalidade de mobilidade de cdigo, mais
precisamente a mobilidade forte, modificaes sero feitas na HoloVM de modo que a
mobilidade possa ser explorada de maneira simples do ponto de vista do desenvolvedor de
software. Na prxima seo uma descrio breve do Holoparadigma ser apresentada com
o objetivo de contextualizar o leitor. Informaes mais detalhadas deste paradigma podem
ser encontradas nas referncias bibliogrficas.

3.1 Conceitos Bsicos

O Holoparadigma [4] um modelo multiparadigma que integra conceitos de
paradigmas bsicos (imperativo, orientado a objetos, funcional e lgico) orientado ao
desenvolvimento de software paralelo e distribudo. Ele prope a utilizao de
processamento simblico como principal instrumento para o tratamento de informaes.
Esta caracterstica foi herdada do paradigma de programao em lgica. O Holoparadigma
estabelece a utilizao de duas unidades de modelagem: o ente, que sua principal
abstrao, e o smbolo, que utilizado para descrever os entes e suas relaes. Um ente
elementar (Figura 3.1a) organizado em trs partes: interface, comportamento e histria.
Um ente composto (Figura 3.1b) possui a mesma organizao de um ente elementar, porm
suportando a existncia de outros entes em sua composio (entes componentes),
assemelhando-se a um grupo. Neste caso, a histria atua como um espao compartilhado
vinculado ao grupo. Cada ente possui uma histria que fica encapsulada no seu interior. No

46
caso de entes compostos esta histria compartilhada pelos entes componentes. Neste
sentido vrios nveis de encapsulamento de histrias podem existir, porm, entes acessam
diretamente a histria em dois nveis (o seu e o do seu ente pai). Esta composio de entes
(presente em entes compostos) pode variar em tempo de execuo de acordo com a
mobilidade dos entes. A Figura 3.1c mostra um ente composto por trs nveis e exemplifica
a histria encapsulada.

Figura 3.1 - Tipos de Entes

A interface de um ente descreve suas possveis interaes com demais entes. O

comportamento contm as aes que definem o comportamento de um ente e a histria
um espao de dados compartilhado no interior de um ente. Esta estrutura, do ponto de vista
estrutural, semelhante a um objeto do paradigma de desenvolvimento orientado a objetos.
A principal diferena encontra-se na histria, que neste caso atua como uma forma
alternativa de comunicao e sincronizao.
A mobilidade no Holoparadigma a caracterstica que permite que entes possam
deslocar-se. No mbito do Holoparadigma existem dois tipos de mobilidade: a mobilidade
lgica e a mobilidade de cdigo. A mobilidade lgica relaciona-se com o deslocamento em
nvel de modelagem, no levando em considerao o ambiente de execuo. A mobilidade
de cdigo, entretanto, relaciona-se com o deslocamento de entes entre nodos fsicos em
uma arquitetura distribuda. Desta forma, um ente se move quando se desloca de um nodo
para outro. nesta mobilidade que o restante deste trabalho est focado. A Figura 3.2a

47
mostra uma possvel mobilidade lgica no ente apresentado na Figura 3.1c. A Figura 3.2b
mostra uma mobilidade de cdigo que no implica em mobilidade lgica.
No escopo de sistemas distribudos, um ente pode assumir dois estados de
distribuio: centralizado ou distribudo. No estado centralizado um ente encontra-se
fisicamente sediado em apenas uma mquina enquanto que no estado distribudo um ente
pode agregar entes executando em mquinas diferentes. A Figura 3.2b mostra um possvel
estado de distribuio para o ente mostrado na Figura 3.1c. Neste caso, a histria do ente
composto atua como uma memria compartilhada distribuda (DSM Distributed Shared
Memory).

Figura 3.2 - Mobilidade no Holoparadigma

A execuo de um programa cria uma estrutura hierrquica de entes, denominada

rvore de Entes (HoloTree). Esta rvore implementa o encapsulamento de entes em nveis
de composio, conforme proposto pelo Holoparadigma. A HoloTree suporta ainda o
aspecto dinmico da poltica de grupos, mudando continuamente durante a execuo de um
programa. Aes como a instanciao e a mobilidade de entes so exemplos de aes que
modificam a HoloTree. A Figura 3.3a exemplifica a HoloTree para a organizao de nveis
mostrada na Figura 3.1c. Um ente composto possui ligaes com seus entes componentes,
os quais ficam localizados um nvel abaixo. Os entes componentes possuem acesso
histria e ao comportamento de um ente composto no qual esto inseridos. O ente

48
composto, por sua vez, possui acesso aos comportamentos dos seus entes componentes. Um
ente ainda possui acesso ao comportamento dos demais entes que esto no mesmo nvel.
Visando colocar em prtica os conceitos estabelecidos pelo Holoparadigma, uma
linguagem de programao, a Hololinguagem [5] foi desenvolvida. A Hololinguagem
uma linguagem multiparadigma direcionada para o desenvolvimento de sistemas
distribudos.

Figura 3.3 - rvore de Entes (HoloTree)

Quando a mobilidade ocorre, torna-se necessria a mudana da viso do grupo dos

entes envolvidos. O ente movido possui uma nova viso (novos entes no mesmo nvel e um
novo ente composto no qual ele est inserido). Caso o ente movido seja composto, a viso
de seus componentes no muda. A mobilidade implica uma atualizao da composio dos
entes origem e destino. Diversas questes conseqentes a esta mobilidade devem ser
tratadas. A mobilidade de um ente elementar, do ponto de vista da HoloTree equivale
realocao de uma folha da rvore enquanto que a mobilidade de um ente composto
equivale realocao de um ramo inteiro da rvore contendo diversos entes. A Figura 3.3b
mostra a mudana que ocorreria na HoloTree para a mobilidade da Figura 3.2a.
Na prxima seo ser apresentada a HoloVM, uma mquina virtual desenvolvida
com o objetivo de oferecer uma camada de execuo a programas baseados no
Holoparadigma.

49

3.2 HoloVM
A HoloVM [23] uma mquina virtual desenvolvida com o intuito de criar uma
camada de abstrao entre os programas escritos na Hololinguagem e a mquina fsica na
qual eles executam, possibilitando que um byte code Holo seja executado em qualquer
plataforma onde exista uma implementao desta mquina virtual. Atualmente existem
implementaes da HoloVM para as plataformas Windows, Linux, Mac OS e Windows
Mobile (Pocket PC), compreendendo assim uma diversa gama de dispositivos, desde
servidores at PDAs.
A execuo de programas pela HoloVM acontece atravs de um arquivo binrio
pr-definido. Este arquivo normalmente possui a extenso hvm e contm alm de uma
tabela de smbolos, as instrues (byte code) a serem executadas. Qualquer compilador
pode gerar, a partir de sua linguagem de origem, um arquivo hvm para ser executado pela
HoloVM.
A HoloVM realiza processamento simblico. Sendo assim no existe internamente
uma definio explcita de variveis e tipos. As variveis so criadas sob demanda e a
verificao de tipos feita durante a execuo do byte code. Apenas trs tipos de dados so
considerados para o processamento interno: smbolos, nmeros e strings.
A HoloVM fornece um conjunto de instrues especficas que suportam as
funcionalidades propostas no Holoparadigma. Entre estas instrues podem ser citadas duas
que tem influncia sobre a localizao dos entes. A primeira, chamada clone, responsvel
pela criao de um ente na aplicao. A segunda, chamada move, faz com que um ente se
mova na rvore de execuo.
Em sendo uma mquina de pilha, a HoloVM possui duas pilhas. A pilha de
operandos e a pilha de controle. A pilha de operandos utilizada para armazenar os
resultados parciais dos clculos, parmetros necessrios execuo de uma ao ou ente e
tambm informaes de retorno destas aes. Dois comandos, load e store so oferecidos
para manipulao desta pilha. A pilha de controle utilizada somente para controle interno
de um fluxo de execuo, armazenando informaes como o endereo de retorno e
variveis locais a uma ao. No existem instrues especficas para manipular esta pilha.

50
Sua manipulao ocorre atravs de instrues de manipulao de variveis e de invocao e
trmino de aes. Cada ente possui sua pilha de operandos e de controle, criadas no
momento de sua clonagem e destrudas no momento de sua extino.
A explorao de concorrncia na HoloVM obtida atravs de multiprogramao
leve (threads) visando obter vrios fluxos de execuo dentro do mesmo processo.
Internamente a HoloVM, uma unidade bsica de execuo chamada de BCE (Byte Code
Executor). O BCE, por definio, uma thread de execuo e sempre est associado a um
ente. A Histria, o Comportamento e a Interface dos entes so implementadados atravs de
blackboards [45]. Sendo assim uma invocao feita a eles se resume a uma invocao
implcita a um blackboard.

3.3 Modelo de Execuo Distribuda

Dadas s diversas caractersticas que favorecem a explorao da mobilidade de
software, mais precisamente a mobilidade de entes, contidas no Holoparadigma, dois
modelos de execuo distribuda foram desenvolvidos. Estes modelos visam colocar em
prtica os conceitos estabelecidos no Holoparadigma.
Os modelos desenvolvidos so, respectivamente, o HS (History Server) e o HNS
(Holo Naming System) [8]. Ambos tem o objetivo de permitir a execuo de programas
que compe uma modelagem em mltiplas plataformas.

3.3.1 History Server

O HS basicamente um servidor que disponibiliza um espao de tuplas que pode
ser compartilhado entre diversas HoloVMs. Este servidor implementa ainda o suporte a
algumas caractersticas que o Holoparadigma possui, dentre as quais se destacam as
questes de restrio ao acesso histria. Estas restries so criadas pelo encapsulamento
de entes, e consistem no fato de que um ente pode acessar apenas a sua histria e a histria
de seu ente pai. Ao executar uma aplicao utilizando este sistema, todo acesso histria
mapeado diretamente para o servidor. Quando um ente acessa a histria de seu pai, ou a
dele prprio, a HoloVM se encarrega de mapear este acesso para uma comunicao com o
HS. Este ento mantm espaos de memria independentes para cada ente criado no

51
ambiente de execuo distribudo. Desta maneira entes em diferentes mquinas podem se
comunicar.
Na Figura 3.4 mostrada a representao de um ambiente de execuo utilizando o
HS juntamente com as possveis interaes com uma ou mais HoloVMs. No passo 1 a
HVM a informa a criao de um ente para o servidor. Tendo feito isto, para que dois entes
possam comunicar-se, basta que eles possuam um ente em comum.

Figura 3.4 - Funcionamento do HS

Quando uma HoloVM executada com o HS, todo o ente criado gera uma
mensagem para o servidor que o registra. Esta a etapa inicial de um processo que permite
que o servidor mantenha a consistncia com relao aos programas em execuo. A
localizao da HoloVM que enviou a mensagem ao servidor no conhecida pelo HS.
Somente a HoloVM quem conhece a localizao do HS. Aps o registro de um ente no
HS, qualquer comando de acesso histria executado por ele mapeado para o servidor.
Da mesma maneira um comando move tambm implica em mudana na estrutura mantida
no servidor. Os passos 2 e 3 exemplificam as HVMs b e c, interagindo com o servidor para
acessar a histria de um ente.
A implementao deste modelo permitiu que os conceitos propostos pelo
Holoparadigma fossem aplicados a um ambiente distribudo. Entretanto o HS apresenta
algumas limitaes. A primeira delas que ele pode ser visto como um ponto central de
falhas devido sua caracterstica centralizada.

Outra limitao que este modelo

52
implementa apenas abstraes para acessos histria dos entes. No entanto esta no a
nica abstrao do Holoparadigma a ser explorada em um ambiente distribudo. Desta
maneira um novo modelo que atende melhor aos requisitos do Holoparadigma foi definido.
Este modelo apresentado na seo seguinte.

3.3.2 Holo Naming System

O principal objetivo do HNS [43] prover um servio que possibilite a execuo de
programas Holo distribudos entre diversas HoloVMs. Dois problemas principais devem ser
resolvidos de modo a fornecer este suporte. O primeiro refere-se localizao de entes em
um ambiente distribudo. O segundo implica o desenvolvimento de uma camada de
execuo que torne possvel que duas HoloVMs possam dar suporte ao uso de todos os
recursos propostos no Holoparadigma que envolvam interao entre entes.
A resoluo do primeiro problema ocorreu com o desenvolvimento de uma soluo
baseada no DNS [31]. Desta maneira o HNS contm uma lista de entes de um determinado
ambiente juntamente com os endereos IP dos dispositivos onde eles esto executando.
Com a criao do HNS, cada HoloTree existente em cada HoloVM tem apenas uma
viso parcial do cenrio. Apenas o servidor quem tem a viso total pois todas as
HoloVMs envolvidas reportam ao servidor qualquer alterao ocorrida em sua estrutura.
Esta estrutura mantida pelo HNS tambm chamada de Distributed Holo Tree
(DHoloTree).
As mensagens trocadas entre o servidor e as HoloVMs podem ser separadas em dois
grupos. No primeiro grupo esto as que servem para informar o servidor sobre uma
alterao na rvore juntamente com as mensagens que requisitam ao servidor informaes a
respeito da localizao dos entes. As instrues clone e move sempre que executadas iro
gerar uma mensagem para o HNS, pois ambas alteram a estrutura interna da HoloVM que
as executou. Desta maneira o HNS sempre mantm uma viso atualizada da rvore
distribuda.
Uma camada de software foi desenvolvida para executar a comunicao entre a
HoloVM e o HNS. Atravs dela a HoloVM pode informar ao HNS a respeito de

53
modificaes em seu estado interno bem como executar consultas. Um protocolo de
camada de aplicao foi desenvolvido para a troca de mensagens. Este protocolo
caracteriza-se por ser bastante simples e reduzido, de modo a gerar um pequeno overhead
de comunicao.
No segundo grupo encontram-se as instrues de acesso a histria, comportamento
e interface juntamente com instrues que o programador pode utilizar para perguntar quem
o pai ou mesmo quem so os entes que compartilham o mesmo pai.
Quando determinado ente necessita interagir com outro, e este ltimo no se
encontra na mesma HoloVM, necessrio ento executar uma consulta no HNS para
descobrir a localizao deste ente. O servidor, por sua vez, retorna um URI (Uniform
Resource Identifier) para a HoloVM. De posse desta localizao, as HoloVMs podem ento
interagir diretamente. Neste estgio elas podem realizar acessos remotos tais como:
Acessar a histria de determinado ente localizado em uma HoloVM remota;
Disparar aes pertencentes ao comportamento de entes remotos;
Acessar aes que esto publicadas na interface dos entes remotos.
Durante a execuo de uma HoloVM utilizando o HNS, existem dois momentos
distintos. No primeiro, como demonstrado na Figura 3.5, acontece a descoberta do servio
pela HoloVM, onde a HVM a descobre um HNS disponvel (passo 1) e este retorna uma
mensagem para a HoloVM informando sua localizao (passo 2). Depois disso a HoloVM
utiliza o suporte oferecido pelo HNS, sincronizando as informaes de sua HoloTree com a
DHoloTree do servidor (passo 3). Depois de sincronizados os contextos, a HoloVM
executa utilizando o suporte oferecido pelo HNS. Ainda na Figura 3.5 dois passos que
permitem a comunicao entre dois entes so mostrados. No passo 4 a HVM c faz uma
consulta ao servidor para descobrir a localizao da HoloVM que possui o ente com o qual
ela quer ser comunicar. Caso o servidor contenha esta informao ela retornada para a
HVM c (passo 5). Com base nesta informao ela envia a requisio da ao desejada para
a HVM b (passo 6) que ir executar a ao e retornar o resultado (passo 7). Este processo

54
ocorre de forma transparente para o usurio, facilitando o desenvolvimento de programas
distribudos.

Figura 3.5 - Representao do funcionamento do HNS

O HNS composto por trs mdulos independentes. O primeiro o servidor HNS

que prov a estrutura para o armazenamento da HoloTree juntamente com a implementao
do protocolo de comunicao para interagir com as HoloVMs. O segundo mdulo
implementa uma camada de comunicao entre a HoloVM e o servidor HNS. Este mdulo
disponibiliza mtodos para anunciar a criao de entes, suas aes de mobilidade, bem
como fazer consultas a respeito da estrutura da DHoloTree juntamente com o endereo dos
entes que a compem. O terceiro mdulo responsvel pela comunicao entre HoloVMs e
consiste de duas partes. Uma delas um servidor acoplado na HoloVM que fica
aguardando por requisies. Este servidor tem acesso a todas as estruturas de dados dos
entes em execuo na HoloVM e capaz de executar consultas locais e retornar o resultado
para HoloVMs remotas. A outra parte responsvel por fazer requisies sempre que um
ente precise interagir com algum ente disponvel em outra HoloVM.

3.4 Concluso
Este captulo apresentou o Holoparadigma juntamente com os modelos propostos
para dar suporte execuo distribuda de programas que o utilizam. Atravs de abstraes

55
simplificadas para a representao de ambientes onde aplicaes mveis executam, ele
apresenta uma proposta inovadora para o desenvolvimento de aplicaes distribudas.
Tambm apresentado neste captulo uma mquina virtual chamada HoloVM. ela
quem oferece suporte execuo de programas baseados em byte code Holo. A HoloVM
oferece suporte nativo a todas as caractersticas do paradigma permitindo que servios
sejam implementados diretamente no ambiente que suporta a execuo. Esta caracterstica
permite que programas possam ser mapeados diretamente para instrues da VM.
Duas solues foram propostas para oferecer suporte execuo distribuda.
Inicialmente foi implementado o HS para uma validao preliminar. Dadas s diversas
limitaes do HS, o HNS foi proposto de modo a suprir as limitaes do HS. Atravs do
HNS programas Holo podem empregar de maneira distribuda diversos conceitos expostos
pelo Holoparadigma.
Entretanto, at ento o Holoparadigma suportava apenas a mobilidade lgica, sendo
a mobilidade de cdigo presente apenas na especificao. Com o objetivo de preencher esta
lacuna, o prximo captulo apresenta o modelo de mobilidade forte de cdigo desenvolvido.

56

4. HoloGo Mobilidade de Cdigo na HoloVM

Este captulo apresenta o modelo proposto para mobilidade forte de cdigo. O
objetivo deste modelo disponibilizar esta funcionalidade entre HoloVMs. Este modelo
pode ser visto como uma camada de software acoplada a HoloVM de modo a oferecer a
mobilidade forte de cdigo sem a necessidade de modificao na Hololinguagem. Antes de
HoloGo a HoloVM suportava apenas a mobilidade lgica de entes.

4.1 Modelo Proposto

Sendo utilizada como plataforma de execuo para programas baseados em byte
code Holo, a HoloVM, em uma analogia com o framework apresentado no Captulo 2, pode
ser vista como um ambiente computacional. Neste sentido, o ente quem ir se mover entre
HoloVMs e pode ser visto como uma unidade de execuo. A Figura 4.1 mostra a HoloVM
inserida no contexto do framework apresentado.

Figura 4.1 - Sistema de Cdigo Mvel tendo a HoloVM como ambiente computacional

O objetivo do modelo disponibilizar na HoloVM a mobilidade forte de cdigo, ou

seja, o ente alm de se mover, move consigo o seu estado de execuo que composto por
duas pilhas (operandos e controle), interface, comportamento e histria. A estrutura interna
de um ente mostrada na Figura 4.2.

57

Figura 4.2 - Estrutura interna de um ente.

Os seguintes passos [32] so necessrios para obteno da mobilidade forte de

cdigo entre entes:
Parar a execuo de um ente;
Serializar os dados de um ente;
Transmitir os dados de um ente para outro ambiente;
Reconstruir, a partir dos dados recebidos, o ente e seu estado de execuo no
ambiente destino.
Toda a funcionalidade referente aos passos necessrios disponibilizada por
HoloGo. Um ente ao necessitar de uma mobilidade de cdigo utiliza as funcionalidades
disponibilizadas por HoloGo. Neste sentido ele quem efetiva os passos necessrios para a
execuo de uma mobilidade de cdigo. Ao ser recebido por outra HoloVM, o HoloGo da
HoloVM de destino quem ir, a partir dos dados serializados recebidos, recriar o ente e
reiniciar sua execuo inserindo-o na HoloTree. Na verso atual de HoloGo, caso o ente
sendo movido esteja aguardando pelo resultado de uma ao, este invariavelmente espera
por este retorno.

58
O suporte oferecido pelo HNS uma pea essencial deste modelo, pois atravs das
funcionalidades dele que os entes podem obter informaes de localizao a respeito de
outros entes. Ao executar uma mobilidade, atravs do comando move, o ente estar, de
maneira implcita, perguntando ao HNS qual a localizao de seu ente destino. Ao receber
esta informao, as medidas necessrias para executar a mobilidade podem ser tomadas.
Neste sentido a mobilidade de cdigo acontece de maneira implcita, ou seja, o ente
executando o comando move no sabe de antemo se ele necessitar ser movido para outra
HoloVM. Esta abordagem reduz o esforo de desenvolvimento de uma aplicao, no
sentido que a mobilidade forte explicitada por apenas uma instruo.
A Figura 4.3 mostra a comunicao realizada por HoloGo entre as HoloVMs e o
HNS no momento em que um ente executa uma mobilidade. No passo um, ao executar a
mobilidade, a HoloVM pergunta ao HNS onde est localizado o ente destino. No passo dois
a resposta obtida. No passo trs a HoloVM comunica-se diretamente com a HoloVM de
destino e a mobilidade de cdigo efetivamente executada. No passo quatro a HoloVM de
destino informa ao HNS a localizao no novo ente e no passo cinco o HNS atualiza sua
estrutura.

Figura 4.3 - Passos realizados no momento de uma mobilidade de cdigo.

59
A mobilidade forte de cdigo em HoloGo pode ser pr-ativa ou reativa. Um ente
pode executar uma ao em outro ente que pode vir a resultar em uma mobilidade de
cdigo deste ente onde a ao foi executada, caracterizando assim uma mobilidade de
cdigo reativa. Da mesma maneira, o prprio ente pode mover-se para outro ambiente
caracterizando uma mobilidade de cdigo pr-ativa.
Os recursos utilizados por um ente no momento de sua migrao podem ser tratados
de acordo com quatro tcnicas [21]: remover o vnculo e referenciar o recurso atravs da
rede, vincular novamente o recurso no ambiente de destino, copiar o recurso juntamente
com o ente ou ainda mover o recurso junto com o ente. Dependendo do tipo de recurso
sendo utilizado uma opo pode ser mais vantajosa em detrimento de outra. Certos tipos de
recursos podem ser descartados, sabendo-se de antemo que estaro disponveis no
ambiente computacional (HoloVM) de destino. Outros, como por exemplo um arquivo no
existente no ambiente de destino, devem ser tratados de outra maneira.
Uma questo chave a ser tratada quando da ocorrncia de uma mobilidade forte de
cdigo refere-se ao tratamento da Constant Pool. Haja visto que ela carregada no
momento em que o arquivo contendo a descrio de um programa Holo lido do disco, e
que a posio de cada smbolo armazenado nela est diretamente relacionada com o byte
code executado, sua modificao em tempo de execuo torna-se dificultada. Desta
maneira esta questo foi abordada adotando-se a poltica de ao mover um ente, fazer com
que ele leve junto sua Constant Pool. Sendo assim, ao ingressar na HoloVM de destino e
reiniciar sua execuo, todas as referncias feitas Constant Pool so feitas a sua Constant
Pool local e no a Constant Pool da HoloVM destino. Atravs desta abordagem, toda vez
que um ente movido fisicamente, ele leva junto sua Constant Pool e passa a referenci-la
toda vez que uma instruo que a acesse seja executada. Esta situao mostrada na
Figura 4.4.
Um ente ainda pode estar compartilhando recursos com mais entes ao mover-se para
outro ambiente. Neste caso, se o ente leva o recurso consigo, os demais entes tero que
acessar este recurso por meio de referncias rede, ou, caso o recurso no saia do ambiente
de origem, o ente movido deve acess-lo atravs da rede. Em ambientes onde a conexo de
rede limitada, como um ambiente de dispositivos mveis conectados atravs de conexes

60
sem fio, esta abordagem pode ocasionar falhas de execuo. Neste contexto um recurso
pode ser considerado fixo ou mvel. Um recurso fixo est permanentemente ligado a uma
HoloVM, enquanto que um recurso mvel pode ser movido ou copiado para outras
HoloVMs. Neste trabalho, o nico recurso tratado em uma mobilidade de cdigo a
Constant Pool que movida juntamente com o ente sendo movido.

Figura 4.4 - Cpia da Constant Pool em uma mobilidade de cdigo

Uma possvel abordagem para facilitar o gerenciamento de recursos seria fazer com
que a HoloVM, alm de exportar ao HNS a localizao dos entes que nela executam,
exporte tambm informaes sobre os recursos disponveis. Desta maneira, um ente poderia
consultar atravs do HNS sobre demais ambientes que possuam os recursos necessrios
para sua execuo. Atravs destas informaes um ente poderia escolher ambientes
computacionais baseado nos recursos disponveis por eles.
Em HoloGo, um ente composto ao ser movido leva consigo seus entes
componentes. Ao detectar uma mobilidade de cdigo, o ente composto deve avisar seus
entes componentes a respeito para que estes parem suas execues e estejam aptos a serem
movidos. As aes que um ente tenha invocado e ainda no tenha recebido resposta devem
ser aguardadas antes de uma mobilidade de cdigo. Desta maneira a mobilidade no
acontece de maneira imediata nestes casos.
Do ponto de vista da HoloTree, ao mover um ente composto, todo um ramo da
rvore movido enquanto que a mobilidade de um ente elementar implica na

61
movimentao de uma folha da rvore. A mobilidade de cdigo de um ente composto
mostrada na Figura 4.5. Os mesmos passos (denotados pelos nmeros nas setas) realizados
na mobilidade de cdigo mostrada na Figura 4.3 so realizados. A diferena que neste
caso um ramo inteiro da rvore movido ao invs de apenas uma folha.

Figura 4.5 - Mobilidade de cdigo em um ente composto

4.2 Modificaes Realizadas na HoloVM

A fim de oferecer o suporte mobilidade forte de cdigo, diversas funes internas
HoloVM tiveram que ser modificadas. Para cada classe utilizada na execuo de um
programa baseado em byte code Holo, funes de serializao e de deserializao foram
adicionadas. As classes envolvidas diretamente na execuo de um ente so demonstradas
na Figura 4.6.
A classe BytecodeExecutor corresponde a uma thread de execuo. nesta classe
que esto contidas as funes referentes a cada um dos byte code definidos na HoloVM. As
pilhas de operando e de execuo esto contidas e so manipuladas por esta classe. Ela
tambm possui como membro uma instncia da classe ConcurrentTask onde esto contidos
o comportamento e a histria de um ente. No diagrama tambm mostrada a classe que

62
implementa a ConstantPool. ela quem mantm uma lista contendo todas as constantes
necessrias para a execuo de um ente, atuando como uma tabela de smbolos. Tanto a
classe Behavior quanto a classe History utilizam o conceito de blackboards a fim de
armazenar dados. Na classe Behavior ficam armazenadas as aes que um ente pode
executar, enquanto que a classe History utilizada para a comunicao e tambm sincronia
entre entes.

Figura 4.6 - Diagrama descrevendo as principais classes envolvidas

Ao ser realizada uma mobilidade de cdigo, o contedo destas classes que deve
ser salvo e enviado ao ambiente computacional de destino.
Os mdulos referentes comunicao entre HoloVMs tambm foram modificados.
Toda a estrutura legada foi aproveitada. Sendo assim, utilizou-se o mesmo padro de envio
e recebimento de mensagens entre HoloVMs. O formato de uma mensagem que contm um
ente mostrado na Figura 4.7.

Figura 4.7 - Formato da mensagem utilizada para enviar um ente

63
O campo Ente identifica ao ente sendo movido. O campo Pai identifica ao ente
no qual o ente movido ser inserido. O campo Tipo especifica o tipo da mensagem sendo
enviada. Ele utilizado na decodificao da mensagem pelo mdulo servidor da HoloVM
de destino. O ltimo campo da mensagem corresponde aos dados serializados que
compreendem o ente sendo enviado. No caso de um ente composto, seus entes filho so
enviados tambm atravs deste campo.
O cdigo original da instruo move foi modificado de modo a prover a mobilidade
forte de cdigo. A Figura 4.8 mostra o cdigo da instruo em sua verso original.
Excees e verificaes de erro foram eliminadas de modo a favorecer a legibilidade do
cdigo fonte.
1
2
3
4
5
6
7
8
9
10
11
12
13
14

string source
string target

= pop().valueToStr();
= pop().valueToStr();

if((*_dynamicBeings)[target]== NULL){
remote_father = true;
HVMClient c((*_dynamicBeings)[source],host);
c.move(target);
}
else{
remote_father = false;
(*dynamicBeings)[source]->out()->dec_beings_in();
(*dynamicBeings)[target]->inc_beings_in();
(*dynamicBeings)[source]->out(*dynamicBeings[target]);
}

Figura 4.8 - Cdigo original da instruo move

Ao ser executada, a instruo move espera que dois argumentos estejam contidos na
pilha de operandos: o ente a ser movido (source) (linha 1) e o ente para onde este ente deve
ser movido (target) (linha 2). Antes da concepo de HoloGo apenas a mobilidade lgica
era oferecida. Desta forma, quando uma instruo move era executada, a HoloVM
inicialmente pesquisava pelo local deste ente de destino (target) (linha 4). Caso este ente
estivesse situado localmente, apenas o ponteiro para o ente pai deste ente sendo movido era
modificado de modo a refletir a nova configurao, como mostrado no cdigo da linha 10
at a linha 13. Caso este ente no estivesse localizado na mesma HoloVM, apenas uma
varivel (remote_father) era modificada de modo a indicar que este ente possui um pai que
no estava localizado nesta HoloVM como visto no cdigo da linha 5 a linha 7. Neste caso,
qualquer mensagem deste ente para seu pai resultaria em uma mensagem enviada pela rede.

64
Em ambos os casos (target local ou target remoto), as modificaes realizadas na rvore
so comunicadas ao HNS para que este possua uma viso precisa do ambiente de execuo
distribudo.
As modificaes introduzidas no cdigo da HoloVM de modo a oferecer suporte
mobilidade forte de cdigo so mostradas na Figura 4.9. Verificaes de condies de erro,
bem como tratamento de excees tambm foram removidas do cdigo de modo a
promover a legibilidade do cdigo fonte.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

string source = pop().valueToStr();

string target = pop().valueToStr();
if((*_dynamicBeings)[target]== NULL){
(*dynamicBeings)[source]->WaitForChilds();
(*dynamicBeings)[source]->SaveStatus();
HVMClient c((*_dynamicBeings)[source],host);
Address* addr = c.GetBeingHVmAddress(target);
c.SendBeing(addr,source,target);
(*dynamicBeings)[source]->StopVM = true;
}
else{
remote_father = false;
(*dynamicBeings)[source]->out()->dec_beings_in();
(*dynamicBeings)[target]->inc_beings_in();
(*dynamicBeings)[source]->out(*dynamicBeings[target]);
}

Figura 4.9 - Cdigo da instruo move modificado

Atravs do uso de HoloGo, ao ser executada uma instruo move, a HoloVM

tambm pesquisa pelo local referente ao ente de destino (ente target). Caso este esteja
situado localmente, apenas a mobilidade lgica executada como no caso anterior (linhas
12 a 15). Caso contrrio a HoloVM notifica os entes filhos deste ente prestes a ser movido
para que estes parem sua execuo (linha 4). Aps o estado de execuo deste ente,
juntamente com o estado de execuo dos entes filhos (caso haja algum) salvo (linha 5).
Neste ponto o mdulo cliente da HoloVM utilizado para enviar o ente serializado para a
outra HoloVM. Sendo assim, uma interao com o HNS feita atravs da instanciao de
um objeto da classe HVMClient que quem disponibiliza as funes referentes parte
cliente da HoloVM. Este objeto instanciado requisita ao HNS o endereo da HoloVM onde
o ente de destino est localizado. De posse desta informao o ente pode ser enviado
HoloVM de destino. Aps o envio, a HoloVM seta a varivel StopVM como verdadeira

65
no ente que foi enviado de modo que sua execuo nesta HoloVM seja interrompida. Desta
maneira todas as estruturas alocadas por este ente so retiradas da memria.
O estado de execuo de um ente, quando salvo, empacotado em uma mensagem
como a mostrada na Figura 4.7. Ao chegar HoloVM de destino, quem manipula esta
mensagem o mdulo servidor da HoloVM. Implementado atravs da classe HVMServer,
este mdulo fica constantemente aguardando por requisies em uma porta especfica.
Desta maneira, ao receber uma mensagem, inicialmente a mesma carregada e seu tipo
verificado. Caso seja uma mensagem contendo um ente, esta classe invoca as rotinas
necessrias para que o ente seja instanciado novamente e seu estado de execuo
recuperado. Aps isso, este ente inserido na HoloTree da HoloVM que o recebeu e sua
execuo reiniciada do ponto onde ela havia parado anteriormente.
Atravs desta abordagem, aplicaes que utilizam mobilidade de cdigo podem ser
modeladas utilizando o Holoparadigma atravs da utilizao dos trs paradigmas de
desenvolvimento apresentados no Captulo 2. Um ente pode executar uma ao em seu ente
pai e esta ao pode resultar em um ente irmo sendo movido para dentro dele,
caracterizando desta maneira o paradigma COD (Code on Demand). Outro cenrio possvel
um ente que envia um ente filho para outra HoloVM a fim deste executar uma tarefa.
Neste caso esta mobilidade estaria caracterizando o paradigma REV (Remote Evaluation).
Um ente ainda pode decidir mover-se por sua prpria vontade, caracterizando assim o
paradigma MA (Mobile Agent).
Outra caracterstica desta abordagem que ao oferecer a mobilidade forte de
cdigo, provida tambm a mobilidade fraca. Um ente ao ser movido pode carregar
consigo apenas o cdigo de outro ente e instanci-lo atravs do comando clone em
diferentes HoloVMs. Desta maneira, um ente pode viajar pelo ambiente instanciando novos
entes em cada ambiente computacional por onde ele passa.

4.3 Concluso
Este captulo apresentou detalhadamente o modelo de mobilidade forte de cdigo
desenvolvido com o Holoparadigma em mente. Dentre suas principais caractersticas
encontra-se a facilidade de desenvolvimento de uma aplicao que utilize mobilidade forte

66
de cdigo, visto que a mesma ocorre de maneira transparente para o desenvolvedor atravs
do comando move. Outra caracterstica deste modelo que ele no impe nenhuma
modificao a Hololinguagem, fazendo com que programas escritos anteriormente
continuem funcionando mesmo aps sua implementao.
Diversos sistemas de cdigo mvel so baseados na linguagem Java [25]. A maioria
destes sistemas, entretanto, disponibiliza apenas mobilidade de cdigo fraca dado que
diversas dificuldades devem ser transpostas na implementao de mobilidade forte nesta
plataforma [40] [10]. A maioria destas dificuldades refere-se ao tratamento de threads.
Dado que o cdigo da JVM mantido por uma empresa privada, solues para mobilidade
forte nesta plataforma implicam em um custo de implementao elevado onde diversas
questes devem ser levadas em conta. Neste sentido, a HoloVM sendo uma mquina
virtual com cdigo aberto e desenvolvida especialmente para suportar programas baseados
no Holoparadigma, facilita o desenvolvimento de uma soluo baseada em mobilidade forte
de cdigo.
Questes referentes implementao do modelo sero apresentadas no prximo
captulo.

67

5. Aspectos de Implementao
Antes de iniciar o processo de prototipao do modelo proposto, um estudo das
estruturas internas a HoloVM foi realizado. Atravs deste estudo, foram identificadas todas
as estruturas necessrias a uma mobilidade forte de cdigo. Foi constatado tambm que a
HoloVM no foi projetada de modo a prover esta funcionalidade. Esta caracterstica
impactou em dificuldades quando da implementao do modelo.

5.1 Descrio do Prottipo

HoloGo foi implementado em ANSI C++ de modo a ser compatvel com qualquer
plataforma para a qual a HoloVM seja portada. Toda a troca de mensagens entre HoloVMs
no que diz respeito mobilidade de cdigo realizada atravs dos mdulos de software
disponibilizados pelo HNS e pelos mdulos cliente e servidor acoplados a cada HoloVM.
Nesta abordagem, uma HoloVM assume o papel de servidor, de cliente, ou at mesmo
ambos os papis. Na implementao atual no foram considerados obstculos
constantemente presentes em uma rede aberta, tais como NATs e firewalls.
Nenhuma modificao referente mobilidade de cdigo foi realizada no servidor
HNS. Modificaes foram realizadas apenas nos mdulos servidor e cliente da HoloVM,
onde funcionalidades de envio e recebimento de byte code Holo foram adicionadas. Nas
modificaes realizadas nestes mdulos toda a estrutura original foi mantida. O protocolo
utilizado na comunicao entre HoloVMs foi estendido de modo a suportar o envio e
recebimento de entes. Neste sentido apenas as classes envolvidas diretamente nesta
comunicao tiveram que ser modificadas. Os passos realizados pelo prottipo no momento
de uma mobilidade de cdigo so mostrados no diagrama de seqncia da Figura 5.1.

68

Figura 5.1 - Diagrama de seqncia de uma mobilidade de cdigo

As funes de serializao e deserializao das classes envolvidas na execuo de

byte code Holo foram implementadas com a utilizao da biblioteca Boost [29]. A Boost
uma biblioteca de classes desenvolvida em ANSI C++. Atravs de uma semntica simples,
a adio destas funcionalidades, tanto em classes simples quanto em classes complexas
tornou-se bastante facilitada, reduzindo desta maneira a complexidade requerida no
processo de desenvolvimento. Atravs do uso desta biblioteca o formato das mensagens
enviadas em uma mobilidade de cdigo torna-se bastante flexvel. No prottipo atual elas
so transmitidas em formato texto, mas com modificaes mnimas no cdigo fonte este
formato pode ser modificado para o formato binrio ou at mesmo XML.
Outra biblioteca utilizada na implementao do prottipo foi a coleo de classes
PACC [36]. Esta biblioteca tambm foi desenvolvida em ANSI C++ de modo a ser portvel
entre diferentes plataformas. Ela disponibiliza classes para comunicao em rede (TCP /
UDP) bem como classes para a criao e gerenciamento de threads, oferecendo assim uma
abstrao nica tanto para ambiente Windows quanto para ambiente Unix. A HoloVM
antes da concepo de HoloGo j utilizava esta biblioteca. Desta maneira toda a

69
comunicao relativa mobilidade forte de cdigo foi implementada utilizando as classes
previamente disponibilizadas por esta biblioteca.

5.2 Funcionalidades Introduzidas no Ambiente

Visando facilitar o desenvolvimento de aplicaes que utilizem mobilidade de
cdigo, trs novas funcionalidades foram acrescentadas ao ambiente. A primeira delas
compreendeu a concepo de um novo tipo de ente. A segunda implicou na adio de
funcionalidades ao HNS e a terceira compreendeu a adio de dois novos comandos
Hololinguagem.
O novo tipo de ente chamado de ente holder. Este ente tem apenas o papel de ficar
parado esperando que entes entrem nele de modo a executar uma tarefa. A Figura 5.2
mostra o cdigo fonte de um ente holder.
Holo()
{
holo()
{
clone(holder,holder);
}
}
holder()
{
holder()
{
history#DONE;
}
}

Figura 5.2 - Cdigo fonte de um ente holder

O funcionamento de um ente deste tipo bastante simples. Ao ser instanciado ele

fica aguardando pela escrita de uma tupla contendo a string DONE em sua histria.
Enquanto isso no acontece, ele fica apenas aguardando e servindo como um lugar onde
entes podem entrar de modo a executar tarefas.
No momento em que um ente deste tipo instanciado em uma HoloVM, o HNS
notificado como ocorre na instanciao de qualquer ente, e adicionalmente atualiza uma
lista com a localizao de todos os entes holder presentes no ambiente distribudo. A
localizao de cada holder mantida atravs do nome do host que o contm. Esta

70
informao agregada ao nome deste ente de modo a diferenciar entes holder em diferentes
locais (ambientes computacionais). Desta maneira uma aplicao Holo pode perguntar ao
HNS quantos ambientes computacionais presentes no ambiente distribudo esto aptos a
receber entes em um determinado momento.
Ambos os comandos adicionados linguagem interagem diretamente com o HNS
de modo a obter informaes a respeito do ambiente de execuo distribudo. A Tabela 5.1
descreve os comandos introduzidos.
Tabela 5.1 - Comandos adicionados Hololinguagem
Comando

Descrio

getvms

Retorna o nmero de entes

holder
em
execuo
no
ambiente distribudo.

getfreevm

Retorna o prximo ente

holder que no contenha
nenhum ente executando

O comando getvms retorna o nmero de HoloVMs que contenham entes do tipo

holder executando. O comando getfreevm retorna o nome de um ente holder que esteja
livre. Na implementao atual, um ente holder pode estar livre (nenhum ente executando
dentro dele) ou ocupado (pelo menos um ente executando dentro dele). Neste sentido o
comando getfreevm tentar encontrar um ente holder que esteja livre e retornar seu
nome para o programa Holo que o invocou.
Esta abordagem visa apenas criar uma infra-estrutura de software que torne mais
fcil o desenvolvimento e tambm a validao de aplicaes Holo que utilizem a
mobilidade forte de cdigo. Em uma implementao mais aprimorada o HNS poderia
utilizar mais informaes a respeito de cada ente holder de modo a explorar melhor a
distribuio de entes entre ambientes computacionais. Entretanto uma abordagem deste tipo
est fora do escopo deste trabalho, que est focado na validao do modelo de mobilidade
forte de cdigo proposto.

71

5.3 Resultados Experimentais

Quando da ocorrncia de uma mobilidade de cdigo, trs elementos determinam o
tempo necessrio para que a mesma ocorra: tempo de serializao, tempo de envio
HoloVM de destino e tempo de deserializao.

Sendo assim, experimentos foram

realizados de modo a medir os tempos necessrios para cada um destes elementos.

Inicialmente foram realizados os experimentos referentes aos tempos de serializao
e deserializao. Neste sentido, um ente elementar foi criado para computar os tempos de
serializao e deserializao. Este mesmo ente foi utilizado para os experimentos realizados
com entes compostos. Nestes experimentos outros entes foram movidos para dentro dele
antes da serializao. Os resultados obtidos neste experimentos so mostrados na Tabela
5.2.
Estes experimentos foram realizados em uma mquina com um processador Athlon
XP 1.8 Ghz com 512 Mb de memria RAM utilizando o sistema operacional Windows XP
Professional.
Tabela 5.2 - Tempos de serializao e deserializao
Nmero de entes
filhos
0
1
2
3

Tempo de
Serializao (s)
0,015
0,016
0,017
0,018

Tempo de
Deserializao(s)
0,015
0,016
0,017
0,018

Desvio
Padro
0,0008
0,0009
0,0009
0,0010

Os resultados apresentados nas colunas dois e trs so uma mdia de dez execues.
Comparando os tempos obtidos na serializao e deserializao de um ente elementar com
os tempos obtidos com um ente composto contendo apenas um filho, observa-se um
crescimento de apenas um milisegundo. No prottipo atual de HoloGo, em um ente
composto, todos os entes componentes compartilham a mesma Constant Pool. Desta
maneira, ao se mover um ente elementar ou um ente composto, somente uma instncia da
Constant Pool movida. Alm disso, verifica-se que o tempo de serializao aumenta
linearmente na medida em que so acrescentados entes componentes.
Visando obter o tempo necessrio para o envio de um ente a outro ambiente
computacional, o mesmo ente utilizado no experimento anterior foi serializado, enviado a

72
outro ambiente onde foi deserializado e enviado de volta ao ambiente de origem. O
esquema utilizado para esta medio mostrado na Figura 5.3. O tempo necessrio para
completar a operao foi computado no ambiente computacional A, onde o ente foi
instanciado e enviado ao ambiente computacional B. A fim de obter somente o tempo de
envio, os tempos de serializao e deserializao em ambos os ambientes computacionais
foram subtrados do tempo total.

Figura 5.3 - Configurao utilizada no experimento

Para este experimento apenas duas mquinas foram utilizadas. Ambas com
processador Athlon XP 2800 com 512 Mb de memria RAM utilizando o sistema
operacional Windows XP Professional e conectadas atravs de uma rede ethernet de 10
Mbits.
A mesma abordagem do primeiro experimento foi utilizada. Inicialmente foi
enviado um ente elementar. Em um segundo instante foi enviado um ente composto com
apenas um filho. Em seguida o experimento foi repetido com entes compostos com dois e
trs filhos. Os resultados obtidos e mostrados na Tabela 5.3 so uma mdia de dez
execues e correspondem somente ao tempo necessrio para o envio de um ente a outro
ambiente computacional.
Tabela 5.3 - Tempo de envio de um ente
Nmero de
entes filhos
0
1
2
3

Tempo (s)

Desvio Padro

0,010
0,015
0,020
0,025

0,002
0,002
0,003
0,002

Atravs dos dados obtidos, observa-se uma tendncia linear no tempo de envio dos
entes. medida que entes filhos so adicionados hierarquia, o tempo cresce
proporcionalmente. O ente utilizado neste experimento possui somente uma ao que

73
realiza o clculo da srie de Fibonacci. O grfico da na Figura 5.4 mostra a tendncia linear
obtida neste experimento.

Figura 5.4 - Tempo de envio

O tempo pode variar de acordo com o nmero de aes contidas no ente, pois um
ente enviado a outro ambiente computacional na forma de uma seqncia de bytes. Neste
sentido, quanto mais aes ou entes filhos um ente tiver, maior ser sua seqncia de bytes
e, consequentemente, maior ser o tempo necessrio para o seu envio.

5.4 Concluso
Este captulo apresentou detalhes especficos da implementao do HoloGo
juntamente com resultados referentes aos passos de serializao, deserializao e envio de
entes envolvidos em uma mobilidade de cdigo. HoloGo foi desenvolvido inteiramente em
ANSI C++ de modo a ser compatvel com uma diversa gama de sistemas operacionais e
dispositivos e tambm facilitando sua integrao com a HoloVM. Funes de serializao e
deserializao foram acrescentadas s estruturas envolvidas na execuo de um ente. O uso
das bibliotecas Boost e PACC facilitou o processo de desenvolvimento.

74
Tendo apresentado os detalhes especficos referentes implementao do modelo
juntamente com experimentos iniciais, o prximo captulo apresenta aplicaes
desenvolvidas que utilizam mobilidade de cdigo atravs das funcionalidades oferecidas
por HoloGo.

75

6. Aplicaes
Visando situar o modelo desenvolvido no contexto real de aplicaes, neste captulo
sero apresentados cenrios que se beneficiam da utilizao de mobilidade de cdigo. Para
cada um dos cenrios apresentados, um programa utilizando a Hololinguagem juntamente
com HoloGo, foi desenvolvido e testado.

6.1 Ganho de Desempenho

O primeiro cenrio modelado compreendeu uma aplicao que visa o ganho de
desempenho na execuo de uma tarefa computacionalmente intensa. Esta aplicao possui
como entrada uma tarefa (denotada por uma matriz) a ser executada e, baseada nos recursos
disponveis no ambiente, esta tarefa dividida em pedaos iguais. Cada pedao da tarefa
atribudo a um ente que se move para um ente do tipo holder a fim de aplicar o
processamento ao seu pedao da tarefa. Neste sentido, o ente que se move carrega os dados
(pedao da tarefa) e tambm o cdigo a ser aplicado. Utilizando esta abordagem um novo
algoritmo pode ser adicionado aplicao apenas inserindo uma nova ao no ente que o
aplica. A Figura 6.1 mostra o cdigo referente ao ente que se move para um ente do tipo
holder.
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Task()
{
Task(task,Target_Being)
{
move(self,Target_Being);
DoTask(task);
move (self,launch);
}
DoTask(task)
{
...
}
}

Figura 6.1 - Trecho de cdigo fonte da aplicao focada em ganho de desempenho

Inicialmente a aplicao requisita ao HNS a quantidade de entes do tipo holder

disponveis no ambiente. Baseado nesta informao a aplicao divide a tarefa a ser
executada e para cada parte da tarefa um ente instanciado e move-se para um dos entes
holder do ambiente.

76
O cdigo localizado entre as duas instrues move na linha 6 executado em uma
mquina remota. Ao ser clonado, o ente descrito na Figura 6.1 recebe como argumento o
nome de um ente do tipo holder para onde ele deve se mover juntamente com o pedao da
tarefa a ser processada. O primeiro comando executado por este ente (linha 5) um
comando move que efetiva a mobilidade de cdigo. Depois de executar a tarefa na mquina
remota este ente volta para a mquina de origem atravs de outra chamada ao comando
move (linha 7).
Os testes foram realizados com quatro tamanhos diferentes de entradas: 500x500,
1000x100, 2000x2000 e 4000x4000 respectivamente. Os resultados obtidos demonstram
que a tendncia manteve-se a mesma para todas as entradas. Executando a aplicao com
apenas uma mquina disponvel no ambiente e utilizando uma entrada de tamanho
1000x1000, o tempo mdio de execuo foi de 19.72 segundos. Na medida em que mais
mquinas entraram no ambiente e anunciaram seus entes holder para o HNS, a aplicao
pode perceber esta mudana e dividir a tarefa entre estas mquinas. Sendo assim,
executando a aplicao com duas, trs e quatro mquinas no ambiente os tempos mdios
obtidos foram 8.94, 6.50 e 5.70 segundos respectivamente.
A Figura 6.2 sumariza os resultados apresentados na Tabela 6.1 que foram obtidos
executando os experimentos em um ambiente de testes. Trs computadores Athlon XP com
512 MB de memria RAM com sistema operacional Windows XP juntamente com um
computador Pentium IV tambm com 512 MB de memria RAM foram utilizados para
realizar os experimentos. Um computador Core 2 Duo com 1 GB de memria RAM com
sistema operacional Windows XP foi utilizado para o gerenciamento da aplicao. Cada um
dos experimentos foi executado dez vezes.

77

Figura 6.2 - Tempo de execuo X Nmero de mquinas

Tabela 6.1 - Tempo de execuo X Nmero de mquinas
1
500x500
1000x1000
2000x2000
4000x4000

Mdia
10.26
19.72
41.37
82.55

2
D. P.
0.93
0.55
0.36
0.65

Mdia
5.62
9.72
19.91
41.62

3
D. P.
0.25
0.51
0.25
0.33

Mdia
3.39
6.51
12.63
24.71

4
D.P.
0.09
0.31
0.29
0.22

Mdia
1.77
5.71
9.41
20.22

D.P.
0.04
0.37
0.32
0.24

Existem outros fatores que influenciam no tempo total de execuo como a latncia
da rede e o tamanho de um ente serializado. Neste experimento, entretanto, o foco principal
a funcionalidade do modelo de mobilidade de cdigo desenvolvido. Neste sentido
HoloGo mostrou-se uma alternativa vivel para a reduo do tempo total de execuo de
uma tarefa computacionalmente intensa e, ao mesmo tempo em que aproveitou os recursos
oferecidos pelo ambiente.

6.2 Gerenciamento de Rede

A demanda por uma quantidade cada vez maior de informaes de gerenciamento,
aliada ao aumento dos requerimentos de confiabilidade exigidos por aplicaes que
executam em ambiente de rede torna a utilizao de cdigo mvel uma alternativa para este
tipo de cenrio. Atualmente o protocolo SNMP um dos mais utilizados para a obteno de
informaes gerenciais. Utilizando uma abordagem centralizada, questes referentes

78
escalabilidade, flexibilidade e desempenho tornam-se prejudicadas [17]. Neste sentido, a
utilizao de agentes mveis para executar tarefas de gerenciamento de rede apresenta-se
como uma possvel soluo para estes ambientes, pois estes so menos sensveis latncia
e tambm a largura de banda [17].
Com isso em mente o segundo cenrio modelado apresenta um ambiente composto
por diferentes mquinas, das quais se quer obter informaes gerenciais. Neste sentido, a
aplicao desenvolvida compreende um ente que viaja de modo a coletar informaes a
respeito de cada ambiente computacional por onde ele passa. Uma aplicao Holo instancia
um ente que requisita ao HNS informaes a respeito do ambiente. De posse destas
informaes o ente inicia sua viajem e, por cada ambiente computacional por onde ele
passa, ele executa uma ao que pesquisa pelos recursos existentes. Esta informao a
respeito dos recursos disponveis em cada ambiente fica armazenada no ente que, ao
retornar para a estao de origem leva estas informaes para seu ente pai. A Figura 6.3
mostra o cdigo fonte desta aplicao.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

holo()
{
holo()
{
getvms(N);
for (X := 1 to N){
getfreeVM(FreeVM);
VMS[X] := FreeVM;
}
clone(agent(VMS),null);
}
agent()
{
agent(ListVMS)
{
for X := 1 to listsize(ListVMS){
move(self,ListVMS[X]);
getresdata(Data);
Vetor[X] := Data;
}
move(self,holo); //Retorna ao ambiente computacional
//de origem levando junto o vetor
//com os dados coletados
}
}

Figura 6.3 - Cdigo fonte da aplicao de gerenciamento

79
Neste cdigo, inicialmente um vetor carregado com informaes referente ao
ambiente (linhas 5 a 9). Tendo este vetor carregado, a aplicao instancia o ente agent que
ir viajar pelo ambiente. Este ente recebe como argumento o vetor contendo as mquinas
para onde ele deve se mover. O cdigo executado pelo ente agente (linhas 16 a 22) um
lao que itera pelo vetor que contm as mquinas do ambiente. Para cada mquina que o
agente visita ele executa o comando getresdata que obtm os seguintes dados a
respeito do ambiente computacional: endereo IP, nmero de processadores, velocidade do
processador, quantidade de memria RAM e espao livre em disco. medida que o ente
viaja ele coleta estas informaes e armazena elas em um vetor (linha 20). Depois de viajar
por todo o ambiente o ente retorna a mquina que o lanou com o vetor contendo em cada
posio os dados referentes a cada mquina por onde ele passou. A Figura 6.4 mostra este
cenrio.

Figura 6.4 - Ambiente utilizado para testar a aplicao de gerenciamento de rede

Um ambiente de testes composto de cinco mquinas foi utilizado para a execuo

desta aplicao: trs mquinas com processador AMD Athlon XP 2000 com 512 Mb de
memria RAM, uma mquina com processador Intel core 2 duo com 1 Gb de memria
RAM e um Tablet PC com processador Intel Centrino 1.5 Ghz com 512 Mb de memria
RAM. O sistema operacional utilizado por todas as mquinas deste experimento foi o
Windows XP Professional, com exceo do Tablet PC que utilizou o sistema operacional

80
Windows XP Tablet PC Edition. O contedo do vetor ao retornar a mquina que o lanou
mostrado na Tabela 6.2.
Tabela 6.2 - Contedo do vetor aps o ente percorrer o ambiente
ndice

IP

Nmero de
Processadores

Velocidade
Processador

Memria
Ram

Espao livre
em disco

1
2
3
4
5

10.17.174.29
10.17.174.208
10.17.174.111
10.17.174.79
10.17.174.51

2
1
1
1
1

1830 MHz
1850 MHz
1850MHz
1850 MHz
1054 MHz

1 Gb
512 Mb
512 Mb
512 Mb
512 Mb

64.8 Gb
17.4 Gb
23.8 Gb
12.4 Gb
31.7 Gb

Nesta aplicao o foco principal novamente foi a funcionalidade provida por

HoloGo. Com poucas modificaes esta aplicao pode ser utilizada para outros fins, como
por exemplo, descoberta de recursos. Neste contexto um ente pode viajar pelo ambiente a
procura de algum recurso especfico necessrio para a execuo de alguma tarefa.

6.3 Computao Ubqua

A mobilidade de cdigo uma parte importante no desenvolvimento de um sistema
de computao ubqua. Dentre suas principais utilizaes encontram-se a adaptao
dinmica a ambientes inteligentes, a adio automtica de funcionalidades a aplicaes e a
implementao da semntica follow-me [3], onde o programa viaja pelo ambiente
juntamente com o usurio.
Com isto em mente uma integrao com um projeto desenvolvido no laboratrio de
computao mvel2 da Unisinos foi realizada. Este trabalho compreende a concepo de
um servidor de localizao, chamado SELIC (Servidor de Localizao e Informao de
Contexto). O SELIC um servidor que permite que aplicaes acessem informaes sobre
localizao de dispositivos. A sua tarefa integrar diversos sistemas de localizao (GPS,
RFID, IEEE 802.11, etc.) que possuem diferentes formatos de dados para fornecer a
informao de posicionamento em uma interface de alto nvel. Para isto ele disponibiliza
uma API atravs de uma interface de Web Services de modo a facilitar a integrao com
outros sistemas. Uma adaptao neste servidor possibilitou que este exporte ao HNS,

http://www.inf.unisinos.br/mobilab

81
atravs de sua API de Web Services, informaes a respeito da localizao fsica dos
dispositivos que contenham entes holder.
A configurao deste experimento mostrada na Figura 6.5. Esta figura mostra a
planta baixa do segundo andar do prdio onde se encontra o laboratrio.

Figura 6.5 - Integrao com servidor de localizao SELIC

Uma aplicao Holo foi concebida de modo que, para qualquer dispositivo que
contenha um ente holder e entre na sala 209, um ente movido para dentro dele de modo a
coletar informaes a respeito dos recursos oferecidos pelo dispositivo que hospeda o ente.
Para isto, esta aplicao fica perguntando ao HNS a respeito da localizao dos entes. Caso
algum ente holder encontre-se dentro da sala 209, esta aplicao executa uma mobilidade
de cdigo. O cdigo fonte da aplicao que implementa este servio mostrado na Figura
6.6.
Tambm foi adicionado Hololinguagem um comando (getlocationdata) que
obtm informaes a respeito da localizao fsica dos entes holder em execuo no
ambiente. Quando este comando executado, um vetor contendo a localizao fsica de
todos os entes holder presentes no ambiente retornado aplicao. De posse destas
informaes a aplicao pode, por exemplo, mover entes somente para dispositivos que
estejam em determinada sala.

82
Na situao mostrada na Figura 6.5, um Tablet PC entrou na Sala 209 executando
um ente holder. A informao de sua localizao passada ao servidor SELIC que a
repassa para o HNS. Desta maneira, ao requisitar informao de localizao, a aplicao
que est executando descobre que este dispositivo encontra-se fisicamente localizado na
Sala 209 e automaticamente executa uma mobilidade de cdigo.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

holo()
{
holo(Location) //localizao fsica passada como parmetro
{
while(1){
getlocationdata(Vet);
for X := 1 to listsize(Vet) do {
if (Vet[X] == Location)
clone(agent(Vet[X+1]),null);
X := X + 1;
}
sleep(5000);
}
}
}
agent()
{
agent(Location)
{
move(self,Location);
getresdata(Data);
move(self,holo);
}
}

Figura 6.6 - Cdigo fonte da aplicao ubqua

Esta aplicao executa um lao infinito que a cada cinco segundos, atravs do
comando getlocationdata (linha 6), carrega um vetor com o nome e a localizao
fsica (dispositivo) dos entes holder em execuo no ambiente. Tendo este vetor carregado
a aplicao itera por ele de modo a verificar se algum ente holder se encontra fisicamente
na localizao passada como parmetro de entrada para a aplicao. Caso exista algum, o
ente agent instanciado atravs do comando clone (linha 9) , se move para o dispositivo
(linha 22), executa o comando que obtm os dados referentes aos recursos do dispositivo e
retorna ao ambiente computacional de origem com estes dados.

83

6.4 Concluso
Este captulo consolidou a utilizao de HoloGo atravs do desenvolvimento de trs
aplicaes que utilizam mobilidade de cdigo. O principal objetivo neste sentido foi
mostrar a utilizao do prottipo em cenrios reais onde a mobilidade de cdigo utilizada.
Neste sentido HoloGo mostrou-se como uma alternativa para ganho de desempenho,
gerenciamento de rede ou recursos e tambm como suporte a ambientes ubquos.
Outro aspecto a ser considerado a facilidade de desenvolvimento oferecida. A
mobilidade forte de cdigo ocorre de maneira transparente atravs do comando move,
livrando assim o desenvolvedor da tarefa de salvar e restaurar o estado de execuo de um
ente. O prximo captulo apresenta as concluses e as contribuies deste trabalho
juntamente com os trabalhos futuros.

84

7. Consideraes Finais
Esta dissertao apresentou um modelo de mobilidade forte de cdigo. Este modelo,
chamado HoloGo, disponibiliza esta funcionalidade dentro do contexto do Holoparadigma.
At ento somente a mobilidade lgica era suportada, estando a mobilidade de cdigo
apenas na especificao.
Inicialmente foram apresentados conceitos envolvendo a mobilidade de cdigo com
o intuito de adotar uma terminologia comum durante o restante do trabalho. Tambm foram
apresentados sistemas que utilizam de alguma forma a mobilidade de cdigo. A maioria dos
sistemas apresentados disponibiliza apenas a mobilidade fraca de cdigo. Outra
caracterstica comum entre os sistemas que apresentam mobilidade forte de cdigo a
utilizao de um runtime proprietrio, o que acaba dificultando a implementao de
mobilidade forte. Trs paradigmas de desenvolvimento de software direcionados
mobilidade de cdigo tambm foram apresentados.
A inteno ao apresentar estes conceitos foi introduzir de maneira sucinta o conceito
de mobilidade de cdigo enfatizando as questes relevantes dentro do contexto do
desenvolvimento de software. A partir da definio destes conceitos foi apresentado o
Holoparadigma juntamente com seu ambiente de execuo distribudo, que serviram como
base para o projeto e desenvolvimento de HoloGo.
Utilizando a HoloVM como plataforma de execuo, HoloGo foi desenvolvido de
modo a no forar nenhuma modificao na Hololinguagem. Utilizando esta abordagem,
programas Holo escritos anteriormente a HoloGo no necessitam de modificaes. Outra
caracterstica do HoloGo a facilidade de implementao de programas que utilizam
mobilidade forte de cdigo. Atravs do comando move a mobilidade de cdigo ocorre de
maneira automtica. HoloGo se encarrega de salvar o estado de execuo no ambiente
computacional de origem e restaura-lo no ambiente computacional de destino.

85
A validao de HoloGo ocorreu atravs da implementao de um prottipo. Este
prottipo possibilitou a realizao de experimentos iniciais, onde se verificou a viabilidade
da mobilidade de cdigo, tanto em entes elementares quanto em entes compostos.
Aps a implementao do prottipo, aplicaes que utilizam mobilidade de cdigo
foram desenvolvidas utilizando HoloGo. O intuito no desenvolvimento destas aplicaes
foi situar o prottipo em cenrios reais de aplicaes. Neste sentido HoloGo mostrou-se
uma alternativa para ganho de desempenho, gerenciamento de rede ou recursos e tambm
em ambientes ubquos .
Como principal contribuio, este trabalho especificou, implementou e validou a
mobilidade forte de cdigo no Holoparadigma. Antes do desenvolvimento de HoloGo, a
mobilidade de cdigo constava apenas na especificao. Com a realizao de HoloGo, alm
da mobilidade forte, foi obtida tambm a mobilidade fraca. Um ente pode se mover por
ambientes computacionais e, em cada ambiente por onde ele passa instanciar outro ente
atravs do comando clone. HoloGo ainda possibilita o desenvolvimento de programas que
utilizam mobilidade de cdigo utilizando os trs paradigmas de desenvolvimento
apresentados: COD, REV e MA.
Como trabalhos futuros tem-se a questo referente ao gerenciamento de recursos.
Na verso atual, o nico recurso sendo tratado a Constant Pool que sempre movida
junto com o ente ao ambiente computacional de destino. Dado que atualmente a
Hololinguagem no oferece funes de acesso a recursos nativos do sistema operacional
subjacente, tais como acesso a arquivos e funes especficas, o tratamento de recursos fica
prejudicado. Uma vez que estas funcionalidades estejam implementadas na Hololinguagem,
funes de tratamento destes novos recursos devero ser adicionadas ao modelo. Alm
destas funes de tratamento, opes de como os recursos sero tratados pelos entes
tambm devem ser oferecidas.
Adicionalmente ao gerenciamento de recursos, a questo referente a entes que
estejam esperando por aes de outros entes antes de serem movidos tambm deve receber
maior ateno. Na verso atual, o ente a ser movido, incondicionalmente aguarda pelo
retorno das aes que estejam executando em outros entes antes de executar sua mobilidade

86
de cdigo. Esta abordagem pode ocasionar atraso ou at mesmo uma deadlock em uma
mobilidade de cdigo. Neste sentido um tratamento mais sofisticado, que por questes de
tempo, no foi implementado neste trabalho, deve ser oferecido por HoloGo. O
desenvolvimento de mais aplicaes que utilizam a mobilidade de cdigo, situando HoloGo
em mais cenrios tambm uma questo a ser mais trabalhada.

87

Referncias Bibliogrficas
[1]

A.L. Murphy, G.P. Picco, and G.-C. Roman. LIME: A Middleware for
Physical and Logical Mobility. In F. Golshani, P. Dasgupta, and W. Zhao,
editors, Proc. of the 21st Int. Conf. on Distributed Computing Systems
(ICDCS-21), pages 524.533, May 2001.

[2]

Augustin, Iara; Yamin, Adenauer; Geyer, Claudio. Requisitos para o

projeto de aplicaes mveis distribudas. VIII Cacic Congresso
Argentino de Cincias de la Computicin. Santa Cruz Argentina. 15-20
october 2001.

[3]

Augustin, Iara. Yamin, Adenauer, Geyer, Cludio. Managing the Followme Semantics to Build Large-Scale Pervasive Applications. 3rd
International Workshop on Middleware for Pervasive and Ad-Hoc
Computing. ACM / IFIP / USENIX. Grenoble, France. 2005.

[4]

Barbosa, J. L. V. (2002). Holoparadigma: Um Modelo Multiparadigma

Orientado ao Desenvolvimento de Software Distribudo. Tese (doutorado
em cincia da computao), Instituto de Informtica, Universidade Federal
do Rio Grande do Sul, Porto Alegre. 213p.

[5]

Barbosa, J. L. V. and Geyer, C. F. R. Uma linguagem multiparadigma

orientada ao desenvolvimento de software distribudo. In Proceedings of
the V Simpsio Brasileiro de Linguagens de Programao (SBLP), 2001.

[6]

Bellfemine, Fabio, Caire Giovanni, Trucco, Tiziana, Rimassa Giovanni.

JADE
Programmers
Guide.
2003
Disponvel
em
http://sharon.cselt.it/projects/jade/doc/programmersguide.pdf Acessado em
03/2006

[7]

Bonnato, Daniel Torres; Barbosa, Jorge Lus Victria; Cavalheiro, Gerson

Geraldo Homrich. Um Suporte Computao Pervasiva para o
Holoparadigma. VI Workshop em Sistemas de Alto Desempenho
(WSCAD 2005), Rio de Janeiro, 2005

[8]

Bonatto, Daniel Torres (2005). HNS: Uma Soluo para Suporte

Execuo Distribuda Considerando Aspectos da Pervasividade.
Dissertao (mestrado em comutao aplicada) Programa Interdisciplinar
em Computao Aplicada. Cincias Exatas e Tecnolgicas. Universidade do
Vale do Rio dos Sinos, 103p.

[9]

Bray, J. and Struman, C.F., Bluetooth Connect Without Cables. PrenticeHall, Inc. 2001

88
[10]

Cabri, Giacomo, et. al. Strong Agent Mobility for Aglets based on the
IBM JikesRVM. ACM Symposium on Applied Computing. Dijon, France.
April 23-27 2006.

[11]

Cardelli, L. A Language with Distributed Scope. Computing Systems; vol.

8, no. 1, pp 27-59, 1995.

[12]

Chakravarti, Arjav J. ; Wang, Xiaojin; Hallstrom, Jason O. ; Baumgartner,

Gerald. Implementation of Strong Mobility for Multi-threaded Agents in
Java. Proceedings of the 2003 International Conference on Parallel
Processing (ICPP03) .

[13]

Chetan, Shiva; Al-Muhtadi, Jalal; Campbell, Roy and Mikunas, Dennis M.

Mobile Gaia: A Middleware for Ad-Hoc Pervasive Computing. IEEE
Consumer Communications and Networking Conference, 2004.

[14]

D. Gelernter. Generative Communication in Linda. ACM Computing

Surveys, 7(1):80.112, Jan. 1985.

[15]

Delamarco, Marcio ; Picco, Gian Pietro. Mobile Code in .NET: A Porting

Experience. In Proceedings of the 6th International Conference on Mobile
Agents (MA 2002), Barcelona (Spain). N. Suri ed. Lecture Notes on
Computer Science vol. 2355. pp 16-31, October 2002.

[16]

Du Bois, A.R; Trinder, P.W.; Loidl, H-W. Towards Mobile Skeletons. In

Parallel Processing Letters, v. 15, n. 3, p. 273-288, 2005.

[17]

Eid, Mohamed, et. al. Trends in Mobile Agents. Journal of Information and
Practice on Information Technology. Vol. 37. No. 4. November, 2005.

[18]

Eisenberg, Andrew. Et al. SQL:2003 has been published. ACM Sigmod

Record. Volume 33. Issue 1. march 2004.

[19]

F. Bellifemine, G. Caire, A. Poggi, G. Rimassa, JADE A White Paper

Sept.
2003.
Disponvel
em
http://jade.tilab.com/papers/2003/
WhitePaperJADEEXP.pdf. Acessado em 11/2006.

[20]

Felmetsger, Viktoria; Vigna, Giovanni. Exploiting OS-level Mechanisms

to Implement Mobile Code Security. Proceedings of the 10th International
Conference on Engineering of Complex Computer Systems (ICECCS`05),
2005.

[21]

Fuggetta, Alfonso; Picco, Gian Pietro; Vigna, Giovanni Unsderstanding

Code Mobility. IEEE Transactions on Software Engineering. Vol. 24 Num.
5. pp 342-361, 1998.

[22]

G.-C. Roman, A.L. Murphy, and G.P. Picco. Coordination and Mobility.
In A. Omicini, F. Zambonelli, M. Klusch, and R. Tolksdorf, editors,

89
Coordination of Internet Agents: Models, Technologies, and Applications,
pages 254.273. Springer, 2000.
[23]

Garzo, A. S. and Barbosa, J. L. V. (2003). Uma mquina virtual com

suporte concorrncia, mobilidade e blackboards. In XXIX Conferncia
Latinoamericana de Informtica (CLEI), volume 24, La Paz. Universidad
Mayor de San Andrs.

[24]

Ghezi, C.; Vigna, Giovanni. Mobile Code Paradigms and Technologies: A

Case Study. Proceedings of the first International Workshop on Mobile
Agents (MA97), pp 39-49, LNCS 1219 Springer Verlag, Berlim, Germany,
April 1997.

[25]

Gosling, J.; Steele, Joy G; The Java Language Specification. AddisonWesley, 1996.

[26]

Grimm, R. One.world : Experiences with a Pervasive Computing

Architecture. On Pervasive Computing, IEEE. pp 22-30. ISSN: 15361268. July-Sept 2004.

[27]

J. Waldo, G. Wyant, A. Wollrath, and S. Kendall. A note on distributed

computing. Technical Report TR-94-29, Sun Microsystems Laboratories,
November 1994.

[28]

Jini Web page. http://www.sun.com/jini . Acessada em 12/2006.

[29]

Karlsson, Bjorn. Beyond the C++ Stardard Library : An Introduction to

Boost. Addison-Wesley Professional, 432 p. New York, 2005.

[30]

Lange, D. and Oshima, M. Programming and Deploying Java Agents

with Aglets. Addison-Wesley. New York, 1998.

[31]

Mockapetris, Paul V and Dunlap, Kevin J. Development of the Domain

Name System. In SIGCOMM, pages 123-133, 1988.

[32]

Naseen, Muhammad Kamram et al. Implementing Strong Code Mobility.

In Information Technology Journal 3(2):188-191, 2004

[33]

Neely, Mat. Write Mobile Agents in .NET to Roam And Interact On

Your
Network.
MSDN
Magazine
online.
http://msdn.microsoft.com/msdnmag/issues/06/02/MobileAgents/default.asp
x . Acessado em 11/2006.

[34]

Nork, Michael. Voyager: An Overview. Recursion Software Inc.

http://www.recursionsw.com/Voyager/Voyager_High_Level_Overview.pdf
Acessado em 03/2006.

[35]

Object Management Group. CORBA: Architecture and Specification

Aug. 1995

90
[36]

Parizeau, Marc. The PACC Collection http://manitou.gel.ulaval.ca/

~parizeau/PACC Acessado em Dezembro de 2006.

[37]

Picco, Gian Pietro. Code: A Lightweight and Flexible Mobile Code

Toolkit. International Workshop on Mobile Agents. MA, 2, 1999. Stuttgart,
Germany. Proceedings Berlim: Springer, 1999. p 160-171 (Lecture Notes
in Computer Science, v.1477).

[38]

Sakamoto, T.; Sekiguchi, T. ; Yonezawa, A. Bytecode Transformation for

Portable Thread Migration in Java. In Proceedings of Agent Systems,
Mobile Agents , and Applications, 2000.

[39]

Sekiguchi, T.; Masuhara, H; Yonezawa, A,. A Simple Extension for Java

Language for Controllable Transparent Migration and its Portable
Implementation. In Coordination Models and Languages, 1999.

[40]

Silva, Luciano Cavalheiro da (2003). Primitivas para Suporte

Distribuio De Objetos Direcionadas a Pervasive Computing .
Dissertao. (mestrado em cincia da computao) Instituto de Informtica,
Universidade Federal do Rio Grande do Sul, Porto Alegre, 123 p.

[41]

Sousa, Joo Pedro; Garlan, David Aura: An Architectural Framework for

User Mobility in Ubiquitous Computer Environments. Proceedings of
the 3rd Working IEEE/IFIP Conference on Software Architecture. Kluwer
Academic Publishers, pp 29-43, August 2002.

[42]

Thorn, Thommy. Programming Languages for Mobile Code. ACM

Computing Surveys. Vol. 29. Num. 3. pp. 213-239, 1997.

[43]

Torres, Daniel; Kellerman, Felipe; Barbosa, Jorge Luis V.; Ramos, Jos
Dirceu and Cavalheiro, Gerson G. H. Estratgias para localizao em um
ambiente de computao mvel. In XXIX Conferncia Latinoamericana de
Informtica (SEMISH), So Leopoldo, 2005. Unisinos.

[44]

Bender, James C. Voyager and Software Agents Applied to SimulationBased Training and Exercise Management. Recursion Software Inc.
December, 2004

[45]

Vraned, S and Stanojevic, M. Integrating multiple paradigms within the

blackboard. IEEE Transactions on Software Engineering, March 1995.

[46]

Xiao, Yang. Rosdahi, Jon. Wireless Home Networks: Performance

Analysis and Enhancement for the Current and Future IEEE 802.11
Mac Protocols. Proceedings of the 9th Annual International Conference on
Mobile Computing and Networking. ACM Press, 2003.

[47]

Yamin, Adenauer C.; Augustin, Yara; Barbosa, Jorge Luis Victria; Silva,
Luciano Cavalheiro da; Cavalheiro, Gerson Geraldo Homrich; Geyer,
Claudio Fernando Resin. A Framework for Exploiting Adaptation in High

91
Heterogeneous Distributed Processing. In Symposium on Computer
Architecture and High Performance Computing (SBAC-PAD 2002) pages
125-132, Los Alamitos ,2002. IEEE Computer Society.
[48]

Waldo, Jim. The Jini Network Centric Architecture. Communications of

the ACM. Vol 42. No 7. July 1999.