MIDAS: Um middleware para interoperar aplicações

UNIVERSIDADE FEDERAL DA BAHIA
INSTITUTO DE MATEMÁTICA
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
Tarcio Marinho Machado
MIDAS: Um middleware para interoperar aplicações SaaS e
provedores de DaaS
Salvador
2015
Tarcio Marinho Machado
MIDAS: Um middleware para interoperar
aplicações SaaS e provedores de DaaS
Monografia apresentada ao curso de graduação
em Sistemas de Informação, Departamento de
Ciência da Computação, Instituto de Matemática, Universidade Federal da Bahia, como
requisito parcial para obtenção do grau de
Bacharel em Sistemas de Informação.
Orientadora: Professora Daniela Barreiro Claro
Salvador
2015
1
Resumo
A computação em nuvem refere-se aos serviços computacionais oferecidos sob demanda na Internet, como
aplicações, plataformas e infraestrutura. Software como um Serviço (SaaS) mostra-se ser uma área promissora
no campo da computação em nuvem, trazendo melhorias para o modelo tradicional de aplicações na Internet.
Em estudos anteriores, foi observado, contudo, que a interoperabilidade entre diferentes provedores de serviços
na nuvem é um tópico ainda pouco explorado. Assim, o presente trabalho propõe o desenvolvimento de um
middleware que visa estabelecer uma comunicação transparente entre aplicações SaaS e dados de quaisquer
provedores de Dado como Serviço (DaaS) de forma que as aplicações possam trabalhar com conjuntos de
dados de serviços DaaS de qualquer fonte. O middleware, doravante denominado MIDAS, converte a consulta
original para uma requisição DaaS adequada e a envia para o provedor do serviço. O resultado obtido é
então formatado de acordo com a resposta esperada pela aplicação. Com o intuito de prover uma validação
para a funcionalidade do middleware, foi elaborado um estudo de caso explicando seu fluxo de trabalho e
implementação e uma análise em relação ao desempenho quando o MIDAS é utilizado na comunicação. Os
resultados obtidos foram satisfatórios em relação à utilização do MIDAS para permitir a interoperabilidade
entre SaaS e DaaS.
Palavras-chave: Computação em nuvem, Software como um Serviço, SaaS, middleware, MIDAS.
3
Abstract
Cloud computing refers to the computational services offered on demand over the Internet, such as applications, platforms and infrastructure. Software as a Service (SaaS) is showing to be a promising area of research
in the cloud computing field, bringing some improvements to the tradicional web applications model. In previous studies, it has been noticed, however, that the interoperability among different cloud service providers
is a topic yet poorly explored. Thus, the present work proposes the development of a middleware that aims
to establish a transparent communication between SaaS applications and data from any Data as a Service
(DaaS) provider in a way that applications can work with DaaS datasets from any source. The middleware,
named MIDAS, converts the original query to a proper DaaS request and send it to the service provider. The
obtained resultset is then formatted to match the response the application is expecting. In order to provide
a validation for the middleware’s functionality, it has been devised a case study explaining its workflow and
implementation and an analysis regarding the performance when MIDAS is used in the communication. The
obtained results were satisfactory regarding the utilization of MIDAS to allow the interoperability between
SaaS and DaaS.
Keywords: Cloud computing, Software as a Service, SaaS, middleware, MIDAS.
Sumário
1
INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2
FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1
Computação em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3
Modelo multi-locatário (multi-tenancy ) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4
Técnicas de mapeamento de esquema de banco de dados . . . . . . . . . . . . . . . . .
14
2.4.1
Tabelas Esparsas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4.2
Tabela Básica e Tabela de Extensão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.5
Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3
TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1
Personalização (customizations) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2
Armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3
Migração de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.4
Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.5
Gerenciamento do banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.6
SGBDR (Sistema de Gerenciamento de Banco de Dados Relacional) . . . . . . . . . . .
25
4
PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1
Aplicação SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
Módulo de Requisição do MIDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.1
Decompositor de Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2.2
Construtor de Consulta
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5
VALIDAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.1
Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.1.1
Pontos de Wi-Fi em Nova York . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.1.2
Hotéis em Nova York
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2
5.3
Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ameaças para a validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
36
6
CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
6.1
Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
6.2
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Lista de ilustrações
Figura 1 – Modelo único locatário (lado esquerdo) versus multi-locatário (lado direito) . . . . . . . .
13
Figura 2 – Mapeamento da área de Software como um Serviço . . . . . . . . . . . . . . . . . . . . . .
17
Figura 3 – Abstração das múltiplas customizações (XUXU; QINGZHONG; LANJU, 2010) . . . . . .
18
Figura 4 – Arquitetura para múltiplas customizações (XUXU; QINGZHONG; LANJU, 2010) . . . .
19
Figura 5 – Arquitetura de Tabelas Esparsas (WEILIANG; SHIDONG; LANJU, 2010) . . . . . . . .
Figura 6 – Arquitetura de Tabela Básica com Tabelas de Extensão dinâmicas (SHENGQI; SHIDONG;
20
LANJU, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Figura 7 – Balanceamento de nós a partir da representação de grafos (HOU; ZHANG; KONG, 2013)
21
Figura 8 – Evolução de metadados (LIU; WU, 2012) . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Figura 9 – Gerenciamento de clusters (BOYTSOV; SOKOLOV, 2012) . . . . . . . . . . . . . . . . .
25
Figura 10 – Middleware MIDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Figura 11 – Diagrama de sequência completo do middleware MIDAS . . . . . . . . . . . . . . . . . . .
28
Figura 12 – Diagrama de sequência do estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Lista de tabelas
Tabela 1 – Análise dos tempos de resposta para a consulta de hotéis . . . . . . . . . . . . . . . . . .
35
Tabela 2 – Análise dos tempos de resposta para a consulta de pontos de Wi-Fi . . . . . . . . . . . .
36
1 Introdução
A Computação em Nuvem refere-se ao novo paradigma computacional que provê aplicações, armazenamento
e até mesmo poder computacional (hardware) sob demanda através da Internet, ou seja, como um serviço
(FOX et al., 2009; BUYYA; YEO; VENUGOPAL, 2008).
A crescente utilização dos serviços baseados em nuvem propicia o surgimento de diferentes abordagens.
Algumas das mais adotadas (ZHOU et al., 2010) são Plataforma como um Serviço (PaaS), Infraestrutura
como um Serviço (IaaS), Dado como um Serviço (DaaS) e Software como um Serviço (SaaS). De forma
geral, serviços na nuvem são cobrados de acordo com a demanda, ou seja, o cliente paga apenas pelos
recursos efetivamente utilizados, um dos fatores motivadores para a migração/adoção do serviço. Outro fator
importante é o potencial de escalar uma aplicação transparentemente de acordo com a demanda. Em outras
palavras, as nuvens representam uma grande malha de sistemas distribuídos e paralelos (BUYYA; YEO;
VENUGOPAL, 2008) que permite que as aplicações possam expandir ou contrair à medida que necessitam
de mais ou menos recursos.
Infraestrutura como Serviço (IaaS, do inglês Infrastructure as a Service) é o modelo de serviço que provê
o aluguel de infraestrutura computacional, como redes e servidores, sob demanda na nuvem (ZHOU et al.,
2010).
Plataforma como um Serviço (PaaS, do inglês Platform as a Service) pode ser visto como um paradigma
intermediário, no qual o cliente faz a escolha de uma plataforma pré-configurada e não precisa se preocupar
com a manutenção da camada de infraestrutura.
O modelo de Software como Serviço (SaaS, do inglês Software as a Service) oferece o aluguel de aplicações
web sob demanda.
Dado como Serviço (DaaS, do inglês Data as a Service) é o paradigma que fornece conjuntos de dados
sob demanda. Diferentemente do modelo de Banco de Dados como um Serviço, que refere-se ao oferecimento
de um banco de dados convencional, como o Oracle ou MongoDB, sob demanda e hospedado na nuvem.
Ao longo da construção deste trabalho, foi desenvolvida uma pesquisa extensiva da literatura disponível a
cerca do modelo de SaaS. O intuito primordial dessa pesquisa inicial foi estudar a comunicação das aplicações e
dados na nuvem a fim de identificar questões ainda pouco exploradas. Como resultado, foi possível observar
uma escassez de trabalhos voltados para a interoperabilidade entre aplicações SaaS e dados advindos de
provedores de DaaS. Essa escassez se deve possivelmente à falta de interesse por parte dos provedores de
DaaS em se padronizar o acesso aos dados.
Com o intuito de preencher essa lacuna, o presente trabalho propõe o desenvolvimento de um middleware
denominado MIDAS, que viabiliza a comunicação transparente entre aplicações SaaS e dados de DaaS independentemente dos provedores dos serviços.
As alternativas oferecidas pelo mercado para oferecer interoperabilidade entre serviços na nuvem limitamse ao fornecimento de modalidades diferentes dentro da mesma nuvem. A comunicação entre serviços de
nuvens distintas é possível desde que a aplicação seja adaptada manualmente para essa nova proposta.
Contudo, foi verificado que as soluções existentes não são transparentes para os provedores dos serviços.
Este trabalho valida a proposta do middleware a partir da concepção de um protótipo do middleware que
estabelece a comunicação transparente entre aplicação e dados oriundos de nuvens distintas. Diante desse
resultado, foi realizada a análise do desempenho do protótipo do ponto de vista do usuário, ou seja, o quão
10
rápido a resposta esperada é retornada. A análise constatou que a inserção do MIDAS na comunicação
aumentou o tempo de resposta em cerca de 96ms.
O presente trabalho está organizado como segue: o Capítulo 2 agrega a fundamentação teórica necessária
para a compreensão da proposta, o Capítulo 3 reúne trabalhos relacionados, o Capítulo 4 apresenta detalhadamente a proposta deste trabalho, o Capítulo 5 descreve a validação desta proposta incluindo um estudo de
caso, análise de desempenho e possíveis ameaças para a validação. Por fim, o Capítulo 6 conclui o trabalho
e apresenta possíveis trabalhos futuros.
2 Fundamentação teórica
Este capítulo reúne todo o embasamento teórico fundamental para a compreensão deste trabalho.
2.1 Computação em nuvem
A computação em nuvem é um modelo em que recursos computacionais – como servidores, redes, aplicações
e bancos de dados – são oferecidos como serviço sob demanda através da Internet. Nesse modelo, o cliente
locatário paga tão somente pelos recursos consumidos e livra-se dos custos de manutenção da infraestrutura
utilizada, que passa a ser responsabilidade do provedor do serviço. Mell e Grance (2011) apontam cinco
características essenciais do modelo de computação em nuvem:
Autoatendimento sob demanda. O fornecimento de recursos adicionais (mais espaço de armazenamento,
por exemplo) acontece de forma automática, sob demanda, sem exigir interação do consumidor com o
provedor do serviço.
Amplo acesso à rede. Clientes acessando a rede a partir de quaisquer plataformas, de dispositivos móveis
a estações de trabalho, têm acesso aos seus serviços.
Compartilhamento de recursos. Os recursos oferecidos pelo provedor do serviço são compartilhados pelos seus clientes através do modelo multi-locatário, em que recursos físicos ou virtuais são atribuídos
dinâmicamente aos consumidores de acordo com a demanda.
Rápida elasticidade. Recursos são fornecidos e liberados elasticamente, de forma a conseguir esticar ou
contrair de acordo com a demanda, dando ao consumidor a sensação de ter recursos ilimitados.
Serviço medido. A utilização dos recursos pode ser controlada e monitorada a qualquer momento, o que
provê transparência tanto para o consumidor quanto para o provedor do serviço.
De acordo com Mell e Grance (2011) e Zhou et al. (2010), as principais modalidades oferecidos na nuvem
são Infraestrutura como Serviço, Plataforma como Serviço e Software como Serviço. Contudo, os serviços
da nuvem não se limitam a esses três modelos, existe na literatura (XU, 2012; DUAN, 2012) o conceito de
Tudo como Serviço (XaaS, Everything as a Service), que simboliza as inúmeras possibilidades de serviço na
nuvem.
Infraestrutura como Serviço (IaaS, do inglês Infrastructure as a Service) é o modelo de serviço que provê
o aluguel de infraestrutura computacional, como redes e servidores, sob demanda na nuvem (ZHOU et al.,
2010). Com este serviço, os clientes possuem a liberdade de configurar todo o ambiente da maneira mais
conveniente, inclusive podendo instalar o sistema operacional de sua preferência. O acesso ocorre através de
uma máquina virtual sob total controle do cliente.
Plataforma como um Serviço (PaaS, do inglês Platform as a Service) pode ser visto como um paradigma intermediário, no qual o cliente faz a escolha de uma plataforma pré-configurada e não precisa se
preocupar com a manutenção da camada de infraestrutura, enquanto que, ainda assim, possui um ambiente
personalizado para executar suas aplicações.
O modelo de Software como Serviço (SaaS, do inglês Software as a Service) surge não apenas como um
novo paradigma para executar aplicações na nuvem, mas também promove uma mudança de conceitos sobre
12
como gerenciar os dados das aplicações na nuvem e como aprimorar seu uso para melhor desempenho e
escalabilidade. Ambas as partes se beneficiam com este novo modelo sob demanda: os usuários, posto que
podem acessar a aplicação de qualquer lugar e a qualquer momento, diretamente da web; e os provedores de
software, que irão eliminar os custos de manutenção da infraestrutura, uma vez que estes ficam a cargo do
provedor de serviço da nuvem.
Dado como Serviço (DaaS, do inglês Data as a Service) é um paradigma proeminente dentre os serviços
de computação em nuvem que fornece dados sob demanda. O fornecimento dos dados pelos provedores
de DaaS costuma ocorrer através de APIs (Application Programming Interface), interfaces que permitem o
consumidor consultar os dados. Em alguns casos, dados públicos também podem ser adquiridos via download
no domínio do provedor. Consequentemente, consumidores livram-se da manutenção de bases de dados
em larga escala. Vale ressaltar que Dados como Serviço (DaaS) e Banco de Dados como Serviço (DBaaS)
são dois serviços distintos. O último refere-se ao oferecimento de um banco de dados, como o Oracle ou
MongoDB, sob demanda e hospedado na nuvem. O foco do modelo de Dados como Serviço está no conjunto
de dados em si, como tabelas em um banco de dados relacional, de tal forma que apenas a leitura dos
dados é permitida. Sendo assim, aos consumidores cabe escolher dentre os conjuntos de dados oferecidos
pelo provedor quais se adequam à sua finalidade. Além disso, governos, instituições e empresas tendem a
disponibilizar publicamente informações, como despesas, orçamentos ou dados econômicos, o que contribui
para o crescimento da demanda por provedores de DaaS.
2.2 Interoperabilidade
Conforme apontam (ASUNCION; SINDEREN, 2010), a definição de interoperabilidade difere levemente de
autor para autor na literatura. No entanto, pode-se entender por interoperabilidade a capacidade de dois ou
mais sistemas interagirem entre si para atingir uma determinada meta sem que nenhuma das partes precise
saber das especificidades da outra (POKRAEV, 2009). Na área de computação em nuvem, (LOUTAS et al.,
2011; AHRONOVITZ et al., 2010) apresentam o conceito de interoperabilidade como sendo “a habilidade de
escrever código que funciona simultaneamente em mais de um provedor de Nuvem, independentemente das
diferenças entre os provedores”.
Quando se busca interoperar dois ou mais sistemas, de forma a fazê-los colaborar em uma tarefa, (ASUNCION; SINDEREN, 2010) destacam a dificuldade de se chegar a uma maneira em comum para codificar,
compreender e utilizar os dados intercambiados. Sendo assim, eles dividem essas diferenças de interoperabilidade em três camadas: sintática, semântica e pragmática.
A interoperabilidade sintática é obtida quando há a compatibilidade de gramática e vocabulário dos dados
entre cada sistema envolvido durante o intercâmbio.
A interoperabilidade semântica é alcançada quando existe o entendimento comum do significado dos dados
por todas as partes.
A interoperabilidade pragmática é atingida quando o efeito das mensagens enviadas é compreendido
pelos sistemas participantes do intercâmbio, logo as mensagens enviadas causarão o efeito esperado pelo
sistema remetente. Pokraev (2009) diz ainda que a interoperabilidade pragmática só é obtida se existe a
interoperabilidade sintática e semântica entre os sistemas.
De acordo com Loutas et al. (2011), grande parte dos estudos de interoperabilidade voltados para computação em nuvem concentram-se no aspecto semântico. Além disso, dois requisitos fundamentais são destacados
para que se resolvam os problemas de compatibilidade e cooperação entre os sistemas na nuvem: o desenvolvimento de um conjunto de modelos padronizados que descrevam os principais elementos da nuvem, como
13
serviços e recursos computacionais e a criação de uma API padrão para a nuvem que seja suportada pelos
provedores da nuvem. A dificuldade em se adotar um padrão para a nuvem é principalmente a resistência
por parte dos provedores, que veem em seus diferenciais uma vantagem competitiva.
2.3 Modelo multi-locatário (multi-tenancy )
Sistemas de Gerenciamento de Banco de Dados Relacionais (SGBDR) são vastamente utilizados pelos mais
diversos tipos de aplicação. Atualmente, com a explosão dos serviços na nuvem, muitas novidades vem
surgindo. Aplicações tradicionais realizam suas operações de dados, como inserção, atualização e consulta,
sobre uma base de dados privada, geralmente acessível apenas de dentro da organização. Esse é o escopo
de uma aplicação com um único locatário (single-tenant), onde o locatário é a própria organização (lado
esquerdo da Figura 1). Ao mudar para a nuvem, o que muitas dessas organizações buscam é a vantagem de
cortar os custos com a manutenção da infraestrutura computacional dessas aplicações. Ao adotar um serviço
de SaaS, essa organização está migrando seus dados para os servidores do provedor de SaaS, passando a ser
um dos múltiplos locatários do serviço e pagando somente pelos recursos consumidos, o que caracteriza a
arquitetura do modelo multi-locatário (BEZEMER et al., 2010). A manutenção dos dados dos locatários,
agora responsabilidade do provedor, é realizada através de três abordagens principais:
Figura 1 – Modelo único locatário (lado esquerdo) versus multi-locatário (lado direito)
1. Máquina Compartilhada. Nessa abordagem os locatários compartilham o servidor, porém cada
um adquire um banco de dados individual com tabelas particulares. De acordo com os resultados
obtidos em (JACOBS; AULBACH et al., 2007), um ponto negativo desse modelo é o baixo potencial
de escalabilidade, embora, por outro lado, a migração de dados dos clientes seja mais simples devido
ao alto isolamento de cada locatário.
2. Instâncias Compartilhadas. Nesse modelo os locatários compartilham uma instancia no banco de
dados, contudo ainda mantém as tabelas privadas.
3. Tabelas Compartilhadas. Nesse modelo, como o próprio nome já diz, diferentes locatários compartilham uma mesma tabela no mesmo esquema dentro do banco de dados. Implementações desse modelo
14
costumam incluir uma coluna Tenant (locatário) em cada uma das tabelas como forma de identificar
qual linha pertence a qual locatário. Essa abordagem é conhecida por oferecer maior escalabilidade em
comparação às demais, mas também traz uma série de problemas, como baixo desempenho e dificuldade
de migração.
2.4 Técnicas de mapeamento de esquema de banco de dados
Nas subseções seguintes estão descritos alguns dos modelos de arquitetura para armazenamento de dados mais
usados na implementação de esquemas de banco de dados para aplicações SaaS no modelo multi-locatário.
2.4.1 Tabelas Esparsas
Esta abordagem baseia-se no modelo de Tabelas Compartilhadas, sua principal característica é a presença
de tabelas bastante largas, o que se traduz em uma altíssima quantidade de colunas. O modelo é composto
por dois tipos de tabela: Tabelas de Metadados e Tabelas de Dados Esparsos. A primeira conta com três
atributos fundamentais que são o TenantID (identificador do locatário), TableID (identificador da tabela) e
ColumnID (identificador da coluna). Já a Tabela de Dados possui o TenantID, TableID e mais as N colunas
de dados de cada locatário. Embora esse modelo contribua para uma redução significativa do número de
tabelas no esquema, ele acaba causando desperdício de espaço de armazenamento e queda de desempenho
das consultas em função do elevado número de NULLs (valores nulos) gerados, visto que alguns locatários
podem usar mais colunas que outros.
2.4.2 Tabela Básica e Tabela de Extensão
Tabela Básica é a maneira mais simples de se implementar o modelo multi-locatário, tendo em vista que ele
só adiciona a coluna TenantID em cada tabela do esquema e compartilha essas tabelas entre os locatários
(AULBACH et al., 2008). As Tabelas de Extensão, por sua vez, tentam solucionar o problema de extensibilidade, que significa separar dados comuns de dados mais específicos, pertinentes a determinados grupos de
locatários (dados de extensão). Ambas as tabelas de dados comuns e dados de extensão recebem o atributo
TenantID, já que diferentes locarários podem usar os mesmos dados de extensão, mais o atributo RowID, um
identificador da linha.
No comparativo, as Tabelas Básicas apresentam grande escalabilidade, entretanto produzem muitos valores nulos, enquanto que as Tabelas de Extensão proveem melhor extensibilidade com a consequência de que
o número de tabelas cresce proporcionalmente ao número de locatários. Existe ainda uma versão aprimorada
discutida em (SHENGQI; SHIDONG; LANJU, 2010) que combina Tabela Básica com Tabela de Extensão
como um modo de limitar o número de tabelas de extensão a somente uma. Para isso, esse novo modelo
propõe uma Tabela Básica contendo todos os dados comuns entre os locatários, uma Tabela de Extensão
que armazena os pares nome-valor das colunas de extensão e uma Tabela de Metadados. Mais uma vez
os atributos TenantID e TableID são empregados, desta vez nas tabelas Básica e de Metadados. Um novo
atributo é sugerido, o GlobalID, que é inserido nas tabelas Básica e de Extensão com o propósito de se chegar
aos respectivos dados de extensão de cada locatário partindo da Tabela Básica.
15
2.5 Middleware
De maneira simplificada, um middleware pode ser visto como uma camada intermediária de abstração entre
sistemas heterogêneos que passam a se comunicar de maneira transparente através de uma interface em
comum. Uma definição mais técnica, fornecida por (BRUNEO; PULIAFITO; SCARPA, 2007) no contexto
de redes de sistemas distribuídos, é a de que o middleware é uma camada de software empregada entre
o sistema operacional e as aplicações, provendo abstração para o desenvovimento de sistemas distribuídos.
Dessa forma, serviços como concorrência, transações, segurança e alta disponibilidade são ofertados pelo
middleware e não pelos desenvolvedores das aplicações.
No contexto da computação em nuvem, middlewares como o IBM Altocumulus (RANABAHU; MAXIMILIEN, 2009) são empregados como meio de se uniformizar a comunicação entre serviços na nuvem. Uma
das vantagens de se utilizar um middleware para comunicar serviços na nuvem é a de se obter uma interface
padrão independente da linguagem de programação adotada pelos diferentes provedores de serviço. Ou seja,
obtêm-se uma comunicação transparente.
Uma característica comum das implementações de middleware é que eles costumam ser baseados em XML
(Extensible Markup Language), protocolo SOAP (Simple Object Access Protocol ) e Arquitetura Orientada a
Serviços (SOA) (ORACLE, 2015). A utilização desses recursos se deve exatamente ao fato de serem orientados
a serviços web, que visam amplo suporte aos mais variados sistemas e aplicações. Outro formato também
bastante usado é o JSON (JavaScript Object Notation) devido à sua simplicidade.
Em contrapartida, a inserção de um middleware em uma comunição entre sistemas heterogêneos adiciona
ao tempo total da comunicação o tempo de processamento do middleware, fator que pode ser prejudicial para
a execução de sistemas que precisam de alta performance, por exemplo.
3 Trabalhos relacionados
Com o intuito de melhor posicionar a relevância do presente trabalho, foi realizada uma revisão sistemática
simplificada na qual foram selecionados os artigos mais relevantes ligados diretamente à relação entre SaaS e
dados na nuvem. Inicialmente foram selecionados todos os trabalhos que continham as palavras-chave ‘SaaS’
e ‘dados na nuvem’. Em seguida, foram aplicados os seguintes critérios de exclusão: (i) artigos que não
possuíam trabalhos relacionados; e (ii) artigos cujo foco principal não estava no acesso/gerenciamento dos
dados. Por exemplo, foram descartados artigos focados em segurança de aplicações na nuvem e na camada
de negócios. Por fim, obteve-se um conjunto de 12 (doze) artigos que foram sintetizados no gráfico de bolhas
da Figura 2. O gráfico nos permite observar quais tópicos de pesquisa estão sendo mais ou menos abordados
pela comunidade científica, além de ressaltar o tipo de contribuição científica proposto e a forma utilizada
para a validação.
Figura 2 – Mapeamento da área de Software como um Serviço
No eixo vertical do gráfico (Research Context) estão representados os principais tópicos de pesquisa relacionados: Interoperabilidade (Interoperability), Personalização (Customization), Armazenamento (Storage),
Migração (Migration), Escalabilidade (Scalability) e SGBDR (RDBMS ). Já o eixo horizontal relaciona duas
visões: do lado esquerdo, o tipo de contribuição científica do trabalho e do lado direito, sua forma de validação. Dentre as contribuições, dois artigos propuseram um Framework, dois propuseram um Método (Method ),
um propôs uma Ferramenta (Tool ), quatro propuseram uma Arquitetura (Arquitecture) e três propuseram
um Modelo (Model ). Conforme mostra o gráfico, apenas dez dos trabalhos forneceram uma forma de valida-
18
ção. A mais utilizada foi o Caso de uso (Use case), presente em quatro artigos. Dois validaram através de
Avaliação empírica (Empirical evaluation), dois através de Experimento controlado (Controlled experiment),
um através de Benchmark e um através de protótipo. As interseções entre os eixos são bolhas que informam
quantos artigos foram enquadrados na relações Tópico x Contribuição (lado esquerdo) e Tópico x Validação
(lado direito). Ou seja, uma bolha com número 2 no lado esquerdo do gráfico representa um conjunto de
dois artigos que fornecem uma contribuição X (eixo horizontal) e abordam o tema Y (eixo vertical), caracterizando a relação Tópico x Contribuição. O mesmo vale para o lado direito do gráfico, que representa a
relação Tópico x Validação.
Os tópicos de pesquisa observados são explanados em mais detalhes nas seções a seguir.
3.1 Personalização (customizations)
Este tópico reúne os trabalhos que tratam do processo de personalização (customização) do banco de dados
de uma aplicação SaaS.
De acordo com (XUXU; QINGZHONG; LANJU, 2010), o serviço de SaaS não suporta que um locatário
alugue uma única aplicação e faça múltiplas personalizações, fator que leva a diversas operações repetidas e
duplicação de metadados. A Figura 3 exibe dois níveis de customização. No primeiro nível, foi adicionada
uma coluna vermelha às tabelas X e Y. No segundo nível, mais duas personalizações foram realizadas. Na
primeira, adiciona-se uma coluna verde à tabela X, que pode ser útil para uma determinada subdivisão da
aplicação. Na segunda, adiciona-se duas colunas amarelas à tabela Y, provavelmente relevante para outro
ramo da aplicação. As colunas azuis representam os atributos originais da aplicação. Com esse objetivo, eles
propuseram a arquitetura de um modelo de armazenamento de dados em esquemas compartilhados orientado
a metadados que habilita múltiplas customizações.
Figura 3 – Abstração das múltiplas customizações (XUXU; QINGZHONG; LANJU, 2010)
Conforme ilustrado na Figura 4, a solução tem seus pilares no paradigma de Tabelas Compartilhadas,
tendo as seguintes características:
• Uma área para as tabelas com metadados personalizados, responsável por manter os metadados das
tabelas e colunas das aplicações e os metadados customizados do locatário.
• Uma área para as tabelas de dados, as quais armazenam os dados da camada de negócios.
• Uma área para tabelas de índices, que mantém tabelas de índices correspondentes a diferentes esquemas.
A solução é validada através de um sistema de testes online que conclui que quanto maior o montante de
metadados compartilhados, menos espaço é demandado para os metadados customizados em comparação ao
modelo tradicional.
19
Figura 4 – Arquitetura para múltiplas customizações (XUXU; QINGZHONG; LANJU, 2010)
O trabalho dessa seção descreve uma solução voltada para aplicações SaaS na nuvem, assim como a
proposta do presente trabalho, porém não trata da interoperabilidade com fontes de dados DaaS.
3.2 Armazenamento
Soluções de armazenamento foram as mais propostas dentre os tópicos observados, englobando cinco artigos.
De maneira geral, essas soluções descrevem formas de se reduzir o desperdício de espaço nos bancos de dados
e aperfeiçoar o desempenho das consultas.
(WEILIANG; SHIDONG; LANJU, 2010) propuseram aperfeiçoar a eficiência das consultas e minimizar
o desperdício de espaço de armazenamento reduzindo a quantidade de valores nulos gerados pelo modelo
de Tabelas Esparsas. Ao invés de empregar uma única tabela esparsa correlacionando-se com uma tabela
de metadados, eles implementam algumas tabelas esparsas com um número máximo de colunas, que serão
as tabelas de dados. Eles também adicionam a Tabela de Metadados Esparsa, que relaciona a tabela de
metadados com cada tabela esparsa de dados. A Figura 5 ilustra a estruturação das múltiplas tabelas
esparsas em comparação com o modelo tradicional de uma única tabela esparsa.
Armazenando os dados dos locatários em múltiplas tabelas esparsas, é possível selecionar aquela cujo o
número máximo de colunas se aproxima mais do número de atributos usados pelo locatário. Por exemplo,
em um banco de dados com quatro tabelas esparsas de 30, 80, 200 e 500 colunas respectivamente, a tabela
de 80 colunas seria a escolhida para um locatário que usa 50 colunas. A determinação do número de tabelas
esparsas e seus respectivos limites de colunas é proposta como uma especulação fundada na demanda dos
locatários. Como há uma variação notável dessa demanda, ele põem que não há uma fórmula para se chegar
a um número preciso de tabelas e colunas, esse seria um resultado da análise das informações disponíveis a
respeito das customizações dos locatários.
A solução proposta por (SHENGQI; SHIDONG; LANJU, 2010) aumenta a eficiência do acesso aos dados
da arquitetura de armazenamento do modelo Tabela Básica combinada com Tabelas de Extensão. Eles armazenam alguns dos dados de extensão mais frequentemente acessados na Tabela Básica, evitando, portanto,
a reconstrução de tuplas. A nova estrutura traz mudanças tanto na Tabela Básica quanto na tabela de
metadados. Nessa última, três colunas são adicionadas (Figura 6):
20
(a) Única tabela esparsa
(b) Múltiplas tabelas esparsas
Figura 5 – Arquitetura de Tabelas Esparsas (WEILIANG; SHIDONG; LANJU, 2010)
Count Sua função é registrar o número de acessos à coluna correspondente.
IsInBasic Sua função é registrar se a coluna já foi transferida para a Tabela Básica.
BColumnName Sua função é guardar o nome da coluna na Tabela Básica se ela já foi transferida.
Figura 6 – Arquitetura de Tabela Básica com Tabelas de Extensão dinâmicas (SHENGQI; SHIDONG;
LANJU, 2010)
Na Tabela Básica, algumas colunas do tipo VARCHAR são reservadas (inicialmente 60) para armazenar
dados de extensão. Eles também desenvolveram um algoritmo que trabalha em segundo plano durante um
período de tempo pré-determinado que é responsável por transferir os dados de extensão para a tabela básica
e vice-versa. O valor de Count é inicializado com 0, IsInBasic com ‘NO’, e BColumnName com NULL.
21
Durante a transferência, os usuários da aplicação podem consultar os dados normalmente e as atualizações
(operações de update) são manipuladas com cuidado para evitar problemas de consistência. Uma Fórmula
de Avaliação é usada para computar o peso de todas as colunas de extensão dos locatários. A coluna com
maior peso – digamos L – ainda armazenada na tabela de extensão, será transferida para a tabela básica se lá
houver um espaço reservado livre. Senão, o algoritmo procura por uma coluna com peso mínimo – digamos
M – na tabela básica. Se L > M, então primeiramente M é transferido da tabela de extensão para a tabela
básica e em seguida o oposto é feito com L. Caso contrário, nada é feito, segue para a próxima tabela de
extensão.
(HOU; ZHANG; KONG, 2013) propuseram reduzir o tempo de acesso aos dados e o custo para atualizar
as réplicas das bases de dados de aplicações SaaS no modelo multi-locatário. Originalmente, os bancos de
dados na nuvem distribuem aleatoriamente os dados dos locatários em múltiplos nós de dados. O problema
destacado é que essa abordagem afeta o tempo de acesso aos dados, balanceamento de carga dos nós e o
custo para atualizar as réplicas, então eles propõem uma estratégia de posicionamento dos dados baseada em
grafos. A estratégia consiste em uma representação de grafos, uma função de balanceamento e um algoritmo
que executa o balanceamento. O grafo ilustrado na Figura 7 é a representação de um grafo unidirecional
completo, no qual um dado locatário i se conecta a todos os nós e cada borda possui um peso. Os pesos são
estipulados pela função de balanceamento, que leva em consideração os aspectos a seguir.
1. A carga dos vértices, proporcional ao número de nós adjacentes.
2. A distância de dois nós adjacentes na rede.
3. A gravidade da carga de trabalho e distância de rede em avaliação.
4. O tempo de resposta para a requisição de um locatário.
Figura 7 – Balanceamento de nós a partir da representação de grafos (HOU; ZHANG; KONG, 2013)
O algoritmo inicialmente realiza a representação do grafo e então encontra um sub-grafo completo com
quatro nós contendo o vértice do locatário com valor mínimo de soma do peso das bordas. Os dados do
locatário são armazenados no nó com menor peso com o vértice do locatário e os outros dois nós irão receber
as réplicas.
Insatisfeitos com o desempenho das implementações disponíveis do modelo de Tabelas Compartilhadas,
(GORTI; SHIRI; RADHAKRISHNAN, 2013) propõem a implementação de Tabelas Índice, cujas principais
22
metas são diminuir o tempo de processamento e desperdício de espaço. Essa abordagem é semelhante às
outras propostas no que tange à existência de uma tabela básica contendo os dados mais comuns dentre
os locatários e uma coluna TenantID identificando os dados de cada um, todavia, em sua abordagem eles
adicionam uma coluna Índice. Essa nova coluna é inserida na tabela básica e é incrementada automaticamente
a cada linha, ela é definida como UNIQUE e NOT NULL. Além da tabela básica, o modelo também conta
com tabelas de suporte que contem apenas duas colunas: Índice (chave para a tabela básica) e um atributo
específico do locatário. O número de tabelas de suporte crescem de acordo com o número de locatários.
A solução é validada através de experimentos controlados em MySQL e testados contra o modelo Chunk
Tables (AULBACH et al., 2008). Seus resultados mostraram que as Tabelas Índice economizaram espaço por
não precisarem de valores NULL e sua arquitetura simples pôde prover melhor indexação e desempenho de
consultas. Em geral, consultas são processadas mais rápido quando não são necessárias operações join sobre
todas as tabelas de suporte, visto que o número de junções é igual ao número de colunas de suporte.
Sabendo que diversos locatários estão acessando seus recursos simultaneamente nas mesmas tabelas físicas,
esse acesso é na verdade feito através de visões lógicas específicas de cada locatário. Entretanto, soluções
atuais para o gerenciamento de dados na nuvem não foram feitas para o SaaS (), o que dificulta direcionar
com precisão as requisições dos locatários para os seus dados. Frente a esse cenario é que () propõe uma
estrutura de índices multi-camada cujo intento é fornecer melhor desempenho para acessar os dados. A
estrutura é composta por três camadas de índices:
1. Índice de Nó (terceiro nível), responsável por localizar rapidamente o dado de um locatário em um nó.
2. Índice Lógico (segundo nível), responsável pelos dados dos locatários no nível de um único nó. Ele
provê suporte para compartilhamento, personalização e indexação isolada para garantir rápido acesso
ao dado do locatário.
3. Índice Físico (primeiro nível), oferece suporte para rápido acesso aos índices lógicos do locatário.
Os trabalhos dessa seção propõem soluções voltadas para aprimorar o armazenamento de dados na nuvem,
mas limitam-se ao banco de dados da própria aplicação SaaS e não tratam da interoperabilidade entre
aplicação e fontes de dados DaaS.
3.3 Migração de dados
Nesta seção são discutidas soluções e alternativas para problemas relacionados à migração de dados ao
atualizar uma aplicação SaaS no modelo de Tabelas Compartilhadas.
Segundo (ZHOU et al., 2013), a migração do componente de negócios de uma aplicação de único locatário
para multi-locatário é um desafio sobretudo em razão do componente de negócios não relacionado ao locatário
e o acesso global aos dados. Faz-se necessário um meio unificado para acessar e isolar dados não relacionados
ao locatário no modelo multi-locatário. Eles propõem um framework para desenvolvimento de banco de
dados multi-locatário para efetuar o isolamento de dados do componente de negócios a partir de um banco de
dados de memória e outro global. É introduzido um mecanismo de relacionamento de dados para construir
a relação entre os bancos de dados (memória e global) para assegurar a correta execução do componente de
negócios no ambiente SaaS. Os autores realizaram realizaram teste tendo o MySQL como banco de dados
global e o SQLite como memória para um sistema de múltiplos restaurantes.
Em virtude da complexidade da migração de dados, (LIU; WU, 2012) desenvolveu um framework que
habilita a atualização do esquema da base de dados sem migração de dados. Essas atualizações representam
23
mudanças do locatário na modelagem dos dados durante a atualização da aplicação SaaS e ela variam desde
a adição de novas colunas à implantação de regras de normalização. A solução é baseada nos elementos
subsequentes (Figura 8).
1. Descrição da Atualização do Esquema. Essa etapa é usada para descrever informações sobre a
atualização do esquema e é formada por três componentes:
a) Objeto de Atualização, uma representação em formato de objeto da tabela que será atualizada.
b) Tipo de Atualização, informa a operação que será empregada durante a atualização do esquema.
c) Descrição da Atualização, contem os detalhes sobre a tabela e as colunas que estão sendo atualizadas (ou NULL quando é uma operação de deleção).
2. Estratégia de Evolução dos Metadados. Responsável por fazer a evolução dos metadados, essa
etapa utiliza a descrição da atualização gerada na etapa anterior como entrada para criar novos metadados de acordo com o Tipo de Atualização de cada mudança nas tabelas antigas.
3. Mecanismo de dados. É o componente responsável por aproveitar os metadados gerados anteriormente para acessar os dados na tabela. Ele conta com um pré-processador que converte a requisição
SQL da visão lógica para a tabela física.
Figura 8 – Evolução de metadados (LIU; WU, 2012)
Um Modelo de Dados Multi-locatários Misto é proposto por (JIANG et al., 2012) como uma tentativa de
balancear o desempenho do banco de dados e a expectativa dos locatários quanto à redução de custos. Eles
avaliaram os prós e contras dos três principais modelos multi-locatário (Máquina Compartilhada, Instâncias
Compartilhadas e Tabelas Compartilhadas) e propuseram um novo modelo denominado Banco de Dados
Locatário visando superar as desvantagens encontradas nos modelos originais. Juntamente com o modelo eles
provêem o CMMG (sigla para Configurable Multi-tenancy data Model Group) como proposta para migração
de banco de dados uni-locatário. O CMMG é a estrutura capaz de suportar as necessidade de customização
dos dados. Com essa estrutura os autores idealizam um proxy de acesso aos dados que funciona como um
invólucro para assegurar que os dados são migrados apesar das diferenças entre os modelos uni e multilocatário.
24
Os trabalhos dessa seção propõem soluções voltadas para a migração de dados de aplicações SaaS, entretanto, diferentemente da proposta do presente trabalho, não tratam da interoperabilidade com fontes de
dados DaaS.
3.4 Escalabilidade
O propósito maior de (NI et al., 2012) é superar os problemas de baixa escalabilidade, inerentes à abordagem
de Instâncias Compartilhadas, e baixo desempenho, inerente às Tabelas Compartilhadas. Para isso os autores
propõem um método de esboço para esquema de banco de dados adaptativo para aplicações multi-locatário.
O esboço é composto por uma tabela base, contendo atributos importantes, e tabelas suplementares para cada
um dos atributos restantes. Eles definem como atributos comuns aqueles que são altamente compartilhados,
atributos estrela as chaves primárias e todas as demais colunas são consideradas incomuns. Os atributos
importantes da tabela base irão compor atributos estrela, atributos comuns e atributos estrela. Dessa forma,
evita-se junções custosas, visto que muitas tabelas irão usar essas colunas. Atributos dependentes são classificados como incomuns, contudo eles são considerados “leves” em termos de espaço de armazenamento e
“caros” em termos de processamento de consultas, por conseguinte é mais vantagem deixá-los na tabela base.
Os atributos restantes formarão as tabelas suplementares.
O trabalho anterior propõe melhorar a escalabilidade de bancos de dados de aplicações SaaS, contudo
não trata da interoperabilidade com fontes de dados DaaS, como é o caso do presente do presente trabalho.
3.5 Gerenciamento do banco de dados
O foco da pesquisa de (BOYTSOV; SOKOLOV, 2012) é o desenvolvimento de uma solução para organizar
clusters de bancos de dados multi-locatários na nuvem utilizando servidores comuns. A idéia é criar um
sistema complexo que seria implantado como uma camada de abstração entre servidores de aplicação e
servidores de banco de dados (Figura 9). Eles adotam a abordagem de Instâncias Compartilhadas para o
isolamento dos dados a nível de banco de dados em prol de alcançar maior generalidade, visto que o modelo
de Tabelas Compartilhadas requer mais conhecimento sobre os dados dos locatários. A seguir, uma lista dos
componentes fundamentais do sistema proposto.
1. Um servidor dedicado, responsável por direcionar as consultas ao servidor de dados certo o mais rápido
possível.
2. Um servidor de gerenciamento de replicação e cópia de segurança.
3. Um conjunto de serviços-agente colocados nos servidores de dados para coletar estatísticas sobre a carga
do servidor e montar seu estado em caso de falha.
4. Um servidor de distribuição de dados e balanceamento de carga, o núcleo de gerenciamento da solução.
Ele está no controle de coletar estatísticas de uso do sistema, geração de relatórios, gerenciamento do
servidor de replicação e efetuar a distribuição inicial dos dados dos locatários entre os servidores, além
de outras tarefas.
O trabalho anterior, embora relacionado ao gerenciamento de bancos de dados na nuvem, não trata da
interoperabilidade entre aplicações SaaS e fontes de dados DaaS, como é o caso do presente do presente
trabalho.
25
Figura 9 – Gerenciamento de clusters (BOYTSOV; SOKOLOV, 2012)
3.6 SGBDR (Sistema de Gerenciamento de Banco de Dados Relacional)
Em visão do problema de dispersão dos dados inerente ao modelo de Tabelas Compartilhadas e o seu precário
sistema de indexação, o trabalho desenvolvido por (HUI et al., 2009) implementa um sistema de banco de
dados multi-locatário que pretende aperfeiçoar os serviços de armazenamento e indexação para aplicações
na nuvem. A ferramenta, nomeada M-Store, foi desenvolvida a partir do MySQL e faz uso de duas técnicas
especiais para atingir maior escalabilidade e oferecimento dos serviços: Bitmap Interpreted Tuple (BIT) e
Multi-Separated Index (MSI).
BIT é a técnica usada para solucionar o desperdício de espaço e o baixo desempenho de consultas, inerentes
às Tabelas Compartilhadas. Ela consiste de duas fases:
1. Primeiro, uma string bitmap é construída para cada locatário, ela decodifica quais atributos são utilizados e quais não são.
2. Segundo, tuplas são armazenadas e recuperadas de acordo com a string bitmap de cada locatário.
O MSI constrói um índice para cada locatário ao invés de um para todos. À primeira vista, isso poderia
levar a um enorme número de índices, crescendo ao passo do número de locatários. Entretanto, o que
acontece é que o número de índices não cresce tanto porque apenas uma fração do total de locatários irá de
fato construir um índice em um atributo específico, não um índice para cada atributo.
Assim como no presente trabalho, o artigo anterior também trata dos dados na nuvem, todavia não aborda
a interoperabilidade entre aplicações SaaS e fontes de dados DaaS.
De modo geral, todos as propostas relacionadas se preocupam com a maneira como aplicações SaaS
obtêm os dados na nuvem, visando melhor desempenho e eficiência. Um ponto fundamental que difere essas
propostas do presente trabalho é que nenhuma delas lida com a comunicação entre aplicação e fontes de
dados externas, como provedores de DaaS.
4 Proposta
O presente trabalho propõe um middleware para que aplicações hospedadas em um provedor de Software
como um Serviço possam operar não apenas com suas próprias bases de dados, mas também com dados de
fontes externas com pouco esforço adicional. Esse middleware é denominado MIDAS e se compromete a
estabelecer uma comunicação transparente entre provedores de SaaS e de Dados como Serviço (DaaS).
Atualmente, as maneiras de se integrar os serviços de SaaS e DaaS são ineficientes, visto que são manuais.
São elas:
• Adquirir um conjunto de dados de um provedor de DaaS e preencher o banco de dados da aplicação
manualmente.
• Acessar a API fornecida pelo provedor diretamente da aplicação, o que exige conhecimento da API do
DaaS.
A idéia é manter as nuvens integradas como uma rede de energia elétrica, em que um dispositivo pode
ser plugado à energia sem que precise saber qual a fonte (hidroelétrica, eólica, solar). Sendo assim, os
provedores de SaaS não precisam adaptar suas aplicações. Por exemplo, normalmente uma aplicação monta
uma solicitação de dados para os seus servidores de banco de dados e recebe em resposta um conjunto de
dados para formatar e dispor na tela para os seus usuários. Agora, a única mudança envolvida é que a
aplicação irá mandar a mesma consulta para o MIDAS e ele será responsável por recuperar os dados do
provedor de DaaS e retorná-los no formato esperado pela aplicação.
O MIDAS, representado pelo modelo da Figura 10 e diagrama de sequência da Figura 11, contém dois
módulos: o Módulo de Requisição (Request Module) e o Módulo de Resposta (Result Module). Como os
próprios nomes já sugerem, o Módulo de Requisição lida com as requisições enviadas pela aplicação SaaS,
enquanto que o Módulo de Resposta lida com a resposta do DaaS.
Este trabalho propõe o funcionamento do Módulo de Requisição do middleware. O Módulo de Resposta
(em cinza na figura) é proposto em (CIDREIRA, 2015). Logo, as próximas seções explanam em mais detalhes
o papel do provedor de SaaS e os componentes do Módulo de Requisição.
4.1 Aplicação SaaS
À medida que um usuário interage com a aplicação SaaS, algumas páginas irão dispor os dados em forma de
listas, tabelas ou parágrafos, por exemplo. Para o usuário, como o sistema recuperou aqueles dados não tem
importância desde que sua navegação não seja comprometida. É o que acontece quando o sistema realiza
as consultas ao seu banco de dados e é o que deve continuar acontecendo após a inserção do MIDAS nesse
cenário. O usuário não deve sofrer com os detalhes de implementação do sistema nem esperar mais do que o
necessário para visualizar a informação desejada em tela.
4.2 Módulo de Requisição do MIDAS
Constituído pelos componentes Decompositor de Consulta (Query Decomposer ) e Construtor de Consulta
(Query Builder ), esse módulo é responsável por receber a consulta enviada pela aplicação SaaS e transmitir
para o provedor de DaaS. Cada componente é explicado em detalhes nos subtópicos a seguir.
28
Figura 10 – Middleware MIDAS
Figura 11 – Diagrama de sequência completo do middleware MIDAS
29
4.2.1 Decompositor de Consulta
Esse é o componente que recebe a consulta da aplicação exatamente como ela é enviada, originalmente na
linguagem do banco de dados usado pelo SaaS. Sua função é decompor essa consulta em um formato chavevalor independente. Esse novo formato irá garantir que o Construtor de Consulta seja capaz de construir a
requisição do DaaS, independentemente da API que o provedor esteja utilizando.
O processo de decomposição ocorre através de uma função que é capaz de identificar a sintaxe da linguagem
de banco de dados da consulta e mapear cada cláusula encontrada com seus respectivos valores para um vetor
independente. Por exemplo, para a consulta SQL a seguir:
SELECT nome , idade FROM dataset - pessoas
O Decompositor de Consulta indentifica os atributos ‘nome’ e ‘idade’ como os campos que estão sendo
buscados e os coloca em um vetor ‘ConsultaDecomposta’ sob a chave ‘campos’. Já o ‘dataset-pessoas’ é
entendido como o local onde buscar os dados. Como o objetivo é transformar a consulta em uma requisição
para uma fonte de dados DaaS, o conteúdo do FROM é colocado no vetor sob a chave ‘dataset’, representando
o identificador do conjunto de dados do provedor de DaaS. Por fim, o vetor tem o seguinte formato:
Co ns ul taDecomposta = [ ‘ campos ’ = > ‘ nome , idade ’ , ‘ dataset ’ = > ‘ dataset - pessoas ’]
4.2.2 Construtor de Consulta
Com a consulta decomposta, o Módulo de Requisição prossegue com o processo de transformar a consulta
do SaaS em uma requisição DaaS válida. Para isso, o MIDAS conta com uma base de dados local (Dataset
Information Storage, explicado em (CIDREIRA, 2015)) que contém todas as informações relevantes sobre o
provedor DaaS de destino, incluindo domínio e parâmetros da API. Conforme visto anteriormente, a consulta
original contém o identificador do conjunto de dados DaaS, a partir dele é possível localizar os demais dados do
provedor. Com essas informações, o Construtor de Consulta consegue associar cada chave/valor encontrado
no vetor gerado pelo Decompositor de Consulta com os parâmetros que compõem a API do DaaS.
Primeiramente, o Construtor de Consulta recebe dois parâmetros de entrada: a consulta do SaaS decomposta e outro vetor contendo os dados da API do DaaS.
Após, o componente começa a concatenar os pedaços de informação na ordem correta. O endereço URL
do provedor DaaS é o primeiro passo para que se possa localizar os dados no domínio do provedor através da
internet. Por exemplo:
http :// www . dominiododaas . com . br
Em seguida, é adicionado ao final desse endereço o caminho para a API. Neste exemplo, o caminho é
‘api/’.
http :// www . dominiododaas . com . br / api /
Dessa forma, já é possível acessar a API do DaaS, porém nenhuma busca está sendo feita ainda. Então
são usados os valores da consulta decomposta para montar os parâmetros da busca. Esses, por sua vez,
possuem o formato ‘?chave1=valor1&chave2=valor2&...chaveN=valorN’. Supondo que a API utiliza o
30
termo ‘dataset’ para indicar o identificador do conjunto de dados e o termo ‘query’ para indicar os campos
a serem buscados, esses termos são concatenados ao final da requisição juntamente com os seus respectivos
valores, contidos no vetor da consulta. Dessa forma, obtém-se a requisição DaaS completa:
http :// www . dominiododaas . com . br / api /? dataset = dataset - pessoas & query = nome , idade
Detalhes de formação da URL, como transformação de caracteres especiais, foram suprimidos a fim de
facilitar o entendimento do exemplo.
5 Validação
As alternativas oferecidas pelo mercado para oferecer interoperabilidade entre serviços na nuvem limitam-se ao
fornecimento de modalidades diferentes dentro da mesma nuvem. A Amazon (AMAZON WEB SERVICES,
INC., 2015), por exemplo, é uma empresa referência no ramo de serviços na nuvem. Ela fornece serviços de
infraestrutura, plataforma e banco de dados, além de outras modalidades. Embora a integração entre os seus
serviços exista, ela não se estende para serviços de terceiros.
Tendo em vista esse desafio, o presente trabalho valida a proposta do middleware de três maneiras:
1. Implementação de um protótipo funcional do MIDAS.
2. Elaboração de estudo de caso demonstrando o estabelecimento de uma comunicação transparente entre
aplicação e dados oriundos de nuvens distintas.
3. Realização de análise de eficiência do protótipo, avaliando seu comportamento com relação ao tempo
em comparação com as mesmas consultas sendo realizadas diretamente nos provedores de DaaS.
5.1 Estudo de caso
O objetivo deste estudo de caso é demonstrar o funcionamento do middleware proposto através da introdução
de uma agência de turismo fictícia que deseja hospedar sua aplicação no ambiente de Software como Serviço
(SaaS) da Red Hat, o OpenShift (RED HAT, INC., 2015). Embora o provedor da nuvem ofereça armazenamento MySQL, o interesse da empresa é agregar dados de diferentes provedores de Dados como Serviço
(DaaS) à sua aplicação.
O atual protótipo do MIDAS compreende apenas consultas SQL, especificamente do SGBD MySQL.
Inicialmente, os comandos aceitos são ‘SELECT’, ‘FROM’, ‘WHERE’, ‘ORDER BY’ e ‘LIMIT’. Dentro do
‘SELECT’ também é possível utilizar a expressão ‘*’, informando que todas as colunas deverão ser retornadas.
Em função de demonstrar que uma mesma aplicação pode consultar diferentes provedores de DaaS, este estudo
mostra o funcionamento de duas seções da aplicação:
• A primeira seção exibe uma lista de pontos de Wi-Fi na região metropolitana da Cidade de Nova York,
cujos dados são fornecidos pelo serviço público de DaaS da OpenDataSoft (OPENDATASOFT, 2015).
• A segunda exibe uma lista de hotéis da Cidade de Nova York obtida no portal de dados abertos da
cidade (THE CITY OF NEW YORK, 2015).
A aplicação conta com interface simples, utilizando HTML5, CSS e JavaScript no lado cliente, PHP 5.4 no
lado servidor e banco de dados MySQL 5.5. Adicionalmente, Bootstrap (BOOTSTRAP, 2015) e jQuery (THE
JQUERY FOUNDATION, 2015) também foram utilizados, além do framework CodeIgniter 2 (ELLISLAB,
2015), auxiliando a programação PHP. A seguir, é detalhado o funcionamento de cada uma das seções da
aplicação.
32
5.1.1 Pontos de Wi-Fi em Nova York
Para melhor representar o cenário, considere durante o resto desta seção que o código da Listagem 5.1 é a
consulta SaaS original, ilustrada no modelo do MIDAS da Figura 10 como Query request.
1
SELECT id , name , address , city
2
FROM nyc - wifi - hotspot - locations
3
WHERE city = ‘ New York ’
4
ORDER BY id
5
LIMIT 10
Listagem 5.1 – Busca por pontos de Wi-Fi em Nova York
A consulta original é obtida através da interação do usuário com a aplicação e é passada como parâmetro
para a função _query_decomposer (Listagem 5.2), que representa a implementação do componente Decompositor de Consulta (ilustrado no modelo do MIDAS da Figura 10 como Query Decomposer ). Na linha 2 da
Listagem 5.2, possíveis espaços no início e no fim da consulta são removidos e todos os caracteres convertidos
para letra minúscula. Um vetor de nome $indexes é criado e preenchido com o índice da primeira posição de
cada termo MySQL presente na consulta (linhas 4 a 7 da Listagem 5.2). A posição do ‘SELECT’ é assumida
como 0 (zero), posto que ele deve obrigatoriamente iniciar a consulta.
1
private function _query_decomposer ( $query ) {
$sql = strtolower ( trim ( $query ) ) ;
2
3
4
$indexes [] = strpos ( $sql , " from " ) ;
5
$indexes [] = strpos ( $sql , " where " ) ;
6
$indexes [] = strpos ( $sql , " order by " ) ;
7
$indexes [] = strpos ( $sql , " limit " ) ;
8
$jsonArray [ " fields " ] = $this - > _getFields ( $sql , $indexes [0] -6) ;
9
10
$jsonArray [ " dataset " ] = $this - > _getDataset ( $sql , $indexes [0]+4 , $indexes , 1) ;
11
$jsonArray [ " filters " ] = $indexes [1] === false ? false : $this - > _getFilters ( $sql ,
12
$jsonArray [ " order " ] = $indexes [2] === false ? false : $this - > _getOrder ( $sql ,
13
$jsonArray [ " limit " ] = $indexes [3] === false ? false : $this - > _getLimit ( $sql ,
$indexes [1]+5 , $indexes , 2) ;
$indexes [2]+8 , $indexes , 3) ;
$indexes [3]+5) ;
14
return $jsonArray ;
15
16
}
Listagem 5.2 – Função _query_decomposer
Em seguida a função salva as colunas da consulta – aquelas entre o ‘SELECT’ e o ‘FROM’ – dentro do
vetor $jsonArray na posição ‘fields’ (linha 9). A chave ‘dataset’ do vetor $jsonArray guarda o valor passado
no ‘FROM’ (linha 10). Nesse caso, ao invés de informar o nome da tabela no banco de dados relacional, o
‘FROM’ conterá o nome identificador do conjunto de dados do DaaS. Isso significa que a aplicação SaaS está
33
consultando o conjunto de dados externo da mesma forma que faria com o próprio banco de dados. A chave
‘filters’ mapeia o valor do ‘WHERE’ (linha 11); ‘order ’, o valor do ‘ORDER BY’ (linha 12); e ‘limit’, o valor
do ‘LIMIT’ (linha 13).
Agora que o vetor independente foi obtido, o próximo passo é executar a função _query_builder (Listagem 5.3), que representa a implementação do componente Construtor de Consulta (ilustrado no modelo do
MIDAS da Figura 10 como Query Builder ). A função possui dois parâmetros: $api_params e $values.
1
private function _query_builder ( $api_params , $values ) {
2
$daas_request
3
$daas_request .= $api_params [ " search_path " ];
= $api_params [ " domain " ];
4
if ( $api_params [ " dataset_param " ] !== null ) {
5
$daas_request .= " ? " . $api_params [ " dataset_param " ]. " = " . $values [ " dataset " ];
6
} else {
7
$daas_request .= $values [ " dataset " ];
8
}
9
10
if ( $values [ " filters " ]) {
11
if ( strpos ( $daas_request , " ? " ) !== false ) {
12
$daas_request .= " & " . $api_params [ " query_param " ]. " = " . $values [ " filters " ];
13
} else {
14
$daas_request .= " ? " . $api_params [ " query_param " ]. " = " . $values [ " filters " ];
15
}
16
}
17
18
if ( $values [ " order " ]) {
19
if ( strpos ( $daas_request , " ? " ) !== false ) {
20
$daas_request .= " & " . $api_params [ " sort_param " ]. " = " . $values [ " order " ];
21
} else {
22
$daas_request .= " ? " . $api_params [ " sort_param " ]. " = " . $values [ " order " ];
23
}
24
}
25
26
if ( $values [ " limit " ]) {
27
if ( strpos ( $daas_request , " ? " ) !== false ) {
28
$daas_request .= " & " . $api_params [ " limit_param " ]. " = " . $values [ " limit " ];
29
} else {
30
$daas_request .= " ? " . $api_params [ " limit_param " ]. " = " . $values [ " limit " ];
31
}
32
}
33
34
return $daas_request ;
35
36
}
Listagem 5.3 – Função _query_builder
$api_params é um vetor que contém o domínio do provedor do serviço de DaaS, o caminho da API e
34
os demais parâmetros que irão compor a requisição DaaS. Esses dados são obtidos a partir a interação com
o armazenamento de informações do DaaS (Dataset Information Storage, em cinza no modelo do MIDAS
da Figura 10). O parâmetro $values é exatamente o vetor resultado da função _query_decomposer e
irá preencher as chaves da requisição com os valores presentes na consulta original. Ou seja, o papel da
função _query_builder é montar a requisição DaaS a partir dos parâmetros da API e os valores do vetor
independente.
Primeiramente a função concatena o domínio do provedor e o caminho para a API dos dados nas linhas
2 e 3. Em seguida (linhas 5-9), é verificado se a API lê o identificador do conjunto de dados com parâmentro
(logo, após a ‘ ?’) ou como parte do endereço, após o caminho da API. Sabendo que a consulta pode conter ou
não filtros, ordenação e limite de resultados, a função verifica a existência dos respectivos valores na consulta
(linhas 11-17, 19-25 e 27-33).
Depois de processada pelo Módulo de Requisição (representado no modelo do MIDAS da Figura 10 como
o Request Module), a consulta original é transformada na requisição DaaS a seguir:
http :// public . opendatasoft . com / api / records /1.0/ search ? dataset = nyc - wifi - hotspot locations & q = city +%3 D + ‘ New + York ’& rows =10& sort = id
A sequência de ações deste estudo de caso é exposta no diagrama de sequência da Figura 12. Uma vez
que a requisição é enviada, os passos seguintes, referentes ao processamento realizado na nuvem do DaaS
e retorno para o Módulo de Resposta, fogem do escopo deste trabalho. Entretanto, a Listagem 5.4 traz a
demonstração de uma linha de resultado para a consulta original em formato JSON, contendo tanto chaves
numéricas (0, 1, 2. . . ) quanto associativas (A, B, C. . . ). Esse é o formato padrão de resposta do driver
MySQL do PHP.
Figura 12 – Diagrama de sequência do estudo de caso
[{"0":" New York " ," city ":" New York " ,"1":" Metropolitan Museum of Art " ," name ":"
Metropolitan Museum of Art " ,"2":"1000 Fifth Avenue " ," address ":"1000 Fifth
Avenue " ,"3":1359 ," id ":1359}]
Listagem 5.4 – Primeira linha do resultado da busca pelos pontos de Wi-Fi
35
5.1.2 Hotéis em Nova York
A aplicação também permite que o usuário pesquise hotéis na cidade de Nova York. Os dados dos hotéis
são obtidos do serviço público de DaaS da própria cidade. Para esta seção, a consulta da Listagem 5.5
representa uma busca pelos hotéis de Nova York. São pesquisados o nome do hotel (company_name), telefone
(phone) e website. O resultado deve se limitar a 10 itens e ser ordenado pelo nome da empresa. O mais
interessante nessa pesquisa é observar que os dados nesse provedor de DaaS advém de um arquivo JSON
(linha 2), entretanto esta peculiaridade em nada interfere com o funcionamento do middleware.
1
SELECT company_name , phone , website
2
FROM v8qe - fx6p . json
3
ORDER BY company_name
4
LIMIT 10
Listagem 5.5 – Busca por hotéis em Nova York
Assim como na seção anterior, a consulta atual também passa pelos procedimentos de quebra de consulta
e construção da requisição DaaS, representados respectivamente pelas funções _query_decomposer (Listagem
5.2) e _query_builder (Listagem 5.3). Como produto, o MIDAS gera a seguinte requisição:
http :// data . cityofnewyork . us / resource / v8qe - fx6p . json ? $order = company_name & $limit =10
Outra novidade desse novo provedor é que ele trata o identificador do conjunto de dados como parte do
caminho da requisição e não como parâmetro da busca, como na última seção. Não obstante, esse cenário
é previsto e tratado pela função _query_builder, conforme já explicado e demonstrado pela Listagem 5.3.
Uma amostra do resultado do MIDAS é ilustrado a seguir pela Listagem 5.6.
[{"0":"(212) 645 -5700" ," phone ":"(212) 645 -5700" ,"1":" www . stayaka . com " ," website ":"
www . stayaka . com " ,"2":" AKA " ," company_name ":" AKA "}
Listagem 5.6 – Primeira linha do resultado da busca pelos hotéis em Nova York
5.2 Desempenho
A análise de eficiência do middleware foi realizada comparando-se os tempos de resposta obtidos buscando-se
os dados a partir da aplicação da agência de turismo e diretamente no provedor de DaaS. A ferramenta
online Hurl.it (RUNSCOPE, INC., 2015) foi empregada para efetuar a medição dos tempos. As Tabelas 1
e 2 apresentam os valores de média, variância e desvio padrão dos tempos observados para cada seção da
aplicação. No total, foram coletadas 40 amostras dos tempos de resposta. 20 partindo da aplicação e 20
enviando a solicitação diretamente para a API do DaaS.
Tabela 1 – Análise dos tempos de resposta para a consulta de hotéis
Partindo da aplicação SaaS
Diretamente na API do DaaS
Média (ms)
270,2
174,8
Variância (ms)
253,76
221,56
Desvio padrão (ms)
15,93
14,88
36
Tabela 2 – Análise dos tempos de resposta para a consulta de pontos de Wi-Fi
Partindo da aplicação SaaS
Diretamente na API do DaaS
Média (ms)
425,1
329,1
Variância (ms)
282,69
333,49
Desvio padrão (ms)
16,81
18,26
A partir desses resultados pode-se notar que a diferença entre as médias dos tempos de resposta para a
consulta de hotéis foi de 95.4ms, o que representa um acréscimo de aproximadamente 55%. Para a consulta
de pontos de Wi-Fi foi notado um acréscimo de 96ms no tempo de resposta, o que representa um aumento de
29%. Esses acréscimos de tempo correspondem ao processamento do middleware, que durou quase o mesmo
tempo em ambos os cenários, todavia representa uma porcentagem de aumento diferente para cada provedor.
Uma vez que é possível o intercâmbio de informação entre provedores de nuvens diferentes, abre-se a
porta para uma nova gama de serviços que podem contemplar muito mais clientes e usuários. No caso de
uma agência de turismo, cada seção da aplicação poderia possuir fontes de dados especializadas no conteúdo
exibido. As seções de pontos de Wi-Fi e hotéis na cidade são algumas das muitas opções. Poderiam haver
seções de restaurantes, parques, shoppings, museus e muito mais. E cada um desses conjuntos de dados estaria
sendo oferecido por provedores cujo trabalho é a manutenção daquela informação, muitas vezes instituições
especialistas ou setores governamentais. Consequentemente, nesse novo cenário, o idealizador da aplicação
não precisará manter todo esse conteúdo, cada qual seria atualizado e mantido pelo seu respectivo provedor.
Cabe ao fornecedor da aplicação selecionar fontes de dados confiáveis para se certificar de que as informações
serão atuais e precisas. Além disso, o banco de dados da aplicação não é descartado. Logo, a aplicação não
é privada de forma alguma de oferecer conteúdo próprio exclusivo.
5.3 Ameaças para a validação
Enquanto não existe uma solução padrão adotada pelos provedores de DaaS que permita a identificação automática da sua configuração, o bom funcionamento do middleware depende de uma administração adequada.
Possíveis mudanças na API do DaaS precisam ser refletidas imediatamente no MIDAS, assim como alterações
no domínio do provedor ou caminho da API.
Outro fator que pode interferir com o funcionamento do middleware é a tentativa de integrar um provedor que utilize alguma API não compatível com os casos previstos atualmente, podendo demandar alguma
eventual adaptação no código do MIDAS.
6 Conclusão
Neste trabalho, é proposto um middleware chamado MIDAS que habilita a interoperabilidade entre os serviços
de nuvem de Software como Serviço (SaaS) e Dados como Serviço (DaaS). Com o MIDAS, aplicações SaaS
podem consultar conjuntos de dados de serviços de DaaS de forma transparente e independentemente de
provedor, como se estivessem consultando o próprio banco de dados. Resultados mostraram que o middleware
é capaz de entregar a resposta esperada pela aplicação sem comprometer a navegação do usuário com longos
tempos de espera.
6.1 Dificuldades encontradas
A grande maioria dos serviços de nuvem disponíveis no mercado é paga e costuma exigir o cadastro de cartão
de crédito internacional mesmo para a utilização do período de testes.
6.2 Trabalhos futuros
Como trabalhos futuros, ficam alguns quesitos importantes para a complementação deste trabalho:
1. Oferecimento de suporte mais robusto para consultas na linguagem MySQL.
2. Demonstração de funcionamento do middleware abrangendo autenticação em domínios protegidos.
3. Elaboração de novo estudo de caso demonstrando o funcionamento do middleware para o caso de
aplicações com banco de dados não relacional.
Referências
AHRONOVITZ, M. et al. Cloud computing use cases white paper. [S.l.]: Version, 2010.
AMAZON WEB SERVICES, INC. Amazon Web Services (AWS) - Cloud Computing Services. 2015.
Disponível em: <http://aws.amazon.com>. Acesso em: 27 de Outubro de 2015.
ASUNCION, C. H.; SINDEREN, M. J. V. Pragmatic interoperability: A systematic review of published
definitions. In: Enterprise Architecture, Integration and Interoperability. [S.l.]: Springer, 2010. p. 164–175.
AULBACH, S. et al. Multi-tenant databases for software as a service: schema-mapping techniques. In:
ACM. Proceedings of the 2008 ACM SIGMOD international conference on Management of data. [S.l.], 2008.
p. 1195–1206.
BEZEMER, C.-P. et al. Enabling multi-tenancy: An industrial experience report. In: IEEE. Software
Maintenance (ICSM), 2010 IEEE International Conference on. [S.l.], 2010. p. 1–8.
BOOTSTRAP. Bootstrap. The world’s most popular mobile-first and responsive front-end framework. 2015.
Disponível em: <http://getbootstrap.com>. Acesso em: 27 de Outubro de 2015.
BOYTSOV, E.; SOKOLOV, V. Multi-tenant database clusters for saas. Proceedings of BMSD, p. 144, 2012.
BRUNEO, D.; PULIAFITO, A.; SCARPA, M. Mobile Middleware: definition and motivations. The
Handbook of Mobile Middleware, Auerbach Pub, p. 145–167, 2007.
BUYYA, R.; YEO, C. S.; VENUGOPAL, S. Market-oriented cloud computing: Vision, hype, and reality for
delivering it services as computing utilities. In: IEEE. High Performance Computing and Communications,
2008. HPCC’08. 10th IEEE International Conference on. [S.l.], 2008. p. 5–13.
CIDREIRA, V. Midas: Um middleware para prover interoperabilidade entre DaaS e SaaS. Monografia
(Graduação) - Universidade Federal da Bahia. 2015.
DUAN, Y. Value modeling and calculation for everything as a service (XaaS) based on reuse. In: IEEE.
Software Engineering, Artificial Intelligence, Networking and Parallel & Distributed Computing (SNPD),
2012 13th ACIS International Conference on. [S.l.], 2012. p. 162–167.
ELLISLAB. CodeIgniter Web Framework. 2015. Disponível em: <https://codeigniter.com>. Acesso em: 27
de Outubro de 2015.
FOX, A. et al. Above the clouds: A berkeley view of cloud computing. Dept. Electrical Eng. and Comput.
Sciences, University of California, Berkeley, Rep. UCB/EECS, v. 28, p. 13, 2009.
GORTI, I.; SHIRI, N.; RADHAKRISHNAN, T. A flexible data model for multi-tenant databases for software
as a service. In: IEEE. Computational Science and Engineering (CSE), 2013 IEEE 16th International
Conference on. [S.l.], 2013. p. 1059–1066.
HOU, D.; ZHANG, S.; KONG, L. Placement of saas cloud data and dynamically access scheduling strategy.
In: IEEE. Computer Science & Education (ICCSE), 2013 8th International Conference on. [S.l.], 2013. p.
834–838.
HUI, M. et al. Supporting database applications as a service. In: IEEE. Data Engineering, 2009. ICDE’09.
IEEE 25th International Conference on. [S.l.], 2009. p. 832–843.
JACOBS, D.; AULBACH, S. et al. Ruminations on multi-tenant databases. In: BTW. [S.l.: s.n.], 2007.
v. 103, p. 514–521.
JIANG, L. et al. A mixed multi-tenancy data model and its migration approach for the saas application. In:
IEEE. Services Computing Conference (APSCC), 2012 IEEE Asia-Pacific. [S.l.], 2012. p. 295–300.
40
LIU, H.; WU, S. Data storage schema upgrade via metadata evolution in saas. In: IEEE. Consumer
Electronics, Communications and Networks (CECNet), 2012 2nd International Conference on. [S.l.], 2012.
p. 3148–3151.
LOUTAS, N. et al. Cloud computing interoperability: the state of play. In: IEEE. Cloud Computing
Technology and Science (CloudCom), 2011 IEEE Third International Conference on. [S.l.], 2011. p. 752–757.
MELL, P.; GRANCE, T. The nist definition of cloud computing. Computer Security Division, Information
Technology Laboratory, National Institute of Standards and Technology Gaithersburg, 2011.
NI, J. et al. Adapt: adaptive database schema design for multi-tenant applications. In: ACM. Proceedings
of the 21st ACM international conference on Information and knowledge management. [S.l.], 2012. p.
2199–2203.
OPENDATASOFT. OpenDataSoft. 2015. Disponível em: <http://public.opendatasoft.com/explore/>.
Acesso em: 11 de Setembro de 2015.
ORACLE. Fusion Middleware Concepts Guide. 2015. Disponível em: <http://docs.oracle.com/cd/E21764_
01/core.1111/e10103/intro.htm#ASCON109>. Acesso em: 24 de Novembro de 2015.
POKRAEV, S. V. Model-driven semantic integration of service-oriented applications. Novay, 2009.
RANABAHU, A. H.; MAXIMILIEN, E. M. A best practice model for cloud middleware systems. 2009.
RED HAT, INC. OpenShift by Red Hat. 2015. Disponível em: <https://www.openshift.com>. Acesso em:
11 de Setembro de 2015.
RUNSCOPE, INC. Hurl.it - Make HTTP Requests. 2015. Disponível em: <https://www.hurl.it>. Acesso
em: 11 de Setembro de 2015.
SHENGQI, W.; SHIDONG, Z.; LANJU, K. A dynamic data storage architecture for saas. In: IEEE.
Multimedia Information Networking and Security (MINES), 2010 International Conference on. [S.l.], 2010.
p. 292–296.
THE CITY OF NEW YORK. NYC Open Data. 2015. Disponível em: <https://nycopendata.socrata.com>.
Acesso em: 11 de Setembro de 2015.
THE JQUERY FOUNDATION. jQuery. 2015. Disponível em: <http://jquery.com>. Acesso em: 27 de
Outubro de 2015.
WEILIANG, C.; SHIDONG, Z.; LANJU, K. A multiple sparse tables approach for multi-tenant data storage
in saas. In: IEEE. Industrial and Information Systems (IIS), 2010 2nd International Conference on. [S.l.],
2010. v. 1, p. 413–416.
XU, X. From cloud computing to cloud manufacturing. Robotics and computer-integrated manufacturing,
Elsevier, v. 28, n. 1, p. 75–86, 2012.
XUXU, Z.; QINGZHONG, L.; LANJU, K. A data storage architecture supporting multi-level customization
for saas. In: IEEE. Web Information Systems and Applications Conference (WISA), 2010 7th. [S.l.], 2010.
p. 106–109.
ZHOU, M. et al. Services in the cloud computing era: A survey. In: IEEE. Universal Communication
Symposium (IUCS), 2010 4th International. [S.l.], 2010. p. 40–46.
ZHOU, X. et al. Suitable database development framework for business component migration in saas
multi-tenant model. In: IEEE. Service Sciences (ICSS), 2013 International Conference on. [S.l.], 2013. p.
90–95.