exehda-hm: uma contribuição à gerência da holotree
TRANSCRIPT
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
INSTITUTO DE INFORMÁTICA
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
EXEHDA-HM: Uma Contribuição à Gerência da HoloTree
Por
ALBERTO EGON SCHAEFFER FILHO
Trabalho de Conclusão submetido como requisito
parcial à obtenção do grau de Bacharel em Ciência
da Computação.
Orientador: Prof. Dr. Cláudio F. R. Geyer
Porto Alegre, Setembro de 2002
2
AGRADECIMENTOS à Vanessa Duranti Soares, pelo carinho e pela paciência; à minha mãe, Adélia Debarba Juchem, pelo incentivo; ao Cláudio Geyer, pela orientação; ao Adenauer Yamin e a todo o grupo de pesquisa, pela ajuda e pelo companheirismo durante a Iniciação Científica e no desenvolvimento deste trabalho; ao meu pai, por tudo (em memória).
3
SUMÁRIO
LISTA DE ABREVIATURAS .................................................................................................................. 5
LISTA DE FIGURAS ................................................................................................................................ 6
LISTA DE TABELAS ............................................................................................................................... 7
RESUMO.................................................................................................................................................... 8
ABSTRACT................................................................................................................................................ 9
1 INTRODUÇÃO................................................................................................................................ 10
1.1 O PROBLEMA .............................................................................................................................. 10 1.2 CONTRIBUIÇÃO DO AUTOR ......................................................................................................... 10 1.3 ESTRUTURA DO TEXTO ............................................................................................................... 11
2 O CONTEXTO DO TRABALHO.................................................................................................. 13
2.1 ARQUITETURA DE SOFTWARE UTILIZADA .................................................................................. 13 2.1.1 Camada Intermediária – Primeiro Nível ........................................................................... 14 2.1.2 Camada Intermediária – Segundo Nível ............................................................................ 14 2.1.3 Camada Intermediária – Terceiro Nível ............................................................................ 15
2.2 HOLOPARADIGMA....................................................................................................................... 15 2.2.1 Tipos de Entes .................................................................................................................... 15 2.2.2 Distribuição e Mobilidade ................................................................................................. 17
2.3 O EXEHDA................................................................................................................................ 18 2.3.1 Características do EXEHDA.............................................................................................. 21 2.3.2 Decisões de Adaptação do EXEHDA................................................................................. 22 2.3.3 Dimensões e Níveis de Adaptação...................................................................................... 23 2.3.4 Transparência x Consciência da Mobilidade..................................................................... 23 2.3.5 A Organização do Escalonamento no EXEHDA................................................................ 23 2.3.6 A Adaptação Multinível Colaborativa ............................................................................... 23 2.3.7 Organização Física do Escalonamento ............................................................................. 24
3 O SERVIÇO DE NOMES COMO NÚCLEO FUNCIONAL DO EXEHDA-HM ..................... 27
3.1 SERVIÇO DE NOMES EM SISTEMAS DISTRIBUÍDOS ...................................................................... 27 3.2 TIPOS DE NOMES......................................................................................................................... 28 3.3 MAPEAMENTO ENTRE NOMES .................................................................................................... 29 3.4 GERAÇÃO DISTRIBUÍDA DE NOMES ............................................................................................ 29 3.5 DISTRIBUIÇÃO E RESOLUÇÃO DE NOMES.................................................................................... 32 3.6 O SERVIÇO DE NOMES DO EXEHDA-HM .................................................................................. 35
4 EXEHDA-HM: MODELAGEM E PRINCÍPIOS DE OPERAÇÃO .......................................... 38
4.1 HOLOTREE: RESUMO DAS PRINCIPAIS CARACTERÍSTICAS .......................................................... 38 4.2 EXEHDA-HM: PRINCIPAIS CONTRIBUIÇÕES AO AMBIENTE DE EXECUÇÃO DO HOLOPARADIGMA
39 4.3 EXEHDA-HM: PRIMITIVAS PARA A MANIPULAÇÃO DE ENTES ................................................... 39
4.3.1 CreateBeing ....................................................................................................................... 39 4.3.2 ExtinguishBeing ................................................................................................................. 40 4.3.3 MoveBeing ......................................................................................................................... 41
4.4 EXEHDA-HM: ESTRATÉGIA DE GERENCIAMENTO.................................................................... 43 4.4.1 O EXEHDA_HMSpace....................................................................................................... 43 4.4.2 Tabelas Auxiliares de Gerenciamento: Base Position Table e Current Position Table..... 44 4.4.3 Estratégia de Propagação de Token: Vizinhança .............................................................. 45
5 EXEHDA-HM: PRINCIPAIS ASPECTOS DA IMPLEMENTAÇÃO....................................... 46
5.1 A LINGUAGEM JAVA................................................................................................................... 46 5.2 FERRAMENTAS UTILIZADAS........................................................................................................ 50
4
5.2.1 Rational Rose Enterprise Edition....................................................................................... 50 5.2.2 JBuilder 4 Personal............................................................................................................ 51
5.3 ARQUIVOS DE CONFIGURAÇÃO DO EXEHDA-HM..................................................................... 51 5.4 PRINCIPAIS CLASSES DO MODELO .............................................................................................. 52
5.4.1 Diagrama de Classes Simplificado .................................................................................... 53 5.4.2 Descrição das Classes........................................................................................................ 54
5.5 O EXEHDA-HM VISUAL........................................................................................................... 55 5.5.1 A Modelagem do EXEHDA-HM Visual ............................................................................. 56
5.6 ESTUDO DE CASO........................................................................................................................ 57
6 CONCLUSÕES ................................................................................................................................ 62
7 BIBLIOGRAFIA.............................................................................................................................. 64
5
LISTA DE ABREVIATURAS API Application Program Interface CVS Concurrent Version System EXEHDA EXcution Environment for High Distributed Applications EXEHDA-HM EXEHDA – HoloTree Manager GC Garbage Collector IDL Interface Definition Language ISAM Infra-estrutura de Suporte às Aplicações Móveis JDK Java Development Kit JMS Java Message Service JVM Java Virtual Machine RMI Remote Method Invocation RPC Remote Procedure Call UML Unified Modeling Language XML eXtensible Markup Language
6
LISTA DE FIGURAS
FIGURA 2.1 – ARQUITETURA ISAM ......................................................................................................... 13 FIGURA 2.2 – TIPOS DE ENTES.................................................................................................................. 16 FIGURA 2.3 – ENTE DISTRIBUÍDO ............................................................................................................. 17 FIGURA 2.4 – MOBILIDADE NO HOLOPARADIGMA.................................................................................... 18 FIGURA 2.5 – CONTEXTO DE EXECUÇÃO .................................................................................................. 19 FIGURA 2.6 – VISÃO GERAL DO EXEHDA............................................................................................... 20 FIGURA 2.7 – ELEMENTOS BÁSICOS DO AMBIENTE DE EXECUÇÃO .......................................................... 21 FIGURA 2.8 – A ADAPTAÇÃO MULTINÍVEL COLABORATIVA .................................................................... 24 FIGURA 2.9 – ORGANIZAÇÃO DO ESCALONAMENTO................................................................................. 26 FIGURA 3.1 – DIAGRAMA TRANSIÇÃO DE ESTADOS PARA A CONSULTA DE ENTES .................................. 36 FIGURA 4.1 – ÁRVORE DE ENTES (HOLOTREE) ........................................................................................ 39 FIGURA 4.2 – DIAGRAMA DE TRANSIÇÃO DE ESTADOS DA PRIMITIVA CREATEBEING .............................. 40 FIGURA 4.3 – DIAGRAMA DE TRANSIÇÃO DE ESTADOS DA PRIMITIVA EXTINGUISHBEING........................ 41 FIGURA 4.4 – DIAGRAMA DE TRANSIÇÃO DE ESTADOS DA PRIMITVA MOVEBEING .................................. 42 FIGURA 5.1 – ARQUITETURA RMI............................................................................................................ 48 FIGURA 5.2 – COMUNICAÇÃO ENTRE AS EXEHDABASES DAS EXEHDACELS........................................ 50 FIGURA 5.3 – EXEMPLO DE ARQUIVO DE CONFIGURAÇÃO EXEHDABASE-CONF.XML ............................ 52 FIGURA 5.4 – DIAGRAMA DE CLASSES SIMPLIFICADO DO EXEHDA-HM................................................ 53 FIGURA 5.5 – CONSULTA GLOBAL DE ENTES REALIZADA ATRAVÉS DO EXEHDA-HM VISUAL............. 55 FIGURA 5.6 – DIAGRAMA DE CLASSES DO EXEHDA-HM VISUAL .......................................................... 56 FIGURA 5.7 – PRIMEIRA ETAPA DA EXECUÇÃO ........................................................................................ 58 FIGURA 5.8 – SEGUNDA ETAPA DA EXECUÇÃO ........................................................................................ 58 FIGURA 5.9 – TERCEIRA ETAPA DA EXECUÇÃO........................................................................................ 59 FIGURA 5.10 – QUARTA ETAPA DA EXECUÇÃO ........................................................................................ 59 FIGURA 5.11 – QUINTA ETAPA DA EXECUÇÃO ......................................................................................... 60 FIGURA 5.12 – SEXTA ETAPA DA EXECUÇÃO ........................................................................................... 60
7
LISTA DE TABELAS
TABELA 3.1 – VANTAGENS E DESVANTAGENS DA CONCATENAÇÃO HIERÁRQUICA COMO ESTRATÉGIA
PARA A GERAÇÃO DISTRIBUÍDA DE NOMES........................................................................................ 31 TABELA 3.2 – VANTAGENS E DESVANTAGENS DA ABORDAGEM UNIFORME COMO ESTRATÉGIA PARA A
GERAÇÃO DISTRIBUÍDA DE NOMES..................................................................................................... 31 TABELA 3.3 – VANTAGENS E DESVANTAGENS DA TÉCNICA CENTRALIZADA COMO ESTRATÉGIA PARA
DISTRIBUIÇÃO E RESOLUÇÃO DE NOMES............................................................................................ 32 TABELA 3.4 – VANTAGENS E DESVANTAGENS DA TÉCNICA COMPLETAMENTE DISTRIBUÍDA COMO
ESTRATÉGIA PARA DISTRIBUIÇÃO E RESOLUÇÃO DE NOMES.............................................................. 33 TABELA 3.5 – VANTAGENS E DESVANTAGENS DA TÉCNICA DISTRIBUÍDA LOCAL COMO ESTRATÉGIA
PARA DISTRIBUIÇÃO E RESOLUÇÃO DE NOMES................................................................................... 34 TABELA 3.6 – VANTAGENS E DESVANTAGENS DA TÉCNICA PARCIALMENTE DISTRIBUÍDA COMO
ESTRATÉGIA PARA DISTRIBUIÇÃO E RESOLUÇÃO DE NOMES.............................................................. 34
8
RESUMO
O projeto ISAM, em desenvolvimento no Instituto de Informática da UFRGS, é formado por três principais frentes de pesquisa: (1) a construção de um middleware de execução para aplicações altamente distribuídas, o qual é chamado de EXEHDA; (2) o Holoparadigma, uma linguagem de programação multiparadigma baseada em agentes dinâmicos que executam sobre o EXEHDA; e (3) o ISAMadapt, que introduz abstrações no Holoparadigma para permitir a construção de aplicações sensíveis ao contexto.
Na perspectiva do ISAM foi desenvolvido o EXEHDA-HoloTree Manager. O EXEHDA-HM, de forma abreviada, é o módulo pertencente ao ambiente de execução EXEHDA responsável pela gerência do contexto de execução de aplicações distribuídas escritas em Holoparadigma. Sua concepção prevê integração com os mecanismos de controle da adaptação empregados pelo EXEHDA.
O principal objetivo do EXEHDA-HM é, portanto, o de manter uma gerência distribuída do contexto de execução das aplicações, além de fornecer um conjunto de primitivas que possibilitem a essas aplicações a manipulação dos entes pertencentes à HoloTree distribuída.
palavras-chave: EXEHDA, Holoparadigma, mobilidade, HoloTree, gerência distribuída, contexto de execução.
9
ABSTRACT
The ISAM Project, in development in the Informatics Institute of UFRGS, is composed by three main research fronts: (1) the construction of an execution middleware for high distributed applications, named EXEHDA; (2) the Holoparadigma, a multiparadigm programming language based on dynamics agents that executes on the EXEHDA; and (3) the ISAMadapt, that introduces abstractions in the Holoparadigma to allow the construction of context-aware applications.
In the ISAM perspective was developed the EXEHDA-HoloTree Manager. The EXEHDA-HM, in an abbreviated form, is the module belonging to the EXEHDA execution environment responsible for the management of the execution context of distributed applications wrote on Holoparadigma. Your conception foresees integration with the mechanisms existent for adaptation control used by EXEHDA.
The main objective of the EXEHDA-HM is, therefore, to mantain a distributed management of the execution context of the applications, besides supplying a group of primitives that make possible to those applications the manipulation of the beings belonging to the distributed HoloTree.
keywords: EXEHDA, Holoparadigma, mobility, HoloTree, distributed management, execution context.
10
1 Introdução
Este capítulo tem como objetivo fazer uma introdução ao trabalho desenvolvido. Inicialmente, são caracterizados o problema e o contexto no qual o trabalho está inserido. Após, é feita uma descrição das principais contribuições do autor, e por fim, a estrutura do texto é apresentada.
1.1 O Problema
O EXEHDA-HM é parte do projeto EXEHDA, que por sua vez, junto com outros trabalhos forma o projeto ISAM. O objetivo do EXEHDA-HM é fornecer ao ambiente de execução EXEHDA suporte à execução distribuída de programas escritos utilizando-se o Holoparadigma. A linguagem de programação definida pelo Holoparadigma, conhecida como Hololinguagem, permite a definição de entes, os quais são unidades de execução e podem ter as suas relações de composição organizadas sob a forma de uma árvore. Um ente interage com outros entes da árvore por meio de operações bem definidas na linguagem, através da Holosemântica.
Dessa forma, uma das principais contribuições do EXEHDA-HM à execução distribuída do Holoparadigma se dá através da gerência da árvore de entes (de onde surgiu seu nome – HM – HoloTree Manager), que pode estar particionada entre diversos nodos distribuídos geograficamente.
Para realizar a gerência da HoloTree, era necessário definir a semântica de execução das operações da Hololinguagem que manipulam entes. Essas operações são: criação, destruição e mobilidade de entes. Como o EXEHDA prevê a existência de células, as quais são um conjunto de um ou mais nodos, e que cada célula gerencia os entes em execução nos seus nodos através de uma instância local do EXEHDA-HM, tornou-se necessária a concepção de um mecanismo de troca de informações entre os EXEHDA-HM de diferentes células, visto que cada um seria responsável pela gerência de um subconjunto da HoloTree, e juntos teriam uma visão global de toda a árvore de entes.
Portanto, cabe ao EXEHDA-HM gerenciar a relação entre os entes do programa Holoparadigma em execução. Considerando a perspectiva de comportamento adaptativo da execução, esta relação tem tanto aspectos lógicos, como físicos. Esse gerenciamento deve ser realizado de forma cooperativa entre as diversas instâncias do EXEHDA-HM, contidas nas diferentes células que formam o ambiente de execução do programa.
1.2 Contribuição do Autor
Essa seção tem por objetivo resumir as contribuições do autor ao projeto EXEHDA, apresentando as principais atividades desenvolvidas na concepção do EXEHDA-HM.
11
Pesquisa e organização bibliográfica
O início das atividades desse trabalho se deu através da revisão bibliográfica de temas relacionados aos trabalhos desenvolvidos pelo grupo de pesquisa, e de artigos, dissertações e teses que tratassem de temas envolvendo a implementação e gerência de serviços de nomes em sistemas distribuídos.
Participação na definição dos requisitos do modelo
Após a pesquisa inicial, foram definidos os requisitos que o EXEHDA-HM deveria possuir, e as atividades que o mesmo deveria desempenhar. Dessa forma, tornaram-se claras as necessidades que deveriam ser supridas, permitindo um melhor planejamento das demais etapas do trabalho. Nessa fase, definiu-se que a principal função do EXEHDA-HM seria a gerência da HoloTree, onde a principal abstração empregada nessa gerência seria um serviço de nomes que englobaria diversas características dos entes e dos recursos do sistema.
Modelagem e Implementação do EXEHDA-HM
As etapas finais contemplaram a modelagem e a implementação do EXEHDA-HM. Enquanto que a modelagem valeu-se de diagramas UML para clarificar e documentar pontos críticos do modelo, a implementação do trabalho foi completamente desenvolvida na linguagem Java. As justificativas para a escolha dessas tecnologias são discutidas no decorrer do texto.
Modelagem e Implementação de Ambiente Visual para depuração
A fim de que os resultados obtidos pudessem ser visualizados de forma gráfica, e não apenas textual, tornou-se necessário o desenvolvimento de uma ferramenta que auxiliasse na depuração de programas escritos na Hololinguagem, os quais podem possuir entes ativos em diferentes máquinas de uma arquitetura distribuída. Com o EXEHDA-HM Visual é possível obter a localização e a descrição de qualquer ente pertencente a uma aplicação Holo, independente da célula ou máquina em que o mesmo esteja sendo executado.
Realização de Testes Objetivando a Integração com Outros Trabalhos
O EXEHDA-HM passou por uma série de testes, de forma que pudessem ser avaliados os pontos que deveriam ser adaptados para realizar-se a integração com as demais ferramentas que estão em desenvolvimento pelo grupo de pesquisa.
1.3 Estrutura do Texto
O texto que segue está organizado em seis capítulos, distribuídos da seguinte forma:
12
• capítulo dois apresenta o contexto no qual o EXEHDA-HM está inserido, relacionando-o aos demais projetos em desenvolvimento pelo grupo de pesquisa, e descrevendo brevemente cada um desses projetos.
• capítulo três discute serviços de nomes em geral, apresentando alternativas para diversos tipos de implementações. Após, é descrito como essas alternativas influenciaram a concepção do serviço de nomes do EXEHDA-HM, visto que esse é um dos pontos-chave utilizados na gerência distribuída de entes.
• quarto capítulo apresenta os principais aspectos relacionados à modelagem do EXEHDA-HM, onde se destacam as primitivas de manipulação de entes, e a estratégia de gerenciamento empregada.
• quinto capítulo discute os principais pontos relacionados à implementação do modelo, apresentando também uma ferramenta visual – o EXEHDA-HM Visual –construída com o intuito de auxiliar na depuração de programas escritos na Hololinguagem, e que possam estar rodando em diferentes máquinas.
• por fim, o capítulo seis encerra o trabalho com algumas considerações finais, e discute possíveis trabalhos futuros relacionados ao EXEHDA-HM.
13
2 O Contexto do Trabalho
O EXEHDA-HM integra a frente de pesquisa EXEHDA, a qual por sua vez, juntamente com as pesquisas Holoparadigma e ISAMadapt compõem o projeto ISAM. Este capítulo tem por objetivo discorrer sobre as principais motivações do projeto ISAM, bem como sobre as principais características das frentes de pesquisa que o compõem. Uma visão geral do ISAM pode ser encontrada em [AUG 2001] [YAM 2002a].
2.1 Arquitetura de Software Utilizada
A arquitetura proposta é organizada em camadas com níveis diferenciados de abstração e está direcionada para a busca da manutenibilidade da qualidade de serviços do ambiente de execução, através do conceito de adaptação. Uma visão da arquitetura do ISAM é apresentada na figura 2.1. Salientam-se dois pontos: (1) a adaptação que permeia todo o sistema, por isto está colocada em destaque; (2) o escalonador que é o "núcleo adaptativo” da arquitetura.
A camada superior (SUP) da arquitetura é composta pela aplicação móvel distribuída. A construção desta aplicação baseia-se nas abstrações do Holoparadigma, as quais permitem expressar mobilidade, acrescidas de novas abstrações para expressar adaptabilidade proposta pelo ISAMadapt.
A camada intermediária aloja as principais funcionalidades providas pelo EXEHDA, a quais são comentadas nos itens que seguem.
Por sua vez, a camada inferior (INF) é composta pelas tecnologias empregadas nos sistemas distribuídos existentes, tais como sistemas operacionais nativos e a Máquina Virtual Java.
FIGURA 2.1 – Arquitetura ISAM
14
2.1.1 Camada Intermediária – Primeiro Nível
A camada intermediária (INTERM) é o núcleo funcional da arquitetura ISAM, sendo formada por três níveis de abstração. O primeiro nível é composto por dois módulos de serviço à aplicação: Escalonamento e Ambiente Virtual do Usuário. O escalonamento, por sua vez, é o componente-chave da adaptação na arquitetura ISAM.
O Ambiente Virtual do Usuário (AVU) compõe-se dos elementos que integram a interface de interação do usuário móvel com o sistema. Este módulo é o responsável por implementar o suporte para que a aplicação que o usuário está executando em uma localização possa ser instanciada e continuada em outra localização sem descontinuidade, permitindo o estilo de aplicações follow-me. O modelo foi projetado para suportar a exploração de aplicações contextualizadas (adaptadas aos recursos, serviços e localização corrente) e individualizadas (adaptadas aos interesses e preferências do usuário móvel). O desafio da adaptabilidade é suportar os usuários em diferentes localizações, com diferentes sistemas de interação que demandam diferentes sistemas de apresentação, dentro dos limites da mobilidade. Este módulo deve caracterizar, selecionar e apresentar as informações de acordo com as necessidades e o contexto em que o usuário se encontra. Para realizar estas tarefas, o sistema se baseia num modelo de uso onde as informações sobre o ambiente de trabalho, preferências, padrões de uso, padrões de movimento físico e hardware do usuário são dinamicamente monitoradas e integram o Perfil do Usuário e da Aplicação.
2.1.2 Camada Intermediária – Segundo Nível
Como já caracterizado anteriormente, na proposta ISAM busca-se um conceito flexível de adaptação que está relacionado ao contexto em que a aplicação está inserida. Por sua vez, a mobilidade física introduz a possibilidade de movimentação do usuário durante a execução de uma aplicação. Desta forma, os recursos disponíveis podem se alterar, tanto em função da área de cobertura e heterogeneidade das redes, quanto em função da disponibilidade dos recursos devido à alta dinamicidade do sistema. Assim, a localização corrente do usuário determina o contexto de execução, definindo toda informação relevante para a aplicação, que pode ser obtida e usada para definir seu comportamento. Em uma análise preliminar, o contexto é determinado através de informações de quem, onde, quando, o que está sendo realizado e com o que está sendo realizado. Obter essas informações é tarefa do módulo de monitoramento, que atua tanto na parte móvel quanto na parte fixa da rede.
As informações que dirigem as decisões do escalonador e dão suporte à aplicação para sua decisão de adaptação são advindas de quatro fontes: perfil da execução, perfil dos recursos, perfil do usuário e da aplicação (ISAMadapt). O módulo monitoramento do ISAM obtém informações do acompanhamento das aplicações executadas pelo usuário, em um dado tempo e em um dado local, com determinados parâmetros, o que permite determinar a evolução histórica e quantitativa das entidades monitoradas. A interpretação destas informações estabelece o perfil do usuário e das aplicações. Desta forma, as aplicações móveis ISAM poderão se adaptar à dimensão pessoal, além das dimensões temporal e espacial presentes nos demais sistemas móveis.
15
2.1.3 Camada Intermediária – Terceiro Nível
No terceiro nível da camada intermediária estão os serviços básicos do ambiente de execução ISAM que provêm a funcionalidade necessária para o segundo nível e cobrem vários aspectos, tais como migração – mecanismos para deslocar um ente de uma localização física para outra; replicação otimista – mecanismo para aumentar a disponibilidade e o desempenho do acesso aos dados; localização e naming – para dar suporte ao movimento dos dispositivos móveis entre diferentes equipamentos mantendo a execução durante o deslocamento.
2.2 Holoparadigma
Esta seção tem por objetivo resumir os principais aspectos do Holoparadigma (de forma abreviada, Holo). Holo é um modelo multiparadigma que possui uma semântica simples e distribuída. Através dessa semântica, o modelo estimula a exploração automática da distribuição (distribuição implícita). Detalhes relacionados ao Holoparadigma podem ser obtidos em [BAR 2002].
2.2.1 Tipos de Entes
O Holoparadigma estabelece duas classificações básicas para organização dos entes: organizacional e funcional. A classificação organizacional distingue os entes, de acordo com a sua estrutura, em dois tipos:
• Ente elementar: ente sem níveis de composição;
• Ente composto: ente formado pela composição de outros entes. Não existe limite para níveis de composição.
Um ente elementar (figura 2.2a) é organizado em três partes: interface, comportamento e história. A interface descreve suas possíveis relações com os demais entes. O comportamento contém ações que implementam a funcionalidade de um ente. Holo não estabelece os tipos de ações a serem utilizadas, no entanto, estabelece que existem dois tipos básicos de comportamento:
• Imperativo: o comportamento imperativo é composto de ações imperativas que descrevem os caminhos para solução de um problema (enfoque no controle, ou seja, como deve ser realizada a ação). Uma ação imperativa possui uma natureza determinista. O paradigma imperativo é uma alternativa para descrição do comportamento imperativo;
• Lógico: o comportamento lógico é composto de ações lógicas que expressam um problema de forma declarativa (enfoque na lógica, ou seja, o que deve ser realizado). Uma ação lógica possui uma natureza não-determinista. O paradigma em lógica é uma alternativa para descrição do comportamento lógico.
A história é um espaço de armazenamento compartilhado no interior de um ente. O símbolo é o átomo de informação no Holoparadigma. Holo propõe a utilização do processamento simbólico como principal instrumento para o tratamento de informações. Esta característica é herdada do paradigma em lógica. Neste sentido, a variável lógica e a unificação são consideradas a base do tratamento de símbolos. Holo
16
estabelece que a história deve ser direcionada para armazenamento e gerenciamento de símbolos. Portanto, o paradigma em lógica torna-se uma alternativa adequada para sua implementação.
Um ente composto (figura 2.2b) possui a mesma organização de um ente elementar, no entanto, suporta a existência de outros entes na sua composição (entes componentes). Cada ente possui uma história. A história fica encapsulada no ente e, no caso dos entes compostos, é compartilhada pelos entes componentes. Os entes componentes participam do desenvolvimento da história compartilhada e sofrem os reflexos das mudanças históricas. Sendo assim, podem existir vários níveis de encapsulamento da história. Os entes acessam somente a história em um nível. A composição varia de acordo com a mobilidade dos entes em tempo de execução. A figura 2.2c mostra dois níveis de história encapsulada em um ente composto organizado em três níveis. Os comportamentos e interfaces foram omitidos para simplificação da figura.
FIGURA 2.2 – Tipos de Entes
Um ente elementar assemelha-se a um objeto do paradigma orientado a objetos.
Do ponto de vista estrutural, a principal diferença consiste na história, a qual atua como uma forma alternativa de comunicação e sincronização. Um ente composto assemelha-se a um grupo. Neste caso, a história atua como um espaço compartilhado vinculado ao grupo. [Lea 2001] salienta que os conceitos da orientação a objetos, tais como objetos e classes, tornam-se limitados quando o tratamento de composição envolve aspectos dinâmicos (mudam durante a execução). Lea também propõe a utilização de grupos para solução desta limitação. Os entes compostos aliados à mobilidade permitem a composição dinâmica no Holoparadigma. Além disso, a utilização de uma mesma unidade (ente) para manipulação de elementos e grupos, simplifica o modelo e sintetiza conceitos já existentes na ciência da computação.
A classificação funcional distingue os entes de acordo com suas funções:
• Ente estático: definição estática de um ente. Esta definição estabelece um padrão estático que pode ser utilizado para criação de outros entes através da clonagem. Um ente estático é criado no nível de modelagem e programação. Modelos e programas são compostos de descrições de entes (entes estáticos), as quais estabelecem interfaces, comportamentos e histórias;
História
ComportamentoInterface
Interface
Ente 1 Ente 2 Ente n...
Ente
História
Ente
História
Ente Ente
Ente
História
Ente Ente
Nível 0
Nível 1
Nível 2 Nível 2
(a) Ente elementar (b) Ente Composto (c) Exemplo de composição (3 níveis)
História
Comportamento
17
• Ente dinâmico: ente em execução. Um programa em execução é composto de entes dinâmicos. Estes entes executam ações e interagem de acordo com seus comportamentos e histórias.
A única distinção entre entes estáticos e dinâmicos consiste na sua função. Os entes estáticos são utilizados como matrizes estáticas para criação de outros entes. Além disso, estabelecem um estado inicial para execução de programas. Por sua vez, os dinâmicos representam o estado corrente de uma execução.
2.2.2 Distribuição e Mobilidade
O Holoparadigma busca a distribuição implícita através da Holosemântica. Uma discussão neste sentido está apresentada em [BAR 2001]. Neste escopo, um ente assume dois estados de distribuição:
• Centralizado: um ente está centralizado quando se localiza em apenas um nodo de um sistema distribuído. Entes elementares estão sempre centralizados. Um ente composto está centralizado se todos os seus entes componentes estão localizados no mesmo nodo;
• Distribuído: um ente está distribuído quando se localiza em mais de um nodo de um sistema distribuído. Entes elementares não podem estar distribuídos. Um ente composto está distribuído se um ou mais entes componentes estão distribuídos.
FIGURA 2.3 – Ente Distribuído
A figura 2.3 exemplifica uma possível distribuição para o ente apresentado na
figura 2.2c. O ente encontra-se distribuído em dois nodos da arquitetura distribuída. A história de um ente distribuído é denominada história distribuída. A distribuição da história pode ser baseada em técnicas de memória compartilhada distribuída ou espaços distribuídos.
História
História
Nodo 1 Nodo 2
Nível 0
Nível 1
Nível 2
Ente
Ente
Ente Ente
HistóriaNível 2
Ente
Ente Ente
Rede de Comunicação
18
A mobilidade é a capacidade que permite o deslocamento de um ente. No Holoparadigma existem dois tipos de mobilidade:
• Mobilidade lógica: a mobilidade lógica relaciona-se com o deslocamento em nível de modelagem, ou seja, sem considerações sobre a plataforma de execução. Neste contexto, um ente se move quando cruza uma ou mais fronteiras de entes;
• Mobilidade física: a mobilidade física relaciona-se com o deslocamento entre nós de uma arquitetura distribuída. Neste contexto, um ente se move quando se desloca de um nó para outro.
A figura 2.4 exemplifica uma possível mobilidade lógica no ente apresentado na figura 2.2c. Conforme exemplificado, após o deslocamento, o ente móvel não possui mais acesso à história no ente origem. No entanto, passa a ter acesso à história no ente destino. Neste caso, somente ocorrerá mobilidade física se os entes origem e destino estiverem alocados em diferentes nós de uma arquitetura distribuída.
As mobilidades lógica e física são independentes. A ocorrência de um tipo de deslocamento não implica a ocorrência do outro. Merece atenção o caso da mobilidade física não implicar obrigatoriamente a mobilidade lógica. Considere-se o ente distribuído mostrado na figura 2.3. Se o ente elementar localizado no nível um, realizar um deslocamento físico conforme mostrado na figura 2.4b, não haverá mobilidade lógica apesar de ter ocorrido mobilidade física. Neste caso, o ente movido continua com a mesma visão da história.
FIGURA 2.4 – Mobilidade no Holoparadigma
2.3 O EXEHDA
Os próximos anos serão caracterizados por elevados níveis de mobilidade, heterogeneidade e interação entre dispositivos conectados a redes de abrangência global. Estas redes interligadas utilizarão tanto conexões cabeadas, como também sem fio. As primeiras pesquisas envolvendo sistemas distribuídos em redes wide-area responderam a diversas questões pertinentes ao gerenciamento de recursos neste contexto, contudo existem lacunas no que diz respeito ao tratamento da heterogeneidade e da adaptação dinâmica. Trabalhos mais recentes empregando tecnologias como
Ente
História
EnteHistória
Ente Ente
Ente
História
Ente Ente
Nível 0
Nível 1
Nível 2 Nível 2
(a) Mobilidade Lógica (b) Mobilidade física sem mobilidade lógica
Mobilidade
Ente
História
Ente
História
Ente Ente
Ente
História
Ente Ente
Nível 0
Nível 1
Nível 2 Nível 2
Mobilidade
Nodo 1 Nodo 2
19
CORBA e Java/Jini abordam a questão da heterogeneidade, porém não se aprofundam em aspectos pertinentes à adaptabilidade.
A integração do Holoparadigma com o EXEHDA constitui uma abordagem integrada de software e ambiente de execução direcionada às redes heterogêneas, com suporte às mobilidades lógica (software) e física (hardware), voltada à execução de aplicações distribuídas em escala global e baseada em componentes de software. Uma visão de composição da proposta linguagem de programação e seu ambiente de execução pode ser visto na figura 2.5 (uma visão sintética da figura 2.1).
FIGURA 2.5 – Contexto de Execução
Uma visão global do EXEHDA pode ser vista na figura 2.6. Nesta figura aparecem: a geração do código adaptativo (ISAMadapt), o compilador do Holoparadigma o qual gera código Java estendido e os dois níveis do EXEHDA. Um nível voltado para o nível da aplicação, e outro direcionado para a administração do nível físico.
A gerência da infra-estrutura física do ambiente de execução ISAM integra-se
com o Globus Toolkit sob três aspectos:
a) monitoramento de hosts disponíveis: este módulo do ambiente de execução
interage com o serviço Globus HBM para detecção da presença de hosts. A informação dos processadores disponíveis é repassada para o serviço de escalonamento. O emprego efetivo do host pela aplicação, será determinado pelo serviço de escalonamento em função de seus índices de ocupação. As métricas e as heurísticas de escalonamento são providas pelo middleware sem o emprego de funcionalidades do Globus.
b) disparo remoto de serviços do ambiente de execução: este módulo interage
com os serviços Globus GRAM e GEM para disparar o suporte para o middleware ISAM nos hosts da arquitetura distribuída. A informação de disponibilidade de hosts é obtida através do item a.
c) instalação dos arquivos necessários ao ambiente de execução: este módulo
interage com os serviços Globus GridFTP e GASS com o objetivo de disseminar nas células (vide figura 2.7) que compõem o ambiente de execução os arquivos executáveis, classes Java e arquivos de configuração necessários ao ambiente de
20
execução. O tamanho da célula é configurável e os hosts EXEHDAbase concentram os serviços de gerência da mesma.
FIGURA 2.6 – Visão Geral do EXEHDA
O contexto de Grid Computing é mapeado em células de execução como pode
ser visto na figura 2.7. Considera-se que os hosts móveis devam usufruir a infra-estrutura de rede fixa existente, beneficiando-se de ambientes como o oferecido pela Internet. Este modelo é refletido nos elementos básicos do ambiente de execução do sistema ISAM:
• EXEHDAcél - denota a área de atuação de uma EXEHDAbase, e é composta pela mesma e por HoloSítios;
• EXEHDAbase - é o ponto de contato do host móvel com os serviços ISAM residentes na parte fixa da rede. Possui as funções de identificação, autenticação e de ativação das ações básicas do sistema;
• EXEHDAnó - são os nodos do sistema responsáveis pela execução da aplicação móvel distribuída propriamente dita. Nestes também processam serviços de gerenciamento ISAM;
• EXEHDAmob-nó - são os nodos móveis do sistema. Análogos aos EXEHDAnós, atuam na execução das aplicações e em algumas funções de monitoramento de recursos, conforme seu poder computacional. Os de menor porte tratam somente da interação com o usuário;
• EXEHDAhome - é um ponto de referência único por usuário móvel no âmbito de toda rede. Está associado a um EXEHDAnó registrado para tal na arquitetura.
21
FIGURA 2.7 – Elementos Básicos do Ambiente de Execução
2.3.1 Características do EXEHDA
Esta seção objetiva destacar os aspectos que caracterizam o EXEHDA. Uma discussão destas características pode ser encontrada em [YAM 2002b]:
• sua operação ocorre sobre o sistema operacional, e sem exigir alteração do mesmo. Isto potencializa a portabilidade;
• pode suportar tanto execuções paralelas como distribuídas. Para tal, interfaces de programação para comunicação interprocessos, tanto síncronas quanto assíncronas, são disponibilizadas;
• não está comprometido com uma heurística de escalonamento em particular. Ao contrário, disponibiliza facilidades para que novas heurísticas sejam implementadas. Esta política também se aplica no que diz respeito aos procedimentos de sensoriamento;
• a heurística de escalonamento/sensoriamento a ser utilizada é selecionada e/ou contextualizada por usuário e aplicação;
• os componentes que tomam decisão são replicados, e são capazes de atividades autônomas e assíncronas. Este aspecto é indispensável para uma operação com elevada escalabilidade. Os servidores que irão compor a gerência distribuída da HoloTree se enquadram nesta situação;
• as metas de escalonamento são perseguidas em escopos. Cada componente que toma decisão escalona serviços no seu domínio;
• uso intensivo de registro histórico como auxiliar na tomada de decisão.
22
Algumas dessas características são típicas de propostas de ambiente de execução com escalonamento difuso e voltadas para aplicações com elevada dinamicidade de execução.
No que diz respeito às estratégias para maximização do desempenho da execução de aplicações Holoparadigma, o escalonamento no EXEHDA utiliza os seguintes princípios:
• balanceamento de carga nos nodos responsáveis pelo processamento;
• localização dos recursos (software e hardware) mais próximos (reduzir custo de comunicação);
• emprego de replicação de serviços e de dados;
• disponibilização antecipada, por usuário, da demanda de componentes das aplicações e dos dados;
• otimização no volume de comunicações, utilizando transferências de contextos e componentes de aplicação personalizadas por usuário;
• monitoração da comunicação praticada pelos componentes das aplicações em execução, com intuito de otimizar aspectos de mapeamento;
• uso de uma estratégia colaborativa entre o ambiente de execução e a aplicação na tomada de decisões de escalonamento (adaptação).
O emprego destes procedimentos fica potencializado pela possível alternância do ponto de conexão dos EXEHDAnós móveis no contexto da rede, comportamento este inerente à computação móvel.
2.3.2 Decisões de Adaptação do EXEHDA
A adaptação é um processo disparado em resposta a uma situação ou evento externo, resultando na troca de um recurso ou por outro ou pela alteração na qualidade do serviço prestado. A adaptação faz o sistema se acomodar às alterações nos recursos disponíveis para ser capaz de continuar trabalhando com a melhor qualidade possível, em cada momento. Pesquisas recentes estão começando a tratar desse problema, porém o fazem com um tipo de aplicação em específico, tais como processamento de imagens ou multimídia. A inovação desta proposta integrada, formada pelos projetos Holoparadigma, EXEHDA e ISAMadapt, está em projetar uma arquitetura com um tratamento uniforme da adaptação e não comprometida com um domínio específico de aplicação. Isto é um fator complicador na proposta, porém justifica-se por se considerar que o potencial de aplicabilidade da computação móvel é amplo. Novos tipos de aplicações estão surgindo derivados do comportamento do usuário móvel (ainda não totalmente entendido/conhecido). Com isto, projetar aplicações móveis é uma tarefa difícil e esta deve ter uma ampla colaboração do sistema. Argumenta-se que para simplificar a tarefa de projetar aplicações móveis distribuídas, o programador deve ter à disposição uma linguagem para expressar aplicações de propósito geral, com abstrações para expressar a mobilidade e a adaptabilidade, e um ambiente de execução que lhe forneça mecanismos para especializar o comportamento móvel adaptativo ao domínio específico da aplicação.
23
2.3.3 Dimensões e Níveis de Adaptação
Pelo exposto, a adaptação ocorre como reação às variações no contexto de execução da aplicação. Desta forma, vê-se que as aplicações móveis podem se adaptar ao longo de três dimensões: temporal (quando ela ocorre), espacial (escolha dos recursos e serviços) e pessoal (preferências e comportamento individual do usuário). Por sua vez, em cada dimensão, pode-se pensar na adaptação em três níveis de abrangência: recursos - relativo às reações às mudanças em recursos físicos, como banda e latência da rede, alterando à qualidade da informação; conteúdo - relativo às alterações na semântica da aplicação, desde que esta pode alterar não somente o formato da informação, mas também seu conteúdo, como as location-aware applications; situação - relativo às mudanças do comportamento do usuário final em face de um novo contexto. Por exemplo, a funcionalidade da aplicação em execução se altera quando o usuário está em determinado local: escritório, casa ou carro. Nos sistemas móveis atuais somente o nível básico, de recursos, é normalmente presente nas arquiteturas de software analisadas.
2.3.4 Transparência x Consciência da Mobilidade
Uma grande diferença entre os sistemas distribuídos tradicionais e os novos sistemas para suporte a computação móvel, é que os primeiros procuram fornecer transparência da distribuição ao usuário, enquanto que nos segundos um certo grau de consciência da mobilidade (localização, contexto) é importante para o comportamento adaptativo. Assim, é necessário estabelecer um equilíbrio entre consciência e transparência (em geral, conflitantes) da mobilidade: o sistema deve fornecer informações sobre o ambiente requeridas pela aplicação para que esta possa reagir (adaptar-se) conforme suas necessidades. Os middlewares dos ambientes de execução correntemente disponíveis não fornecem facilidades para controlar o grau de transparência requerido pela aplicação móvel. Também neste aspecto, a arquitetura do EXEHDA se diferencia das demais.
2.3.5 A Organização do Escalonamento no EXEHDA
No ISAM, as aplicações solicitam direta ou indiretamente recursos do escalonador. Algumas podem especificar uma determinada necessidade de qualidade de serviço (QoS), outras podem aceitar o “melhor-possível” nos níveis de serviço. Assim, o módulo de escalonamento do middleware, tem a estratégia de trabalhar com diferentes políticas de gerenciamento para diferentes aplicações, usuários e/ou domínios de execução. Neste caso, as estratégias de adaptação exigem do mecanismo de escalonamento o tratamento de problemas de otimização utilizando critérios múltiplos.
2.3.6 A Adaptação Multinível Colaborativa
A proposta ISAM contempla um comportamento adaptativo em dois segmentos: (1) na aplicação, a qual define o comportamento da adaptação (alternativas) e o contexto de seu interesse; (2) no ambiente de execução (EXEHDA), o qual tem um comportamento inerentemente adaptativo no momento em que processa a aplicação.
24
Uma visão estrutural da Adaptação Multinível Colaborativa proposta pode ser vista na figura 2.8.
Na codificação da aplicação, o programador especifica os elementos computacionais que afetam o comportamento da aplicação, os respectivos níveis de variação suportados e codifica comportamentos alternativos para atender à variação nas condições ambientais (variação nos elementos computacionais no contexto da aplicação).
Estas informações influenciam o comportamento adaptativo a ser adotado pelo ambiente de execução. Por sua vez, o ambiente de execução fornece meios (a) para que sejam monitorados elementos computacionais do ambiente, (b) para que a aplicação possa registrar seu interesse em determinados elementos, (c) para notificar à aplicação das alterações ocorridas, e (d) para selecionar o comportamento alternativo mais adequado ao ajuste das novas condições ambientais. Como o sistema que gerencia as aplicações, este também pode ter um comportamento pró-ativo, e executar adaptações relativas à administração e desempenho do sistema de forma global. A proposta de adaptação multinível colaborativa está detalhada em [YAM 2002c].
FIGURA 2.8 – A Adaptação Multinível Colaborativa
Neste sentido, um problema de pesquisa em andamento, é estabelecer o nível de cooperação requerido entre projetistas de sistemas e projetistas de aplicações para criar protocolos aceitáveis para ambos os grupos.
Por outro lado, o ISAM gerencia diversas aplicações que concorrem na utilização dos recursos. A otimização da execução de um subconjunto do total de aplicações não pode comprometer o nível mínimo de QoS necessário para o restante. Desta forma, o escalonador precisa trabalhar com uma visão global das execuções em andamento.
2.3.7 Organização Física do Escalonamento
A forma como é organizada a distribuição dos equipamentos afeta diretamente todos os serviços de um middleware, e naturalmente o seu escalonamento. A
25
organização adotada no EXEHDA é a celular hierárquica (veja a figura 2.7). Nesta, os equipamentos pertencentes a uma mesma célula comunicam-se diretamente (utilizando uma organização plana). Nas comunicações com o exterior um equipamento específico atua como fronteira. A característica hierárquica faculta que uma célula possa recursivamente conter outras. Esta proposta de escalonamento foi apresentada em [YAM 2001].
Esta organização atende a necessidade de confinamento de contexto inerente ao modelo de programação adotado para o EXEHDA, o Holoparadigma. Este modelo é baseado em eventos associados a escopos. Outrossim, a organização celular hierárquica é orgânica com o Holoparadigma, o qual trabalha com o conceito de entes (entidade de modelagem). O conceito de entes também contempla a possibilidade de agrupamento hierárquico. Tal associação se mostra oportuna ao mapeamento e/ou à alocação dinâmica de tarefas.
Em função das características do software e do hardware, o escalonamento no middleware ISAM utiliza uma organização fisicamente distribuída e cooperativa representada na figura 2.7. Como principais premissas passíveis de serem atingidas por esta organização tem-se: tolerância a falhas, escalabilidade, autonomia dos domínios administrativos (EXEHDAcel) e suporte a múltiplas políticas de escalonamento.
A proposta está baseada em dois escalonadores (figura 2.9): (1) EscCel e (2) EscEnte:
EscCel: fica localizado no nó EXEHDAbase com atuação entre as EXEHDAcels. O mesmo tem atribuições no gerenciamento global da arquitetura, tais como:
• localizar recursos (hardware e software) mais próximos, para reduzir custos de comunicação;
• decidir quando e onde replicar serviços e/ou componentes de software (entes);
• decidir quando e para onde migrar os componentes de software;
• instanciar o Ambiente Virtual do Usuário nos EXEHDAnós. Esta instanciação é feita sob duas óticas: (1) balanceamento de carga - neste caso é escolhido o nó menos carregado, (2) aspectos de afinidade da aplicação - exigência de memória, bases de dados, etc.;
• disponibilizar antecipadamente, por usuário, a demanda de componentes das aplicações e dos dados;
• repassar ao escalonador EscEnte a carga de trabalho (componentes de software) proveniente de outras EXEHDAbase.
Pelas suas atribuições, além da consideração de custos de comunicação e balanceamento de carga, o escalonador EscCel atua de forma intensiva sobre aspectos de replicação e migração.
EscEnte: também existente em todas as EXEHDAbases, tem atribuições no gerenciamento interno da EXEHDAcel, tais como:
• efetuar o mapeamento dos componentes da aplicação nos EXEHDAnós da EXEHDAcel. Os critérios utilizados também são balanceamento de carga e de afinidade funcionais;
26
• dar suporte aos procedimentos de adaptação colaborativa multinível com a aplicação.
FIGURA 2.9 – Organização do Escalonamento
Uma estratégia do escalonador EscEnte é associar o contexto (a EXEHDAcel, as
aplicações e os usuários) a grupos de escalonamento, onde cada grupo pode definir políticas especificas de balanceamento de carga. Cabe ao mecanismo de escalonamento gerir a evolução da execução das aplicações dos diferentes grupos segundo as políticas por eles selecionadas.
EscCél
EscEnte EXEHDABase
EXEHDASítio EXEHDASítio
EXEHDASítio
EXEHDABase
EXEHDASítio
EXEHDASítio EXEHDASítio
EXEHDACél
EXEHDACél
EscEnte
27
3 O Serviço de Nomes como Núcleo Funcional do EXEHDA-HM
Esse capítulo tem como objetivo discutir os principais aspectos relacionados a serviços de nomes em geral, e após, descrever como os mesmos contribuíram para a concepção do EXEHDA-HM. O EXEHDA-HM tem como função central gerenciar e coordenar um conjunto de entes pertencentes a uma aplicação Holo distribuída. Cada servidor tem conhecimento de um subconjunto dos entes da aplicação, sendo esse conhecimento armazenado em seu espaço de nomes. Para manter a consistência da HoloTree distribuída, cada servidor poderá (e deverá) consultar os espaços de nomes de servidores remotos. Algumas alternativas para a resolução dessas e de outras questões serão discutidas ao longo desse capítulo.
3.1 Serviço de Nomes em Sistemas Distribuídos
O emprego de um serviço de nomes é uma questão central no desenvolvimento de sistemas distribuídos; uma boa estratégia permite que objetos residentes em nodos distintos de uma arquitetura distribuída interajam, sem que saibam previamente da localização de outros objetos. Isso se dá através da consulta a um servidor de nomes, que mantém, de forma centralizada ou não, um mapeamento entre o nome de um objeto e a localização desse objeto. Um nome é um identificador de objeto, isto é, um nome identifica um ou mais objetos; um nome único, por outro lado, identifica um único objeto.
Em [TER 84], é proposto o uso de convenções para a nomenclatura de objetos distribuídos, com o objetivo de facilitar o compartilhamento e uso desses recursos. Dessa forma, o conjunto de nomes, obedecendo a um dado conjunto de convenções, seria chamado um espaço de nomes.
Um serviço de nomes distribuído pode ser visto sob duas perspectivas distintas: do sistema ou do usuário. O sistema deve ser capaz de gerenciar um conjunto de objetos concorrentes contidos em diferentes nodos de um sistema distribuído; além disso, dado o nome de um objeto, o sistema deve ser capaz de localizá-lo. O usuário, por sua vez, deve ser capaz de acessar serviços disponibilizados por um conjunto de objetos, dado o nome do serviço desejado, sem necessariamente saber onde o objeto ou o serviço se encontra.
Segundo [ZNA 92], os componentes de um serviço de nomes podem ser classificados como estruturais ou funcionais. Os componentes estruturais estão relacionados à construção do serviço de nomes baseado em entidades ativas, chamadas de servidores de nomes. Os componentes funcionais são responsáveis por tratar questões relacionadas à (1) comunicação, (2) gerenciamento da base de dados, e (3) gerenciamento de nomes. Dessa forma, o módulo de comunicação seria responsável por definir os modos de comunicação entre os clientes e os servidores do serviço de nomes. O componente de gerenciamento da base de dados especificaria os mecanismos adequados para armazenar e recuperar os atributos dos objetos nomeados. Por fim, o componente de gerenciamento de nomes seria responsável pelas questões básicas relacionadas à distribuição e resolução de nomes.
28
Algumas características que devem ser providas por um sistema de nomes são: (1) a unicidade de nomes entre os objetos do sistema para que seja possível distinguí-los; (2) os nomes devem ser fáceis de usar; (3) deve ser possível comunicar os nomes para outros nodos do sistema; e por fim, (4) deve ser possível pesquisar por outros objetos, provavelmente através da consulta a um servidor de nomes responsável por manter informações referentes aos mesmos.
Além disso, o serviço de nomes utilizará um tipo de nome para gerenciar os objetos distribuídos, mas poderá ainda oferecer outro tipo de nome para ser utilizado pelos usuários do sistema; nesse caso, deverá existir algum algoritmo que traduza nomes de um tipo para outro (mapeamento). Como a criação de objetos pode ocorrer em qualquer nodo da arquitetura distribuída, a unicidade de nomes não pode ser comprometida – é necessário garantir que objetos com o mesmo identificador não serão criados por nodos distintos. Por fim, uma boa estratégia de distribuição de nomes e localização de objetos deve ser fornecida pelo serviço de nomes. Essas e outras questões serão discutidas nas seções a seguir.
3.2 Tipos de Nomes
Para que o sistema possa gerenciar um conjunto de objetos distribuídos, ele deve ter alguma forma de nomeá-los para uma posterior localização. Além disso, caso os objetos estejam à disposição dos usuários do sistema, deve haver também alguma forma desses acessarem tais objetos. Existem diversos tipos de nomes, e entre eles os mais relevantes são:
Nomes de sistema: utilizados para identificar unicamente um objeto no sistema. Geralmente, têm uma estrutura que facilita o gerenciamento dos objetos pelo sistema, mesmo que essa não seja uma boa representação para os usuários do sistema.
Nomes de usuário: utilizados para que usuários possam localizar serviços providos pelos objetos do sistema. São nomes de fácil manipulação por parte do usuário, mas não necessariamente eficientes para o gerenciamento. O sistema deve fornecer alguma forma de relacionar nomes de usuário e nomes de sistema (possivelmente através de um mapeamento).
O conjunto de nomes forma um espaço de nomes (name space), o qual pode possuir uma estrutura plana ou hierárquica. O modo como o servidor organizará seu espaço de nomes dependerá da estratégia a ser empregada. A estrutura do espaço de nomes fornece o contexto para um determinado nome, onde são definidos seu escopo, sua semântica e sua visibilidade.
Geralmente nomes de sistema são armazenados em espaços de nomes planos, enquanto que nomes de usuário em espaços hierárquicos. Espaços de nomes planos são mais simples de serem gerenciados, enquanto que os hierárquicos fornecem uma melhor forma de lembrança dos nomes, e um melhor encapsulamento, facilitando o uso por parte do usuário. A tarefa de mapear um nome de usuário (nome lógico) em um nome de sistema (nome físico) pode ser feita transparentemente pelo sistema, o que reduz a complexidade da aplicação.
29
3.3 Mapeamento Entre Nomes
Considerando que o sistema suporte mais de um tipo de nome na identificação de objetos (por exemplo, nomes de sistema e nomes de usuário), deve ser empregado algum algoritmo que realize o mapeamento entre diferentes tipos de nomes. O mapeamento pode ser feito explicitamente, solicitando-se ao serviço de nomes a conversão de um determinado nome de usuário em nome de sistema, ou implicitamente, durante a solicitação de um serviço a um determinado objeto identificado por seu nome de usuário. Nesse caso, a conversão será feita automaticamente e de forma transparente ao usuário.
Segundo [CAL 94], a relação que mapeia nomes de usuário em nomes de sistema é tipicamente uma das seguintes:
One-to-one: É o tipo mais simples de mapeamento, onde um nome de usuário pode ser considerado um tipo de nome de sistema, possuindo todas as propriedades que nomes de sistema devem ter (unicidade, por exemplo);
One-to-many: Um único nome de usuário corresponde a diversos nomes de sistema. Este mapeamento geralmente é utilizado na identificação de grupos de objetos.
One-to-one-out-of-many: Mapeamento utilizado para identificar através de um nome comum, um conjunto de objetos fortemente relacionados, como por exemplo, cópias replicadas de um mesmo objeto ou serviço. Nesse caso, um elemento do conjunto é selecionado pela função de mapeamento.
Many-to-one: Este tipo de mapeamento é empregado quando um objeto ou serviço tem diversos aliases pelos quais pode ser identificado.
Many-to-many: Nesse caso, um grupo de objetos possui diversos aliases, que identificam todos os membros de um grupo.
Cada tipo de relação de mapeamento tem suas vantagens. Um mapeamento one-to-one é muito simples e eficiente de ser implementado, através do simples emprego de uma função de hash, responsável por converter um nome de usuário em um nome de sistema. O mapeamento one-to-many fornece um mecanismo de nomeação de grupos de objetos, onde somente o nome do grupo necessita ser conhecido, mas não necessariamente o nome de cada um de seus participantes. O mapeamento one-to-one-out-of-many é um tipo especial de mapeamento onde, por exemplo, somente o nome do serviço ou objeto é importante, mas não a réplica onde a solicitação será processada. Mapeamentos many-to-one e many-to-many permitem o uso de aliases para identificar objetos ou serviços do sistema.
3.4 Geração Distribuída de Nomes
Em sistemas distribuídos, a geração de nomes pode ser uma tarefa não trivial, e isso irá depender das propriedades que serão necessárias aos nomes gerados pelo sistema. Entre essas propriedades, destacam-se:
Unicidade: A unicidade é requerida, por exemplo, na geração de nomes de sistema, onde um nome deve identificar exatamente um único objeto, a fim de que o sistema possa gerenciar os objetos que formam a aplicação. Por outro lado, nomes de usuário não necessitam serem únicos e sua criação pode ser mais flexível, ou mesmo
30
deixada a cargo do usuário, dependendo da função de mapeamento empregada e da semântica de nomes de usuário definida pelo sistema.
Migração de objetos: A migração de objetos permite que um determinado objeto seja movido entre diferentes nodos de um sistema distribuído. Sistemas que empregam essa estratégia têm como objetivo o aumento da eficiência do processamento geral do sistema. Nesses sistemas, a geração de nomes torna-se um pouco mais complicada pois o nome deve identificar o objeto e o nodo em que o mesmo está localizado.
Transparência de localização: Caso seja permitida a mobilidade de objetos durante sua execução, nomes que sejam independentes de localização podem ser de grande vantagem. Se um objeto com nome dependente de localização precisar ser movido, então todas as ocorrências de seu nome deverão ser alteradas para apontar para a nova localização. Por outro lado, nomes únicos dependentes de localização são mais fáceis de gerar, uma vez que o nodo responsável pela criação do objeto pode colocar em seu nome algum esquema de nomeação local utilizado pelo nodo em questão.
Estrutura do espaço de nomes: o espaço de nomes utilizado pode apresentar uma estrutura plana ou hierárquica. No caso de uma estrutura hierárquica, essa poderá facilitar a geração de nomes únicos, uma vez que o nome somente precisará ser único dentro de seu contexto. Por outro lado, um objeto deverá ser referenciado somente junto ao contexto no qual está inserido, para que dessa forma possa-se garantir que o objeto correto está sendo identificado.
Estrutura interna dos nomes: Um nome pode ou não ter uma estrutura interna, o que influenciará fortemente a geração de nomes. Nomes não estruturados têm como vantagem permitir uma nomeação uniforme de todos os objetos. Além disso, nomes não estruturados são independentes de localização, facilitando sua utilização em objetos móveis. Porém, sua geração é mais difícil, uma vez que deve ser garantida a unicidade de nomes entre diferentes nodos de um sistema distribuído através da coordenação desses nodos A geração de nomes únicos estruturados pode ser mais fácil que a geração de nomes não-estruturados, caso mais de um identificador seja utilizado (um identificador de objeto, e um identificador do nodo responsável por seu gerenciamento).
O mecanismo de geração de nomes a ser empregado depende fortemente das propriedades listadas acima. Se não há a necessidade de que os nomes gerados sejam únicos, então uma estratégia baseada na geração local de nomes por cada nodo pode ser utilizada, onde cada nodo gera seus nomes, sem a necessidade de sincronização com outros nodos. Porém, a geração de nomes de sistema deve ser coordenada entre os diversos nodos que compõem o sistema para garantir a unicidade dos nomes. A seguir, são apresentadas três estratégias que têm essa finalidade em sistemas distribuídos:
Concatenação Hierárquica
Nessa estratégia, um identificador único é atribuído a cada domínio na hierarquia (geralmente cada host). O identificador do objeto dentro do domínio é então concatenado com o identificador do domínio para produzir um identificador único. As vantagens e desvantagens dessa estratégia são apresentadas na tabela 3.1:
31
TABELA 3.1 – Vantagens e Desvantagens da Concatenação Hierárquica como Estratégia para a Geração Distribuída de Nomes
Vantagens Desvantagens
• Os identificadores de domínio não precisam ter a mesma eficiência que os identificadores de objetos, uma vez que eles serão criados com uma freqüência muito menor que os identificadores de objetos.
• O algoritmo utilizado na implementação dessa estratégia é muito simples e bastante comum.
• Se nomes dependentes de localização forem usados, então o identificador do Domínio pode localizar imediatamente o objeto.
• A forma e o tamanho dos identificadores pode variar se essa estratégia for utilizada em sistemas heterogêneos, tornando-os difíceis ou ineficientes de usar em algumas aplicações.
• As fronteiras entre os hosts são explicitamente visíveis.
Abordagem Uniforme
A abordagem uniforme baseia-se no desenvolvimento de um conjunto de identificadores globais de objetos gerados uniformemente e que podem ser utilizados pelos objetos do sistema. Dessa forma, identificadores locais seriam amarrados (temporariamente ou permanentemente) a identificadores globais. O nível de indireção introduzido por este mecanismo apresenta algumas vantagens e desvantagens, as quais são listadas na tabela 3.2:
TABELA 3.2 – Vantagens e Desvantagens da Abordagem Uniforme como Estratégia para a geração Distribuída de Nomes
Vantagens Desvantagens
• Mapeamentos many-to-one e one-to-many entre identificadores locais e globais tornam-se muito fáceis, uma vez que a indireção já está presente.
• Identificadores globais podem ser re-atribuídos, caso os objetos migrem ou deixem de existir.
• Desenvolvimento de uma forma padrão para os nomes globais não é direto, e deve ser utilizada em todos os nodos do sistema.
• A atribuição de identificadores globais ainda necessita de uma sincronização entre os nodos.
• Uma implementação dessa estratégia é mais complicada que a implementação da concatenação hierárquica.
Concatenação
Essa estratégia baseia a geração de nomes em um identificador de nodo e um relógio de tempo real para gerar nomes únicos. Note que essa estratégia produz nomes
32
dependentes de localização. Como a precisão do relógio excede a taxa de criação de nomes, garante-se a geração de identificadores únicos.
A técnica da concatenação hierárquica é facilmente implementável, com uma boa eficiência. Porém, a flexibilidade oferecida pela abordagem uniforme é maior, porque identificadores locais são realmente nomes de usuário, e o sistema mapeia automaticamente identificadores locais em identificadores globais.
3.5 Distribuição e Resolução de Nomes
Distribuição e resolução de nomes são conceitos bastante dependentes entre si. Distribuição de nomes define como o conhecimento a respeito dos nomes dos objetos é distribuído entre os nodos que compõem o sistema distribuído. Resolução de nomes define como a localização de um objeto pode ser determinada, dado o identificador desse objeto.
A distribuição de nomes tem como objetivo gerenciar nomes de uma forma descentralizada. Uma técnica centralizada, apesar de ser mais facilmente implementável, pode tornar-se um gargalo para o sistema. Existem diversos esquemas possíveis para realizar a distribuição de nomes, dependendo principalmente da quantidade e da natureza de informações compartilhadas. Em [CAL 94], são definidas as seguintes técnicas:
Técnica Centralizada: um único servidor é responsável por gerenciar os nomes
Nessa estratégia, um único nodo é responsável por todo o gerenciamento de nomes. Sendo assim, todas as consultas e atualizações passam por esse servidor de nomes. As vantagens e desvantagens dessa abordagem são listadas na tabela 3.3:
TABELA 3.3 – Vantagens e Desvantagens da Técnica Centralizada como Estratégia para Distribuição e Resolução de Nomes
Vantagens Desvantagens
• Provavelmente é a forma mais fácil de realizar a implementação.
• A resolução de nomes torna-se uma tarefa fácil, uma vez que o servidor de nomes conhece a localização de todos os objetos.
• A geração de identificadores únicos torna-se bastante fácil também, uma vez que as requisições podem ser serializadas pelo servidor.
• Os acessos ao servidor de nomes centralizado podem tornar-se um gargalo para o sistema.
• Em caso de falha do nodo central, toda a informação será perdida uma vez que não há replicação de dados.
33
Técnica Completamente Distribuída: todas as informações são distribuídas
Nessa abordagem, cada nodo mantém um servidor de nomes local para o gerenciamento de nomes. Todas as informações são compartilhadas entre todos os servidores, e as atualizações feitas em um nodo devem ser propagadas aos demais. Suas vantagens e desvantagens são apresentadas na tabela 3.4:
TABELA 3.4 – Vantagens e Desvantagens da Técnica Completamente Distribuída como Estratégia para Distribuição e Resolução de Nomes
Vantagens Desvantagens
• A resolução de nomes pode ser realizada em paralelo por vários nodos.
• Em caso de falha, a informação pode ser recuperada através de outro servidor de nomes, pois os dados são compartilhados e replicados em cada um deles.
• A criação de identificadores únicos independentes de localização deixa de ser uma tarefa trivial, uma vez que os servidores de nomes devem ser sincronizados para evitar a duplicação de nomes.
• Existe a necessidade de propagação de novos nomes para todos os nodos remotos.
• Como todos os dados são replicados, é requerido um grande espaço de armazenamento por parte dos servidores.
Técnica Distribuída Local: nenhuma informação é replicada
Nessa estratégia, cada servidor mantém somente as informações relativas aos nomes locais. A cada vez que uma resolução é solicitada e o objeto não é encontrado no servidor local, deve ser realizado um broadcast a todos os demais nodos participantes do sistema, e o nodo no qual o objeto em questão está residindo deverá informar a localização do objeto. As vantagens e desvantagens dessa abordagem são apresentadas na tabela 3.5:
34
TABELA 3.5 – Vantagens e Desvantagens da Técnica Distribuída Local como Estratégia para Distribuição e Resolução de Nomes
Vantagens Desvantagens
• Permite uma maior escalabilidade do sistema, pois somente as informações de objetos locais necessitam serem armazenadas.
• A implementação do algoritmo de resolução de nomes torna-se bastante simples, consistindo essencialmente de um broadcast para todos os nodos remotos, aguardando que alguém responda.
• A criação de novos objetos não implica na distribuição de informação para os demais nodos.
• A criação de identificadores únicos independentes de localização requer a sincronização dos servidores para evitar a duplicação de nomes.
• A resolução de nomes através de broadcast pode tornar-se um gargalo para o sistema, caso haja muitos nodos remotos.
• Resolução de nomes não pode ser feita em paralelo em todos os nodos simultaneamente, pois o broadcast é um fator serializante.
Técnica Parcialmente Distribuída: somente a informação necessária é distribuída
Essa solução é um meio termo entre a abordagem completamente distribuída, e a abordagem distribuída local. Nela, somente nomes que são usados remotamente necessitam realmente serem distribuídos. Todos os nomes locais são armazenados somente no nodo em que reside o objeto a que eles referem-se. Essa técnica tem suas vantagens e desvantagens descritas na tabela 3.6:
TABELA 3.6 – Vantagens e Desvantagens da Técnica Parcialmente Distribuída como Estratégia para Distribuição e Resolução de Nomes
Vantagens Desvantagens
• Resolução de nomes pode ser feita em paralelo em todos os nodos simultaneamente.
• A criação de novos nomes não necessariamente implica que o nome deva ser propagado para todos os demais nodos participantes.
• Menos informações necessitam serem compartilhadas, se comparada à técnica completamente distribuída.
• A técnica apresenta boa escalabilidade, mesmo se a freqüência de solicitações e o número de objetos no sistema aumentarem.
• A criação de identificadores únicos independentes de localização requer a sincronização dos servidores para evitar a duplicação de nomes.
• Somente os nomes usados em um nível global são replicados em outros servidores, logo a tolerância a falhas é parcial.
• Algum esquema de detecção deve ser desenvolvido para que o sistema possa manter o controle de quais objetos são utilizados globalmente.
35
Ainda existem variantes das técnicas apresentadas nessa seção. As questões mais importantes na escolha de uma estratégia de gerenciamento e resolução de nomes distribuídos estão relacionadas a (1) uma criação eficiente de identificadores únicos, (2) resolução rápida e eficiente de nomes, (3) escalabilidade e, (4) a redução da quantidade de informações trocadas. Alguns desses parâmetros podem ir de encontro a outro, e a combinação mais adequada desses fatores depende das características do sistema, e também das facilidades providas pelo ambiente, como por exemplo, uma rede que tenha suporte a broadcast, caso a Técnica Distribuída Local seja empregada.
3.6 O Serviço de Nomes do EXEHDA-HM
As seções anteriores discutiram características e alternativas para a implementação de serviços de nomes em sistemas distribuídos; esta seção, por sua vez, destina-se a apresentar alguns pontos chaves do serviço de nomes proposto pelo EXEHDA-HM para permitir o gerenciamento da HoloTree distribuída.
O primeiro ponto a ser destacado refere-se aos tipos de nomes suportados pelo serviço de nomes. O EXEHDA-HM não contempla a geração de nomes de sistema, os quais devem ser únicos para toda a aplicação: os nomes de sistema são gerados por outros módulos do EXEHDA, responsáveis pela gerência do meio físico, quando da criação dos entes no ambiente de execução. Em relação aos nomes de usuário, estes são definidos em tempo de codificação do programa Holo como sendo os nomes dos próprios entes, sendo utilizados de forma inalterada pelo EXEHDA-HM.
No espaço de nomes do EXEHDA-HM, o mapeamento entre nomes de usuário e nomes de sistema é realizado através de uma estratégia one-to-one: dessa forma, um nome de usuário é associado a apenas um nome de sistema.
O espaço de nomes adotado no EXEHDA-HM apresenta uma estrutura plana formada por uma tabela hash que armazena pares do tipo
<NOME_DO_ENTE, DESCRITOR_DO_ENTE>;
onde NOME_DO_ENTE refere-se ao nome de usuário pelo qual o ente pode ser localizado, e DESCRITOR_DO_ENTE é uma estrutura que armazena diversas informações a respeito do ente. Tais informações são utilizadas na manutenção da HoloTree, e entre as quais podemos destacar: nome de seu ente pai, nome de seus entes filhos, o host onde o mesmo está localizado, a referência física ao ente, etc...
Quanto à questão de distribuição de nomes, a abordagem inicialmente adotada foi a Técnica Distribuída Local, apresentada na seção anterior. Nessa abordagem, cada servidor mantinha as informações dos entes gerenciados pelo nodo local. Quando um nome necessitasse ser resolvido e o ente não fosse encontrado no espaço de nomes local, uma pesquisa remota era realizada nos diversos servidores que formavam a aplicação, aguardando até que algum deles respondesse a solicitação. Essa pesquisa era realizada por meio de um broadcast controlado; para que a rede não ficasse inundada de requisições, a pesquisa era realizada em grupos de nodos remotos de cada vez.
Porém, essa estratégia poderia comprometer a escalabilidade das aplicações – característica inerente às aplicações EXEHDA. [TER 84] observa que em ambientes que possuam um grande número de hosts, o custo de comunicação entre os clientes e os servidores de nomes é um fator crucial. Nesse tipo de sistema, a performance dos servidores de nomes é dominada pelo número de servidores que devem ser acessados, e
36
o custo de comunicação com esses servidores. Assim, o grupo de servidores de nomes que gerenciam coletivamente o espaço de nomes deveria ser configurado para minimizar os custos de localização.
Com isso, foi desenvolvida uma segunda alternativa de implementação, onde algumas informações de gerenciamento seriam replicadas, mas não os espaços de nomes em si. Nessa estratégia, uma tabela replicada em todos os nodos EXEHDA-HM manteria as informações sobre o nodo responsável pela criação de cada ente da aplicação (Base Position Table). Em uma segunda tabela auxiliar, não-replicada, cada servidor manteria uma entrada para os entes que têm como base o servidor em questão, onde seriam mantidas informações que indicassem a posição atual do ente (Current Position Table).
Dessa forma, quando da necessidade de localização de um ente, um servidor EXEHDA-HM inicialmente procuraria pelo servidor base do ente em sua Base Position Table. De posse do nome do servidor base do ente, o mesmo seria consultado para descobrir a posição corrente do ente (caso o mesmo fosse o servidor base, essa consulta seria local, caso contrário, a consulta seria remota). Assim, a obtenção da localização de um ente teria, no pior caso, o custo de duas consultas: uma consulta local à tabela de posições base replicada, e uma consulta remota à tabela de posições corrente. A figura 3.1 apresenta um diagrama de estados descrevendo como a consulta por um determinado ente é realizada pelo EXEHDA-HM.
FIGURA 3.1 – Diagrama Transição de Estados para a Consulta de Entes
Em muitos casos, essa segunda estratégia pode tornar-se mais eficiente, uma vez que não é mais necessária a consulta de entes através de um broadcast; possui como desvantagem a necessidade de replicação e propagação de informações de gerenciamento, porém esta se resume apenas às informações relacionadas ao servidor responsável pela criação de um determinado ente (servidor base): esse tipo de dado não muda durante toda a existência do ente na aplicação Holo, o que garante que as informações trocadas para manter a consistência das réplicas não comprometerão significativamente o desempenho da aplicação.
Consultando a tabela auxiliar (LOCAL) de POSIÇÃO CORRENTE de entes
Consultando a tabela auxiliar (REMOTA) de POSIÇÃO CORRENTE de entes
Servidor base é o próprio onde o comando foi executado?
[ Sim ] [ Não ]
Acessando descritor do ente
Consultando tabela auxiliar de POSIÇÃO BASE de entes para determinar a posição base do ente
37
Assim, buscou-se conciliar os aspectos positivos das propostas e técnicas para distribuição e resolução de nomes apresentadas na seção 3.5. Empregou-se dessa forma uma abordagem distribuída que, ao mesmo tempo em que evita um broadcast para a consulta de entes remotos, também exige que o mínimo de informações de gerenciamento seja replicada e propagada entre as diversas instâncias do EXEHDA-HM. O próximo capítulo discute, em maiores detalhes, tópicos relacionados às estratégias de gerenciamento e às estruturas de dados que são utilizadas na distribuição e resolução de nomes, feitas pelo EXEHDA-HM.
38
4 EXEHDA-HM: Modelagem e Princípios de Operação
Este capítulo descreve os principais aspectos pertinentes à concepção do módulo EXEHDA-HM. Nele é introduzida a HoloTree, são sumarizadas as principais contribuições do EXEHDA-HM (que compõe o Gerenciador de Contexto da Execução Distribuída presente na figura 2.6) para o EXEHDA, e discutidos os principais aspectos referentes à modelagem dos seus componentes.
4.1 HoloTree: Resumo das Principais Características
A execução de um programa escrito na Hololinguagem prevê a criação de uma estrutura hierárquica de entes, denominada Árvore de Entes ou HoloTree. A HoloTree implementa o encapsulamento de entes em níveis de composição, conforme proposto pelo Holoparadigma (veja figura 2.2). Em função disso, a modelagem do EXEHDA-HM deve suportar os aspectos dinâmicos da HoloTree distribuída, mudando continuamente durante a execução de um programa. As seguintes ações alteram a HoloTree:
• Clonagem: a clonagem de transição cria um novo ente no interior daquele que a executa (um nível abaixo na HoloTree);
• Mobilidade: a mobilidade lógica altera a HoloTree, deslocando um ente (elementar ou composto) de um ponto para outro da árvore.
• Extinção: através da extinção de entes, toda uma sub-árvore da HoloTree é removida da aplicação Holo.
Um ente composto possui ligações com seus entes componentes, os quais ficam localizados no nível abaixo. Os entes componentes possuem acesso à história e ao comportamento do composto no qual estão inseridos. Por sua vez, o composto possui acesso aos comportamentos dos seus componentes. Além disso, um ente possui acesso ao comportamento dos demais entes no mesmo nível.
A mobilidade é implementada no EXEHDA-HM através do gerenciamento de grupo seguindo princípios de controle de membership. Quando a mobilidade ocorre, torna-se necessária a mudança da visão do grupo dos entes envolvidos. O ente movido possui uma nova visão (novos entes no mesmo nível e um novo composto acima dele). Se o movido for um ente composto, a visão dos seus entes componentes não muda.
A mobilidade implica a atualização da composição dos entes origem e destino. Além disso, os componentes de um ente podem ser entes compostos (grupos de grupos). A mobilidade de um ente elementar equivale a realocação de uma folha da árvore e a mobilidade de um composto transfere um ramo contendo vários entes. A figura 4.1 caracteriza uma mudança ocorrida na HoloTree.
39
FIGURA 4.1 – Árvore de Entes (HoloTree)
4.2 EXEHDA-HM: principais contribuições ao ambiente de execução do Holoparadigma
As principais contribuições para o EXEHDA são as seguintes:
• contempla as primitivas do EXEHDA para suporte às ações que manipulam entes;
• implementa os procedimentos para garantia da coerência quando as ações manipularem entes compostos;
• oferece suporte para localização de recursos em geral no EXEHDA; • oferece suporte para a localização de entes, tanto logicamente quanto
fisicamente.
4.3 EXEHDA-HM: primitivas para a manipulação de entes
O EXEHDA-HM oferece um conjunto de primitivas que possibilitam a manutenção da HoloTree através do gerenciamento de entes que encontram-se distribuídos entre uma ou mais EXEHDAcels (vide figura 5.2). Essas primitivas permitem a criação, extinção e a mobilidade de entes, e são denominadas, respectivamente, CreateBeing, ExtinguishBeing e MoveBeing. A semântica dessas primitivas foi definida pela Hololinguagem, e isso garantiu ao EXEHDA-HM recursos para realizar a gerência adequada dos entes pertencentes à HoloTree distribuída. As seções seguintes descrevem cada uma dessas primitivas.
4.3.1 CreateBeing
Esse comando tem por objetivo atender a solicitação de criação de um ente. O ente pode ser criado e gerenciado no servidor EXEHDA-HM da EXEHDAcel na qual o comando clone foi chamado, ou a criação e o conseqüente gerenciamento podem ser delegados a outro EXEHDA-HM, caso o parâmetro destino informado contemple equipamento de outra EXEHDAcel. Seja como for, o servidor responsável irá inserir uma nova entrada no seu espaço de nomes, indicando a existência de um novo ente.
HistóriaHistória
Ente
História
Ente Ente Ente Ente
História
Ente Ente
HistóriaHistória
Ente Ente
Nível 0
Nível 1
Nível 2
(a) Árvore de Entes (HoloTree)
HistóriaHistória
Ente
História
Ente Ente Ente Ente
História
Ente Ente
HistóriaHistória
Ente Ente
(b) Mobilidade
MobilidadeOrigem Destino
40
Essa entrada, além das informações pertinentes ao ente recém criado, armazenará informações sobre seus entes filhos (que inicialmente não existirão) e informações sobre seu ente pai. Além disso, a entrada pai do ente criado deverá ser atualizada de modo que o mesmo tome conhecimento da existência de um novo componente em sua estrutura. A figura 4.2 apresenta o diagrama de estados para a primitiva CreateBeing.
FIGURA 4.2 – Diagrama de Transição de Estados da Primitiva CreateBeing
Os parâmetros recebidos pela primitiva CreateBeing são os seguintes:
• Nome do ente composto que terá como componente o ente a ser criado; • Nome do ente a ser criado; • Nome do host onde o ente deve ser criado; • Nome do nodo EXEHDAbase que deve ser utilizado na criação do ente. Este
parâmetro é opcional, e assume-se como valor default o EXEHDAbase pertencente à EXEHDAcel local;
4.3.2 ExtinguishBeing
Esse comando visa a remoção de um ente e de seus entes componentes da aplicação Holo em execução. O processo inicia quando é feita a chamada ao comando ExtinguishBeing em um dos servidores EXEHDA-HM. O servidor inicia uma busca pela entrada correspondente ao ente que se deseja extinguir, sendo essa busca feita no EXEHDA-HM da EXEHDAcel local, ou em servidores de EXEHDAcels remotas, caso as estruturas auxiliares de gerenciamento indiquem que o ente em questão não se encontra na mesma EXEHDAcel na qual o comando foi chamado. Uma vez encontrado, a entrada correspondente ao ente é removida do espaço de nomes do servidor em questão, e o ente é destruído. A etapa seguinte do algoritmo consiste em, recursivamente, extinguir todos os entes filhos do ente recém removido, podendo eles estar em qualquer um dos servidores EXEHDA-HM utilizados pela aplicação Holo. Para tanto, o mesmo procedimento utilizado para extinguir o ente base deve ser tomado, porém, executado recursivamente até que todo o ramo da HoloTree, que possua como
Atualizando entrada do ente pai
Iniciando o processocriar ente
Criando ente localmente Criando ente remotamente
Parâmetro destino informado?
[ Não ] [ Sim ]
41
raiz o ente base, tenha sido completamente removido. Além disso, para que a consistência da HoloTree distribuída seja mantida, o pai do ente cuja solicitação de extinção se referia deve ser informado de que um de seus entes componentes não existe mais: isso implica em uma nova consulta, procurando pelo EXEHDA-HM responsável pelo gerenciamento do ente pai, para que seu descritor seja atualizado. A figura 4.3 apresenta o diagrama de estados para a primitiva ExtinguishBeing.
FIGURA 4.3 – Diagrama de Transição de Estados da Primitiva ExtinguishBeing
O único parâmetro recebido pela primitiva ExtinguishBeing é o seguinte:
• Nome do ente a ser removido da aplicação (conseqüentemente, todos os seus entes componentes também serão removidos);
4.3.3 MoveBeing
A terceira primitiva fornecida pelo EXEHDA-HM permite a mobilidade lógica (e física) de um ente. O algoritmo empregado na implementação da primitiva MoveBeing segue o mesmo princípio das duas anteriores: em um primeiro momento, a entrada correspondente ao ente que se deseja mover deve ser procurada no servidor EXEHDA-HM da EXEHDAcel local, ou em servidores de EXEHDAcels remotas. Uma vez encontrada, a entrada é removida do espaço de nomes origem. Adicionalmente, a entrada correspondente ao pai do ente que será movido também deve ser atualizada, de forma a indicar que o ente não faz mais parte de seu contexto. A etapa seguinte consiste na localização da entrada correspondente ao ente destino. Uma vez encontrada, duas operações devem ser realizadas: a inserção da entrada do ente movido no espaço de nomes, e atualização da entrada do ente destino, indicando a existência de um novo componente em sua estrutura.
Iniciando o processo
Removendo ente do espaço de nomes do servidor determinado como servidor corrente do mesmo
Consultando tabela auxiliar de posição base de entes para determinar a posição base do ente pai a ser atualizado
Atualizando ente pai localizado no servidor determinado como servidor corrente do mesmo
Consultando tabela auxiliar de posição base de entes para determinar a posição base do ente a ser removido
extinguir entes componentes
[ Quando não houver mais entes filhos a serem extinguidos ]
Consultando a tabela auxiliar (local) de posição corrente de entes
Consultando a tabela auxiliar (remota) de posição corrente de entes
Consultando a tabela auxiliar (local) de posição corrente de entes
Servidor base do ente pai é o próprio onde o comando foi executado?
[ Sim ]
Consultando a tabela auxiliar (remota) de posição corrente de entes
[ Não ]
Servidor base do ente é o próprio onde o comando foi executado?
[ Sim ] [ Não ]
42
FIGURA 4.4 – Diagrama de Transição de Estados da Primitva MoveBeing
Iniciando o processo
Consultando tabela auxiliar de posição base de entes para determinar a posição base do ente pai a ser atualizado
Consultando tabela auxiliar de posição base de entes para determinar a posição base do ente destino
Inserindo ente no servidor determinado como servidor corrente do ente destino Atualizando ente destino
Removendo ente do espaço de nomes do servidor determinado como servidor corrente do mesmo
Consultando a tabela auxiliar (local) de posição corrente de entes
Consultando a tabela auxiliar (remota) de posição corrente de entes
Consultando tabela auxiliar de posição base de entes para determinar a posição base do ente a ser movido
Consultando a tabela auxiliar (local) de posição corrente de entes
Servidor base do ente pai é o próprio onde o comando foi executado?
[ Sim ]
Consultando a tabela auxiliar (remota) de posição corrente de entes
[ Não ]
Atualizando o ente pai localizado no servidor determinado como servidor corrente do mesmo
Consultando a tabela auxiliar (local) de posição corrente de entes
Consultando a tabela auxiliar (remota) de posição corrente de entes
Servidor base do ente é o próprio onde o comando foi executado?
[ Sim ] [ Não ]
Servidor base do ente destino é o próprio onde o comando foi executado?
[ Sim ] [ Não ]
43
A apresenta figura 4.4 o diagrama de estados da primitiva MoveBeing.
Os parâmetros recebidos pela primitiva MoveBeing são os seguintes:
• Nome do ente destino da mobilidade lógica (o novo pai); • Nome do ente a ser movido; • Valor booleano que indique se deve existir mobilidade física do ente. • Valor booleano que indique se os entes componentes devem acompanhar o ente
composto em uma mobilidade física, caso ela exista. Este parâmetro é opcional, e assume-se como default o valor false.
4.4 EXEHDA-HM: Estratégia de Gerenciamento
O gerenciamento realizado pelo EXEHDA-HM permite a manutenção da consistência da HoloTree em um ambiente distribuído. Para realizar esse gerenciamento, faz-se necessário o conhecimento de uma série de informações relacionadas tanto a entes pertencentes à mesma EXEHDAcel que o servidor, como também relacionadas aos entes pertencentes a EXEHDAcels remotas.
O conhecimento sobre os entes gerenciados localmente pelo servidor EXEHDA-HM é armazenado em uma estrutura chamada EXEHDA_HMSpace. Informações referentes a entes gerenciados por servidores remotos são mantidas em tabelas auxiliares replicadas. As seções seguintes descrevem essas estruturas.
4.4.1 O EXEHDA_HMSpace
O EXEHDA_HMSpace é uma estrutura de dados utilizada para armazenar qualquer tipo de recurso que venha a ser gerenciado pelo EXEHDA-HM, incluindo entes pertencentes a uma aplicação Holo. As informações pertinentes a um ente são utilizadas na construção de um descritor de ente (Being Descriptor) e então armazenadas no EXEHDA_HMSpace, associando-se o descritor do ente ao nome do ente. Internamente, o EXEHDA_HMSpace mantém uma tabela hash, contendo pares da forma <chave, valor>, onde o campo chave corresponde ao nome do ente, e o campo valor ao descritor do ente. Com o uso de uma tabela hash, a consulta de entes através de seu nome é realizada de forma bastante eficiente pelo EXEHDA-HM.
Em um descritor de entes, são mantidos todos os dados pertencentes a um ente, e que podem vir a serem úteis durante o seu gerenciamento. Entre essas informações, pode-se destacar: nome do ente pai, nomes dos entes filhos, máquina onde o ente está atualmente alocado, entre outras, de menor importância.
Em um EXEHDA_HMSpace são armazenados somente os entes gerenciados pelo servidor EXEHDA-HM em questão. Entes gerenciados por servidores remotos não são mantidos na estrutura local. Dessa forma, a proposta é que os entes pertencentes a uma aplicação Holo distribuída não se encontrem replicados entre os diversos servidores EXEHDA-HM.
Considerando que a mobilidade é premissa básica de um middleware como o EXEHDA, essa estratégia foi adotada devido à alta taxa de deslocamento dentro da HoloTree que os entes pertencentes a uma aplicação Holo podem apresentar. A manutenção das informações replicadas provocaria uma elevada taxa de troca de mensagens entre os servidores para garantir a manutenção da consistência das réplicas,
44
tornando o modelo ineficiente para a maioria das aplicações desenvolvidas na Hololinguagem.
Assim como a completa replicação de entes entre os diversos EXEHDA_HMSpace distribuídos poderia tornar-se uma estratégia pouco eficiente devido à necessidade de atualização dessas entradas, a completa falta de replicação também poderia provocar alguns problemas relacionados ao desempenho do modelo, forçando uma “busca cega” cada vez que um ente necessitasse ser localizado.
Seguindo essa estratégia, qualquer operação que necessitasse da localização de um ente não encontrado no EXEHDA_HMSpace local exigiria uma pesquisa, seqüencial ou paralela, entre os diversos servidores remotos. Essa abordagem poderia provocar um grande número de troca de mensagens, podendo ainda tornar-se um gargalo para o sistema.
Como solução proposta, empregou-se uma estratégia de replicação parcial, apenas das informações de gerenciamento, permitindo formas de manutenção de consistência e busca de entes mais eficientes. Essa solução faz uso de algumas tabelas auxiliares de gerenciamento, mantidas pelos servidores EXEHDA-HM, e que serão descritas na seção a seguir.
4.4.2 Tabelas Auxiliares de Gerenciamento: Base Position Table e Current Position Table
A manutenção de entes realizada pelo EXEHDA-HM conta com o auxílio de informações auxiliares de gerenciamento armazenadas em duas tabelas auxiliares: Base Position Table e Current Position Table.
A Base Position Table contém informações que indicam qual servidor EXEHDA-HM foi responsável pela criação de cada ente de uma HoloTree distribuída. Dessa forma, no momento da criação de um ente, o servidor EXEHDA-HM responsável pelo desencadeamento dessa ação, armazena em sua Base Position Table informação indicando que um ente foi criado por ele. Em seguida, essa informação é propagada para os demais servidores, fazendo com que todos tomem conhecimento do nodo responsável pela criação de um ente.
De forma semelhante, quando um ente é extinto, o responsável pela ação remove a entrada de sua Base Position Table, e propaga essa informação para os demais servidores, a fim de que todos saibam da não mais existência do ente.
A justificativa para o uso dessa estratégia de replicação parcial dos dados referentes a entes remotos, e não mais a replicação total dos entes contidos nos EXEHDA_HMSpace remotos encontra-se no fato de que as informações agora mantidas são constantes durante toda a vida do ente dentro da aplicação Holo. Uma vez criado, o ente terá o mesmo servidor base durante toda a sua existência, e este manterá conhecida a posição corrente do ente para que outros servidores possam, a partir da consulta ao servidor base, saber onde o ente encontra-se localizado atualmente. Assim, o servidor base de um ente, agirá como um tracker para esse ente. As informações são constantes no sentido de que, não importando para onde o ente seja movido durante a sua existência, a informação replicada referente ao servidor base daquele ente não será alterada.
45
Como já mencionado, a posição corrente do ente é mantida por seu servidor base. Em um primeiro momento, a posição corrente será idêntica à posição base; mas caso o ente seja movido de um ponto a outro da HoloTree, cabe ao servidor base manter controle da localização corrente do ente. Isso se dá com o auxílio de uma segunda tabela auxiliar: a Current Position Table. Essa tabela, diferente da anterior, não é replicada entre os servidores, mas sim mantida por cada servidor, mantendo o controle da posição corrente de cada ente para os quais o mesmo atua como o servidor base.
4.4.3 Estratégia de Propagação de Token: Vizinhança
O servidor responsável pela criação ou extinção de um ente também é responsável pelo início da propagação dessa informação para os demais servidores. Como já citado, todos nodos EXEHDA-HM têm conhecimento do servidor base de qualquer ente que componha a aplicação Holo, informação esta obtida através de uma simples consulta a sua Base Position Table. Essa tabela é replicada em todos os servidores, e informa qual EXEHDA-HM mantém o controle sobre a posição atual de um determinado ente.
A propagação das alterações na Base Position Table utiliza uma técnica de propagação de token em anel. Cada nodo EXEHDA-HM recebe em seu arquivo de configuração um dado informando qual é seu nodo vizinho, de modo que a topologia dos servidores EXEHDA-HM seja um anel. Dessa forma, no momento de execução do algoritmo de propagação, cada servidor EXEHDA-HM é responsável por propagar as informações de criação/extinção (armazenadas em uma estrutura chamada token) para seu vizinho, até que as informações tenham percorrido todo o anel, chegando novamente ao servidor que iniciou o processo de propagação. Nesse momento, o token é descartado, e dá-se por encerrado o processo de atualização da Base Position Table de cada um dos servidores. Como resultado, todas as instâncias do EXEHDA-HM saberão qual o servidor base do ente recém criado, ou então, da não mais existência do ente extinto.
46
5 EXEHDA-HM: Principais Aspectos da Implementação
Esse capítulo tem por objetivo apresentar os principais aspectos relacionados à implementação do EXEHDA-HM. As primeiras seções discutirão pontos referentes à linguagem e às ferramentas utilizadas no desenvolvimento do trabalho. A implementação do modelo será tratada logo a seguir, através da descrição das principais classes, acompanhada de um diagrama de classes simplificado do modelo. Será apresentado também o EXEHDA-HM Visual, uma ferramenta que irá auxiliar na depuração de programas escritos na Hololinguagem, permitindo a visualização das informações pertinentes aos entes em um ambiente distribuído. Por último, um estudo de caso demonstra o funcionamento do EXEHDA-HM.
5.1 A Linguagem Java
As funções de alto nível do ambiente de execução EXEHDA estão sendo implementadas na linguagem Java. O EXEHDA-HM sendo um módulo integrante do EXEHDA está sendo implementado também utilizando a mesma.
Java é uma linguagem que foi criada pela Sun Microsystems ([SUN 2002]) a partir de uma pesquisa corporativa interna com o codinome Green que ocorreu no ano de 1991. Deste projeto resultou a linguagem que é baseada em C e C++ e que seu criador, James Gosling, chamou de Oak (carvalho) em homenagem a uma árvore que dava para a janela de seu escritório na Sun. Descobriu-se mais tarde que já havia uma linguagem de programação que se chamava Oak. Quando uma equipe da Sun visitou uma cafeteria local, o nome Java (cidade de origem de um tipo de café importado) foi sugerido e teve seu uso consagrado pela prática.
Mas o projeto Green atravessava algumas dificuldades. O mercado para dispositivos eletrônicos inteligentes destinados ao consumidor final não estava se desenvolvendo tão rapidamente como a Sun tinha previsto. Pior ainda, um contrato importante pelo qual a Sun competia fora concedido à outra empresa. Então o projeto estava em risco de cancelamento. Por pura sorte, a World Wide Web explodiu em popularidade em 1993 e a equipe da Sun viu imediato potencial de utilizar Java para criar páginas da Web com o recurso de conteúdo dinâmico. Isso deu nova vida ao projeto.
Java apresenta inúmeras vantagens quando utilizada para a programação de um sistema distribuído como, por exemplo, a portabilidade de seu código. O compilador Java não gera instruções nativas; ao invés disso, ele gera bytecodes para uma máquina virtual, a Máquina Virtual Java (JVM). Qualquer arquitetura que possua uma JVM poderá processar os bytecodes, tornando o programa Java independente de plataforma. Esses e outros aspectos da linguagem são discutidos em [MOR 2000].
O fato de Java ser orientada a objetos contribuiu para o sucesso alcançado pela linguagem. A orientação a objetos promove o encapsulamento e a reutilização de código, facilitando o desenvolvimento de projetos realizados por um grupo de pessoas.
Os projetistas de Java, na Sun Microsystems, eram programadores C++. Eles entenderam o que havia de melhor na linguagem, suas características e suas limitações, e basearam toda a criação da linguagem Java em C++. Ao projetar a linguagem Java, eles copiaram a sintaxe de C++ e reutilizaram seus melhores elementos de projeto.
47
Além disso, eliminaram seus principais geradores de erros: ponteiros e gerenciamento de memória via código. Em Java, a alocação de objetos é feita de forma automática, não sendo necessário código específico para essa tarefa. A desalocação de objetos, também é feita de forma transparente ao programador, através do Garbage Collector (GC). O GC é uma thread que roda em baixa prioridade, liberando objetos que não estejam mais sendo referenciados por outros objetos em um programa Java.
Além disso, Java apresenta alta performance com multithreading interno para períodos de inatividade do processador facilitando a paralelização das aplicações. Java também suporta a programação de sistemas distribuídos, através de sockets e remote method invocation (RMI), entre outras formas de comunicação.
Java RMI
A Remote Method Invocation (RMI) permite comunicação entre objetos que estejam sendo executados em diferentes Java Virtual Machine (JVM). Essas JVMs podem estar localizadas em um mesmo host, ou em host distintos. Isso permite que aplicações invoquem métodos de objetos localizados remotamente, compartilhando recursos e processando, promovendo a distribuição de carga através do sistema. Além disso, os métodos podem passar como parâmetro objetos com os quais uma máquina virtual remota nunca tenha se deparado antes, permitindo o carregamento dinâmico de classes, conforme elas vão se fazendo necessárias.
A RMI está baseada em uma tecnologia anterior semelhante para programação procedural, denominada de Chamada de Procedimento Remoto (Remote Procedure Calls – RPC), desenvolvida nos anos de 1980. A RPC permite que um programa procedural (isto é, um programa escrito em C ou outra linguagem de programação procedural) chame uma função que reside em outro computador tão convenientemente como se essa função fosse parte do mesmo programa em execução. O objetivo central da RPC foi tornar transparente para o programador o mecanismo que permite às partes do aplicativo se comunicarem através de uma rede. A RPC realiza todas as funções de rede e ordenação (marshalling) dos dados (isto é, empacotamento de argumentos de função e valores de retorno para transmissão através de uma rede). Uma desvantagem de RPC é que ela suporta um conjunto limitado de tipos de dados simples. Portanto, a RPC não é adequada para passar e retornar objetos Java. Outra desvantagem da RPC é ela que exige do programador aprender uma linguagem de definição de interface (Interface Definition Language – IDL) especial para descrever as funções que podem ser invocadas remotamente.
A RMI é implementação da RPC para Java, objetivando a comunicação distribuída de um objeto Java com outro. Uma vez que um método (ou serviço) de um objeto Java é registrado como sendo remotamente acessível, um cliente pode “pesquisar” (“lookup”) esse serviço e receber uma referência que permita ao cliente utilizar esse serviço (isto é, chamar o método). A sintaxe da chamada de método é idêntica àquela de uma chamada para um método de outro objeto do mesmo programa. Como acontece com a RPC, a ordenação (marshalling) dos dados é tratada pela RMI. Entretanto, a RMI oferece transferência de objetos de tipos de dados complexos via o mecanismo de serialização de objetos. Qualquer objeto da linguagem Java pode ser utilizado na passagem de parâmetros de uma chamada remota, assim como o retorno dessa chamada, desde que o mesmo implemente a interface Serializable.
48
A Arquitetura RMI
O propósito do RMI é permitir que objetos localizados em JVMs distintas sejam capazes de serem acessados como se fossem objetos locais. A máquina virtual que chama o método remoto é geralmente referenciada como cliente, enquanto que a máquina virtual que contém o objeto remoto é referenciada como servidor. Um dos aspectos mais importantes do RMI é a sua transparência. Uma aplicação não necessita saber se um objeto é remoto ou local. Uma invocação de método em um objeto remoto tem a mesma sintaxe que uma invocação de método em um objeto local.
Embora a obtenção de uma referência a um objeto remoto seja um pouco diferente da realizada para objetos locais, o objeto remoto será utilizado como se fosse local. A infra-estrutura fornecida pelo RMI vai, automaticamente, interceptar a chamada ao método, localizar o objeto remoto, e processar a requisição remotamente. Essa transparência de localização inclui até mesmo mecanismos relacionados à garbage collection.
A implementação do RMI é constituída essencialmente de três camadas de abstração [AVE 2000]:
• Camada stub/skeleton: Essa camada intercepta as chamadas realizadas pelo cliente á referência, e redireciona-as para o objeto remoto.
• Camada de referência remota: Essa camada é responsável por tratar os detalhes relacionados á interpretação e gerenciamento dos acessos feitos por clientes aos objetos remotos. Ela define e suporta a semântica de invocação de uma conexão RMI. Além disso, essa camada conecta clientes e objetos remotos que estão ativos em um servidor através de um link one-to-one.
• Camada de transporte: Essa camada é baseada em conexões TCP/IP entre máquinas em uma rede. Ela provê a conectividade básica necessária para a comunicação entre hosts em um ambiente distribuído.
A figura 5.1 apresenta um diagrama da arquitetura RMI.
FIGURA 5.1 – Arquitetura RMI
49
Alternativas para o uso de RMI
Além do RMI, existem alternativas que permitem a comunicação entre diferentes máquinas virtuais Java. Entre elas, destacam-se:
• Sockets;
• Java Message Service (JMS);
Através do uso de sockets, o programador tem a disposição um mecanismo básico, porém suficiente e flexível, para o desenvolvimento de aplicações distribuídas. Contudo, o uso de sockets requer uma comunicação via protocolos de nível de aplicação, o que pode ser complicado e tendente a erros.
Segundo [AVE 2000], a principal diferença entre RMI e JMS encontra-se no fato de que em RMI os objetos permanecem residentes e amarrados (bound) a uma determinada máquina virtual (embora argumentos de métodos e valores de retorno, assim como stubs, possam ser enviados através da rede) enquanto que em JMS as mensagens (objetos) viajam fisicamente e de forma assíncrona através da rede, de uma JVM para outra. JMS é na verdade um middleware orientado a mensagens que conecta múltiplos sistemas de forma assíncrona através da produção e consumo de mensagens. Uma mensagem pode ser uma solicitação, uma notificação, ou um evento, enviado de uma parte da aplicação para outra.
RMI como mecanismo de comunicação no EXEHDA-HM
No EXEHDA, o processamento ocorre organizado em células. A abrangência de uma célula é determinada tendo por critério o custo de comunicação entre os nós processadores envolvidos. Este critério é empregado pelo administrador do sistema. Esta organização pode ser vista na figura 5.2.
Os equipamentos EXEHDAbase constituem o centro administrativo da célula, e dentre outras atribuições alojam os módulos distribuídos EXEHDA-HM que se interligam através de um mecanismo de pesquisa remota. Cada instância do EXEHDA-HM necessita comunicar-se com as instâncias residentes em outras células, a fim de que possam, de forma cooperativa, realizar o gerenciamento da HoloTree distribuída. Essa comunicação é realizada através da chamada de métodos remotos, com o uso de RMI. Optou-se por essa alternativa devido ao nível de abstração por ela oferecida, permitindo um certo grau de transparência na comunicação entre as instâncias do EXEHDA-HM, que tanto podem invocar seus métodos locais, como métodos de instâncias remotas, se assim for necessário durante o gerenciamento.
50
EXEHD Abase
EXEHDAbase
EXEHDAbaseEXEHDAnó n
EXEHD Anó 1 EXEHD Anó 2
EXEHDAnó M óvel
EXEHDAcél
EXEHDAnó M óvel
FIGURA 5.2 – Comunicação entre as EXEHDAbases das EXEHDAcels
5.2 Ferramentas Utilizadas
Essa seção visa descrever brevemente algumas das principais características das ferramentas utilizadas durante o projeto e implementação do EXEHDA-HM.
5.2.1 Rational Rose Enterprise Edition
A ferramenta utilizada para modelar o EXEHDA-HM durante sua fase de projeto foi o Rational Rose Enterprise Edition. Esse software, através do uso da notação UML, permite gerar uma série de diagramas que auxiliam posteriormente na obtenção de um melhor resultado na fase de implementação. Informações detalhadas sobre este software podem ser encontradas em [RAT 2002].
Nesse trabalho, seu uso foi restrito à geração de diagramas de classe e diagramas
de estados, porém, o software apresenta um vasto conjunto de recursos disponíveis, cobrindo toda a especificação Unified Modeling Language. Em [LAR 2000], são tratados diversos aspectos da UML, inclusive, com exemplos dos vários digramas por ela providos.
Abaixo, são citadas algumas das características que levaram à escolha do
Rational Rose como ferramenta de modelagem:
• Permite a visualização das aplicações através do uso de uma grande variedade de diagramas.
• Possibilita a obtenção de uma melhor qualidade do software final, visto que oferece recursos para projetar e modelar o sistema, antes de iniciar sua construção;
• Permite que desenvolvedores participantes de um projeto comuniquem-se através do uso de uma mesma ferramenta e uma mesma linguagem (UML);
51
• Propicia a obtenção de código mais robusto através da geração de modelos visuais baseados em UML;
5.2.2 JBuilder 4 Personal
JBuilder foi o ambiente de desenvolvimento Java utilizado na implementação do EXEHDA-HM. Essa ferramenta fornecida pela Borland ([BOR 2002]) oferece ao desenvolvedor diversas facilidades. Entre elas destacam-se:
• Editor integrado com sintaxe diferenciada; • Debugger; • Compilador; • Wizards; • Tutoriais; • Gerenciador de projetos; • Suporte a controle de versões através do uso do CVS; • CodeInsight, permitindo que o código seja autocompletado durante a digitação;
Por ser desenvolvida em Java, essa ferramenta exige um hardware com maior
poder de processamento que o necessário para outras ferramentas de desenvolvimento Java, como é o caso do JCreator, que é desenvolvido em C/C++. Para o uso adequado do JBuilder, é recomendada uma máquina com pelo menos 128 MB de memória RAM.
5.3 Arquivos de Configuração do EXEHDA-HM
A configuração dos diversos servidores EXEHDA-HM é realizada através da leitura de parâmetros de execução de um arquivo XML. Esse arquivo contém as informações necessárias para a configuração da EXEHDAbase na qual o EXEHDA-HM será executado.
Entre as informações disponibilizadas pelo arquivo de configuração, podem ser identificadas três seções principais:
• Dados referentes ao EXEHDA-HM que executará na célula local; • Dados referentes aos nodos EXEHDA-HM que executarão em células remotas; • Informações referentes aos servidores considerados vizinhos do EXEHDA-HM
local;
O último conjunto de dados, referente ao conjunto de servidores vizinhos do servidor local, é utilizado pela estratégia de propagação de token por vizinhança, discutida na seção 4.4.3.
A figura 5.3 apresenta um exemplo de arquivo de configuração de uma EXEHDAbase.
52
FIGURA 5.3 – Exemplo de Arquivo de Configuração EXEHDAbase-conf.xml
Entre os principais motivos que levaram a escolha da eXtensible Markup Language (XML) como forma de passagem de parâmetros para a EXEHDAbase, destacam-se:
• A XML é uma meta linguagem, provendo um formato para a descrição de dados estruturados.
• Um documento XML pode ser visto tanto como uma simples seqüência linear de caracteres, ou como uma estrutura de dados abstrata representando uma árvore de nodos;
• A XML é uma linguagem extensível, no sentido que possibilita a definição de novas tags, de acordo com a necessidade;
Resumindo: o uso da XML na definição do arquivo de configuração das
EXEHDAbases permite descrever os dados hoje disponíveis de forma estruturada, além de possibilitar a inclusão de novas informações através da definição de novas tags que se façam necessárias com o passar do tempo.
5.4 Principais Classes do Modelo
Essa seção tem por objetivo apresentar uma visão das principais classes que compõe o EXEHDA-HM, através de um diagrama de classes simplificado utilizando a notação UML (veja figura 5.4). Após, é feita uma breve descrição das funções desempenhadas pelas classes apresentadas. Componentes periféricos que compõem modelo foram poupados do diagrama, a fim de que o mesmo possa ser melhor visualizado.
53
5.4.1 Diagrama de Classes Simplificado
FIGURA 5.4 – Diagrama de Classes Simplificado do EXEHDA-HM
1..*
1
EXEHDA_HMServerInterface
createBeing()extinguishBeing()moveBeing()printLocalSpace()getCurrentPosition()updateCurrentPosition()propagateToken()remoteCreateBeing()remoteAddChildToParent()remoteRemoveBeing()remoteRemoveChildFromParent()remoteMoveBeingFromOldParent()remoteMoveBeingToNewParent()
<<Interface>> TestClient
myServer : EXEHDA_HMServerInterface
execute()
BeingNotFoundException
BeingNotFoundException()
BeingDescriptor
holoTreePosition : Stringparent : Stringchildren : VectorhostName : String
EXEHDA_HMSpace
beingTable : Hashtable
putEntry()getEntry()removeEntry()contains()toString()formatField()insertWhiteSpaces()
0..*
1
UpdateToken
beingName : StringbasePosition : Stringoperation : String
Configurator
config : Document
getValue()getList()
EXEHDA_HMServer
localSpace : EXEHDA_HMSpacebasePositionTable : HashtablecurrentPositionTable : HashtablelocalServerName : StringneighborServerName : StringremoteServerNames : Vector
configureServer()registerLocalServer()lookupRemoteServers()shutdownServer()createBeing()addChildToParent()extinguishBeing()removeBeing()removeChildren()removeChildFromParent()moveBeing()moveBeingFromOldParent()moveBeingToNewParent()printLocalSpace()getCurrentPosition()updateCurrentPosition()propagateToken()queryBeingPosition()remoteCreateBeing()remoteAddChildToParent()remoteRemoveBeing()remoteRemoveChildFromParent()remoteMoveBeingFromOldParent()remoteMoveBeingToNewParent()main()
11
1
1
1
1..*
1
1
1
1
1
54
5.4.2 Descrição das Classes
- EXEHDA_HMServerInterface: Essa interface define os métodos públicos do servidor que serão acessíveis a seus clientes (no caso, o ambiente de execução Holo ou algum outro servidor remoto). Dessa forma, essa interface define quais métodos serão disponibilizados pelo servidor, mas não as suas implementações.
- EXEHDA_HMServer: Classe que implementa a interface EXEHDA_HMServerInterface, provendo os métodos responsáveis pela gerência da HoloTree distribuída. É a principal classe do modelo, sendo responsável por implementar todas as primitivas relacionadas à manipulação de entes (createBeing, extinguishBeing e moveBeing), além de diversos métodos auxiliares a esses comandos. Além disso, contém uma série de métodos responsáveis por implementar etapas do ciclo de vida de um servidor EXEHDA-HM, como inicialização, configuração e encerramento. Para realizar a manutenção da HoloTree distribuída, são mantidas informações em diversas estruturas de gerenciamento: essas estruturas podem conter dados relacionados aos entes de uma aplicação Holo (como o EXEHDA_HMSpace, a Base Position Table e a Current Position Table, descritas na seção 4.4), como também dados referentes aos servidores remotos (Remote Server Names e Neighbor Server Names, utilizados nos algoritmos de busca e propagação de informações).
- EXEHDA_HMSpace: Classe que implementa um espaço de recursos (resource space). Encapsula uma tabela hash, provendo métodos de acesso que permitem a recuperação e associação de informações relevantes de um ente ao seu nome. Os pares <key, value> dessa tabela correspondem a pares <String, BeingDescriptor>. A chave de uma entrada é o nome do ente; o valor associado a essa chave é um objeto da classe BeingDescriptor (descrito logo abaixo).
- BeingDescriptor: Classe que encapsula as informações pertinentes a um determinado ente, como: nome, host, posição na HoloTree, nome do pai, vetor contendo os nomes dos filhos, etc... Dessa forma, permite concentrar em um único objeto todas as informações utilizadas no gerenciamento de um ente pertencente à aplicação distribuída.
- UpdateToken: Classe que encapsula as informações utilizadas na atualização, realizada por cada servidor EXEHDA-HM, da tabela de posição base dos entes. A cada vez que um ente é criado ou extinto, o servidor responsável por essa operação monta um objeto UpdateToken e inicia sua propagação para que os outros servidores atualizem as suas tabelas de posição base de entes. O objeto UpdateToken sempre é transferido para o servidor EXEHDA-HM vizinho do servidor em questão. Maiores detalhes sobre a estratégia de propagação de informações são apresentados na seção 4.4.3.
- BeingNotFoundException: Classe que representa a exceção que deve ser atirada quando um ente deveria ter sido encontrado em um determinado servidor, mas não o foi, seja pelo fato dele ter sido movido, ou pelo fato dele ter sido extinto, antes que a informação tivesse sido completamente propagada. Dessa forma, o controle do fluxo de execução é passado para fora do EXEHDA-HM, sendo o ambiente de execução o responsável por tentar repetir a ação anterior, ignorar o fato do ente não ter sido encontrado, ou simplesmente abortar o processamento.
55
- Configurator: Classe utilizada na configuração inicial do servidor EXEHDA-HM, extraindo os parâmetros de configuração do arquivo XML EXEHDAbase-conf.xml. Permite obter um único dado do arquivo, através do método getValue (utilizado, por exemplo, para recuperar o nome do servidor local), ou uma lista de valores, através do método getList (utilizado para recuperar a lista de servidores remotos, e a lista de servidores vizinhos do EXEHDA-HM em questão).
- TestClient: Classe utilizada para simular o ambiente de execução EXEHDA, realizando diversas chamadas às primitivas de manipulação de entes do EXEHDA-HM. Após obter uma referência do objeto EXEHDA_HMServer, são realizadas uma série de chamadas a seus métodos, de forma que entes sejam criados, movidos e extintos.
5.5 O EXEHDA-HM Visual
Para possibilitar a depuração visual dos resultados obtidos com o EXEHDA-HM, fez-se necessário o desenvolvimento e uma ferramenta visual que permitisse a seu usuário consultar a localização de entes gerenciados pelo EXEHDA-HM. O EXEHDA-HM Visual visa suprir essa necessidade. Futuramente, objetiva-se que o visualizador de entes seja integrado à ferramenta de depuração Holodebugger [CEC 2002].
A figura 5.5 mostra o resultado de uma consulta global realizada através do EXEHDA-HM Visual, onde todos os entes pertencentes a aplicação distribuída foram localizados. À esquerda, é apresentada a lista de entes encontrados; quando um deles é selecionado, as informações contidas em seu descritor são apresentadas na tela, permitindo ao usuário identificar seu ente pai, seus entes filhos, e o host onde o mesmo encontra-se localizado.
FIGURA 5.5 – Consulta Global de Entes Realizada Através do EXEHDA-HM Visual
56
5.5.1 A Modelagem do EXEHDA-HM Visual
A fase inicial do desenvolvimento da ferramenta EXEHDA-HM Visual consistiu de um levantamento dos requisitos e das funcionalidades que ela deveria oferecer. Essas funcionalidades referem-se essencialmente às modalidades de consulta de entes, além de outros serviços de menor importância, os quais são citados logo abaixo:
• Consulta de entes através do seu nome; • Consulta de entes através do host onde estão localizados; • Consulta de entes através da célula onde estão sendo gerenciados; • Consulta de todos os entes que compõem a aplicação, independente de nome,
host ou célula; • Disponibilização de estatísticas que apresentem o número de entes criados,
extintos e movidos dentro de cada uma das células que compõem o ambiente de execução;
As etapas seguintes contemplaram o projeto de classes e a implementação
propriamente dita da ferramenta. Apenas a título de ilustração, a figura 5.6 apresenta o digrama de classes do EXEHDA-HM Visual, de forma que as principais classes que compõem a ferramenta possam ser visualizadas.
FIGURA 5.6 – Diagrama de Classes do EXEHDA-HM Visual
ThreeDVBChart
drawChart()calculateMargin()printLegend()
GenericChart
chartTitle : StringdisplayLegend : booleandisplayXAxys : booleandisplayYAxys : boolean
initChart()drawChart()paintComponent()drawChartTitle()setChartTitle()calculateMargin()setDisplayLegend()setDisplayXAxys()setDisplayYAxis()
ChartPanel
createNewChart()
BeingDescriptorThinView
beingName : StringparentName : StringhostName : Stringchildren
EXEHDA_HMViewer
allServers : HashMapallServerNames : Vector
main()makeMenu()getAllEntries()doConnect()doExit()doAbout()doCreatedBeings()doExtinguishedBeings()doMovedInBeings()doMovedOutBeings()doQueryByBeingName()doQuerybyHost()doQueryByCell()doQueryAll()
JTable
0..*
1
0..*
1
DetailPanel
beingNameFieldlabel : StringparentNameFieldLabel : StringchildNameFieldLabel : StringhostNameFieldLabel : StringbeingNameLabel : StringparentNameLabel : StringchildNameLabel : String[]hostNameLabel : StringprefixFieldName : StringsufixFieldName : String
setFields()
MainPanel
makeHeader()makeMasterPanel()makeDetailPanel()refreshDetailPanel()
57
5.6 Estudo de Caso
Nesta seção será caracterizado o funcionamento do EXEHDA-HM através da manipulação das primitivas de serviço por ele implementadas. Para realizar esses testes, foi criado um programa com a finalidade específica de disparar uma série de chamadas ao módulo EXEHDA-HM. Porém, após a integração com os demais trabalhos do projeto EXEHDA, a utilização das primitivas do EXEHDA-HM se dará a partir do resultado da compilação de um programa em Holoparadigma e dos mecanismos de gerência da adaptação.
Na situação apresentada, duas instâncias do EXEHDA-HM foram utilizadas para gerenciar uma árvore distribuída de entes. Para realizar esse teste, foram empregados dois hosts, cada um abrigando um servidor EXEHDA-HM. Pretende-se assim, demonstrar a execução do EXEHDA-HM, através da gerência da HoloTree sendo realizada de forma cooperativa por duas EXEHDAcels (nesse teste, assume-se que cada EXEHDAcel é formada por apenas um host, o qual é o próprio nodo EXEHDAbase).
O programa-exemplo utilizado nesse estudo de caso realiza seis chamadas ao EXEHDA-HM, criando, movendo e extinguindo entes. As instruções por ele executadas são apresentadas abaixo:
As primitivas implementadas pelo EXEHDA-HM, e os respectivos parâmetros
recebidos por cada uma delas, foram descritos na seção 4.3.
As ações executadas em cada etapa, e seus resultados, são apresentados acompanhados por screenshots do EXEHDA-HM Visual (permitindo a visualização dos entes gerenciados por cada EXEHDAcel). Em cada etapa da execução são mostrados dois screenshots do EXEHDA-HM Visual, cada um com o resultado de uma consulta de entes por célula (cada célula é formada por apenas um host, que no caso são guaiaca.inf,.ufrgs.br e poncho.inf.ufrgs.br) após a execução daquele passo. Além disso, em cada passo é apresentada uma ilustração da estrutura de composição e localização dos entes que formam a HoloTree naquele momento.
Passo 1: createBeing(null,"Holo","guaiaca.inf.ufrgs.br"); Passo 2: createBeing("Holo","Azul","guaiaca.inf.ufrgs.br"); Passo 3: createBeing("Holo","Verde","poncho.inf.ufrgs.br", "poncho.inf.ufrgs.br"); Passo 4: createBeing("Azul","Rosa","guaiaca.inf.ufrgs.br"); Passo 5: moveBeing("Verde","Rosa",true); Passo 6: extinguishBeing("Verde");
58
FIGURA 5.7 – Primeira Etapa da Execução
FIGURA 5.8 – Segunda Etapa da Execução
59
FIGURA 5.9 – Terceira Etapa da Execução
FIGURA 5.10 – Quarta Etapa da Execução
60
FIGURA 5.11 – Quinta Etapa da Execução
FIGURA 5.12 – Sexta Etapa da Execução
61
Esse estudo de caso procurou demonstrar uma situação real de uso do EXEHDA-HM sendo este executado de forma distribuída, gerenciando uma HoloTree com seus entes espalhados entre duas EXEHDAcels (assumiu-se que a EXEHDAcel local seria aquela formada pelo host guaiaca.inf.ufrgs.br). Inicialmente foi criada uma HoloTree formada por quatro entes, através de quatro chamadas à primitiva CreateBeing. A terceira chamada a essa primitiva apresentou uma peculiaridade, pois recebeu um parâmetro adicional, indicando que o ente deveria ser criado na EXEHDAcel remota, gerenciada pelo host poncho.inf.ufrgs.br. Após, com o uso do comando MoveBeing, o ente Rosa foi movido para o ente Verde, passando este a ser um ente composto, enquanto que o ente Azul tornou-se um ente elementar (a estrutura de composição de entes foi descrita na seção 2.2). Além disso, o ente Rosa deixou de ser gerenciado pela instância do EXEHDA-HM executando no host guaiaca.inf.ufrgs.br, e passou a ser gerenciado pela instância do EXEHDA-HM no host poncho.inf.ufrgs.br. Por fim, com a execução do comando ExtinguishBeing, o ente Verde foi removido da aplicação, e conseqüentemente o ente Rosa, que era seu único ente componente. Ao final da execução, temos apenas dois entes existentes na aplicação: o ente Holo e o ente Azul; além disso, a HoloTree resultante está completamente delimitada pela EXEHDAcel que tem como EXEHDAbase o host guaiaca.inf.ufrgs.br, uma vez que não existem ramificações da árvore de entes em células remotas (nesse caso, não existem entes sendo gerenciados pelo EXEHDA-HM executando na célula formada pelo host poncho.inf.ufrgs.br).
62
6 Conclusões
Este capítulo tem três objetivos: (1) tecer considerações sobre os principais aspectos do trabalho, (2) caracterizar seu significado no contexto do projeto EXEHDA e (3) apontar algumas possibilidades de trabalhos relacionados.
O EXEHDA-HM tem como objetivo principal fornecer um serviço de gerência do contexto de execução para aplicações distribuídas desenvolvidas na Hololinguagem. Essas aplicações são processadas no ambiente de execução EXEHDA, sendo o EXEHDA-HM o módulo responsável pela manutenção do contexto de execução, materializando a abstração de uma árvore de entes (HoloTree).
Como os entes que formam a HoloTree poderão estar localizados em diferentes nodos da arquitetura distribuída, foi necessário o estudo de técnicas de distribuição e gerência de nomes em sistemas distribuídos. Para isso, os principais aspectos relacionados a serviços de nomes foram revisados e discutidos no capítulo 3. O EXEHDA-HM, por sua vez, é responsável pela implementação de alguns desses aspectos, permitindo assim que instâncias do EXEHDA-HM possam localizar entes residentes em EXEHDAcels remotas, atuando de forma cooperativa na tarefa de gerenciar uma execução distribuída do Holoparadigma.
Este trabalho modelou e implementou as primitivas responsáveis pela criação, destruição e mobilidade de entes. A sintaxe destas primitivas está apresentada na Hololinguagem, e os entes a serem manipulados podem estar distribuídos em diferentes instâncias do EXEHDA-HM. Considerando-se esse fato, foi definida uma estratégia de localização de recursos nos espaços de entes dos servidores EXEHDA-HM. Essa estratégia tem como premissas uma localização eficiente dos entes no ambiente distribuído, enquanto que procura evitar uma replicação (e conseqüente propagação) total de informações entre as instâncias do EXEHDA-HM. Dessa forma, chegou-se a um modelo onde somente algumas informações de gerenciamento necessitam serem replicadas entre os nodos. Isso garante que a alta dinamicidade das aplicações escritas na Hololinguagem não comprometerá o desempenho do sistema, uma vez que menos informações precisarão ser propagadas à medida que os dados que caracterizam o estado da execução se alterem.
O EXEHDA-HM, assim como o EXEHDA quase na sua totalidade, está sendo desenvolvido na linguagem Java. Dentre outras características, essa linguagem fornece uma rica API para programação distribuída. Um dos recursos oferecidos pela linguagem, e que foi utilizado na implementação do EXEHDA-HM chama-se Remote Method Invocation (RMI). Com o RMI, é possível realizar chamadas de métodos em objetos remotos. É justamente dessa forma que é realizada a comunicação entre as diversas instâncias do EXEHDA-HM, a fim de que as EXEHDAcels compartilhem informações de gerenciamento. Cada instância do EXEHDA-HM é, portanto, um servidor RMI que se comunica com outros servidores durante a execução das primitivas que alteram a estrutura da HoloTree distribuída.
Ao longo do projeto percebeu-se a necessidade de uma ferramenta que permitisse uma melhor visualização das informações referentes aos entes da HoloTree. Inicialmente, esse acompanhamento era realizado através dos logs gerados por cada instância do EXEHDA-HM, mas logo se tornou clara a necessidade de desenvolvimento de uma ferramenta desse tipo. O EXEHDA-HM Visual destina-se a essa finalidade: permitir uma visualização das propriedades e da organização física e lógica dos entes. O
63
EXEHDA-HM Visual permite diversas formas de consulta de entes. Entre elas destacam-se: por nome do ente, por host físico, por célula de execução, ou consulta global de todos os entes da aplicação. Dessa forma, o EXEHDA-HM Visual atua como um depurador visual, permitindo o acompanhamento e monitoramento da posição dos entes distribuídos entre as diversas EXEHDAcels.
Integrando o middleware de execução distribuída EXEHDA, o módulo EXEHDA-HM contribui com a gerência do contexto de execução das aplicações escritas em Holoparadigma. Essas aplicações são inerentemente distribuídas, dinâmicas e potencialmente escaláveis. Essas características foram determinantes na concepção serviço nomes mantido pelo EXEHDA-HM, o qual tem como objetivo reduzir o número de mensagens trocadas na resolução dos nomes e na propagação das informações necessárias à execução de forma adaptativa de aplicações em Holoparadigma.
Por fim, com a definição da semântica distribuída dos comandos para a manipulação da HoloTree, o EXEHDA-HM oferece ao EXEHDA suporte efetivo à execução distribuída. Esse suporte se dá por meio de primitivas que possibilitem a total integração com os outros mecanismos do EXEHDA, garantindo que a consistência da HoloTree seja preservada mesmo que ela esteja distribuída por um conjunto de nodos, e deste modo tendo seus entes sujeitos a procedimentos de adaptação e gerenciados por diferentes instâncias do EXEHDA-HM.
Trabalhos Futuros
Como trabalhos relacionados ao EXEHDA-HM que poderão ser realizados posteriormente, destacam-se:
• Integração total com os outros módulos que compõem o EXEHDA;
• Implementação de estratégias alternativas na propagação de informações replicadas às demais instâncias do EXEHDA-HM;
• Implementação de suporte á replicação de entes, em uma mesma, ou em diferentes instâncias do EXEHDA-HM;
• Realização de testes de performance para avaliar o desempenho do EXEHDA-HM;
• Realização de melhorias na interface gráfica do EXEHDA-HM Visual, de forma a permitir uma melhor visualização das informações por ela providas;
• Integração do EXEHDA-HM Visual com a ferramenta Holodebugger;
64
7 Bibliografia
[AUG 2001] AUGUSTIN, Iara; YAMIN, Adenauer; BARBOSA, Jorge; GEYER, Cláudio. Requisitos para o Projeto de Aplicações Móveis Distribuídas. VIII CACIC CONGRESO ARGENTINO DE CIENCIAS DE LA COMPUTACIÓN. Santa Cruz, Argentina. Oct, 2001.
[AVE 2000] AVEDAL, Karl. Distributed Computing Using RMI. In: Java Server Programming J2EE Edition. Chicago: Wrox Press, 2000. v.1, chap. 2, p.35-97.
[BAR 2001] BARBOSA, Jorge L. V., SCHAEFFER, Alberto E. Using Mobility and Blackboards to Support a Multiparadigm Model Oriented to Distributed Processing. In: SYMPOSIUM ON COMPUTER ARCHITECTURE AND HIGH PERFORMANCE COMPUTING, 13., 2001, Pirenópolis, Brasil. Proceedings… Brasília: UNB, 2001. p.187-194.
[BAR 2002] BARBOSA, Jorge L. V. Holoparadigma: Um Modelo Multiparadigma Orientado ao Desenvolvimento de Software Distribuído. 2002. 215p. Tese (Doutorado em Ciência da Computação) – Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre.
[BOR 2002] Homepage do JBuilder. Disponível em http://www.borland.com/. Último acesso em setembro de 2002.
[CAL 94] CALLSEN, Christian J. Open Distributed Computing. 1994. 285p. Doctor thesis - Institute of Electronic Systems, AALBORG University, Denmark.
[CEC 2002] CECIN, Fábio R. et al. Holo Debugger: Um Depurador para uma Linguagem Multiparadigma Concorrente. 2002. In: VI SBLP - Simpósio Brasileiro de Linguagens de Programação. 14p. Rio de Janeiro, RJ. 2002.
[FER 2001] FERRARI, Débora N. Um Modelo de Replicação em Ambientes que Suportam Mobilidade. 2001. 88p. Dissertação (Mestrado em Ciência da Computação) - Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre.
[LAR 2000] LARMAN, Craig. Utilizando uml e padrões: uma introdução à análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 2000. chap. 21,33, p.252-266, 365-375.
[LEA 2001] LEA, Doug. Objects in Groups. Disponível em: <http://gee.cs.oswego.edu/dl/groups/>. Acesso em: novembro 2001.
[MOR 2000] MORGAN, Michael. Java 2 para programadores profissionais. Rio de Janeiro: Ciência Moderna, 2000.
[RAT 2002] Homepage do Rational Rose. Disponível em http://www.rational.com/. Último acesso em setembro de 2002.
65
[SUN 2002] SUN MicroSystems. Documentação da linguagem Java. Disponível em http://java.sun.com/products/jdk/1.3/. Último acesso em setembro de 2002.
[TER 84] TERRY, Doulas B. An analisys of naming conventions for distributed computer systems. In: Second annual conference on data communications on Communications architectures and protocols, 1984, Montreal. p.218-224.
[YAM 2001] YAMIN, Adenauer; AUGUSTIN, Iara; BARBOSA, Jorge. SILVA, Luciano; GEYER, Cláudio. Explorando o Escalonamento no Desempenho de Aplicações Móveis Distribuídas. In: WORKSHOP EM SISTEMAS COMPUTACIONAIS DE ALTO DESEMPENHO, II, WSCAD 2001. Anais . Pirenópolis, set., 2001.
[YAM 2002a] YAMIN, Adenauer Corrêa et al. ISAM: a Pervasive View in Distributed Mobile Computing. In: NETWORK CONTROL AND ENGINEERING FOR QOS, SECURITY AND MOBILITY WITH FOCUS ON POLICY-BASED NETWORKING, 2002, Paris, France. Proceedings… Paris: IEEE/IFIP, October 2002.
[YAM 2002b] YAMIN, Adenauer Corrêa et al. A Framework for Exploiting Adaptation in High Heterogeneous Distributed Processing. In: SYMPOSIUM ON COMPUTER ARCHITECTURE AND HIGH PERFORMANCE COMPUTING, 14., 2002, Vitória, Brasil. Proceedings… Vitória: UFES, October 2002.
[YAM 2002c] YAMIN, Adenauer Corrêa et al. Collaborative Multilevel Adaptation in Distributed Mobile Applications. In: International Conference of the Chilean Computer Science Society (SCCC 2002), 12., 2002, Atacama, Chile. Proceedings… Atacama: IEEE. Atacama,. November 2002.
[ZNA 92] ZNATI, Taieb B. A simulation based analysis of naming schemes for distributed systems. In: Proceedings of the 25th annual symposium on Simulation, 1992, Orlando. p.42-51.