computaÇÃo em nuvem com o google app engine · serviço, trazendo a imagem de nebulosidade. o...
TRANSCRIPT
RODRIGO SOARES
COMPUTAÇÃO EM NUVEM COM O GOOGLE APP ENGINE
CANOAS, 2009
1
RODRIGO SOARES
COMPUTAÇÃO EM NUVEM COM O GOOGLE APP ENGINE
Trabalho de conclusão apresentado em sessão de apresentação pública do curso de Ciência da Computação do Centro Universitário La Salle - Unilasalle, como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação.
Orientação: Prof. Me. Marcos Ennes Barreto
CANOAS, 2009
2
A minha namorada, Clarissa, maior
incentivadora, pelo que sou e realizo,
simplesmente.
3
AGRADECIMENTOS
Agradeço a todos que colaboraram de forma direta ou indireta para que este
trabalho pudesse ser concluído.
Obrigado a todos pela atenção, paciência e pelo tempo a mim dedicado.
4
RESUMO
A computação em nuvem pode ser considerada o estágio mais recente e evoluído
do conceito de virtualização. Seu modelo é orientado a serviços, podendo ser
dividido em: software como serviço, plataforma como serviço, infra-estrutura como
serviço e armazenamento como serviço. Computação em nuvem é uma evolução da
computação em grade e recebe esse nome principalmente por dois motivos:
primeiro, por estar no ambiente da internet, que traz a idéia de nuvem; segundo, por
ser transparente para o usuário final, sem deixar que ele perceba onde está cada
serviço, trazendo a imagem de nebulosidade. O estudo desses conceitos, bem como
os principais aspectos, oportunidades e obstáculos da computação em nuvem são
apresentados neste trabalho. Esta monografia estuda também os ambientes de
execução do Google App Engine – Python e Java – que estão localizados na
camada de plataforma como serviço, e provêem recursos para o desenvolvimento
na camada de software como serviço. Foi projetada e desenvolvida uma camada de
serviços, que está disponibilizada através de um portal, e conta com os seguintes
recursos: geração de código, submissão, monitoramento, tutoriais e controle de
projetos criados, em ambos os ambientes Python e Java. O portal foi avaliado
qualitativamente através de um questionário respondido por alunos da disciplina de
Sistemas Distribuídos do curso de Ciência da Computação do UNILASALLE.
Palavras-chave: Computação em nuvem. Sistemas distribuídos. Web services.
Google App Engine.
5
ABSTRACT
Cloud computing can be considered the most recent and evolved stage of
virtualization. Its model is service-oriented and can be divided into: software as a
service, platform as a service, infrastructure as a service and storage as a service.
Cloud computing is an evolution of grid computing and is named mainly for two
reasons: first, by being an Internet environment, which brings the idea of cloud and
second, due to its transparency to the user, hiding the services location and bringing
the image of cloud cover. The concepts, as well as the main aspects, opportunities
and challenges of cloud computing are presented in this work. The Google App
Engine execution environments for Python are also described, as they provide
resources for development in the software as a service layer. Within the scope of this
work, an access portal to the Google App Engine was developed and evaluated. The
portal provides services for code generation, application submission and monitoring,
as well as a general guide to use the GAE environment, both for Java and Python
languages. Evaluation was made by means of a questionnaire answered by students
of Distributed Systems course in the Computer Science undergraduate course of
UNILASALLE.
Key words: Cloud computing. Distributed systems. Web services. Google App
Engine.
6
LISTA DE FIGURAS
Figura 1 – Evolução da Computação em Nuvem......................................................12
Figura 2 – Usuários e provedores das camadas de Computação em Nuvem...........13
Figura 3 – Suporte de serviços executados na nuvem e localmente. .......................22
Figura 4 – Estrutura da Nuvem do Google. ...............................................................24
Figura 5 – Sintaxe da GQL........................................................................................26
Figura 6 – Ambiente de Execução Java....................................................................27
Figura 7 – Classe de dados Employee.java. .............................................................30
Figura 8 – Camada de Serviços para o Google App Engine. ....................................34
Figura 9 – Módulo de Login.......................................................................................35
Figura 10 – Código Python para o Google App Engine.............................................36
Figura 11 – Código Java para o Google App Engine. ...............................................36
Figura 12 – Criando um novo projeto web - Java......................................................37
Figura 13 – Erro de compilação. ...............................................................................38
Figura 14 – Status do processo de submissão..........................................................39
Figura 15 – Controle de projetos. ..............................................................................40
Figura 16 – Fluxograma do módulo gerador de código.............................................43
Figura 17 – Fluxograma do módulo de submissão....................................................44
LISTA DE QUADROS
Quadro 1 – Comparação de algumas plataformas para nuvem................................14
Quadro 2 – Custos de recursos das nuvens Google e Microsoft. .............................21
Quadro 3 – Identificação do perfil dos entrevistados.................................................45
Quadro 4 – Identificação do nível de conhecimento específico dos entrevistados....45
Quadro 5 – Avaliação do portal. ................................................................................46
7
LISTA DE SIGLAS
AMI – Amazon Machine Image
API – Application Programming Interface
AWS – Amazon Web Services
CGI – Common Gateway Interface
DRY – Don't Repeat Yourself
dSaaS – data Storage as a Service
E/S – Entrada e Saída
EC2 – Elastic Compute Cloud
GAE – Google App Engine
GQL – Google Query Language
GWT – Google Web Toolkit
HTML – HyperText Markup Language
HTTP – Hypertext Transfer Protocol
IaaS – Infrastructure as a Service
JDO – Java Data Objects
JDOQL – Java Data Objects Query Language
JPA – Java Persistence API
JRE – Java Runtime Environment
JSON – JavaScript Object Notation
JSP – Java Server Pages
JVM – Java Virtual Machine
MVC – Model-View-Controller
ORM – Object-Relational Mapping
PaaS – Plataform as a Service
POJO – Plain Old Java Objects
QoS – Quality of Service
S3 – Simple Storage Service
SaaS – Software as a Service
SDK – Software Development Kit
SLA – Service Level Agreements
SSL – Secure Sockets Layer
8
URL – Uniform Resource Locator
VDC – Virtual Data Center
VLAN – Virtual Local Area Network
VM – Virtual Machine
VPN - Virtual Private Network
WSGI – Web Server Gateway Interface
XML – eXtensible Markup Language
9
SUMÁRIO
1 INTRODUÇÃO.............................................................................................10
1.1 Contexto ........................................... ..........................................................10
1.2 Objetivos.......................................... ...........................................................11
1.3 Estrutura do trabalho .............................. ..................................................11
2 FUNDAMENTAÇÃO TEÓRICA.............................. .....................................12
2.1 Computação em nuvem ................................ ............................................12
2.1.1 Principais aspectos da computação em nuvem...........................................16
2.1.2 Oportunidades e obstáculos ........................................................................17
2.2 Ambientes.......................................... .........................................................21
2.3 Google App Engine.................................. ..................................................24
2.3.1 Google SDK.................................................................................................25
2.3.2 Funcionamento do Google App Engine .......................................................25
2.3.3 Ambiente do Google App Engine.................................................................26
2.3.4 Modelo de armazenamento .........................................................................28
2.3.4.1 Interfaces de dados em Java.......................................................................29
2.3.4.2 Entidades e propriedades ............................................................................31
2.3.4.3 Consultas e índices......................................................................................32
2.3.4.4 Transações e grupos de entidades..............................................................32
2.3.4.5 Cotas e limites .............................................................................................33
3 PORTAL DE SERVIÇOS................................. ............................................34
3.1 Proposta / camada de serviços ...................... ..........................................34
3.2 Implementação e avaliação.......................... .............................................41
4 CONCLUSÃO.......................................... ....................................................47
REFERÊNCIAS ...........................................................................................48
APÊNDICE A – Guia de utilização do Google App Engi ne .....................50
APÊNDICE B – Questionário Avaliação ............... ....................................64
10
1 INTRODUÇÃO
Computação em nuvem (cloud computing) é um novo conceito que chega ao
mercado. Segundo Buyya et al. (2008), é uma metáfora para a “nuvem” que forma a
internet. Basicamente, trata-se de um ambiente de computação formado por uma
grande rede de servidores, sejam eles virtuais ou físicos. As aplicações que residem
na nuvem são chamadas de cloud applications. Pode-se dizer que este é o estágio
mais evoluído do conceito de virtualização.
1.1 Contexto
Esta é uma área relativamente nova, que está no início de seu
desenvolvimento, mas que apresenta um grande potencial de crescimento, devido
ao contexto dos sistemas em que estamos inseridos atualmente.
No conceito de computação em nuvem, os recursos são disponibilizados
através de serviços pela internet, permitindo ao usuário o acesso a uma variada
gama de ferramentas, sem que esse tenha conhecimento da infra-estrutura que está
por trás do ambiente. Toda a tecnologia fica transparente para o usuário.
De acordo com Buyya et al. (2008), a nuvem é um sistema distribuído e
paralelo, constituído por uma coleção de computadores virtuais interconectados que
provêem um ou mais recursos computacionais, baseados em acordos de níveis de
serviços pré-estabelecidos através uma negociação entre o consumidor e o
prestador de serviços.
Para Delic e Walker (2009), a nuvem é um complexo de hardware, software,
dados e pessoas que provêem serviços on-line.
Pode-se traçar um paralelo entre o cenário atual da computação em nuvem e
o da computação em grade há anos atrás. Logo que o modelo de computação em
grade surgiu, diversas empresas partiram para as suas próprias implementações.
Com o tempo tornou-se visível que era importante definir padrões e permitir que
diversas plataformas pudessem interagir. Assim, ao passar de algum tempo, foram
desenvolvidos modelos e padrões, os quais foram aplicados em grande escala.
11
Acredita-se que o mesmo poderá acontecer no cenário da computação em
nuvem. Atualmente, existem algumas propostas de ambientes para o
desenvolvimento e/ou suporte de aplicações em nuvem, cada qual com suas
especificidades e com pouca ou nenhuma interação com outros ambientes.
1.2 Objetivos
Este trabalho tem por objetivo estudar os conceitos e modelos de
programação/execução que se aplicam à computação em nuvem, em especial o
ambiente Google App Engine, que provê suporte para o desenvolvimento,
publicação e acesso a aplicações Web que executam nos servidores da nuvem
Google.
Com base nesse estudo, foi percebida a necessidade de aprimoramento de
alguns serviços do ambiente disponibilizado pelo Google. Para suprir algumas
dessas necessidades, este trabalho define uma camada de virtualização de
serviços, através do desenvolvimento de um Portal Web. Os serviços
disponibilizados pelo portal são: Geração de Código, Submissão e Monitoramento.
1.3 Estrutura do trabalho
O presente trabalho está dividido da seguinte forma: o Capítulo 2 apresenta
os principais conceitos sobre os assuntos envolvidos nesta monografia.
A proposta do trabalho é apresentada no Capítulo 3, abortando o modelo de
implementação, e as avaliações realizadas sobre o mesmo.
A conclusão do trabalho, bem como suas contribuições, limitações e trabalhos
futuros constam no Capítulo 4.
12
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta conceitos que possibilitarão um melhor entendimento
do trabalho desenvolvido.
2.1 Computação em nuvem
O modelo de computação em nuvem está orientado a diversos tipos de
serviço, os quais podem ser divididos em: Software como Serviço (SaaS – Software
as a Service), Plataforma como Serviço (PaaS – Plataform as a Service),
Infraestrutura como Serviço (IaaS – Infrastructure as a Service) e Armazenamento
como Serviço (dSaaS – data Storage as a Service).
Figura 1 – Evolução da Computação em Nuvem. Fonte: Autoria Própria, 2009.
Na base da figura 1 estão os conceitos que deram origem à computação em
nuvem. São eles: clusters, super computadores, computação em grade e
computação como utilitário. O topo da figura 1 ilustra as camadas de serviços
providas pela nuvem.
13
A primeira camada da figura 1 ilustra o surgimento de computadores com alto
poder de processamento, juntamente com os clusters, que são um conjunto de
computadores que trabalham com o conceito de computação distribuída.
A segunda camada da figura 1, chamada de Computação em Grade, foi à
responsável por construir um modelo de divisão de tarefas entre inúmeras
máquinas, gerando uma alta taxa de processamento.
A última camada em verde da figura 1, Computação como Utilitário, é uma
das principais responsáveis pelo surgimento do conceito de computação em nuvem.
Nessa camada já se pensava em tratar computação e processamento como um
serviço, ou seja, vendido como um utilitário.
O estágio mais evoluído da virtualização dos sistemas distribuídos é a
computação em nuvem, observada na primeira camada em azul da figura 1. Sua
base em computação como utilitário levou a criação de subcamadas de serviço,
exibida na última camada da figura 1.
Figura 2 – Usuários e provedores das camadas de Computação em Nuvem. Fonte: Traduzido de Armbrust et al., 2009.
Segundo Armbrust et al. (2009), quando uma nuvem é disponibilizada na
forma de “pague o que você usar” (pay-as-you-go), essa nuvem é chamada de
Nuvem Pública (Public Cloud); ou seja, o serviço de computação/processamento
está sendo vendido como utilitário (Utility Computing). A figura 2 ilustra esse
conceito. Um fornecedor de nuvem vende seus serviços de processamento para um
fornecedor de software como serviço, que finalmente os repassa ao usuário final.
Como exemplo desses serviços podem ser citados o AmazonWeb, o Google
App Engine e o Microsoft Azure. Para datacenters internos de uma empresa, ou que
14
não são disponibilizados ao público, Armbrust et al. (2009) utiliza o termo Nuvem
Privada (Private Cloud). Assim, em linhas gerais, Computação em Nuvem é a junção
de SaaS e Utility Computing.
Um bom exemplo de funcionamento de uma nuvem é o serviço gratuito
Google Docs. Ele mantém os dados armazenados em seus datacenters e os
usuários dos serviços apenas acessam via web, de qualquer lugar a qualquer hora,
por meio de um navegador. O quadro 1 apresenta um comparativo de características
entre diversos sistemas voltados para computação em nuvem.
Amazon Google Microsoft Sun GRIDS Lab Sistema Característica
Elastic Compute Cloud (EC2)
App Engine Live Mesh
Network.com (Sun Grid) Aneka
Foco Infra-estrutura Plataforma Infra-estrutura Infra-estrutura Plataforma
Tipo de serviços Armazenamento, Computação
Aplicação Web Armazenamento Computação Computação
Negociação dinâmica de parâmetros de QoS
Nenhuma Nenhuma Nenhuma Nenhuma
Baseado em SLA Reserva de recursos
Interface de acesso para o usuário
Linha de comando
Controle via portal Web
Qualquer dispositivo com Live Mesh
Execução de scripts e portal Web
Controle via portal Web
API Web Sim Sim Desconhecido Sim Sim
Valor agregado de provedores de serviço
Sim Não Não Sim Não
Framework de programação
Baseado em imagens de máquinas
Python Não aplicável Solaris OS, Java, C, C++, FORTRAN
API de suporte em C# e .Net
Quadro 1 – Comparação de algumas plataformas para nuvem. Fonte: Buyya et al., 2008.
O Amazon Elastic Compute Cloud (EC2) fornece um ambiente de
computação virtual que permite ao usuário executar aplicações baseadas em Linux.
O usuário pode criar uma Amazon Machine Image (AMI), contendo os aplicativos,
bibliotecas, dados e configurações desejadas, ou selecionar de uma biblioteca AMI
já existente. Para armazenar essas informações, a Amazon oferece um serviço
chamado de Amazon Simple Storage Service (S3).
15
O Google App Engine permite ao usuário desenvolver e executar aplicações
Web através de duas linguagens de programação: Python1 e Java2. No capítulo 3
será explicado de forma detalhada o funcionamento dessa ferramenta, por ser um
dos focos desse trabalho. Atualmente o Google App Engine é livre para uso de até
500MB de armazenamento, e até 5 milhões de visualizações de páginas por mês.
O Microsoft Live Mesh3 tem como objetivo prover um local centralizado para
que o usuário armazene dados e aplicativos que podem ser acessados através de
computadores e telefones móveis em qualquer lugar do mundo. Todos os usuários
do Live Mesh são protegidos por senha e autenticados através do seu Windows Live
Login, enquanto todas as transferências de arquivos são protegidas por Secure
Socket Layer (SSL). Para acessar as aplicações e dados enviados para o servidor, é
disponibilizado um portal Web.
O Sun Grid permite ao usuário executar aplicações baseadas em Solaris,
Java, C, C++ e Fortran. Primeiro o usuário precisa criar e depurar suas aplicações e
scripts em tempo de execução em um ambiente de desenvolvimento local
configurado para ser semelhante ao Sun Grid. Então, ele precisa criar um pacote
(que contém todos os scripts relacionados, bibliotecas, binários executáveis e dados
de entrada) e enviá-lo para o Sun Grid. Finalmente, ele pode executar e acompanhar
a aplicação usando o portal Web da Sun Grid.
O GRIDS Lab Aneka4 (Aneka NextGen Enterprise Grid) é uma solução
baseada em serviços .NET para construção de grades empresariais. É modelado
para suportar múltiplos modelos de aplicação, persistência e soluções de segurança.
Isso permite maior flexibilidade na hora de alguma troca, porque não impacta no
sistema como um todo. A grade é montada com a utilização dos computadores dos
usuários sem interferir nas suas atividades e a configuração se dá através um ponto
único, onde é possível a inicialização dos serviços.
1 (http://www.python.org/) 2 (http://www.java.com/pt_BR/) 3 (https://www.mesh.com/) 4 (http://www.gridbus.org/intro.html)
16
2.1.1 Principais aspectos da computação em nuvem
A nuvem pode oferecer os mais variados tipos de recursos de Tecnologia da
Informação, dos diversos níveis de computação, aplicativos, além de proporcionar o
armazenamento de arquivos nos mais diferentes formatos. Fazem parte da nuvem
empresas desenvolvedoras de softwares, fabricantes de hardware, datacenters,
prestadoras de serviços sob demanda, entre outros.
Do ponto de vista de hardware, a computação em nuvem apresenta três
novos aspectos (Armbrust et al., 2009):
a) Elimina a necessidade de um planejamento para médio e longo prazo de
expansão dos recursos de hardware. Com a computação em nuvens os
recursos são “infinitos”, porque podem ser comprados sob demanda;
b) As empresas podem começar utilizando poucos recursos de hardware, e
irem aumentando gradativamente quando há um aumento das demandas;
c) Redução de custos. Os recursos podem ser pagos por hora de utilização,
por armazenamento, por processamento ou até por dia. Todas essas
características deixam o processo muito flexível, permitindo que os
recursos deixem de ser utilizados quando não houver mais a necessidade.
Como não foram feitos investimentos em compra de hardware, apenas
deixa-se de utilizar o serviço.
Um dos grandes fatores que potencializaram a computação em nuvem,
segundo Armbrust et al. (2009), foram as operações em grande escala dos
datacenters. Com essa nova maneira de se pensar em hardware e software, os
custos de eletricidade, redes, operação, entre outros, são bastante reduzidos.
Quando se traçou um comparativo entre os serviços dos datacenters e a
computação em nuvem, verificou-se que o modelo da nuvem poderia oferecer
serviços abaixo do custo de um datacenter de tamanho médio e ainda assim ter um
bom lucro.
Embora os custos de hardware continuem diminuindo, a construção de um
datacenter é muito caro. Poder abrir mão desse investimento, transferindo os
recursos para a nuvem pode ser um bom negócio. Como a nuvem é elástica, paga-
se somente pelo que se usa. Quando se investe em um datacenter precisa-se
pensar nos níveis de pico, e adequar a estrutura para que suporte esses picos. Mas,
17
em momentos de baixo processamento, a ociosidade das máquinas acaba sendo
onerosa.
Transferindo o processamento para a nuvem, o risco é transferido para o
fornecedor. Controlar a subutilização (underprovisioning) e saturação
(overprovisioning) passa a ser de responsabilidade de quem está vendendo o
serviço.
2.1.2 Oportunidades e obstáculos
Em seu relatório técnico, Armbrust et al. (2009) definem de forma bastante
adequada diversas oportunidades e obstáculos para computação em nuvem. Logo
abaixo elas serão comentadas.
Disponibilidade dos Serviços
Como o acesso à nuvem se dá através da Internet, um fator que está gerando
muita preocupação para empresas aderirem à nuvem é a disponibilidade dos
serviços. Ironicamente, os produtos SaaS existentes atualmente tem fixado um alto
padrão neste quesito. Talvez o maior exemplo, citado por Armbrust et al. (2009) seja
o Google Search. Se um usuário acessa a pesquisa do Google e esta não está
disponível, imagina-se que o problema não está na pesquisa do Google, mas sim
em sua conexão com a internet. Ou seja, o Google se tornou referência de
disponibilidade. Para a computação em nuvem essa mesma disponibilidade é
esperada, o que não é tarefa simples.
Dados Presos
Como as soluções de nuvens são, em sua grande maioria, proprietárias, os
usuários ficam presos à nuvem em que estão. Retirar os dados e programas de uma
nuvem para transportá-los para outra não é simples.
Uma solução apontada por Armbrust et al. (2009) é a criação de uma API
padronizada para que desenvolvedores de SaaS pudessem criar serviços e dados
únicos para diversas nuvens. Em um primeiro momento, esse tipo de solução pode
18
gerar o medo de que o lucro da nuvem se esvaia, mas Armbrust et al. (2009) dão
dois argumentos para afastar essa preocupação.
Em primeiro lugar, os clientes nem sempre buscam a solução mais barata. A
qualidade dos serviços é um ponto muito importante nessa avaliação. Alguns
fornecedores de serviços para Internet hoje oferecem um custo dez vezes maior que
outros porque são mais confiáveis e oferecem serviços extras para melhorar a
usabilidade.
Em segundo lugar, o modelo de uma API padronizada poderia permitir a
utilização dos mesmos softwares tanto em uma nuvem pública, quanto em uma
nuvem privada. Dessa forma, o compartilhamento dos dados ficaria mais simples,
permitindo a utilização da nuvem pública para funções adicionais que não podem ser
tratadas na nuvem privada, devido à pesada carga de processamento temporário.
Confidencialidade e Auditabilidade dos Dados
A confidencialidade dos dados na nuvem é outro fator preocupante. Mas,
Armbrust et al. (2009) afirmam em seu relatório técnico que acreditam não haver
obstáculos fundamentais para fazer um ambiente de computação em nuvem tão
seguro quanto a maioria dos ambientes de rede internos das empresas. Afirmam
também que muitos dos obstáculos podem ser superados com a adoção de
tecnologias de armazenamento codificado, VLANs (Virtual Local Area Networks) e
filtros de rede, como firewalls e filtros de pacotes. Por exemplo, criptografando os
dados antes de colocá-los nas nuvens pode ser mais seguro do que dados não
criptografados em uma rede de dados local.
Para a auditabilidade dos dados, sugerem a criação de uma camada adicional
na nuvem, fora do alcance do sistema operacional que está fazendo a virtualização.
Isso proporciona uma maior segurança do que deixar a responsabilidade da
fiscalização em uma única camada lógica.
Gargalo da Transferência de Dados
Os dados de uma nuvem podem não raro ultrapassar os terabytes. E, quando
esses dados precisam ser recuperados para fora da fronteira da nuvem, podem se
tornar um problema. Os usuários da nuvem, bem como os fornecedores, precisam
se preocupar com as implicações da localização e do tráfego em todos os níveis do
sistema, de forma a minimizar os custos. Uma possibilidade para contornar esse
19
problema é a de encontrar mecanismos que tornem atraente para o usuário manter
os dados na nuvem. Mecanismos esses que podem ser serviços adicionais para o
usuário, de forma que ele possa manipular seus dados diretamente na nuvem, sem
necessidade de fazer download dos mesmos.
Imprevisibilidade do Desempenho
De acordo com experiências realizadas por Armbrust et al. (2009), várias
máquinas virtuais podem compartilhar processadores e memórias
surpreendentemente bem em um ambiente de computação em nuvem, mas o
processo de entrada e saída (E/S) compartilhado é mais problemático. Uma
possibilidade de contornar esse problema é trabalhando na melhoria das
arquiteturas dos sistemas operacionais de forma a melhorar a eficiência da E/S na
virtualização. Tecnologias como PCIexpress são difíceis de virtualizar, mas são
cruciais para a nuvem. Outra alternativa apontada por Armbrust et al. (2009) é de
que a memória flash vai diminuir a interferência de E/S. Memórias flash podem
suportar muito mais gigabytes de E/S por segundo do que discos rígidos.
Armazenamento Escalonável
Uma das características da computação em nuvem é permitir “infinito”
armazenamento de dados sob demanda. Esse armazenando escalonável e sob
demanda é complicado de ser tratado. Uma opção para resolver esse problema é
criar um sistema de armazenamento capaz de suprir essas necessidades, e
combiná-lo com as vantagens de aumentar e reduzir os espaços de armazenamento
conforme a demanda.
Erros em sistemas distribuídos de grande escala
Um dos desafios da computação em nuvem é eliminar os erros em grande
escala desses sistemas distribuídos. Um problema comum é que esses erros não
podem ser reproduzidos em pequenas configurações, de modo que a depuração
deve ocorrer na escala de datacenters. (Armbrust et al., 2009).
Rápida escalabilidade ou elasticidade
Essa nova forma de trabalhar com computação traz consigo muito forte a
idéia de “pague o que for usar” ou, no termo original em inglês, pay-as-you-go. Um
20
exemplo é o que o Google faz com o seu App Engine. Conforme a carga aumenta e
diminui, são calculados os ciclos e o usuário é cobrado pelo que utilizou. Já o AWS
(Amazon Web Services) faz a sua taxação por hora, mesmo que a máquina esteja
ociosa.
O desafio então é escalar automaticamente para cima ou para baixo,
respondendo à carga que está sendo recebida, de forma a reduzir os custos, mas
sempre cuidando para não violar os SLAs (Service Level Agreement. Significa
Acordo de Nível de Serviço).
Responsabilidade Legal
Um cliente que faça uma má utilização dos serviços da nuvem pode
comprometê-la como um todo. Armbrust et al. (2009) nos dão o seguinte exemplo.
Uma má utilização do domínio da EC2 (Elastic Compute Cloud, da Amazon) acaba
por colocá-lo em uma lista negra de spams. Isso poderá impactar no trabalho de
outros clientes. Uma possibilidade seria a de criar uma reputação semelhante ao “e-
mail confiável”. A questão legal envolvida é de quem é a responsabilidade. Seria da
empresa que enviou o spam, ou da Amazon? Os prestadores de serviço de
computação em nuvem tentam deixar toda responsabilidade legal junto ao cliente.
Licenciamento do Software
Atualmente, as licenças de software são destinadas para os computadores no
qual serão executados. É comum os usuários pagarem pelo software, e uma taxa de
manutenção. Inicialmente muitos fornecedores de computação em nuvem partiram
para software aberto (open source), porque o modelo de licenciamento de software
comercial não os favorece.
As empresas estão tendo que alterar esse modelo de licenciamento. Um
exemplo já pode ser verificado com a Microsoft e a Amazon. A Microsoft está
oferecendo o Windows Server e o Windows SQL Server para o EC2 na forma de
pay-as-you-go. Ou seja, está cobrando por hora de utilização dos softwares.
21
O quadro 2 ilustra os preços praticados pelo Google e pela Microsoft
atualmente. Pode ser observado que cada recurso da nuvem é cobrado
separadamente. Os valores exibidos no quadro foram obtidos em outubro de 2009.
Google App Engine
Windows Azure Platform
Recurso Unidade Custo Unitário Custo Unitário
Largura de banda de saída Gigabyte $0,12 $0,15
Largura de banda de entrada Gigabyte $0,10 $0,10
Tempo de CPU Horas CPU $0,10 $0,12
Dados armazenados Gigabytes por mês $0,15 $0,15
Destinatários de e-mail Destinatários $0,0001 $0,00
Quadro 2 – Custos de recursos das nuvens Google e Microsoft. Fonte: Autoria Própria, 2009.
2.2 Ambientes
Este trabalho está concentrado na camada de Plataforma como Serviço (ou
PaaS) da computação em nuvem. Existem diversos modelos existentes para essa
categoria. Dentre eles se destacam o Windows Azure Platform, o Sun Cloud API e o
Google App Engine.
Windows Azure Platform
O Windows Azure Platform é uma solução desenvolvida pela Microsoft,
voltada para criação, implantação e gerenciamento de aplicações e serviços web
distribuídos. Em outras palavras, é uma plataforma para executar aplicativos
Windows e armazenar os dados na nuvem da Microsoft.
O Azure suporta um grande conjunto de serviços para o desenvolvimento de
aplicações para a nuvem. Uma grande vantagem é que a sua plataforma de serviços
pode ser utilizada por aplicativos que estão sendo executados na nuvem, como
também aplicativos executados localmente.
A Plataforma de Serviços Azure é um grupo de tecnologias da nuvem, que
fornece um conjunto específico de serviços para desenvolvedores de aplicativos.
Como a figura 3 mostra, a Plataforma de Serviços Azure pode ser usada tanto por
22
aplicativos em execução na nuvem quanto por aqueles executados em sistemas
locais.
Figura 3 – Suporte de serviços executados na nuvem e localmente. Fonte: CHAPPELL, 2008.
A plataforma de serviços do Azure inclui diversos componentes. São eles:
a) Windows Azure:
- Ambiente baseado no Windows. Executa aplicativos e armazena dados
nos servidores da Microsoft;
b) Microsoft .NET Services:
- Serviços de infra-estrutura distribuída, baseado em aplicativos para
nuvem;
c) Microsoft SQL Services:
- Serviços de dados para nuvem. Baseado no SQL Server;
d) Live Services:
- Integração com os aplicativos Live da Microsoft. Funciona através do
Live Framework.
Sun Cloud API
A API para computação em nuvem da Sun é responsável por criar e gerenciar
recursos na nuvem, incluindo processamento, armazenamento e componentes de
rede. O uso da API é realizado através do protocolo HTTP. A grande maioria das
tarefas pode ser realizada com GET e POST.
23
Esta API possui as seguintes características:
a) Modelos de recursos que descrevem as estruturas de dados em notações
de objetos JavaScript (JSON - JavaScript Object Notation);
b) As requisições são feitas através de pedido e resposta. O pedido é
enviado para a nuvem, processado, e devolvido para o usuário.
A nuvem da Sun possui os seguintes componentes (SUN, 2009):
a) Cloud: Pode ser considerado o ambiente de mais alto nível da nuvem. É
onde os usuários irão interagir com a API;
b) Virtual Data Center (VDC): É um módulo isolado, populado por Clusters,
Virtual Private Networks (VPNs), endereços públicos e volumes de
armazenamento;
c) Cluster: É um agrupamento de máquinas virtuais. Bastante útil para
controle de acesso, isolamento geográfico, e automatização de scripts;
d) Virtual Machine (VM): Um servidor;
e) Virtual Private Network (VNet): Uma sub-rede, não conectado à Internet,
que pode ser utilizado para conectar máquinas virtuais dentro de um VDC
(Virtual Data Center);
f) Endereço Público: Conexão com Internet;
g) Volume de armazenamento: Recurso de armazenamento que pode ser
acessado através do WebDAV e protocolos de armazenamento.
Google App Engine
Para o desenvolvimento deste trabalho foi escolhido o Google App Engine.
Por possuir uma poderosa plataforma de desenvolvimento, com disponibilidade para
execução dos aplicativos diretamente na nuvem, de forma gratuita, as simulações
propostas nesta monografia puderam ser realizadas em cenário real. Na próxima
seção será detalhado o funcionamento do ambiente do Google App Engine.
24
2.3 Google App Engine
O Google App Engine é um ambiente que permite a criação de aplicativos
para Web. Possibilita a publicação dessas aplicações em uma nuvem própria do
Google. O ambiente de desenvolvimento do software (SDK) do Google App Engine
permite desenvolver e enviar aplicativos para nuvem. A estrutura da nuvem do
Google está ilustrada na figura 4.
Para auxiliar o desenvolvimento é disponibilizado o Google Web Toolkit
(GWT). O GWT é um conjunto de ferramentas específico para desenvolvimento web,
que facilita algumas tarefas que o desenvolvedor normalmente precisa executar.
A figura 4 ilustra também a divisão dos ambientes de execução em Python e
Java, cada qual com uma forma específica de armazenamento de dados.
Por fim, a figura 4 mostra que o ambiente possui também alguns serviços de
apoio.
Figura 4 – Estrutura da Nuvem do Google. Fonte: Autoria Própria, 2009.
25
2.3.1 Google SDK
O SDK inclui um aplicativo de servidor da web que simula o ambiente do
Google App Engine, incluindo uma versão local do armazenamento de dados,
contas do Google e a capacidade de obter URLs e enviar e-mails diretamente do
seu computador, usando as APIs do Google App Engine. O SDK é executado em
qualquer computador com Python 2.5, e há versões disponíveis para Windows, Mac
OS X e Linux (Google, 2009). O SDK também possui suporte a Java, através de um
plug-in de desenvolvimento para o Eclipse.
O App Engine Java SDK, em conjunto com o Google Plugin para o Eclipse,
possui uma ferramenta para execução de testes locais da aplicação, sem a
necessidade de possuir um servidor Web, nem de submeter o projeto para a nuvem.
Possui também uma ferramenta para fazer a submissão do projeto para a nuvem
Google, através de uma funcionalidade chamada Deploy.
2.3.2 Funcionamento do Google App Engine
Os aplicativos do Google App Engine comunicam-se com o servidor da web
usando o padrão CGI. Quando o servidor recebe uma solicitação para seu aplicativo,
ele executa o aplicativo com os dados solicitados nas variáveis do ambiente e no
fluxo de entrada padrão (para dados POST). Para responder, o aplicativo grava a
resposta no fluxo de saída padrão, incluindo cabeçalhos e conteúdo HTTP.
O Google App Engine suporta qualquer estrutura programada em Python puro
que se comunique com CGI (e qualquer outra estrutura compatível com WSGI
usando um adaptador CGI), incluindo Django, CherryPy, Pylons e web.py.
Pode ser integrado na ferramenta o Django. Django é um framework para
desenvolvimento rápido para web, escrito em Python, que utiliza o padrão MVC
(model-view-controller). O Django utiliza o princípio DRY (Don't Repeat Yourself), no
qual faz com que o desenvolvedor aproveite ao máximo o código já feito, evitando a
repetição. Com o ORM do Django você define a modelagem de dados através de
classes em Python.
26
Armazenar dados em um aplicativo da web escalável pode ser complicado.
Um usuário pode estar interagindo com muitos servidores da web em um dado
momento, e a próxima solicitação do usuário pode ser para um servidor da web
diferente do servidor que tratou a solicitação anterior. Todos os servidores da web
precisam interagir com dados que também estão distribuídos em dezenas de
máquinas, possivelmente em diferentes locais ao redor do mundo (Google, 2009).
Com o Google App Engine essa preocupação deixa de existir. A infra-estrutura do
engine cuida de toda a distribuição, replicação e balanceamento de carga de dados
por trás de uma API.
O armazenamento de dados do Google App Engine possui um mecanismo de
consulta sofisticado para modelos de dados. Como o armazenamento de dados do
Google App Engine não é um banco de dados relacional tradicional, as consultas
não são especificadas usando SQL. Em vez disso, utiliza-se uma linguagem que o
Google chama de GQL. A GQL usa uma sintaxe familiar para fornecer acesso aos
recursos do mecanismo de consultas do armazenamento de dados do Google App
Engine. A figura 5 ilustra um exemplo de sintaxe da GQL.
Figura 5 – Sintaxe da GQL. Fonte: Google, 2009.
O envio do aplicativo para a nuvem Google é feito através da execução de
uma simples linha de comando. É necessário possuir uma conta padrão Google.
2.3.3 Ambiente do Google App Engine
O Google App Engine suporta aplicações desenvolvidas em diversas
linguagens de programação. O Engine possui dois ambientes de execução. O
27
primeiro apresenta um ambiente de execução em Python dedicado, incluindo um
interpretador Python e a biblioteca padrão do Python. O segundo ambiente de
execução utiliza tecnologias padrão Java. O ambiente inclui a Java Virtual Machine
(JVM), servlets Java e a linguagem de programação Java. Pode ser utilizada
também qualquer outra linguagem que usa um interpretador ou compilador com
base na JVM, como o Ruby5, por exemplo. A figura 6 ilustra de forma detalhada o
ambiente de execução do Google App Engine para Java.
Figura 6 – Ambiente de Execução Java. Fonte: Autoria Própria, 2009.
Esses ambientes foram escolhidos por possibilitarem que o aplicativo seja
executado rapidamente, com segurança e sem interferência de outros aplicativos no
sistema que, em um ambiente de nuvem, é indispensável.
O Google App Engine inclui os seguintes recursos (GOOGLE, 2009):
a) Serviço de web dinâmico, com suporte completo a tecnologias de web
comuns.
b) Armazenamento persistente com consultas, classificação e transações.
c) Ajuste e balanceamento de carga automáticos.
d) APIs para autenticação de usuários e envio de e-mails usando contas do
Google.
5 (http://rubyonrails.org/)
28
e) Um ambiente de desenvolvimento local com todos os recursos, simulando
o Google App Engine em seu computador.
f) Tarefas programadas para disparar eventos em horários específicos e em
intervalos regulares.
O ambiente Java está atualmente utilizando a versão 6 do Java. O SDK para
Java do Google App Engine suporta o desenvolvimento de aplicativos em Java 5 ou
6. O ambiente inclui a plataforma Java SE Runtime Environment6 (JRE 6) e as suas
bibliotecas.
É possível acessar a maioria dos serviços do Google App Engine utilizando as
APIs em Java padrão. Para o armazenamento dos dados, o SDK para Java inclui
uma implementação da interface Java Data Objects (JDO) e Java Persistence API
(JPA). Para o envio de mensagens de correio eletrônico (e-mail), pode ser utilizada a
API JavaMail.
2.3.4 Modelo de armazenamento
O armazenamento dos dados é feito através de um mecanismo de consultas
e transações atômicas.
O Google App Engine fornece um armazenamento robusto e dimensionável.
O foco no desenvolvimento é sempre com relação ao desempenho das
leituras/consultas. São armazenadas entidades de dados com propriedades,
organizadas de acordo com tipos definidos por aplicação. Todas consultas são
sempre pré-indexadas, visando resultados mais rápidos, tendo em conta que o
conjunto de dados pode ser muito grande. O modelo de armazenamento suporta
atualizações transacionais, usando agrupamentos de entidade definidos pelo
aplicativo como a unidade de transação na rede de dados distribuída.
Apesar do modelo de armazenamento de dados do Google App Engine não
ser relacional, ele é bastante consistente. Mesmo tendo diversos pontos em comum
com os bancos de dados relacionais, suas características individuais foram
6 (http://java.sun.com/)
29
projetadas para obter um ganho significativo na capacidade de dimensionar
automaticamente seu espaço.
O que promove esse ganho do Google App Engine em relação aos bancos de
dados tradicionais é a utilização de uma arquitetura distribuída para gerenciar o
dimensionamento para conjuntos de dados muito grandes. É possível definir
relacionamentos entre os objetos de dados, através de um processo de otimização
feito pela própria aplicação.
As consultas são executadas sobre objetos de dados, conhecidos como
entidades. A entidade pode ter uma ou mais propriedades. Uma propriedade pode,
inclusive, ser uma referência a outra entidade. Cada entidade possui um
identificador único, que pode ser chamado de chave. Essa chave é composta por um
tipo e um identificador numérico exclusivo, que é fornecido pelo armazenamento de
dados. Outra alternativa para o identificador é montá-lo a partir de uma string
fornecida pelo aplicativo.
A preocupação com a economia de memória e tempo de execução é
constante. Dessa forma, algumas consultas podem limitar o número de resultados
que são retornados pelo armazenamento de dados. As entidades do
armazenamento de dados são obtidas pelo aplicativo através da sua chave, ou
ainda através de uma consulta às propriedades dessa entidade. Essa consulta pode
retornar zero ou mais entidades. Os resultados são classificados por valores de
propriedade.
Importante destacar também que o armazenamento de dados suporta
diversas operações em uma única transação. Em caso de falha em uma das
operações, é possível reverter toda a transação. Em um ambiente web distribuído,
onde é comum usuários manipularem o mesmo dado ao mesmo tempo, este tipo de
tratamento é imprescindível.
2.3.4.1 Interfaces de dados em Java
O JDO utiliza objetos Java denominados Plain Old Java Objects (POJO) para
descrever como as instâncias da classe são armazenadas como entidades no banco
de dados, e como as entidades são recriadas como instâncias quando recuperadas
30
do banco de dados. A figura 7 ilustra uma classe de dados simples. No exemplo da
figura 7 foi declarada uma entidade de nome “Employee”, com as propriedades “id”,
“firstName”, “lastName” e “hireDate”. O “id” está definido como chave primária da
tabela.
Figura 7 – Classe de dados Employee.java. Fonte: Google, 2009.
As entidades do banco de dados não têm esquema. É responsabilidade da
aplicação garantir que as entidades atendam ao esquema quando necessário. O
SDK para Java inclui duas interfaces para manipulação do banco de dados e
persistência. São elas: JDO e JPA. Essas interfaces padrão incluem mecanismos
para realizar consultas sobre os dados, e possibilitam também a definição de
classes de objetos de dados. Outros adaptadores de interface podem ser
implementados através de uma API de nível inferior.
31
A interação com o banco de dados é realizada através de um objeto
PersistenceManager, obtido a partir de um objeto PersistenceManagerFactory.
Como é muito custoso configurar um PersistenceManagerFactory, deve ser previsto
que se obtenha a instância apenas uma vez durante a existência do aplicativo (que
pode requerer muitas solicitações). Recomenda-se fazer esse processo inserindo-o
em uma única classe.
A JDO contém uma interface de consulta chamada JDOQL. A JDOQL
normalmente é utilizada para recuperação de entidades como instâncias da classe.
2.3.4.2 Entidades e propriedades
Os objetos de dados do Google App Engine são tratados como entidades.
Uma entidade pode ter uma ou mais propriedades. As propriedades podem possuir
diversos tipos de dados, incluindo caracteres, números inteiros, valores de ponto
flutuantes, datas, além de vários outros.
As entidades são identificadas por uma chave única. A chave é composta por
um identificador numérico exclusivo, que pode ser fornecido tanto pelo aplicativo,
quanto pelo armazenamento de dados.
Para obtenção de uma entidade do banco de dados, o aplicativo deve utilizar
a chave da entidade, ou então realizar uma consulta correspondente às
propriedades da entidade. Para economizar memória ou reduzir o tempo de
execução, a consulta pode limitar o número de resultados retornados pelo banco de
dados.
O sistema de armazenamento de dados do Google App Engine não exige que
todas entidades de um determinado tipo tenham as mesmas propriedades,
diferentemente de um banco de dados relacional. A especificação do modelo de
dados pode ficar a critério da aplicação, com a utilização de bibliotecas incluídas no
ambiente de desenvolvimento, ou ainda pelo próprio código.
32
2.3.4.3 Consultas e índices
As consultas ao banco de dados do Google App Engine são realizadas sobre
uma classe de dados de uma entidade. O resultado é retornado através da entidade
se possuir ao menos um valor para cada propriedade definida nos filtros da consulta,
e se todos os critérios do filtro forem atendidos pelos valores da propriedade.
Todas as consultas ao banco de dados são feitas com a utilização de um
índice. Esse índice é na verdade uma tabela que armazena os resultados da
consulta da ordem requisitada. Os índices no Google App Engine são definidos em
um arquivo de configuração. Caso seja realizada uma consulta que não possui um
índice configurado, o servidor web adiciona sugestões a esse arquivo
automaticamente, facilitando o trabalho do desenvolvedor. Esse arquivo pode ser
facilmente editado.
2.3.4.4 Transações e grupos de entidades
Todas as tentativas de criação, atualização ou exclusão de entidades no
sistema de armazenamento de dados do GAE gera uma transação. A transação é
muito importante, pois garante que a efetivação da ação solicitada só ocorra quando
todo o processo for concluído. Em caso de erro, ou de qualquer falha inesperada, a
transação é desfeita e, conseqüentemente, a entidade continua íntegra e
consistente.
O GAE possui uma API de transação para gerenciar esse controle, e permite
que diversas ações possam ser executadas sobre uma entidade, em uma única
transação.
É possível também manipular mais de uma entidade em uma única transação.
Mas, para isso, é preciso informar com antecedência todas as entidades que serão
atualizadas juntas, para que a API possa fazer esse reconhecimento em tempo de
execução. Além disso, é preciso que essas entidades estejam em um mesmo grupo
de entidades.
33
A definição de grupos de entidades é realizada através de uma hierarquia de
relacionamentos. O processo é feito da seguinte maneira: uma entidade é declarada
como filha de outra já existente. Essa outra entidade se torna então uma entidade
pai. Entidades sem pai são conhecidas por entidades raiz.
O gerenciamento das transações utiliza o sistema de concorrência otimista.
Funciona da seguinte maneira: enquanto o aplicativo está manipulando um entidade
ou um grupo de entidades, todas as outras tentativas de atualização de qualquer
entidade do grupo falham.
2.3.4.5 Cotas e limites
O Google App Engine exerce um controle sobre o banco de dados
disponibilizado em sua nuvem, e oferece uma cota de utilização.
Todas as chamadas para a API de armazenamento contam para a cota de
chamadas do armazenamento de dados. Essa cota é dividida em dados enviados e
dados recebidos.
Essa quantidade total de dados para armazenamento é ajustável, e pode ser
configurado pelo painel de configuração da plataforma.
34
3 PORTAL DE SERVIÇOS
O objetivo deste trabalho é desenvolver uma camada de serviços para o
Google App Engine. Os serviços implementados suprem algumas carências
identificadas no ambiente disponibilizado pelo Google.
3.1 Proposta / camada de serviços
A estrutura da camada de serviços pode ser visualizada na figura 8. O acesso
a essa camada é feito através de um Portal de Acesso7, disponibilizado no ambiente
de execução do Google App Engine. O Portal dispõe de seis blocos de serviços.
Figura 8 – Camada de Serviços para o Google App Engine. Fonte: Autoria Própria, 2009.
Login
Este serviço é responsável pela autenticação do usuário. Para acesso aos
serviços do portal, a autenticação é obrigatória. Para realizar a identificação, deve
ser informado usuário (e-mail) e senha.
7 (http://portalacessotcc.appspot.com/)
35
O módulo de Login, ilustrado na figura 9, trabalha com a API das Contas do
Google em Java. Com a utilização desse módulo é possível detectar se o usuário
logado é um administrador, facilitando o desenvolvimento em áreas da aplicação
restritas aos administradores.
Figura 9 – Módulo de Login. Fonte: Autoria Própria, 2009.
Com a utilização do Login através das contas padrão Google, o Portal poderá
ser acessado por milhões de usuários ativos cadastrados no Google, sem a
necessidade de exigir novo cadastramento.
Caso o acesso ao Portal seja realizado por um usuário que não possui uma
conta padrão Google, a API disponibiliza um serviço para cadastramento.
Gerador de Código
O Google App Engine oferece suporte a duas linguagens de programação:
Java e Python.
Sempre que é iniciado o desenvolvimento de uma nova aplicação utilizando
Python é necessário montar manualmente toda a estrutura básica de arquivos. Além
disso, é necessário inserir nos arquivos códigos da estrutura padrão do Google App
Engine, os quais sempre se repetem. A figura 10 destaca os pontos onde existe
repetição de código para uma aplicação simples (Hello World!).
36
Figura 10 – Código Python para o Google App Engine. Fonte: Autoria Própria, 2009.
Para o desenvolvimento via Java, o Google disponibiliza um plugin para
integrar o ambiente de execução da nuvem com a ferramenta Eclipse. Com a
utilização desse plugin, na criação de um novo projeto, a estrutura básica de
arquivos é criada. Mas, para os usuários que não utilizam essa ferramenta, o
problema encontrado no Python precisa ser enfrentado também no Java. A figura 11
ilustra o código de um servlet Java, destacando os pontos que são gerados pelo
serviço.
Figura 11 – Código Java para o Google App Engine. Fonte: Autoria Própria, 2009.
37
O serviço de Geração Automática de Código é responsável por auxiliar o
desenvolvedor na tarefa de montar a estrutura inicial de arquivos, já embutindo o
código padrão necessário para o correto funcionamento da aplicação.
Os pontos onde o usuário deve inserir o código específico da sua aplicação
estão destacados no arquivo fonte, de forma comentada.
Figura 12 – Criando um novo projeto web - Java. Fonte: Autoria Própria, 2009.
É possível também criar um novo projeto com mais opções além da estrutura
básica, conforme ilustrado na figura 12. Este módulo permite, por exemplo, no
momento da criação do projeto selecionar que se deseja trabalhar com acesso a
banco de dados. O aplicativo será então gerado com todas as configurações
necessárias para realizar este acesso, facilitando o trabalho do desenvolvedor.
Outra possibilidade é a de escolha de exemplos embutidos na estrutura
padrão. Por exemplo, caso o usuário deseje ver uma aplicação básica de Livro de
38
Visitas funcionando, é possível fazer essa seleção. O código será gerado já com
essa estrutura embutida.
Submissão
De posse da aplicação pronta, o Portal disponibiliza um serviço de envio do
aplicativo para a nuvem Google. Este módulo é o responsável por receber o pacote
de um projeto, compilá-lo e implantá-lo na nuvem. Caso ocorra algum erro de
compilação a submissão é interrompida, e o erro é exibido na tela, conforme
ilustrado na figura 13.
Figura 13 – Erro de compilação. Fonte: Autoria Própria, 2009.
O processo de compilação só é necessário para o ambiente de execução
Java. Para o ambiente Python o processo de compilação não existe, portanto os
erros de sintaxe só são percebidos em tempo de execução.
Para que a submissão ocorra de forma adequada, é necessário que o pacote
esteja em formato ZIP.
Ao final da submissão é gerado um link para o usuário acessar o seu
aplicativo, conforme ilustrado na figura 14.
39
Figura 14 – Status do processo de submissão. Fonte: Autoria Própria, 2009.
Monitoramento
O Google App Engine disponibiliza um arquivo XML com diversos indicadores
sobre o status dos serviços do ambiente. Esse XML foi incorporado ao portal, e traz
alguns indicadores tais como: uptime, gráfico de latência de leitura, gráfico de
latência de escrita, status do ambiente Python, status do ambiente Java, status das
APIs de serviços, entre outros.
Tutoriais
O módulo de Tutoriais está encarregado em auxiliar o usuário a executar os
serviços do Portal. Estão disponíveis três tutoriais. São eles: Guia de Utilização do
GAE, Como criar/submeter uma aplicação em Java e Como criar/submeter uma
aplicação em Python.
O Guia de Utilização do GAE fornece uma visão geral sobre o ambiente de
execução do Google. Ensina a criar uma conta, passa por todo processo de
instalação, e finaliza ensinando a criar uma aplicação básica.
O tutorial Como criar/submeter uma aplicação em Java fornece informações
detalhadas sobre como utilizar o serviço de Geração de Código do Portal para
40
desenvolver um aplicativo em Java. Vai desde a parte inicial da criação do projeto,
até a submissão para a nuvem.
O tutorial Como criar/submeter uma aplicação em Python é semelhante ao
anterior, mas detalha os aspectos específicos desta outra linguagem de
programação.
Controle de Projetos
Este serviço é responsável por armazenar todos os projetos gerados através
do portal, exibindo informações como: nome do projeto, nome do pacote, data de
criação, ambiente, um link para download do projeto, e um link para exclusão do
projeto, conforme ilustrado na figura 15.
Figura 15 – Controle de projetos. Fonte: Autoria Própria, 2009.
É armazenada nesse serviço também a URL de acesso a última aplicação
submetida pelo usuário.
41
3.2 Implementação e avaliação
Para a implementação do Portal e de seus respectivos serviços, foi escolhido
o ambiente de execução em Java. Existem duas maneiras de desenvolver nesse
ambiente. Uma delas é com a utilização de ferramentas comuns de desenvolvimento
da web e padrões de APIs em Java. Para interação com o ambiente é utilizado o
padrão servlet Java. Podem ser utilizadas também tecnologias comuns de
aplicativos da web, como JavaServer Pages (JSPs). A outra forma, escolhida para o
desenvolvimento deste trabalho, é a utilização de um plugin para integração do
Google App Engine com o Eclipse.
O Eclipse é um ambiente de desenvolvimento integrado, que reúne
ferramentas de apoio ao desenvolvimento de software. Para a implementação do
Portal foi utilizado o Eclipse 3.4 (Ganymede)8.
A seguir serão vistos detalhes de implementação dos serviços do Portal.
Login
Este serviço utiliza a API das Contas Google em Java. Seus principais
métodos são:
o createLoginURL(): retorna uma URL podendo ser utilizada para a
exibição de página de login para o usuário.
o createLogoutURL(): retorna uma URL podendo ser utilizada para
desconectar o usuário do aplicativo.
o getCurrentUser(): retorna informações sobre o usuário, se este estiver
conectado.
o isUserAdmin(): retorna um valor booleano. Se a solicitação foi feita por
um usuário administrador retorna true, caso contrário retorna false.
o isUserLoggedIn(): retorna um valor booleano. Se o usuário está
conectado retorna true, caso contrário retorna false.
A tela de login das Contas do Google informa ao usuário que ele está fazendo
login no aplicativo, utilizando o nome do aplicativo escolhido no momento do
8 (http://www.eclipse.org/ganymede/)
42
registro. Este nome pode ser alterado em Configurações do aplicativo no Console de
administração.
Após a autenticação, o usuário é redirecionado diretamente ao aplicativo.
Esse controle é realizado automaticamente pela API.
No ambiente de desenvolvimento, a API simula o sistema de contas utilizando
uma tela de login fictícia. Quando a aplicação chama a API de usuários para obter a
URL da tela de login, a API retorna uma URL especial do servidor de
desenvolvimento que solicita somente o usuário (endereço de e-mail), mas não
solicita a senha. Não é feita nenhuma verificação nos dados informados, e o
aplicativo se comportará como se tivesse sido realizado um login com uma conta
verdadeira.
Gerador de Código
O Google App Engine suporta dois padrões diferentes de APIs para
armazenamento de dados: JDO e JPA. Essas interfaces são disponibilizadas
através do DataNucleus Access Platform9, que é uma implementação de vários
padrões persistentes Java, juntamente com um adaptador para o armazenamento
de dados do GAE. Todo o armazenamento de dados necessário para
implementação do Portal proposto, foi desenvolvida utilizando essas tecnologias.
Para o desenvolvimento do layout, foi utilizado JSP, que permite a construção
de páginas dinâmicas, realizando a junção de código Java com código HTML. Foram
utilizados também servlets Java, que permitem processar dinamicamente
requisições e respostas, proporcionando novos recursos aos servidores Java.
O primeiro passo que o usuário deve seguir ao entrar nesse módulo é
escolher entre os ambientes de execução Java e Python. Ao escolher o ambiente
Java, é solicitado para que se informe o nome do projeto e o nome do pacote, que
não podem conter espaços nem caracteres especais. Se a escolha foi pelo ambiente
Python, só é solicitada a informação do nome do projeto.
O segundo passo para geração de código é escolher a personalização do
código. Esta opção fica entre inserir um exemplo de acesso a bando de dados, onde
o usuário pode inserir o nome da entidade de sua preferência, bem como a
quantidade de campos que desejar, informado o nome do campo e seu respectivo
9 (http://www.datanucleus.org/)
43
tipo de dado. A outra opção é a de gerar o código com um exemplo embutido,
podendo escolher os seguintes aplicativos: Hello World, Livro de Visitas e Login.
Figura 16 – Fluxograma do módulo gerador de código. Fonte: Autoria Própria, 2009.
O fluxograma da figura 16 ilustra o funcionamento do módulo gerador de
código. A primeira etapa é preparar o ambiente para o usuário. Isso compreende a
criação de um diretório, caso ainda não exista, para o usuário conectado ao portal.
Após a criação do diretório é realizada uma cópia de uma aplicação modelo para a
pasta do usuário, conforme prévia seleção.
A etapa de personalização dos arquivos fonte é responsável pela geração de
código na aplicação modelo contida na pasta do usuário. Essa customização é
realizada seguindo as características do projeto informadas pelo usuário através do
portal.
Caso esteja sendo gerado um projeto para o ambiente de execução em Java
é necessário realizar um processo de compilação da aplicação. Esse passo não é
necessário para o ambiente de execução em Python.
O passo seguinte é o armazenamento do projeto no banco de dados do portal
para futura consulta através da funcionalidade de Controle de Projetos.
Finalmente, o projeto é empacotado e um link para download do arquivo
gerado é disponibilizado ao usuário.
44
Submissão
O processo de submissão recebe um arquivo ZIP como entrada. Após o
upload do arquivo para o servidor, o serviço deve descompactar o pacote e colocar
cada arquivo em seu respectivo diretório. Essas etapas são realizadas através de
scripts desenvolvidos para o serviço de submissão do Portal.
Para o ambiente Java, este módulo efetua a compilação dos arquivos e, em
caso de erro, retorna uma mensagem para o usuário.
O fluxograma da figura 17 ilustra todas as etapas percorridas pelo módulo de
submissão.
Figura 17 – Fluxograma do módulo de submissão. Fonte: Autoria Própria, 2009.
Monitoramento
Para este serviço foi utilizado um arquivo XML disponibilizado pelo ambiente
do Google App Enigne.
Tutoriais
Os tutoriais estão disponibilizados no portal na forma de links para o
download de arquivos no formato PDF.
45
Controle de Projetos
Sempre que o usuário cria ou submete um novo projeto é feito um
armazenamento desses dados, para controle desse módulo.
Avaliação do Portal
A avaliação do portal foi realizada de forma qualitativa. Foi aplicado um
questionário, que pode ser visualizado no apêndice B deste trabalho, com o objetivo
de traçar o perfil do usuário, com a facilidade de utilização dos serviços do portal. O
questionário foi aplicado na turma de Sistemas Distribuídos do curso de Ciência da
Computação do Unilasalle no segundo semestre de 2009.
Foram entrevistadas três pessoas. O perfil dessas pessoas está ilustrado no
quadro 3. Nota-se que todas elas são da área de desenvolvimento de software.
Perfil
P1 P2 P3
Trabalha com desenvolvimento Sim Sim Sim Quadro 3 – Identificação do perfil dos entrevistados.
Fonte: Autoria Própria, 2009.
O quadro 4 complementa a identificação do perfil dos entrevistados. Neste
quadro está sendo exibido o nível de conhecimento de desenvolvimento Web, Java
e Python de cada pessoa.
Conhecimento
P1 P2 P3
Desenvolvimento Web 3 4 4
Desenvolvimento Java 3 4 3
Desenvolvimento Python 2 2 2 Quadro 4 – Identificação do nível de conhecimento específico dos entrevistados.
Fonte: Autoria Própria, 2009.
No quadro 5 está sendo demonstrada a avaliação de diversos serviços do
portal. A avaliação foi realizada com base em duas atividades propostas aos
entrevistados. A primeira consistia na geração de código Java e posterior submissão
do projeto, utilizando as ferramentas disponibilizadas pelo portal. A segunda tarefa
foi semelhante à primeira, com a diferença de estar voltada ao ambiente Python.
46
Avaliação Portal
P1 P2 P3
Geração de Código Java 5 5 4
Geração de Código Python 5 5 4
Submissão de Código Java 5 5 5
Submissão de Código Python 5 5 5
Tutoriais 5 4 5 Quadro 5 – Avaliação do portal.
Fonte: Autoria Própria, 2009.
Percebeu-se que mesmo para os usuários com pouco conhecimento em
determinada linguagem de programação, como Python, por exemplo, a utilização do
portal deu-se de forma bastante simples.
47
4 CONCLUSÃO
Ao longo deste trabalho foram estudados os conceitos de computação em
nuvem, seus aspectos mais importantes, bem como as oportunidades e obstáculos
que estão envolvidas neste assunto. Foi proposto e desenvolvido um portal de
serviços para computação em nuvem, com a utilização do ambiente de execução do
Google App Engine.
É possível concluir que os serviços do portal contribuem para auxiliar a
difusão de novos projetos na área de computação em nuvem.
O portal de serviços possui um grande potencial para ser expandido. Como
trabalho futuro, pode ser destacado a criação de um ambiente para edição dos
arquivos de forma on-line, facilitando a edição de novos projetos.
Outra sugestão para ampliação do portal, sugerida por um dos entrevistados
que responderam ao questionário de avaliação, é a inserção de uma lista de
bibliotecas que funcionem no servidor do Google, como por exemplo: displaytag,
displaytable, vraptor, spring, groove, e uma lista de frameworks que podem ser
incorporados nas aplicações.
Conclui-se que o portal de serviços é uma boa alternativa para pessoas que
estão iniciando o desenvolvimento de aplicações para nuvem, por ter um ambiente
amigável, e possuir serviços que auxiliam a construção de novos projetos.
48
REFERÊNCIAS
AMAZON. Amazon Elastic Compute Cloud. Disponível em: <http://aws.amazon.com/ec2/>. Acesso em: 10 maio 2009. ARMBRUST, M. et al. Above the Clouds : A Berkeley View of Cloud Computing [Relatório Técnico]. Disponível em: <http://www.eecs.berkeley.edu/Pubs/ TechRpts/2009/EECS-2009-28.pdf>. Acesso em: 15 mar. 2009. BUYYA, R. et al. Market-Oriented Cloud Computing : Vision, Hype, and Reality for Delivering IT Services as Computing Utilities. 2008. High Performance Computing and Communications. IEEE International Conference. CHAPPELL, David. Apresentando a Plataforma de Serviços Azure : uma breve análise do Windows Azure, .NET Services, SQL Services e Live Services. Disponível em: <http://www.msdnbrasil.com.br/downloads/artigostecnicos/azure/Apresentando PlataformaAzure.pdf>. Acesso em: 10 out. 2009. DELIC, K. A.; WALKER, M. A. Emergence of the academic computing clouds . Ubiquity. Disponível em: <http://doi.acm.org/10.1145/1414663.1414664>. Acesso em: 12 ago. 2009. ECLIPSE. Eclipse . Disponível em: <http://www.eclipse.org/>. Acesso em: 5 mar. 2009. FRANKLIN JUNIOR, Curtis. Cloud Computing: Technologies And Strategies Of The Ubiquitous Data. São Paulo: CRC Press, 2009. GOOGLE. Google App Engine . Disponível em: <http://code.google.com/intl/pt-BR/appengine/>. Acesso em: 12 maio 2009. HAYES, B.. Cloud computing . ACM, 2008. Disponível em: <http://doi.acm.org/10.1145/1364782.1364786>. Acesso em 12 ago. 2009. JAVA. The Source for Java Developers . Disponível em: <http://java.sun.com/>. Acesso em: 10 out. 2009. JONES, M. T. Computação em Nuvem com Linux . Disponível em: <http://www.ibm.com/developerworks/br/library/l-cloud-computing/>. Acesso em: 10 abr. 2009. LINTHICUM, D. S. Cloud Computing and SOA Convergence in Your Enterpr ise : A Step-by-Step Guide. São Paulo: Addison-Wesley Information Technology Series, 2009.
49
MC EVOY, G. V.; SCHULZE, B. Using clouds to address grid limitations . Proceedings of the 6th international Workshop on Middleware For Grid Computing, 2008. Disponível em: <http://doi.acm.org/10.1145/1462704.1462715>. Acesso em: 10 abr. 2009. MILLER, Michael. Cloud Computing - Web-Based Applications That : Change The Way You Work And Collaborate Online. São Paulo: Que, 2008. PYTHON. Python Programming Language . Disponível em: <http://www.python.org/>. Acesso em: 10 out. 2009. SUN. The Sun Cloud API. Disponível em: <http://kenai.com/projects/ suncloudapis/pages/Home>. Acesso em: 13 out. 2009. WEISS, A. 2007. Computing in the clouds . Disponível em: <http://doi.acm.org/10.1145/1327512.1327513>. Acesso em: 13 out. 2009.
50
APÊNDICE A – Guia de utilização do Google App Engin e
1. Criando uma conta no Google App Engine.
Acesse o link: http://appengine.google.com/start.
O GAE utiliza a conta padrão Google. Se você já possui uma conta padrão, vá para
o passo 2. Se não possui, clique no link destacado em vermelho na Figura 1.
Figura 1. Fonte: Google, 2009.
51
Acessando o link para criar uma nova conta, é exibida a tela da Figura 2.
Figura 2. Fonte: Google, 2009.
Basta preencher os dados solicitados, e clicar no botão “Aceito. Criar minha conta.”
52
2. Ativando uma conta no Google App Engine
Faça o login no link http://appengine.google.com/start utilizando sua conta padrão
Google. Após a autenticação do usuário, é exibida a tela da Figura 3.
Figura 3. Fonte: Google, 2009.
Para criar uma nova aplicação, deve-se clicar no botão “Create na
Application”, exibido na Figura 3. Ao clicar no botão, é mostrada a tela da Figura 4.
Nessa tela deve ser selecionado o seu país, na lista de seleção destacada em
vermelho, na Figura 4. Até a data de entrega deste trabalho, as opções disponíveis
para seleção são: Other (Not Listed), Canada, Japan e United States. Para o Brasil,
deve ser selecionada a primeira opção.
O segundo campo que deve ser preenchido é o Mobile Number, destacado
em verde na figura 4. Para celulares do Brasil, até a data de entrega deste trabalho,
somente duas operadoras de celular estão habilitadas para receber o código de
confirmação. São elas: TIM Celular S.A. e TNL PCS S.A.
Após preencher corretamente os campos, deve-se clicar no botão “Send”. Essa ação
irá disparar um SMS para o celular informado no campo Mobile Number, contendo o
código de confirmação que deverá ser informado na Figura 5.
53
Figura 4. Fonte: Google, 2009.
Na figura 5 deve ser informado o código de confirmação recebido no celular
através de uma mensagem SMS, no campo Enter Account Code.
Figura 5. Fonte: Google, 2009.
Preenchendo corretamente o campo e clicando no botão “Send”, já está
habilitada a sua conta no Google App Engine, e já se pode criar a primeira
aplicação.
3. Criando uma aplicação no Google App Engine
A tela de cadastro de uma nova aplicação está ilustrada na Figura 6. Todos
os aplicativos devem possuir um identificador único. Para verificar se o identificador
desejado ainda está disponível, basta digitá-lo no campo Application Identifier, e
54
clicar no botão “Check Availability”. Esse identificador fará parte da URL para acesso
da aplicação posteriormente.
Figura 6. Fonte: Google, 2009.
Após a escolha do identificador, deve ser preenchido o campo Application
Title, com o título da sua aplicação. Clicando no botão “Save”, sua aplicação será
registrada, e já estará habilitada para deploys (transferência da aplicação local para
os servidores do Google). Se o registro ocorreu com sucesso, será demonstrada a
tela da Figura 7.
55
Figura 7. Fonte: Google, 2009.
4. Integrando o Google App Engine com o Eclipse
Para este guia foi utilizado o Eclipse versão 3.4.2 (Ganymede).
O Google desenvolveu um Plug-in para o Eclipse, que pode ser instalado da
seguinte forma: com o Eclipse aberto, selecione Help, depois Software Updates,
conforme ilustrado na figura 8.
Figura 8. Fonte: Eclipse, 2009.
56
Após essa ação, será aberta uma janela, conforme a figura 9.
Figura 9. Fonte: Eclipse, 2009.
Nesta janela, deve ser selecionada a aba Available Software. Nessa aba,
deve ser clicado no botão “Add Site...”, destacado em vermelho na figura 10.
Figura 10. Fonte: Eclipse, 2009.
Será aberta então uma caixa de texto, onde deve ser inserido o endereço:
http://dl.google.com/eclipse/plugin/3.4, conforme ilustrado na figura 11.
57
Figura 11. Fonte: Eclipse, 2009.
Será então adicionado na lista de softwares disponíveis para instalação no
Eclipse, três novas opções: Google Plugin for Eclipse 3.4, Google App Engine Java
SDK 1.2.5 e Google Web Toolkit SDK 1.7.1.
Para instalá-los, basta clicar no checkbox Google Update Site for Eclipse 3.4,
conforme ilustrado na figura 12. Após essa seleção, deve-se clicar no botão Install....
Figura 12. Fonte: Eclipse, 2009.
Concluída a instalação do Plug-in, e reiniciado o Eclipse, serão demonstrados
três novos botões na interface do Eclipse (figura 13).
58
Figura 13. Fonte: Eclipse, 2009.
5. Criando um Projeto
O primeiro botão – New Web Application Project – possibilita a criação de um
novo projeto. Ao ser clicado, exibe a janela demonstrada na figura 14.
59
Figura 14. Fonte: Eclipse, 2009.
Nessa tela é possível definirmos o nome do projeto, e o nome do pacote do
projeto. Pode ser escolhido o local de armazenamento físico dos arquivos do projeto
em Location. Por último, são exibidas as opções de seleção do Google SDK. O
Google Web Toolkit pode ser habilitado ou desabilitado conforme a necessidade do
projeto, bem com a opção do Google App Engine. É possível escolher entre as
versões padrão instaladas, ou outra específica, conforme a necessidade.
A estrutura de diretórios ficará semelhante ao seguinte:
NovoProjeto/ src/ ...Códigos fonte Java...
60
META-INF/ ...outras configurações... jdoconfig.xml NovoProjeto/ NovoProjetoServlet.java log4j.properties war/ ...JSPs, imagens, arquivos de dados... WEB-INF/ ...configurações da aplicação... lib/ ...bibliotecas... classes/ ...classes compiladas... appengine-web.xml web.xml
O diretório war/ utiliza o layout WAR (http://java.sun.com/j2ee/tutorial/1_3-
fcs/doc/WCC3.html) padrão para agrupar aplicativos da web. Esse diretório é
necessário para a execução do servidor de desenvolvimento e para implementação
do aplicativo no GAE.
6. Compilando um Projeto
O GAE disponibiliza um compilador específico para as aplicações
desenvolvidas para a nuvem. O ícone para acioná-lo é o:
61
Figura 15. Fonte: Eclipse, 2009.
Nessa janela é possível escolher diversas opções de compilação.
7. Envio do aplicativo para a nuvem Google
O botão que faz o deploy da aplicação para a nuvem é o seguinte:
Na figura 16 estão os campos que devem ser preenchidos, para que o envio
da aplicação possa ser feito corretamente. Primeiro, o nome do projeto. Nos campos
Email e Password, deve ser informado o seu login padrão Google, que já deve ter
previamente ativado a conta no Google App Engine. Na primeira vez que o projeto é
enviado para a nuvem, devem ser informados outros parâmetros, no link App Engine
project settings...
62
Figura 16. Fonte: Eclipse, 2009.
Na figura 17 podemos ver um campo muito importante, o Application ID. Esse
identificador deve ser o mesmo que foi criado no item 3 desse guia, para que o
Google possa fazer a correta associação.
Figura 17. Fonte: Eclipse, 2009.
63
Com tudo preenchido corretamente, basta clicar no botão Deploy da figura 16,
e aguardar o envio dos arquivos para a nuvem.
Na figura 18 pode ser visualizado um exemplo de uma aplicação rodando na
nuvem Google.
Figura 18. Fonte: Autoria Própria, 2009.
64
APÊNDICE B – Questionário Avaliação
TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO
Informações para o(a) participante voluntário(a): Você está convidado(a) a responder este questionário que faz parte da coleta de dados da pesquisa para o trabalhao de conclusão de curso “Computação em Nuvem com o Google App Engine" sob responsabilidade do(a) pesquisador(a) Rodrigo Soares - UNILASALLE. Caso você concorde em participar da pesquisa, leia com atenção os seguintes pontos: a) você é livre para, a qualquer momento, recusar-se a responder às perguntas que lhe ocasionem constrangimento de qualquer natureza; b) você pode deixar de participar da pesquisa e não precisa apresentar justificativas para isso; c) sua identidade será mantida em sigilo; d) caso você queira, poderá ser informado(a) de todos os resultados obtidos com a pesquisa, independentemente do fato de mudar seu consentimento em participar da pesquisa; e) os dados serão usados de forma anônima e apenas para o TCC ou publicação decorrente do mesmo; f) a participação ou não no questionário não trará nenhuma vantagem ou desvantagem pessoal.
Questionário Avaliação
Nome
Curso
1. Trabalha na área de Informática?
Sim
Redes
Desenvolvimento
Outra
Não
2. De acordo com a tabela abaixo, indique o seu grau de conhecimento nos
assuntos listados. 1. Nenhum 2. Básico 3. Intermediário 4. Avançado
Desenvolvimento Web
Desenvolvimento Java
65
Desenvolvimento Python
3. De acordo com a tabela abaixo, indique sua impressão sobre os serviços do
portal. 1. Muito Complexo 2. Difícil 3. Normal 4. Simples 5. Muito Simples
Geração de Código Java
Geração de Código Python
Submissão de Código Java
Submissão de Código Python
Tutoriais
4. Utilize o espaço abaixo para sugestões/críticas: