A linguagem de programação Java vem sendo uma das escolhidas para a implementação de aplicações compostas por objetos distribuídos. Estas aplicações caracterizam-se por possuir comportamento complexo e, portanto, são mais difíceis de depurar e refinar para obter melhores desempenhos. Considerando a necessidade do desenvolvimento de uma ferramenta de monitoração para o modelo de objetos distribuídos, que colete informações mais detalhadas sobre a execução da aplicação, é apresentado neste trabalho um ambiente de monitoração de aplicações distribuídas escritas em Java, o DOMonitor. Um dos objetivos do DOMonitor é obter o comportamento que a aplicação apresenta durante a execução, possibilitando a detecção de comportamentos equivocados e seu respectivo refinamento. O DOMonitor é voltado para aplicações compostas por objetos distribuídos e caracteriza-se por identificar principalmente: (i) o comportamento dinâmico das threads; (ii) a utilização dos métodos de sincronização; e (iii) a comunicação entre os entes distribuídos da aplicação. O DOMonitor está fundamentado em quatro premissas: (i) ser transparente para o usuário, não exigindo anotações no código fonte; (ii) apresentar uma organização modular, e por isto ser flexível e expansível; (iii) ser portável, não exigindo nenhuma alteração na Maquina Virtual Java; e (iv) operar de forma a garantir a ordem dos eventos previstos pelo programa. Os dados produzidos pelo DOMonitor podem ser utilizados com diversas finalidades tais como visualização da execução, escalonamento e como suporte à execução de aplicações móveis. Para comprovar esta versatilidade, foi proposta a integração do sistema a dois outros projetos, o Pajé e o ISAM. O projeto ISAM utilizará os dados monitorados para tomadas de decisão durante o curso da execução e o projeto Pajé permite a visualização gráfica das características dinâmicas de uma aplicação Java.

A linguagem de programação Java vem sendo uma das escolhidas para a implementação de aplicações compostas por objetos distribuídos. Estas aplicações caracterizam-se por possuir comportamento complexo e, portanto, são mais difíceis de depurar e refinar para obter melhores desempenhos. Considerando a necessidade do desenvolvimento de uma ferramenta de monitoração para o modelo de objetos distribuídos, que colete informações mais detalhadas sobre a execução da aplicação, é apresentado neste trabalho um ambiente de monitoração de aplicações distribuídas escritas em Java, o DOMonitor. Um dos objetivos do DOMonitor é obter o comportamento que a aplicação apresenta durante a execução, possibilitando a detecção de comportamentos equivocados e seu respectivo refinamento. O DOMonitor é voltado para aplicações compostas por objetos distribuídos e caracteriza-se por identificar principalmente: (i) o comportamento dinâmico das threads; (ii) a utilização dos métodos de sincronização; e (iii) a comunicação entre os entes distribuídos da aplicação. O DOMonitor está fundamentado em quatro premissas: (i) ser transparente para o usuário, não exigindo anotações no código fonte; (ii) apresentar uma organização modular, e por isto ser flexível e expansível; (iii) ser portável, não exigindo nenhuma alteração na Maquina Virtual Java; e (iv) operar de forma a garantir a ordem dos eventos previstos pelo programa. Os dados produzidos pelo DOMonitor podem ser utilizados com diversas finalidades tais como visualização da execução, escalonamento e como suporte à execução de aplicações móveis. Para comprovar esta versatilidade, foi proposta a integração do sistema a dois outros projetos, o Pajé e o ISAM. O projeto ISAM utilizará os dados monitorados para tomadas de decisão durante o curso da execução e o projeto Pajé permite a visualização gráfica das características dinâmicas de uma aplicação Java.

A linguagem de programação Java vem sendo uma das escolhidas para a implementação de aplicações compostas por objetos distribuídos. Estas aplicações caracterizam-se por possuir comportamento complexo e, portanto, são mais difíceis de depurar e refinar para obter melhores desempenhos. Considerando a necessidade do desenvolvimento de uma ferramenta de monitoração para o modelo de objetos distribuídos, que colete informações mais detalhadas sobre a execução da aplicação, é apresentado neste trabalho um ambiente de monitoração de aplicações distribuídas escritas em Java, o DOMonitor. Um dos objetivos do DOMonitor é obter o comportamento que a aplicação apresenta durante a execução, possibilitando a detecção de comportamentos equivocados e seu respectivo refinamento. O DOMonitor é voltado para aplicações compostas por objetos distribuídos e caracteriza-se por identificar principalmente: (i) o comportamento dinâmico das threads; (ii) a utilização dos métodos de sincronização; e (iii) a comunicação entre os entes distribuídos da aplicação. O DOMonitor está fundamentado em quatro premissas: (i) ser transparente para o usuário, não exigindo anotações no código fonte; (ii) apresentar uma organização modular, e por isto ser flexível e expansível; (iii) ser portável, não exigindo nenhuma alteração na Maquina Virtual Java; e (iv) operar de forma a garantir a ordem dos eventos previstos pelo programa. Os dados produzidos pelo DOMonitor podem ser utilizados com diversas finalidades tais como visualização da execução, escalonamento e como suporte à execução de aplicações móveis. Para comprovar esta versatilidade, foi proposta a integração do sistema a dois outros projetos, o Pajé e o ISAM. O projeto ISAM utilizará os dados monitorados para tomadas de decisão durante o curso da execução e o projeto Pajé permite a visualização gráfica das características dinâmicas de uma aplicação Java.

O advento dos computadores pessoais e posteriormente das estações de trabalho, somado ao desenvolvimento de hardware de comunicação eficiente e de baixo custo, levou a popularização das redes locais. Entretanto, o software não presenciou o mesmo desenvolvimento do hardware, especialmente devido a complexidade dos sistemas distribuídos. A heterogeneidade das máquinas, sistemas e redes, inerente aos ambientes computacionais modernos, restringe igualmente a integração e cooperação entre os nodos disponíveis. 0 objetivo do presente trabalho é, a partir da análise dos principais aspectos relacionados à distribuição e à heterogeneidade, desenvolver um sistema operacional de rede heterogêneo. Tal sistema, denominado HetNOS (de Heterogeneous Network Operating System), permite o desenvolvimento e validação de aplicações distribuídas homogêneas e heterogêneas de forma rápida e fácil. Os usuários podem concentrar-se nos aspectos de distribuição dos algoritmos, abstraindo detalhes dos mecanismos de comunicação, pois a programação de aplicações distribuídas é baseada em uma plataforma de interface homogênea, fácil de usar e com independência de localidade. Sendo um sistema operacional de rede, o HetNOS atua sobre o conjunto de sistemas operacionais nativos existentes; o ambiente de trabalho e estendido e não substituído. Não há entidades nem informações centralizadas, e os algoritmos são distribuídos, usualmente resultando maior confiabilidade e desempenho. A topologia do sistema é um anel lógico, esquema justificado pela generalidade de tal configuração e pela simplificação do projeto do núcleo distribuído do HetNOS. O paradigma de comunicação entre módulos e a troca de mensagens, mecanismo implementado sobre a interface de programação em rede sockets. Não há compartilhamento de memória em nenhuma instância, tornando o sistema mais legível, manutenível e portável. A interpelação entre módulos fica restrita à interface de mensagens definidas e aceitas por cada módulo. A arquitetura do HetNOS é estruturada e distribuída, pois o sistema é composto de camadas hierárquicas subdivididas em módulos, estes implementados com processos. O nível 1 corresponde ao conjunto de núcleos de sistemas operacionais nativos suportados, sobre o qual é implementado o núcleo distribuído heterogêneo do HetNOS, a DCL (Distributed Computing Layer). O principal serviço fornecido pela DCL (executada no nível 2), é um subsistema de troca de mensagens canônico e independente de localidade. Processos servidores e de usuários podem utilizar as mais variadas formas de comunicação por mensagens, tal como envio, recepção e propagação de mensagens síncronas, assíncronas, bloqueantes e não bloqueantes. No nível 3 estão os servidores do sistema, que estendem e implementam de forma distribuída a funcionalidade do sistema nativo. O Servidor de Nomes é o repositório global de dados, servindo a processos do sistema e de usuários. O Servidor de Autorização implementa o esquema de controle no acesso a recursos do sistema. O Servidor de Tipos permite que aplicações copiem dados estruturados de forma independente de localidade e de arquitetura. Por fim, o Servidor de Arquivos estende os serviços (de arquivos) locais de forma a integrá-los em um único domínio (espaço). No nível 4, arquiteturas e sistemas operacionais são emulados por módulos interpretadores (denominados Emulators). Aplicações de usuários estão espalhadas dos níveis 2 a 5; a camada varia com o tipo de aplicação. Para demonstrar a viabilidade do sistema, implementou-se a estrutura fundamental do HetNOS, incluindo a DCL (um núcleo distribuído heterogêneo), a versões básicas dos módulos servidores, as bibliotecas de procedimentos, além de diversos tipos de aplicações. O sistema conta hoje com mais de 25.000 linhas de código fonte C em mais de 100 arquivos. O desempenho do subsistema de comunicação implementado pela DCL (em avaliações com diferentes configurações de hardware) superou as expectativas iniciais, mas ainda está muito aquém do necessário a aplicações distribuídas. Segundo o que indicam as primeiras experiências realizadas, o HetNOS será bastante útil na prototipação e avaliação de modelos distribuídos, assim como na programação de software distribuído homogêneo e heterogêneo. Projetos de pesquisa do CPGCC envolvendo sistemas distribuídos (p.ex., tolerância a falhas e simulações) podem utilizar o HetNOS como ferramenta para implementação e validação de seus modelos. Futuramente, aplicações distribuídas e paralelas de maior porte poderão ser programadas, como sistemas de gerencia de bases de dados distribuídas, simuladores e sistemas de controle para automação industrial. / The advent of personal computers and, later, of workstations, along with the development of efficient and low-cost communication hardware has led to the popularization of local-area networks. However, distributed software did not experiment the same development of hardware, specially due to the complexity of distributed systems. The machine, system and communication network heterogeneity, inherent to the modern computing environments, is also responsible for the lack of integration and cooperation of available nodes. The purpose of this work is, from the analysis of the main aspects related to distribution and heterogeneity, to design a heterogeneous network operating system. Such system, named HetNOS (which stands for Heterogeneous Network Operating System), allows users to quickly write and validate distributed homogeneous and heterogeneous applications. Users can concentrate their work in the distributed aspects, abstracting communication mechanisms' details, because programming of distributed applications is based on a homogeneous interface platform, easy to use and location-independent. Being a network operating system, HetNOS acts over the set of native operating systems; the environment is extended instead of substituted. There are neither centralized information nor entities, and the algorithms are always distributed, usually yielding more reliability and performance. The HetNOS topology is a logical ring, scheme adopted partly due to the generality of such configuration and partly to simplify the HetNOS distributed kernel design. The communication paradigm between modules is the message exchange, a mechanism implemented over the sockets network application programming interface. There is no shared memory at all, making the system clearer, more manutible and portable. The interrelation between modules is restricted to the message interface defined and accepted by a module. The HetNOS architecture is structured and distributed, as the system is composed of hierarchical layers divided into modules, which in their turn are realized as processes. The layer 1 is the set of native operating system kernels, over which is implemented the distributed heterogeneous HetNOS kernel, namely DCL (states for Distributed Computing Layer). The main service provided by DCL (in layer 2) is a canonical, location-independent, message exchange mechanism. Server and user processes may use multiple forms of message primitives, such as synchronous, asynchronous, blocking and non-blocking send and receive. In the layer 3 are the system servers, which extend and implement in a distributed way the functionality of native systems. The name server is a global data repository, serving other system and user processes. The authorization server implements the security scheme to control the access to the system resources. The type server allows applications to transfer structured data independently of location and architecture. Finally, the file server extends the local (file) services to integrate them into a unique domain (space). In the layer 4, architectures and operating systems are emulated by interpreter modules (named Emulators). User applications are spread over the layers 2 to 5, depending on the application type. In order to prove the system viability, the fundamental HetNOS structure has been implemented, including its distributed heterogeneous kernel, the base of server modules, the procedure libraries, and several types of applications. The system source code has over 25,000 lines of C programming distributed over a hundred files. Although the optimization is an endless process, the performance of the DCL communication subsystem (evaluated using a few different hardware configurations) overestimated initial predictions, but is weak if considered the requirements to distributed processing. Accordingly to the first experiences made, HetNOS will be of great value to evaluate and prototype distributed models, as well as to the programming of homogeneous and heterogeneous distributed software. Local research projects involving distributed systems (e.g., fault tolerance and simulations) may use HetNOS as a tool to validate and implement their models. In the future, more complex distributed and parallel applications will be programmed, such as a distributed database management system, simulators and factory automation control systems.

As grades computacionais e as redes peer-to-peer (P2P) surgiram como áreas distintas, com diferentes propósitos, modelos e ferramentas. No decorrer dos últimos anos, estas áreas foram convergindo, uma vez que a infraestrutura e o modelo de execução descentralizada das redes P2P provaram ser uma alternativa adequada para o tratamento de questões relacionadas à manutenção de grades de larga escala, tais como escalabilidade, descoberta, alocação e monitoramento de recursos. O modelo MultiCluster trata a convergência entre grades computacionais e redes peer-to-peer de uma forma mais restrita: os problemas de escalabilidade, de descoberta e alocação de recursos são minimizados considerando-se apenas recursos localmente disponíveis para a construção de uma grade, a qual pode ser usada para a execução de aplicações com diferentes características de acoplamento e comunicação. Esse trabalho apresenta a arquitetura do modelo e seus aspectos funcionais, bem como um primeira implementação do modelo, realizada através da adaptação da biblioteca de programação DECK sobre os protocolos do projeto JXTA. A avaliação do funcionamento dessa implementação é apresentada e discutida, com base em algumas aplicações com diferentes características. / Grid computing and peer-to-peer computing emerged as distinct areas with different purposes, models and tools. Over the last years, these areas has been converging since the infrastructure and the execution model used in peer-to-peer networks have proven to be a suitable way to treat some problems related to the maintenance of large scale grids, such as scalability, monitoring, and resource discovery and allocation. The MultiCluster model addresses the convergence of grids and peer-to-peer networks in a more restricted way: the problems related to scalability, resource allocation and discovery are minimized by considering only local resources for the conception of a small scale grid, which can be used to run applications with different characteristics of granularity and communication. This work presents the MultiCluster architecture and its functional aspects, as well as a first implementation carried out by adapting the DECK programming library to use JXTA protocols and its consequent evaluation, based on applications with different characteristics.

Em vista da maior complexidade da programação paralela e distribuída em relação à programação de ambientes centralizados, novas ferramentas vêm sendo construídas com o objetivo de auxiliar o programador desses ambientes a desempenhar sua tarefa de formas mais eficazes e produtivas. Uma das ferramentas que há algum tempo tem sido usada na programação centralizada e aos poucos está sendo empregada também na programação concorrente é a programação visual. A programação visual se vale da presença de elementos visuais na especificação dos programas como peças chaves do processo de desenvolvimento de software. No caso específico da programação concorrente, a programação visual é especialmente útil pela capacidade que os gráficos têm de representar de forma mais adequada estruturas bidimensionais. Um programa concorrente, por relacionar no espaço diversos elementos com seus próprios fluxos de execução, faz surgir duas dimensões de análise que são mais difíceis de serem observadas através de programas textuais. Atualmente existem ferramentas de programação visual paralela e distribuída, mas a ênfase é dada na programação paralela, sem muita atenção a aplicações de sistemas abertos ou cliente-servidor. Além disso, tais ferramentas sofrem da falta de apoio à engenharia do software. Considerando essas deficiências, este trabalho apresenta uma ferramenta de programação visual para o desenvolvimento de aplicações compostas por objetos distribuídos que ofereça também a possibilidade de aplicar os principais conceitos da engenharia de software, como reutilização e orientação a objeto. Nesta ferramenta, o programador especifica de maneira visual a estrutura do seu programa, insere o código textual para a lógica da aplicação e o ambiente se encarrega do tratamento da distribuição e da comunicação de mais baixo nível. A aplicação é representada como um grafo dirigido, onde os nodos representam os objetos distribuídos e os arcos indicam os relacionamentos existentes entre esses objetos. A especificação dos programas é modular, baseando-se na reunião de componentes reutilizáveis, o que torna o sistema altamente configurável e extensível. Tanto a implementação da ferramenta quanto o código das aplicações geradas usam a linguagem de programação Java. A linguagem de programação visual projetada não especifica detalhes a respeito de como irá funcionar a comunicação e distribuição dos objetos. Portanto, foram implementados componentes para comunicação e outros recursos de programação distribuída, como locks e dados globais para serem usados nas aplicações. Para validar os principais objetivos da ferramenta, foram implementados alguns exemplos de aplicações distribuídas, como um pequeno sistema de bate-papo.

As grades computacionais e as redes peer-to-peer (P2P) surgiram como áreas distintas, com diferentes propósitos, modelos e ferramentas. No decorrer dos últimos anos, estas áreas foram convergindo, uma vez que a infraestrutura e o modelo de execução descentralizada das redes P2P provaram ser uma alternativa adequada para o tratamento de questões relacionadas à manutenção de grades de larga escala, tais como escalabilidade, descoberta, alocação e monitoramento de recursos. O modelo MultiCluster trata a convergência entre grades computacionais e redes peer-to-peer de uma forma mais restrita: os problemas de escalabilidade, de descoberta e alocação de recursos são minimizados considerando-se apenas recursos localmente disponíveis para a construção de uma grade, a qual pode ser usada para a execução de aplicações com diferentes características de acoplamento e comunicação. Esse trabalho apresenta a arquitetura do modelo e seus aspectos funcionais, bem como um primeira implementação do modelo, realizada através da adaptação da biblioteca de programação DECK sobre os protocolos do projeto JXTA. A avaliação do funcionamento dessa implementação é apresentada e discutida, com base em algumas aplicações com diferentes características. / Grid computing and peer-to-peer computing emerged as distinct areas with different purposes, models and tools. Over the last years, these areas has been converging since the infrastructure and the execution model used in peer-to-peer networks have proven to be a suitable way to treat some problems related to the maintenance of large scale grids, such as scalability, monitoring, and resource discovery and allocation. The MultiCluster model addresses the convergence of grids and peer-to-peer networks in a more restricted way: the problems related to scalability, resource allocation and discovery are minimized by considering only local resources for the conception of a small scale grid, which can be used to run applications with different characteristics of granularity and communication. This work presents the MultiCluster architecture and its functional aspects, as well as a first implementation carried out by adapting the DECK programming library to use JXTA protocols and its consequent evaluation, based on applications with different characteristics.

O advento dos computadores pessoais e posteriormente das estações de trabalho, somado ao desenvolvimento de hardware de comunicação eficiente e de baixo custo, levou a popularização das redes locais. Entretanto, o software não presenciou o mesmo desenvolvimento do hardware, especialmente devido a complexidade dos sistemas distribuídos. A heterogeneidade das máquinas, sistemas e redes, inerente aos ambientes computacionais modernos, restringe igualmente a integração e cooperação entre os nodos disponíveis. 0 objetivo do presente trabalho é, a partir da análise dos principais aspectos relacionados à distribuição e à heterogeneidade, desenvolver um sistema operacional de rede heterogêneo. Tal sistema, denominado HetNOS (de Heterogeneous Network Operating System), permite o desenvolvimento e validação de aplicações distribuídas homogêneas e heterogêneas de forma rápida e fácil. Os usuários podem concentrar-se nos aspectos de distribuição dos algoritmos, abstraindo detalhes dos mecanismos de comunicação, pois a programação de aplicações distribuídas é baseada em uma plataforma de interface homogênea, fácil de usar e com independência de localidade. Sendo um sistema operacional de rede, o HetNOS atua sobre o conjunto de sistemas operacionais nativos existentes; o ambiente de trabalho e estendido e não substituído. Não há entidades nem informações centralizadas, e os algoritmos são distribuídos, usualmente resultando maior confiabilidade e desempenho. A topologia do sistema é um anel lógico, esquema justificado pela generalidade de tal configuração e pela simplificação do projeto do núcleo distribuído do HetNOS. O paradigma de comunicação entre módulos e a troca de mensagens, mecanismo implementado sobre a interface de programação em rede sockets. Não há compartilhamento de memória em nenhuma instância, tornando o sistema mais legível, manutenível e portável. A interpelação entre módulos fica restrita à interface de mensagens definidas e aceitas por cada módulo. A arquitetura do HetNOS é estruturada e distribuída, pois o sistema é composto de camadas hierárquicas subdivididas em módulos, estes implementados com processos. O nível 1 corresponde ao conjunto de núcleos de sistemas operacionais nativos suportados, sobre o qual é implementado o núcleo distribuído heterogêneo do HetNOS, a DCL (Distributed Computing Layer). O principal serviço fornecido pela DCL (executada no nível 2), é um subsistema de troca de mensagens canônico e independente de localidade. Processos servidores e de usuários podem utilizar as mais variadas formas de comunicação por mensagens, tal como envio, recepção e propagação de mensagens síncronas, assíncronas, bloqueantes e não bloqueantes. No nível 3 estão os servidores do sistema, que estendem e implementam de forma distribuída a funcionalidade do sistema nativo. O Servidor de Nomes é o repositório global de dados, servindo a processos do sistema e de usuários. O Servidor de Autorização implementa o esquema de controle no acesso a recursos do sistema. O Servidor de Tipos permite que aplicações copiem dados estruturados de forma independente de localidade e de arquitetura. Por fim, o Servidor de Arquivos estende os serviços (de arquivos) locais de forma a integrá-los em um único domínio (espaço). No nível 4, arquiteturas e sistemas operacionais são emulados por módulos interpretadores (denominados Emulators). Aplicações de usuários estão espalhadas dos níveis 2 a 5; a camada varia com o tipo de aplicação. Para demonstrar a viabilidade do sistema, implementou-se a estrutura fundamental do HetNOS, incluindo a DCL (um núcleo distribuído heterogêneo), a versões básicas dos módulos servidores, as bibliotecas de procedimentos, além de diversos tipos de aplicações. O sistema conta hoje com mais de 25.000 linhas de código fonte C em mais de 100 arquivos. O desempenho do subsistema de comunicação implementado pela DCL (em avaliações com diferentes configurações de hardware) superou as expectativas iniciais, mas ainda está muito aquém do necessário a aplicações distribuídas. Segundo o que indicam as primeiras experiências realizadas, o HetNOS será bastante útil na prototipação e avaliação de modelos distribuídos, assim como na programação de software distribuído homogêneo e heterogêneo. Projetos de pesquisa do CPGCC envolvendo sistemas distribuídos (p.ex., tolerância a falhas e simulações) podem utilizar o HetNOS como ferramenta para implementação e validação de seus modelos. Futuramente, aplicações distribuídas e paralelas de maior porte poderão ser programadas, como sistemas de gerencia de bases de dados distribuídas, simuladores e sistemas de controle para automação industrial. / The advent of personal computers and, later, of workstations, along with the development of efficient and low-cost communication hardware has led to the popularization of local-area networks. However, distributed software did not experiment the same development of hardware, specially due to the complexity of distributed systems. The machine, system and communication network heterogeneity, inherent to the modern computing environments, is also responsible for the lack of integration and cooperation of available nodes. The purpose of this work is, from the analysis of the main aspects related to distribution and heterogeneity, to design a heterogeneous network operating system. Such system, named HetNOS (which stands for Heterogeneous Network Operating System), allows users to quickly write and validate distributed homogeneous and heterogeneous applications. Users can concentrate their work in the distributed aspects, abstracting communication mechanisms' details, because programming of distributed applications is based on a homogeneous interface platform, easy to use and location-independent. Being a network operating system, HetNOS acts over the set of native operating systems; the environment is extended instead of substituted. There are neither centralized information nor entities, and the algorithms are always distributed, usually yielding more reliability and performance. The HetNOS topology is a logical ring, scheme adopted partly due to the generality of such configuration and partly to simplify the HetNOS distributed kernel design. The communication paradigm between modules is the message exchange, a mechanism implemented over the sockets network application programming interface. There is no shared memory at all, making the system clearer, more manutible and portable. The interrelation between modules is restricted to the message interface defined and accepted by a module. The HetNOS architecture is structured and distributed, as the system is composed of hierarchical layers divided into modules, which in their turn are realized as processes. The layer 1 is the set of native operating system kernels, over which is implemented the distributed heterogeneous HetNOS kernel, namely DCL (states for Distributed Computing Layer). The main service provided by DCL (in layer 2) is a canonical, location-independent, message exchange mechanism. Server and user processes may use multiple forms of message primitives, such as synchronous, asynchronous, blocking and non-blocking send and receive. In the layer 3 are the system servers, which extend and implement in a distributed way the functionality of native systems. The name server is a global data repository, serving other system and user processes. The authorization server implements the security scheme to control the access to the system resources. The type server allows applications to transfer structured data independently of location and architecture. Finally, the file server extends the local (file) services to integrate them into a unique domain (space). In the layer 4, architectures and operating systems are emulated by interpreter modules (named Emulators). User applications are spread over the layers 2 to 5, depending on the application type. In order to prove the system viability, the fundamental HetNOS structure has been implemented, including its distributed heterogeneous kernel, the base of server modules, the procedure libraries, and several types of applications. The system source code has over 25,000 lines of C programming distributed over a hundred files. Although the optimization is an endless process, the performance of the DCL communication subsystem (evaluated using a few different hardware configurations) overestimated initial predictions, but is weak if considered the requirements to distributed processing. Accordingly to the first experiences made, HetNOS will be of great value to evaluate and prototype distributed models, as well as to the programming of homogeneous and heterogeneous distributed software. Local research projects involving distributed systems (e.g., fault tolerance and simulations) may use HetNOS as a tool to validate and implement their models. In the future, more complex distributed and parallel applications will be programmed, such as a distributed database management system, simulators and factory automation control systems.

As grades computacionais e as redes peer-to-peer (P2P) surgiram como áreas distintas, com diferentes propósitos, modelos e ferramentas. No decorrer dos últimos anos, estas áreas foram convergindo, uma vez que a infraestrutura e o modelo de execução descentralizada das redes P2P provaram ser uma alternativa adequada para o tratamento de questões relacionadas à manutenção de grades de larga escala, tais como escalabilidade, descoberta, alocação e monitoramento de recursos. O modelo MultiCluster trata a convergência entre grades computacionais e redes peer-to-peer de uma forma mais restrita: os problemas de escalabilidade, de descoberta e alocação de recursos são minimizados considerando-se apenas recursos localmente disponíveis para a construção de uma grade, a qual pode ser usada para a execução de aplicações com diferentes características de acoplamento e comunicação. Esse trabalho apresenta a arquitetura do modelo e seus aspectos funcionais, bem como um primeira implementação do modelo, realizada através da adaptação da biblioteca de programação DECK sobre os protocolos do projeto JXTA. A avaliação do funcionamento dessa implementação é apresentada e discutida, com base em algumas aplicações com diferentes características. / Grid computing and peer-to-peer computing emerged as distinct areas with different purposes, models and tools. Over the last years, these areas has been converging since the infrastructure and the execution model used in peer-to-peer networks have proven to be a suitable way to treat some problems related to the maintenance of large scale grids, such as scalability, monitoring, and resource discovery and allocation. The MultiCluster model addresses the convergence of grids and peer-to-peer networks in a more restricted way: the problems related to scalability, resource allocation and discovery are minimized by considering only local resources for the conception of a small scale grid, which can be used to run applications with different characteristics of granularity and communication. This work presents the MultiCluster architecture and its functional aspects, as well as a first implementation carried out by adapting the DECK programming library to use JXTA protocols and its consequent evaluation, based on applications with different characteristics.

O advento dos computadores pessoais e posteriormente das estações de trabalho, somado ao desenvolvimento de hardware de comunicação eficiente e de baixo custo, levou a popularização das redes locais. Entretanto, o software não presenciou o mesmo desenvolvimento do hardware, especialmente devido a complexidade dos sistemas distribuídos. A heterogeneidade das máquinas, sistemas e redes, inerente aos ambientes computacionais modernos, restringe igualmente a integração e cooperação entre os nodos disponíveis. 0 objetivo do presente trabalho é, a partir da análise dos principais aspectos relacionados à distribuição e à heterogeneidade, desenvolver um sistema operacional de rede heterogêneo. Tal sistema, denominado HetNOS (de Heterogeneous Network Operating System), permite o desenvolvimento e validação de aplicações distribuídas homogêneas e heterogêneas de forma rápida e fácil. Os usuários podem concentrar-se nos aspectos de distribuição dos algoritmos, abstraindo detalhes dos mecanismos de comunicação, pois a programação de aplicações distribuídas é baseada em uma plataforma de interface homogênea, fácil de usar e com independência de localidade. Sendo um sistema operacional de rede, o HetNOS atua sobre o conjunto de sistemas operacionais nativos existentes; o ambiente de trabalho e estendido e não substituído. Não há entidades nem informações centralizadas, e os algoritmos são distribuídos, usualmente resultando maior confiabilidade e desempenho. A topologia do sistema é um anel lógico, esquema justificado pela generalidade de tal configuração e pela simplificação do projeto do núcleo distribuído do HetNOS. O paradigma de comunicação entre módulos e a troca de mensagens, mecanismo implementado sobre a interface de programação em rede sockets. Não há compartilhamento de memória em nenhuma instância, tornando o sistema mais legível, manutenível e portável. A interpelação entre módulos fica restrita à interface de mensagens definidas e aceitas por cada módulo. A arquitetura do HetNOS é estruturada e distribuída, pois o sistema é composto de camadas hierárquicas subdivididas em módulos, estes implementados com processos. O nível 1 corresponde ao conjunto de núcleos de sistemas operacionais nativos suportados, sobre o qual é implementado o núcleo distribuído heterogêneo do HetNOS, a DCL (Distributed Computing Layer). O principal serviço fornecido pela DCL (executada no nível 2), é um subsistema de troca de mensagens canônico e independente de localidade. Processos servidores e de usuários podem utilizar as mais variadas formas de comunicação por mensagens, tal como envio, recepção e propagação de mensagens síncronas, assíncronas, bloqueantes e não bloqueantes. No nível 3 estão os servidores do sistema, que estendem e implementam de forma distribuída a funcionalidade do sistema nativo. O Servidor de Nomes é o repositório global de dados, servindo a processos do sistema e de usuários. O Servidor de Autorização implementa o esquema de controle no acesso a recursos do sistema. O Servidor de Tipos permite que aplicações copiem dados estruturados de forma independente de localidade e de arquitetura. Por fim, o Servidor de Arquivos estende os serviços (de arquivos) locais de forma a integrá-los em um único domínio (espaço). No nível 4, arquiteturas e sistemas operacionais são emulados por módulos interpretadores (denominados Emulators). Aplicações de usuários estão espalhadas dos níveis 2 a 5; a camada varia com o tipo de aplicação. Para demonstrar a viabilidade do sistema, implementou-se a estrutura fundamental do HetNOS, incluindo a DCL (um núcleo distribuído heterogêneo), a versões básicas dos módulos servidores, as bibliotecas de procedimentos, além de diversos tipos de aplicações. O sistema conta hoje com mais de 25.000 linhas de código fonte C em mais de 100 arquivos. O desempenho do subsistema de comunicação implementado pela DCL (em avaliações com diferentes configurações de hardware) superou as expectativas iniciais, mas ainda está muito aquém do necessário a aplicações distribuídas. Segundo o que indicam as primeiras experiências realizadas, o HetNOS será bastante útil na prototipação e avaliação de modelos distribuídos, assim como na programação de software distribuído homogêneo e heterogêneo. Projetos de pesquisa do CPGCC envolvendo sistemas distribuídos (p.ex., tolerância a falhas e simulações) podem utilizar o HetNOS como ferramenta para implementação e validação de seus modelos. Futuramente, aplicações distribuídas e paralelas de maior porte poderão ser programadas, como sistemas de gerencia de bases de dados distribuídas, simuladores e sistemas de controle para automação industrial. / The advent of personal computers and, later, of workstations, along with the development of efficient and low-cost communication hardware has led to the popularization of local-area networks. However, distributed software did not experiment the same development of hardware, specially due to the complexity of distributed systems. The machine, system and communication network heterogeneity, inherent to the modern computing environments, is also responsible for the lack of integration and cooperation of available nodes. The purpose of this work is, from the analysis of the main aspects related to distribution and heterogeneity, to design a heterogeneous network operating system. Such system, named HetNOS (which stands for Heterogeneous Network Operating System), allows users to quickly write and validate distributed homogeneous and heterogeneous applications. Users can concentrate their work in the distributed aspects, abstracting communication mechanisms' details, because programming of distributed applications is based on a homogeneous interface platform, easy to use and location-independent. Being a network operating system, HetNOS acts over the set of native operating systems; the environment is extended instead of substituted. There are neither centralized information nor entities, and the algorithms are always distributed, usually yielding more reliability and performance. The HetNOS topology is a logical ring, scheme adopted partly due to the generality of such configuration and partly to simplify the HetNOS distributed kernel design. The communication paradigm between modules is the message exchange, a mechanism implemented over the sockets network application programming interface. There is no shared memory at all, making the system clearer, more manutible and portable. The interrelation between modules is restricted to the message interface defined and accepted by a module. The HetNOS architecture is structured and distributed, as the system is composed of hierarchical layers divided into modules, which in their turn are realized as processes. The layer 1 is the set of native operating system kernels, over which is implemented the distributed heterogeneous HetNOS kernel, namely DCL (states for Distributed Computing Layer). The main service provided by DCL (in layer 2) is a canonical, location-independent, message exchange mechanism. Server and user processes may use multiple forms of message primitives, such as synchronous, asynchronous, blocking and non-blocking send and receive. In the layer 3 are the system servers, which extend and implement in a distributed way the functionality of native systems. The name server is a global data repository, serving other system and user processes. The authorization server implements the security scheme to control the access to the system resources. The type server allows applications to transfer structured data independently of location and architecture. Finally, the file server extends the local (file) services to integrate them into a unique domain (space). In the layer 4, architectures and operating systems are emulated by interpreter modules (named Emulators). User applications are spread over the layers 2 to 5, depending on the application type. In order to prove the system viability, the fundamental HetNOS structure has been implemented, including its distributed heterogeneous kernel, the base of server modules, the procedure libraries, and several types of applications. The system source code has over 25,000 lines of C programming distributed over a hundred files. Although the optimization is an endless process, the performance of the DCL communication subsystem (evaluated using a few different hardware configurations) overestimated initial predictions, but is weak if considered the requirements to distributed processing. Accordingly to the first experiences made, HetNOS will be of great value to evaluate and prototype distributed models, as well as to the programming of homogeneous and heterogeneous distributed software. Local research projects involving distributed systems (e.g., fault tolerance and simulations) may use HetNOS as a tool to validate and implement their models. In the future, more complex distributed and parallel applications will be programmed, such as a distributed database management system, simulators and factory automation control systems.