Interface Web para um Software de Gerenciamento
de Tarefas em Grids
Trabalho de Conclusão de Curso apresentado à UTFPR como requisito parcial para obtenção do título de Tecnólogo em Desenvolvimento de Sistemas Distribuídos.
Curitiba
2009
Interface Web para um Software de Gerenciamento
de Tarefas em Grids
Trabalho de Conclusão de Curso apresentado à UTFPR como requisito parcial para obtenção do título de Tecnólogo em Desenvolvimento de Sistemas Distribuídos.
Orientador:
Professora Ana Cristina Barreiras Kochem Vendramin
Co-Orientador:
Professor Celso Antônio Alves Kaestner
Curitiba
2009
1 INTRODUÇÃO... 9
1.1 Justificativa e escolha do tema ... 10
1.2 Objetivos do trabalho ... 10
1.3 Conteúdo do trabalho ... 10
2 GRIDS E COMPUTAÇÃO DE ALTO DESEMPENHO ... 12
2.1 Grid ... 12
2.1.1 Arquitetura ... 13
2.1.2 Open Grid Services Architecture ... 16
2.2 Utilitários na computação distribuída de alto desempenho ... 17
2.2.1 Globus Toolkit ... 17
2.2.2 Sun Grid Engine ... 26
3 METODOLOGIA ... 31 3.1 Levantamento de requisitos ... 31 3.2 Recursos empregados ... 31 3.2.1 Recursos financeiros ... 31 3.2.2 Recursos pessoais... 32 3.3 Softwares utilizados ... 32 3.4 Tecnologias utilizadas ... 33 4 RESULTADOS ... 35 4.1 Modelagem... 35 4.1.1 Descrição da arquitetura ... 35 4.1.2 Requisitos ... 36
4.1.3 Diagramas de casos de uso ... 38
4.1.4 Diagrama de classes ... 41
4.1.5 Diagramas de seqüência ... 42
4.1.6 Diagrama entidade-relacionamento ... 46
4.2 Conteúdo dos resultados ... 46
4.3 Implantação ... 54
5 CONCLUSÕES... 57
5.1 Contribuições... 57
5.2 Trabalhos futuros... 57
Figura 2 – Componentes do Globus Toolkit 4 ... 18
Figura 3 – Tarefa executada com o binário globus-job-run ... 23
Figura 4 – Tarefa executa com o binário globus-job-run e opções ... 23
Figura 5 – Job colocado em execução em segundo plano ... 24
Figura 6 – Estado do processo ... 25
Figura 7 – Resultado do processo resgatado ... 25
Figura 8 – Primeira tela do qmon ... 26
Figura 9 – Tela de inicialização de job ... 27
Figura 10 – Lista dos jobs enviados para o cluster ... 28
Figura 11 – Estrutura de controles ... 36
Figura 12 – Diagrama de Casos de Uso ... 38
Figura 13 – Diagrama de Classes ... 41
Figura 14 – Diagrama de seqüência para o caso de uso Autenticar ... 42
Figura 15 - Diagrama de seqüência para o caso de uso Realizar Operação ... 43
Figura 16 - Diagrama de seqüência para o caso de uso Requisitar Resultado ... 43
Figura 17 - Diagrama de seqüência para o caso de uso Alterar Senha ... 44
Figura 18 - Diagrama de seqüência para o caso de uso Fazer Logoff ... 44
Figura 19 - Diagrama de seqüência para o caso de uso Manipular Ação ... 45
Figura 20 – Diagrama Entidade-Relacionamento ... 46
Figura 21 – Caixa de login do sistema ... 47
Figura 22 – Menu com as opções que o usuário tem acesso ... 47
Figura 23 – Alteração de dados ... 48
Figura 24 – Opções do grid com alguns plug-ins carregados ... 48
Figura 25 – “Verificar validade do certificado” ... 49
Figura 26 – “Listar Jobs” ... 49
Figura 27 – “Interações com o grid” com alguns plug-ins carregados ... 50
Figura 28 – “Iniciar job simplificado”... 51
Figura 32 – Adicionar nova informação para o usuário ... 53
Figura 33 – Editar informação já salva ... 53
Figura 34 – Executar informação ... 54
CAS: Community Authorization Service CSS: Cascade Style Sheets
DRS: Data Replication Service
GRAM: Grid Resource Allocation and Management GRIP: Grid Resource Information Protocol
GSI: Grid Security Infrastructure GT4: Globus Toolkit 4
HTML: Hypertext Markup Language HTTP: Hypertext Transfer Protocol IDE: Integrated Development Enviroment LDAP: Lightweight Directory Access Protocol LSF: Loading Sharing Facility
MVC: Model-view-controller
OGSA: Open Grid Services Architecture
OGSA-DAI: Open Grid Services Architecture Data Access and Integration PHP: Hypertext Preprocessor
PID: Process Identifier QoS: Quality of Service RFT: Reliable File Transfer RLS: Replica Location Service
SGBD: Sistema Gerenciador de Banco de Dados SGE: Sun Grid Engine
TCP / IP: Transmission Control Protocol / Internet Protocol UML: Unified Modeling Language
W3C: World Wide Web Consortium
RESUMO
O objetivo deste trabalho é o desenvolvimento de um sistema de interface web para o conjunto de serviços que gerencia as tarefas no grid
Globus Toolkit. Será possível a realização de diversas tarefas que podem
ser feitas via Globus Toolkit, com o diferencial que para fazê-las o usuário contará com uma interface mais amigável, excluindo boa parte da necessidade de conhecimento técnico, além de ser possível adequar o sistema para as necessidades do usuário. Haverá também a possibilidade de acesso e operação de um grid a partir de qualquer lugar do planeta usando apenas um navegador internet.
1 INTRODUÇÃO
No mundo atual, principalmente devido às facilidades e ao barateamento nos custos operacionais da internet, os sistemas feitos para serem acessados e administrados usando este meio de comunicação estão cada vez mais comuns.
Paralelo a isso, no universo da computação de alto desempenho o papel principal mais recentemente é desempenhado pelos clusters. O tipo mais comum de cluster, o Beowulf, é um conjunto de computadores cuja principal diferença para os grids está no fato de os primeiros operarem sempre em conjunto, havendo uma centralização na infra-estrutura (JATIT, 2009).
A estrutura de grid abre a possibilidade para que seja heterogênea, ou seja, um grid pode ser formado com os mais variados tipos de plataformas, sendo possível formar um grid com vários clusters, como descrito por ABBAS, 2004. Por esta razão, contrapondo ao fato de que, normalmente, os clusters são formados por máquinas dedicadas apenas a trabalhar como um supercomputador, excetuando-se em alguns casos na utilização de arquiteturas como OpenMoxis (SLOAN, 2004), e, decorrente disso, na possibilidade que se há nos grids de utilizar recursos de máquinas ociosas a maior parte do tempo, a alternativa torna-se interessante financeiramente, já que representa uma economia de custos (WELLINGTON, 2007).
Neste contexto, a integração desses dois pontos da informática mostrou-se viável através de uma integração de um sistema web que trabalhasse com um grid na medida em que não há, até o presente momento, uma solução com as especificações utilizadas como essa no mercado.
1.1 Justificativa e escolha do tema
Dentro da computação em larga escala, os grids cada vez ganham mais espaço, assim como a web hoje em dia é utilizada por pessoas de todos os segmentos.
Não seria de se estranhar em haver a necessidade de usuários sem tanto conhecimento técnico de utilizar o potencial dos recursos de um grid. Logo, se ele pudesse lidar com algo que é mais familiar como normalmente é o ambiente web, seria de toda valia.
1.2 Objetivos do trabalho
O projeto tem como objetivo principal desenvolver um sistema web para fazer o gerenciamento de tarefas e operações num grid. Ele se utilizará de uma interface web amigável para realizar operações que necessitariam de conhecimento específico apurado do utilizador além de demandar algum tempo, o que refletiria diretamente na produtividade do usuário.
A melhoria na interface e a automatização de tarefas, tudo de forma transparente, estão nos principais pilares deste projeto.
1.3 Conteúdo do trabalho
Este trabalho é dividido em seis capítulos. O primeiro e presente capítulo descreve a introdução, a apresentação do tema, justificativa e objetivos. O segundo capítulo trabalha com as definições de grid e algumas ferramentas. No capítulo três o desenvolvimento do projeto é abordado na forma de explicação das ferramentas e das tecnologias utilizadas. O quarto capítulo descreve os resultados finais que foram conseguidos no presente projeto, além de detalhes técnicos do resultado final. No quinto e sexto capítulo, as conclusões do projeto são colocadas em pauta. Além disso,
situações como o desenvolvimento posterior através de projetos futuros também são propostos.
2 GRIDS E COMPUTAÇÃO DE ALTO DESEMPENHO
O objeto do presente capítulo é fazer um apanhado geral a respeito do estado em que a tecnologia de grids se encontra além de definir conceitos chaves no estudo da ferramenta Globus Toolkit.2.1 Grid
De acordo com Buyya (2002), grid é um tipo de sistema distribuído que permite compartilhamento, seleção e agregação dinâmica de recursos autônomos e distribuídos geograficamente em função da disponibilidade, capacidade, performance, custo e requerimentos de qualidade de serviço (QoS – Quality of Service) do usuário, termo que define a garantia na entrega de pacotes para a aplicação.
Foster (2002) elabora uma lista de características que os sistemas deveriam seguir para serem considerados um grid. Os pontos citados pelo autor são os seguintes:
• Coordenação de recursos descentralizada: um grid deve integrar e coordenar recursos e usuários em diferentes níveis, além de lidar com questões de segurança e políticas internas;
• Utilização de interfaces e protocolos padrões, de código aberto: o
grid é necessita de serviços de autenticação, autorização,
descoberta de recursos e acesso aos recursos;
• Oferta de um sistema não trivial de QoS: os recursos do grid devem oferecer os mais diversos tipos de qualidade de serviço, tais como: tempo de resposta, vazão de dados, disponibilidade, segurança e alocação de diversos tipos de recursos para atender às mais complexas demandas dos usuários. Em relação aos
cluster, esse é o diferencial, já que a arquitetura de cluster não
2.1.1 Arquitetura
A arquitetura proposta para grid, mais aceita entre os autores da área, constitui-se em um conjunto de camadas que são denominadas, da mais alta para mais baixa: fabricação, conectividade, recurso, coletiva e aplicação.
Figura 1 – Arquitetura grid
Nas seções a seguir estão descritas as camadas da arquitetura grid. 2.1.1.1 Fabricação
A camada mais baixa da arquitetura, a camada de fabricação do grid, provê os recursos para os quais o acesso é mediado pelos protocolos do
grid: recursos computacionais, sistema de armazenamento, catálogos e
recursos de rede.
Essa camada deve implementar as operações locais, agindo justamente sobre os recursos físicos ou lógicos.
Por esta razão, quanto mais rica for a implementação de funções nesta camada, mais sofisticada serão as operações de compartilhamento, do mesmo modo que, com menos recursos na camada de fabricação, reflete numa infra-estrutura mais simples.
O mínimo que essa camada deve implementar são:
• Mecanismos de busca: funções de descoberta da própria estrutura, estado e capacidades;
• Mecanismos de armazenamento de recursos para prover qualidade de serviço.
Há também outros recursos que podem ser inseridos como, por exemplo, os mecanismos de recursos computacionais para controle de processos.
2.1.1.2 Conectividade
A camada de conectividade define o centro dos protocolos de autenticação e comunicação que são necessários nas transações de rede específicas do grid.
Os protocolos de comunicação permitem a troca de dados entre recursos da camada de fabricação. Já os protocolos de autenticação constroem sobre os serviços de comunicação mecanismos de segurança criptografados para verificar a identidade dos usuários e recursos.
A comunicação inclui transporte, roteamento e gerenciamento de nomes, que normalmente é utilizada a pilha do protocolo TCP/IP (Transmission Control Protocol/ Internet Protocol), embora não seja obrigatório.
As soluções relacionadas com autenticação devem possuir as seguintes características:
• Autenticação única: os usuários devem entrar com os dados de autenticação apenas uma vez, e depois ter o acesso aos recursos do grid;
• Autorização: um usuário deve ser capaz de executar um programa de acordo com as suas permissões, sendo que este programa acessará apenas os recursos autorizados;
• Integração com as soluções locais de segurança: questões de segurança em níveis acima devem ser respeitadas;
• Relações de confiança baseadas no usuário: Quando um usuário for utilizar os recursos de vários provedores ao mesmo tempo, deve ocorrer sem que haja a necessidade de uma nova autenticação.
2.1.1.3 Recursos
A camada de recursos constrói sobre a camada de conectividade protocolos de comunicação e autenticação para obter negociações seguras, iniciação, monitoramento, controle, contabilidade e pagamento de recursos individuais. As implementações dos protocolos citados nesta camada, utilizam a camada de fabricação para acessar e controlar os recursos locais.
Duas classes primárias dos protocolos da camada de recursos podem ser citados:
• Protocolos de informação: usados para obter informações da estrutura e do estado do recurso como, por exemplo, sua configuração atual e sua carga atual;
• Protocolos de gerenciamento: usados para negociar o acesso aos recursos compartilhados.
2.1.1.4 Coletiva
Enquanto a camada de recursos é focada nas interações com um único recurso, a camada coletiva contém protocolos e serviços que não são associados com apenas um dos recursos, mas são globais e capturam interações de vários recursos do grid.
Alguns exemplos de protocolos dessa camada são:
• Serviços de Diretório: permitem a descoberta da existência e/ou das propriedades dos recursos da organização virtual;
• Serviços de monitoramento e diagnósticos: ajudam no monitoramento dos recursos da organização virtual para solucionar problemas relacionados a falhas arbitrárias, ataques e sobrecarga;
• Serviços de replicação de dados: auxiliam no armazenamento dentro da organização virtual, para melhorar a performance no acesso aos dados.
2.1.1.5 Aplicação
A última camada da arquitetura do grid é a camada de aplicação. Ela compreende as aplicações do usuário que operam no ambiente de uma organização virtual.
2.1.2 Open Grid Services Architecture
Um sistema grid pode ser constituído de vários e diferentes componentes, como por exemplo, serviço de descoberta de recursos, de manipulação de processos, gerenciamento de dados, entre outros. Esses serviços vão interagir constantemente, podendo causar certa desordem se existirem muitos destes serviços trabalhando ao mesmo tempo,
principalmente se eles forem implementados cada um de uma forma, inviabilizando assim o trabalho em conjunto.
Houve então a padronização, através da definição de uma interface que todos deveriam seguir. A Global Grid Forum desenvolveu a OGSA (Open Grid Services Architecture), uma arquitetura padrão, comum e aberta para grids (SOTOMAYOR; CHILDERS 2005).
A tecnologia escolhida para o OGSA foi a Web Service, que reflete em duas principais vantagens: primeiro na possibilidade de se definir um padrão para que num sistema formado por diversos tipos de máquinas; segundo no fato de que ao utilizar web service abre-se a possibilidade de explorar outras ferramentas e serviços externos, já que é um padrão amplamente adotado (TUECKE et al., 2002).
Ele foi adotado pela Globus Alliance em setembro de 2003, a partir da versão 3.0 do Globus Toolkit.
2.2 Utilitários na computação distribuída de alto desempenho
Nesta seção estão descritas duas ferramentas principais utilizadas na computação de alto desempenho: o Globus Toolkit e o Sun Grid Engine. 2.2.1 Globus ToolkitO Globus Toolkit é um conjunto de ferramentas de código aberto desenvolvido e distribuído pela Globus Alliance para a computação em grid. Esse conjunto de ferramentas inclui softwares para segurança, para infra-estrutura de informações, gerenciamento de recursos, gerenciamento de dados, comunicação, tolerância a erros e portabilidade (FOSTER; KESSELMAN, 2001).
Essas ferramentas podem ser utilizadas tanto de forma independente como de forma conjunta no desenvolvimento de aplicações em grid.
Os serviços implementados pelo Globus toolkit são considerados serviços de alto nível. Por serem de alto nível, os desenvolvedores podem utilizá-los para construir suas aplicações.
A Figura 2 ilustra os componentes do Globus Toolkit, que por conveniência são divididos em cinco categorias: segurança, gerenciamento de dados, gerenciamento de execução, serviços de informação e bibliotecas comuns. Os principais componentes do Globus Toolkit estão descritos nas próximas seções.
Figura 2 – Componentes do Globus Toolkit 4
2.2.1.1 Segurança
Os componentes de segurança do GT4, que em conjunto são chamados de Grid Security Infrastructure, facilitam a comunicação segura e a utilização das políticas de segurança nas aplicações.
Os principais componentes de segurança são (FOSTER; 2006): • Serviço de Autorização da Comunidade: há a possibilidade de se
utilizar o serviço chamado Community Authorization Service (CAS) para fazer todo o gerenciamento de políticas de autorização de utilização dos recursos de um grid.
• Autenticação e autorização: são as bibliotecas e ferramentas de controle de acesso aos recursos e serviços. Há também um
framework que permite o uso de métodos escritos pelo usuário
relacionados com autenticação e autorização;
• Gerenciamento de credenciais: o gerenciamento das credenciais dos usuários dentro do grid pode ser feito de uma forma padrão com a utilização do SimpleCA, ou então com uma credencial personalizada;
• Delegação de tarefas: O GT4 possui um serviço que é responsável por autorizar ou não, através de credenciais em um ambiente, a delegação de tarefas para outro ponto. Além disso, nesse quesito, enquadra-se também a questão da única autenticação. Esses dois só são possíveis graças aos chamados
proxy certificates, que utilizam os conceitos de chaves de
segurança para autenticação e através dessa autenticação delegar serviços de um ao outro.
2.2.1.2 Gerenciamento de dados
Os componentes de gerenciamento de dados do Globus Toolkit provêm a descoberta, transferência e acesso a arquivos principalmente de grandes volumes.
Os principais componentes da parte de gerenciamento de dados são: • GridFTP: componente para transferência de dados, otimizado
para grande quantidade de dados entre hosts.
• Reliable File Transfer (RFT): sistema que se utiliza internamente do GridFTP para fazer a transferência de grande quantidade de dados, possuindo alguns recursos a mais que o próprio GridFTP, como por exemplo a possibilidade de se continuar uma transferência interrompida;
• Localização de replicações: o Replica Location Service (RLS) permite ao usuário saber onde estão localizadas as replicações de dados na organização virtual;
• Replicação de dados: o Data Replication Service (DRS) usa o RLS e o RFT para garantir que as réplicas estarão disponíveis para quem precisar delas;
• OGSA-DAI: o OGSA Data Access and Integration (OGSA-DAI) provê acesso e faz a integração das mais diversas fontes de dados que o grid pode ter.
2.2.1.3 Gerenciamento de execução
O gerenciamento de execução gerencia a execução, o escalonamento e o monitoramento das tarefas no grid.
No gerenciamento de execução, pode-se destacar (SOTOMAYOR; CHILDERS, 2005):
• Grid Resource Allocation and Management (GRAM): a principal função do GRAM é fornecer os serviços de monitoramento e execução das tarefas. Ele é o principal componente desta seção; • Community Scheduler Framework: fornece uma interface com
escalonadores de processos diferentes, como o Condor (THAIN; TANNENBAUM; LIVNY, 2003), LSF (Loading Sharing Facility) (FEITELSON; RUDOLPH, 1995) ou o SGE (Sun Grid Engine) (GENTZSCH, 2001);
• Workspace Management: componente que fornece ao utilizador a possibilidade de gerenciar todas as formas de workspaces no grid. 2.2.1.4 Serviços de Informação
Os serviços de informação servem para monitorar e descobrir recursos na organização virtual. São também conhecidos como serviços de descoberta.
2.2.1.5 Bibliotecas comuns
As bibliotecas comuns são ferramentas e bibliotecas desenvolvidas para várias linguagens de programação que servem para os desenvolvedores criar novos serviços para serem usados e integrados ao
2.2.1.6 Globus toolkit e a arquitetura grid
Foster (2001) ao propor as camadas do Globus Toolkit faz um estudo de como o Globus se enquadra:
• Fabricação: o GT foi feito para primeiramente utilizar dos componentes de fabricação implementados pelo distribuidor. Caso não haja um disponível, ele implementa a própria funcionalidade; explicar melhor
• Conectividade: os protocolos utilizados nesta camada são os protocolos da pilha TCP/IP. O protocolo baseado na chave pública da Grid Security Infrastructure (GSI) é utilizado para autenticação, proteção da comunicação e autorização. O GSI também participa da composição do protocolo de segurança da camada de transporte, para gerenciar as características como a autenticação única, a autorização e a integração com as soluções locais de segurança;
• Recurso: para os protocolos de informação, é utilizado o Grid
Resource Information Protocol (GRIP). Já para o gerenciamento
de recursos, é utilizado o GRAM;
• Coletiva: entre outros, essa camada provê serviços como Meta
Directory Server, que é utilizado em serviços de diretório, com
alguns pontos em comum com o LDAP (Lightweight Directory
Access Protocol), na questão de arquitetura (SCIBILIA 2008).
2.2.1.7 Análise do funcionamento
Nesta seção são analisadas algumas ferramentas presentes no
Globus Toolkit, não se atentando para configurações do servidor.
Os arquivos binários disponíveis para realizar as operações do
Globus Toolkit executam apenas em modo texto, ou seja, não há nenhuma
Uma tarefa como a de iniciar um processo deve ser executada com o binário globus-job-run que de forma simples pode executar um processo como ilustrado na Figura 3.
Figura 3 – Tarefa executada com o binário globus-job-run
A Figura 3 mostra o binário /bin/date enviado para o host ubuntu. Esse processo é executado de forma simples e seu resultado é retornado.
Dependendo do ambiente em que o usuário do sistema se encontra pode até ser viável executar uma série de comandos dessa forma, mas nesse caso aumenta-se a complexidade do comando com parâmetros adicionais (ver Figura 4).
Na Figura 4 a tarefa é executada com o globus-job-run com parâmetros adicionais que limitam em um minuto a execução, utilizam o diretório /bin como diretório ativo e se repetem por cinco vezes.
Colocar jobs na fila ou em execução em segundo plano é uma tarefa recorrente na computação de alto desempenho. No caso do Globus Toolkit isso pode ser feito utilizando o binário globus-job-submit, conforme é mostrado na Figura 5.
Figura 5 – Job colocado em execução em segundo plano
Na Figura 5 o job foi colocado em execução em segundo plano e foi retornado o PID (Process Identifier) que identifica o processo. É a partir deste PID que se pode continuar trabalhando com o processo em questão.
O estado do job pode ser acompanhado utilizando o binário
Figura 6 – Estado do processo
Na Figura 6 o estado de execução do processo é mostrado. No caso, a palavra “DONE” representa que o processo foi executado sem erros. Caso o processo já tenha sido executado sem problemas (como ilustrado na Figura 6) e haja o interesse em resgatar o resultado dele, deve ser utilizado o binário globus-job-get-output (ver Figura 7).
Figura 7 – Resultado do processo resgatado
Na Figura 7 o resultado do processo é resgatado. Ele é impresso, em seguida, e pode ser resgatado quantas vezes for necessário.
2.2.2 Sun Grid Engine
O Sun Grid Engine (SGE) é um escalonador de processos, utilizado principalmente para clusters e grids (GENTZSCH, 2001). Ele é desenvolvido e mantido pela Sun Microsystem. Seu objetivo é controlar filas e processos, distribuir processamento, gerenciar permissões de usuários e outras atividades comuns nesses sistemas.
O SGE possui uma interface gráfica chamada qmon. Através desse software é possível realizar todas as ações possíveis em linha de comando, mas com o auxílio da interface gráfica, conforme ilustra a Figura 8.
Figura 8 – Primeira tela do qmon
As funções do qmon são ligadas através de botões com ícones que não são intuitivos.
Como o foco deste projeto está no desenvolvimento de uma interface gráfica web, a análise dos pontos fracos e fortes será feita em cima do utilitário qmon, considerando os recursos possíveis ao programa.
2.2.2.1 Análise do Programa
A primeira tela do programa SGE possui uma série de botões que direcionam o usuário para janelas secundárias de acordo com cada função. Dentro dessas funções, os recursos possíveis e disponíveis do SGE são inseridos.
Ao se inicializar um processo em uma das telas, há a possibilidade de se acompanhar em outra janela, conforme as Figura 9 e 10.
Figura 9 – Tela de inicialização de job
A Figura 9 mostra a tela de inicialização de um job no qmon. Nela há a possibilidade de se inserir diversas informações específicas a respeito do que deve ser iniciado, tais como: script, argumentos, prioridade.
Figura 10 – Lista dos jobs enviados para o cluster
Na Figura 10 são listados os jobs que estão pendentes e que foram enviados pela tela mostrada na Figura 9. Para cada job são incluídos a sua prioridade, identificação, o proprietário, o dono, o estado, além da situação no cluster.
2.2.2.2 Usabilidade
A Tabela 1 mostra os atributos de usabilidade analisados durante a realização dos testes com o programa qmon, utilizando uma métrica de 1 a 5 onde 1 significa nada satisfeito e 5 completamente satisfeito.
Tabela 1. Usabilidade do qmon
Atributo Valor
Facilidade de aprendizado 4 Eficiência de uso 3 Facilidade de memorização 2 Baixa taxa de erros 3 Satisfação subjetiva 4
2.2.2.3 Pontos fortes
A riqueza de opções que o programa oferece é o ponto forte a se destacar no qmon. Todo o escopo de opções oferecido pelo SGE é abrangido pela interface gráfica.
Além de conseguir atingir todas as possibilidades de uma forma geral, é possível também passar como parâmetro todas as opções. Em alguns casos isso também pode ser considerado um ponto fraco, já que para a maioria das operações não seria necessário o preenchimento de todos os campos.
Há também a vantagem de que quando o usuário executa o programa ele não precisa informar mais nenhum outro dado de autenticação, na medida em que a primeira autenticação é válida por toda a seção.
2.2.2.4 Pontos fracos
Na tela inicial do qmon você tem uma grande quantidade de botões sem descrição de sua funcionalidade. Para saber a função de cada um dos botões o usuário tem que interpretar os ícones que são bastante subjetivos ou então rolar o mouse por cima para ler a descrição que aparece.
Quando clicado em algum dos botões, a tela de cada opção contém muitas informações e, em alguns casos, o excesso de opções – que muitas vezes não são obrigatórias – pode causas problemas de usabilidade ao usuário, conforme mostra a Figura 9.
A falta de explicação de como agir em cada tela pode prejudicar o trabalho de um usuário inexperiente. Algumas dicas em lugares pontuais seriam de boa valia.
3 METODOLOGIA
Neste capítulo o foco principal é mostrar a metodologia empregada no desenvolvimento do sistema.
3.1 Levantamento de requisitos
O levantamento de requisitos no projeto foi feito considerando dois pilares principais: as funcionalidades do Globus Toolkit e as interações possíveis do gerenciador gráfico do Sun Grid Engine.
Para as ferramentas do Globus Toolkit, grande parte de suas funções, apenas disponíveis por linha de comando foram trazidas para o ambiente web.
Com o qmon, gerenciado gráfico do SGE, o tratamento foi diferente, ele foi usado como referência de gerenciador gráfico de funcionalidades de uma máquina de alto desempenho. A partir dele, conclusões principalmente a respeito da usabilidade do sistema foram obtidas.
3.2 Recursos empregados
Nesta seção estão listados os recursos empregados para o desenvolvimento do sistema separados por grupo.
3.2.1 Recursos financeiros
Uma vez que as tecnologias empregadas para o desenvolvimento do
software são de utilização gratuita, tanto as linguagens quanto as
ferramentas de desenvolvimento, não houve nenhuma aplicação de recursos financeiros com o custeamento de ferramentas ou licença de aplicativos.
Também não houve gastos com a questão estrutural do projeto, afinal toda a estrutura necessária já estava disponível anteriormente e não foi adquirida exclusivamente para este projeto.
3.2.2 Recursos pessoais
Para o desenvolvimento do sistema em si, o pessoal alocado para o desenvolvimento da ferramenta, foi de apenas um aluno do curso de Tecnologia em Desenvolvimento de Sistemas Distribuídos.
3.3 Softwares utilizados
A seguir é apresentada uma breve descrição das ferramentas utilizadas na implementação do projeto:
• Eclipse (3.3.2) com PHP Development Tools (1.0.3): o Eclipse é uma ferramenta poderosa de desenvolvimento desenvolvida em Java, portanto multi-plataforma. Focada principalmente no desenvolvimento Java, essa IDE (Integrated Development
Environment) possui plug-ins e adaptações para outras
linguagens, como o PHP, e hoje está entre as ferramentas mais utilizadas pelos desenvolvedores também desta linguagem. Sua licença é gratuita (BURNETTE, 2005). O desenvolvimento de toda a ferramenta foi feita basicamente em cima desta IDE;
• PostgreSQL (8.2): é um sistema gerenciador de banco de dados relacional. Sua licença é gratuita (DOUGLAS, 2005). Pequenas implementações utilizaram este banco de dados para gravar as informações, no caso os procedimentos salvos pelo usuário;
• Apache HTTP Server (2.2): o Apache HTTP Server é um servidor para o protocolo HTTP (Hypertext Transfer Protocol) que também é distribuído gratuitamente (LAURIE; LAURIE, 2002). O servidor
em que o sistema foi implementado utilizava o Apache com o PHP instalado;
• Jude Community (5.3): o Jude Community é a versão gratuita de outro editor de UML (Unified Modeling Language), o Jude (JUDE, 2009). Os diagramas UML do sistema foram feitos utilizando este
software;
• Interpretador PHP (5.2.5): o interpretador PHP é gratuito e é executado em conjunto com o apache para interpretar os comandos da linguagem de programação PHP (LERDORF; MACINTYRE, 2006).
3.4 Tecnologias utilizadas
Como o projeto se trata de um sistema com ambiente web, algumas tecnologias devem ser aplicadas obrigatoriamente, como o HTML (Hypertext
Markup Language) auxiliado pelo CSS (Cascade Style Sheets). Essas duas
tecnologias tem suas boas práticas de uso regidas pela W3C. O detalhamento dessas e outras tecnologias são fornecidos na seqüência:
• HTML: é a linguagem interpretada pelo navegador internet para construir páginas (MUSCIANO; KENNEDY, 2006). Na sua versão atual em relação à anterior, algumas práticas foram abandonadas e não recomendadas, o que fez com que surgisse o XHTML (Extensible Hypertext Markup Language) que é a forma recomendada de aplicação do HTML (MUSCIANO; KENNEDY, 2006);
• CSS: são os estilos que definem como o HTML será construído na página, nas questões de aparência (fonte, cores) e de posicionamento tal como a relação entre os elementos do código. (MEYER, 2006);
• Javascript: é uma linguagem de script utilizada para prover interatividade às páginas HTML (FLANAGAN, 2006);
• PHP (Hypertext Preprocessor): É uma linguagem de programação projetada normalmente para utilização na internet, que é interpretada pelo servidor HTTP, através da instalação de um interpretador (LERDORF; MACINTYRE, 2006).
• Jquery: é uma biblioteca de código aberto feita para facilitar e simplificar o desenvolvimento de aplicações web que utilizem recursos de Javascript e CSS (CHAFFER; SWEDBERG, 2009).
4 RESULTADOS
Neste capítulo são colocadas questões acerca do que foi desenvolvido no projeto. Tanto questões de implementação quanto de projeto são abordados, embora o foco seja realmente o resultado final.
4.1 Modelagem
A modelagem listada a seguir foi feita observando os padrões da Análise Orientada a Objetos. São descritos os processos e diagramas correspondentes apresentados em seqüência.
4.1.1 Descrição da arquitetura
Tendo em vista que o sistema do projeto é feito para web, a arquitetura não poderia ser outra a não ser cliente-servidor. No desenvolvimento, o padrão de arquitetura foi utilizado o MVC
(Model-view-controller, em português Modelo-Apresentação-Controle) (BUSCHMANN et
al., 1996).
No padrão MVC, através do qual as três camadas do projeto foram desenvolvidas (ver Figura 11): modelo: a camada que interage diretamente com o grid; controle: os programas que tratam e encaminham as requisições ao modelo; apresentação: as páginas em HTML.
Figura 11 – Estrutura de controles
4.1.2 Requisitos
São apresentados a seguir os requisitos do projeto, separado como: requisitos funcionais e requisitos não-funcionais.
4.1.2.1 Requisitos não-funcionais
Os principais requisitos não-funcionais são:
• Os usuários são autenticados pelo próprio sistema de autenticação do Globus Toolkit, não mantendo nada em banco de dados relacionado com autenticação;
• Suas sessões são relacionadas com a sua autenticação, e, por essa razão, nenhuma ação será possível sem a autenticação inicial;
• Por ser web, o sistema será multiplataforma, sendo que sua utilização será independente do sistema operacional do cliente; • O atraso de resposta a um comando será minimizado ao máximo,
para dar ao sistema maior confiabilidade, em dados com alteração de valores;
• Informações constantes e utilizadas em várias partes do programa e que são diferentes em cada implantação, serão mantidas em arquivos de configuração em separado. São enquadrados nessa situação dados de autenticação, dados de conexão com o banco de dados entre outros;
• As funcionalidades do grid serão desenvolvidas a parte como
plug-ins. Cada plug-in conterá informações a respeito de uma
funcionalidade desempenhada por algum binário presente no
Globus Toolkit, além de conter informações como parâmetros.
• Para o projeto atual, serão implementadas funcionalidades pontuais, mas haverá documentação para implementação de funcionalidades secundárias, sempre a partir dos binários disponibilizados pelo Globus Toolkit.
4.1.2.2 Requisitos funcionais
A lista dos requisitos funcionais feita para o projeto é:
• O usuário ao acessar o sistema deve fornecer um login e uma senha, para aí então ter acesso ao sistema. Ele pode sair do sistema quando desejar;
• Ao ser autenticado, é mostrada uma lista de ações que o usuário pode realizar, e em cima da lista de ações, ele poderá realizar ações no grid;
• O resultado da operação deverá ser requisitado pelo usuário, quando executar uma operação;
• Será permitido ao usuário alterar sua senha depois de autenticado;
• O usuário poderá criar e gerenciar ações pessoais, dentro das funcionalidades que possui instalada, e executá-las quando desejar.
4.1.3 Diagramas de casos de uso
A Figura 12 ilustra o diagrama de casos de uso relacionado com os requisitos funcionais do sistema.
Figura 12 – Diagrama de Casos de Uso
Os casos de uso ilustrados na Figura 12 são descritos de uma forma mais clara nas próximas seções.
4.1.3.1 Autenticar
Descrição: funcionalidade que o usuário entra com seu usuário e senha para utilizar o sistema.
Pós-condições: o resultado para este caso de uso é mostrar o resultado da operação, caso ele tenha digitado dados válidos, ele será redirecionado para a página com as funções disponíveis.
Tratamento de exceções: em caso de dados inválidos, o erro será indicado.
4.1.3.2 Realizar operação
Descrição: permite que o usuário realize alguma operação (genérica) no grid.
Pré-condições: para executar esse caso de uso, o usuário deve estar previamente autenticado.
Pós-condições: a resposta imediata é mostrada ao usuário. Caso ele deseje uma resposta maior, deve executar o caso de uso Requisitar Resultado.
Tratamento de exceções: caso algum parâmetro inválido seja passado, será mostrado erro na tela.
4.1.3.3 Requisitar Resultado
Descrição: permite ao usuário resgatar um resultado de uma operação mais longa no grid.
Pré-condições: além de estar autenticado, o usuário deve ter realizado uma operação através do caso de uso Realizar Operação na mesma sessão.
Pós-condições: o resultado armazenado é mostrado ao usuário de forma completa.
Tratamento de exceções: caso seja requisitado o resultado de algo inválido, será mostrado erro na tela.
4.1.3.4 Alterar senha
Descrição: permite ao usuário alterar a sua senha de autenticação no sistema.
Pré-condições: o usuário precisa estar autenticado e deve passar como parâmetro dessa operação, a senha atual.
Pós-condições: caso a senha passada pelo usuário nas pré-condições seja reconhecida realmente como a senha atual do usuário, será alterada a senha para a nova senha.
Tratamento de exceções: caso seja passada uma senha atual errada, será mostrado o erro. Se houver alguma falha e a senha não puder ser trocada, será mostrada uma mensagem.
4.1.3.5 Fazer logoff
Descrição: permite ao usuário sair do sistema, de forma com que a sessão seja quebrada.
Pré-condições: para executar esse caso de uso, o usuário deve estar previamente autenticado.
Pós-condições: qualquer sinal de autenticação do usuário é quebrado e ele é redirecionado para a página de login.
Tratamento de exceções: caso a sessão já tenha sido interrompida não será mostrada mensagem alguma, apenas feito o redirecionamento para a página inicial.
4.1.3.6 Manipular ação
Descrição: permite ao usuário manipular suas ações pessoais gravadas, seja adicionando novas, editando, removendo ou executando.
Pré-condições: para executar esse caso de uso, o usuário deve estar previamente autenticado.
Pós-condições: dependendo do caso, o resultado da operação. No caso de execução, o caso de uso Realizar Operação é chamado.
Tratamento de exceções: caso não seja possível se comunicar com o banco, será mostrada mensagem. Caso algum parâmetro inválido seja passado, um erro será mostrado.
4.1.4 Diagrama de classes
O Diagrama de Classes previsto para este projeto possui quatro classes principais no desenvolvimento do projeto. As relações entre elas estão ilustradas na Figura 13.
Figura 13 – Diagrama de Classes
As classes Operacao e OperacaoResultado possuem os procedimentos em si. As operações e o resultado delas são manipulados através de instâncias das duas. A partir da classe OperacaoUsuario é possível fazer as operações com relação ao banco de dados, na questão de salvar, editar e remover operações particulares do usuário.
Atuando diretamente com o grid, está a classe ShellGlobus, que armazena informações da conexão com o Globus Toolkit e assim consegue realizar as operações interpretando as instâncias da classe Operacao e retornando OperacaoResultado.
A classe Usuario manipula as ações do usuário, de fazer o login,
logout e alteração de senha, além de servir como referência para quem
realizou alguma determinada operação. 4.1.5 Diagramas de seqüência
Foram desenvolvidos diagramas de seqüência para cada caso de uso, de acordo com as ações descritas nos contratos na seção 4.1.3.
Figura 15 - Diagrama de seqüência para o caso de uso Realizar Operação
Figura 16 - Diagrama de seqüência para o caso de uso Requisitar
Figura 17 - Diagrama de seqüência para o caso de uso Alterar Senha
As Figuras 14, 15, 16, 17 e 18 possuem em comum o fato de as informações passadas pela apresentação para o controle serem processadas e enviadas para o Globus Toolkit através da classe
ShellGlobus. Por via dessa classe, a resposta é devolvida, tratada
novamente no controle e passada ao usuário na apresentação.
Há ainda outra possibilidade, caso haja interação com o banco de dados como no caso de uso Manipular Ação. Para esse caso de uso foi construído outro diagrama de sequência (ver Figura 19).
Figura 19 - Diagrama de seqüência para o caso de uso Manipular Ação
No diagrama apresentado na Figura 19 os dados são armazenados ou tratados no banco de dados, ao contrário dos outros diagramas de seqüência anteriores que interagem diretamente com o grid.
4.1.6 Diagrama entidade-relacionamento
A Figura 20 ilustra as relações entre as entidades do sistema que possui correspondência no SGBD (Sistema Gerenciador de Banco de Dados).
Figura 20 – Diagrama Entidade-Relacionamento
Os parâmetros das operações salvas no banco de dados são relacionados em N para 1 com uma operação. Uma operação pode ter 0 ou infinitos parâmetros.
4.2 Conteúdo dos resultados
O principal produto do projeto é um sistema para gerenciamento de tarefas no ambiente grid.
Ao acessar o sistema, o usuário deve obrigatoriamente fazer a autenticação. Para que seja validado, ele deve entrar com um usuário válido no sistema e que possua acesso autorizado no Globus Toolkit. O usuário deve inserir também a senha do Globus, conforme é mostrado na Figura 21.
Figura 21 – Caixa de login do sistema
Caso o usuário possua os dados necessários para fazer a autenticação obrigatória do sistema, ele será direcionado para a tela inicial que contém informações a respeito das ações que ele pode executar (ver Figura 22).
Figura 22 – Menu com as opções que o usuário tem acesso
A opção do menu “Alterar dados” leva para a página de alteração de dados pessoais para que o usuário possa por exemplo alterar a sua senha do Globus Toolkit (ver Figura 23).
Figura 23 – Alteração de dados
Em “Opções do grid”, o usuário tem acesso às informações do grid que estão disponíveis para consulta (ver Figura 24). Essas opções são carregadas através dos plug-ins, e são consideradas as opções que não recebem parâmetros e sendo assim, tem a mesma chamada todas as vezes.
Os links “Verificar validade de certificado” e “Listar jobs” direcionam para as implementações dos plug-ins.
A Figura 25 ilustra o resultado quando o usuário clica nas opções “Verificar validade de certificado” e, na sequência, “Realizar Operação”.
Figura 25 – “Verificar validade do certificado”
Ainda no menu “Opções de grid” caso seja clicado na opção “Listar
Jobs” a tela mostrada é ilustrada na Figura 26.
Na Figura 26, são listados os jobs enviados. É mostrado o identificador, o comando que foi utilizado, a data de envio e o estado. A partir dali é possível carregar o resultado.
Em “Interações com o Grid” (ver Figura 27) as ações que o usuário tem acesso são disponibilizadas. Essas opções também são carregadas através dos plug-ins e necessitam de parâmetros em número variado. Os
links “Iniciar job simplificado”, “Iniciar job fila” e “Resgatar resultado de job”
direcionam para as implementações dos plug-ins.
Figura 27 – “Interações com o grid” com alguns plug-ins carregados
Na Figura 28 é mostrado o plug-in implementado “Iniciar job simplificado”, após ser clicado no botão “Realizar Operação”.
Figura 28 – “Iniciar job simplificado”
A Figura 29 ilustra o plug-in implementado “Iniciar job fila”, que coloca o job na fila de execução.
Figura 29 – “Iniciar job fila”
Para resgatar o resultado da operação colocada na fila (ver Figura 29) é utilizada a opção “Resgatar resultado de job”, mostrada na Figura 30.
Figura 30 – “Resgatar resultado de job”
Na guia “Minhas informações” as ações salvas pelo usuário estão disponíveis para edição, exclusão e execução, conforme ilustram as Figuras 31, 32, 33 e 34.
Na Figura 31 é mostrada a lista de ações pessoais salvas de um usuário.
A Figura 32 ilustra a ação de adicionar uma nova informação para o usuário.
Figura 32 – Adicionar nova informação para o usuário
A Figura 33 mostra a ação de clicar em “[editar]” ao lado de “Ver a validade do meu certificado”.
Ao clicar em “[executar]” ao lado de “Verificar validade de certificado” a tela mostrada é a da Figura 34.
Figura 34 – Executar informação
4.3 Implantação
Nessa seção estão descritos a implantação do sistema proposto neste projeto, os testes e resultados obtidos.
4.3.1 Testes
Os testes foram feitos na mesma máquina de desenvolvimento. Nessa máquina foi configurado o Globus Toolkit, implementado o plug-in “Iniciar job simplificado”, que implementa o binário globus-job-run do Globus
Toolkit. O resultado obtido via interface web foi comparado com o resultado
da linha de comando para saber se as implementações estão realmente de acordo (ver Figura 35).
Figura 35 – Operação realizada no sistema
É demonstrada na Figura 35, em primeiro plano, a execução de um comando no grid pela linha de comando. No segundo plano é executada exatamente a mesma operação só que com a utilização do sistema.
4.4 Discussão
Nesta seção são colocados em pauta os meios empregados para o desenvolvimento do projeto e as consequências diretas de seus resultados. 4.4.1 Conteúdo da discussão
Tendo como base para análise o projeto e sua implementação, devemos levar em consideração alguns pontos:
• O Globus Toolkit possui um grande número de recursos disponíveis entre todas as suas ferramentas, o que faz da forma de desenvolvimento através de plug-ins uma saída viável para a implementação;
• A escolha da plataforma web para o sistema aumenta a compatibilidade no que se diz respeito ao sistema operacional do cliente e olhando por este prisma vai de encontro com a heterogeneidade que é possível no grid;
• Os problemas da web com relação à velocidade de banda e atrasos podem ser vilões no caso de um sistema web de alto desempenho e grande volume de dados.
5 CONCLUSÕES
O capítulo a seguir tratará das conclusões do projeto em dois aspectos principais: quais as reais contribuições dele e o que poderá ser melhorado no futuro.
5.1 Contribuições
O principal produto do trabalho é colocar a disposição uma nova forma de se utilizar um grid e gerenciar o Globus Toolkit: através de um
front-end web. Neste contexto, a principal contribuição para a comunidade é
a facilidade de se ter acesso às operações em um grid.
Dentro da grande quantidade de funcionalidades que o Globus Toolkit possui, abre também espaço para que sejam criados plug-ins específicos para determinadas situações.
Houve também uma coleta de informações a respeito de grids e do
Globus Toolkit que conta com pouca literatura na língua portuguesa.
5.2 Trabalhos futuros
O principal ponto a ser trabalhado no futuro em relação ao corrente projeto é a implementação de mais plug-ins para aumentar a gama de recursos e funcionalidades.
Há também melhorias com relação aos recursos do programa, como por exemplo, possibilitar a exportação de dados para outros formatos além de visualização na web e também com relação à possibilidade de troca de arquivos.
Outro tema que pode ser explorado com mais profundidade a partir deste trabalho, é a utilização de front-end web para outras formas de computação de alto desempenho, sempre procurando tornar as coisas mais fáceis e intuitivas para quem está utilizando.
6 REFERÊNCIAS
ABBAS, Ahmar. Grid Computing: A Practical Guide to Technology and
Applications. Estados Unidos da América: Charles River Media, 2004.
BURNETTE, Ed. Eclipse IDE Pocket Guide. Estados Unidos da América: O’Reilly, 2005.
BUSCHMANN, Frank; et al. Pattern-Oriented Software Architecture
Volume 1: A System of Patterns. Estados Unidos da América: Wiley, 1996.
BUYYA, Rajkumar. Grid Computing Info Centre: Frequently Asked
Questions (FAQ). Disponível em:
<http://www.gridcomputing.com/gridfaq.html>. 2002. Acesso em 12 de abril de 2009.
CHAFFER, Jonathan; SWEDBERG, Karl. Learning jQuery 1.3. Estados Unidos da América: Packt Publishing, 2009.
DOUGLAS, Korry. PostgreSQL (2nd Edition). Estados Unidos da América: Sams, 2005.
FEITELSON, Dror; RUDOLPH, Larry. Parallel Job Scheduling: Issues and
Approaches, Proceedings of the Workshop on Job Scheduling Strategies for Parallel Processing. Estados Unidos da América: Springer,
1995.
FLANAGAN, David. Javascript: The Definitive Guide. Estados Unidos da América: O'Reilly, 2006.
FOSTER, Lan. Globus Toolkit Version 4: Software for Service-Oriented
Systems. In: IFIP International Conference on Network and Parallel
Computing, p. 2-13, Toquio. Springer-Verlag:Berlim, 2006.
FOSTER, Lan. What is the grid? A three point checklist. Argonne National Lab & Universidade de Chicago. Julho, 2002.
FOSTER, Lan; KESSELMAN, Carl; TUECKE, Steven. The Anatomy of the
Grid: Enabling Scalable Virtual Organizations. International J.
Supercomputing Applications, v. 8, n. 3, p. 1-25, 2001.
GENTZSCH, Wolfgang. Sun Grid Engine: Towards Creating a Compute
Power Grid. In: First IEEE International Symposium on Cluster Computing
and the Grid (CCGrid'01), Brisbane, 2001.
JATIT (Journal of Theoretical and Applied Information Technology).
Comparison of Grid Computing vs. Cluster Computing. Disponível em:
<http://www.jatit.org/research/introduction_grid_computing.htm> Acesso em 4 de agosto de 2009.
JUDE. ChangeVision JUDE/Community. JUDE/Community Basic
Operation Guide. Disponível em:
<http://jude.change-vision.com/jude-web/notes/JUDE_BasicOperationGuide-e.pdf> Acesso em 4 de setembro de 2009.
LAURIE, Peter; LAURIE, Ben. Apache: The Definitive Guide. Estados Unidos da América: O'Reilly, 2002.
LERDORF, Rasmus; TATROE, Kevin; MACINTYRE, Peter. Programming
MEYER, Eric. CSS: The Definitive Guide. Estados Unidos da América: O'Reilly, 2006.
MUSCIANO, Chuck; KENNEDY, Bill. HTML & XHTML: The Definitive
Guide. Estados Unidos da América: O'Reilly, 2006.
SCIBILIA, Fabio. Introduction to Workload Management System and
Information System in gLite. Disponível em
<http://agenda.ct.infn.it/getFile.py/access?contribId=7&sessionId=1&resId=0 &materialId=slides&confId=67>. Acesso em 4 de setembro de 2009.
SLOAN, Joseph. High Performance Linux Clusters with OSCAR, Rocks,
OpenMosix, and MPI. Estados Unidos da América: O'Reilly, 2004.
SOTOMAYOR, Borja; CHILDERS, Lisa. Globus Toolkit 4: programming
Java Services. Estados Unidos da América: Morgan Kaufmann, 2005.
THAIN, Douglas; TANNENBAUM, Todd; LIVNY, Miron. Condor and the
grid. In: BERMAN, F. et al (Eds.). Grid computing: making the global
infrastructure a reality, p. 299-332, Nova Iorque: John Wiley, 2003.
TUECKE, Steven; et al. The Physiology of the Grid: An Open Grid
Services Architecture for Distributed Systems Integration. Disponível
em <http://www.globus.org/alliance/publications/papers/ogsa.pdf>. 2002. Acesso em 12 de abril de 2009.
WELLINGTON, Stephen B. Grid or cluster: What’s the difference?.
Disponível em
<http://computerworld.co.nz/news.nsf/news/18DFEC40EEA32D2DCC25726 8000F9AFB>. 2007.
Autorização
Autorizo a reprodução e/ou divulgação total ou parcial da presente obra, por qualquer meio convencional ou eletrônico, desde que citada a fonte.
Nome do autor: Daniel Alexandre Gouveia
Assinatura do autor: ____________________________ Instituição: Universidade Tecnológica Federal do Paraná Local: Curitiba, Paraná
Endereço: Avenida Sete de Setembro, 3165 E-mail: danielgouv@yahoo.com
