IMPLEMENTAÇÃO DE UMA METODOLOGIA
PARA A CONSTRUÇÃO DE
SISTEMAS DISTRIBUÍDOS CONFIGURÁVEIS
SOBRE PVM
DISSERTAÇÃO DE MESTRADO
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
IMPLEMENTAÇÃO DE UMA METODOLOGIA
PARA A CONSTRUÇÃO DE
SISTEMAS DISTRIBUÍDOS CONFIGURÁVEIS
SOBRE PVM
DISSERTAÇÃO APRESENTADA AO DEPARTAMENTO DE ENGENHARIA ELÉTRICA DA PUC/RJ COMO PARTE DOS REQUISITOS PARA A OBTENÇÃO DO TÍTULO DE MESTRE EM CIÊNCIAS EM ENGENHARIA ELÉTRICA
ORIENTADOR: ORLANDO GOMES LOQUES FILHO CO-ORIENTADOR: JULIUS CESAR BARRETO LEITE
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO
• A meus professores orientadores, Dr. Orlando Loques e Dr. Julius Leite, pelo apoio constante e paciência durante a realização deste trabalho.
• Aos professores e pessoal administrativo do Departamento de Engenharia Elétrica, pelo apoio necessário para a terminação do meu curso de Mestrado.
• À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), pela ajuda financeira recebida durante toda a minha estadia no Brasil.
A presente dissertação descreve as características mais relevantes encontradas na metodologia de construção de software implementada pelo ambiente P-RIO. Este ambiente foi construído sobre a plataforma PVM, visando reunir em um só sistema as abstrações de alto nível para a modularização, paralelização e configuração gráfica de aplicações, e a portabilidade oferecida pela máquina virtual.
A metodologia proposta facilita a reutilização do software e a manutenção de sistemas, permitindo maior eficiência no processo de desenvolvimento de aplicações distribuídas e paralelas. Além disso, o suporte à operação oferecido por P-RIO permite que usuários, sem um grande treinamento prévio, possam criar sistemas computacionais relativamente complexos.
A implementação do ambiente inclui uma interface gráfica e uma linguagem de configuração, integradas ao sistema, que provêem facilidades para a construção, depuração e gerenciamento de aplicações. São apresentados, também, alguns exemplos de aplicações que utilizam a metodologia P-RIO.
Abstract
This dissertation describes the most relevant characteristics of the software construction methodology implemented by the P-RIO environment. This environment was built on the PVM platform, attempting to combine in a single system the high-level facilities for modularity, parallelization and graphic configuration of applications, and the portability offered by the virtual machine.
The proposed methodology simplifies software reuse and system maintenance, improving efficiency in the development process of distributed and parallel applications. Besides, the operation support offered by P-RIO allows users, with little training, to build relatively complex computational systems.
Dissertação de Mestrado apresentada por Enrique Vinicio Carrera Erazo ao Departamento de Engenharia Elétrica da PUC/RJ e aprovada pela Comissão Julgadora, formada pelos seguintes professores:
Prof. Orlando Loques (Orientador) CAA-UFF
Prof. Julius Leite (Co-orientador) CAA-UFF
Prof. Miguel Menasche DEE-PUC/RJ
Prof. Ricardo Bianchini COPPE-UFRJ Visto e permitida a impressão
Rio de Janeiro, 15/03/1996
Prof. Maria Augusta Davidovich
TEMA Pág.
Resumo... iii
Sumário... iv
Lista de Figuras... viii
Lista de Tabelas... ix
CAP 1. Introdução... 1
1.1. Motivação... 1
1.2. Objetivos... 2
1.3. Organização... 3
CAP 2. Sistemas Distribuídos... 5
2.1. Conceitos Básicos... 5 2.1.1. Organização do Hardware... 6 2.1.2. Paradigmas de Software... 8 2.2. Características... 9 2.2.1. Vantagens... 9 2.2.2. Desvantagens... 10 2.2.3. Requisitos... 10 2.3. Questões de Projeto... 12 2.3.1. O Componente Mínimo... 13 2.3.2. Modelo do Sistema... 14 2.3.3. Alocação de Processadores... 15 2.3.4. Suporte Tradicional... 16
2.3.5. Suporte à Operação e Gerência... 17
2.4. O Sistema de Comunicação... 17
2.4.1. Protocolos de Comunicação... 18
2.4.2. Modelo Cliente-Servidor... 18
2.4.3. Comunicação de Grupo... 20
2.5. Depuração... 21
2.5.1. Técnicas Básicas... 22
2.5.2. Depuração Baseada em Eventos... 23
2.6. Estudo de Casos... 23
2.6.1. ISIS... 23
2.6.2. Linda... 24
2.6.3. Parallel Virtual Machine... 25
2.6.4. Message Passing Interface... 26
2.6.5. Distributed Computing Environment... 26
2.7. Resumo... 27
CAP 3. Sistemas Distribuídos Configuráveis... 28
3.1. Objetos Distribuídos... 28
3.1.1. Orientação a Objetos... 28
3.1.2. Alternativas... 31
3.1.3. Software de Componentes... 33
3.2. Programação Visual... 34
3.2.1. Ambientes de Programação Visual... 35
3.2.2. Interface Gráfica de Usuário... 36
3.3. Sistemas Configuráveis... 37 3.3.1. Modularidade... 37 3.3.2. Configuração... 38 3.3.3. Reconfiguração... 40 3.3.4. Linguagem de Configuração... 41 3.4. Estudo de Casos... 42 3.4.1. COOL... 42 3.4.2. REX... 43 3.4.3. Regis... 43 3.4.4. RIO... 44 3.5. Resumo... 44
CAP 4. O Ambiente P-RIO... 45
4.1.1. Módulos e Conectores... 46 4.1.2. Grupos... 48 4.1.3. Módulos Compostos... 49 4.1.4. Características do Ambiente... 50 4.2. Configuração... 51 4.2.1. A Linguagem de Configuração... 52 4.2.2. Nomeação... 52 4.3. Comunicação... 53
4.4. Programação dos Módulos... 54
4.4.1. Tolerância a Falhas... 55 4.4.2. Transparência da Programação... 56 4.5. Suporte à Gerência... 57 4.6. Resumo... 58 CAP 5. Implementação... 59 5.1. Descrição da Arquitetura... 59 5.1.1. A Biblioteca de Funções... 60 5.1.2. O Configurador... 61 5.1.3. O Console... 61 5.1.4. As Aplicações... 62 5.2. O Sistema de Comunicação... 62 5.3. A Interface de Programação... 64 5.3.1. Primitivas de Programação... 64 5.3.2. Primitivas de Comunicação... 67 5.3.3. Primitivas de Configuração... 69 5.4. A Linguagem de Configuração... 73 5.5. Resumo... 76
CAP 6. Utilização do Ambiente... 77
6.1. Exemplos... 77
6.1.1. Cálculo de π... 77
6.1.2. Reconhecimento de Imagens Utilizando Redes Neurais... 80
LISTA DE FIGURAS
FIGURA Pág.
1. Classificação do Hardware... 6
2. Multicomputador Virtual... 7
3. Processos vs. Threads... 13
4. Chamada a Procedimentos Remotos... 19
5. Estrutura de um Objeto... 29
6. Delegação Direta e Composição Hierárquica... 32
7. Componentes de um Sistema Configurável... 39
8. Módulo Básico... 47
9. Grupo de Comunicação... 48
10. Composição de Módulos... 49
11. Módulos Compostos... 50
12. O Sistema de Comunicação... 54
13. Memória Compartilhada Distribuída... 56
14. Memória Virtual... 57
15. Estrutura do Ambiente P-RIO... 59
16. Implementação do Sistema de Comunicação... 63
17. Configuração para o Cálculo de π... 78
18. Reconhecimento de Imagens... 81
19. Etapa de Pré-processamento... 81
20. Configuração da Aplicação no Ambiente P-RIO... 82
21. Detalhe da Interface Gráfica P-RIO... 86
22. Módulo Composto para a Paralelização da Rede Neural... 87
23. Saídas do Tipo printf-like das Instâncias P-RIO... 88
24. Capacidade de Depuração da Interface Gráfica... 89
25. Tempos de Comunicação Round-Trip... 90
LISTA DE TABELAS
TABELA Pág.
1. Tipos de Pinos de Comunicação... 65
2. Tipos de Dados Transmitidos pelos Pinos de Comunicação... 65
3. Condições de Instanciação de um Módulo... 70
4. Tempos de Execução para o Cálculo de π... 91
Introdução
A presente dissertação está centrada na implementação do ambiente P-RIO (Parallel
Reconfigurable Interconnectable Objects) sobre a plataforma de software PVM (Parallel Virtual Machine)[26]. O ambiente P-RIO é um suporte para a construção, depuração e execução
de aplicações distribuídas e paralelas, baseado em uma metodologia de construção de software modular que separa a programação dos componentes de uma aplicação, da configuração da aplicação.
A metodologia adotada é a mesma encontrada no ambiente RIO (Reconfigurable
Interconnectable Objects)[61], e em outras propostas similares [34], [8]. No entanto, os
fundamentos de implementação e a extensibilidade do sistema são completamente distintos, com ênfase, principalmente, na portabilidade e facilidade de uso do sistema.
São apresentados, a seguir, os fatos que motivaram a realização deste trabalho e os objetivos propostos para o mesmo, seguidos de uma visão geral dos tópicos abordados nesta dissertação.
1.1. Motivação
As aplicações computacionais tem alcançado um grau de sofisticação que requerem um elevado processamento e compartilhamento de recursos, contrapondo-se às limitações tecnológicas que impedem o aumento ilimitado no desempenho de sistemas uniprocessador. No entanto, o aparecimento de microprocessadores e estações de trabalho, com poder de computação semelhante a muitos computadores de grande porte, tem permitido que os usuários acessem máquinas de maior desempenho a menor custo. Da mesma forma, os grandes avanços na área de redes de computadores e transmissão de dados, têm mudado as medidas de utilidade e velocidade destes dispositivos.
Como conseqüência direta deste desenvolvimento, o processamento distribuído e paralelo já é uma realidade. No entanto, um problema ainda por resolver nestes sistemas é a falta de
software. A procura por boas linguagens, ferramentas e ambientes que facilitem o
atraindo a comunidade científica. Especial atenção merece, neste sentido, o aproveitamento dos sistemas de computação comuns a nosso meio (i.e. estações de trabalho ligadas em rede), para criar sistemas de computação concorrente robustos, confiáveis e flexíveis.
Por outro lado, o projeto de sistemas de software grandes e complexos, como é o caso dos sistemas distribuídos, requer mecanismos de decomposição de forma a torná-lo tratável. Ao dividir um sistema em partes menores é possível compreender mais facilmente o relacionamento entre suas diversas funcionalidades e o comportamento global. Esta é uma característica fundamental, considerando que quando as pessoas projetam sistemas elas tipicamente provêem uma descrição arquitetural consistindo de um conjunto de componentes e um conjunto de relações que indicam as interações entre aqueles componentes[3]. Desta forma, são também motivo de pesquisa ambientes que permitem a construção de aplicações isolando a programação da configuração dos seus componentes.
Uma outra característica importante nos sistemas atuais, é a potencial portabilidade do
software entre as várias arquiteturas de hardware existentes. Para o caso dos sistemas
distribuídos, isto oferece, além da inerente flexibilidade de uso, um suporte adicional para o aproveitamento de um conjunto de computadores heterogêneos ligados em rede. Merece também destaque especial, a necessidade de uma interface de usuário que facilite a utilização dos recursos presentes no sistema. A interação com essa interface deve ser simples e eficiente, não precisando de conhecimentos especializados para usar as técnicas de computação nela embutidas. Uma boa alternativa para isto, é a utilização de ambientes de programação visual que permitam a interação gráfica entre o usuário e o sistema.
1.2. Objetivos
O estudo levado a cabo nesta dissertação tem por objetivo dar continuidade às pesquisas feitas na área de sistemas distribuídos configuráveis. Especificamente, o trabalho está centrado na implementação de uma metodologia que permita a construção, depuração, operação e manutenção de sistemas distribuídos e paralelos, baseando-se, para isto, no paradigma da orientação a objetos. Uma característica também proposta para o sistema a ser implementado, é ampla portabilidade entre plataformas de hardware e sistemas operacionais.
fornecidas pelos sistemas existentes. Esta interface, baseada na visualização do ambiente, deve ser simples e fácil de entender, de forma a permitir que pessoas sem um grande treinamento prévio possam desenvolver rápida e eficientemente sistemas computacionais relativamente complexos.
1.3. Organização
Ao longo da presente dissertação, vão ser introduzidos os fundamentos e características de um ambiente integrado para o desenvolvimento e gerência de sistemas distribuídos e paralelos. Este ambiente que está baseado em uma metodologia que separa a construção dos componentes de uma aplicação, da construção da própria aplicação, será implementado sobre a plataforma de software PVM, garantindo a sua portabilidade a vários sistemas operacionais e plataformas de hardware. Além disso, para facilitar a interação do usuário com o ambiente criado, será fornecida uma interface gráfica que mapeie os conceitos associados em representações gráficas.
Este documento está estruturado em sete capítulos, cada um dos quais tenta dar uma visão geral de um tópico relacionado com o desenvolvimento do ambiente P-RIO. Este capítulo inicial dá uma breve introdução às idéias que motivaram esta dissertação e aos objetivos que são perseguidos através da mesma.
No capítulo 2 são revisados os conceitos que caracterizam aos sistemas distribuídos. É feita uma introdução às características e conceitos básicos que regem tais sistemas, junto com uma descrição de várias questões de projeto a eles associadas. São ampliados, também, alguns pontos importantes como o sistema de comunicação e o processo de depuração em sistemas distribuídos. O capítulo finaliza com o estudo de vários sistemas existentes.
No capítulo 3 são analisados os conceitos em que se baseiam os sistemas distribuídos configuráveis. A discussão inicia com dois temas de forte influência nos sistemas configuráveis: a programação orientada a objetos e a programação visual. São mostrados, além de vários conceitos relacionados com a configuração e reconfiguração de aplicações, alguns sistemas existentes baseados nas idéias abordadas no capítulo.
fundamentos para a programação dos componentes de uma aplicação. Ao final, é discutido o suporte à gerência oferecido pelo ambiente.
O capítulo 5 descreve a implementação do ambiente P-RIO. O capítulo inicia com uma breve descrição da arquitetura do ambiente P-RIO, seguida por um estudo do sistema de comunicação utilizado. Posteriormente, são detalhadas as primitivas de programação existentes na biblioteca P-RIO, assim como a linguagem de configuração utilizada para a construção de aplicações.
No capítulo 6 são apresentados vários exemplos que demostram a utilização do sistema. São discutidos tanto a interface gráfica existente no sistema quanto os resultados de desempenho para várias funções do ambiente P-RIO. O capitulo finaliza com uma análise comparativa entre a metodologia proposta e a implementação realizada.
Sistemas Distribuídos
Neste capítulo apresenta-se uma revisão geral dos conceitos que caracterizam os sistemas distribuídos, analisando-se os principais aspectos e alternativas para o desenvolvimento de um ambiente integrado que facilite a programação paralela e distribuída. Esta revisão inicia com uma introdução às características e conceitos básicos que regem os sistemas distribuídos, continuando com a descrição de várias questões de projeto aplicáveis a estes sistemas. A seguir, são ampliados alguns pontos importantes como o sistema de comunicação e o processo de depuração em ambientes distribuídos. Finalmente, são dados alguns exemplos de sistemas utilizados para a programação paralela e distribuída.
2.1. Conceitos Básicos
Um sistema distribuído pode ser definido como um conjunto de máquinas interconectadas, onde cada uma das quais têm ao menos uma CPU (Central Processing Unit) e memória local. Cada máquina administra independentemente os seus recursos e a computação, devendo todos os processos submetidos ao sistema cooperar como se fossem uma única aplicação sob um controle descentralizado.
Os sistemas distribuídos são utilizados principalmente quando é preciso abarcar grandes áreas geográficas, quando se quer melhorar o desempenho através do processamento paralelo, quando se quer reduzir custos, quando é requerida a distribuição de determinados componentes com propósitos de sincronização, ou quando certas características de tolerância a falhas são desejadas. Cabe mencionar, adicionalmente, que a diferença principal entre os sistemas distribuídos e os de processamento paralelo, é que os últimos estão orientados à solução de um único problema por vez.
Na definição inicial estão envolvidos diversos conceitos referentes ao hardware e software dos sistemas de computação. A seguir, são apresentadas algumas definições úteis para os sistemas distribuídos e paralelos nesta área.
Os computadores tradicionais, classificados como SISD (Single Instruction Stream, Single
Data Stream) de acordo com a taxonomia de Flynn[30], se caracterizam por ter um processador
que executa uma única instrução sobre um único dado. Este esquema, adotado por mainframes e computadores pessoais, tem limitações de desempenho que podem ser atenuadas mediante técnicas de processamento paralelo.
O processamento paralelo, como tal, está expresso em duas formas: SIMD (Single
Instruction Stream, Multiple Data Stream) e MIMD (Multiple Instruction Stream, Multiple Data Stream)[36]. Os computadores SIMD, tais como os computadores vetoriais e outros
supercomputadores, tem alcançado um desempenho extremadamente alto em uma classe restrita de problemas científicos. Os computadores MIMD, por outro lado, baseados em
transputers e processadores comerciais interligados, têm sido capazes de alcançar altas taxas
de processamento na solução de problemas de propósito geral. Estes últimos são também chamados, em alguns casos, de sistemas escaláveis, graças a sua possibilidade de crescimento computacional.
Os sistemas tipo MIMD, por sua vez, podem ser divididos em multiprocessadores e multicomputadores. Os multiprocessadores, denominados também sistemas fortemente acoplados, são caracterizados por possuírem uma memória compartilhada que é utilizada para a comunicação entre processos. Os multicomputadores, por outro lado, tem memória local para cada uma das CPUs, as quais se comunicam mediante troca de mensagens. Estes últimos são também chamados de sistemas fracamente acoplados.
Computadores
MIMD
SISD SIMD
Multicomputadores Multiprocessadores
Figura 1. Classificação do Hardware.
maioria dos casos, mediante troca de mensagens[58].
Um ponto importante nos multicomputadores, e também nos multiprocessadores, é a forma de ligação usada pela arquitetura para interconectar as várias CPUs. As formas de ligação, empregadas na maioria de sistemas, se agrupam naquelas que usam um barramento comum ou nas que utilizam uma rede de interconexão. A ligação baseada em um barramento comum é de fácil construção e comumente encontrada nos multiprocessadores. Nela, todas as CPUs trocam informação através do barramento, convertendo-o em um gargalo de difícil expansão. Para eliminar este gargalo, têm sido propostas redes de interconexão que ligam os processadores mediante topologias em grade, hierárquicas ou hipercúbicas, facilitando a troca de informação entre as CPUs.
WAN LAN 4
LAN 3 LAN 2
LAN 1
Figura 2. Multicomputador Virtual
uma forma homogênea para o programador.
2.1.2. Paradigmas de Software
O software é o ente que isola o usuário comum dos detalhes de baixo nível associados com o
hardware. Ele tenta oferecer todas as vantagens implícitas na arquitetura, simplificando o
trabalho do programador. Apesar de ser vago e amorfo, o software determina a imagem que o usuário tem do sistema, não necessitando essa imagem concordar com a realidade encontrada no hardware.
Existem várias formas para abordar o software empregado pelos sistemas paralelos e distribuídos, sendo difícil estabelecer um critério uniforme que determine a tendência dentro da área. Assim, a maneira de exemplo, os sistemas com múltiplas CPUs podem ser divididos, de acordo com a imagem apresentada pelo software, em fracamente acoplados e fortemente acoplados. O software fracamente acoplado é aquele onde o usuário percebe a existência dos vários elementos de processamento, necessitando especificar explicitamente as ações de interação entre eles, assim como os entes envolvidos. Por outro lado, o software fortemente acoplado torna transparente a existência das várias CPUs, mostrando ao usuário a visão de uma máquina virtual.
Associando as classificações de hardware e software apresentadas, pode se estabelecer certas combinações que se aproximam daquelas encontradas comercialmente, indo desde simples sistemas operacionais de rede (compartilhamento de arquivos e dispositivos), até multiprocessadores de tempo compartilhado (processamento altamente paralelo). Uma destas combinações são os sistemas distribuídos, onde se tem um software fortemente acoplado rodando sobre um hardware fracamente acoplado. Neles, o usuário tem a imagem de uma única máquina virtual, apesar da heterogeneidade que possa existir entre os elementos processadores, como é o caso dos supercomputadores virtuais e metacomputadores, mencionados anteriormente.
para o desenvolvimento dessa classe de sistemas.
2.2. Características
Para que um sistema distribuído possibilite tratar as aplicações distribuídas como se fossem aplicações centralizadas, além de oferecer confiabilidade e um desempenho mínimo, o sistema deve contar com um mecanismo de comunicação entre processos global e único, idêntica administração de processos, um esquema de proteção global, e uma mesma interface de chamadas ao sistema. No entanto, ao comparar um sistema distribuído com um sistema centralizado, surgem algumas vantagens e desvantagens, junto com vários requisitos.
2.2.1. Vantagens
As principais vantagens dos sistemas distribuídos sobre os sistemas centralizados podem ser sintetizadas nos seguintes pontos:
a) Economia: Os microprocessadores oferecem uma relação custo/desempenho melhor que muitos computadores de grande porte.
b) Velocidade: Um sistema distribuído pode apresentar um poder de computação maior que o encontrado nos sistemas centralizados.
c) Distribuição Inerente: Muitas aplicações envolvem, implicitamente, um conjunto de máquinas separadas espacialmente.
d) Confiabilidade: Se um ou mais processadores falham, o sistema como um todo pode ainda trabalhar, embora o seu desempenho possa ser afetado.
e) Incremento Gradual: O poder de computação do sistema pode ser aumentado em pequenos incrementos.
Existem também algumas outras vantagens dos sistemas distribuídos em relação à opção de ter um conjunto de processadores isolados, associados a usuários independentes. As principais são compartilhamento de dados e dispositivos, comunicação e flexibilidade de uso.
2.2.2. Desvantagens
de complexidade neles envolvido e dependendo do tipo de aplicação, pode-se obter mais benefícios em um sistema centralizado que em um distribuído. Algumas desvantagens presentes nos sistemas distribuídos, embora cada dia se tornem menores, são resumidas nos seguintes itens:
a) Software: A falta de padrões, linguagens, sistemas operacionais e ambientes que facilitem a criação, operação e manutenção de aplicações distribuídas, impede o desenvolvimento da área.
b) Redes: O ponto de falha principal em um sistema distribuído é a rede de comunicação, que pode se saturar ou apresentar problemas maiores (velocidade nominal, interferência, erros de transmissão, etc.).
c) Segurança: Se não são aplicados mecanismos de proteção adequados, o fácil acesso aos dados se converte em um sério problema ao trabalhar com dados confidenciais.
2.2.3. Requisitos
Um sistema distribuído precisa que alguns requisitos sejam levados em conta durante o seu projeto. O alcance deles determinará o sucesso do sistema em termos de utilidade, desempenho e generalidade. Os requisitos relevantes, neste sentido, são os mostrados a seguir. TRANSPARÊNCIA
Sem dúvida, a característica principal que se quer na maioria de sistemas distribuídos, é que o usuário tenha a visão de uma única máquina virtual. Essa visão, que esconde a existência dos vários elementos de processamento, é gerenciada pelo sistema operacional distribuído, podendo ser dividida em vários níveis: transparência de localização, transparência à migração, transparência de acesso, transparência às falhas, transparência de concorrência, transparência de replicação, entre outros.
Esta característica pode não ser totalmente desejada, especialmente em aplicações onde o paralelismo é explicitamente usado.
FLEXIBILIDADE
padrões que virão a reger o desenvolvimento dos sistemas distribuídos. Sendo assim, os atuais sistemas devem ter a capacidade de atualizar ou mudar certos serviços conforme a tecnologia ou os padrões o requeiram. Junto a esta capacidade de adaptação ao novo, está também a capacidade de adaptação ao já existente: portabilidade e interoperabilidade. Estas duas características fazem aproveitáveis os mais diversos sistemas de computação, apesar da sua potencial heterogeneidade, permitindo que as aplicações aproveitem as vantagens de cada uma das plataformas de hardware e software a disposição.
Um ponto também importante, é o nível de suporte oferecido pelo sistema operacional. Neste aspecto, duas tendências dividem esforços: o núcleo monolítico e o micro-núcleo. O núcleo monolítico pode ser mais eficiente, embora sofra de certa falta de flexibilidade quantitativa e qualitativa. Um exemplo são os sistemas operacionais do tipo UNIX. Por outro lado, o micro-núcleo fornece um conjunto reduzido de funções básicas que permite que outros serviços sejam implementados como servidores ao nível de usuário. Pode ser menos eficiente, mas graças a sua modularidade, favorece alterações na sua funcionalidade e portabilidade a outras arquiteturas.
Um outro aspecto relacionado com a flexibilidade, é a possibilidade de que uma aplicação distribuída possa fazer alterações evolucionárias ou operacionais em tempo de execução. Mais conhecido como reconfiguração, este requisito é discutido no capítulo 3.
CONFIABILIDADE
Um dos objetivos da construção de sistemas distribuídos, é elevar o grau de confiabilidade com respeito aos sistemas centralizados. Isto não é simples de conseguir devido à presença da rede de interconexão, mas em termos gerais, os aspectos que persegue a confiabilidade são: disponibilidade, segurança, coerência, e tolerância a falhas.
A disponibilidade se refere à fração de tempo que o sistema é utilizável ou está disponível para o usuário. A segurança protege todos os recursos da utilização desautorizada. A coerência, por outro lado, permite a utilização concorrente das informações por diferentes componentes ou a utilização de técnicas de replicação. Finalmente, técnicas de tolerância a falhas podem ser aplicadas na medida em que isto não introduza um decremento avultado no desempenho.
Com o incremento da complexidade das aplicações, é esperado um incremento no número de CPUs utilizadas pelos sistemas distribuídos. Isto traz uma série de problemas que só podem ser enfrentados se são evitadas técnicas de projeto como componentes, tabelas e algoritmos centralizados, ou estruturas de controle hierárquico. Deve-se preferir, no seu lugar, o uso de mecanismos de sincronização distribuídos. Por outro lado, as normas que regem o projeto de um bom algoritmo descentralizado, com capacidade de escalabilidade, são:
• Nenhum processador tem informação completa do estado do sistema.
• Os processadores fazem decisões baseadas só em informações acessíveis localmente. • A falha de um processador não leva à falha do algoritmo.
• Não se pode assumir implicitamente a existência de um relógio global. DESEMPENHO
Todas as condições e características descritas não tem muito sentido para o usuário se o desempenho apresentado pelo sistema distribuído não supera aquele obtido em um sistema centralizado. Várias métricas tem sido definidas para avaliar o desempenho de sistemas paralelos e distribuídos, embora nenhuma seja mais válida que a execução da própria aplicação no sistema[45]. Um ponto chave para alcançar um bom desempenho nos sistemas distribuídos é a otimização da comunicação entre processos. A eficiência desta tarefa determina, em grande parte, a eficiência do sistema como um todo. Também relacionados são a capacidade dos canais de comunicação e a freqüência com que são invocadas as primitivas de comunicação no sistema (granularidade das aplicações).
2.3. Questões de Projeto
Um sistema distribuído consta de múltiplas CPUs interligadas. Contudo, nada foi dito ainda sobre quais são as alternativas ou modelos de trabalho usados para dar ao usuário a visão de uma única máquina. Alguns desses modelos, assim como os suportes oferecidos, são descritos a seguir.
Todo o software executável em um sistema de computação, incluindo o sistema operacional, é organizado como um conjunto de processos seqüenciais. Um processo é simplesmente um programa em execução, incluindo o seu PC (Program Counter), registros e variáveis[47]. Conceitualmente, um processo é a mínima unidade que tem a sua própria CPU virtual, o que leva a considerá-lo como o componente mínimo de qualquer computação.
Computador Computador Processos Threads PC Sist. Operacional Sist. Operacional
Figura 3. Processos vs. Threads.
No entanto, muitos sistemas operacionais já contam com a possibilidade de dividir um processo em dois ou mais miniprocessos compartilhando um mesmo espaço de endereçamento. Cada um desses miniprocessos é executado seqüencialmente, com o seu próprio contador de programa, registros e pilha, e na maioria dos casos, sem proteção entre eles. Estas linhas de controle são chamadas de threads. As threads são usadas principalmente em aplicações que conjugam processamento paralelo, execução seqüencial e chamadas bloqueantes ao sistema. Muitos modelos estão sendo propostos para tais fins, principalmente devido ao baixo custo de criação. Na atualidade, duas possibilidades de implementação destas linhas de controle chaveadas competem. A primeira é a implementação ao nível do usuário, não implicando nenhuma modificação no núcleo do sistema operacional e dando a opção de que cada usuário escolha o seu próprio algoritmo de escalonamento. A segunda possibilidade é a implementação ao nível do núcleo do sistema operacional, implicando um desempenho pior, embora simplifique alguns problemas de desenvolvimento.
2.3.2. Modelo do Sistema
Em um sistema incluindo muitas CPUs é importante conhecer como elas estão organizadas e quais são as opções de utilização para uma determinada tarefa de computação. Desta forma, podem ser definidos, em termos gerais, três modelos aplicáveis a um sistema: estações de trabalho, repositório de processadores, e um modelo híbrido que mistura os dois anteriores. MODELO ESTAÇÕES DE TRABALHO
A característica encontrada neste modelo, que é o mais comumente encontrado, é a existência de várias estações de trabalho ou computadores pessoais de alto desempenho, ligados através de uma rede de alta velocidade. As vantagens deste modelo são a sua simplicidade e facilidade para entender, embora não proporcione o suporte necessário para ter um verdadeiro sistema distribuído.
Os principais problemas associados ao modelo são: como compartilhar o poder computacional do conjunto de estações de trabalho, como encontrar uma estação de trabalho ociosa e o que fazer para que os processos possam ser executados transparentemente, apesar de estarem sendo processados em máquinas diferentes. Estes problemas estão sendo solucionados, prometendo converter este modelo em um dos mais populares.
MODELO REPOSITÓRIO DE PROCESSADORES
MODELO HÍBRIDO
Na maioria dos casos, não é adequado ter somente o modelo de estações de trabalho ou somente o modelo de repositório de processadores. Uma solução mais adequada é ter uma mistura de ambos, com a qual se atenuam as desvantagens dos dois modelos. Esta mistura é mais cara, no entanto provê uma rápida resposta interativa, um uso eficiente dos recursos e um projeto simples do sistema.
Atualmente, a possibilidade de ter estações de trabalho ligadas por uma rede de alta velocidade, junto a multiprocessadores e servidores dedicados, é comum. Sendo assim, este modelo é um dos mais gerais e aplicável em grande parte dos casos. Tudo isto leva a que pacotes de software como PVM, Linda, Express, etc., ganhem popularidade e repercussão na área, graças a sua orientação implícita para a programação paralela e distribuída de um conjunto heterogêneo de computadores.
2.3.3. Alocação de Processadores
Um dos problemas que surgem quando um conjunto de processos requer vários processadores é qual processador alocar a qual processo. Para isto, vários modelos de alocação tem sido propostos, tentando cada um deles otimizar uma determinada condição como utilização da CPU, tempo de resposta, etc. A maioria destes modelos assume que todos os processadores são compatíveis e totalmente interconectados, devendo se entender por compatibilidade o fato de que pelo menos existem os executáveis dos programas para cada um deles. Uma outra hipótese freqüente é que cada estação conheça sua carga, tendo sido propostas diversas técnicas para determinar esta magnitude (mas nenhuma considerada exata).
Uma regra que tem sido aceita amplamente é que os algoritmos de alocação de processadores (e também de balanceamento de carga) mais simples são, geralmente, os melhores. Não se deve esquecer que uma análise de estabilidade pode ajudar a detectar laços de troca de informação prejudiciais para o desempenho do sistema.
2.3.4. Suporte Tradicional
Os sistemas operacionais existentes, sejam estes genéricos, como no caso de UNIX, ou especializados, oferecem um suporte básico tradicional para a programação de sistemas distribuídos. Este suporte mínimo esta resumido nos seguintes itens:
a) Suporte ao Componente Mínimo: É a estrutura de execução mínima oferecida pelo sistema operacional, assim como o suporte disponível para a mesma. Na maioria dos sistemas operacionais, o componente mínimo é o processo.
b) Sistema de Comunicação: Corresponde ao suporte que permite a interação dos componentes de um sistema distribuído, tanto para fins de sincronismo quanto para troca de informação.
c) Nomeação: É a capacidade do sistema operacional para prover uma identificação única para todos os componentes do sistema.
O suporte tradicional geralmente sofre de algumas deficiências que impedem o seu aproveitamento direto na construção de sistemas distribuídos. As principais são:
• Os serviços oferecidos não são completos nem abrangentes.
• Não existe homogeneidade entre os serviços locais e os serviços remotos. • Não se tem mecanismos de redundância, coerência, nem tratamento de falhas. • Os serviços de nomeação e reconfiguração são deficientes ou inexistentes. • Oferecem pouca flexibilidade e portabilidade.
• A utilização de primitivas especializadas é complexa e repleta de detalhes de sintaxe. Isto leva a pensar na necessidade de um sistema de suporte explícito, que proveja serviços nativos especializados para a construção e operação de aplicações distribuídas.
O sistema de suporte oferecido por um sistema operacional distribuído pode ser implícito ou explícito. O suporte implícito é o caso do suporte tradicional, oferecido pela maioria dos sistemas operacionais. O suporte explícito, por outro lado, é um suporte adicional que facilita a operação e gerência do sistema, englobando tarefas como tolerância a falhas, balanceamento de carga, coordenação, depuração e reconfiguração, assim como um incremento na integridade e disponibilidade das aplicações distribuídas.
O suporte à operação compreende os mecanismos que implementam os modelos definidos na metodologia adotada pelo sistema. Tais mecanismos estão associados com a separação da computação dentro do ambiente e com as relações existentes entre os componentes, podendo também incluir as primitivas de comunicação, implementação de tarefas, métodos de sincronismo e outros.
Complementarmente, o suporte à gerência oferece recursos complexos de nomeação, reconfiguração e controle de recursos. A sua função é prover uma certa transparência ao usuário, permitindo-o controlar o sistema através da representação estabelecida na metodologia implementada pelo mesmo. O suporte à gerência é independente, mas a sua flexibilidade e serviços oferecidos estão baseados nos recursos providos pelo suporte à operação. Atualmente, mostram-se muito adequadas para tarefas de gerência e configuração, as interfaces do tipo gráfico, as quais facilitam a interação homem-máquina. É por isso que dentro do suporte à gerência, é cada vez mais importante o uso de linguagens e ambientes de programação visual.
2.4. O Sistema de Comunicação
A maior diferença existente entre os sistemas distribuídos e os sistemas centralizados está na comunicação entre processos. Devido à ausência de uma memória compartilhada, todas as atividades de comunicação estão baseadas na troca de mensagens entre processos. O sistema de comunicação tem como função regular esta troca de mensagens, tornando-a segura e eficiente.
2.4.1. Protocolos de Comunicação
que definem o serviço, enquanto que os protocolos são o conjunto de regras que determinam a ação de cada uma delas. Modelos como o OSI-RM (Open System Interconnection - Reference
Model)[57] apresentam falta de transparência, tolerância a falhas e atomicidade para a
construção de sistemas distribuídos, além de certa sobrecarga introduzida especialmente em LANs. Uma alternativa, é utilizar um subconjunto de camadas que melhorem o desempenho e garantam suficiente confiabilidade na comunicação.
Os protocolos podem ser classificados como orientados à conexão ou sem conexão, sendo utilizados conforme os requisitos da aplicação. Dentre os protocolos mais difundidos e de propósito geral estão o TCP (Transmission Control Protocol) e o UDP (User Datagram
Protocol)[51]. TCP é um protocolo confiável orientado à conexão. UDP, por outro lado, é um
protocolo mais simples que permite enviar datagramas, podendo haver duplicação ou perda de mensagens. Ambos protocolos utilizam os serviços de uma camada de rede denominada IP (Internet Protocol). IP é o protocolo de nível de rede da Internet, que permite o envio de datagramas entre computadores ou redes interconectadas. Provê um serviço de distribuição sem conexão, sendo o bloco base para a construção de outros protocolos como TCP e UDP.
Existem também outros protocolos que estão otimizados para obter vantagens de sistemas específicos, provendo um elevado desempenho mediante o uso de redes de alta velocidade. Tais protocolos são especializados e não muito difundidos.
2.4.2. Modelo Cliente-Servidor
O modelo cliente-servidor está baseado geralmente em protocolos simples de pedido/resposta. Estes protocolos provêem facilidades mínimas de controle e verificação, normalmente associadas às camadas inferiores que são já uma tecnologia dominada e muito utilizada.
Sist. Operacional
Cliente Servidor
Sist. Operacional
Stub Stub
Máquina Cliente Máquina Servidor
1 2 3 4 5 6 7 8 9 10
Figura 4. Chamada a Procedimentos Remotos
Uma classe especial de primitivas síncronas são as denominadas RPC (Remote Procedure
Call)[6]. O seu fundamento é dar transparência à comunicação entre processos mediante a
eliminação do paradigma de entrada/saída. A operação básica da execução remota dos procedimentos é feita pela geração de um stub cliente e de um stub servidor a partir de especificações formais em uma linguagem determinada. No momento que um programa acessa o procedimento remoto, de forma similar aos procedimentos locais (figura 4), a troca de mensagens entre os stubs permite a execução remota do código invocado. A passagem de parâmetros e resultados é feita através do seu empacotamento em mensagens. Os problemas que devem ser resolvidos neste caso são, entre outros: diferentes espaços de endereçamento para a execução dos procedimentos remotos, impossibilidade de ter variáveis globais, dificuldade para a passagem de ponteiros, existência de diferentes tipos de máquinas, e possíveis falhas nas máquinas.
No modelo cliente-servidor, um problema a solucionar é como o cliente localiza o servidor, sendo a principal alternativa a denominada “ligação dinâmica”. Para isso, o servidor inicia a sua operação exportando a sua interface a um processo chamado de binder, que registra o servidor e fica à espera de mensagens provenientes de clientes desejando importar uma determinada versão. O binder entrega um handler para o cliente, o qual faz então a chamada ao procedimento remoto. Este aproveitamento tem alta flexibilidade devido à possibilidade de ter múltiplos servidores, permitindo implementar técnicas de balanceamento de carga e tolerância a falhas, assim como atividades de autenticação. As desvantagens são a carga extra para o sistema e o possível gargalo de comunicação.
Apesar do modelo cliente-servidor impossibilitar a formação de grupos de comunicação, são muitas as aplicações onde vários receptores compartilham uma mesma operação de comunicação. Um grupo é uma coleção de processos que atuam em conjunto, onde a comunicação é geralmente baseada em multicasting ou broadcasting das mensagens. É uma abstração simples que pode introduzir detalhes complicados quando se permite que os grupos sejam altamente dinâmicos.
O endereçamento dos grupos pode ser através de um único endereço, através de uma lista de processos destinatários, ou através de um endereçamento baseado em predicados[58]. Esta última opção faz com que uma mensagem seja aceita só quando a avaliação de uma expressão é igual a TRUE. As primitivas usadas para a comunicação de grupos podem ser as mesmas do caso ponto a ponto, dando maior transparência à programação do sistema, mas também podem ser procedimentos de biblioteca diferentes, com sintaxes específicas. Um outro assunto importante é a composição de grupos. Para isto, é geralmente utilizado um servidor que pode tornar-se um gargalo em sistemas maiores. No entanto, também existem algoritmos distribuídos que se adaptam muito bem à gerência de grupos.
2.4.4. Modelo Transacional
Uma abstração de mais alto nível, que se refere ao uso da comunicação para o processamento da informação, são as transações atômicas. Nelas, a interação de um cliente é tratada como uma ação única, segura e indivisível. Depois de iniciada uma transação e negociadas as opções de interação, é esperado um acordo total dos processos envolvidos. Se algum processo não concordar, o sistema volta ao estado em que se encontrava justo antes de iniciada a transação. As propriedades encontradas no modelo transacional são:
• Serialidade, não existe interferência entre transações concorrentes.
• Atomicidade, acontecem de uma forma indivisível para o mundo exterior.
• Permanência, uma vez que uma transação concorda, as mudanças são permanentes.
Os mecanismos mais usados para a implementação de transações são o espaço de trabalho privado, a lista de intenções (ou registro de escritura prévia) e os protocolos de acordo em duas fases. Existem, também, alguns mecanismos para garantir a não interferência entre transações concorrentes, provendo serialidade às mesmas, os principais são o locking e o uso de carimbos de tempo.
2.5. Depuração
O mecanismo de depuração é definido como o processo de localização, análise e correção de possíveis falhas, sendo uma falha uma condição acidental que impossibilite um programa de executar suas funções como desejado[39]. Este mecanismo é de grande importância no desenvolvimento de sistemas não triviais, fazendo-o essencial para a construção de aplicações distribuídas. A distribuição torna ainda mais complicada a já difícil tarefa de depurar.
Os principais obstáculos encontrados são a dificuldade de manter o estado global exato do sistema, o grande espaço de estados, a não repetibilidade das interações entre múltiplos processos assíncronos, as limitações existentes nas tarefas de comunicação, e a latência entre os erros e a sua descoberta. Pode-se adicionar a tudo isto o “efeito teste”, que faz com que erros do sistema desapareçam em uma execução controlada.
preocupação a coordenação dos depuradores independentes. Um sistema de depuração típico pode ser modelado como a união de três domínios: o domínio do programa que inclui as características estáticas do programa, o domínio humano que inclui os atributos do programador, e o domínio de execução que inclui as descrições no tempo de execução. O sistema de depuração então, administra as interações entre estes domínios através das suas respectivas interfaces[18].
Existem inúmeras metodologias utilizadas pelos programadores para a depuração dos seus sistemas. No entanto, todas elas podem ser agrupadas nas categorias top-down e bottom-up. A metodologia top-down inicia a depuração no grupo completo de processos como um todo e, a cada passo, aprofunda na depuração de cada um dos seus componentes. A metodologia
bottom-up, mais popular que a top-down, é aquela que inicia o processo de depuração com
cada um dos componentes elementares e, a cada passo, sobe até ter todo o conjunto de processos da aplicação.
2.5.1. Técnicas Básicas
Assumindo que não existem erros no software do sistema operacional, podem se utilizar as seguintes técnicas básicas de depuração:
• Geração de Saídas: É uma técnica primitiva e simples.
• Rastreio (tracing): Permite obter o fluxo de execução do programa.
• Pontos de Parada: Suspendem a execução do processo, armazenando o estado final. • Execução de Asserções: Se baseia no uso de predicados de execução.
• Execução Controlada: Permite mudar a velocidade e a seqüência de execução. • Re-execução: Simula a execução utilizando o histórico de um processo.
Cada uma destas técnicas gera várias saídas que tem que ser monitoradas ou armazenadas para uma análise posterior. As formas de visualização mais comuns são: textual, diagramas tempo-processos, animação, e múltiplas janelas. A tendência é ter várias visões simultâneas dos detalhes de estado da aplicação, podendo inclusive ser uma por processo.
Em um sistema distribuído existem duas classes de eventos do ponto de vista da depuração: as atividades de comunicação entre os processos e as atividades internas de cada um deles. Independente da técnica de depuração utilizada, uma forma fácil de tratar tais eventos é gravar a história deles para análise posterior. Essa história de eventos pode ser examinada usando ferramentas que vão desde simples editores de texto a representações animadas dos dados.
Uma característica importante deste registro é a possibilidade de fazer uma re-execução utilizando unicamente a informação histórica dos eventos. Adicionalmente, ele pode ser usado para a simulação de um ambiente que permita a execução controlada de um determinado processo. Problemas na criação deste histórico são o desempenho obtido ao compartilhar operações de leitura/escrita sobre um mesmo dispositivo, e o tipo de ordenação utilizada pela história de eventos.
2.6. Estudo de Casos
Vários grupos de pesquisa tem desenvolvido pacotes de software para assistir aos programadores no desenvolvimento de sistemas paralelos e distribuídos. Alguns exemplos são descritos a seguir.
2.6.1. ISIS
O sistema ISIS[5] foi desenvolvido na Cornell University, sendo um conjunto de programas que rodam sobre vários sistemas do tipo UNIX. A base do sistema é o ISIS Distributed
ToolKit, que fornece a tecnologia central, conhecida como sincronismo virtual, para o seu
função é tratar eventos, estabelecendo um estilo de programação call-back baseada em eventos. Para a implementação de tais tarefas, ISIS usa linhas de controle internamente definidas. Este modelo de computação distribuída inclui outras ferramentas como o ISIS
Reliable NFS, ISIS Distributed Resource Manager, Distributed News e Reliable Distributed Object Manager, de grande ajuda no desenvolvimento de aplicações.
2.6.2. Linda
Linda[17] é um modelo de programação concorrente que tem evoluído a partir de um projeto de pesquisa na Yale University. O conceito primário de Linda é o “espaço de tuplas”, uma abstração através da qual os processos cooperantes se comunicam. O espaço de tuplas tem sido proposto como um paradigma alternativo aos métodos tradicionais de processamento como memória compartilhada e troca de mensagens. O conceito de espaço de tuplas é essencialmente uma abstração da memória compartilhada distribuída sem requerer hardware específico, com uma diferença importante (espaços de tuplas são associativos) e algumas distinções menores (são possíveis leituras destrutivas e não-destrutivas, e diferentes semânticas de coerência). As aplicações usam o modelo Linda, introduzindo explicitamente dentro dos programas seqüenciais cooperantes construções que manipulam o espaço de tuplas.
Do ponto de vista da aplicação, Linda é um conjunto de extensões à linguagem de programação que facilita a programação paralela. O software do sistema estabelece e mantém espaços de tuplas, sendo usado em conjunção com bibliotecas que interpretam e executam apropriadamente as primitivas Linda. Dependendo do ambiente, o mecanismo do espaço de tuplas é implementado usando diferentes técnicas, variando o seu grau de eficiência. Um novo esquema do sistema, chamado de Piranha, foi proposto recentemente[27]. Ele propõe um enfoque ativo da computação concorrente: recursos computacionais (vistos como agentes ativos) pegam tarefas computacionais de uma localidade bem conhecida, baseados em fatores de disponibilidade e usabilidade.
2.6.3. Parallel Virtual Machine
compartilhada ou memória local, supercomputadores vetoriais, estações gráficas especializadas, ou estações de trabalho escalares, podendo estar interligadas através de uma variedade de redes, tais como Ethernet, Token Ring, FDDI (Fiber Distributed Data Interface), HiPPI (High-Performance Parallel Interface), etc.
Os programas de usuário, escritos em C ou Fortran, podem acessar os recursos da plataforma através das bibliotecas PVM para realizar atividades de baixo nível, como iniciação de processos, transmissão e recepção de mensagens, sincronização mediante barreiras ou encontros (rendezvous), etc. Os usuários podem, opcionalmente, controlar a localização da execução dos componentes de uma aplicação, assim como monitorar o estado de uma máquina determinada. O sistema PVM manipula transparentemente o roteamento das mensagens, a conversão de dados entre arquiteturas incompatíveis, e outras tarefas que são necessárias para a operação em um ambiente heterogêneo de rede.
Junto com o software básico, estão sendo desenvolvidas uma série de ferramentas e sistemas auxiliares, que tornam PVM um recurso de computação concorrente coerente e flexível. XPVM, por exemplo, é uma interface gráfica que permite a monitoração e depuração de aplicações. HeNCE (Heterogeneous Network Computing Environment) é uma interface gráfica e metodologia para o uso de PVM. PIOUS (Parallel Input/Output System) é a arquitetura de um sistema de arquivos paralelo que provê acesso a um armazenamento permanente por parte de um grupo de processos em um ambiente PVM.
O pacote de software associado com PVM é amplamente portável e de livre distribuição, e está se convertendo em um padrão na área de processamento paralelo. Ele está sendo desenvolvido, desde 1989, por um grupo de instituições, incluindo o Oak Ridge National
Laboratory, University of Tennessee, Emory University e Carnegie Mellon University.
2.6.4. Message Passing Interface
MPI não pretende ser uma infra-estrutura de software completa e auto-contida que possa ser usada para a computação distribuída. Ele não inclui requisitos como gerência de processos, configuração da máquina virtual e suporte para entrada/saída, embora algumas extensões tenham sido propostas. Como resultado, foi antecipado que MPI será estruturado como uma camada de interface para a comunicação, a qual será construída sobre as facilidades nativas da plataforma de hardware, com exceção de certas operações de transferência de dados que podem ser implementadas a um nível mais próximo do hardware.
2.6.5. Distributed Computing Environment
O ambiente DCE (Distributed Computing Environment)[48] foi estruturado pela OSF (Open
Software Foundation) como um conjunto integrado de serviços de sistema e de rede. Ele
suporta o desenvolvimento, operação e manutenção de aplicações distribuídas sobre qualquer sistema operacional do tipo UNIX que proveja comunicação entre processos baseada em
sockets TCP/IP. DCE implementa, sobre o sistema operacional base, um ambiente de threads
que é empregado para a implementação dos serviços DCE e inclusive para a construção das aplicações.
Os serviços oferecidos podem se resumir nos seguintes itens: mecanismo de comunicação RPC, biblioteca de suporte a threads, serviços de temporização, servidor de nomes baseado no padrão X.500, sistema de arquivos de acordo com a especificação DFS, e um mecanismo de segurança baseado em autenticação. Este ambiente pode ser considerado com uma plataforma versátil e eficiente para a construção de sistemas distribuídos, oferecendo atualmente diversos sistemas que disponibilizam um ambiente de gerência.
2.7. Resumo
Sistemas Distribuídos Configuráveis
Revisadas as idéias principais sobre sistemas distribuídos, vão ser abordados a seguir os conceitos em que se baseiam os denominados sistemas distribuídos configuráveis. Estes sistemas podem se adaptar facilmente a situações específicas de utilização e operação, sem necessidade de reprogramação. Isto é útil para a construção de aplicações que mudam a sua estrutura durante o tempo de execução (aplicações de natureza dinâmica), ou que tenham requisitos de alta disponibilidade e confiabilidade. O capítulo inicia discutindo dois temas de forte influência nos sistemas configuráveis: a programação orientada a objetos e a programação visual. São mostradas, para cada um destes temas, as principais abordagens e opções de implementação. A seguir, são analisados vários conceitos relacionados com a configuração e reconfiguração de aplicações. Finalmente, são apresentados, a título de exemplo, alguns sistemas existentes que empregam os conceitos anteriormente mencionados.
3.1. Objetos Distribuídos
Um tema que tem recebido grande atenção na área dos sistemas de software é a programação orientada a objetos, apresentando-se como a principal alternativa para a construção de sistemas complexos ou de grande porte. Os sistemas distribuídos, que por definição são sistemas complexos, têm sido favorecidos pela adoção de metodologias que privilegiam a modularidade e reutilização do software, tanto na concepção, como na sua implementação. Além disso, as aplicações atuais requerem, cada vez mais, soluções que misturem a flexibilidade da concorrência e distribuição com o poder da tecnologia orientada a objetos. Essa tarefa não é fácil, existindo muitas abordagens que tentam aproveitar a grande capacidade de modelagem desta proposta, mediante a denominada COOP (Concurrent Object-Oriented
Programming).
3.1.1. Orientação a Objetos
dados locais, os ambientes orientados a objetos baseiam a sua programação em elementos chamados de objetos, os quais são componentes de software que encapsulam tanto os dados como as operações que atuam sobre esses dados (figura 5). Um objeto, que na maioria das propostas é um ente totalmente isolado dos outros, permite a modificação do seu estado interno (dados) unicamente através da invocação de uma das operações contidas na definição do mesmo. A execução de uma das operações internas, com a informação de parâmetros necessária, é chamada de invocação de um método sobre o objeto. Todo objeto é uma instância concreta de alguma classe, possuindo o mesmo conjunto de operações e representação interna que todos os objetos criados a partir dessa classe. Uma classe é a extensão natural do conceito de tipo de dados, podendo ser considerada uma fôrma, ou especificação, baseada na qual os objetos são criados.
Métodos Implementação dos Métodos Estado Interno
(Dados)
Figura 5. Estrutura de um Objeto
Quando um sistema de software manipula só dados e funções como objetos, é chamado de sistema baseado em objetos. Quando os objetos são abstraídos em classes com propriedades de herança e polimorfismo, o sistema é dito orientado a objetos. Desta forma, um sistema de
software orientado a objetos deve prover todos os quatro mecanismos listados a seguir:
a) Encapsulamento: Esconde ou torna privados os detalhes de implementação dos objetos, tornando públicas só as abstrações necessárias para utilizar o objeto. Os objetos se comunicam através de interfaces bem definidas, de modo que as mudanças no seu estado permanecem localizadas dentro do objeto.
b) Abstração: Separa as propriedades essenciais para escrever o software com algum propósito, das propriedades que são irrelevantes a esse propósito. A abstração permite separar a interface do objeto, da sua implementação.
existentes. Como foi dito, uma classe é um molde para uma coleção de objetos com estrutura de dados e comportamento similares. Uma subclasse herda as operações da classe superior, podendo modificá-las ou estende-las com operações adicionais, para criar níveis maiores de especialização. De fato, a herança estabelece uma hierarquia de classes que estimula o reaproveitamento do software visando a organização e simplicidade implícitas. d) Polimorfismo: É uma outra característica bastante útil que permite que uma mensagem
enviada a um objeto possa ter diferentes resultados, dependendo de como o objeto interpreta o pedido. Consiste no uso da mesma operação, em instâncias de classes relacionadas mas distintas, permitindo que a maioria das operações da classe superior possam ser utilizadas nas classes inferiores. Isto possibilita que mesmo que uma operação faça sentido na classe superior e na inferior, as implementações em cada uma delas possam ser distintas, de forma a alterar o seu comportamento.
A orientação a objetos permite um rápido desenvolvimento graças ao mecanismo de herança, que permite que novas peças de código herdem os comportamentos de projetos e códigos existentes. Deve-se notar que o projeto, e não simplesmente o código, pode ser reutilizado, sendo esta uma característica essencial. Uma vez que um objeto é projetado, escrito, depurado e usado em uma determinada aplicação, a sua utilidade aumenta já que ele foi verificado e testado, sendo potencialmente mais confiável. Devido a que os sistemas orientados a objetos podem ser implementados gradualmente, a sua manutenção pode também ser reduzida. Uma vez postos em funcionamento, os sistemas continuam sendo paulatinamente melhorados, com efeitos localizados dentro dos objetos da aplicação. Tudo isto, graças às características de encapsulamento e abstração encontradas na programação orientada a objetos. Aliás, é importante mencionar que os sistemas orientados a objetos raramente mudam a sua estrutura global. É comum, em muitos casos, somente a evolução contínua dos objetos neles contidos.
No entanto, o verdadeiro poder do software orientado a objetos reside na construção de
frameworks específicos para as aplicações em desenvolvimento. Um framework é um projeto
para uma aplicação genérica que não só incorpora o código, mas também as interações entre os módulos de código. Em resumo, pode se dizer que a programação orientada a objetos resolve três problemas principais que são enfrentados no desenvolvimento de software:
• A necessidade de reduzir os custos de manutenção na fase de funcionamento.
3.1.2. Alternativas
A distribuição em um modelo orientado a objetos gera uma série de problemas que dificultam a implementação completa do paradigma na sua forma tradicional. As maiores considerações que tem que ser levadas em conta, para o caso dos sistemas distribuídos, são as listadas a seguir:
a) Herança: Os custos envolvidos na busca dentro da hierarquia de classes através do sistema distribuído, inviabilizam as vantagens obtidas com a adoção desta técnica.
b) Verificação de Tipo: As linguagens orientadas a objetos não possuem verificação de tipo estática. No caso distribuído, devido ao seu tratamento remoto, isto pode gerar erros indesejáveis em tempo de execução.
c) Gerenciamento: Parte da funcionalidade no gerenciamento de uma linguagem orientada a objetos está determinada pela hierarquia de classes que descreve o comportamento dos objetos requeridos por uma aplicação, não existindo uma descrição explícita da estrutura do programa. Isto se contrapõe com a descrição explícita da relação entre os elementos, importante em ambientes distribuídos.
d) Granularidade de Concorrência: Basicamente se tem dois casos, no primeiro a granularidade de concorrência coincide com o objeto, e no segundo, um objeto pode suportar várias threads de execução simultânea.
e) Falhas Parciais: São as falhas introduzidas em operações que não exigem maiores cuidados, requerendo mecanismos adicionais de tratamento que vão desde a simples detecção de falhas, até tolerância a falhas transparente.
alternativas que se mostram mais viáveis para este caso: a delegação direta e a composição hierárquica[60]. Estado Métodos Estado Métodos Estado Métodos Estado Métodos Delegação Direta Composição Hierárquica
Figura 6. Delegação Direta e Composição Hierárquica
DELEGAÇÃO DIRETA
A delegação consiste na transferência direta da responsabilidade do tratamento de um método de um objeto para outro (figura 6). Não impõe restrições quanto às relações existentes entre os objetos encapsulados, já que não se baseia na hierarquia de classes nem em nenhuma outra forma de relação entre objetos. Como não existe o mecanismo de herança que permita o compartilhamento de dados locais pelas classes relacionadas, deve ocorrer a delegação explícita das informações locais na transferência dos métodos. Isto leva a que a transferência de um método possa requerer um tratamento local, tanto para condicionar os parâmetros como para informar as variáveis de estado locais.
No caso distribuído, esta abordagem tem duas deficiências principais: não fica claro como podem ser construídos objetos complexos que encapsulem atividades internas paralelas, e, falta uma definição explícita da relação existente entre os objetos que determine a descrição do programa como composto por vários objetos.
COMPOSIÇÃO HIERÁRQUICA
