COLLA: UMA PLATAFORMA COLABORATIVA PARA PROGRAMAS JAVA E JAVACÁ&LÁ

BRUNO CERQUEIRA HOTT Orientador: Joubert de Castro Lima COLLA: UMA PLATAFORMA COLABORATIVA PARA PROGRAMAS JAVA E JAVACÁ&LÁ Ouro Preto Dezembro de 2012

Universidade Federal de Ouro Preto Instituto de Ciências Exatas Bacharelado em Ciência da Computação COLLA: UMA PLATAFORMA COLABORATIVA PARA PROGRAMAS JAVA E JAVACÁ&LÁ Monograa apresentada ao Curso de Bacharelado em Ciência da Computação da Universidade Federal de Ouro Preto como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação. BRUNO CERQUEIRA HOTT Ouro Preto Dezembro de 2012

UNIVERSIDADE FEDERAL DE OURO PRETO FOLHA DE APROVAÇÃO CollA: Uma Plataforma Colaborativa para programas Java e JavaCá&Lá BRUNO CERQUEIRA HOTT Monograa defendida e aprovada pela banca examinadora constituída por: Dr. Joubert de Castro Lima Orientador Universidade Federal de Ouro Preto Ms. Felipe Santiago Martins Coimbra de Melo Universidade Federal de Ouro Preto Ms. Túlio Ângelo Machado Toffolo Universidade Federal de Ouro Preto Ouro Preto, Dezembro de 2012

Resumo Atualmente, já dispomos na literatura de vasto conjunto de middlewares que permitem especialistas a executarem suas tarefas em clusters ou grids computacionais. A ideia da computação voluntária está normalmente presente. Nela, usuários podem participar de um projeto cedendo computadores, tornando desta forma a infraestrutura computacional maior e mais propicia a obter soluções a menor custo. Infelizmente, não dispomos de uma infraestrutura computacional que permita que qualquer especialista possa ceder, porém também usar recursos compartilhados numa rede de voluntários e colaboradores. A plataforma de software denominada Collaborative Anlysis (CollA) tem como objetivo permitir que artefatos possam ser compartilhadas por diversos especialistas em diversos ambientes. Os principais artefatos da plataforma CollA são: fontes de dados, nós de processamento (incluindo processador, memória principal e secundária), componentes de software, experimentos ou apenas resultados dos experimentos. Nossa hipótese é que ao compartilhar artefatos permitimos que especialistas possam colaborar cada vez mais no processo decisório, tornando-o menos custoso, mais ágil e mais robusto. Neste trabalho foram implementados os serviços básicos da plataforma CollA, tais como chat, manutenção de usuários e grupos de usuário, serviço de compartilhamento de computadores, incluindo a possibilidade de utilização de computadores com IPs inválidos, o serviço de execução de quaisquer tarefas implementadas em Java e a integração com o middleware para desenvolvimento de aplicações paralelas ou distribuídas Java Cá&Lá. A plataforma CollA foi testada exaustivamente, onde fora realizado a submissão de tarefas por mais de oito horas consecutivas a ambientes homogêneos e heterogêneos criados com a plataforma CollA. Nos ambientes criados a plataforma chegou a gerenciar mais de trinta computadores com diferentes congurações e localizados em diferentes partes do globo. A primeira versão gratuita e livre da plataforma CollA está disponível ao público, incluindo manuais de utilização e instalação. i

Abstract There are many middleware's in the literature useful for specialists to submit tasks to a computer cluster or grid. The voluntary computing is part of such eort. Users can participate from a project by registering computers, turning the computer infrastructure bigger and therefore able to solve some hard problems with lower costs. Unfortunately, there is no platform where users can create communities and share computers, applications, simulations results, forming a network of volunteers and also collaborators. The Collaborative Platform called CollA main goal is to share artifacts with specialists in dierent communities created in CollA. CollA artifacts are: computers, data sources, applications and applications results. Our hypothesis is to enable tools and a platform where we can share, so we believe that specialists will collaborate in the decision making process, turning it less expensive, robust and faster. We have implemented the basic services of CollA, including chat, users and groups management, computers sharing, including computers with invalid IPs, and task executors. Each task can be a Java program or a JavaCá&Lá program. JavaCá&Lá is a middleware to fast prototype distributed or parallel Java applications, where you develop like your sequential Java environment. CollA platform was tested with homogeneous and heterogeneous computers. A tester application submits tasks during eight hours to CollA. CollA worked with more than 30 computers with dierent congurations and disposed at dierent locations of globe. Colla is free and public software. Software, manuals and publications can be downloaded from CollA site. ii

Dedico este trabalho à minha lha Marcela, meu bem mais precioso e fonte de perseverança. iii

Agradecimentos Agradeço primeiramente a Deus pelos dons da vida e sabedoria. Agradeço à UFOP e aos professores do DECOM pela oportunidade oferecida e pelos ensinamentos passados. Agradeço especialmente ao Prof. Joubert pelo tempo dedicado e por toda ajuda para que esse trabalho fosse realizado. E ao prof. David pela conança depositada durante minha graduação. À turma 08.1 pelos momentos e, em especial, ao Victor Hugo e Saulo Henrique pelo apoio e ajuda. Agradeço também ao Diogo, companheiro de projeto, que mesmo longe sempre me ajudou. Agradeço às repúblicas Molotov e Jóia Rara e aos meus amigos pela companhia, risadas e rocks. À toda minha família que me incentivou a buscar um futuro melhor e aos meus pais por sonhar e batalhar por esse dia. E à minha lha por ser meu maior incentivo. À Lays, minha el namorada, por todo amor, incentivo e ajuda, sem você eu já tinha desistido a muito tempo, você é essencial na minha vida. E a toda família Murta pela torcida. iv

Sumário 1 Introdução 1 1.1 Organização da Monograa............................. 2 2 Referencial Teórico 4 2.1 Arquiteturas de Computadores........................... 4 2.1.1 Memória Compartilhada........................... 4 2.1.2 Memória Distribuída............................. 4 2.2 Arquiteturas de Software............................... 6 2.2.1 Cliente/Servidor............................... 6 2.2.2 Ponto a ponto................................ 6 2.2.3 Soluções Híbridas............................... 7 3 Trabalhos Correlatos 9 3.1 Globus......................................... 9 3.2 Legion......................................... 10 3.3 MyGrid........................................ 11 3.4 Condor........................................ 12 3.5 BOINC........................................ 13 3.6 XtremWeb-CH.................................... 13 3.7 BonjourGrid...................................... 14 3.8 PastryGrid...................................... 15 3.9 SETI@home...................................... 16 4 Desenvolvimento 17 4.1 CollA Server..................................... 18 4.1.1 IPs inválidos................................. 21 4.1.2 CollA Task Executor............................. 22 4.2 CollA Host...................................... 24 4.3 CollA Client - Aplicativo Developer Viewer.................... 26 4.4 CollA Groups..................................... 27 v

4.5 CollA Chat...................................... 28 4.6 Conclusões...................................... 28 5 Experimentos 30 5.1 Ambiente Computacional dos Experimentos.................... 31 5.2 Metodologia dos Experimentos........................... 31 5.3 Resultados do experimento no ambiente homogêneo e com IPs válidos..... 32 5.4 Resultados do experimento no ambiente heterogêneo e com IPs inválidos.... 32 6 Conclusões 34 Referências Bibliográcas 50 vi

Lista de Figuras 2.1 Exemplo de uma grade de computação com clusters................. 5 2.2 Organização hierárquica de nós em uma rede de superpares............. 8 2.3 Funcionamento principal do BitTorrent........................ 8 4.1 Componentes da plataforma CollA............................ 18 4.2 Tela principal do CollA Super Server.......................... 19 4.3 Modelo de arquitetura utilizado pelo CollA...................... 20 4.4 Arquitetura do CollA Server............................... 20 4.5 Modelo de arquitetura utilizado pelo CollA para o envio de mensagens de chat entre usuários com IP inválido............................. 21 4.6 Modelo de arquitetura utilizado pelo CollA para o envio aplicações entre o cliente e o host.......................................... 23 4.7 Modelo de arquitetura utilizado pelo CollA para o envio aplicações entre o cliente e o host com IP inválido................................. 23 4.8 Tela principal do CollA Host............................... 25 4.9 Arquitetura do CollA Host............................... 25 4.10 Tela principal do CollA Developer Viewer........................ 26 4.11 Arquitetura do CollA Client............................... 27 4.12 Tela de informações do CollA Groups......................... 28 vii

Lista de Tabelas 2.1 Tipos de prováveis gargalos............................... 6 5.1 Resultados do experimento em ambiente homogêneo................. 32 5.2 Tempo médio de cada tarefa utilizada no experimento em ambiente homogêneo.. 32 5.3 Resultados do experimento em ambiente heterôgeneo................. 33 5.4 Tempo médio de cada tarefa utilizada no experimento em ambiente heterogêneo.. 33 viii

Capítulo 1 Introdução A espécie humana pode ser considerada a única que vive no presente, analisa o passado e tenta prever o futuro. Como estamos cercados de abstrações, tentamos a todo o momento predizer seus comportamentos. Existem duas alternativas cientícas para predizer o comportamento de uma abstração, seja esta uma empresa, a bolsa de valores de um país, um indivíduo de uma espécie, a Amazônia, e tantas outras. A primeira usa teorias que descrevem o comportamento da abstração sendo modelada. Normalmente, tais teorias descrevem fenômenos físicos usando matemática como linguagem. Esta alternativa é representada por abordagens orientadas por teorias (Theory-Driven Approaches). A segunda usa o comportamento passado, descrito normalmente por um grande volume de dados, para predizer o comportamento. Esta alternativa é representada por abordagens orientadas por dados (Data-Driven Approaches (Sismanis et al., 2002; Witten et al., 2005)), usadas quando teorias não existem. As abordagens orientadas por dados são divididas em abordagens orientadas por hipóteses (Hypothesis-Driven Approaches Gray et al. (1997); Harinarayan et al. (1996)) e abordagens orientadas por descobertas (Discover-Driven Approaches (Alpaydin, 2004; Langley, 1996; Mitchell, 1997; Russell, 1995)). De uma forma geral, abordagens orientadas por dados permitem identicar padrões desconhecidos, não triviais, potencialmente úteis e implícitos a partir de grandes volumes de dados. O volume de dados é uma realidade que afeta sensivelmente os recursos computacionais utilizados pelas abordagens orientadas por dados, sejam estes processamento e memória. Recentemente, a Akamai, empresa de infraestrutura de rede da qual pouca gente ouve falar, mas que é responsável por boa parte do conteúdo que chega a seu browser em qualquer dispositivo, pois serve cerca de um dos dois e meio bilhões de usuários da internet, lançou o tamanho do problema no volume de dados. Em seu relatório do primeiro trimestre de 2012 já chegamos a mais de 700 Petabytes de dados por semana, ou seja, cerca de 700 milhões de bilhões de bytes por semana. Como prover serviços de análise que suportem tamanha demanda? Ninguém ainda sabe, porém já estamos estudando e neste projeto propomos uma alternativa de solução inicial que passa pela COLABORAÇÃO. 1

1. Introdução 2 Infelizmente muito pouca pesquisa foi feita no sentido de tornar o processo de análise de dados mais colaborativo, já que o volume de dados e o número de abordagens para analisá-los tende a crescer. Partimos da hipótese de que serviços como chats, edição colaborativa, entre outros, tornam qualquer processo mais colaborativo, incluindo o processo de análise de grandes volumes de dados. De uma forma geral, existem inúmeras abordagens sendo disponibilizadas, algumas reunidas em ambientes de código aberto como o Weka (WEKA, 2012), e um número crescente de fontes de dados disponíveis para serem copiadas e analisadas individualmente por tais abordagens ou ambientes, mas até o momento quase nenhum esforço foi feito no sentido de compartilhar mais do que simplesmente fontes de dados entre especialistas. Temos também na literatura diversos middlewares que permitem criarmos clusters ou grids de computação voluntária. Nestes ambientes, aplicações ou tarefas podem ser executadas de forma similar ao CollA, assim como computadores podem ser cedidos à resolução de um problema em larga escala, porém ainda não é possível criar ambientes onde todos os usuários possam executar tarefas, ceder computadores e compartilhar fontes de dados. Devido as limitações impostas nos middlewares e a falta de uma infraestrutura simples e robusta para o desenvolvimento de aplicações para análise de dados que sejam colaborativas e distribuídas, implementamos a plataforma de software denominada Collaborative Analysis (CollA). A plataforma CollA já permite que não somente fontes de dados sejam compartilhadas, mas também que componentes de software, experimentos, resultados de experimentos e nós de processamento (incluindo memória principal, secundária e processadores) possam ser usados de forma colaborativa por diferentes especialistas em diferentes ambientes criados na plataforma. A plataforma já dispõe do serviço de chat, manutenção de usuários e grupos de usuário, serviço de compartilhamento de computadores, incluindo a possibilidade de utilização de computadores com IPs inválidos, o serviço de execução de quaisquer tarefas implementadas em Java e a integração com o middleware para desenvolvimento de aplicações paralelas ou distribuídas Java Cá&Lá(JavaCá&Lá, 2012). A plataforma CollA foi testada exaustivamente, onde fora realizado a submissão de tarefas por mais de oito horas consecutivas a ambientes homogêneos e heterogêneos criados com a plataforma CollA. Nos ambientes criados a plataforma chegou a gerenciar mais de trinta computadores com diferentes congurações e localizados em diferentes partes do globo. A primeira versão gratuita e livre da plataforma CollA está disponível ao público, incluindo manuais de utilização e instalação. 1.1 Organização da Monograa O Capítulo 2 faz uma revisão de conceitos sobre computação distribuída, abordando os modelos de arquitetura de computadores e sistemas. No Capítulo 3 são apresentados alguns trabalhos correlatos que serviram de orientação

1. Introdução 3 para o trabalho proposto. Os detalhes da arquitetura e desenvolvimento da plataforma são explicados no Capítulo 4. No Capítulo 5 são apresentados a elaboração e os resultados dos testes e os mesmos são analisados para se caracterizar o comportamento da plataforma e vericar a validade das estratégias propostas e implementadas. Por m, as conclusões são apresentadas no Capítulo 6.

Capítulo 2 Referencial Teórico 2.1 Arquiteturas de Computadores Nesta seção serão abordadas as arquiteturas de computador mais comuns, dentre estas, podemos dividi-las em arquiteturas paralelas e arquiteturas distribuídas. Arquiteturas paralelas possuem diversos elementos de processamento e um sistema de endereço único, facilitando desta forma a comunicação. Já nas arquiteturas distribuídas encontramos sistemas de endereçamento distintos e o sistema de comunicação usando obrigatoriamente uma rede de dados. 2.1.1 Memória Compartilhada Arquiteturas paralelas assumem endereçamento compartilhado entre os processos em execução, portanto não existe envio de mensagens usando redes de dados em tais arquiteturas. Normalmente, temos as máquinas multicore como exemplos de arquiteturas paralelas. Note que alguns sistemas operacionais oferecem um único sistema de endereços aos processos, mesmo quando executado sobre um conjunto de máquinas. Neste exemplo não temos uma arquitetura paralela, pois somente os processos dos usuários são abstraídos para usufruírem de um endereço único, porém os processos de sistema continuam a usar a rede de dados para comunicação. 2.1.2 Memória Distribuída Quando temos um grupo de máquinas, sicamente temos sistemas de memória distintos, portanto não há como processos comunicarem usando o mesmo sistema de endereçamento. Neste cenário uma rede de dados é adicionada e os processos comunicam por troca de mensagens. Na literatura diferenciamos as arquiteturas de computadores distribuídas em clusters e grades computacionais. 4

2. Referencial Teórico 5 Arquitetura em cluster Um cluster é formado por um conjunto de computadores idênticos que utilizam um mesmo sistema operacional. Muitas vezes é construído a partir de computadores convencionais, os quais são ligados em rede e comunicam-se através do sistema, trabalhando como se fossem uma única máquina de grande porte. Há diversos tipos de cluster. Um tipo famoso é o cluster da classe Beowulf(Becker et al., 1995), constituído por diversos nós escravos gerenciados por um só computador. Segundo o site top500(top500, 2012), atualmente o cluster mais poderoso do mundo é o americano Sequoia, com 1572864 cores e capaz de realizar 20132.7 TFlops de computação. Arquitetura em grade Um aspecto característico da computação de cluster é sua homogeneidade. Os computadores que compõem um cluster são os mesmos, todos têm o mesmo sistema operacional e todos estão conectados a mesma rede. Por comparação, sistemas de computação em grade têm alto grau de heterogeneidade: Nenhuma premissa é adotada em relação a hardware, sistemas operacionais, redes, domínios administrativos, políticas de segurança e assim por diante. A gura 2.1 exemplica o conceito de grades de computadores. A grade possui dois clusters, cada um com um conjunto de máquinas de tipos diferentes, e mais duas máquinas autônomas utilizadas por clientes da aplicação. Figura 2.1: Exemplo de uma grade de computação com clusters

2. Referencial Teórico 6 2.2 Arquiteturas de Software Quando se vai projetar um sistema distribuído, fundamentalmente, o arquiteto de software utiliza a arquitetura centralizada, distribuída ou mesmo uma mistura das duas primeiras. 2.2.1 Cliente/Servidor Pensar em termos de clientes que requisitam serviços a servidores nos ajudam a entender e gerenciar a complexidade de sistemas distribuídos. No modelo cliente/servidor básico, processos em sistemas distribuídos são divididos em dois grupos, com possível sobreposição. Um servidor é um processo que implementa um serviço especíco (um serviço de banco de dados, por exemplo) e um cliente é um processo que requisita um serviço de um servidor enviando-lhe uma requisição e, na sequência, esperando pela resposta do servidor Problemas Se uma quantidade maior de usuários ou recursos devem ser considerados devese tomar cuidado com serviços, dados e algoritmos centralizados. Estes conceitos são explicados na tabela 2.1, pois eles normalmente se tornam gargalos, pontos únicos de falhas e saturam a rede onde residem. Conceito Serviços centralizados Dados centralizados Algoritmos centralizados Exemplo Um único servidor para todos os usuários Uma única lista telefônica para todos os usuários Fazer roteamento com base em informações completas Tabela 2.1: Tipos de prováveis gargalos 2.2.2 Ponto a ponto Uma rede ponto a ponto (P2P em inglês) consiste num conjunto de computadores que comunicam entre si de forma descentralizada, isto é, sem a necessidade de um nó ou nós centrais responsáveis por gerir as ligações entre eles. Cada processo se comporta como um cliente e um servidor ao mesmo tempo. As arquiteturas descentralizadas possuem as seguintes diferenças com relação às centralizadas: Nenhum nó possui informação completa do estado do sistema; Cada nó toma decisões baseado somente em informações locais; A falha de um nó não inviabiliza a execução do algoritmo; Não se pressupõe a existência de um relógio global.

2. Referencial Teórico 7 As arquiteturas descentralizadas também possuem várias vantagens com relação aos sistemas centralizados, entre as quais se destacam: Elevada disponibilidade - Como a rede não depende de um nó central a disponibilidade da rede é bastante superior à de uma rede baseada no modelo cliente-servidor. Mesmo que um determinado nó esteja inativo é sempre possível contactar qualquer outro nó da rede. Particionamento de recursos - Os recursos necessários (algoritmos, dados e comunicação essencialmente) são distribuídos e não estão todos concentrados num nó central. Desta forma é possível conseguir melhor desempenho e aumentar a capacidade de forma econômica. Ao contrário de uma rede cliente-servidor, o aumento de nós da rede representa uma possível melhora na escalabilidade e na tolerância a diversos tipos de falha, haja visto a possibilidade de implementar replicação e cache em arquiteturas descentralizadas. Note que a latência também pode ser reduzida quando utilizamos arquiteturas ponto-a-ponto, por exemplo. Elevada Segurança e Robustez - Dada a inexistência de um servidor central que possa ser alvo de um ataque (Single Point of Failure) uma rede P2P apresenta uma menor probabilidade de ser afetada num ataque malicioso. Sistemas descentralizados são mais resilientes, ou seja, tolerantes a falha. Superpares Deve-se notar que localizar recursos relevantes em sistemas P2P pode se tornar problemático à medida que a rede cresce. A razão para esse problema de escalabilidade é simples: como não há nenhum modo determinístico para rotear uma requisição de pesquisa até um recurso especíco, em essência, a única técnica à qual um nó pode recorrer é enviar a requisição a todos os nós. Como alternativa, muitos sistemas peer-to-peer propuseram a utilização de nós especiais que mantenham um índice de recursos localmente. Nós que mantém índice, ou agem como intermediários, em geral são denominados superpares (superpeers). Sua utilização resulta em uma organização hierárquica. Um exemplo simples dessa organização é mostrado na gura 2.2. Nessa organização, todo par comum está conectado como cliente a um superpar. Toda comunicação de e para um par comum ocorre por meio daquele superpar associado ao par. 2.2.3 Soluções Híbridas Estruturas híbridas são disponibilizadas notavelmente em sistemas distribuídos colaborativos. Vamos considerar o sistema de compartilhamento de arquivos BitTorrent. O BitTorrent é um sistema ponto a ponto de transferência de arquivos. Seu funcionamento principal é mostrado na gura 2.3. A ideia básica é que, quando um usuário nal estiver procurando um arquivo, ele transra porções do arquivo de outros usuários até que as porções transferidas possam ser

2. Referencial Teórico 8 Figura 2.2: Organização hierárquica de nós em uma rede de superpares montadas em conjunto, resultando no arquivo completo. Uma meta importante de projeto é garantir colaboração. Na maioria dos sistemas de compartilhamento de arquivos uma fração signicativa de participantes se limita a obter arquivos. Com essa nalidade, um arquivo só pode ser transferido quando o cliente que está transferindo estiver fornecendo conteúdo a mais alguém. Figura 2.3: Funcionamento principal do BitTorrent O BitTorrent combina soluções centralizadas e descentralizadas. Assim como o BitTorrent, temos um conjunto de serviços sendo ofertados em clouds públicos ou privados que possuem a mesma natureza. As APIs do Google para serviços de roteamento, geolocalização, tradução e consulta são outros excelentes exemplos de arquiteturas de sistemas distribuídos híbridas e bem sucedidas.

Capítulo 3 Trabalhos Correlatos Com a popularização da internet temos a disseminação da computação voluntária e da computação colaborativa. No primeiro exemplo hosts de usuários dispostos pelo mundo cedem tempo ocioso de seus computadores para execução de porções de problemas de grande porte como, por exemplo, a varredura dos sinais oriundos do espaço ou mesmo a procura por curas de doenças mortais e vastamente contraídas por populações. No segundo exemplo os usuários não somente cedem CPU, memória e disco, mas também possuem a possibilidade de submeter tarefas, visualizar resultados e em alguns casos interagir com outros usuários formando grupos. Neste capítulo apresentamos o estado da arte sobre plataformas colaborativas ou apenas voluntárias existentes. 3.1 Globus O Globus (Foster e Kesselman, 1997)(Globus, 2012) é atualmente o projeto de maior impacto na área de Computação em Grade. O sistema desenvolvido é denominado Globus Toolkit (GT) e provê uma série de funcionalidades que permitem a implantação de sistemas de Computação em Grade onde hosts podem ser cadastrados e assim se pode montar uma plataforma privada de computação voluntária em que os computadores cadastrados são usados para processamento e armazenamento. Este software lida com certas questões de infraestrutura, como manipulação de mensagens e gerenciamento de recursos, permitindo, portanto, ao desenvolvedor focar sua atenção na lógica da aplicação. O GRAM (Grid Resource Allocation and Management) provê uma interface assíncona de Web Services para iniciar, monitorar e gerir a execução de computações arbitrárias em computadores remotos. Esta interface permite que o cliente dena algumas variáveis como o tipo e a quantidade de recursos designados, os dados para serem enviados para e do local da execução, o executável e seus argumentos, as credenciais a serem utilizadas, e as persistências exigidas pelo trabalho. Em outras palavras, é permitido ao cliente monitorar o status tanto do recurso computacional quanto das tarefas individualmente. 9

3. Trabalhos Correlatos 10 A especicação GridFTP provê bibliotecas e ferramentas para uma transferência de dados conável, segura, e de alta performance de memória para memória e de disco para disco. O WSRF e WS-Notication provê associações entre as propriedades dos recursos com entidades de rede e o WS-Notication permite o acesso a tais propriedades. Tais funcionalidades permitem a coleta de informações sobre o estado recente dos recursos, que cam expostos para consultas externas. Infelizmente, no Globus o usuário constrói o seu GRID, ou seja, o Globus não suporta computação colaborativa, onde usuários e grupos de usuários compartilham serviços e variáveis. O Globus não pode ser oferecido como serviço a um conjunto de usuários para realizarem computações diversas e algum tipo de interação entre seus usuários, portanto mantê-lo pode ser custoso quando usuários esporádicos precisam executar tarefas ou manter dados de forma distribuída. Imagine um usuário ter de criar uma plataforma Globus para que possa executar alguns pares de programas e então ter de desfazer tal infraestrutura. Java CoG Kit O Java CoG Kit(von Laszewski et al., 2001)(Java CoG Kit, 2012) nos permite acessar, utilizando Java, os serviços Grid providos pelo Globus toolkit. Dentre as funcionalidades do CoG Kit podemos citar: agendar e administrar computação remota; manipular sistemas de arquivos distribuídos; permitir a utilização de políticas de segurança; reservar e alocar recursos; disponibilizar meios grácos para administração do sistema, execução de tarefas e outras funcionalidades do usuário. Por se tratar de um extensão Globus para usuários Java, este sofre das mesmas limitações descritas para o Globus. 3.2 Legion Assim como o Globus, o Legion(Grimshaw et al., 1997)(Legion, 2012) é uma plataforma para se construir serviços em grade de computadores. A característica marcante do Legion é sua arquitetura orientada a objetos: entidades, tais como computadores, dispositivos de armazenamento, aplicações e serviços da grade, são representadas por objetos. Legion provê serviços básicos que todo objeto necessita, como chamada de métodos e propagação de excessões, e faz uso de serviços de camadas inferiores, como transporte de mensagem. É assíncrono e possui variáveis, recursos, compartilhados Ele possuiu uma arquitetura escalável sem nodos centralizados. O Legion mascara a complexidade do ambiente de hardware, a comunicação e a sincronização. Mantém um nível de segurança aos usuários e recursos. Contêm mecanismos para administrar e explorar recursos heterogêneos. Suporta códigos escritos em múltiplas linguagens e provê interoperacionalidade entre eles. Legion também é tolerante à falhas.

3. Trabalhos Correlatos 11 O legion é exível às necessidades do usuário no que se diz respeito à performance e nível de serviço. Por exemplo, um banco necessita de protocolos de segurança mais sosticados do que o usuário comum, pagando, então, o preço de se utilizar chaves criptográcas maiores assim como algoritmos de criptograa que demandam mais CPU. Para atingir às suas necessidades, o usuário pode implementar suas próprias políticas ou utilizar alguma existente por meio de herança. Legion especica a funcionalidade (não a implementação) dos objetos do núcleo do sistema. Na verdade, ele também provê implementações dos objetos que compreendem o núcleo, mas os usuários não são obrigados a usá-los. Devido às suas semelhanças, Globus e Legion dividem os mesmos problemas no que diz respeito a usuários esporádicos e plataformas voluntárias e não colaborativas. 3.3 MyGrid O MyGrid(Cirne et al., 2003) objetiva, ao máximo, simplicar o processo de implantação da grade computacional, permitindo que qualquer usuário tome a iniciativa de instalar uma grade computacional com os recursos que dispõe. Sua arquitetura é dividida em uma máquina que submete e coordena a execução das aplicações (Home Machines), e as máquinas da grade que serão utilizadas para a execução das aplicações de usuário (Grid Machines). Tais máquinas podem estar sob um outro tipo de GRID, como o Globus. Uma tarefa do MyGrid (MyGrid task) é formada pelas subtarefas inicial, grid, e nal, que são executadas sequencialmente nesta ordem. Subtarefas são comandos externos chamados pelo MyGrid. Consequentemente, qualquer programa, escrito em qualquer linguagem, pode ser visto como uma subtarefa. As subtarefas inicial e nal são executadas na Home Machine. A subtarefa inicial é incumbida de congurar o ambiente para a tarefa, por exemplo, transferindo os dados de entrada para a Grid Machine. A subtarefa nal é tipicamente utilizada para coletar os resultados das tasks de volta para a Home Machine. As subtarefas de grid executam em uma Grid Machine e executam a computação em si. Note que as subtarefas intermediárias podem ser executadas de forma assíncrona pela plataforma MyGrid. Outro componente importante do MyGrid é o agendador (Scheduler). O Scheduler recebe a descrição das tarefas que compõe a aplicação do usuário, escolhe qual máquina deve executar cada tarefa e submete as tarefas para execução. MyGrid utiliza uma la de trabalhos com réplica que consiste em agendar todas as tarefas para execução e quando não há mais tarefas a serem executadas o MyGrid seleciona as máquinas que estão sem trabalho para executarem réplicas das tarefas já submetidas. A réplica que acabar sua execução primeiro é assumido como uma execução válida e as outras réplicas são canceladas. Essa tática melhora a performance em situações onde as tasks são designadas a hosts lentos. As desvantagens são que o próprio usuário que deseja executar aplicações o responsável por sua implantação. Não considera grupos de usuários e colaboração de computadores, serviços

3. Trabalhos Correlatos 12 e variáveis/recursos. OurGrid O OurGrid(Andrade et al., 2003)(OurGrid, 2012) foi construído para suprir a limitação de usuários colaborando ao ceder máquinas e executores e escalonadores de tarefas distribuídas facilmente pelo grid. Trata-se de uma comunidade peer-to-peer para compartilhamento de maquinas para execução, agendada ou não, de tarefas. O modelo de compartilhamento adotado é de uma rede de favores, ou seja, um modelo no qual fornecer peers para outro peer é considerado um favor. OurGrid promove equidade aos seus usuários, em outras palavras, os participantes da rede que doarem mais peers possuem maior participação na grade de computadores. OurGrid é completamente descentralizado e composto de entidades autônomas. Cada peer depende somente do seu conhecimento local para fazer parte do sistema. Quando um usuário necessita consumir alguns recursos ele envia, via broadcast, uma mensagem solicitando recursos que te atendam. Todos aqueles que seus recursos satisfazem as características solicitadas e estão disponíveis (de acordo com suas políticas locais) respondem ao solicitante lhe enviando uma mensagem. OurGrid é a plataforma que mais se assemelha ao CollA, possui as mesmas funcionalidades, porém é completamente descentralizada. 3.4 Condor O principal objetivo do Condor(Litzkow et al., 1988)(Condor, 2012) é utilizar capacidade disponível e inutilizada de máquinas pessoais para executar programas, preservando o proprietário, do recurso, de perdas de desempenho. Cada tarefa é realizada individualmente em cada estação de trabalho. Elas não se comunicam ou trocam informação umas com as outras. Se uma tarefa está executando em uma estação de trabalho, esta verica se o usuário voltou a utilizá-la, e caso tenha voltado, a tarefa em background é suspensa. Neste caso, o Condor salva seu estado para que a tarefa possa continuar a executar quando a estação de trabalho car ociosa novamente. O cronograma de tarefas é realizado por um coordenador estático e centralizado. Este coordenador é responsável por reunir as informações do sistema - quais tarefas se encontram em espera e quais estão executando, além da localização das máquinas ociosas - e implementar a política de planejamento. O coordenador central pergunta às estações de trabalho para ver quais estações estão disponíveis, como recursos, aos sistemas e quais já tem tarefas em background aguardando. Para que o acesso às máquinas remotas seja feita de maneira justa, o Condor verica quantas máquinas foram alocadas ao usuário durante um período de tempo, priorizando aque-

3. Trabalhos Correlatos 13 les usuários que menos conseguem máquinas para seu uso. Estes usuários são os chamados usuários leves ou esporádicos, em contrapartida os usuários que utilizam várias máquinas são conhecidos como usuários pesados ou intensos. Como o Condor só utiliza o processamento ocioso das máquinas, o usuário não tem garantia de quando sua aplicação será executada, dependendo sempre da disponibilidade dos recursos do GRID. 3.5 BOINC O sistema BOINC (Berkeley Open Infrastructure for Network Computing)(Anderson, 2004)(Boinc, 2012) foi criado para: reduzir as barreiras da entrada à computação voluntária, prover o compartilhamento de recursos por projetos autônomos, suportar diversas aplicações e recompensar os participantes. Boinc provê ferramentas (scripts em Python e interfaces em C++) para criar, iniciar, parar e consultar projetos. Adicionando novas aplicações, plataformas e versões de aplicações; criando unidades de trabalho e monitorando a performance do servidor. BOINC foi projetado para ser usado por cientistas e não por programadores ou prossionais de TI. Suas ferramentas são simples, bem documentadas e um projeto cheio de recursos pode ser criado em poucas horas. Suas aplicações são executáveis na maioria das plataformas disponíveis. Os participantes podem escolher várias opções que vão desde quanto de banda o BOINC poderá usar até a velocidade que sua CPU pode trabalhar. BOINC prevê um sistema de contabilidade que é uma unidade de crédito, calculada pela combinação de computação, armazenamento e transferência utilizada do usuário. BOINC foi desenvolvido para suprir a alta demanda de computação dos projetos que possuem vida longa. Em outras palavras, BOINC é uma plataforma para projetos que vão car executando por alguns meses ou anos, pois é muito custoso criar uma plataforma deste porte para executar um problema por algumas horas ou dias. Outra desvantagem vem do fato de o BOINC não ser colaborativo e sim voluntário, seus usuários apenas cedem poder computacional para o projeto e não obtém retorno. 3.6 XtremWeb-CH XtremWeb-CH(XWCH)(Abdennadher et al., 2012)(XtremWeb-CH, 2012) é um middleware para computação voluntária que pode facilmente implantar e executar aplicações paralelas e distribuídas em uma infraestrutura de computação voluntária. XWCH consiste de três componentes principais: o coordenador, o trabalhador e o depósito. O coordenador aceita requisições de execução vindas dos clientes, atribui as tarefas para os trabalhadores de acordo com uma política de escalonamento e disponibilidade,

3. Trabalhos Correlatos 14 supervisiona a execução de tarefas nos trabalhadores, detecta falência/desconexão dos trabalhadores e re-envia tarefas para outros trabalhadores disponíveis. O trabalhador inicia a computação designada a ele e aguarda até que a tarefa nalize. Eles utilizam somente um método de retirar: ele iniciam conexões com o coordenador para obter dados de tarefas, ou para noticar o coordenador sobre o status da tarefa. Trabalhadores podem executar em um ambiente com IPs inválidos (NAT) O depósito é usado pelos trabalhadores para baixarem dados de entrada necessários para executar sua tarefa alocada e/ou enviar dados de saída produzidos pela tarefa. Um nó depósito age como um repositório ou servidor de arquivos. Tem-se também um cliente de linha de comando e uma API para submissão de aplicações. Pelo ponto de vista do usuário, existem três níveis de abstrações no XWCH: Uma aplicação é um conjunto de tarefas, que poderão ser submetidas a restrições de precedência. Um módulo é um conjunto de códigos binários que, em geral, contém o mesmo código fonte. Cada binário tem como alvo uma plataforma especíca (OS, CPU). Uma vez que um módulo é criado ele está disponível para uso. Desenvolvedores podem utilizá-lo como um bloco de construção para desenvolver suas aplicações. Uma tarefa é a execução de um código binário em um dado trabalhador. XtremWeb-CH não considera grupos de usuários e a colaboração de computadores, serviços e variáveis/recursos. 3.7 BonjourGrid BounjourGrid (Abbes et al., 2009) é capaz de 1) criar, para cada usuário, um ambiente de execução especíco de forma descentralizada e 2) orquestrar múltiplas instâncias de middlewares para grades computacionais. É possível então, construir, sob demanda, ambientes de execução especícos (combinação dos middlewares XtremWeb, Condor, Boinc, entre outros). BonjourGrid implanta um coordenador, localmente na máquina do usuário, e então solicita participantes (workers). Utilizando uma infraestrutura de publicar/subscrever, cada máquina publica seu estado (ocioso, trabalhador, coordenador). O coordenador, então, seleciona um subgrupo de nós, formando assim um Elemento de Computação (CE) que utilizando middlewares como XtremWeb, Condor ou Boinc irá executar, gerenciar e controlar a aplicação do usuário. Quando um CE termina a aplicação, seu coordenador retorna ao estado ocioso e libera todos os trabalhadores para também retornarem ao estado ocioso.

3. Trabalhos Correlatos 15 Cada CE é de propriedade do usuário que iniciou o estado de coordenador na sua máquina. Então este CE é responsável pela execução de uma ou várias aplicações do mesmo usuário. No nível de usuário, cada usuário implanta sua aplicação na sua máquina e a execução parece local. No nível do middleware, encontramos múltiplos CEs independentes executando sua própria aplicação. E por m, no nível mais baixo todas as máquinas estão interconectadas e disponíveis a qualquer usuário. O BonjourGrid não é colaborativo de forma que os usuários possam interagir e trabalhar juntos. Além disso, o usuário é dono de um conjunto de máquinas até que a execução de tarefas seja concluída, o que pode gerar o um desbalanceamento destes recursos entre os usuários do sistema caso algum mal intencionado decida obter um grande número de máquinas para si. 3.8 PastryGrid PastryGrid(Abbes et al., 2008) é um sistema para gestão de grades computacionais e aplicações do usuário sobre uma rede P2P totalmente descentralizada. O sistema não executa somente aplicações do tipo Bag of Tasts (BoT) mas também aplicações distribuídas com precedência de tarefas de uma maneira descentralizada. A idéia básica do PastryGrid é que cada aplicação do usuário cria seu próprio, autônomo e descentralizado ambiente de execução. Cada aplicação detém um local chamado de Rendez-Vouz Point (RDV), para armazenar ou recuperar dados. As máquinas que contribuem para a execução de uma ou várias tarefas de uma aplicação também podem contribuir na gestão e controle de outras tarefas da memsa aplicação. Não existe um elemento especíco que coordena os passos da execução das aplicações. A originalidade do PastryGrid consiste na execução de aplicações distribuídas para tarefas com precedência, de maneira descentralizada. Uma Aplicação Distribuída (DA) é a combinação de um ou vários módulos. Um módulo é um conjunto de tarefas que usa um mesmo arquivo binário e, geralmente, diferentes arquivos de entrada. Tarefas de um mesmo módulo podem ser realizadas de maneira paralela. Para descrever sua aplicação distribuída um usuário deverá fornecer um pacote comprimido contento todos os dados necessários, arquivos binários e o grafo de uxo de dados da aplicação (onde os nós são as tarefas e as arestas são as comunicações entre as tarefas). O usuário deve especicar também os requerimentos para a execução de cada tarefa da plicação. PastryGrid provê uma ferramenta, chamada de SDAD (Sistema para descrição de aplicações distribuídas). Nesta ferramenta temos um modo gráco para aplicações simples e um modo avançado para aquelas complexas. O esquema de endereçamento utilizado é baseado em DHT (Tabela Hash Distribuída). Neste modelo os nós podem se juntar e sair da rede, e as entradas da tabela hash são automaticamente mapeadas em novos nós físicos. Referencias para essas entradas não precisam ser atualizadas. Ela utiliza um algoritmo de roteamento totalmente descentralizado que garante

3. Trabalhos Correlatos 16 a entrega das mensagens em no máximo O(log(N)) saltos, onde N é o número de nós físicos participando da rede. Assim como a plataforma BonjourGrid, o PastryGrid não é colaborativo de forma que os usuários possam interagir e trabalhar juntos. Além disso, o usuário é dono de um conjunto de máquinas até que a execução de tarefas seja concluída, o que pode gerar o um desbalanceamento destes recursos entre os usuários do sistema caso algum mal intencionado decida obter um grande número de máquinas para si. A grande vantagem é a possibilidade de execução de aplicações distribuídas do próprio usuário, pois os demais middlewares suportam dados distribuídos e aplicações sequenciais ou paralelas apenas. No caso do CollA o usuário pode enviar tarefas codicadas usando JavaCá&Lá, que permite a fácil prototipação de aplicações Java paralelas ou distribuídas a partir de um único código similar ao sequencial. 3.9 SETI@home Por m temos o SETI@home(Anderson et al., 2002)(SETI@home, 2012) que, diferentemente das demais, não é uma plataforma e sim uma aplicação. SETI@home utiliza milhões de computadores em casas e escritórios de todo o mundo para analisar sinais de rádio do espaço em busca de vida extraterrestre. Essa abordagem proporcionou um poder computacional sem precedentes e demonstrou a viabilidade da computação voluntária onde os recursos computacionais são providos pelo público em geral. Atualmente existem 4,5 milhões de usuários cadastrados e o software do cliente foi portado para 175 plataformas diferentes. A arquitetura do sistema é bem simples: Os dados são quebrados em pequenos pacotes de 350 KiB, denominados unidades de trabalho (workunits). Os clientes SETI@home são executados em computadores pessoais espalhados pelo mundo. Basicamente eles requisitam uma unidade de trabalho, processam a mesma, enviam os resultados para o servidor central e nesse momento recebem outra unidade de trabalho. O protocolo de comunicação entre os clientes e o servidor é baseado em HTTP, de maneira a permitir que máquinas atrás de rewals consigam contatar o servidor. A aplicação é fortemente acoplada ao sistema, não permitindo que se executem outros problemas além do SETI. Além disso, falta um mecanismo que permita um uso mais eciente dos recursos: quando a máquina não está totalmente ociosa o único controle que pode-se fazer sobre o cliente é colocá-lo em baixa prioridade. O SETI foi o precursor do BOINC.

Capítulo 4 Desenvolvimento Neste trabalho implementamos uma plataforma de software denominada Collaborative Analysis (CollA). A plataforma CollA já permite que não somente fontes de dados sejam compartilhadas, mas também que componentes de software, experimentos, resultados de experimentos e nós de processamento (incluindo memória principal, secundária e processadores) possam ser usados de forma colaborativa por diferentes especialistas em diferentes ambientes CollA que operam sobre um conjunto de máquinas ou hosts heterogêneos e distribuídos pela internet em diferentes topologias e tecnologias de rede. A plataforma CollA permite que grupos de usuários possam ser criados e que artefatos comuns à análise possam estar disponíveis em tais grupos. A plataforma também já dispõe do serviço de chat, manutenção de usuários e grupos de usuário, serviço de compartilhamento de computadores, incluindo a possibilidade de utilização de computadores com IPs inválidos, o serviço de execução de quaisquer tarefas implementadas em Java e a integração com o middleware para desenvolvimento de aplicações paralelas ou distribuídas Java Cá&Lá(JavaCá&Lá, 2012). A primeira versão gratuita e livre da plataforma CollA está disponível ao público, incluindo manuais de utilização e instalação. Na Figura 4.1 ilustramos os serviços nativos na plataforma CollA. Neste exemplo, os usuários Cli1 e Cli2 possuem os hosts que chamaremos h1, h2 e h3, respectivamente. O usuário Cli1 possui apenas um host enquanto o usuário Cli2 possui dois hosts cadastrados no CollA. O usuário Cli1 decide submeter sua tarefa para o CollA executar e o resultado, assim como a tarefa, passam a car disponíveis a todo o grupo ao qual Cli1 pertence. Neste caso, ambos os usuários Cli1 e Cli2 conseguirão re-submeter a tarefa ou mesmo analisar os resultados. Em suma, basta cada usuário cadastrar um conjunto de hosts CollA e se juntar a grupos CollA para usufruir de maior poder computacional. Além de submeter tarefas, o CollA permite que usuários de um mesmo grupo conversem usando chat. Note que o usuário pode se juntar e/ou criar quantos grupos almejar. Quantos mais hosts forem sendo cadastrados mais a ideia do CollA ca interessante. 17

4. Desenvolvimento 18 Figura 4.1: Componentes da plataforma CollA. 4.1 CollA Server A plataforma CollA possui o servidor, ainda centralizado, chamado de CollA Server, que mantém informações sobre todo o sistema. Quando um usuário (ou host) efetua seu cadastrado no sistema ele contata o servidor, passa suas informações e pede permissão para cadastro. O mesmo ocorre quando um usuário (ou host) se conecta/desconecta do sistema. Sempre uma solicitação é enviada ao servidor que armazena esta informação. Outra informação importante que o servidor mantém é o cadastro de grupos existentes e seus participantes. O servidor possui uma interface onde as principais informações do sistema podem ser visualizadas de forma coerente. Uma lista com todos os clientes cadastrados na plataforma é disponibilizada e ao selecionar um deles um grupo de informações sobre o usuário é exibido, entre elas: nome, email, se ele está online, entre outras. Ao selecionar um usuário os seus hosts são exibidos e então temos a opção de obtermos informações de qualquer um deles. Outra informação relevante que ca disponível no servidor são as seções do usuário, permitindo acompanhar o histórico de tarefas de cada cliente que inclui: quando ele se conectou, qual serviço ele utilizou e quando ele deixou o sistema. Por m, o servidor possui ainda um log que traz informações, em tempo real, de tudo o que acontece no sistema.

4. Desenvolvimento 19 No exemplo da gura 4.2 o administrador selecionou o cliente bruno e pode visualizar suas informações assim como os seus hosts e suas seções. Tal cliente possui apenas o host bruno_0, está online, possui o IP 192.168.2.101, não possui um IP público, utilizou o serviço de chat às 14:49hs do dia 03/10/2012, etc. Figura 4.2: Tela principal do CollA Super Server. No ato do login, o usuário requisita ao servidor os grupos que ele participa e seus membros, a resposta obtida é uma lista de usuários com seus endereços IP e grupos aos quais pertencem, além de outras informações como os hosts ofertados. De posse desta lista, o cliente tem a capacidade de contatar outros usuários de forma direta, sem ter de requisitar essa comunicação ao servidor. Fica evidenciado que a arquitetura do CollA é híbrida com base nas arquiteturas cliente/servidor e ponto a ponto. Essa estratégia torna o CollA mais robusto e escalável, já que são poucas as comunicações que devem ser centralizadas, além de seguro, pois exige-se uma autenticação com o servidor. A gura 4.3 exemplica simplicadamente a arquitetura da plataforma CollA e nos mostra como uma mensagem de chat é enviada pela rede. No exemplo, o usuário cli1 abre uma conexão

4. Desenvolvimento 20 (a) com o servidor solicitando sua lista de contatos e então abre uma nova conexão (b), desta vez, com cli2 e envia sua mensagem. A conexão em (b) permanece ativa enquanto o chat estiver aberto por algum dos seus participantes e é utilizada durante a troca de mensagens entre eles. Figura 4.3: Modelo de arquitetura utilizado pelo CollA Arquiteturalmente, como pode ser visto na gura 4.4, o CollA Server é um servidor multithread que utiliza da técnica produtor/consumidor, onde o produtor é o servidor que recebe as solicitações e as repassa para um de seus Server Workers para que possam responder à solicitação. As informações pertinentes à plataforma são encaminhadas ao CollA Management que se encarrega de armazená-las. Caso o usuário não possua um IP público e visível fora de sua rede, o socket utilizado na conexão com servidor será armazenado para que este mantenha um meio de comunicação com o usuário. O problema com IPs inválidos são tratados na próxima seção. Figura 4.4: Arquitetura do CollA Server

4. Desenvolvimento 21 4.1.1 IPs inválidos Máquinas com IPs válidos podem ser encontradas diretamente por outras máquinas na Internet. Já as máquinas com IPs inválidos não podem ser encontradas diretamente, pois o endereço IP ao qual se tem acesso é, na realidade, o endereço do provedor de acesso à Internet (ISP, na sigla em inglês). O ISP distribui endereços IP válidos somente em sua rede interna, sendo tais endereços IP inacessíveis fora da mesma, impossibilitando, desta forma, o uso de tais computadores pela plataforma CollA. IPs inválidos foi uma das questões mais complexas impostas na primeira fase do projeto CollA, ao qual este documento faz parte. Para solucionar este problema utilizamos o servidor CollA como intermediário na comunicação. Como exemplo, vamos adotar o cenário em que temos dois usuários: cli1 possuindo IP válido e cli2, inválido. Neste cenário, ao se logar cli1 entra em contato com o servidor CollA, enviando os dados de autenticação de usuário e também o seu endereço IP. O servidor compara os dados enviados com a conexão existente. O mesmo ocorre com cli2, porém o servidor CollA identica que seu IP é invalido, conrmando que trata-se de um computador utilizando algum ISP. Neste cenário cli2 consegue se comunicar diretamente com cli1, porém cli1 deve utilizar o servidor CollA para que possa se comunicar com cli2. Utilizando, além do cenário descrito, a aplicação CollA Chat e a gura 4.5 para exemplicar, temos cli1 enviando sua mensagem, pelo canal (a), para o servidor e este repassando a mensagem, por (b), ao cli2 que pode respondê-la de maneira direta, utilizando-se do canal de comunicação unidirecional (c). Figura 4.5: Modelo de arquitetura utilizado pelo CollA para o envio de mensagens de chat entre usuários com IP inválido Para que o servidor CollA possa agir como intermediário para clientes ou hosts com endereços IP inválidos, se faz necessária uma conexão ininterrupta entre o usuário com IP inválido e o servidor. Esta solução inicial acarreta em um gargalo na plataforma CollA, pois se um número crescente de clientes ou hosts estiverem conectados via ISPs o servidor CollA se torna o limitante, já que toda a comunicação deverá passar por ele. Neste sentido, estamos traba-

4. Desenvolvimento 22 lhando na versão que diminui tal gargalo, criando o conceito de super Hosts ou super Peers Maiores detalhes de super hosts e outras melhorias no capítulo Conclusões. 4.1.2 CollA Task Executor O que torna o CollA colaborativo é a sua capacidade para executar aplicações em cima da sua infraestrutura. Os usuários podem ceder suas máquinas pessoais para outros clientes CollA, possibilitando que pequenos laboratórios possam obter, quando necessário, poder computacional em grandezas muito superiores das quais eles teriam acesso se utilizassem apenas seus próprios computadores. A tarefa a ser executada deve sempre estar vinculada a um grupo ao qual o usuário pertença, desse modo a tarefa não pertence mais a um cliente e sim ao grupo e seus membros, que podem acompanhar a sua execução e obter informações sobre a tarefa, como o tempo que ela levou para executar e o resultado obtido. Uma vez compartilhada, a tarefa pode ser re-submetida por qualquer usuário do grupo e não apenas seu codicador ou proprietário. Internamente à plataforma CollA, o usuário que solicita a execução de algum aplicativo deve, antes de mais nada, solicitar ao servidor um host disponível para execução. De posse das informações dos hosts ativos (online), o servidor é capaz de escolher um host que vai atender ao usuário, utilizando a técnica round-robin para garantir algum balanceamento. Tal técnica foi escolhida pois escolhe sempre um host diferente na tentativa de ocupar igualmente todos os hosts. Depois de escolhido, suas informações são enviadas ao usuário que deve entrar em contato. O cliente então entra em contato diretamente com o host. Pelo exemplo da gura 4.6 podemos observar que, por (a), o cliente cli1 entra em contato com o servidor com o intuito de enviar uma aplicação para execução recebe a informação de que o host h2 se encontra disponível e, por meio de (b), lhe envia a tarefa para ser executada. O resultado da tarefa é retornado ao usuário pelo mesmo canal de comunicação (b). Assim como acontece com a troca de mensagens por chat, alguns dos hosts podem utilizar IP inválido, o que não permite que sejam contatados diretamente. Nestes casos, também utilizamos a solução de enviar a aplicação para o servidor que repassa ao host. Podemos observar esse cenário no exemplo da gura 4.7, onde o servidor repassa a tarefa de cli1, recebida por (a), para h2, por meio de (b). O resultado da computação pode ser enviado diretamente à cli2 desde que este possua um IP válido, usando o canal de comunicação (c). É também permitido ao usuário que envie alguns anexos à aplicação, tais anexos podem ser outras aplicações ou bibliotecas que a tarefa necessite para executar, ou ainda arquivos que a tarefa manipule. O software JavaCá&Lá (JavaCá&Lá, 2012) é o responsável pela execução das tarefas no host. Tal software tem a capacidade de executar qualquer aplicação escrita em Java paralelamente em um computador multicore. E é também um middleware para dar suporte à

4. Desenvolvimento 23 Figura 4.6: Modelo de arquitetura utilizado pelo CollA para o envio aplicações entre o cliente e o host Figura 4.7: Modelo de arquitetura utilizado pelo CollA para o envio aplicações entre o cliente e o host com IP inválido

4. Desenvolvimento 24 programação paralela, onde as suas aplicações são programadas de forma similar a sequencial, sendo necessário atender algumas restrições impostas pelo middleware. Os resultados obtidos através dos hosts e algumas informações sobre a execução da tarefa, como o tempo de execução da mesma, são disponibilizados a um grupo de usuários CollA. Cabe a cada usuário abrir o resultado em um aplicativo especíco, como é o caso dos editores e planilhas ou ferramentas matemáticas e estatísticas. Assim como os resultados de tarefas CollA cam disponíveis a usuários de um grupo CollA, o mesmo acontece com as próprias tarefas. Desta forma, permitimos a re-submissão de tarefas de qualquer usuário de um grupo e não apenas pelo programador da mesma. Tarefas que implementam soluções não exatas para problemas com ordem de complexidade não polinomiais podem se valer e muito da resubmissão de tarefas CollA com parâmetros de execução diferenciados e obtidos por diferentes especialistas. 4.2 CollA Host O CollA Host tem como objetivo permitir que usuários possam cadastrar as máquinas que se deseja compartilhar com a plataforma CollA. Hosts podem executar qualquer tipo de programa escrito em Java ou JavaCá&Lá. Com essa funcionalidade o CollA permite que múltiplos programas possam ser executados transparentemente em máquinas multicore ou grades heterogêneas de computadores e que objetos Java possam ser compartilhados entre diferentes aplicações Java em JVMs distintas. Na seção 4.1.2 foi detalhado o serviço nativo CollA de execução de tarefas Java ou Java Cá&Lá. Antes de cadastrar um host o usuário precisa ter cadastrado um usuário utilizando o CollA Developer Viewer, pois os hosts devem sempre estar vinculados a um usuário. No exemplo da gura 4.8 o host bruno_1 se conecta à plataforma CollA. Arquiteturalmente, como pode ser visto na gura 4.9, o componente Host Register é responsável pelo cadastro e login do host com o servidor. Então, um Micro Server passa a executar para que possa receber mensagens de clientes e servidores CollA. O Micro Server é multithread e utiliza da técnica produtor/consumidor, onde o produzido são as tarefas recebidas através das mensagens e os consumidores são threads que se encarregam de executar tais tarefas. Com essa abordagem cada host consegue atender a um número considerável de usuários. CollA Host é integrado ao middleware JavaCá&Lá que ca responsável por executar as tarefas recebidas. Com isso, o Task Executor é responsável por enviar as tarefas ao JavaCá&Lá e por requisitar seus resultados ao mesmo. Os resultados das mensagens são enviados diretamente aos usuários ou ao servidor CollA, podendo também ser armazenados para futuras solicitações dos clientes.

4. Desenvolvimento 25 Figura 4.8: Tela principal do CollA Host. Figura 4.9: Arquitetura do CollA Host

4. Desenvolvimento 26 4.3 CollA Client - Aplicativo Developer Viewer Os usuários CollA utilizam do programa CollA Developer Viewer (CDV) para se cadastrar, logar, e utilizar os serviços disponíveis pelo CollA, como criação e manipulação de grupos, chat, submissão de tarefas, entre outros. Após efetuar seu cadastro e se conectar à plataforma, o usuário pode visualizar os grupos aos quais ele pertence e os contatos dos seus grupos, assim como a disponibilidade (online ou oine) de tais amigos. Uma vez selecionado algum contato, é possível visualizar seus hosts cadastrados no CollA e suas características, que vão desde a quantidade de processadores e memória que a máquina possui até mesmo sua arquitetura e sistema operacional. Uma área de noticações é visível e nela são disponibilizadas algumas informações úteis como, por exemplo, se o usuário foi aceito em um grupo que ele pediu ingresso ou se seu novo grupo foi criado com êxito. Note que o usuário pode se liar a vários grupos CollA, como também pode cadastrar vários hosts à sua conta de usuário. No exemplo da Figura 4.10 o usuário bruno selecionou o grupo Group-test que também possui cadastrado o usuário diogo e após ele se selecionar no grupo, ele visualiza as características do seu host nomeado de bruno_0. Tal host possui 4 processadores, sistema operacional Windows, está cadastrado no Brasil, etc. Figura 4.10: Tela principal do CollA Developer Viewer. Arquiteturalmente, como pode ser visto na gura 4.11 o componente User Register é o responsável por efetuar o cadastro do usuário e também por logá-lo. Então, um Micro Server passa a executar para que possa receber mensagens de clientes, hosts e servidores CollA.

4. Desenvolvimento 27 As mensagens recebidas de outros usuários podem ser mensagens de chat ou mensagens de solicitação de ingresso a grupos. As mensagens recebidas de hosts podem ser mensagens informando o m da execução de tarefas ou mensagens com os resultados das tarefas. O servidor pode contatar o usuário para repassar mensagens de outros usuários e hosts ou enviar mensagens de conrmação de login ou conrmação de criação de grupo. O componente de Chat é responsável por enviar as mensagens de chat aos outros usuários e por organizar as mensagens de chat recebidas. O componente Group Manager é o responsável por criar grupos, pedir ingresso a grupos, por receber convites de ingresso a grupos e por gerenciar os grupos que o cliente faz parte. O componente Task Scheduler é o responsável por enviar tarefas para serem executadas, por receber os resultados das tarefas e também por gerenciar as tarefas e os resultados. Figura 4.11: Arquitetura do CollA Client 4.4 CollA Groups O CollA é colaborativo, portanto grupos são fundamentais. No CollA grupos compartilham de toda infraestrutura computacional cadastrada no CollA. Além disto, grupos usufruem de privacidade com tarefas, resultados de tarefas e chats disponíveis aos grupos apenas. Qualquer usuário cadastrado na plataforma pode criar o seu próprio CollA Group, aqueles que quiserem fazer parte do grupo deverão solicitar seu ingresso, que será analisado pelo seu administrador. Quem cria o grupo é chamado de administrador e tem o perl de aceitar ou recusar novos ingressantes. Todos os usuários podem visualizar quais são os membros que pertencem aos grupos em que ele está cadastrado. Algumas informações acerca destes membros também são disponibilizadas, como email do usuário, país de origem e com quantos hosts ele está contribuindo. Na

4. Desenvolvimento 28 gura 4.12 é exibida as informações do grupo Group-test, podemos observar que o usuário bruno pode ser contatado pelo email bruno@mail.com, reside no Brasil e está oferecendo 2 hosts para serem utilizados pela plataforma. Figura 4.12: Tela de informações do CollA Groups 4.5 CollA Chat O chat só é possível entre os usuários de um mesmo grupo e como não existe um limite de grupos em que se pode participar, o chat pode ocorrer entre muitos usuários. Quando um usuário inicia um chat com alguém, ele envia sua mensagem diretamente ao amigo que é comunicado e pode respondê-lo da mesma forma. E, no caso do destinatário se encontrar sob um ISP e com isso possuir um IP inválido, a mensagem é enviada ao servidor para ser repassada. 4.6 Conclusões Na atual versão CollA, disponível em (CollA, 2012) já dispomos do serviço CollA Job Executor para execução de programas Java na plataforma. Cabe a plataforma executar remotamente o JAR, noticar o resultado e obter o resultado localmente para possível visualização ou

4. Desenvolvimento 29 análise. As tarefas submetidas, assim como seus resultados, cam disponíveis ao grupo CollA, possibilitando a re-submissão de tarefas ou a análise colaborativa dos resultados. O CollA já executa em ambientes distribuídos compostos por máquinas com IPs válidos e inválidos, resolvendo assim uma das questões mais complexas impostas na primeira fase do projeto. Manuais de instalação e utilização foram feitos e já se encontram disponíveis no site. O código fonte e a documentação, javadoc, do mesmo foram feitos, porém optamos por não torná-los públicos até que fechemos a segunda fase do projeto, planejada para 2013 apenas. No próximo capítulo experimentos com o CollA são feitos e os serviços de compartilhamento de máquinas e submissão de tarefas é testado em dois grupos de usuários, um homogêneo e com IPs válidos e outro com máquinas distintas, SOs distintos, IPs inválidos e longas distâncias entre hosts CollA.

Capítulo 5 Experimentos Este capítulo apresenta os resultados obtidos a partir dos experimentos realizados com a plataforma CollA. A funcionalidade escolhida para teste foi o CollA Task Executor, pois utiliza de toda a arquitetura da plataforma. Foram escolhidos três algoritmos simples para a execução dos experimentos, denominados jar0, jar1 e jar2. O algoritmo jar0 é responsável por calcular, de forma recursiva, o 40 o elemento da série de Fibonacci. Ele é considerado um algoritmo leve, pois a sua computação é realizada em menos de um segundo tornando-o excelente para vericar se as tarefas chegam a seus destinos e são computadas corretamente, assim como para vericar se os resultados obtidos através delas são retornados com sucesso. O algoritmo jar1 gera um vetor de elementos aleatórios de tamanho 100.000 e os ordena utilizando do método de ordenação Gnome sort 1. Neste exemplo os vetores de números não são enviados pela rede, sendo apenas gerados e ordenados no host CollA. Este é considerado um algoritmo moderado, pois sua computação é realizada em um tempo que varia de 17 à 70 segundos dependendo da máquina onde ele é executado, sendo utilizado para vericar o comportamento dos hosts quando estressados e quando possuem várias tarefas por executar. Por m, o algoritmo jar2 também gera e ordena um vetor de tamanho 100.000, mas aqui enviamos junto um arquivo anexo de 858KB e obtemos como resposta o vetor ordenado de tamanho 800KB. Este algoritmo é considerado pesado e tem como objetivo vericar o comportamento da plataforma quando sujeita a grande volume de dados. 1 Algoritmo similar ao Insertion sort com a diferença que o Gnome sort leva um elemento para sua posição correta, com uma sequencia grande de trocas assim como o Bubble sort. O algoritmo percorre o vetor comparando seus elementos dois a dois, assim que ele encontra um elemento que está na posição incorreta, ou seja, um número maior antes de um menor, ele troca a posição dos elementos, e volta com este elemento até que encontre o seu respectivo lugar. Complexidade de tempo: Θ(n 2 ) 30

5. Experimentos 31 5.1 Ambiente Computacional dos Experimentos Os experimentos foram testados em dois ambientes. Ambos utilizando como servidor uma máquina com processador Intel Xeon (2, 00 GHz) de 8 núcleos e 16GB de memória RAM com sistema operacional Linux Ubuntu, possuindo IP válido. O primeiro são dois clusters, um composto por 17 máquinas com processador Intel Core i3 (3, 30GHz) de 4 núcleos e 8GB de memória RAM com sistema operacional Windows 7 e outro composto por 18 máquinas com processador Athlon Dual Core 5400B (2, 80GHz) de 2 núcleos e 2GB de memória RAM com sistema operacional Windows 7. Todas as máquinas do cluster possuem IPs válidos. O segundo ambiente contou com as máquinas do primeiro ambiente e mais um notebook com processador Intel Core 2 Duo (2, 10GHz) de 2 núcleos e 3GB de memória RAM com sistema operacional Windows 7, um notebook com processador Intel Core i3 (2, 40GHz) de 4 núcleos e 3GB de memória RAM com sistema operacional Linux Ubuntu, um notebook com processador Intel Atom (1, 50GHz) de 2 núcleos com sistema operacional Windows 7 e 2GB de memória RAM, e um notebook com processador Intel Core i3 (2, 20GHz) de 4 núcleos e 3GB de memória RAM com sistema operacional Linux Ubuntu. Todos os notebooks estavam fora da rede local do servidor e não possuíam IPs válidos. Neste cenário 3 notebooks estavam na cidade de Ouro Preto, Minas Gerais e 1 na cidade do Porto, em Portugal. O primeiro ambiente foi utilizado para testar a plataforma onde todos os seus usuários possuem IPs válido. Enquanto no segundo ambiente foi testado o comportamento da plataforma quando seus hosts são heterogêneos, ou seja, alguns de seus participantes se encontram sob provedores de internet e não podem ser contatados diretamente. 5.2 Metodologia dos Experimentos Foi desenvolvido um algoritmo, denominado Tester, para validar o funcionamento da plataforma. Esse algoritmo se cadastra no servidor, loga e envia milhares de tarefas ininterruptamente à plataforma, esperando receber seus resultados. Os três algoritmos descritos no início deste capítulo foram utilizados nos experimentos, como representado na equação 5.1, onde t representa o algoritmo enviado e i representa a itereção do Tester: t 0, i%3 = 0 t 1, i%3 = 1 t 2, i%3 = 2 (5.1)

5. Experimentos 32 Antes de inicializar o Tester, o servidor é ligado e as máquinas do ambiente cadastradas como hosts. Depois do Tester ter sido inicializado o experimento era realizado por um período de 8 horas sem alteração de hosts. 5.3 Resultados do experimento no ambiente homogêneo e com IPs válidos Para testar a plataforma utilizando um ambiente homogêneo o Tester foi congurado para enviar 40 tarefas por minuto o que daria 19.200 tarefas durante às 8 horas de execução. O resultado deste teste pode ser visto na tabela 5.1 Tarefas à enviar Tarefas enviadas Respostas obtidas 19.200 18.633 18.632 100, 00% 97, 05% 97, 04% Tabela 5.1: Resultados do experimento em ambiente homogêneo Temos então, 19.200 requisições ao servidor com o intuito de obter hosts disponíveis, destas 18.633 foram atendidas e este mesmo número de tarefas foram enviadas aos hosts. Somente uma tarefa se perdeu ao fazer o caminho contrário e retornar o resultado obtido ao Tester. E por m, todos os resultados obtidos foram corretos. Podemos observar um comportamento estável da plataforma, onde temos como gargalo o servidor que não respondeu à todas as solicitações feitas pelo Tester. O tempo médio de execução de cada tarefa executada com sucesso, considerando os momentos em que a tarefa é enviada ao host e o resultado retorna ao Tester é demonstrado na tabela 5.2. Algoritmo jar0 jar1 jar2 Tempo médio de execução 29, 8s 87, 9s 87, 4s Tabela 5.2: Tempo médio de cada tarefa utilizada no experimento em ambiente homogêneo 5.4 Resultados do experimento no ambiente heterogêneo e com IPs inválidos Diferentemente do teste anterior, aqui utilizamos duas máquinas como Testers, cada uma enviando 12 tarefas por minuto o que daria 5.760 tarefas por cada Tester durante às mesmas 8 horas de execução. O resultado do teste pode ser visto na tabela 5.3

5. Experimentos 33 Tester Tarefas à enviar Tarefas enviadas Respostas obtidas Tester1 5.760 5.619 5.353 Tester1 100, 00% 97, 55% 92, 93% Tester2 5.760 5.600 5.364 Tester2 100, 00% 97, 22% 93, 13% Tabela 5.3: Resultados do experimento em ambiente heterôgeneo No total temos, 11.520 requisições ao servidor com o intuito de obter hosts disponíveis, destas 11.219 foram atendidas e este mesmo número de tarefas fora enviadas aos hosts. Durante o teste um dos notebooks se desligou, cando indisponível. Neste caso o problema é que o servidor ainda o via como um host disponível e, às vezes, o enviava ao Tester. Como resultado todas as tarefas enviadas à ele foram perdidas. Assim, 502 tarefas se perderam ao fazer o caminho contrário e retornar o resultado obtido ao Tester. E por m, todos os resultados obtidos foram corretos. Podemos observar um comportamento estável da plataforma, onde temos como gargalo o servidor que não respondeu à todas as solicitações feitas pelo Tester. O tempo médio de execução de cada tarefa executada com sucesso, considerando os momentos em que a tarefa é enviada ao host e o resultado retorna ao Tester é demonstrado na tabela 5.4. Algoritmo jar0 jar1 jar2 Tempo médio de execução 7, 6s 64, 2s 69, 1s Tabela 5.4: Tempo médio de cada tarefa utilizada no experimento em ambiente heterogêneo

Capítulo 6 Conclusões A plataforma CollA é uma alternativa de solução baseada em colaboração para resolver o problema da massiva quantidade de dados a serem analisados por diferentes especialistas. Nesta versão implementamos os serviços básicos que já tornam a plataforma CollA útil a usuários que almejem colaborar cedendo computadores e componentes de software. Já é possível executar tarefas programadas em Java (com ou sem o uso do middleware Java Cá&Lá) na plataforma. Em linhas gerais, pessoas físicas, laboratórios, universidades, empresas, entre outros, já podem se cadastrar em ambientes na plataforma CollA. CollA pode também ser executado numa intranet de uma determinada empresa, órgão do governo ou universidade, onde funcionários criam ambientes, compartilham e cooperam seus processos analíticos. A academia, o governo e a iniciativa privada podem encontrar ou criar ambientes direcionados a determinadas áreas, permitindo com isto que especialistas multidisciplinares compartilhem e cooperem cada vez mais. A infraestrutura básica para que isto ocorra já está disponível e, como apresentado, muitas melhorias já estão em andamento para que tenhamos uma plataforma mais robusta e que permita que usuários possam formar grupos colaborativos compartilhando recursos computacionais de maneira mais eciente, aumentando o desempenho de seus projetos, uma melhoria bem-vinda principalmente para grupos com acesso a um menor número de máquinas. As metas propostas por este trabalho foram concluídas e como melhoria incluiremos alguns métodos de tolerância à falha, tais como re-conexão dos sockets quando não conseguem se estabelecer, envio da mesma tarefa para mais de um host como forma de prevenir falhas e constante monitoração do status dos membros da plataforma de modo a não permitir que mensagens sejam enviadas a quem não estiver mais disponível. Incluiremos, também, o conceito de Super Hosts que cuidarão de grupos de hosts ou clientes que estejam usando ISPs para comunicação, recebendo e encaminhando as mensagens que estes não conseguem receber de forma direta. Deste modo não teremos apenas um intermediário CollA e sim vários. Acreditamos que esta solução, comumente adotada em sistemas 34

6. Conclusões 35 distribuídos em grade escala, atenda as necessidades da plataforma CollA. E por m, propomos a integração completa ao projeto Cá&Lá Parallel Programming(JavaCá&Lá, 2012), permitindo que tarefas CollA possam ser programadas usando o middleware Java Cá&Lá em qualquer versão. Desta forma, as tarefas poderão ser executadas em várias máquinas e gerenciadas pelo CollA transparentemente. Na segunda fase do projeto também propomos implementar o serviço de partição de bases de dados para o usuário. Massivas bases de dados em formato texto poderão usar o ambiente CollA como repositório compartilhado. Além disto, as atuais tarefas poderão usar as bases a partir da plataforma CollA e não mais localmente.

Apêndice Neste capítulo são apresentados o Guia de Instalação e o Guia do Usuário da plataforma CollA. 36

GUIA DE INSTALAÇÃO COLLA CONFIGURAR XML SERVER_CONF Antes de instalar, cabe ao usuário configurar o arquivo server_conf. O usuário deve editar somente o campo referente ao endereço IP da máquina servidor. O arquivo XML server_conf deve estar presente no mesmo diretório dos projetos CollA_Client e CollA_Host. Sem o correto endereço IP do server CollA a plataforma não funciona. INSTALAR SERVIDOR O usuário deverá escolher uma máquina de sua rede e instalar o jar chamado CollA_server. Nenhuma informação será requerida neste passo. INSTALAR CLIENTE Após o servidor estar funcionando, instalar o jar CollA_client na máquina que o usuário almeja submeter tarefas, fazer chat, etc. Caso o usuário possua mais de um dispositivo, basta instalar o CollA_Client em quantos computadores almejar. Depois de instalado, o usuário loga ou se cadastra na plataforma CollA. INSTALAR HOST Por fim, instale quantos hosts almejar usando o jar CollA_Host. Cada host exigirá registrar os dados do usuário, portanto algum usuário já deve estar cadastrado na plataforma CollA. JÁ INSTALEI, E AGORA? Depois de toda plataforma CollA instalada, você pode convidar quantos clientes almejar e estes podem registrar hosts, submeter Tasks, etc., tornando um departamento, uma universidade, uma software house, um grupo de pesquisa, etc., um grupo CollA. GUIA DO USUÁRIO COLLA É fundamental a leitura do documento Guia do Usuário. Com ele aprenderemos a usar os serviços já disponíveis na plataforma CollA.

GUIA DO USUÁRIO COLLA SERVIDOR INFORMAÇÕES VISUALIZAÇÃO DOS LOGS DO SISTEMA Na tela principal do Servidor - aba Server Status - estão disponíveis informações do sistema, tais como: cliente C conectou, cliente D se cadastrou, entre outras. Fig1. Server status VISUALIZAÇÃO DOS CLIENTES E HOSTS CADASTRADOS Clicando na aba Clients você pode visualizar, do lado esquerdo, todos os clientes cadastrados na plataforma e também seus hosts.

Fig2. Clientes CollA e seus hosts VISUALIZAÇÃO DOS STATUS DE CLIENTES E HOSTS Para visualizar as informações detalhadas sobre cada cliente basta selecioná-lo para que suas informações apareçam na coluna central do aplicativo CollA Server. Os hosts cadastrados pelo usuário podem ser detalhados ao clicar sobre o host desejado. No exemplo da Figura 2 temos o cliente Bruno com apenas um host cadastrado (bruno_0). VISUALIZAÇÃO DAS SEÇÕES As sessões de cada usuário podem ser apresentadas no componente sessions da Figura 2. CLIENTE GERAL REALIZAR CADASTRO Para se cadastrar na plataforma você deverá clicar em "Signup" na tela inicial e preencher um formulário com algumas informações pessoais. Em seguida confirme seu cadastro pressionando o botão "Signup". Pronto! Você está cadastrado na plataforma CollA.

Fig3. Cadastro LOGAR Para logar basta entrar com usuário e senha na tela inicial do aplicativo e em seguida no botão "Login". A janela principal do programa irá abrir.

Fig4. Login INFORMAÇÕES DA TELA PRINCIPAL Na tela principal você pode visualizar os contatos do seu grupo que estão online ou off-line. Uma vez selecionado algum contato, você pode visualizar os hosts de tal contato no painel inferior esquerdo na Figura 5. Note que você pode se filiar a vários grupos CollA. No exemplo da Figura 5, o usuário bruno selecionou o grupo Group-test e neste grupo CollA foi escolhido o host bruno_0. O host bruno_0 possui 4 processadores, roda Windows, está cadastrado no Brasil, etc. Na parte inferior da tela são disponibilizadas algumas informações úteis como, por exemplo, se você foi aceito em algum grupo que almeja, se o novo grupo foi criado com êxito, entre outras.

Fig5. GUI do usuário na plataforma CollA GRUPOS CRIAR NOVO GRUPO Para criar um novo grupo você deve selecionar "Groups" na barra de menus e em seguida "Create a group". Insira o nome do grupo e selecione o botão "Create". Você já vai fazer parte deste grupo. Na Figura 6 criamos o grupo Teste. Fig6. Criando um novo grupo CollA

PARTICIPAR DE UM GRUPO JÁ EXISTENTE Para solicitar ingresso em um grupo já existente você deve ir até "Groups->Join a group", pesquisar o grupo desejado, selecioná-lo e então clicar no botão "Join". Lembrando que seu ingresso ao grupo depende da aceitação do administrador do mesmo. Fig7. Filiação a grupos no CollA ACEITAR OU RECUSAR INGRESSO DE MEMBROS NO MEU GRUPO Se você é administrador de algum grupo, você pode verificar se existem solicitações de ingresso pendentes selecionando "Groups->manage my groups". Uma janela será aberta e do lado esquerdo temos uma lista dos usuários que solicitaram ingresso no grupo. Do lado direito temos duas listas, a primeira dos usuários que você deseja aceitar e a segunda dos usuários que você deseja recusar. Para aceitar ou recusar você deve selecionar o usuário desejado e inseri-lo na lista "Accept" ou "Refuse" e em seguida selecionar o botão "APPLY".

Fig8. Aceites ou recusas de participação de membros em grupos CollA VISUALIZAR INFORMAÇÕES DO GRUPO Em "Groups->manage my groups" na aba "Members" você pode visualizar uma lista de membros do grupo e ao selecionar algum membro você visualiza algumas informações sobre o mesmo. Na Figura 9 ilustramos o detalhamento do membro bruno, pertencente ao grupo Group-test.

Fig9. Informações sobre um membro de um grupo CollA CHAT ENVIAR UMA MENSAGEM DE CHAT Chats só podem ser realizados por pessoas do mesmo grupo, portanto para começar um chat com alguém é necessário que vocês estejam no mesmo grupo. Do lado esquerdo da tela principal você deve dar dois cliques sobre o usuário desejado. Uma vez feito isto, uma janela de chat se abre, conforme ilustra a Figura 10. Observe que existe uma aba para cada usuário que você esteja conversando.

Fig10. Chats TASKS ENVIAR UMA TASK Para enviar uma task (um arquivo jar, ear ou war, com ou sem dependências) a ser executada pelo CollA remotamente você deve ir ao menu "File->Send Task". Na janela que abrir você deve primeiramente selecionar o grupo usado para processar a task. Neste caso o CollA seleciona apenas os hosts deste grupo para usar no processamento da task. Em "Task dependencies" você deverá selecionar todos os arquivos "jar" que a task precisa para executar. Clique em add para poder navegar nas pastas de seu sistema de arquivos e escolher. Em "Task arguments (Files)" você deve selecionar todos os arquivos que a task vai manipular durante sua execução, arquivos texto por exemplo. Clique em add para poder navegar nas pastas de seu sistema de arquivos e escolher. Depois destes passos você deve selecionar a task a ser executada (um arquivo jar!). Clique em add para poder navegar nas pastas de seu sistema de arquivos e escolher. Logo em seguida você deve selecionar a classe a ser executada, dentre as classes disponíveis na task, e o método a ser executado, dentre os métodos da classe solicitada. Os argumentos definidos em Task arguments serão usados como parâmetros para o método escolhido, portanto na atual versão só pode executar tasks que não possuam parâmetros ou que estes sejam arquivos de qualquer tipo.

Fig11. Enviando uma task para o CollA executar remotamente usando hosts de algum grupo VER RESULTADOS DAS TASKS Para ver o resultado de alguma task você deve ir até "File->Results" e selecionar o grupo ao qual a task pertence. Uma lista de tasks pertencentes ao grupo é exibida. Selecione a task desejada para visualizar diversas informações da task, assim como o resultado da task. O resultado pode ser persistido na máquina onde o usuário esta operando o CollA, portanto basta clicar em click here to save... para persistir o resultado localmente. Se o resultado for do tipo arquivo (Java File Class) o CollA inclusive oferece a opção de abrir localmente o aplicativo onde tal arquivo poderá ser exibido.

Fig12. Visualizando resultados de tasks submetidas ao CollA LOGOUT Para sair da plataforma você deve fechar o aplicativo simplesmente. HOST GERAL REALIZAR CADASTRO Na primeira vez que você inicializar o host, você terá que cadastrá-lo. Para isso basta inserir as informações do usuário ao qual você deseje vincular o novo host. Note que o usuário já foi cadastrado usando a Figura 3, portanto ao cadastrar um host apenas informe os dados de usuários ou membros já cadastrados. Repita este passo para cada máquina que você almeja colaborar com outros. Cadastre muitas e cobre de seus parceiros a mesma atitude. IMPORTANTE: antes de cadastrar um host você deve ter que cadastrar um usuário.

Fig13. Registrar um host LOGAR Uma vez que você tenha cadastrado a sua máquina como host, ela irá se conectar automaticamente quando o programa for inicializado. INFORMAÇÕES DA TELA PRONCIPAL A tela principal do host nos traz algumas informações como o ID vinculado a ele e algum possível erro de conexão.