Um exemplo de aplicacao multi-tenancy com - ESPWEB

Um exemplo de aplicação multi-tenancy com Hibernate
Shards
Anderson Fernando Custódio1, Edson A. Oliveira Junior2
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 –
[email protected]
2
Departamento de Informática – Universidade Estadual de Maringá (UEM) - Av. Colombo, 5790 – Bloco
C56 – Maringá – PR – Brasil - [email protected]
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
ou
multi-tenancy
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
consideravelmente
a
Shards.
complexidade
O
do
uso
desse
framework
desenvolvimento
diminui
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]
[12
A Figura
igura 1 ilustra os tenants de uma aplicação, onde o nome do banco
de dados é a palavra "Tenant"
"
seguido
eguido 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
a abordagem,
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
eparados (Separate schema)
Nessa
a 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.
dados
Figura 2. Modelo de dedicação compartilhada com esquemas separados [12]
[12
6
Nesse modelo é criado um esquema para cada tenant,, como é possível
ver na Figura
igura 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.
ompartilhado (Partitioned data)
2.2.3 Esquema Compartilhado
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
igura 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/ptBR/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
<http://www.microsoft.com/windowsazure/pt/br/>. Acesso em: 04 de julho 2013.
em:
[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
<http://www.hibernate.org/subprojects/shards/docs>. Acesso em: 06 de maio 2013.
em:
[14]
JBoss
Community.
"Hibernate
Shards
Downloads".
Disponível
<http://www.hibernate.org/subprojects/shards/download> Acesso em: 06 de maio 2013.
em:
18