Existe una creciente demanda de sistemas online, especial-mente de aquellos que requieren procesamiento de informa-ción. Esta demanda sumada a las nuevas tecnologías de monitoreo (como por ejemplo las redes de sensores) impulsaron un nuevo tipo de aplicación que requiere bajas latencias y procesamiento continuo de grandes volúmenes de datos (los cuales arriban en forma de streams). El proce-samiento de streams constituye un paradigma de cómputo relacionado con SIMD que permite que algunos tipos de apli-caciones puedan explotar una forma de procesamiento para-lelo y puede emplearse en diferentes dominios, como por e-jemplo para la implementación de sistemas financieros, moni-toreo basado en sensores, sistemas militares, monitoreo de red, etc. Si bien los sistemas de gestión de bases de datos (DBMS) pueden utilizarse para implementar este tipo de apli-caciones, las restricciones de bajas latencias de procesa-miento y grandes volúmenes de datos a procesar los vuelve inadecuados. Una mejor alternativa son los sistemas de ges-tión de streams de datos, usualmente sistemas distribuidos de gestión de streams de datos (DSMS por su sigla en inglés) de-bido a que estas aplicaciones son inherentemente distribuidas y por lo tanto las soluciones distribuidas son naturales y proveen mejoras en cuanto a escalabilidad y performance. Esta tesis se enfoca en dos aspectos desafiantes pertenecien-tes al campo de los sistemas distribuidos en general y al de los DSMS en particular: (1) tolerancia a fallas capaz de re-sistir fallas a nivel de nodos y de red y (2) gestión de carga en sistemas federados. Nuestro enfoque al problema de la to-lerancia a fallas se basa en replicación capaz de enmascarar tanto las fallas a nivel de los nodos como a nivel de las redes. Nuestroprotocolo, denominado Disponibilidad y Consistencia Ajustable a las Aplicaciones (DCAA) puede manejar adecua-damente la relación entre disponibilidad y consistencia, man-teniendo (si es posible) la disponibilidad especificada por el usuario o la aplicación, pero produciendo (eventualmente) los resultados correctos. Al mismo tiempo, DCAA también trata de producir el menor número de resultados incorrectos (impre-cisos) que luego deberían requerir corrección. La principal diferencia entre DCAA y enfoques previos sobre tolerancia a fallas en el campo de los DSMS es que DCAA soporta al mismo tiempo diferentes restricciones en las aplicaciones, esto quiere decir que cada aplicación puede potencialmente tener distintas preferencias de disponibilidad y consistencia. Por otro lado presentaremos un nuevo protocolo de gestion de carga denominado Mecanismo de Precio Acotado (MPA), el cual permite que nodos autonomos (participantes colabora-tivos) compartan su carga sin la necesidad de contar con recursos suficientes para la operación durante picos de carga. MPA es un protocolo basado en contratos donde cada nodo practica una negociación offline y los participantes migran carga en tiempo de ejecución únicamente a nodos (pares) con los cuales mantienen un contrato (y pagan mutuamente de acuerdo al precio contratado). Este protocolo de gestión de carga ofrece incentivos que promueven la participación de los nodos y produce una buena distribución de carga (a nivel global del sistema). Los aportes mas importantes de nuestro enfoque por sobre trabajos previos basados en economías de cómputo son su estabilidad, predecibilidad, baja carga de procesamiento, privacidad y promoción de relaciones entre participantes, posibilitando que los mismos pueden crear y explotar estas relaciones privilegiadas. El protocolo MPA es general y por lo tanto puede utilizarse para la gestión de carga de cualquier entorno federado y no sólo bajo DSMS. Más aún, este nuevo protocolo de gestión de carga debe no sólo traba-jar en los típicos entornos colaborativos sino que también debe ser capaz de solucionar escenarios más reales, donde cada nodo (probablemente parte de diferentes organizaciones autónomas) juega bajo distintas reglas, tratando de maximi-zar su propia ganancia sin cooperar necesariamente con sus pares. Además de los modelos económicos existen varios tra-bjos basados en SLA (Service Level Agreements) para solucio-nar el problema de la gestión de carga cuando el entorno no es colaborativo. Mostraremos que los modelos SLA no proveen una solucion completa y que los acuerdos entre pares usual-mente proveen mejores resultados. Si bien esta tesis parece tener dos focos en lugar de uno, es importante notar que ata-caremos especialmente el problema de la gestión de carga en sistemas distribuidos federados. La relación entre este enfo-que y la tolerancia a fallas radica en los contratos negocia-dos: además de precio y tareas (carga), los contratos pueden incluir disponibilidad, característica que vuelve especialmente importante la tolerancia a fallas. / There is an increased demand for online systems,especially those requiring information processing. This demand added to new monitoring technologies (like sensors networks) have motivated a new type of application that requires low latency and continuous processing of large volumes of data (arriving as streams). Stream processing is a computer programming paradigm, related to SIMD, that allows some applications to more easily exploit a form of parallel pro-cessing and it can be employed in many different domains, such as financial systems, sensor based monitoring, milita-ry systems, network monitoring, etc. Even when traditional database management systems (DBMS) can be used to handle these applications, the low latency and high volume pro-cessing constrains make them not suitable. A much better alternative are the data stream management systems, usually distributed data stream management systems (DSMS) because these are inherently distributed applications so distributed solutions are natural and providers of scalabi-lity and performance improvements. This thesis focuses on two challenges faced by distributed systems in general and DSMS in particular: (1) fault tolerance able to resist node and network failures and (2) load management in fede-rated systems. The fault tolerance approach is based on re-plication and our protocol can resist most node and net-work failures. It is called Disponibilidad y Consistencia Ajustable a las Aplicaciones (DCAA) and addresses the availability/consistency relation by maintaining (if possi-ble), the availability specified by the user or the appli-cation but (eventually) producing correct results. At the same time, DCAA also attempts to produce the minimum number of incorrect (inaccurate) results that will need correction. The main difference of DCAA over previous approaches for fault tolerance in DSMS is that DCAA supports at the same time different application constrains, this means that each application can potentially choose a different preference of availability and consistency. Our load management protocol, called Mecanismo de Precio Acota-do (MPA) enable autonomous nodes (collaborative participa-nts) to share their load without having the required re-sources for peak load work. MPA is a contract based proto-col where nodes practice an offline negotiation and parti-cipants migrate load at execution time only to peers with whom they hold a contract (and pay each other according to the contracted price). This load management protocol offers incentives that promote participation and produces a good (system wide level) load distribution. The key differences of our approach over previous works based on computational economies are its stability, predictability, lightweight, privacy, and promotion of the relationships among participants, enabling them to create and exploit these privileged relationships. The MPA protocol is gene-ral, so it can be used to manage load in any federated en-vironment, and not only DSMS. Moreover, this new load ma-nagement protocol should not only work under the typical collaborative environment, but also should be able to address the more realistic scenery where each node (proba-bly part of different and autonomous organizations) plays under different rules trying to maximize their own gain, without necessarily cooperating with their partners. Besi-des economic models there are various works based on SLA (service level agreements) to solve the load management problem when the environment is not a collaborative one. We will show that SLA models do not provide a complete solution and that peer agreements usually provide better results. Although this thesis seems to have two focuses instead of one, it is important to notice that we espe-cially address the load management problem under federated distributed systems. The relation among this focus and fault tolerance is in the negotiated contracts: besides price and tasks (load), contracts can include availability, which raises the importance of fault tolerance.

[pt] Neste trabalho defenderemos a tese de que funções e continuações como valores de primeira classe constituem uma boa base para construção de abstrações que se beneficiem do comportamento assíncrono da programação distribuída orientada a eventos.Propomos e desenvolvemos o sistema ORFEO, baseado na linguagem LUA 34, que atribui às funções remotas o mesmo status de primeira classe de funções locais.O sistema também possui a propriedade de tratar continuações como valores de primeira classe, permitindo capturar o que resta a ser executado do processamento de um evento.A aplicação dessas duas propriedades, funções remotas e continuações como valores de primeira classe, em um contexto de comunicação por eventos permite que um desenvolvedor possa construir abstrações de objetos distribuídos e de sincronização sem precisar de primitivas especiais no sistema.O resultado une a expressividade de uma linguagem procedural de técnicas funcionais e mecanismos de extensão presentes na linguagem LUA.

O trabalho em torno do sistema TRIX visa desenvolver um sistema operacional multiprocessado experimental, para servir de base a futuros trabalhos de pesquisa em sistemas operacionais e processamento paralelo. Como características essenciais do sistema tem-se simplicidade, desempenho e compatibilidade com UNIX. Com o sistema operando em vários processadores, pode-se fazer experiências de muitos tipos em processamento paralelo, como por exemplo, ensaios de distribuição de carga, avaliações de desempenho, implementação de linguagens paralelas ou distribuídas, ,bancos de dados, sistemas dedicados, etc. Ao construir o sistema TRIX, decidiu-se usar o código fonte de um sistema já pronto e funcionando, para encurtar o tempo de desenvolvimento. Optou-se pelo MINIX, que é um sistema bem estruturado, dividido em camadas de processos seqüenciais que se comunicam por troca de mensagens. Mais que isso, 0 MEND( a compatível com o UNIX versão 7 e o seu c6digo fonte pode ser usado para fins acadêmicos sem ferir o seu Copyright. Foi necessário porem dotar o MINIX de características distribuídas, para o controle de uma arquitetura multiprocessada. projeto e implementação destas características é o assunto deste trabalho. Inicialmente são avaliados os sistemas operacionais multiprocessados encontrados na literatura, de maneira a auxiliar no projeto do TRIX. Entre os detalhes estudados estão as diferenças entre sistemas paralelos e distribuídos, a comunicação entre seus processos e sua forma de distribuição. São apresentados os microprocessadores do tipo transputer, com seus mecanismos de criação e comunicação de processos implementados em hardware. Também é detalhado o sistema operacional MINIX, com sua construção em camadas, com processos servidores e clientes e suas estruturas de controle. 0 sistema foi projetado tentando maximizar a sua flexibilidade, escalabilidade e disponibilidade e minimizar sua complexidade. Os processos servidores são divididos de forma fixa, controlando as funções de memória localmente e as funções de arquivos remotamente. Os processos de usuário são distribuídos tentando se equalizar a taxa de ocupação dos processadores do sistema. E implementado um mecanismo de identificação global de processos juntamente com um método transparente de comunicação. Isso é feito junto com a criação de um driver suplementar ao sistema, responsável pela comunicação entre processos de processadores distintos. O núcleo original do MINIX recebeu uma serie de alterações para suportar as características distribuídas do novo sistema, de maneira a identificar processos locais e remotos. Foram extraídas do núcleo as funções executadas pelo escalonador em hardware do transputer. Foram inseridas algumas funções novas para tratar de algumas idiosincrasias do transputer, como por exemplo, sua falta de gerencia de memória. Finalmente, foi criado um mecanismo distribuído para controlar a arvore de processos do sistema, mantendo a semântica do UNIX. A escolha do processador para a execução de novos processos 6 feita pelo processador que o estiver criando, através de informações recebidas sobre processadores menos ocupados que estiverem mais próximos. / The TIUX system has been defined as an experimental operating system, to be used in future research on operating systems and parallel processing. The essential characteristics of the system are simplicity, performance and uNix compatibility. With the system running on several processors, several topics can be studied, such as load balancing, performance evaluation, implementation of distributed or parallel programming languages, distributed data bases and embedded systems. While designing the TRix system, it was decided to use the source code of an existing system, to shorten the development time. MINIX was chosen, because it is a well structured system, divided into layers of sequential processes, which communicate via messages. MINIX is compatible with UNIX version 7 and its source code can be used for academic purposes without any copyright infringiment. It had to be extended to control a multiprocessor architecture. The implementation of these characteristics is the main subject of this work. Initially some existing multiprocessor operating systems are evaluated, in order to guide in the development of TRIX. The studied issues are differences between parallel and distributed systems, interprocess communication features and the process distribution policy. The transputer microprocessors are presented, with their hardware implemented devices for process creation and communication. The MINIX operating system layered structure is described, with client and server processes and their control structures. The system is projected as an attempt to maximize flexibility, scalability and availability and to minimize complexity. The server processes are distributed in a fixed layout, controlling the memory and processes locally, and the files remotely. The user processes are distributed with load balancing among the processors. Global identification and transparent communication are implemented. This is achieved with an additional device driver, responsible for communication between processes running on different processors. The original MINIX kernel was changed to support the new distributed features of the system, identifying processes globally. The scheduler functions were stripped off, as they are now performed by the transputer hardware. Some functions were inserted to deal with some transputer problems, as for example, the lack of a memory management unit. Finally, a mechanism to control the global system process tree was created, maintaning strict UNIX semantics. The choice of which processor will hold a newly created process is made by the processor creating it, based on information received about the nearer processor with a low load.

O trabalho em torno do sistema TRIX visa desenvolver um sistema operacional multiprocessado experimental, para servir de base a futuros trabalhos de pesquisa em sistemas operacionais e processamento paralelo. Como características essenciais do sistema tem-se simplicidade, desempenho e compatibilidade com UNIX. Com o sistema operando em vários processadores, pode-se fazer experiências de muitos tipos em processamento paralelo, como por exemplo, ensaios de distribuição de carga, avaliações de desempenho, implementação de linguagens paralelas ou distribuídas, ,bancos de dados, sistemas dedicados, etc. Ao construir o sistema TRIX, decidiu-se usar o código fonte de um sistema já pronto e funcionando, para encurtar o tempo de desenvolvimento. Optou-se pelo MINIX, que é um sistema bem estruturado, dividido em camadas de processos seqüenciais que se comunicam por troca de mensagens. Mais que isso, 0 MEND( a compatível com o UNIX versão 7 e o seu c6digo fonte pode ser usado para fins acadêmicos sem ferir o seu Copyright. Foi necessário porem dotar o MINIX de características distribuídas, para o controle de uma arquitetura multiprocessada. projeto e implementação destas características é o assunto deste trabalho. Inicialmente são avaliados os sistemas operacionais multiprocessados encontrados na literatura, de maneira a auxiliar no projeto do TRIX. Entre os detalhes estudados estão as diferenças entre sistemas paralelos e distribuídos, a comunicação entre seus processos e sua forma de distribuição. São apresentados os microprocessadores do tipo transputer, com seus mecanismos de criação e comunicação de processos implementados em hardware. Também é detalhado o sistema operacional MINIX, com sua construção em camadas, com processos servidores e clientes e suas estruturas de controle. 0 sistema foi projetado tentando maximizar a sua flexibilidade, escalabilidade e disponibilidade e minimizar sua complexidade. Os processos servidores são divididos de forma fixa, controlando as funções de memória localmente e as funções de arquivos remotamente. Os processos de usuário são distribuídos tentando se equalizar a taxa de ocupação dos processadores do sistema. E implementado um mecanismo de identificação global de processos juntamente com um método transparente de comunicação. Isso é feito junto com a criação de um driver suplementar ao sistema, responsável pela comunicação entre processos de processadores distintos. O núcleo original do MINIX recebeu uma serie de alterações para suportar as características distribuídas do novo sistema, de maneira a identificar processos locais e remotos. Foram extraídas do núcleo as funções executadas pelo escalonador em hardware do transputer. Foram inseridas algumas funções novas para tratar de algumas idiosincrasias do transputer, como por exemplo, sua falta de gerencia de memória. Finalmente, foi criado um mecanismo distribuído para controlar a arvore de processos do sistema, mantendo a semântica do UNIX. A escolha do processador para a execução de novos processos 6 feita pelo processador que o estiver criando, através de informações recebidas sobre processadores menos ocupados que estiverem mais próximos. / The TIUX system has been defined as an experimental operating system, to be used in future research on operating systems and parallel processing. The essential characteristics of the system are simplicity, performance and uNix compatibility. With the system running on several processors, several topics can be studied, such as load balancing, performance evaluation, implementation of distributed or parallel programming languages, distributed data bases and embedded systems. While designing the TRix system, it was decided to use the source code of an existing system, to shorten the development time. MINIX was chosen, because it is a well structured system, divided into layers of sequential processes, which communicate via messages. MINIX is compatible with UNIX version 7 and its source code can be used for academic purposes without any copyright infringiment. It had to be extended to control a multiprocessor architecture. The implementation of these characteristics is the main subject of this work. Initially some existing multiprocessor operating systems are evaluated, in order to guide in the development of TRIX. The studied issues are differences between parallel and distributed systems, interprocess communication features and the process distribution policy. The transputer microprocessors are presented, with their hardware implemented devices for process creation and communication. The MINIX operating system layered structure is described, with client and server processes and their control structures. The system is projected as an attempt to maximize flexibility, scalability and availability and to minimize complexity. The server processes are distributed in a fixed layout, controlling the memory and processes locally, and the files remotely. The user processes are distributed with load balancing among the processors. Global identification and transparent communication are implemented. This is achieved with an additional device driver, responsible for communication between processes running on different processors. The original MINIX kernel was changed to support the new distributed features of the system, identifying processes globally. The scheduler functions were stripped off, as they are now performed by the transputer hardware. Some functions were inserted to deal with some transputer problems, as for example, the lack of a memory management unit. Finally, a mechanism to control the global system process tree was created, maintaning strict UNIX semantics. The choice of which processor will hold a newly created process is made by the processor creating it, based on information received about the nearer processor with a low load.

O trabalho em torno do sistema TRIX visa desenvolver um sistema operacional multiprocessado experimental, para servir de base a futuros trabalhos de pesquisa em sistemas operacionais e processamento paralelo. Como características essenciais do sistema tem-se simplicidade, desempenho e compatibilidade com UNIX. Com o sistema operando em vários processadores, pode-se fazer experiências de muitos tipos em processamento paralelo, como por exemplo, ensaios de distribuição de carga, avaliações de desempenho, implementação de linguagens paralelas ou distribuídas, ,bancos de dados, sistemas dedicados, etc. Ao construir o sistema TRIX, decidiu-se usar o código fonte de um sistema já pronto e funcionando, para encurtar o tempo de desenvolvimento. Optou-se pelo MINIX, que é um sistema bem estruturado, dividido em camadas de processos seqüenciais que se comunicam por troca de mensagens. Mais que isso, 0 MEND( a compatível com o UNIX versão 7 e o seu c6digo fonte pode ser usado para fins acadêmicos sem ferir o seu Copyright. Foi necessário porem dotar o MINIX de características distribuídas, para o controle de uma arquitetura multiprocessada. projeto e implementação destas características é o assunto deste trabalho. Inicialmente são avaliados os sistemas operacionais multiprocessados encontrados na literatura, de maneira a auxiliar no projeto do TRIX. Entre os detalhes estudados estão as diferenças entre sistemas paralelos e distribuídos, a comunicação entre seus processos e sua forma de distribuição. São apresentados os microprocessadores do tipo transputer, com seus mecanismos de criação e comunicação de processos implementados em hardware. Também é detalhado o sistema operacional MINIX, com sua construção em camadas, com processos servidores e clientes e suas estruturas de controle. 0 sistema foi projetado tentando maximizar a sua flexibilidade, escalabilidade e disponibilidade e minimizar sua complexidade. Os processos servidores são divididos de forma fixa, controlando as funções de memória localmente e as funções de arquivos remotamente. Os processos de usuário são distribuídos tentando se equalizar a taxa de ocupação dos processadores do sistema. E implementado um mecanismo de identificação global de processos juntamente com um método transparente de comunicação. Isso é feito junto com a criação de um driver suplementar ao sistema, responsável pela comunicação entre processos de processadores distintos. O núcleo original do MINIX recebeu uma serie de alterações para suportar as características distribuídas do novo sistema, de maneira a identificar processos locais e remotos. Foram extraídas do núcleo as funções executadas pelo escalonador em hardware do transputer. Foram inseridas algumas funções novas para tratar de algumas idiosincrasias do transputer, como por exemplo, sua falta de gerencia de memória. Finalmente, foi criado um mecanismo distribuído para controlar a arvore de processos do sistema, mantendo a semântica do UNIX. A escolha do processador para a execução de novos processos 6 feita pelo processador que o estiver criando, através de informações recebidas sobre processadores menos ocupados que estiverem mais próximos. / The TIUX system has been defined as an experimental operating system, to be used in future research on operating systems and parallel processing. The essential characteristics of the system are simplicity, performance and uNix compatibility. With the system running on several processors, several topics can be studied, such as load balancing, performance evaluation, implementation of distributed or parallel programming languages, distributed data bases and embedded systems. While designing the TRix system, it was decided to use the source code of an existing system, to shorten the development time. MINIX was chosen, because it is a well structured system, divided into layers of sequential processes, which communicate via messages. MINIX is compatible with UNIX version 7 and its source code can be used for academic purposes without any copyright infringiment. It had to be extended to control a multiprocessor architecture. The implementation of these characteristics is the main subject of this work. Initially some existing multiprocessor operating systems are evaluated, in order to guide in the development of TRIX. The studied issues are differences between parallel and distributed systems, interprocess communication features and the process distribution policy. The transputer microprocessors are presented, with their hardware implemented devices for process creation and communication. The MINIX operating system layered structure is described, with client and server processes and their control structures. The system is projected as an attempt to maximize flexibility, scalability and availability and to minimize complexity. The server processes are distributed in a fixed layout, controlling the memory and processes locally, and the files remotely. The user processes are distributed with load balancing among the processors. Global identification and transparent communication are implemented. This is achieved with an additional device driver, responsible for communication between processes running on different processors. The original MINIX kernel was changed to support the new distributed features of the system, identifying processes globally. The scheduler functions were stripped off, as they are now performed by the transputer hardware. Some functions were inserted to deal with some transputer problems, as for example, the lack of a memory management unit. Finally, a mechanism to control the global system process tree was created, maintaning strict UNIX semantics. The choice of which processor will hold a newly created process is made by the processor creating it, based on information received about the nearer processor with a low load.

[pt] Sistemas formados por componentes distribuídos possibilitam a ocorrência de falhas provenientes da interação entre componentes. A etapa de testes desta classe de sistemas é árdua, já que prever todas as interações entre componentes de um sistema é inviável. Portanto, ainda que um sistema de componentes seja testado, a ocorrência de erros em tempo de execução continua sendo possível e, evidentemente, esses erros devem ser observados disparando alguma ação que impeça de causarem grandes danos. Este trabalho apresenta um mecanismo de identificação de erros de inconsistência semântica de tipos baseado em logs estruturados. Falhas de inconsistência semântica de tipos são falhas decorrentes da interpretação errônea de valores que são representados sintaticamente sob os mesmos tipos básicos. O mecanismo proposto consiste na geração de logs estruturados conforme a definição de interfaces de comunicação e a identificação de anomalias através de uma técnica existente de verificação de contratos. Além disso, o mecanismo propõe um modelo de gestão taxonômica de tipos semânticos utiliza a técnica de Raciocínio Baseado em Casos (RBC). O mecanismo de identificação de falhas foi implementado através de uma extensão do middleware Robot Operation System (ROS). O mecanismo, além de observar erros, gera informação complementar que visa auxiliar a diagnose da causa do erro observado. Finalmente, uma prova de conceito aplicada a um sistema de controle de locomoção de um robô híbrido, adaptado de um sistema real, foi desenvolvida para a validação da identificação de falhas. / [en] Systems formed by distributed components enable the occurrence of faults arising from the interaction between components. The stage of testing this class of systems is difficult, since foresee all interactions between components of a system is not feasible. Therefore, even if a component system is tested, the occurrence of run-time errors is still possible and, of course, these errors should be seen shooting some action that prevents them from causing major damage. This paper presents an identification mechanism of errors given by semantic inconsistency typed data, based on structured logs. Semantic inconsistency of typed data could cause failures due to the misinterpretation of values that are represented syntactically under the same basic types. The proposed mechanism consists in generating structured logs according to the definition of communication interfaces, and identifying anomalies by an existing contract verification technique. In addition, the mechanism proposes a management model of taxonomic semantic types using the Case-Based reasoning technique (CBR). The fault identification mechanism was implemented through an extension of the Robot Operation System middleware (ROS). The mechanism, in addition to observing errors, generates additional information which aims to assist the diagnosis of the cause of the observed error. Finally, a proof of concept applied to a locomotion control system for a hybrid robot, adapted from a real system, has been developed for fault identification validation.

No description available.

[pt] O desenvolvimento baseado em componentes de um tópico que tem atrasado bastante atençco nos últimos anos. Esta técnica permite a construção de sistemas de software complexos de forma rápida e estruturada. Diversos modelos de componentes já foram propostos pela indústria e pela academia. Dentro destes, aqueles que oferecem suporte da comunicação distribuída geralmente interagem através de Chamadas Remotas de Procedimentos. Dos modelos pesquisados, apenas o CORBA Component Model possui uma especificação em andamento para o suporte da comunicação através de fluxos de dados. Esse suporte se mostra de grande relevância em sistemas que precisam lidar com dados de sensores e com transmissão de áudio e vídeo. O objetivo principal deste trabalho de apresentar uma arquitetura que permita a implementação de aplicações com suporte ao fluxo de dados no middleware Software Component System (SCS). Para tal, o modelo de componentes do SCS foi estendido para oferecer portas de fluxos de dados. Como avaliação, este trabalho apresenta alguns resultados experimentais de desempenho e escalabilidade, assim como uma aplicação que exercita as necessidades do executor de fluxos de algoritmos do CSBase, um framework utilizado no desenvolvimento de sistemas para computação em grade. / [en] Component-based software development is a topic that has attracted attention in recent years. This technique allows the construction of complex software systems in a quick and structured way. Several component models have been proposed by the industry and the academy. The majority of these component models adopt Remote Procedure Calls as their basic communication mechanism. The CORBA Component Model is the only one from the surveyed models that has a work in progress to support communication over data streams. This support proves to be of great importance in systems that must deal with data from sensors and systems that deal with audio and video transmission. The main goal of this work is to propose an architecture that enables the middleware Software Component System (SCS) to support applications that require data streaming. To this end, the SCS component model was extended to support stream ports. As evaluation, this work presents some experimental results of performance and scalability, as well as an application that exercises the needs of the CSBase s algorithm ow executor, a framework used to build systems for grid computing.

Made available in DSpace on 2015-03-05T13:56:59Z (GMT). No. of bitstreams: 0 Previous issue date: 23 / Hewlett-Packard Brasil Ltda / Contabilizar e caracterizar o uso de grades computacionais constitui uma tarefa de gerenciamento indispensável, especialmente quando essas grades são usadas em larga escala, envolvendo várias instituições e participantes. As soluções de gerência de grades existentes atualmente são limitadas: (a) por se destinarem a monitorar apenas o estado dos recursos que compõem o ambiente (como consumo de memória e espaço de armazenamento em disco),omitindo dados estatísticos e históricos sobre a execução de aplicações; (b) por não oferecem suporte à coleta, ao processamento e à consolidação de informações que são geradas por diferentes tecnologias de grade; e (c) por não oferecem um esquema seletivo para a divulgação das informações gerenciais que são obtidas. Para suprir as lacunas recém mencionadas, esta dissertação propõe uma abordagem baseada em políticas para contabilização e caracterização de uso de grades computacionais compostas por sistemas heterogêneos. A abordagem proposta se materializa através de uma arquit / Accounting and characterizing the use of computational grids constitutes a management task of paramount importance, especially when they are used in large scale, involving many institutions and participants. Current grid computing management solutions are limited since they: (a) solely monitor the status of environment resources (like CPU and disk space consumption), omitting statistical and historical data about the execution of applications; (b) do not offer support for gathering, processing and consolidation of information that is generated by heterogeneous grid technologies; and (c) do not allow the specification of policies to distribute the collected information. To fullfil this gap, this work proposes an approach based on polices to account and characterize usage of grid computing infrastructures, even when such grids are formed by heterogeneous middleware. The approach is materialized through an architecture based on the Web Services Distributed Management standard. This work presents the architec

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.