Interface Web para um Software de Gerenciamento de Tarefas ...cristina/Web_Grid.pdf · para fazer o...

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

Daniel Alexandre Gouveia

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

SUMÁRIO

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

4.3.1 Testes ............................................................................................................ 54

4.4 Discussão ............................................................................................................. 55

4.4.1 Conteúdo da discussão .................................................................................. 55

5 CONCLUSÕES......................................................................................... 57

5.1 Contribuições...................................................................................................... 57

5.2 Trabalhos futuros............................................................................................... 57

6 REFERÊNCIAS ........................................................................................ 58

LISTA DE FIGURAS

Figura 1 – Arquitetura grid .................................................................................. 13

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 29 – “Iniciar job fila” .................................................................................. 51

Figura 30 – “Resgatar resultado de job” .............................................................. 52

Figura 31 – Lista de ações pessoais de um usuário ........................................... 52

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

Figura 35 – Operação realizada no sistema ....................................................... 55

LISTA DE SIGLAS

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

XHTML: Extensible Hypertext Markeup Language

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.

Palavras-chave: Grid, Web, Globus Toolkit

Capítulo 1 – Introdução 9

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.

Capítulo 2 – Grids e computação de alto desempenho 12

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

prevê o QoS.


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 Toolkit

O 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

Fonte: http://www-unix.globus.org/toolkit/docs/4.0/GT4Facts/


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

Globus Toolkit.


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

interface gráfica para eles além do próprio terminal do Linux.


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).

Figura 4 – Tarefa executa com o binário globus-job-run e opções


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 globus-

job-status (ver Figura 6).


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.

Capítulo 3 – Metodologia 31

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).

Capítulo 4 – Resultados 35

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.

Pré-condições: nenhuma.


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.



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.




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 14 – Diagrama de seqüência para o caso de uso Autenticar


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 Resultado


Figura 17 - Diagrama de seqüência para o caso de uso Alterar Senha

Figura 18 - Diagrama de seqüência para o caso de uso Fazer Logoff


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.

Figura 24 – Opções do grid com alguns plug-ins carregados


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.

Figura 26 – “Listar Jobs”


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.

Figura 31 – Lista de ações pessoais 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”.

Figura 33 – Editar informação já salva


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.

Capítulo 5 – Conclusões 57

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.

Capítulo 6 – Referências 58

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

PHP. Estados Unidos da América: O'Reilly, 2006.


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: [email protected]

Interface Web para um Software de Gerenciamento de Tarefas ...cristina/Web_Grid.pdf · para fazer o...

Documents

Transcript of Interface Web para um Software de Gerenciamento de Tarefas ...cristina/Web_Grid.pdf · para fazer o...