Um exemplo de aplicação multi-tenancy com Hibernate Shards

Um exemplo de aplicação multi-tenancy com Hibernate Shards Anderson Fernando Custódio 1, Edson A. Oliveira Junior 2 Resumo. Com o avanço da computação em nuvem, pequenas e grandes empresas tem passado por mudanças no fornecimento de software ao seus clientes. Nesse modelo, o software passa a ser oferecido como serviço (SaaS). Uma forma de implementar SaaS é por meio do modelo arquitetural multitenancy, que permite compartilhar a instância de uma aplicação e banco de dados entre diversos clientes. Implementar multi-tenancy sem a ajuda de um framework pode se tornar uma tarefa difícil. Este artigo apresenta uma revisão bibliográfica para identificar o estado da arte de multi-tenancy e, no final, é apresentado o desenvolvimento de um exemplo de aplicação multi-tenancy utilizando o framework Hibernate Shards o qual diminui consideravelmente a complexidade da implementação e torna o desenvolvimento mais rápido e menos exaustivo. Palavras-chave: Computação em Nuvem, Hibernate Shards, Multi-tenancy, Software como Serviço. Abstract. With the advance of cloud computing, small and large companies have changed their software supply to their customers. In this model, the software is now offered as a service (SaaS). One way to implement SaaS is through the multi-tenancy architectural model, which allows one to share an application instance and database among several customers. Implementing multi-tenancy without the help of a framework can become a hard task. Thus, this paper presents a literature review to identify the state of the art of multitenancy and it is presented the development of an application example using the multi-tenancy framework Hibernate Shards. With this framework implementation complexity is significantly reduced, making development faster and less exhausting. Keywords: Cloud Computing, Hibernate Shards, Multi-tenancy, Software as a Service. 1 Aluno do curso de especialização em Desenvolvimento de Sistemas para Web Universidade Estadual de Maringá (UEM) - Av. Colombo, 5790 Bloco C56 Maringá PR Brasil afcustodioo@gmail.com 2 Departamento de Informática Universidade Estadual de Maringá (UEM) - Av. Colombo, 5790 Bloco C56 Maringá PR Brasil - edson@din.uem.br 1

1. Introdução Computação em nuvem ou cloud computing é um modelo que permite acessar recursos (rede, servidores, aplicações, etc.) [1] convenientemente. Esses recursos são fornecidos dinamicamente como serviço, podendo ser acessados por meio da Internet, utilizando um navegador e configurados de acordo com a necessidade do contratante. Diferentemente dos modelos cliente/servidor em que a aplicação é disponibilizada estaticamente como produto [2]. De acordo com o NIST (National Institute of Standards and Technology), cloud computing é classificada em três modelos de serviços: Software como Serviço (SaaS), Plataforma como Serviço (PaaS) e Infraestrutura como Serviço (IaaS) [1]. É no modelo de SaaS (Software as a Service) que é encontrada a abordagem organizacional multi-tenancy ou multi-inquilino. Algumas características de aplicações multi-tenancy são: compartilhamento de recursos de hardware, aplicação e banco de dados [3]. O modelo arquitetural multi-tenancy permite que uma instância da aplicação ou banco de dados, sendo executada em um servidor, possa ser compartilhada entre diversos inquilinos ou tenants, com a garantia de isolamento dos dados [4]. Alguns dos benefícios de um ambiente multi-tenancy são o compartilhamento de recursos e a diminuição de custos. Porém o desenvolvimento de uma aplicação multi-tenancy pode ser uma tarefa complexa e exaustiva sem o uso de algum framework. O objetivo deste artigo é mostrar de forma prática e objetiva, a implementação de uma estratégia multi-tenancy, utilizando a tecnologia Java e o framework Hibernate Shards. O uso desse framework diminui consideravelmente a complexidade do desenvolvimento multi-tenancy, principalmente no que tange ao armazenamento dos dados. 2

2. Revisão Bibliográfica 2.1 Cloud Computing Existem diversas definições para cloud computing. Neste artigo será utilizada a definição proposta pelo NIST [1]: computação em nuvem é um modelo que permite acesso configurável a recursos computacionais, fornecidos com o mínimo de esforço ou interação. Assim, o modelo de cloud computing é dividido em cinco principais características, três serviços e quatro modelos de implantação. Como o foco deste artigo é multi-tenancy serão abordadas as principais características e serviços da computação em nuvem utilizando a definição proposta pelo NIST. 2.1.1 Principais Características Alocação de recursos sob demanda: recursos podem ser adquiridos e configurados pelo consumidor conforme a sua necessidade. Assim, não é necessária a interação humana com cada provedor dos serviços que estão sendo disponibilizados. Amplo acesso a rede: os recursos são disponibilizados na rede e podem ser acessados por meio de diversos dispositivos tais como Smartphones e laptops. Pooling de recursos: em cloud computing os recursos físicos e virtuais são fornecidos sob um modelo multi-tenancy de acordo com a demanda do consumidor. Não há uma noção exata para o usuário de onde os recursos estão localizados, mas geralmente existe a possibilidade do usuário selecionar o local em um alto nível de abstração (país, estado ou datacenter). Elasticidade rápida: é a capacidade de aumentar ou reduzir recursos quando esses não estão sendo utilizados. Tudo feito de forma rápida e normalmente automática, gerando redução de custos para o cliente. Para o provedor dos serviços é muito conveniente, pois permite melhor utilização dos recursos do datacenter. Controle de serviços: sistemas de cloud computing controlam e otimizam automaticamente a utilização dos recursos. Assim, o contratante ou consumidor pode monitorar, controlar e ter acesso a relatórios e recursos de 3

logging. Isso permite maior transparência sobre os serviços disponibilizados e utilizados. 2.1.2 Modelos de Serviços Software como serviço (Software as a Service - SaaS): neste modelo, os sistemas são fornecidos para os usuários por meio da Internet e podem ser acessados geralmente usando um navegador Web. A aplicação e o banco de dados podem ser compartilhados entre os inquilinos, ficando transparente para o usuário final, pois o sistema deve garantir o isolamento dos dados, para que um tenant não acesse os dados de outro. No modelo SaaS o usuário não precisa adquirir licenças de software como acontece no modelo convencional, paga somente pelos recursos que utilizar [6]. Outra característica é que o usuário não controla a infraestrutura como: rede, servidores, sistemas operacionais, mas somente configurações limitadas e específicas do usuário, tais como o tema visual e idioma da aplicação [1, 5, 6]. Exemplos de SaaS são o CRM da Salesforce e o Google Docs [5, 6]. Plataforma como Serviço (Platform as a Service - PaaS): a PaaS fornece uma infraestrutura que permite o desenvolvimento e a execução de aplicações em nuvem [3]. Em tal infraestrutura o desenvolvedor tem um conjunto de ferramentas pré-definidas que são suportadas pela plataforma, tais como linguagem de programação e Sistema Gerenciador de Banco de Dados (SGBD) [1]. Assim como no SaaS, o usuário não tem controle sobre a infraestrutura subjacente. Além disso, o usuário está sujeito a aceitar imposições feitas pela plataforma quanto ao tipo de software que pode desenvolver e qual SGBD pode ser utilizado [6, 7]. Alguns exemplos de PaaS são o Google App Engine [8], Force.com Platform [9] e Windows Azure Platform [10]. Infraestrutura como serviço (Infrastructure as a Service - IaaS): esse modelo fornece toda a infraestrutura para a PaaS e SaaS. Nele o cliente pode controlar recursos como rede, armazenamento e sistema operacional [1]. Um benefício da IaaS é poder solicitar novos servidores virtuais conforme a necessidade, escalando a aplicação horizontalmente [11]. Isso proporciona 4

economia para o contratante, por não precisar adquirir hardware mais robusto, como acontece no modelo convencional de infraestrutura. Um exemplo de IaaS é o Amazon Elastic Cloud Computing (EC2) [5]. 2.2 Multi-Tenancy No modelo tradicional de distribuição de software, cada organização tem uma aplicação e um banco de dados sendo executados. Assim, os recursos podem ficar ociosos em grande parte do tempo e, em momentos de pico, podem se tornar insuficientes. Multi-tenancy é um modelo arquitetural que permite que uma instância da aplicação ou banco de dados, possa ser compartilhada entre diversos inquilinos [4]. O tenant é uma entidade organizacional que aluga uma aplicação multitenancy que é fornecida no modelo SaaS. Cada tenant pode ter vários usuários que são os stakeholders da organização [3]. Uma aplicação multi-tenancy deve garantir que os dados de um tenant não estejam visíveis para o outro. Mesmo estando em um ambiente com recursos compartilhados, cada tenant tem a impressão que está em uma aplicação com recursos dedicados. Esse modelo define níveis de maturidade para o isolamento ou compartilhamento para a arquitetura de software e dados. A seguir são descritas as principais abordagens multi-tenancy [12]: 2.2.1 Banco de dados separados (Separate database) Esse é o modelo mais simples. Nele a instância da aplicação é compartilhada entre os tenants, cada qual com seu próprio banco de dados. Isso traz um isolamento lógico entre os tenants, permitindo que suas informações fiquem separadas. A Figura 1 apresenta os bancos de dados isolados de cada tentant. 5

Figura 1. Um banco de dados distinto para cada tenant [12] A Figura 1 ilustra os tenants de uma aplicação, onde o nome do banco de dados é a palavra "Tenant" seguido do número da sua identificação. Ao cadastrar um tenant o número é incrementado e um novo banco de dados é criado. Ter um banco de dados para cada tenant pode facilitar a extensão do modelo de dados para atender às necessidades específicas do tenant. A restauração dos dados em caso de falha é mais fácil, pois as informações estão separadas em cada banco de dados. Porém, nessa abordagem, o custo de hardware é maior e o arquiteto deve estar atento às possíveis limitações do SGBD, quanto ao número máximo de bancos de dados suportados. 2.2.2 Esquemas Separados (Separate schema) Nessa abordagem existe somente um banco de dados. Ao cadastrar um novo tenant, é criado um novo esquema no banco de dados com um conjunto de entidades para o referido tenant. A Figura 2 apresenta os esquemas isolados de cada tenant compartilhando o mesmo banco de dados. Figura 2. Modelo de dedicação compartilhada com esquemas separados [12] 6

Nesse modelo é criado um esquema para cada tenant,, como é possível ver na Figura 2. Neste exemplo o nome do esquema corresponde à palavra "tenant" seguido do número da sua identificação. Ao cadastrar um tenant na aplicação, o número é incrementado e um novo esquema é criado no banco de dados. Assim como no modelo anterior, esse torna simples a extensão do modelo de dados e ainda permite um grau moderado da lógica de isolamento dos dados. Uma desvantagem é a dificuldade para recuperar os dados em caso de falha, pois a restauração completa do banco de dados vai sobrepor os dados de todos os tenants.. Isso exige uma estratégia de restauração de backups em casos de falhas. 2.2.3 Esquema Compartilhado (Partitioned data) Nesse e modelo existe somente um banco de dados e o esquema é compartilhado entre todos os tenants. Para isso cada entidade deve conter uma coluna que associe o registro ao tenant apropriado. A Figura 3 ilustra os tenants compartilhando o mesmo esquema do banco de dados. Figura 3. Modelo de dedicação compartilhada com esquemas compartilhados [4] No esquema compartilhado o isolamento dos dados é feito por meio de uma coluna no banco de dados que identifica o tenant. A Figura 3 ilustra esse 7

isolamento pela coluna "InquilinoID". Os números desta coluna são as identificações dos tenants da aplicação. Esse modelo tem o menor custo de hardware por permitir maior número de tenants por servidor. Deve ser tomado grande cuidado com a segurança para não permitir que os dados de um tenant se misturem com os de outro, em casos de erros inesperados. A restauração de backup em caso de falhas é similar ao do modelo anterior, devendo ser desenvolvida uma estratégia para recuperação dos dados. 2.3 Hibernate Shards O Hibernate Shards é uma extensão do Hibernate Core que foi desenvolvido por um pequeno time de engenheiros da Google, com a finalidade encapsular e reduzir a complexidade do particionamento horizontal do banco de dados [13]. O engenheiro de software do Google, Max Ross juntamente com Tomislav Nad e Maulik Shah, desenvolveram o Hibernate Shards e passaram a utilizá-lo para uso interno do Google. Após algum tempo o projeto foi doado para a JBoss e passou a ser mantido pela mesma [4]. Uma das facilidades do Hibernate Shards é a integração com o Hibernate Core que permite fácil desenvolvimento do ambiente multi-tenancy. Para aplicações já existentes que utilizam o Hibernate Core, a implementação pode ser feita sem grandes impactos ou refatorações [13]. Segundo a documentação oficial do Hibernate Shards [13], o framework não implementou totalmente a interface Criteria e o suporte à HQL aceita somente queries simples, não podendo utilizar distinct, order by ou agregações. 3. Exemplo de Aplicação Multi-Tenancy com Hibernate Shards Nesta seção é mostrado um exemplo de uso do Hibernate Shards para desenvolver uma solução multi-tenancy considerando dois tenants. A abordagem selecionada é a de bancos de dados separados (Seção 2.2.1). 8

Assim, para cada tenant existirá um banco de dados com as respectivas entidades. 3.1 Pré-requisitos Para desenvolver esse exemplo, foi utilizada o IDE NetBeans versão 7.3 e a linguagem de programação Java SE 7. A Figura 4 lista as bibliotecas utilizadas. Figura 4. Bibliotecas utilizadas no desenvolvimento do exemplo Conforme pode-se ver na Figura 4, ao adicionar a biblioteca do Hibernate, o NetBeans insere automaticamente outras bibliotecas que são necessárias para o funcionamento do Hibernate. Já o Driver JDBC é responsável pela conexão com o banco de dados, neste caso foi usado o Driver do PostgreSQL. A única biblioteca que difere de uma configuração padrão do Hibernate, é a do Hibernate Shards, a qual pode ser encontrada no site da JBoss Community, na seção de downloads [14]. 9

3.2 Configuração do Hibernate Shards A configuração do Hibernate Shards é muito semelhante à configuração tradicional do Hibernate. Para cada tenant é criado um arquivo de configuração. Abaixo o conteúdo do arquivo de configuração do shard0 (Listagem 1). O mesmo é feito para o shard1. Listagem 1. Arquivo de configuração hibernate0.cfg.xml <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <hibernate-configuration> <session-factory name="hibernatesessionfactory0"> <property name="dialect">org.hibernate.dialect.postgresqldialect</property> <property name="connection.driver_class">org.postgresql.driver</property> <property name="connection.url"> jdbc:postgresql://localhost:5432/shard0 </property> <property name="connection.username">postgres</property> <property name="connection.password">postgres</property> <property name="hibernate.connection.shard_id">0</property> <property name="hibernate.shard.enable_cross_shard_relationship_checks"> true </property> <property name="hibernate.hbm2ddl.auto">update</property> </session-factory> </hibernate-configuration> Seguindo o código da Listagem 1, deve-se criar um novo arquivo de configuração para o tenant1 com o nome "hibernate1.cfg.xml". No novo arquivo alterar o valor da propriedade "connection.url" para "shard1". Também deve ser alterado o valor da propriedade "hibernate.connection.shard_id" para "1". 3.3. Classe para a Estratégia de Definição do Shard Ao considerar vários tenants é necessário ter uma estratégia de sharding, que permite identificar o tenant de cada shard. Para isso, é feita uma implementação da interface ShardSelectionStrategy fornecida pelo Hibernate Shards, conforme o código da Listagem 2. 10

Listagem 2. Classe ShardSelectionStrategyImpl.java package br.com.config.shard; import br.com.model.entidade.pessoa; import org.hibernate.shards.shardid; import org.hibernate.shards.strategy.selection.shardselectionstrategy; public class ShardSelectionStrategyImpl implements ShardSelectionStrategy { @Override public ShardId selectshardidfornewobject(object obj) { if (obj instanceof Pessoa) { return new ShardId(((Pessoa) obj).gettenantid()); throw new IllegalArgumentException(); É importante destacar no código da Listagem 2 a chamada ao método "gettenantid" da classe Pessoa. Este método identifica o tenant e deverá existir em cada entidade. 3.4 Desenvolvendo a Session Factory A classe responsável pela construção da SessionFactory foi desenvolvida conforme é mostrado na Listagem 3. Listagem 3. Classe HibernateUtil.java public class HibernateUtil { private static final SessionFactory sessionfactory = buildsessionfactory(); private static SessionFactory buildsessionfactory() { AnnotationConfiguration config = new AnnotationConfiguration().configure("config/hibernate0.cfg.xml"); config.addannotatedclass(pessoa.class); List shardconfigs = new ArrayList(); shardconfigs.add(buildshardconfig("config/hibernate0.cfg.xml")); shardconfigs.add(buildshardconfig("config/hibernate1.cfg.xml")); Map<Integer, Integer> virtualshardmap = new HashMap<>(); virtualshardmap.put(0, 0); virtualshardmap.put(1, 1); ShardStrategyFactory shardstrategyfactory = buildshardstrategyfactory(); ShardedConfiguration shardedconfig = new ShardedConfiguration( config, shardconfigs, shardstrategyfactory, virtualshardmap); 11

return shardedconfig.buildshardedsessionfactory(); public static SessionFactory getsessionfactory() {return sessionfactory; private static ShardConfiguration buildshardconfig(string configfile) { AnnotationConfiguration prototypeconfig = new AnnotationConfiguration().configure(configFile); return new ConfigurationToShardConfigurationAdapter(prototypeConfig); private static ShardStrategyFactory buildshardstrategyfactory() { return new ShardStrategyFactory() { @Override public ShardStrategy newshardstrategy(list<shardid> shardids) { ShardSelectionStrategy pss = new ShardSelectionStrategyImpl(); ShardResolutionStrategy prs = new AllShardsShardResolutionStrategy(shardIds); ShardAccessStrategy pas = new SequentialShardAccessStrategy(); return new ShardStrategyImpl(pss, prs, pas); ; Na Listagem 3 o método "buildsessionfactory" faz a leitura dos arquivos de configurações dos tenants (Seção 3.2), em seguida, chama o método "buildshardstrategyfactory" que é responsável por criar as estratégias que controlam o comportamento do sharding. Para obter a sessionfactory é instanciada a classe ShardedConfiguration passando como parâmetros: as configurações dos shards, a ShardStrategyFactory e um map com a identificação dos tenants. 3.5 A Classe Pessoa Em seguida é apresentado o código da classe entidade Pessoa, que será persistida no banco de dados, conforme a Listagem 4. Listagem 4. Classe Pessoa.java @Entity public class Pessoa implements Serializable { private static final long serialversionuid = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO, generator = "pessoa_seq") 12

@SequenceGenerator(name = "pessoa_seq", sequencename = "pessoa_seq") private Long id; private String nome; private Integer idade; private int tenantid; //Getters and Setters //Equals and HashCode 3.6 A Classe DAO (Data Access Object) Para facilitar a persistência no banco de dados foi desenvolvido um DAO simples, conforme a Listagem 5. Listagem 5. Classe DAO.java public class DAO<T> { private Session session = null; public void saveorupdate(t objeto) { try { getsession().begintransaction(); getsession().saveorupdate(objeto); getsession().gettransaction().commit(); catch (Exception exception) { rollback(exception, "saveorupdate"); finally { closesession(); private Session getsession() { if (session == null) { session = HibernateUtil.getSessionfactory().openSession(); return session; private void rollback(exception e, String operacao) { if (getsession().gettransaction().isactive()) { getsession().gettransaction().rollback(); System.out.println("Não foi possível executar a operação de " + operacao + ". " + "Erro: " + e.getmessage()); private void closesession() { if (getsession().isopen()) { getsession().close(); 13

session = null; A Listagem 5 mostra o funcionamento de um DAO que permite centralizar o código responsável por persistir os objetos no banco de dados. O método "getsession" é responsável por buscar a sessão invocando o método "getsessionfactory" (Seção 3.4). O método mais importante é o "saveorupdate" que abre a transação, insere o objeto e faz o commit no banco de dados. Se algum erro ocorrer, o método "rollback" é chamado e a operação é revertida. No final a sessão é encerrada. 3.7 A Classe Principal do Exemplo Por fim é criada a classe que contêm o método main, responsável por executar a aplicação. Nessa classe existem dois objetos da classe pessoa, que são persistidos no banco de dados quando a aplicação é executada, conforme a Listagem 6. Listagem 6. Classe Main.java public class Main { public static void main(string args[]) { new Main().run(); private void run() { DAO<Pessoa> daopessoa = new DAO<>(); Pessoa pessoa1 = new Pessoa(); pessoa1.setnome("joão"); pessoa1.setidade(30); pessoa1.settenantid(0); daopessoa.saveorupdate(pessoa1); Pessoa pessoa2 = new Pessoa(); pessoa2.setnome("maria"); pessoa2.setidade(25); pessoa2.settenantid(1); daopessoa.saveorupdate(pessoa2); 14

A classe "Main.java" listada é responsável por executar o aplicativo. Ao invocar o método "run" é feita uma instância do DAO, em seguida são criados dois objetos do tipo Pessoa. Para cada pessoa é definido um tenant diferente, por meio do método "settenantid". O método "saveorupdate" (Seção 3.6) é chamado e insere os registros nos bancos de dados. 3.8 A Criação do Banco de Dados Para que a aplicação funcione é necessário criar dois bancos de dados com os nomes "shard0" e "shard1". Neste exemplo foi utilizado o PostgreSQL. Com a configuração que foi feita na Seção 3.2, definindo o valor da propriedade "hibernate.hbm2ddl.auto" como "update", o hibernate cria as entidades no banco de dados automaticamente. 3.9 Estrutura dos Arquivos do Exemplo A Figura 5 apresenta a estrutura dos arquivos do exemplo, para facilitar a organização. Figura 5. Estrutura de arquivos do exemplo com hibernate shards 3.10 Considerações sobre a Execução da Aplicação No NetBeans para executar o aplicativo, basta abrir a classe "Main.java" e clicar no botão "Executar Projeto". 15

Quando o método "saveorupdate" da classe DAO é chamado, o Hibernate Shards precisa identificar em qual banco de dados deve ser inserido o novo registro. Para isso é invocado o método "selectshardidfornewobject" da classe "ShardSelectionStrategyImpl" (Seção 3.3), que identifica por meio do método "gettenantid" à qual tenant pertence o objeto a ser gravado. Ao executar a aplicação, será feita a inserção da pessoa com nome "João" no banco de dados "shard0", e a pessoa com nome "Maria" será inserida no banco de dados "shard1". 4. Lições Aprendidas Durante o desenvolvimento deste trabalho, foi possível perceber a importância da pesquisa de novas tecnologias e conceitos. Principalmente sobre Cloud Computing e o desenvolvimento e entrega de Software como Serviço, que é uma forte tendência nos últimos anos. Existem vários artigos que trazem informações sobre multi-tenancy, porém pode-se perceber a escassez de material que aborde a implementação. Ao pesquisar sobre o framework Hibernate Shards não foram encontradas muitas soluções implementadas, o que dificultou no desenvolvimento do exemplo da aplicação. 5. Considerações Finais e Trabalhos Futuros Este artigo apresentou o desenvolvimento de um exemplo de aplicação multi-tenancy utilizando o framework Hibernate Shards. Foram mostrados os principais conceitos de cloud computing e seus três modelos de serviço: SaaS, PaaS e IaaS, que permitiram destacar o modelo arquitetural multi-tenancy e suas abordagens. O fornecimento de software como serviço pode trazer muitas vantagens para empresas que desenvolvem software. É muito importante que programadores e engenheiros de software conheçam melhor esse modelo. A 16

pesquisa e a construção de um exemplo de aplicação multi-tenancy foi o que motivou o desenvolvimento deste trabalho. Por meio deste artigo e do exemplo considerado, foi possível concluir que o Hibernate Shards atende às necessidades para o desenvolvimento de uma solução multi-tenancy para pequenas aplicações. Sua configuração é muito simples, principalmente se existir conhecimento prévio do Hibernate. É importante destacar que o Hibernate Shards suporta somente queries simples e sua última versão foi lançada no ano de 2007. Este artigo forneceu uma visão sobre as principais características sobre o modelo multi-tenancy. Dentre as várias opções de implementação, este trabalho se limitou a desenvolver um exemplo de aplicação multi-tenancy, com a abordagem de bancos de dados separados, utilizando o framework Hibernate Shards. Como direção para possíveis trabalhos futuros tem-se: (i) desenvolver exemplos das outras abordagens multi-tenancy; (ii) estudar a viabilidade da utilização do Hibernate Shards ou do Hibernate 4, que já possuem suporte a multi-tenancy; e (iii) catalogar e comparar os principais frameworks multitenancy para Java. Referências Bibliográficas [1] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST Cloud Computing Program. Disponível em: <http://www.nist.gov/itl/cloud/index.cfm>. Acesso em: 01 de julho 2013. [2] AZAMBUJA JUNIOR, UALTER. "Computação Java nas Nuvens". Java Magazine, 108ª Edição, Editora DevMedia, 2012. [3] NETO, JOSINO RODRIGUES. "Desenvolvimento de aplicações multi-tenancy: um estudo de mapeamento sistemático". Recife: UFPE, 2012. 116 p. Dissertação (Mestrado) - Programa de Pós-graduação em Ciência da Computação, Universidade Federal de Pernambuco, Recife, 2012. [4] MOREIRA, THIAGO. "Multitenancy e Hibernate Shards". Java Magazine, 92ª Edição, Editora DevMedia, 2011. [5] SOUSA, FLÁVIO; MOREIRA, LEONARDO; MACHADO, JAVAM. "Computação em Nuvem: Conceitos, Tecnologias, Aplicações e Desafios". ERCEMAPI 2009, SBC: 2009. [6] OLIVEIRA JUNIOR, E. A.; BONINI, R. P. "Desenvolvimento de Sistemas para a Nuvem: como identificar as principais tecnologias de apoio ao ciclo de vida de software". Engenharia de Software Magazine, v. 57, p. 55-62, 2013. 17

[7] NETO, JOSINO RODRIGUES et al. "Software as a Service: Desenvolvendo Aplicações Multi-tenancy com Alto Grau de Reuso". WEBMEDIA, 2012. [8] GOOGLE INC. Google App Engine. Disponível em: <http://code.google.com/intl/pt- BR/appengine/>. Acesso em: 03 de julho 2013. [9] SALESFORCE.COM, INC. Social & Mobile Application Development Platform. Disponível em: <http://www.force.com>. Acesso em: 04 de julho 2013 [10] MICROSOFT INC. Windows Azure Platform. Disponível em: <http://www.microsoft.com/windowsazure/pt/br/>. Acesso em: 04 de julho 2013. [11] RAMALHO, NEILSON CARLOS LEITE. "Um Estudo Sobre a Adoção da Computação em Nuvem no Brasil". São Paulo: USP, 2012. 143 p. Dissertação (Mestrado) - Programa de Pós-graduação em Sistemas de Informação, Escola de Artes, Ciências e Humanidades da Universidade de São Paulo, São Paulo, 2012. [12] MICROSOFT INC. "Arquitetura de dados para múltiplos inquilinos". Disponível em: <http://msdn.microsoft.com/pt-br/library/aa479086.aspx>. Acesso em: 01 de agosto 2013. [13] JBoss Community. "Hibernate Shards documentation". Disponível em: <http://www.hibernate.org/subprojects/shards/docs>. Acesso em: 06 de maio 2013. [14] JBoss Community. "Hibernate Shards Downloads". Disponível em: <http://www.hibernate.org/subprojects/shards/download> Acesso em: 06 de maio 2013. 18