AltoStratus Solucoes de Middleware para

Programa CTIC – Rede Nacional de Ensino e Pesquisa
AltoStratus: Soluções de Middleware para Composição, Execução e

Gerenciamento de Serviços em Nuvens Híbridas e Heterogêneas
Entregável do Segundo Trimestre – WP2
Estudo e caracterização de plataformas de Computação em Nuvem
Equipe Técnica:
Prof.ª Thais Vasconcelos Batista (Coordenadora) – UFRN
Prof. Nélio Alessandro Azevedo Cacho – UFRN
Prof.ª Flavia Coimbra Delicato – UFRJ
Prof. Paulo de Figueiredo Pires – UFRJ
Prof.ª Noemi de La Rocque Rodriguez – PUC-Rio
Prof.ª Ana Lúcia de Moura – PUC-Rio
Frederico Araújo da Silva Lopes – UFRN

Everton Ranielly de Sousa Cavalcante – UFRN
Diego Henrique Oliveira de Souza – UFRN
Novembro de 2011
Conteúdo
1 Introdução ................................................................................................................................... 7
2 Plataformas de Computação em Nuvem .................................................................................. 9
2.1 Amazon Web Services (AWS) .............................................................................................. 9
2.1.1 Principais serviços ...................................................................................................... 10
2.1.1.1 Amazon Elastic Compute Cloud (EC2) ......................................................... 10
2.1.1.2 Amazon Simple Storage Service (S3) ............................................................ 11
2.1.1.3 Amazon Relational Database Service (RDS) ................................................. 11
2.1.1.4 Amazon SimpleDB ........................................................................................ 11
2.1.1.5 Amazon Simple E-mail Service (SES) .......................................................... 12
2.1.2 Ferramentas de apoio ao desenvolvimento ................................................................ 12
2.1.3 API e exemplos de uso ............................................................................................... 12
2.1.3.1 Amazon Elastic Compute Cloud (EC2) ......................................................... 12
2.1.3.2 Amazon Simple Storage Service (S3) ............................................................ 14
2.1.3.3 Amazon SimpleDB ........................................................................................ 16
2.1.3.4 Amazon Simple E-mail Service (SES) .......................................................... 18
2.2 Eucalyptus ........................................................................................................................... 20
2.3OpenStack............................................................................................................................. 23
2.3.1.1 OpenStack Compute (Nova) .......................................................................... 25
2.3.1.2 OpenStack Object Storage (Swift) ................................................................. 26
2.3.1.3 OpenStack Image Service (Glance) ............................................................... 26
2.3.2.1 OpenStack Compute....................................................................................... 27
2.3.2.2 OpenStack Object Storage ............................................................................. 30
2.3.2.3 OpenStack Image Service .............................................................................. 32
2.4 Google App Engine (GAE) ................................................................................................. 33
2.4.1 Serviços escaláveis ..................................................................................................... 35
2.4.1.1 Memcache ...................................................................................................... 35
2.4.1.2 URL Fetch ...................................................................................................... 35
2.4.1.3 Serviço de e-mail............................................................................................ 36
2.4.1.4 Serviço de mensagens instantâneas ................................................................ 36
2.4.2.1 Exemplo de um simples Java servlet ............................................................. 37
2.4.3.1 Memcache ...................................................................................................... 39
2.4.3.2 URL Fetch ...................................................................................................... 40
2.4.3.3 Serviço de e-mail............................................................................................ 41
2.4.3.4 Serviço de mensagens instantâneas ................................................................ 45
2.4.3.5 Acesso a estatísticas do banco de dados via código-fonte ............................. 45
2.4.3.6 Monitoramento de status de capacidade ........................................................ 45
2.4.3.8 Monitoramento de quota de serviços ............................................................. 46
2.4.3.9 Implantação de aplicações.............................................................................. 48
2.5 Windows Azure Platform .................................................................................................... 48
2.5.1.1 Windows Azure Compute .............................................................................. 49
2.5.1.2 Microsoft SQL Azure Database ..................................................................... 50
2.5.1.3 Windows Azure Virtual Machine (VM) ........................................................ 51
2.5.1.4 Windows Azure Storage ................................................................................ 51
2.5.1.5 Windows Azure AppFabric Caching ............................................................. 52
2.5.1.6 Windows Azure AppFabric Service Bus ....................................................... 52
2.5.1.7 Business Intelligence ...................................................................................... 52
2.5.3 Exemplo de uso .......................................................................................................... 53
2.6 Discussão ............................................................................................................................. 56
3 Considerações finais ................................................................................................................. 59
Referências ................................................................................................................................... 61
Lista de Figuras
Figura 1. Página principal do Amazon Web Services (AWS) – http://aws.amazon.com .............. 9
Figura 2. Criação de diferentes instâncias a partir de uma AMI no Amazon EC2. ..................... 10
Figura 3. Trecho de exemplo de código Java utilizando a Amazon EC2 API. ............................ 14
Figura 4. Trecho de exemplo de código Java utilizando a Amazon S3 API. ............................... 15
Figura 5. Trecho de exemplo de código Java utilizando a Amazon SimpleDB API (Parte 1 de 2).
.................................................................................................................................... 17
.................................................................................................................................... 18
Figura 7. Trecho de exemplo de código Java utilizando a Amazon SES API. ............................ 20
Figura 8. Página inicial do Eucalyptus – http://www.eucalyptus.com ......................................... 21
Figura 9. Componentes básicos do Eucalyptus. ........................................................................... 22
Figura 10. Esquema de infraestrutura Eucalyptus e seus componentes básicos de serviços. ...... 23
Figura 11. Página inicial do OpenStack – http://www.openstack.org/ ........................................ 24
Figura 12. Serviços da plataforma OpenStack. ............................................................................ 25
Figura 13. Exemplo de operação com o OpenStack Compute. .................................................... 28
Figura 14. Definição da interface EntityManager para operação com o OpenStack Compute. 29
Figura 15. Operações envolvendo a interface EntityManager com binding para Java. ............ 30
Figura 16. Exemplo de requisição e resposta em operação com o OpenStack Object Storage. .. 31
Figura 17. Obtenção da lista de objetos armazenados em um container no OpenStack Object
Storage com o uso de binding da API para a linguagem Java. ................................... 32
Figura 18. Exemplo de resposta JSON em operação com o OpenStack Image Service. ............. 33
Figura 19. Exemplo de requisição em operação com o OpenStack Image Service. .................... 33
Figura 20. Página inicial do Google App Engine (GAE) –
http://code.google.com/intl/pt-BR/appengine/ ........................................................... 34
Figura 21. Estrutura de um projeto Java no Eclipse com o GAE. ................................................ 37
Figura 22. Exemplo de servlet para obtenção de data/hora. ......................................................... 38
Figura 23. Conteúdo do descritor de implantação web.xml. ....................................................... 38
Figura 24. Conteúdo do arquivo appengine‐web.xml. ............................................................. 39
5
Figura 25. Trecho de código Java para obtenção de identificador para implementação do cache.
.................................................................................................................................... 39
Figura 26. Exemplo de servlet utilizando o serviço URL Fetch. ................................................. 40
Figura 27. Exemplo de servlet para envio de e-mails utilizando o serviço de e-mail do GAE.... 42
Figura 28. Mapeamento de caminho de entrada de e-mail para Java servlet no arquivo web.xml.
.................................................................................................................................... 43
Figura 29. Exemplo de servlet para o recebimento de e-mails..................................................... 44
Figura 30. Trecho de código para envio de uma mensagem instantânea via GAE. ..................... 45
Figura 31. Obtenção de estatísticas de aplicação implantada no GAE a partir do dashboard. .... 45
Figura 32. Obtenção do status de funcionamento de partes de aplicação implantada no GAE. .. 46
Figura 33. Trecho de código com chamadas a métodos para mensurar o processamento requerido
por uma aplicação no GAE em um dado momento. ................................................... 47
Figura 34. Mapeamento da appstats do GAE para Java servlet no arquivo web.xml. ................ 47
Figura 35. Página inicial do Windows Azure Platform –
http://www.microsoft.com/windowsazure/ ................................................................ 48
Figura 36. Estrutura do Windows Azure e serviços que compõem a plataforma. ....................... 49
Figura 37. Criação de Serviço Hospedado ................................................................................... 54
Figura 38. Seleção de arquivos para implantação de serviço no Windows Azure. ...................... 54
Figura 39. Conteúdo do arquivo de configuração ServiceConfiguration.cspkg. ............... 55
Figura 40. Código ASP .NET da página a ser exibida. ................................................................ 55
Figura 41. Página ASP .NET do exemplo em execução. ............................................................. 56
6
Lista de Tabelas
Tabela 1. Principais comandos do Amazon EC2 organizados por funções. ................................ 13
Tabela 2. Principais comandos do Amazon S3 organizados por tipos de operações. .................. 14
Tabela 3. Comandos do Amazon SimpleDB. ............................................................................... 16
Tabela 4. Comandos do Amazon SES. ......................................................................................... 18
Tabela 5. Tempos máximos de processamento especificados pelo SLA do Azure Storage. ....... 51
Tabela 6. Principais informações sobre as plataformas analisadas. ............................................. 58
7
1 Introdução
Computação em Nuvem é “um tipo de sistema paralelo e distribuído que consiste de uma
coleção de computadores conectados e virtualizados que são dinamicamente provisionados e
apresentados como um ou mais recursos computacionais” (Buyya et al., 2008). Porém, o termo
Computação em Nuvem refere-se não somente à estrutura de hardware e de software dos
datacenters, mas também aos serviços providos por estes (Armbrust et al., 2009; Zhang et al.,
2010). Do ponto de vista dos serviços oferecidos, a Computação em Nuvem pode ser conceituada
como um conjunto de serviços disponibilizados via rede, provendo escalabilidade,
personalização, garantias de QoS, infraestruturas sob demanda e de baixo custo, os quais podem
ser acessados de um modo simples e pervasivo (Wang et al., 2010).
Tipicamente, plataformas de Computação em Nuvem disponibilizam interfaces que
possibilitam que os usuários, utilizando qualquer dispositivo conectado à Internet, possam ter
acesso aos serviços, arquivos, informações e programas situados “na nuvem”. Ou seja,
plataformas de Computação em Nuvem são provedores de serviços as quais viabilizam a ideia da
computação utilitária, que significa computação ao alcance de todos, onde usuários pagam pelos
serviços computacionais que utilizam.
Conceitualmente, as plataformas de Computação em Nuvem proveem suas
funcionalidades como serviços. Essas funcionalidades podem ser categorizadas como HaaS –
Hardware as a Service (hardware como um serviço)1, SaaS – Software as a Service (software
como um serviço), e DaaS – Data as a Service (dados como um serviço). Assim, serviços
baseados em uso de hardware, software e armazenamento de dados, respectivamente, são
oferecidos aos usuários finais. Detalhes sobre essa categorização podem ser encontrados no
trabalho de Wang et al. (2010). Para suportar IaaS, SaaS e DaaS, uma infraestrutura de
Computação em Nuvem pode, adicionalmente, disponibilizar uma quarta categoria de serviços,
denominada PaaS – Platform as a Service (plataforma como um serviço). PaaS, também
chamado de cloudware, é um nível adicional de abstração que permite o desenvolvimento e
gestão de aplicações sob medida “na nuvem”. Portanto, o PaaS propicia uma plataforma na qual
aplicações são desenvolvidas usando abstrações construídas sobre a infra-estrutura subjacente.
Assim, os usuários ganham maior poder para criar e instalar suas próprias aplicações utilizando
os serviços IaaS, SaaS e DaaS.
Várias importantes empresas estão fornecendo plataformas de computação em nuvem,
como Amazon, Google e Microsoft, além de haver também várias iniciativas open-source como
Eucalyptus e OpenStack. Os exemplos comerciais mais conhecidos de PaaS são o Amazon Web
Services, Google Code, Salesforce PaaS e o Windows Azure.
1
No nível de serviço HaaS, também se lida com a virtualização de recursos, de modo que, às vezes, os serviços de
HaaS são tidos como serviços de IaaS – Infrastructure as a Service (infraestrutura como serviço), visto que se
podem prover recursos físicos propriamente ditos como virtualizados, a exemplo das máquinas virtuais. No
presente relatório, a menção acerca de serviços de IaaS também se referirá, implicitamente, aos serviços de HaaS.
8
Embora as plataformas de Computação em Nuvem, de um modo geral, não exijam muito

esforço de programação do lado do usuário (utilizador dos serviços), já que muitas vezes ele só
precisa de um navegador para acessar os serviços, a necessidade de composição de serviços,
visando agregar serviços oferecidos por diferentes plataformas de nuvem, aumenta esse esforço,
uma vez que obriga que a composição seja realizada do lado do usuário. Isso ocorre uma vez que
a falta de padronização de interoperabilidade impossibilita que a composição seja realizada
automaticamente pelas próprias plataformas. Assim, a composição exige a manipulação de um
vasto número de APIs e protocolos não interoperáveis entre si de diferentes plataformas de
computação em nuvem, e ainda do uso contínuo de diferentes serviços de descoberta de serviços.
Para evitar essa maior complexidade no lado do usuário, uma solução é prover uma infraestrutura
de desenvolvimento que permita a integração dos serviços providos por diferentes plataformas de
computação em nuvem. Assim, essa infraestrutura possibilitaria o uso de serviços de diversos
provedores de forma transparente para o usuário, caracterizando uma nuvem híbrida, que consiste
na utilização de duas ou mais nuvens a fim de gerar valor agregado para o usuário.
Visando endereçar esse problema da necessidade de composição de serviços em um
ambiente atualmente não dotado de características de interoperabibildade, o Projeto AltoStratus
tem como objetivo propor, especificar, implementar, implantar e avaliar técnicas e mecanismos
de um middleware, o Cloud Integrator, para composição, execução e gerenciamento de serviços
em ambiente de nuvens computacionais híbridas e heterogêneas. Portanto, esse Projeto realizará a
instanciação de uma infraestrutura de nuvem híbrida, sobre a qual serão executados o middleware
Cloud Integrator e os serviços disponibilizados por esse middleware. Para tal, várias plataformas
de computação em nuvem serão usadas pelo Cloud Integrator.
O objetivo desse relatório é fornecer uma visão geral das características principais e dos
serviços providos por diferentes plataformas de nuvens, bem como ilustrar o uso de cada uma
delas. A finalidade do levantamento realizado e descrito neste documento é identificar pontos
positivos e negativos das plataformas mais conhecidas e apontar as potencialmente mais
adequadas para utilização no contexto desse projeto, com base em requisitos como facilidade de
uso, disponibilidade, conjunto de serviços oferecidos, acesso livre ou a um custo baixo.
Este documento está estruturado da seguinte forma. O Capítulo 2 apresenta uma visão
geral de diversas plataformas de nuvem disponíveis e uma discussão sobre os pontos positivos e
negativos de cada uma delas. Por fim, no Capítulo 3 são delineadas algumas considerações finais
e apontadas as direções para os trabalhos futuros.
9
2 Plataformas de Computação em Nuvem

Este capítulo apresenta uma visão geral de diversas plataformas de nuvem disponíveis no
mercado, incluindo uma breve apresentação sobre os serviços providos por cada plataforma, bem
como exemplos simples de uso de cada uma delas. A Seção 2.1 apresenta os serviços Amazon
Web Services (AWS), a Seção 2.2 apresenta o Eucalyptus, a Seção 2.3 discorre sobre o
OpenStack, a Seção 2.4 apresenta o Google App Engine (GAE), a Seção 2.5 resume o Windows
Azure. Finalmente, a Seção 2.6 apresenta uma discussão sobre as plataformas apresentadas,
ressaltando as diferenças entre elas.
2.1 Amazon Web Services (AWS)

Amazon Web Services (AWS) (http://aws.amazon.com/), serviços de nuvem providos pela
Amazon, são utilizados largamente por empresas de vários tamanhos e domínios e oferecem
poder computacional, facilidades de armazenamento e várias outras funcionalidades que
permitem que empresas implantem aplicações e serviços a um baixo custo, com grande
flexibilidade, escalabilidade e confiabilidade.
Figura 1. Página principal do Amazon Web Services (AWS) – http://aws.amazon.com

10
2.1.1 Principais serviços

Essa subseção apresenta os principais serviços da plataforma Amazon Web Services
(AWS), sendo eles: (i) Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service
(S3), Amazon Relational Database Service (RDS), Amazon SimpleDB e Amazon Simple E-mail
Service (SES).
2.1.1.1 Amazon Elastic Compute Cloud (EC2)
Um dos principais serviços oferecidos no portfolio AWS é o Amazon EC2

(http://aws.amazon.com/ec2/), um serviço que oferece capacidade de computação
redimensionável (i.e. elástica) na nuvem. Esse serviço apresenta-se como um verdadeiro
ambiente de computação virtual, permitindo aos usuários, através de uma interface Web simples,
criar, usar e gerenciar máquinas virtuais com sistemas operacionais Windows e Linux, ou mesmo
iniciar tais máquinas de acordo com as necessidades das aplicações. Como acontece na
Computação em Nuvem, o usuário paga apenas pelos recursos consumidos, por instância-horas
e/ou transferência de dados (cobrado por gigabyte de dados transferidos).
No Amazon EC2, tem-se AMIs (Amazon Machine Images), que funcionam como uma
espécie de template e contêm uma pré-configuração de software (e.g. sistema operacional e
aplicações), a partir das quais se podem criar instâncias (máquinas virtuais), que são cópias
executáveis da AMI, como ilustra a Figura 2. Essas instâncias, que podem ser múltiplas e
inclusive de diferentes tipos, são executadas até que sejam paradas ou finalizadas pelo usuário; se
uma instância porventura falhar, pode-se criar uma nova a partir da AMI selecionada.
Figura 2. Criação de diferentes instâncias a partir de uma AMI no Amazon EC2.
O SLA (Service Level Agreement)2 do Amazon EC2, disponível em

http://aws.amazon.com/ec2-sla/, estabelece que a disponibilidade do serviço é de 99,95% por
ano, sendo provido ao cliente um crédito de 10% do valor de sua conta caso essa disponibilidade
não seja verificada.
2
SLA (Service Level Agreement) é uma espécie de contrato firmado entre o provedor de um serviço e o cliente do
mesmo, sendo descrito o serviço, suas metas, papeis e garantias de qualidade de serviço (Verma, 1999).
11
2.1.1.2 Amazon Simple Storage Service (S3)
Amazon S3 (http://aws.amazon.com/s3/) é um serviço que provê uma infraestrutura de

armazenamento para lidar com grandes quantidades de dados. Esse serviço provê uma interface
Web simples que pode ser utilizada para armazenar e recuperar qualquer quantidade de dados a
partir de qualquer lugar da Web. No Amazon S3, cada objeto (i.e. dados e respectivos
metadados), cujo tamanho pode ir de 1B a 5TB, é armazenado em um bucket, que é um container
para objetos armazenados no Amazon S3 o qual pode ser recuperado de maneira unívoca através
de uma chave de acesso.
O SLA do Amazon EC2, disponível em http://aws.amazon.com/s3-sla/, estabelece que a
disponibilidade do serviço (uptime) é de 99,9% por mês, sendo provido ao cliente um crédito de
10% do valor de sua conta caso essa disponibilidade seja maior ou igual a 99% porém inferior
aos 99,9% estabelecidos por mês, ou de 25% caso seja inferior a 99%.
2.1.1.3 Amazon Relational Database Service (RDS)
Amazon RDS (http://aws.amazon.com/rds/) é um serviço PaaS que implementa um banco

de dados relacional em nuvem, além de possibilitar a configuração e operação do banco. O
Amazon RDS é projetado para desenvolvedores ou empresas que necessitam de todos os recursos
e capacidades de um banco de dados relacional ou que desejam migrar aplicações existentes e
ferramentas que utilizam um banco de dados desse tipo para a nuvem. Assim, como o Amazon
RDS provê acesso às capacidades de um banco de dados MySQL ou Oracle, códigos e
aplicações, bem como ferramentas utilizadas para esses tipos de bases de dados, podem ser
utilizados de maneira simples no Amazon RDS.
2.1.1.4 Amazon SimpleDB
Amazon SimpleDB (http://aws.amazon.com/simpledb/) é um serviço que, como o próprio

nome diz, implementa um banco de dados simples, no sentido em que oferece um número de
funcionalidades menor se comparado a bancos de dados relacionais, mas que, entretanto, pode ser
considerado suficiente para várias aplicações que empregam dados e não necessitam manipular
relacionamentos entre tais dados, como em aplicações de log.
No Amazon SimpleDB utiliza-se o conceito de domínios, que corresponde ao conceito de
tabelas existente em bancos de dados relacionais. Como explanado adiante na Seção 2.1.1.3, esse
serviço provê uma API simples para se fazer operações de acesso e armazenamento em bancos de
dados, além de indexar dados automaticamente, facilitando assim as tarefas relacionadas ao
gerenciamento de dados. Entretanto, como esse serviço é bem limitado em termos de funções,
para aplicações que dependem de desempenho e de sistemas com bases de dados relacionais
comerciais (além de tipicamente um administrador de banco de dados), o Amazon RDS seria a
melhor escolha para a implantação desse tipo de banco de dados.
12
2.1.1.5 Amazon Simple E-mail Service (SES)
Amazon SES (http://aws.amazon.com/ses/) é um serviço para envio de e-mails para

desenvolvedores e empresas que se propõe a eliminar complexidade e custos de se construir uma
solução de e-mail in-house ou de licenciamento, instalação e operação de um serviço de terceiros,
visto que construir soluções de e-mail de larga escala para o envio de mensagens transacionais e
de marketing é frequentemente um desafio complexo e custoso para as empresas.
O Amazon SES é integrado a outros serviços AWS, tornando mais fácil o envio de e-
mails a partir de aplicações hospedadas em serviços como o Amazon EC2. Através de uma API
simples, apresentada na Seção 2.1.3.4, empresas podem acessar uma infraestrutura de e-mail
altamente disponível para se comunicarem com seus clientes de maneira eficiente e barata.
2.1.2 Ferramentas de apoio ao desenvolvimento

O AWS Toolkit for Eclipse (http://aws.amazon.com/eclipse/) é um plug-in open-source
para o IDE Eclipse3que tem por objetivo tornar fácil o desenvolvimento, implantação
(deployment) e depuração de aplicações desenvolvidas na linguagem de programação Java
utilizando os serviços AWS. Esse toolkit inclui o chamado AWS Explorer, que permite ao
usuário interagir com os serviços AWS através do IDE, e também possui suporte para o AWS
Elastic Beanstalk, para que o usuário possa implantar a aplicação desenvolvida na nuvem da
Amazon. Na Seção 2.1.3 são mostrados exemplos simples de aplicações Java que fazem uso das
facilidades providas por esse Eclipse plug-in.
O AWS Toolkit for Visual Studio (http://aws.amazon.com/visualstudio/), similar ao
Eclipse plug-in, é uma extensão para o IDE Microsoft Visual Studio, que tem por objetivo tornar
fácil o desenvolvimento, depuração e implantação de aplicações utilizando a plataforma .NET e
os serviços AWS. Esse toolkit também inclui o AWS Explorer e possui suporte para o AWS
CloudFormation, permitindo a implantação de aplicações .NET na nuvem da Amazon.
2.1.3 API e exemplos de uso

2.1.3.1 Amazon Elastic Compute Cloud (EC2)
A Tabela 1 apresenta uma breve descrição dos principais comandos utilizados no Amazon
EC2. A lista completa de comandos (115 no total), bem como a descrição detalhada de cada um
deles e os tipos de dados envolvidos, pode ser encontrada no Amazon Elastic Compute Cloud
API Reference, disponível no endereço http://awsdocs.s3.amazonaws.com/EC2/latest/ec2-
api.pdf.
3
Eclipse – http://www.eclipse.org/
13
Tabela 1. Principais comandos do Amazon EC2 organizados por funções.
Funções Comandos (actions) Descrição

4
Regiões e zonas Mostra as zonas de disponibilidade para a
describeAvailabilityZones
de disponibilidade instanciação de máquinas virtuais no EC2
Retorna informações acerca das
describeInstances instâncias de propriedade do usuário em
questão
Cria um número específico de instâncias
runInstances
Instâncias a partir de uma AMI
startInstances Inicia uma ou mais instâncias
stopInstances Paralisa uma ou mais instâncias
terminateInstances Termina (finaliza) uma ou mais instâncias
Habilita o monitoramento para uma
monitorInstances
instância em execução
Monitoramento
Desabilita o monitoramento para uma
unmonitorInstances
instância em execução
A Figura 3 apresenta um exemplo de manipulação do Amazon EC2. As linhas 5 e 6 criam

um cliente do serviço EC2 utilizando as credenciais (chave de acesso e chave secreta) do usuário
na infraestrutura AWS. A linha 11 recupera quais as zonas disponíveis para instanciação de
máquinas virtuais no EC2. A linha 15 recupera a descrição das instâncias de máquinas virtuais de
propriedade do usuário, enquanto nas linhas 16 a 21 a referência de cada uma das instancias são
recuperadas, podendo essas instancias estarem executando ou não. A linha 26 instancia um objeto
da classe StopInstancesRequest, responsável por armazenar a coleção de instâncias que
devem ter sua execução paralisada. Esse objeto é populado pelo código contido entre as linhas 28
a 37. Nesse trecho de código, cada instância tem alguns de seus detalhes impressos na tela
(identificador, endereço IP e status de cada instância). A linha 35 verifica se cada instancia está
em execução de modo que, se uma instancia estiver em execução, seu identificador é armazenado
em uma coleção. Essa coleção é adicionada ao objeto da classe StopInstancesRequest (linha
39). Por fim, a linha 40 paralisa a execução de todas as instâncias em execução.
4
No Amazon EC2, os conceitos de regiões (Regions) e zonas de disponibilidade (Availability Zones) são utilizados
para se referirem à localização das instâncias nos datacenters da Amazon. Regiões são dispersas e localizadas em
áreas geográficas distintas (EUA, Europa, etc.) e agregam zonas de disponibilidade, que são locais distintos dentro
de uma região. Uma explanação maior acerca desses conceitos pode ser encontrada no Amazon Elastic Compute
Cloud User Guide, disponível no endereço http://awsdocs.s3.amazonaws.com/EC2/latest/ec2-ug.pdf.
14
Figura 3. Trecho de exemplo de código Java utilizando a Amazon EC2 API.
2.1.3.2 Amazon Simple Storage Service (S3)
S3. A lista completa de comandos, bem como a descrição de cada um deles e os tipos de dados
envolvidos, pode ser encontrada no Amazon Simple Storage Service API Reference, disponível
no endereço http://awsdocs.s3.amazonaws.com/S3/latest/s3-api.pdf.
Tabela 2. Principais comandos do Amazon S3 organizados por tipos de operações.
Funções Comandos Descrição

Retorna uma lista dos buckets de propriedade do
listAllMyBuckets
usuário em questão
Operações sobre createBucket Cria um bucket
buckets
deleteBucket Elimina um bucket
listBucket Retorna informações acerca de itens em um
15
bucket
Adiciona um objeto de tamanho menor ou igual a
putObjectInline
1MB a um bucket
putObject Adiciona um objeto a um bucket
Operações sobre Cria uma cópia de um objeto, especificadas as
copyObject
objetos chaves dos buckets de origem e de destino
getObject Recupera um objeto
Elimina um objeto
deleteObject
(que não poderá ser restaurado)
A Figura 4 apresenta um exemplo de manipulação do Amazon S3 através da API Java

disponibilizada pelo AWS. Assim como no EC2, as credenciais do usuário devem ser passadas
como parâmetro na criação do objeto cliente do serviço (linhas 5 e 6). A linha 11 busca a lista de
buckets do usuário no S3. A partir da linha 15, para cada bucket, a lista de arquivos armazenados
é recuperada com o objetivo de descobrir a quantidade de arquivos armazenados e a quantidade
de bytes utilizados pelo usuário no S3.
Figura 4. Trecho de exemplo de código Java utilizando a Amazon S3 API.

16
2.1.3.3 Amazon SimpleDB
SimpleDB:
Tabela 3. Comandos do Amazon SimpleDB.
Comandos Descrição
createDomain Cria um domínio
listDomain Lista um domínio
deleteDomain Elimina um domínio (por vez)
Lê metadados de um domínio, e.g. requisitos atuais de espaço
domainMetadata
de armazenamento
Adiciona ou atualiza um registro com base em um identificador
putAttributes
de registro (record identifier) e pares atributo/valor
Dispara, simultaneamente, múltiplas operações de inserção
batchPutAttributes
(insert) com o objetivo de aumentar o desempenho
deleteAttributes Elimina registros, atributos ou valores
getAttributes Lê um registro
Executa uma query (consulta) sobre a base de dados utilizando
Select uma sintaxe similar a SQL, mas sem ser aplicada a múltiplos
domínios, como é possível fazer com joins (junções)
A Figura 5 apresenta um exemplo de código fonte Java que manipula o serviço

SimpleDB. As linhas 7 e 8 criam uma instância cliente do serviço SimpleDB, passando como
parâmetro as credenciais (chave de acesso e chave secreta) do usuário na infraestrutura AWS
através do arquivo AWSCredentials.properties. A linha 11 cria um domínio no SimpleDB,
domínio esse que serve com referencia para os dados que serão armazenados. Nesse exemplo, são
armazenados dados sobre as operações dos usuários em um sistema fictício (i.e. um serviço de
log). A linha 13 cria um novo registro de log, indicando que o usuário de nome Maria efetuou
login no sistema, enquanto a linha 14 insere esse registro de log no SimpleDB utilizando o
método putLog, implementado entre as linhas 45 e 55 (c.f. Figura 6). Outros registros de log são
inseridos até a linha 26. A linha 29 lista todos os logs do usuário de nome Maria utilizando o
métodolistLogPerUser, que recupera esses logs e é implementado entre as linhas 57 e 81 (c.f.
Figura 6).
17
A Figura 6 apresenta os métodos de inserção de um log e de listagem de logs de um

mesmo usuário. O método putLog (linhas 45 a 55) insere um log no serviço SimpleDB. As
linhas 48 a 52 apresenta a instanciação de um objeto responsável por armazenar os dados do log
(username, date, time e action). Por fim, a linha 54 armazena os dados do log no domínio
previamente criado (LOG) no SimpleDB. A Figura 6 também apresenta o método
listLogPerUser (linhas 57 a 81), responsável por listar todos os logs de um usuário específico.
A linha 61 cria a expressão de consulta no SimpleDB responsável por buscar no domínio LOG
todos as tuplas do usuário passado como parâmetro. A linha 63 instancia um objeto da classe
SelectRequest, objeto esse responsável por configurar a requisição da consulta na base de
dados. A linha 68 apresenta a consulta através do cliente do SimpleDB, que recupera todas as
tuplas de log de um respectivo usuário e as adiciona em uma coleção de objetos.
18
2.1.3.4 Amazon Simple E-mail Service (SES)
SES. A lista completa dos tipos de dados pode ser encontrada no Amazon Simple Email Service
API Reference, disponível no endereço http://s3.amazonaws.com/awsdocs/ses/latest/ses-api.pdf.
Tabela 4. Comandos do Amazon SES.
Comandos Descrição
Elimina um endereço de e-mail específico da lista de e-mails
deleteVerifiedEmailAddress
verificados
getSendQuota Recupera o limite atual de envio pelo usuário em questão
Recupera as estatísticas (de duas semanas) de envio do
getSendStatistics
usuário em questão
Retorna uma lista contendo todos os endereços de e-mail
listVerifiedEmailAddress
verificados
Compõe uma mensagem de e-mail baseada em dados de
sendEmail entrada e imediatamente enfileira a mensagem para posterior
envio
sendRawEmail Envia uma mensagem de e-mail com cabeçalho e conteúdo
19
especificado pelo cliente, sendo bastante útil para o envio de

e-mails MIME multipart
verifyEmailAddress Verifica um endereço de e-mail
A Figura 7 apresenta um exemplo de código Java que manipula a API do Amazon SES.
As linhas 8 a 11 apresentam a instanciação de um cliente do serviço através das credenciais do
usuário. A linha 13 verifica, através do método verifyEmailAddress (linhas 43 a 52), o
endereço de e-mail usado como remetente no e-mail que será enviado; essa verificação é exigida
pela infraestrutura AWS para se certificar que o usuário é realmente dono do endereço de e-mail
utilizado como remetente na mensagem. A linha 15 inicia a configuração da mensagem que será
enviada, informando qual o protocolo de transporte que deverá ser usado no envio da mensagem.
A linha 18 recupera uma sessão de acordo com as propriedades definidas, sessão essa usada
posteriormente para o envio da mensagem. Nas linhas 21 a 26 a mensagem a ser enviada é
configurada com o remetente, destinatário, assunto da mensagem e a mensagem em si. A linha 28
instância um objeto da classe Transport, que utiliza a sessão anteriormente recuperada, e que
envia a mensagem para o destinatário (linha 30). Por fim, a linha 32 fecha a sessão utilizada pelo
objeto da classe Transport. O método verifyE‐mailAddress é apresentado a partir da linha
43. Esse método recebe uma instância cliente do Amazon SES e o endereço de e-mail do
remetente da mensagem. Esse método primeiro recupera a lista de e-mails já verificados para esse
usuário (linha 45). Caso o e-mail passado com parâmetro esteja contido na lista de e-mails
verificados (linha 47), o método finaliza a execução e a mensagem poderá ser enviada. Caso o e-
mail ainda não tenha sido verificado, o processo de verificação do e-mail é iniciado (linha 50).
20
Figura 7. Trecho de exemplo de código Java utilizando a Amazon SES API.
2.2 Eucalyptus
Eucalyptus, acrônimo de Elastic Utility Computing Architecture Linking Your Programs
To Useful Sytems (http://www.eucalyptus.com/), é um software open source para a
implementação de uma infraestrutura de nuvem IaaS (Infrastructure-as-a-Service). Seu principal
propósito é permitir a implantação de nuvens privadas em empresas, ou de nuvens híbridas, que
permitem a combinação de recursos privados locais com recursos disponibilizados em nuvens
públicas. Em especial, devido à sua compatibilidade com as APIs adotadas pela nuvem da
Amazon (AWS), o Eucalyptus permite a construção de nuvens híbridas compostas com recursos
21
disponibilizados por essa nuvem pública. O software Eucalyptus é distribuído livremente e pode
ser redistribuído ou modificado sob os termos da licença GNU General Public License, versão 3.
O Eucalyptus iniciou como um projeto do Laboratório MAYHEM do Computer Science
Department da University of California, Santa Barbara, EUA. Em 2009, a equipe desse projeto
criou uma empresa (Eucalyptus Systems Inc.) para comercializá-lo. Atualmente, existem duas
vertentes do software Eucalyptus: um projeto open source e o produto Eucalyptus EE (Enterprise
Edition), sua versão comercial. A versão comercial adiciona algumas facilidades não disponíveis
na versão open source, como o suporte ao hipervisor5 VMWare, a conversão de imagens de
máquina virtual VMware para o formato Eucalyptus ou Amazon e um adaptador que permite o
armazenamento de blocos de dados em uma rede SAN (Storage Area Network).
Figura 8. Página inicial do Eucalyptus – http://www.eucalyptus.com
As principais características do Eucalyptus incluem:

 API compatível com AWS EC2;
 serviço de armazenamento compatível com Amazon S3;
5
Também conhecido como VMM – virtual machine monitor, elemento que monitora e gerencia máquinas virtuais.
22
 compatibilidade com o formato de imagens de máquina virtual adotado na nuvem da

Amazon (AMI), além de um padrão próprio (Eucalyptus Machine Image, EMI);
 possibilidade de configuração e gerenciamento de pools de recursos virtuais;
 gerenciamento de identidades de usuários com API compatível com Amazon IAM
(Identity Access Management) e integrável a sistemas LDAP ou Microsoft Active
Directory.
Além disso, a nova versão do Eucalyptus (Eucalyptus 3) inclui mecanismos automáticos
de failover e failback baseados na replicação de seus principais componentes de serviço, que
podem ser utilizados para a implantação de uma infraestrutura de nuvem de alta disponibilidade.
Já o Eucalyptus Community Cloud (ECC, disponível em
http://open.eucalyptus.com/try/community-cloud) é um ambiente de serviços de nuvem baseado
no Eucalyptus disponibilizado sem custos para testes e experimentações. Qualquer usuário
registrado no site da Comunidade Eucalyptus (http://open.eucalyptus.com/) tem livre acesso aos
recursos dessa nuvem.
A nuvem ECC não tem o propósito de prover suporte a sistemas de produção, e seus
recursos são oferecidos num esquema de melhor esforço (best-effort) e com uma série de
restrições de uso que limitam, por exemplo, o tempo de vida máximo de instâncias (6 horas), o
número máximo de instâncias em execução (4), e o tempo de vida e tamanho máximos de
volumes de dados (respectivamente, 3 semanas e 5GB).

Como a ideia do Eucalyptus é prover uma infraestrutura de nuvem IaaS compatível com a
nuvem da Amazon (AWS), os serviços básicos de computação virtual e armazenamento dessa
nuvem são implementados por componentes de serviço Eucalyptus, conforme mostrado na Figura
9.
Figura 9. Componentes básicos do Eucalyptus.
Os componentes de serviço Eucalyptus são implementados como serviços Web

independentes que oferecem, sobre sua interface básica de serviço, uma camada adicional que
23
expõe uma interface compatível com os serviços AWS. Internamente, uma infraestrutura
Eucalyptus é composta por quatro componentes básicos de serviço, ilustrados na Figura 10 e
detalhados a seguir.
Figura 10. Esquema de infraestrutura Eucalyptus e seus componentes básicos de serviços.
Cloud Controller. Implementa o ponto de entrada na nuvem para usuários e

administradores, oferecendo a interface para um serviço de computação virtual compatível com
Amazon EC2, sendo responsável por coletar informações dos controladores de nós de execução
para tomar decisões de escalonamento repassadas aos controladores de clusters.
Cluster Controller. É o componente responsável pela gerência em grupo de nós de
execução (cluster). O conceito de um cluster Eucalyptus é similar ao conceito de uma zona de
disponibilidade (availability zone) na rede da Amazon. Um cluster controller é responsável por
escalonar a execução de instâncias de máquinas virtuais nos nós de seu grupo.
Node Controller. É o componente responsável por gerenciar a execução de instâncias de
máquinas virtuais no nó que o hospeda.
Storage Controller (Walrus). É um serviço de armazenamento compatível com o Amazon
S3. Provê basicamente dois tipos de funcionalidade, (i) um serviço de armazenamento e
recuperação de grandes volumes de dados, e (ii) um serviço de armazenamento de imagens de
máquinas virtuais.
2.3 OpenStack
OpenStack (http://www.openstack.org/) é um projeto de desenvolvimento colaborativo de
uma plataforma open-source de serviços de nuvem. O objetivo do projeto é oferecer soluções
para a construção de diversos tipos de nuvens, públicas ou privadas, de pequena ou larga escala.
Essas soluções são disponibilizadas através de licença Apache 2.0 e podem ser livremente
utilizadas por provedores de serviços de nuvem, empresas, grupos de pesquisa ou qualquer outra
organização que necessite implantar uma infraestrutura de provisionamento e gerência de
24
serviços de computação virtual e armazenamento de grandes volumes de dados. Todo o código

desenvolvido no projeto OpenStack está disponível no repositório público GitHub
(https://github.com/openstack/).
O projeto OpenStack foi criado em parceria pela NASA (National Aeronautics and Space
Administration) e a Rackspace Hosting (http://www.rackspace.com/), um grande provedor de
serviços de nuvem e hospedagem. Tanto a nuvem pública da Rackspace como a nuvem da NASA
possui hoje, em seu núcleo, serviços baseados em componentes OpenStack. Atualmente o projeto
OpenStack reúne em sua comunidade de colaboradores diversas companhias de peso como Cisco,
Citrix, Dell, Intel e Microsoft.
Figura 11. Página inicial do OpenStack – http://www.openstack.org/
No contexto do OpenStack são desenvolvidos três principais projetos de software: (i)

OpenStack Compute (Nova), que oferece serviços de computação virtual; (ii) OpenStack Object
Storage (Swift), para a implantação de uma infraestrutura de armazenamento de alta capacidade,
e; (iii) OpenStack Image Service (Glance), que provê suporte à catalogação e à gerência de
bibliotecas de imagens de discos virtuais. A Erro! Fonte de referência não encontrada. ilustra
o relacionamento entre esses projetos e sua utilização para a composição de uma plataforma de
serviços de nuvem.
25
Figura 12. Serviços da plataforma OpenStack.

2.3.1.1 OpenStack Compute (Nova)
OpenStack Compute, ou Nova (http://openstack.org/projects/compute/), implementa um

serviço de computação virtual, incluindo a criação, iniciação e gerência de instâncias de
máquinas virtuais, o gerenciamento da infraestrutura de rede e o controle de acesso de usuários
aos recursos da nuvem. Seu desenvolvimento teve como base o serviço Nebula, desenvolvido
pela NASA. É semelhante em escopo ao serviço EC2 da Amazon e expõe suas funcionalidades
para usuários através de uma interface de controle e para aplicações através de suas APIs.
Instâncias executáveis de máquinas virtuais (denominadas servidores) podem ser criadas
a partir de diferentes formatos de imagens, dentre eles o AMI (Amazon Image Format), adotado
na nuvem da Amazon, e o OVF (Open Virtualization Format), um padrão aberto, criado por um
conjunto de empresas de virtualização, liderado pela VMWare. Diferentes hipervisores podem ser
utilizados para a execução de servidores nos nós de computação, incluindo Xen, KVM e
VMWare. Diferentes tipos de configuração de hardware (denominados flavors) podem ser
escolhidos para a criação de um servidor; cada um desses tipos define uma combinação
específica de recursos como espaço em disco e tamanho de memória. Um serviço Nova permite
26
comandar a reinicialização (reboot) e o redimensionamento (resize) de um servidor. Através

dessa última facilidade é possível converter um servidor existente para uma nova configuração
(flavor), com maior ou menor capacidade de recursos.
O OpenStack permite a associação de recursos não apenas a usuários específicos, mas
também a projetos. Um projeto OpenStack é composto por um conjunto específico de usuários,
volumes, instâncias e imagens, além de uma VLAN particular. Um melhor controle do uso de
recursos é possível, pois se pode associar a um projeto multiusuário – ao invés de a cada usuário
individual – limites para a utilização de recursos da nuvem, como o número e tamanho dos
volumes utilizados e o número de instâncias iniciadas. Um mesmo usuário pode participar de
vários projetos, além de poder manter um projeto exclusivo (um projeto com identificador igual
ao do usuário).
2.3.1.2 OpenStack Object Storage (Swift)
OpenStack Object Storage, ou Swift (http://openstack.org/projects/storage/), implementa

um serviço de armazenamento de dados redundante e escalável, baseado em clusters de
servidores. Seu desenvolvimento tem como base a plataforma Cloud Files da Rackspace, cujo
código foi aberto e cedido ao projeto OpenStack. Seu modelo de armazenamento de longo termo
é adequado a dados razoavelmente estáticos e permanentes como imagens de máquinas virtuais,
repositórios de e-mails, vídeos e fotos de alta resolução, e arquivamento de backups.
O OpenStack Object Storage é similar, em escopo, ao serviço de armazenamento Amazon
S3 e utiliza conceitos semelhantes, como container e objeto. Containers representam
compartimentos de armazenamento, e permitem a organização dos dados, enquanto objetos são a
entidade básica do serviço, e são compostos por dados e seus metadados. O maior tamanho
permitido para a carga (upload) de um objeto é de 5GB; contudo, objetos maiores que 5GB
podem ser segmentados para carga e posteriormente concatenados, formando um único objeto,
que pode ser recuperado em apenas uma operação.
O serviço Object Storage usa uma arquitetura distribuída, sem um ponto central de
controle, para prover maior escabilidade e redundância. Objetos são replicados em múltiplos nós,
sendo o serviço responsável por essa replicação e por garantir a integridade dos dados através do
cluster. No caso de falha de um nó, o serviço refaz seu conteúdo em outro nó ativo.
2.3.1.3 OpenStack Image Service (Glance)
OpenStack Image Service, ou Glance, (http://www.openstack.org/projects/image-service/)

provê serviços de descoberta, registro e recuperação de imagens de discos virtuais, que podem
estar armazenadas em diversos tipos de repositórios back-end, como um serviço OpenStack
Object Storage, um serviço Amazon S3, ou mesmo um sistema de arquivos local.
Imagens públicas ou privadas (acessíveis por um grupo específico de usuários), de
diferentes formatos, podem ser catalogadas nesse serviço. Atualmente é oferecido suporte aos
27
seguintes formatos de imagens: raw, AMI, VHD (Hyper-V), VDI (VirtualBox), qcow2
(Qemu/KVM), VMDK (VMWare) e OVF (Open Virtualization Format). Entre os planos para o
futuro do serviço é prevista a possibilidade de conversão entre diferentes formatos de imagens de
máquinas virtuais.
2.3.2.1 OpenStack Compute
A interação com o serviço OpenStack Compute pode ser feita de duas formas: através da
API nativa OpenStack e através da Amazon EC2 API, especificada pela Amazon para seu serviço
de computação virtual. O suporte à Amazon EC2 API permite a execução de aplicações nas duas
infraestruturas de nuvem, e também facilita a migração de aplicações da nuvem da Amazon para
uma nuvem baseada no OpenStack.
A API nativa OpenStack é oferecida como serviços HTTP REST, descritos no documento
OpenStack Compute Developer Guide, disponível no endereço
http://docs.openstack.org/api/openstack-compute/1.1/os-compute-devguide-1.1.pdf. Todas as
requisições HTTP ao OpenStack Compute devem incluir credenciais de autenticação, e
implementações específicas desse serviço podem prover suporte a diversos esquemas de
autenticação, como OAuth, Basic Auth e Token. Alguns desses esquemas podem requerer o uso
de SSL sobre HTTP (HTTPS).
As requisições e respostas das operações definidas pela API podem utilizar formatos
JSON ou XML. O formato de uma requisição é especificado no cabeçalho Content‐Type,
obrigatório para requisições que contenham um corpo (request body). O formato das respostas
pode ser especificado na requisição correspondente, através do cabeçalho Accept ou
adicionando-se uma extensão .xml ou .json à sua URI.
Quatro grupos de operações são oferecidos pela API: Server Actions, Flavors, Images e
Metadata. O grupo Server Actions contém operações para a criação e remoção de servidores
(instâncias), para obtenção dos detalhes de um servidor (imagem, flavor, metadados, endereço
IP), para a atualização dos atributos de um servidor (nome, metadados e endereço IP), para
comandar a reinicialização (reboot) e redimensionamento (resize) de um servidor, para a criação
de uma nova imagem a partir de uma determinada instância, e para obtenção da lista de
servidores disponíveis ao usuário. O grupo Flavors permite obter a lista de configurações
(flavors) disponíveis e os detalhes de uma configuração específica. O grupo Images permite obter
a lista de imagens disponíveis ao usuário e os detalhes de uma imagem específica, como nome,
datas de criação e modificação, requisitos de disco e memória, e também comandar a remoção de
uma imagem do sistema. Finalmente, o grupo Metadata permite listar e alterar os metadados
associados a um determinado servidor ou imagem.
A Figura 13 apresenta um exemplo de operação solicitada ao serviço OpenStack Compute
através de sua API nativa. Tal operação consiste na requisição para a criação de um novo servidor
28
(instância), com formato XML. Esse exemplo ilustra também a possibilidade de customização de
um servidor no momento de sua criação, através da injeção de arquivos de dados em seu sistema
de arquivos (personality files).
Figura 13. Exemplo de operação com o OpenStack Compute.
Para facilitar o acesso ao serviço OpenStack Compute foi especificada uma arquitetura
independente de plataforma e linguagem que serve como base para a construção de bindings da
API REST para diversas linguagens de programação de alto nível. Essa arquitetura é definida no
documento API Language Binding Guide (disponível no endereço
http://docs.rackspace.com/servers/api/v1.0/cs-bindguide-20090916.pdf) e consiste de um
conjunto de interfaces abstratas especificadas na linguagem IDL (Interface Description
Language), definida pelo OMG (Object Management Group). São especificados pelo OMG
mapeamentos de IDL para diversas linguagens de programação como Java, Ruby, Python, and
C++. Diversos bindings para a API do serviço OpenStack Compute baseados nesses
mapeamentos são disponíveis. Alguns desses bindings, disponibilizados como open source,
podem ser obtidos através do repositório público GitHub (https://github.com/rackspace/).
A Figura 14 apresenta a definição de uma interface abstrata, EntityManager, que

contém operações comuns a todos os gerenciadores de entidades do OpenStackCompute, como,
por exemplo, os gerenciadores de servidores e de imagens. As operações do grupo CRUD
(Create, Read, Update e Delete) permitem a criação, obtenção de informações e conteúdo,
atualização e remoção de entidades OpenStackCompute, e correspondem a operações POST,
GET, PUT e DELETE do protocolo HTTP. Como todas essas operações são assíncronas, as
operações do grupo Polling permitem a obtenção do status de operações CRUD pendentes.
29
Operações wait bloqueiam o cliente até o final de uma operação CRUD pendente sobre a
entidade especificada; operações notify permitem o registro de uma função (ChangeListener) que
receberá uma notificação quando o estado da entidade especificada for alterado. Finalmente, as
operações do grupo Lists criam coleções de entidades de um determinado tipo, simplificando
futuras interações com o serviço para a monitoração de um grupo de entidades específico.
Figura 14. Definição da interface EntityManager para operação com o OpenStack Compute.
A Figura 15 mostra a utilização de operações definidas pela interface abstrata

EntityManager com o uso de um binding para a linguagem Java. O trecho de código exibido
requisita a criação de um novo servidor (operação create), e aguarda a finalização dessa criação
através da operação wait.
30
Figura 15. Operações envolvendo a interface EntityManager com binding para Java.
2.3.2.2 OpenStack Object Storage
A API do serviço OpenStack Object Storage também é implementada como um conjunto

de serviços REST, descritos no documento OpenStack Object Storage Developer Guide,
disponível no endereço http://docs.openstack.org/api/openstack-object-storage/1.0/os-
objectstorage-devguide-1.0.pdf. Todas as requisições REST ao OpenStack Object Storage devem
incluir um cabeçalho de autorização ou token (X‐Auth‐Token). Clientes da API devem fornecer
ao serviço de Autenticação um username válido e sua chave de acesso, para obter esse token,e
também as URIs do OpenStack Object Storage. As requisições de autenticação e de operações do
OpenStack Object Storage devem utilizar HTTPS.
Três grupos de serviços são oferecidos pelo OpenStack Object Storage: (i)Storage
Account Services, (ii) Storage Container Services e (iii) Storage Object Services. As operações
do primeiro serviço permitem obter informações sobre os containers associados ao usuário. O
segundo grupo oferece operações para a criação e remoção de containers, para a obtenção dos
metadados de um container e para a obtenção da lista de objetos armazenados em um container
específico. O último grupo oferece operações para a recuperação dos dados (ou parte deles) de
um objeto, para a criação e atualização de um objeto (dados e metadados), para a cópia de objetos
(no mesmo container ou em outro container) e para a remoção de objetos.
A Figura 16 apresenta um exemplo de requisição para a obtenção da lista de objetos
armazenados em um container e a resposta obtida, em formato XML.
31
Figura 16. Exemplo de requisição e resposta em operação com o OpenStack Object Storage.
Além da API REST, uma série de bindings para diversas linguagens de programação
podem ser utilizados para simplificar a integração do acesso ao OpenStack Object Storage a
aplicações desenvolvidas nessas linguagens. Esses bindings proveem uma camada de abstração
sobre a API REST nativa, permitindo aos desenvolvedores das aplicações trabalhar com modelos
de containers e objetos ao invés de trabalhar diretamente com requisições e respostas HTTP.
Esses bindings são disponibilizados com licenças MIT a partir do repositório GitHub
(http://github.com/rackspace). São disponíveis atualmente bindings para PHP, Python, Java,
C#/.NET e Ruby.
A Figura 17 mostra a obtenção da lista de objetos armazenados em um container com o
uso do binding da API para a linguagem Java.
32
Figura 17. Obtenção da lista de objetos armazenados em um container no OpenStack Object

Storage com o uso de binding da API para a linguagem Java.
2.3.2.3 OpenStack Image Service
A interação básica com o OpenStack Image Service também se dá através de uma

interface REST, descrita no documento OpenStack Image Service Developer Guide, disponível
no endereço http://docs.openstack.org/api/openstack-image-service/1.0/os-image-service-
devguide-1.0.pdf. As operações disponibilizadas pela interface do OpenStack Image Service
permitem: a obtenção de informações sobre as imagens públicas catalogadas no servidor Glance
acessado, a adição de uma nova imagem de máquina virtual (pública ou privada), a recuperação
do conteúdo de uma imagem de máquina virtual, a atualização dos metadados de uma imagem, e
a obtenção e atualização da lista de usuários associados a uma imagem privada. Como discutimos
anteriormente, as imagens catalogadas nesse serviço podem ser armazenadas em diversos tipos de
repositórios back-end, como um serviço OpenStack Object Storage, um serviço Amazon S3, ou
mesmo um sistema de arquivos local.
Para obter, por exemplo, informações detalhadas (metadados) das imagens de máquinas
virtuais públicas catalogadas em um servidor Glance executando na URL
http://glance.example.com, uma requisição GET deverá ser enviada para
http://glance.example.com/images/detail. A Figura 18 apresenta um exemplo de
resposta a essa requisição, em formato JSON.
33
Figura 18. Exemplo de resposta JSON em operação com o OpenStack Image Service.
Além do acesso direto à API REST, um cliente do serviço OpenStack Image Service pode
utilizar uma classe Python distribuída em conjunto com o código desse serviço para acessar suas
operações. Assumindo que existe um servidor Glance executando no endereço
glance.example.com, na porta 9292, a mesma requisição descrita acima poderia ser feita com
base na classe cliente como mostrado na Figura 19.
Figura 19. Exemplo de requisição em operação com o OpenStack Image Service.
2.4 Google App Engine (GAE)

O Google App Engine (https://appengine.google.com) (GAE) é classificado como um
serviço PaaS (Platform-as-a-Service) que prioriza o suporte a hospedagem de aplicações Web. A
virtualização e elasticidade claramente observadas em soluções IaaS, como os serviços AWS da
Amazon, são praticamente imperceptíveis no GAE. Isto ocorre porque todo o gerenciamento da
virtualização e elasticidade são feitos de forma automática pelo GAE, de acordo com o número
de requisições recebidas por uma aplicação. Assim, o GAE é recomendado para ser utilizado para
aplicações onde a semântica de invocação request-reply pode ser utilizada, como no caso de
aplicações Web.
34
Figura 20. Página inicial do Google App Engine (GAE) – http://code.google.com/intl/pt-BR/appengine/
O GAE é formado por três elementos principais: (i) ambiente de execução, (ii) datastore,
e (iii) serviços escalaveis. O primeiro deles, o ambiente de execução, determina o ciclo de
execução de uma aplicação implantada no GAE. Assim, quando o ambiente de execução recebe
uma requisição HTTP (HyperText Transfer Protocol), o primeiro passo é identificar a aplicação
alvo daquela requisição através do nome de domínio. De posse do nome da aplicação requisitada,
o ambiente de execução seleciona um servidor para atender tal requisição com base em dados de
uso de CPU, memória, etc. Depois de selecionar um servidor, a aplicação alvo é iniciada no
servidor escolhido e recebe a requisição HTTP encaminhada inicialmente. Finalmente, a
aplicação trata a requisição, retorna uma resposta para o cliente e é finalizada. Essa sequência de
passos faz com que uma aplicação implantada no GAE tenha seu tempo de existência limitado à
duração de um processamento de requisição. Este curto tempo de vida de uma aplicação faz com
que não seja possível manter estado entre requisições, o que permite distribuir o tráfego de
requisições entre vários servidores.
Como várias aplicações podem estar executando em um mesmo servidor, o ambiente de
execução utiliza o conceito de sandbox para restringir os recursos utilizados por cada aplicação.
O sandbox restringe a utilização dos seguintes recursos:
 gravar no sistema de arquivos – as aplicações devem utilizar o armazenamento de
dados do GAE para armazenar dados persistentes;
 abrir um socket ou acessar diretamente outro host;
35
 gerar um subprocesso ou thread – uma solicitação da Web a uma aplicação deve

ser manipulada em um único processo dentro de no máximo 30 segundos; os
processos que ultrapassarem este tempo são encerrados;
 fazer outros tipos de chamadas de sistema.
O GAE fornece ambiente de execução para aplicações escritas nas linguagens de

programação Java e Python. Apesar de o presente relatório ilustrar a utilização de alguns serviços
do GAE utilizando a linguagem Java, ambas as linguagens usam o mesmo modelo de execução
onde um sandbox controla o acesso aos recursos do sistema. Qualquer tentativa de utilizar
construções de linguagem ou bibliotecas que violem as restrições do sandbox falhará com o
retorno de uma exceção.
Talvez o recurso mais importante que o GAE ofereça é seu serviço de armazenamento de
dados, o datastore. Com sua infraestrutura gigantesca – a mesma do engine (motor) de busca da
Google –, seu sistema de banco de dados BigTable e seu sistema de arquivos Google File
System, o GAE proporciona um armazenamento dimensionável e robusto, com mecanismos de
consulta e transações atômicas. Esse serviço de persistência utiliza uma arquitetura distribuída.
Os dados podem ser distribuídos nessa estrutura de forma otimizada, bastando para isso descrever
o relacionamento entre os objetos de dados (entidades) e definindo índices para as consultas. O
GAE para Java inclui suporte para duas interfaces para bancos de dados, (i) JDO (Java Data
Objects) e (ii) JPA (Java Persistence API).
2.4.1 Serviços escaláveis

2.4.1.1 Memcache
O serviço de Memcache é utilizado para acelerar consultas comuns no armazenamento de

dados. Por exemplo, se muitas solicitações fizerem a mesma consulta com os mesmos parâmetros
e não for necessário exibir imediatamente no site as alterações nos resultados, a aplicação poderá
armazenar os resultados em cache no Memcache. As solicitações subsequentes podem consultar o
cache de memória e executar a consulta no armazenamento de dados apenas se não houver
resultados ou se eles tiverem expirado. Dados da sessão, preferências do usuário e quaisquer
outras consultas executadas na maioria das páginas de um site são boas candidatas para o
armazenamento em cache.
2.4.1.2 URL Fetch
Devido às restrições do sandbox, as aplicações do GAE só podem se comunicar com

outras aplicações ou acessar outros recursos da Web através do serviço URL Fetch. Através desse
serviço, a aplicação faz uma requisição ao Google para que ele autorize a abertura de uma porta
na sua aplicação e assim ela interaja com outra aplicação Web ou serviço Web. O URL Fetch usa
a infraestrutura de rede do Google para proporcionar eficiência e escalabilidade.
36
Uma aplicação pode usar o serviço URL Fetch para emitir solicitações HTTP e HTTPS
(HyperText Transfer Protocol Secure) e receber respostas. Além disso, o serviço dispõe de
opções para personalizar requisições através da implementação de métodos da classe
FetchOptions como, por exemplo:
 allowTruncate – permite o truncamento de respostas muito grandes;
 doNotFollowRedirects – é chamado quando não se pretende permitir
redirecionamento de requisições;
 validateCertificate, se a requisição for do tipo HTTPS, esta opção permite
que seja validado o certificado SSL da aplicação requisitada.
2.4.1.3 Serviço de e-mail
As aplicações do GAE podem enviar mensagens de e-mail em nome dos administradores

da aplicação e em nome de usuários com contas do Google e podem receber e-mails em vários
endereços. As aplicações enviam mensagens usando o serviço de e-mail e recebem mensagens na
forma de solicitações HTTP iniciadas pelo GAE e postadas para a aplicação.
2.4.1.4 Serviço de mensagens instantâneas
Uma aplicação do GAE pode enviar e receber mensagens instantâneas para qualquer
serviço de mensagens instantâneas compatível com XMPP (eXtensible Messaging and Presence
Protocol), como o Google Talk. Uma aplicação pode enviar e receber mensagens de bate-papo,
enviar convites de bate-papo e solicitar informações de status. Mensagens XMPP de entrada são
processadas por manipuladores de solicitação, semelhantes a solicitações da Web.
Alguns usos possíveis de mensagens instantâneas incluem participantes de bate-papo
automatizados (“bots de bate-papo”), notificações instantâneas e interfaces de bate-papo para
serviços. Um cliente avançado com uma conexão a um servidor XMPP (como o Google Talk)
pode usar XMPP para interagir com uma aplicação do GAE em tempo real, inclusive para
receber mensagens iniciado pela aplicação. É importante observar que esse tipo de cliente usando
o Google Talk deve usar a senha do usuário para fazer uma conexão XMPP e não pode usar um
cookie das contas do Google.
Atualmente, uma aplicação não pode participar de bate-papos de grupo e só pode receber
mensagens dos tipos “bate-papo” e “normal”, podendo enviar mensagens de qualquer tipo
definido na RFC 39216.

O GAE disponibiliza um plug-in para o IDE Eclipse. Caso não se esteja usando o IDE
Eclipse ou não se deseje utilizar o plug-in do Google, é possível fazer o download do Google App
6
RFC 3921 – Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence –
http://www.ietf.org/rfc/rfc3921.txt
37
Engine SDK Java como um arquivo compactado na página de downloads do GAE, no endereço
http://code.google.com/appengine/downloads.html.
Aplicações Web Java para o GAE utilizam servlets Java, interface padrão para interagir
com o servidor de aplicações. Uma aplicação consiste em uma ou mais classes que estende uma
classe base servlet, e esses servlets são mapeados para URLs usando um arquivo de configuração
padrão chamado descritor de implantação. Quando o GAE recebe uma solicitação para uma
aplicação Java, ele determina qual classe de servlet utilizar baseado na URL e no descritor de
implantação; depois de localizar a classe, a mesma é instanciada, sendo invocado o método
apropriado do servlet.
Todos os arquivos para uma aplicação Java, incluindo as classes Java compiladas,
arquivos de configuração e arquivos estáticos, são organizados em uma estrutura de diretório
padrão WAR (Web application ARchive), de modo que tudo que tiver no diretório WAR fica
implantado no GAE. A Figura 21 mostra um exemplo de uma estrutura de um novo projeto Java
no Eclipse.
Figura 21. Estrutura de um projeto Java no Eclipse com o GAE.
2.4.2.1 Exemplo de um simples Java servlet
Como mostrado na Figura 22, a classe servlet estende a

classejavax.servlet.http.HttpServlet e sobrescreve os métodos para cada um dos
métodos HTTP que pretende suportar. O método doGet que é sobrescrito é chamado pelo
servidor com os parâmetros do tipo HttpServletRequest e HttpServletResponse, o
primeiro contendo informações sobre o pedido (requisição), como URL, parâmetros de
38
formulário e cookies, e o segundo servindo como resposta, enviada pelo GAE ao término da
execução desse método.
Figura 22. Exemplo de servlet para obtenção de data/hora.
Para informar ao GAE para invocar este servlet para solicitações, é necessário um
descritor de implantação, o arquivo war/WEB‐INF/web.xml, que deverá ser editado semelhante
ao exemplo mostrado na Figura 23. Esse arquivo web.xml faz o mapeamento de todas as URLs
para ClockServlet.
Figura 23. Conteúdo do descritor de implantação web.xml.
O GAE ainda precisa de um arquivo de configuração adicional que não é parte do padrão
servlet, war/WEB‐INF/appengine‐web.xml, sendo atribuído a esse arquivo conteúdo
semelhante ao exemplo mostrado na Figura 24. Nesse exemplo, o arquivo de configuração
informa ao GAE que esta é a versão 1 de uma aplicação chamada clock. É possível também
utilizar esse arquivo de configuração para controlar outros comportamentos, tais como arquivos
estáticos e sessões.
39
Figura 24. Conteúdo do arquivo appengine‐web.xml.
O WAR para o aplicativo deve incluir vários JARs (Java ARchives) do Google App
Engine SDK, o Java EE implementation JARs e a App Engine API JAR, instalados pelo plug-in
Eclipse no WAR automaticamente. Se o plug-in Eclipse não estiver sendo utilizado, esses JARs
devem ser copiados manualmente dos subdiretórios lib/user/ e lib/shared/ para o diretório
war/WEB‐INF/lib/no projeto.
2.4.3.1 Memcache
O serviço Memcache implementa a interface Java JCache, presente no pacote

javax.cache.*. A Figura 25 apresenta um trecho de código Java para obter um identificador
para a implementação do cache. Através das chamadas aos métodos getInstance e
getCacheFactory obtém-se o identificador para a instância CacheFactory e depois é criado
um cache através da passagem de um objeto Map vazio para o método createCache. Para inserir
um valor, é invocado o método put da classe javax.cache.Cache, passando como parâmetro
uma tupla chave/valor; de maneira similar, para recuperar um valor a partir de uma chave, deve
ser invocado o método get dessa mesma classe.
Figura 25. Trecho de código Java para obtenção de identificador para implementação do cache.
40
2.4.3.2 URL Fetch
Uma maneira simples de obter o conteúdo de uma página em um URL é criar um objeto
java.net.URL e, em seguida, chamar seu método openStream. Esse método lida com os
detalhes de criação da conexão, emissão de uma solicitação HTTP GET e recuperação dos dados
da resposta, como no trecho de código mostrado na Figura 26, no qual é feita uma requisição
básica. Na linha 8 é instanciado um objeto para guardar a URL, no caso a pagina padrão da
Google; logo após é aberta uma conexão para leitura de informações da pagina, conforme pode
ser observado na linha9, e, em seguida, a informação é exibida (no caso a própria pagina da
Google).
Figura 26. Exemplo de servlet utilizando o serviço URL Fetch.
Na linha 19 é iniciado um objeto do tipo URLFetchService através da classe

URLFetchServiceFactory. Logo em seguida, na linha 20, tem-se uma instância da classe
FetchOptions, através da qual se configuram restrições ou outras opções para a requisição. Ao
configurar estes objetos, todos eles são passados como parâmetro para o objeto HTTPRequest na
41
linha 22 e por fim, na linha 23,écapturada a resposta através do objeto URLFetchService.

Finalmente, a resposta é fornecida através do HTTPResponse, que irá conter a resposta em forma
de array de bytes, bastando então manipular o resultado da requisição confirme necessário.
2.4.3.3 Serviço de e-mail
Para enviar uma mensagem de e-mail é chamada a API de serviço de e-mail, através da
interface javax.mail.JavaMail em Java. A mensagem de saída tem um endereço de remetente
(From), um ou mais destinatários (To, Cc, ou Bcc), um assunto (email_subject), o corpo da
mensagem (email_body) e arquivos anexados, se necessário. Para utilizar a interface
JavaMail, primeiro é criada uma sessão, que normalmente contém informações necessárias para
se conectar a um servidor de correio eletrônico; no entanto, no GAE, nenhuma configuração é
necessária. Assim, pode-se preparar a mensagem como um objeto MimeMessage e, em seguida,
enviá-la usando o método estático send da classe Transport, que utiliza a sessão recentemente
criada para enviar a mensagem.
Um exemplo de servlet para o envio de e-mails é mostrado na Figura 27. Como mostrado,
são chamados os métodos da classe MimeMessage, setFrom para especificar o remetente,
addRecipient para especificar o(s) destinatário(s), setSubject para especificar o assunto, e
setText para especificar o corpo da mensagem.
42
Figura 27. Exemplo de servlet para envio de e-mails utilizando o serviço de e-mail do GAE.
Uma vez que a aplicação é implantada no GAE, qualquer pessoa pode enviar um e-mail
para <someid>@<appid>.appspotmail.com, onde <someid> é qualquer identificador de
usuário e <appid> é o identificador da aplicação. No arquivo appengine‐web.xml é necessário
incluir os elementos
<inbound‐services>
<service>mail</service>
</inbound‐services>
para ativar o serviço de e-mail. Em Java, pode-se mapear o caminho de entrada de e-mail para um
servlet com uma entrada no descritor de implantação web.xml, como mostra a Figura 28.
43
Figura 28. Mapeamento de caminho de entrada de e-mail para Java servlet no arquivo web.xml.
A Figura 29 mostra um exemplo de servlet para recebimento de e-mails. Se a mensagem

recebida é uma mensagem MIME multipart (uma mensagem com um corpo HTML ou anexos), o
método getContent da classe MimeMessage retorna um objeto que implementa a interface
Multipart. Pode-se usar essa interface para obter uma contagem das partes (getCount) e
selecionar as partes pelo índice (getBodyPart).
44
Figura 29. Exemplo de servlet para o recebimento de e-mails.

45
2.4.3.4 Serviço de mensagens instantâneas
Para enviar mensagens instantâneas, uma aplicação pode fornecer como corpo da
mensagem um texto simples que é exibido para o usuário ou pode fornecer um bloco XML
incluído nos dados XML de XMPP. O trecho de código mostrado na Figura 30 testa a
disponibilidade de um usuário e, em seguida, envia uma mensagem de bate-papo.
Figura 30. Trecho de código para envio de uma mensagem instantânea via GAE.
2.4.3.5 Acesso a estatísticas do banco de dados via código-fonte
O ambiente de gerenciamento do GAE, conhecido como dashboard, fornece uma

interface interativa com algumas características e estatística da aplicação implantada. No entanto,
há como capturar métricas estatísticas diretamente do datastore via código-fonte, dentre as quais
podem ser citadas quantas entidades existem por tipo ou ainda quanto de espaço é ocupado por
entidades de certo tipo de dado. Isso pode ser feito usando a classe DatastoreService, como
mostrado no trecho de código apresentado na Figura 31.
Figura 31. Obtenção de estatísticas de aplicação implantada no GAE a partir do dashboard.
Na linha 1 obtém-se uma instancia da classe DatastoreService através da invocação

do método getDatastoreService fornecido pela classe DatastoreServiceFactory, objeto
esse que fornecerá o acesso ao sistema de datastore. Feito isso, na linha 2, é realizada uma
consulta que retorna uma entidade Entity com dados estatísticos e, a partir daí, pode-se obter
informações como o total de bytes ocupados (linha 3), o total de entidades, etc.
2.4.3.6 Monitoramento de status de capacidade
O GAE permite monitorar, em tempo real, o status das partes da aplicação, seja servidor
de e-mail, bando de dados, imagens, etc., o que pode ser feito a partir da API de capabilities
46
(com.google.appengine.api.capabilities).Por exemplo, como mostrado na Figura 32,

para saber como está o status de funcionamento do banco de dados, basta fazer uso do método
getStatus, que pode retornar enabled (habilitado), disabled (desabilitado), scheduled
maintenance (em manutenção, agendada) ou unknown (desconhecido). Pode-se ainda obter desta
mesma forma (linha 2) informações de estado sobre outros serviços, como: memcache, e-mail,
etc.
Figura 32. Obtenção do status de funcionamento de partes de aplicação implantada no GAE.
2.4.3.8 Monitoramento de quota de serviços
O ambiente de administração do GAE dispõe também de um serviço para monitorar

quantitativamente questões de requisição, quantidade de processamento da aplicação em certas
atividades, etc. Para a linguagem Java, ainda não foi implementado muitas funcionalidades para
ter acesso a essas estatísticas por meio de uma API. Apesar disto, é possível obter alguns dados
acerca de estatísticas de CPU através da classe QuotaService. Por meio desta classe, pode-se
mensurar o processamento requerido por uma aplicação em um dado momento. Os principais
métodos desta API são:
 getCpuTimeInMegaCycles – captura o tempo de processamento de uma
requisição até aquele momento, sendo relativa ao processamento da aplicação
dentro do sandbox e proveniente do servidor em que a aplicação está naquele
instante; esse tempo é retornado em megaciclos7, unidade de tempo que equivale
1/1200 segundos de CPU;
 getApitimeInMegaCycles – captura o tempo de processamento de uma
requisição a uma API (mail, XMPP, Memcache, leitura em datastore e demais
APIs externas ao sandbox) até aquele instante;
 convertCpuSecondsToMegacycles – converte em megaciclos a quantidade de
processamento adquirida em segundos;
 convertCpuMegacyclesToSeconds – converte em segundos a quantidade de
processamento adquirida em megaciclos.
Um exemplo do comportamento dessas funções pode ser observado na Figura 33. Na
linha 1 instancia-se o objeto qs através da classe que o disponibiliza, QuotaServiceFactory.
Logo após na linha 3, é capturada a quantidade corrente de megaciclos gasta pelo processador
naquele momento. Depois de executar as instruções das linhas de 5 a 8, é capturado novamente o
processamento e é convertido o valor de megaciclos para segundos (linhas 11 e 12) e exibido no
browser tais valores (linhas 13 e 14).
7
É importante frisar que as métricas tanto em segundos como em megaciclos consideram um processador com
configuração 1.2 GHz 64-bit x86.
47
Figura 33. Trecho de código com chamadas a métodos para mensurar o processamento requerido
por uma aplicação no GAE em um dado momento.
Já para medir o tempo de processamento de uma requisição a uma chamada à API, basta
substituir nas linhas 3 e 10, na Figura 33, o método getCpuTimeInMegacycles pelo
getApitimeInMegaCycles. Dessa forma, obtém-se o tempo de processamento gasto numa
requisição a uma API externa até aquele instante.
O GAE possui uma ferramenta, chamada appstats, que consegue resgatar essas métricas
através do uso de um servlet, ou seja, todas as requisições na aplicação em questão são filtradas
por ele e disponibilizadas automaticamente na página de estatísticas. Para dispor deste serviço,
primeiramente precisa-se mapear o servlet (já implementado) no arquivo web.xml de sua
aplicação, acrescentando o trecho XML mostrado na Figura 34. Na tag filter é descrito qual o
nome do filtro (atributo filter‐name) bem como a classe que ele se encontra, que por padrão
écom.google.appengine.tools.appstats.AppstatsFilter. Logo depois é indicado qual
o nome do filtro e sua URL padrão e também configurado o servlet que filtrará os eventos da
aplicação (tag servlet‐mapping) e definidas as regras de acesso (tag security‐
constraint).
Figura 34. Mapeamento da appstats do GAE para Java servlet no arquivo web.xml.
48
2.4.3.9 Implantação de aplicações
O pacote com.google.appengine.tools contém as classes de suporte no

desenvolvimento de aplicações implantadas no GAE, podendo ser incorporado em IDEs e outros
utilitários de desenvolvimento para realizar testes e implantação de aplicativos no GAE. Já o
pacote com.google.appengine.tool.admin é destinado ao gerenciamento das aplicações
implantadas no GAE. Entre as classes deste pacote, destaca-se a classe AppAdmin. Esta classe é
uma interface de administração de aplicativos para o App Engine. Ela permite atualizar,
configurar e gerenciar um aplicativo implantado no App Engine.
2.5 Windows Azure Platform

O Windows Azure Platform (http://www.microsoft.com/windowsazure/) é a plataforma da
Microsoft que permite a criação e hospedagem de aplicações escalonáveis em seus servidores.
Atualmente várias empresas estão usando o Windows Azure, tais como NASA, Xerox, Boeing e
Telefonica.
Figura 35. Página inicial do Windows Azure Platform – http://www.microsoft.com/windowsazure/

49

O conjunto de serviços providos pelo Windows Azure contempla serviços hospedados nos
datacenters da Microsoft e que podem ser acessados pela Internet. O Windows Azure inclui uma
camada fundamental que serve de base para todos os serviços, bem como um conjunto de
serviços de desenvolvimento que podem ser utilizados individualmente ou de maneira conjunta.
A Figura 36 ilustra os produtos e componentes que são parte do Windows Azure.
Figura 36. Estrutura do Windows Azure e serviços que compõem a plataforma.
As subseções a seguir discorrem brevemente acerca dos principais serviços oferecidos

pelo Windows Azure. Outros detalhes podem ser encontrados no Windows Azure Library,
disponível no endereço http://msdn.microsoft.com/en-us/library/windowsazure/dd163896.aspx.
2.5.1.1 Windows Azure Compute
O Windows Azure Compute (http://www.microsoft.com/windowsazure/features/compute/)

provê aos desenvolvedores uma plataforma para hospedar e gerenciar aplicações nos datacenters
da Microsoft ao redor do mundo. Essas aplicações são construídas com base em um ou mais
componentes chamados roles, que podem ser de três tipos diferentes:
(i) Web – é executado em uma máquina virtual e é utilizado para hospedar front-ends
de aplicações Web utilizando o IIS (Internet Information Services) 7, permitindo a
criação de aplicações em ASP .NET, Java ou PHP;
(ii) Worker – também é executado em uma máquina virtual e em geral é utilizado para
prover as capacidades de processamento de uma aplicação Web hospedada
utilizando o Web role; esse role, junto com o Web role, permite aos
desenvolvedores implantar aplicações Web que possibilitem aos usuários
50
interagirem com as mesmas, através do Web role, e, em seguida, fazer com que as
tarefas a serem executadas sejam processadas pelo Worker role.
(iii) Virtual Machine (VM) – oferece máquinas virtuais em si, permitindo inclusive aos
usuários definirem configurações e atualizações de sistemas operacionais para as
mesmas; enquanto os Web e Worker roles são executados em máquinas virtuais, o
VM role é a própria máquina virtual que confere ao usuário controle total das
operações.
No Windows Azure Compute, tem-se também o conceito de instâncias, que representam

servidores Web virtuais, que variam com tipo de processador utilizado, quantidade de memória,
capacidade de armazenamento e memória cache.
O SLA do Windows Azure Compute garante disponibilidade de 99,9% das instâncias, de
modo que caso esse SLA não seja cumprido, é fornecido ao cliente um crédito de 10% sobre o
valor de cobrança caso a porcentagem do tempo de atividade mensal seja inferior a 99,9% e de
25% caso seja inferior a 99%.
2.5.1.2 Microsoft SQL Azure Database
O SQL Azure Database (http://www.microsoft.com/windowsazure/features/database/) é

um serviço de banco de dados relacional em nuvem escalável desenvolvido com base nas
tecnologias Microsoft SQL Server. O RDBMS (Relational DataBase Management System) do
SQL Azure Database permite aos desenvolvedores criar, acessar e manipular tabelas, visões
(views), índices, procedimentos armazenados (stored procedures), gatilhos (triggers) e funções
(functions), além de operações de consultas e junções, de maneira consideravelmente similar ao
que é feito com o Microsoft SQL Server.
Além dos serviços convencionais providos por banco de dados, outras funcionalidades
disponíveis são:
 Microsoft SQL Azure Reporting, que provê aos desenvolvedores estatísticas de
disponibilidade (do serviço on-line) e de desempenho dos bancos de dados por ele
gerenciados;
 Microsoft SQL Azure Data Sync, serviço de sincronização uni e bidirecional de dados
que permite que dados sejam facilmente compartilhados entre o Microsoft SQL Azure
Database e bancos de dados Microsoft SQL Server locais, bem como entre múltiplas
bases de dados implementadas no Microsoft SQL Azure Database, dentro do mesmo
ou de diferentes datacenters.
O SLA do SQL Azure Database garante disponibilidade mensal de 99,9%, de modo que
caso esse SLA não seja cumprido, também é fornecido ao cliente um crédito de 10% sobre o
valor de cobrança caso a porcentagem do tempo de atividade mensal seja inferior a 99,9% e de
25% caso seja inferior a 99%.
51
2.5.1.3 Windows Azure Virtual Machine (VM)
O Windows Azure Virtual Machine

(http://www.microsoft.com/windowsazure/features/virtualmachines/) permite aos
desenvolvedores implantar uma imagem personalizada (customizada) de um Windows Server
2008 R2 (edições Enterprise ou Standard) para o Windows Azure. O Windows Azure VM
funciona como uma imagem de disco rígido virtual (VHD – Virtual Hard Drive) de uma máquina
virtual Windows Server 2008 R2. Esse VHD é criado utilizando uma máquina local com
Windows Server e, em seguida, enviado para o Windows Azure; uma vez na nuvem, o VHD
pode ser carregado sob demanda em uma máquina virtual e emulado.
2.5.1.4 Windows Azure Storage
O Windows Azure Storage (http://www.microsoft.com/WindowsAzure/features/storage/)

provê diferentes tipos de serviços de armazenamento persistente na nuvem, a saber:
(i) BLObs (Binary Large Objects), para armazenamento de texto ou dados
binários;
(ii) Table Service, recomendado para grandes quantidades de dados que precisam
de uma estrutura adicional (informações sobre relacionamentos entre os dados
armazenados) ou dados que necessitam ser acessados através de consultas
(queries);
(iii) Queue Service, recomendado para mensagens persistentes entre instâncias de
Web e Workerroles.
Diferentemente do armazenamento local, BLOBs, tables e queues podem ser acessados
simultaneamente, de maneira escalável, por múltiplas aplicações ou instâncias de aplicações, sem
perda de desempenho.
O SLA do Windows Azure Storage garante disponibilidade de 99,9% dos serviços de
adição, leitura e exclusão de dados. De maneira similar ao Windows Azure Compute, caso esse
SLA não seja cumprido, é fornecido ao cliente um crédito de 10% sobre o valor de cobrança caso
a porcentagem do tempo de atividade mensal seja inferior a 99,9% e de 25% caso seja inferior a
99%. O SLA do Windows Azure Storage também especifica os tempos máximos de
processamento de transações desse serviço, conforme a Tabela 6.
Tabela 5. Tempos máximos de processamento especificados pelo SLA do Azure Storage.
Tipo de solicitação Tempo máximo de processamento
 PutBlob e GetBlob
Deve ser concluído dentro do tempo resultante da
(incluindo blocos e páginas)

multiplicação de 2 segundos pelo número de megabytes
Obter intervalos de blob de página transferidos no processamento da solicitação
válidos
52
 Copiar blob O processamento deve ser concluído em até 90 segundos
 PutBlockList

O processamento deve ser concluído em até 60 segundos
GetBlockList
 Consulta de tabela O processamento deve ser concluído ou retornar uma
 Listar operações continuação em até 10 segundos
 Operações de tabela de lote O processamento deve ser concluído em até 30 segundos
 Todas as operações de tabela de

uma única entidade

O processamento deve ser concluído em até 2 segundos
Todas as outras operações de blob
e mensagem
2.5.1.5 Windows Azure AppFabric Caching
O Windows Azure AppFabric Caching

(http://www.microsoft.com/windowsazure/features/caching/) provê cache distribuído em
memória para aplicações no Windows Azure. Os benefícios são os já conhecidos para a memória
cache local, como o acesso mais rápido aos objetos em cache em relação aos que estão na
memória. Assim, qualquer objeto pode ser colocado no cache, sem limite de tamanho ou custos
de serialização para o cache local, bem como sem a necessidade de qualquer instalação ou
gerenciamento de instâncias. Esse cache pode ter seu tamanho aumentado/reduzido conforme a
necessidade, i.e. de forma elástica.
2.5.1.6 Windows Azure AppFabric Service Bus
O Windows Azure AppFabric Service Bus

(http://www.microsoft.com/windowsazure/features/servicebus/) provê troca segura de mensagens
e conectividade. Isto permite a construção de aplicações em nuvem distribuídas e fracamente
acopladas, onde a comunicação entre módulos ou serviços é feita através de mensagens.
Aplicações híbridas, ambientes locais e de nuvem em interação, também podem fazer uso deste
serviço de mensagens e conectividade. Esse serviço possibilita o uso de vários protocolos e
padrões de comunicação e mensagem (e.g. SOAP, REST e serviços Web), além de políticas
publish/subscribe de mensagens.
2.5.1.7 Business Intelligence
Os serviços de reporting providos pelo Windows Azure permitem o desenvolvimento de

relatórios operacionais com o auxílio do Microsoft Azure Reporting
(http://www.microsoft.com/windowsazure/features/reporting/). Assim, os usuários podem acessar
os relatórios através de um portal de gerenciamento, monitoramento e logging, o Windows Azure
Management Portal. Estes relatórios podem ser desenvolvidos com ferramentas locais e depois
53
colocados na nuvem, como um esqueleto, que será preenchido com dados atuais, fornecendo uma
visão em tempo real da situação da empresa para gerentes e executivos.
Para oferecer suporte ao desenvolvimento de aplicações em nuvem utilizando os serviços

do Windows Azure, existem as ferramentas Windows Azure Tools for Microsoft Visual Studio,
que incluem o Windows Azure SDK, uma extensão para a IDE Microsoft Visual Studio [2010]
que permite a criação, configuração, depuração, execução e implantação de aplicações Web
escaláveis e serviços no Windows Azure. Com o Windows Azure SDK integrado ao Microsoft
Visual Studio, as aplicações (locais ou em nuvem) podem se conectar a bases de dados no SQL
Azure Database, as consultas e manipulações de dados das aplicações podendo ser feitas através
do próprio IDE.
Outro conjunto de ferramentas para o desenvolvimento de aplicações utilizando o
Windows Azure é o Windows Azure Tools for Eclipse, plug-ins para o IDE Eclipse que oferecem
aos desenvolvedores assistentes (wizards) e utilitários para o desenvolvimento, depuração,
configuração e implantação de aplicações escritas nas linguagens Java ou PHP no Windows
Azure. Especificamente para o IDE Eclipse e a linguagem Java, tem-se o Windows Azure Plugin
for Eclipse with Java, que pode ser facilmente integrado a esse IDE e, depois de instalado, criar
um Windows Azure Project.
Como ilustrado na Figura 36, essas ferramentas de desenvolvimento como extensões aos
IDEs Eclipse e Microsoft Visual Studio fazem parte do ambiente de desenvolvimento local, de
modo que os SDKs proveem ferramentas e recursos para implementar e testar localmente as
aplicações para depois implantá-las no ambiente de nuvem.
2.5.3 Exemplo de uso

Para executar uma aplicação no Windows Azure Platform, é preciso desenvolver a
aplicação localmente utilizando o IDE Microsoft Visual Studio 2010 com o SDK do Azure e
depois fazer a implantação (deploy) na nuvem utilizando o gerenciador Web do Azure
(http://windows.azure.com/).
Para este exemplo, foi feito o download de um código exemplo já pronto do site do
Microsoft Developer Network (MSDN), disponível no endereço
http://code.msdn.microsoft.com/Windows-Azure-HelloWorld-ee52983e. No site da Microsoft
não foi encontrada documentação apresentando as APIs dos serviços oferecidos pelo Windows
Azure que permitisse acessá-los programaticamente (i.e. via código fonte), como ocorre para as
demais plataformas de nuvem.
Primeiramente, cria-se um novo serviço pelo gerenciador Web do Windows Azure, como
mostra a Figura 37. Após descompactar o arquivo referente ao exemplo e criar o serviço
hospedado, os arquivos HelloWorld.cspkg e ServiceConfiguration.cscfg devem ser
54
selecionados para a implantação na nuvem, conforme a Figura 38. O arquivo

ServiceConfiguration.cscfg é o arquivo de configuração de serviço a ser implantado no
Windows Azure, cujo conteúdo é mostrado na Figura 39. A linha 9 desse arquivo declara que
apenas uma instância estará rodando a aplicação em questão, HelloWorld; para tornar o serviço
escalável, é preciso alterar este valor de acordo com a demanda.
Figura 37. Criação de Serviço Hospedado
Figura 38. Seleção de arquivos para implantação de serviço no Windows Azure.

55
Figura 39. Conteúdo do arquivo de configuração ServiceConfiguration.cspkg.
O arquivo que contém a página a ser mostrada é Default.aspx, cujo conteúdo é

mostrado na Figura 40. Essa página apenas mostra a mensagem “Hello World!” (linha 13), além
de um pequeno texto e três links (linhas 19 a 22).
Figura 40. Código ASP .NET da página a ser exibida.
Após fazer a implantação do serviço (o que, para o presente exemplo, demorou 10

minutos), é preciso colocá-lo em execução, o que é feito através do VIP de Permuta. Ao clicar
nesse botão, o serviço deixará o estado de Preparação e entrará no estado de Produção. Para o
exemplo em questão, essa mudança de estado do serviço demorou 15 minutos.
A Figura 41 mosta o exemplo em execução.
56
Figura 41. Página ASP .NET do exemplo em execução.
2.6 Discussão
Este capítulo apresentou uma análise de cinco plataformas de computação em nuvem
disponíveis no mercado. Seus principais serviços foram listados e as suas características mais
relevantes foram levantadas. Adicionalmente, foram apresentados exemplos simples de utilização
de alguns de seus serviços. Cada plataforma possui aspectos positivos e negativos. Além disso,
cada uma delas provê uma gama de serviços diferentes, podendo oferecer IaaS, PaaS e SaaS.
A plataforma de nuvem da Amazon oferece uma ampla gama de serviços, AWS (Amazon
Web Services), englobando transversalmente serviços que vão desde IaaS a PaaS e SaaS. Seus
serviços, como computação (Amazon EC2), armazenamento (Amazon S3) e banco de dados
(Amazon SimpleDB e Amazon RDS) estão bem documentados, o que facilita sua utilização.
Além disso, há um pacote de ferramentas para o IDE Eclipse, o que possibilita o
desenvolvimento de aplicações de maneira rápida e com fácil acesso à documentação da API
Java. Adicionalmente, um conjunto de ferramentas também é oferecido para o Microsoft Visual
Studio.
A plataforma Eucalyptus é uma implementação open source dos principais serviços AWS
(EC2 e S3), e compartilha a API desses serviços. Este compartilhamento de APIs provê uma
grande integração entre as duas plataformas, possibilitando uma fácil migração de aplicações de
uma plataforma para a outra, e o uso das ferramentas de desenvolvimento disponíveis para AWS.
Além disso, a disponibilização sem custos dos recursos da nuvem Eucalyptus Community Cloud
(ECC) é uma facilidade interessante para testes de aplicações desenvolvidas para ambas as
plataformas. Os serviços da plataforma Eucalyptus são atualmente utilizados como núcleo de
nuvens privadas e híbridas de diversas organizações e empresas como Puma, Fujitsu e o
Departamento de Agricultura dos Estados Unidos. Contudo, apenas serviços básicos de
computação virtual e armazenamento são oferecidos.
57
O OpenStack é uma plataforma de computação em nuvem que visa prover uma

infraestrutura (IaaS), oferecendo serviços de computação (Nova), armazenamento (Swift) e
gerenciamento de imagens virtuais (Glance). Além de oferecer uma API própria, a plataforma
OpenStack também oferece suporte (i.e. implementa) as APIs do Amazon EC2 e do Amazon S3.
Bindings da API OpenStack para diversas linguagens de programação, como Java, Python, Ruby
e C++ são disponíveis para download, simplificando o desenvolvimento de aplicações nessas
linguagens. O projeto OpenStack tem como objetivo principal o estabelecimento de um padrão
open source para a implementação de serviços básicos de nuvens públicas e privadas, e conta
com o apoio da NASA e de um número significativo de empresas. É uma alternativa, nesse nicho,
à plataforma Eucalyptus, e vem obtendo visibilidade e interesse crescentes. Todo o código desta
plataforma pode ser obtido no endereço https://github.com/openstack/.
A plataforma da Google, o GAE, oferece uma estrutura para a criação de aplicações Web,
que podem ser desenvolvidas utilizando as linguagems Java ou Python. Serviços de comunicação
como e-mail, mensagens instantâneas, URL Fetch, etc. são oferecidos para suportar a execução
dessas aplicações na nuvem. Elas podem ser desenvolvidas utilizando o plug-in do Google para o
Eclipse ou através do Google App Engine SDK. Entre os pontos positivos de se utilizar o GAE,
destaca-se a facilidade de implatação e gerenciamento das aplicações. Pelo fato de o GAE
implementar os conceitos de PaaS, seus usuários não precisam gerenciar instâncias de servidores,
definir parâmetros de escalonamento, etc. Todo este trabalho é feito de forma automática pelo
GAE, considerando para tal o número de requisições recebidas pela aplicação. Este nível de
abstração fornecido pelo GAE proporciona várias facilidades. Por exemplo, a implantação e o
monitoramento de uma aplicação podem ser especificados através de um arquivo XML, evitando
as complexas operações de instalação e instanciação de imagens. No entanto, as facilidades
fornecidas pelo GAE só são possíveis devido às severas restrições impostas pelo seu ambiente de
execução (sandbox). Estas restrições são o principal ponto negativo do GAE. De certa forma, elas
podem inviabilizar a migração de aplicações Web para o GAE uma vez que exigem o uso de
APIs especificas do GAE para implementar conceitos como controle de sessão e invocação por
meio de sockets. Em relação aos objetivos do presente projeto, o GAE fornece um bom conjunto
de APIs para implantação e monitoramento de aplicações, no entanto, pouco pode ser feito em
relação a adaptação, uma vez que poucos parâmetros do ambiente de execução podem ser
modificados.
A plataforma de Computação em Nuvem da Microsoft, Windows Azure Platform, possui
uma quantidade considerável de serviços. Um conjunto de ferramentas para o IDE Microsoft
Visual Studio é disponibilizado para o desenvolvimento de aplicações para esta plataforma,
aplicações essas que podem ser desenvolvidas nas linguagens Java, ASP .NET e PHP.
Uma análise dessas plataformas evidencia que cada plataforma é indicada para um uso
específico: algumas são melhores para armazenamento, como é o caso dos serviços AWS, outras
provêem melhores serviços de comunicação, como é o caso do Windows Azure e outras estão
mais focadas no desenvolvimento em si de aplicações a serem executadas na nuvem, como é o
58
caso do Google App Engine. Na escolha de uma plataforma de nuvem para execução de
aplicações ou provimento de serviços aos seus clientes, deve-se ponderar todas as características
citadas e também preço, disponibilidade, tolerância a falhas e conveniência dos serviços. A
Tabela 6 mostra um resumo das principais características das plataformas analisadas.
Tabela 6. Principais informações sobre as plataformas analisadas.
Google Windows
Serviços/ Amazon Web
Eucalyptus OpenStack App Azure
Plataformas Services
Engine Platform
Categorização IaaS, PaaS e IaaS, PaaS
IaaS IaaS PaaS
de serviços SaaS e SaaS
Azure
Processamento EC2 Cloud Controller Nova Não possui
Compute
Azure
Armazenamento Amazon S3 Walrus Swift Não possui
Storage
Amazon
Via serviço de Via serviço de Azure SQL
Banco de dados SimpleDB, Datastore
terceiros terceiros Database
Amazon RDS
Diversas
linguagens
Java, PHP,
(Java, Python,
Python, Ruby e Java, através do
C++, entre Java,
Suporte a .NET compartilhamento Java e
outras). API ASP .NET
linguagens (entretanto a da API Java do Python
compartilha a e PHP
API Java é a AWS
AWS API, além
mais completa)
de oferecer API
própria
Eclipse e
Eclipse e Ferramentas para Não possui
Integração com Microsoft
Microsoft AWS podem ser plug-in Eclipse
IDEs Visual
Visual Studio utilizadas específico
Studio
Possui uma
versão paga e
Uso comercial Pago uma versão Gratuito Pago Pago
gratuita (ECC)
porém limitada
59
3 Considerações finais
Este relatório apresentou cinco das plataformas de Computação em Nuvem atualmente
disponíveis na literatura, tendo-se discorrido acerca de suas principais características e serviços.
Para esses serviços, são apresentados exemplos de código-fonte, ilustrando assim o uso das APIs
dessas plataformas de Computação em Nuvem. Por fim, o relatório apresentou uma discussão
sobre aspectos positivos e negativos de cada uma dessas plataformas com o objetivo de se ter
subsídios para promover uma seleção dentre as mesmas para serem utilizadas no contexto do
Projeto AltoStratus.
Dentro do Projeto AltoStratus, a Equipe Técnica composta por pesquisadores da UFRN,
UFRJ e PUC-Rio é responsável pela Ação 2 – Especificação e Implementação de um Modelo de
Composição de Serviços Confiáveis para Ambiente de Computação em Nuvem. Para a execução
dessa ação, é necessário selecionar algumas plataformas de Computação em nuvem, de modo a
permitir a composição de serviços providos pelas mesmas. Desse modo, três das plataformas
descritas nesse relatório foram selecionadas:
(i) Amazon AWS – essa plataforma foi selecionada por oferecer uma ampla gama de
serviços, por oferecer um bom suporte ao desenvolvimento de aplicações em
nuvem através de sua API e infraestrutura de programação, através de plug-ins do
Eclipse, e ainda pelo fato de ser uma das plataformas pioneiras e mais difundidas.
(ii) Google App Engine – essa plataforma foi selecionada, pois além de oferecer um
bom suporte de desenvolvimento, provê serviços distintos (e talvez
complementares) aos serviços oferecidos pela plataforma AWS, cujo foco é em
serviços IaaS, enquanto o do Google App Engine é em serviços PaaS;
(iii) OpenStack – essa plataforma foi selecionada principalmente por ser open-source,
possibilitando maior flexibilidade de implementação e maior controle de
monitoramento dos serviços, uma vez que a plataforma será instalada em um
ambiente controlado do nosso laboratório. Além disso, uma plataforma open-
source possibilita o uso exaustivo da plataforma a um custo financeiro zero, o que
não acontece com as plataformas proprietárias. Embora existam outras opções de
plataformas OpenSource, como o Eucalyptus, o OpenStack vem obtendo
visibilidade e interesse crescentes, e foi escolhido recentemente para compor os
serviços de nuvem disponibilizados pelo Ubuntu, uma das principais distribuições
Linux.
Uma vez escolhidas as plataformas de Computação em Nuvem a serem utilizadas, os

próximos passos desse projeto são: (i) especificar de um serviço para a composição e gerência de
workflows com tolerância a falhas, serviço esse que será responsável por criar e gerenciar
workflows com o objetivo de compor serviços providos por diferentes plataformas de
Computação em Nuvem; (ii) implementar um protótipo desse serviço; (iii) escrever relatório
60
abordando a especificação e implementação do serviço supracitado, e; (iv) testar e escrever

relatório de testes do serviço implementado.
61
Referências
Armbrust, Michael et al. (2009). Above the clouds: A Berkley view of Cloud Computing.
Technical Report – Reliable Adaptive Distributed Systems Laboratory, University of California
at Berkley, USA, 2009.
Buyya, Rajkumar; Yeo, Chee Sin; Venugopal, Srikumar (2008) Market-oriented Cloud
Computing: Vision, hype and reality for delivering IT services as computing utilities. In: HPCC
2008 – 10th IEEE International Conference on High Performance Computing and
Communications, 2008, Dalian, China. Proceedings of… Washington, D.C, USA: IEEE
Computer Society, pp.5–13.
Verma, Dinesh (1999) Supporting Service Level Agreements on IP networks [s.l., s.n.] Macmillan
Technical Publishing.
Wang, Lizhe; Von Laszewski, Gregor; Kunze, Marcel; Tao, Jie (2010) Cloud Computing: A
perspective study. New Generation Computing 28(2), pp.137–146.
Zhang, Qi; Cheng, Li; Boutaba, Raouf (2010) Cloud Computing: State-of-the-art and research
challenges. Journal of Internet Services and Applications 1(1), pp.7–18.

AltoStratus Solucoes de Middleware para

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

AltoStratus Solucoes de Middleware para

Enviado por

Direitos autorais:

Formatos disponíveis

Programa CTIC – Rede Nacional de Ensino e Pesquisa

AltoStratus: Soluções de Middleware para Composição, Execução e

Entregável do Segundo Trimestre – WP2

Estudo e caracterização de plataformas de Computação em Nuvem

Frederico Araújo da Silva Lopes – UFRN

Embora as plataformas de Computação em Nuvem, de um modo geral, não exijam muito

2 Plataformas de Computação em Nuvem

2.1 Amazon Web Services (AWS)

Figura 1. Página principal do Amazon Web Services (AWS) – http://aws.amazon.com

2.1.1 Principais serviços

2.1.1.1 Amazon Elastic Compute Cloud (EC2)

Um dos principais serviços oferecidos no portfolio AWS é o Amazon EC2

Figura 2. Criação de diferentes instâncias a partir de uma AMI no Amazon EC2.

O SLA (Service Level Agreement)2 do Amazon EC2, disponível em

2.1.1.2 Amazon Simple Storage Service (S3)

Amazon S3 (http://aws.amazon.com/s3/) é um serviço que provê uma infraestrutura de

2.1.1.3 Amazon Relational Database Service (RDS)

Amazon RDS (http://aws.amazon.com/rds/) é um serviço PaaS que implementa um banco

2.1.1.4 Amazon SimpleDB

Amazon SimpleDB (http://aws.amazon.com/simpledb/) é um serviço que, como o próprio

2.1.1.5 Amazon Simple E-mail Service (SES)

Amazon SES (http://aws.amazon.com/ses/) é um serviço para envio de e-mails para

2.1.2 Ferramentas de apoio ao desenvolvimento

2.1.3 API e exemplos de uso

Tabela 1. Principais comandos do Amazon EC2 organizados por funções.

Funções Comandos (actions) Descrição

A Figura 3 apresenta um exemplo de manipulação do Amazon EC2. As linhas 5 e 6 criam

Figura 3. Trecho de exemplo de código Java utilizando a Amazon EC2 API.

2.1.3.2 Amazon Simple Storage Service (S3)

Tabela 2. Principais comandos do Amazon S3 organizados por tipos de operações.

Funções Comandos Descrição

A Figura 4 apresenta um exemplo de manipulação do Amazon S3 através da API Java

Figura 4. Trecho de exemplo de código Java utilizando a Amazon S3 API.

2.1.3.3 Amazon SimpleDB

Tabela 3. Comandos do Amazon SimpleDB.

A Figura 5 apresenta um exemplo de código fonte Java que manipula o serviço

A Figura 6 apresenta os métodos de inserção de um log e de listagem de logs de um

2.1.3.4 Amazon Simple E-mail Service (SES)

Tabela 4. Comandos do Amazon SES.

especificado pelo cliente, sendo bastante útil para o envio de

Figura 7. Trecho de exemplo de código Java utilizando a Amazon SES API.

Figura 8. Página inicial do Eucalyptus – http://www.eucalyptus.com

As principais características do Eucalyptus incluem:

 compatibilidade com o formato de imagens de máquina virtual adotado na nuvem da

2.2.1 Principais serviços

Figura 9. Componentes básicos do Eucalyptus.

Os componentes de serviço Eucalyptus são implementados como serviços Web

Figura 10. Esquema de infraestrutura Eucalyptus e seus componentes básicos de serviços.

Cloud Controller. Implementa o ponto de entrada na nuvem para usuários e

serviços de computação virtual e armazenamento de grandes volumes de dados. Todo o código

Figura 11. Página inicial do OpenStack – http://www.openstack.org/

No contexto do OpenStack são desenvolvidos três principais projetos de software: (i)

Figura 12. Serviços da plataforma OpenStack.

2.3.1 Principais serviços

OpenStack Compute, ou Nova (http://openstack.org/projects/compute/), implementa um

comandar a reinicialização (reboot) e o redimensionamento (resize) de um servidor. Através

2.3.1.2 OpenStack Object Storage (Swift)

OpenStack Object Storage, ou Swift (http://openstack.org/projects/storage/), implementa

2.3.1.3 OpenStack Image Service (Glance)

OpenStack Image Service, ou Glance, (http://www.openstack.org/projects/image-service/)

2.3.2 API e exemplos de uso

2.3.2.1 OpenStack Compute

Figura 13. Exemplo de operação com o OpenStack Compute.