“Desenvolvimento de aplicações multi-tenancy: um estudo de mapeamento sistemático”

Por

Josino Rodrigues Neto
Dissertação de Mestrado

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br

www.cin.ufpe.br/~posgraduacao

RECIFE, Junho/2012

Universidade Federal de Pernambuco Centro de Informática Pós-graduação em Ciência da Computação

Josino Rodrigues Neto

“Desenvolvimento de aplicações multi-tenancy: um estudo de mapeamento sistemático”

Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.

Orientador: Silvio Romero de Lemos Meira Co-Orientador: Vinicius Cardoso Garcia

RECIFE, Junho/2012

Eu dedico essa dissertação primeiramente à minha família, aos meus amigos e aos meus professores que me deram todo o suporte necessário para chegar até aqui. Em especial agradeço a Deus por ter colocado todas essas pessoas no meu caminho.

Agradecimentos

Agradeço a Deus, por ter me dado uma família linda. À minha esposa , Késia(in memorian) por ter me incentivado a continuar mesmo quando eu pensava que nada iria dar certo. À minha filha Sara, que aprendeu a usar o skype sozinha pra conseguir conversar comigo enquanto trabalhava na minha dissertação. À minha mãe, Dona Susana que me apoiou no momento mais difícil da minha vida e que sempre esteve ao meu lado. Aos meus amigos Carlos Portela, Brunno Wagner e Andreza Leite pela madrugadas em claro estudando e fazendo trabalhos das disciplinas(as SCRUMadrugadas). Isso deu resultado, tivemos conceito A em todas as disciplinas amigos. Minha amiga Andreza Leite também foi muito útil nas revisões da minha dissertação, deu contribuições de precisão cirúrgia ao meu trabalho. Ao meu amigo Wilton, que embora tenha pago algumas cadeiras comigo eu só conheci de verdade quando descobri que ele dividia apartamento com meu melhor amigo piauiense residente em Recife, Julio Damasceno. Julio Damasceno diga-se de passagem, um nerd++ com o qual eu tive a oportunidade de trabalhar por muitos anos e aprender tudo que sei sobre Linux. A todos os outros amigos que conheci no mestrado e com os quais eu aprendi diversas coisas diferentes: Kadna, Thalita, Danielle, Fish, Elaine, Emanuel e Viviane(Vivi). Agradeço também por todos os meus amigos da Rise: Marinho, Rafael, Leonardo, Alexandro, Luiz e em especial Eduardo Cruz por terem me proporcionado bons momentos de aprendizado na incubadora do Porto Digital, ajudando na implementação prática da minha dissertação. Gostaria de agradecer aos meus amigos da FJB(Força Jovem Brasil), aos que são piauienses(Jezlia Resende, Ângela Núbia, Eulálio Pereira e Amanda Patricia) e aos que são pernambucanos(aqui não vou citar nomes porque são muitos). Todo essas pessoas foram um suporte pra mim nas horas vagas. Era com eles que eu realizava as atividades filantrópicas que me fizeram crescer como ser humano. Dentre esses gostaria de agradecer especialmente à Dra Jezlia Resende por ter revisado alguns trechos da minha dissertação e ajudado corrigir alguns detalhes do português. Por fim, mas não mais importante queria agradecer aos meus mestres e orientadores Silvio Meira, Vinícius Garcia e Paulo Anselmo por terem me ajudado a organizar minhas idéias em uma dissertação e transforma-las em ciência de verdade. Muito Obrigado a todos.

iv

Eu vou marcar a minha geração Vou conquistar a minha posição Se eu acreditar no sonho Vou realizar Chegou a minha vez Não vou ter medo de tentar Eu sei, quem sabe faz a hora É hora de lutar. —SONOROS (Força Jovem Brasil)

Resumo

De forma crescente, Software como serviço (SaaS) está se tornando uma forma dominante de entrega de software aos usuários. Da perspectiva dos provedores de serviço, os benefícios de SaaS mostram-se através da economia de escala, pela oferta de software a um grande número de consumidores através de uma instância compartilhada de software. Uma forma de implementar SaaS é através da adoção de multi-tenancy, uma abordagem para a implementação de SaaS que divide a instância de uma aplicação em várias aplicações virtuais chamadas tenants. Para prover software desse tipo é necessário levar em consideração vários aspectos como segurança, alocação de recursos, customização, escalabilidade, armazenamento de dados, reuso, etc. Esse trabalho visa, apartir de um mapeamento sistemático, identificar o estado da arte de multi-tenancy, propostas de implementação e principais lacunas existentes nessa área através da análise dos principais trabalhos publicados sobre o assunto. Ao final desse trabalho é apresentado aplicação desses conceitos na indústria.

vi

Abstract

Increasingly, Software as a Service (SaaS) is becoming a dominant form of software delivery to users. From perspective of service providers, the benefits of SaaS are shown through economies of scale, by offering software to a large number of consumers through a shared instance of software. One way to implement SaaS is through multi-tenancy, an approach to the implementation of SaaS that divides the instance of an application in various virtual applications called tenants. To offer this type of software is necessary to take into account various aspects such as security, resource allocation, customization, scalability, data storage, reuse, etc. This paper aims to start a systematic mapping to identify the state of the art of multi-tenancy, implementation proposals and major gaps in this area through the analysis of the main papers on the subject. At the end of this study is presented applying these concepts in the industry.

vii

Sumário

Lista de Figuras Lista de Tabelas Lista de Siglas 1 Introdução 1.1 Motivação . . . . . . . . . . 1.2 Objetivos . . . . . . . . . . 1.2.1 Objetivos Gerais . . 1.2.2 Objetivos Específicos 1.3 Metodologia . . . . . . . . . 1.4 Contribuições científicas . . 1.5 Estrutura da dissertação . . .

xi xii xiii 1 2 6 6 6 6 8 8 9 10 15 18 19 21 23 23 25 26 26 29 30 30 31 38 38 39 41

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2

Fundamentação Teórica 2.1 Cloud Computing . . . . . . . 2.2 SaaS - Software como Serviço 2.3 Multi-tenancy . . . . . . . . . 2.4 Considerações Finais . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3

Mapeamento Sistemático 3.1 Diretivas de pesquisa . . . . . . . . . . . . . 3.1.1 Pesquisa exploratória . . . . . . . . . 3.1.2 Definição de Questões de Pesquisa . . 3.2 Seleção dos dados . . . . . . . . . . . . . . . 3.2.1 Condução da pesquisa . . . . . . . . 3.2.2 Triagem dos Trabalhos . . . . . . . . 3.3 Classificação . . . . . . . . . . . . . . . . . 3.3.1 Esquema de Classificação . . . . . . 3.3.2 Classificação dos trabalhos relevantes 3.4 Principais Descobertas . . . . . . . . . . . . 3.4.1 Alocação de Recursos . . . . . . . . 3.4.2 Banco de Dados . . . . . . . . . . . 3.4.3 Customização . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

viii

3.5

3.6 3.7 3.8 4

3.4.4 Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 Migração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.7 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.8 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.9 SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapeamento das evidências . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Q1 - Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Q2 - Quais as propostas existentes para implementação da arquitetura multi-tenancy? . . . . . . . . . . . . . . . . . . . . . . . Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . Métodos ou Técnicas . . . . . . . . . . . . . . . . . . . . . . . Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Propostas de Arquitetura . . . . . . . . . . . . . . . . . . . . . 3.5.3 Q3 - Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicação multi-tenancy . . . . . . . . . . . . . 3.5.4 Q4 - Quando a adoção da arquitetura multi-tenancy é viável? . . Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ameaças a validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . .

43 43 44 45 46 48 48 49 50 51 53 53 55 56 57 60 61 64 65 66 66 68 70 72 73 77 78 78 80 81 81 83

Aplicação na Indústria 4.1 Problema . . . . . . . . . . . . . . . . . . . . . 4.2 Metodologia . . . . . . . . . . . . . . . . . . . . 4.3 Definição de Arquitetura . . . . . . . . . . . . . 4.3.1 Identificação dos objetivos da Arquitetura 4.3.2 Visão geral da aplicação . . . . . . . . . 4.3.3 Pontos Críticos e Soluções . . . . . . . . 4.3.4 Proposta de solução de arquitetura . . . . Autenticação . . . . . . . . . . . . . . . Configuração . . . . . . . . . . . . . . . Banco de dados (Database) . . . . . . . . 4.3.5 Tecnologias . . . . . . . . . . . . . . . . 4.3.6 Prototipagem . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

ix

4.4 4.5 5

Migração do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . .

85 89 90 91 91 92 107 108

Conclusão e Trabalhos Futuros 5.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Referências Bibliográficas Appendices A Estudos Primários

x

Lista de Figuras

1.1 1.2

1.3

1.4 1.5 2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 4.1 4.2 4.3 4.4 4.5 4.6

Cauda Longa(Adaptada de: (Chong and Carraro, 2006)) . . . . . . . . Empresas de software globais vêem seu pecentual de venda de produtos diminuirem de 70 por cento em 1990 para menos de 50 por cento em 2003(Adaptada de: (Cusumano, 2008)) . . . . . . . . . . . . . . . . . Empresas de software corporativo baseado em web tem adotado uma varidade de modelos de negócio. Pagamento de assinatura mensal é o modelo de pagamento mais popular (Adaptada de: (Cusumano, 2008)) . Hype Cycle para Cloud Computing((Smith, 2011)) . . . . . . . . . . . Resumo da Metodologia(Elaboração própria) . . . . . . . . . . . . . . Modelos de serviço de Cloud Computing . . . . . . . . . . . . . . . . . Amazon S3’s Growth(Huang, 2011a) . . . . . . . . . . . . . . . . . . . Níveis de Maturidade SaaS(Chong and Carraro, 2006) . . . . . . . . . Processo de Mapeamento Sistemático - Adaptado de (Petersen et al., 2008) Percentual de estudos retornados de acordo com a estratégia de busca . Percentual de estudos retornados pelas buscas automáticas . . . . . . . Quantidade de artigos agrupados por Contexto e Ano . . . . . . . . . . Quantidade de artigos agrupados por Contexto e Contribuição . . . . . Quantidade de artigos agrupados por Contexto e Tipo de Pesquisa . . . Quantidade de artigos agrupados por Questão e Tipo de Pesquisa . . . . Técnicas de mapeamento de esquema(Fonte: (Aulbach et al., 2008)) . . Metamodelo para SPL(Fonte: (Cavalcanti et al., 2011)) . . . . . . . . . Metodologia utilizada para desenvolvimento de aplicação na indústria(Fonte: Elaboração própria) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de Caso de Uso da Aplicação Alexandria(Fonte: Elaboração própria) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura de Referência adotada(Fonte: (Bezemer et al., 2010)) . . . Arquitetura do Grails Framework(Fonte: (Judd et al., 2008)) . . . . . . Arquitetura da Aplicação(Fonte: Elaboração própria) . . . . . . . . . .

2

3

4 5 7 14 16 17 23 29 29 36 36 37 37 42 69 70 74 80 83 84

xi

Lista de Tabelas

2.1 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 4.1 4.2 4.3 A.1 A.2 A.3 A.4 A.5

Definições de Cloud Computing(Vaquero et al., 2008) . . . . . . . . . . Questionamentos e termos . . . . . . . . . . . . . . . . Strings Search . . . . . . . . . . . . . . . . . . . . . . . Resultado da aplicação dos critérios de exclusão . . . . . Faceta Contexto . . . . . . . . . . . . . . . . . . . . . . Faceta Tipos de pesquisa (Fonte: (Wieringa et al., 2005)) Faceta Contribuição (Fonte: (Wieringa et al., 2005)) . . . Artigos associados por Questão de pesquisa . . . . . . . Artigos agrupados por contexto . . . . . . . . . . . . . . Artigos agrupados por contribuição . . . . . . . . . . . . Artigos agrupados por Tipo de Pesquisa . . . . . . . . . Métodos e técnicas para implementar multi-tenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 26 28 30 32 33 34 34 35 35 38 54

Estilos arquiteturais escolhidos e suas influências em nossa arquitetura . 76 Atributos de qualidade desejáveis na arquitetura . . . . . . . . . . . . . 79 Resultado da aplicação dos critérios de exclusão(Fonte: Elaboração própria) 86 Estudos Primários . . . . . . . . Estudos Primários(Continuação) Estudos Primários(Continuação) Estudos Primários(Continuação) Estudos Primários(Continuação) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 109 110 111 112

xii

Lista de Siglas

API Application Programming Interface ARPANET Advanced Research Projects Agency Network CRM Customer Relationship Management CRUD Service Component Architecture EC2 Elastic Compute Cloud GUI Graphic User Interface IaaS Infrastructure as a Service ITHA Isolated Tenancy Hosted Applications MTEA Multi-tenant Enabled Application NIST National Institute of Standards and Technology P2P Peer-to-Peer PaaS Platform as a Service PDA Personal Data Assistent QoS Quality of Service RBAC Role-Based Access Control RIA Rich Internet Application S3 Simple Storage Service SaaS Software as a Service SCA Service Component Architecture SGBD Sistema de Gerenciamento de Banco de Dados SLA Service Level Agreement SOA Service Oriented Architecture

xiii

SPIN Service Performance Isolation Infrastructure SPL Software Product Lines TI Tecnologia da Informação UML Unified Modeling Language WSDL Web Service Definition Language XML Extensible Markup Language

xiv

1
Introdução
Os consumidores mudaram com a evolução dos meios de comunicação, transporte e distribuição de produtos e serviços. À medida que os custos de distribuição baixam, diversos produtos que não tinham condições de serem ofertados por ter baixa procura e volume de vendas passam a ter seu lugar no mercado. Nesse contexto, surgiu o conceito de Cauda Longa (Anderson, 2006). A Cauda Longa é um fenômeno observado em empresas de internet que conseguem faturar com produtos de nicho de mercado tanto quanto, ou até mais que os tradicionais produtos da "moda". Isso se tornou viável com o advento da internet, já que a inexistência de limitação do espaço físico, para exibição de produtos, faz com que os produtos que atendem a uma pequena fatia do mercado sejam exibidos aos clientes da mesma forma que os produtos focados na grande massa de clientes. A grande descoberta veio da análise da quantidade de produtos vendidos. Um estudo feito com a Amazon (Amazon, 2011) mostrou que, por ter uma "prateleira"maior de livros à venda, o faturamento dos livros menos populares (fora dos 100 mil principais títulos) representava em torno de um quarto da receita. Analisando o cenário temos a impressão de que são produtos que não vale a pena vender (Anderson, 2006). Isso é verdade para uma loja física tradicional puramente por uma questão de espaço físico, o que não acontece em uma loja virtual. Foi no varejo da internet que descobriu-se o poder da Cauda Longa e da prateleira de tamanho infinito. Segundo Chong et al. (Chong and Carraro, 2006), fornecedores de soluções complexas de software de linha de negócios se defrontam com uma curva de mercado semelhante, como é mostrado na Figura 1.1. Em contraste com os pacotes mais simples de software pronto, o software de linha de negócios tende a ser personalizado para atender as necessidades de clientes individuais, potencialmente incluindo instalação no local e visitas de serviço por parte das equipes de manutenção do fornecedor, muitas vezes exigindo

1

1.1. MOTIVAÇÃO

hardware de servidor dedicado e uma equipe de suporte para gerenciá-lo. O custo de fornecer esse tipo de atenção dedicada influencia no preço mínimo desse produto. Esse software, portanto, tende a ser vendido para empresas maiores que podem pagar por esse nível de atenção.

Figura 1.1 Cauda Longa(Adaptada de: (Chong and Carraro, 2006))

Para cada grande empresa que compra uma solução de linha de negócios existem dezenas de empresas menores e de tamanho médio que poderiam beneficiar-se dessa solução, mas não possuem os recursos para adquiri-la. Assim, no modelo SaaS (Choudhary, 2007) de fornecimento de software, precisa-se desenvolver soluções e infraestruturas de baixo custo, com alto aproveitamento de recursos durante o uso do aplicativo por um grande número de usuários, para assim atingir um público ainda não suportado, devido os custos proibitivos de entrada(Sousa et al., 2010).

1.1

Motivação

Na Cauda Longa, um número muito grande de usuários que poderá adotar a solução de software que permite a cada cliente pagar um valor muito baixo pelo uso do software, e ainda assim, o provedor de serviço poderá ter um lucro considerável ao final do mês. No mercado de software pode-se citar duas abordagens para venda de software, uma seria vender uma solução para um pequeno grupo de clientes que estão dispostos a pagar um alto valor por esse produto ou serviço. Outra é vender(ou prover um serviço) a um valor muito baixo, desde que se possa atender a um número grande de clientes. Esse cenário é demonstrado na Figura 1.1. Quanto mais um provedor de serviços consegue

2

1.1. MOTIVAÇÃO

baixar o custo de um produto para os clientes, um número maior de clientes poderá ser alcançado. Um ponto importante no modelo de SaaS é o apoio para vários clientes, fazendo possível que compartilhem a mesma aplicação e infraestrutura, reduzindo os custos operacionais. Isso significa que cada cliente pode interagir com o aplicativo como se ele fosse o único usuário da aplicação. Em especial, um cliente não pode acessar ou visualizar os dados de outro, embora compartilhem a mesma estrutura física (Sousa et al., 2010) e paga por esse serviço de acordo com o uso. Nos últimos anos, temos sofrido uma grande mudança no mercado de software onde empresas têm mudado seu foco do desenvolvimento de produtos para o desenvolvimento de serviços(Cusumano, 2008). Um estudo realizado com 500 empresas de desenvolvimento de software, onde analisou-se o percentual de vendas de produtos e serviços dessas empresas, mostrou o crescimento do percentual de vendas de serviços em relação à produtos. O resultado desse estudo é apresentado na Figura 1.2.

Figura 1.2 Empresas de software globais vêem seu pecentual de venda de produtos diminuirem de 70 por cento em 1990 para menos de 50 por cento em 2003(Adaptada de: (Cusumano, 2008))

O mesmo estudo citado anteriormente, baseado em informações obtidas apartir 108 empresas de desenvolvimento de software corporativo, identificou que a cobrança de taxa mensal é a forma de cobrança mais utilizada nessas empresas, superando em mais de 2 vezes a forma de cobrança através de pagamento de Taxa Inicial de Licença de Software, que é considerada a forma de cobrança tradicional(Figura 1.3)(Cusumano, 2008). Segundo estudos do Instituto Gartner(Gartner, 2011), em julho de 2011, a previsão de receita mundial de SaaS era de U$ 12,1 bilhões em 2011, um aumento de 20,7% em relação à receita de 2010 quando a receita atingiu U$ 10 bilhões. A previsão, de acordo com a pesquisa é que SaaS apresente um crescimento saudável até 2015, quando a receita

3

1.1. MOTIVAÇÃO

Figura 1.3 Empresas de software corporativo baseado em web tem adotado uma varidade de modelos de negócio. Pagamento de assinatura mensal é o modelo de pagamento mais popular (Adaptada de: (Cusumano, 2008))

mundial atingiria U$ 21,3 bilhões. No mercado de SaaS, aplicações de CRM(Customer Relationship Management) arrematam a maior fatia, com faturamento de U$ 3,2 bilhões em 2010 e podendo chegar ao final de 2011 com U$ 3,8 bilhões. Gartner espera que SaaS represente quase 32% da receita do mercado total de software CRM em 2011. Embora seja grande o volume de recursos aplicados nessa área, a publicidade massiva em torno de Cloud Computing e SaaS deixa o cenário nebuloso para os desenvolvedores(Milojicic, 2008). O número crescente de tecnologias, somado à expeculações sobre seu uso, pode dificultar a tomada de decisão por parte de desenvolvedores e gerentes de projeto. O Gartner lança anualmente o "Gartner’s Hype Cycle", que caracteriza como o exagero sobre uma tecnologia desenvolve-se "de um entusiasmo através de um período de desilusão a um eventual entendimento da relevância da tecnologia e seu papel em um mercado ou domínio"(Smith, 2011). Segundo Smith et al.(Smith, 2011), multi-tenancy(Tsai et al., 2010c), uma das formas de se implementar aplicações SaaS está no segundo estágio do "hype cycle"definido pelo Gartner, como mostra a Figura 1.4. O "hype cycle"é dividido em cinco fases que são descritas a seguir: • Technology Trigger - È a primeira fase do hype cycle, quando a nova tecnologia gera grande interesse da mídia e da sociedade. • Peak of Inflated Expectations - Nesta fase é apresentado um entusiasmo exagerado, cercado de expectativas não realistas. Ocorrem aplicações de sucesso da

4

1.1. MOTIVAÇÃO

Figura 1.4 Hype Cycle para Cloud Computing((Smith, 2011))

tecnologia e decepções. É a fase atual de Cloud Computing, segundo o relatório do Instituto Gartner(Smith, 2011). • Trough of Disillusionment - O interesse na tecnologia começa a diminuir devido a experimentos e implementações falharem na entrega. Ela ocorre devido a nova tecnologia não conseguir atender toda a expectativa criada. • Slope of Enlightenment - Nessa fase, mais casos de como as empresas podem se beneficiar da tecnologia começam a se cristalizar e a tecnologia começa a ser mais amplamente compreendida. Produtos começam a surgir de fornecedores de tecnologia, mas empresas conservadoras continuam cautelosas. • Plateau of Productivity - Uma adoção da tecnologia com maior maturidade começa a acontecer. Os critétios de viabilidade da tecnologia são melhor definidos. A aplicabilidade da tecnologia no mercado em geral e sua relevância podem ser claramente vistos. De acordo com o gráfico da Figura 1.4, um entusiasmo exagerado, cercado de expectativas não realistas permeia a área de multi-tenancy. Diante disso , identificou-se a necessidade de elaborar uma sintetização do conhecimento gerado sobre multi-tenancy, bem como o levantamento de evidências que possam auxiliar desenvolvedores a tomar

5

1.2. OBJETIVOS

decisões durante o desenvolvimento de uma aplicação SaaS multi-tenancy. A realização de uma sintetização que siga o rigor da metodologia científica, aumenta a credibilidade deste trabalho e elimina interferências causadas por entusiasmos proporcionados pela mídia. Tornando esse trabalho um artefato importante durante a tomada de decisões em um projeto real.

1.2

Objetivos

Esta seção lista o objetivo geral e os objetivos específicos desta dissertação.

1.2.1

Objetivos Gerais

Mapear a área de multi-tenancy identificando pontos que possam auxiliar desenvolvedores e engenheiros de software durante o criação de aplicações web que adotem multi-tenancy como estilo arquitetural para a implementação de SaaS.

1.2.2

Objetivos Específicos

O objetivo geral pode ser decomposto nos seguintes objetivos específicos: • Apresentar uma visão geral da arquitetura multi-tenancy, explicando os principais conceitos úteis para entendimento deste trabalho; • Definir o status de maturidade atual de multi-tenancy; • Identificar as evidências sobre os fatores que influenciam na adoção e desenvolvimento de SaaS multi-tenancy; • Analisar e classificar de maneira sistemática os estudos primários e os artefatos encontrados que podem auxiliar no desenvolvimento de uma aplicação multitenancy • Por fim, combinar os resultados evidenciados no estudo secundário com uma aplicação prática dos conceitos de multi-tenancy na indústria.

1.3

Metodologia

Para alcançar os objetivos esperados, as atividades foram divididas em 3 fases:

6

1.3. METODOLOGIA

• Fase 1 - Apartir dos objetivos da pesquisa, foi realizado uma revisão bibliográfica inicial para a familiarização com os termos e principais conceitos relacionados ao tema multi-tenancy. Essa fase foi baseada na leitura de artigos, publicações em sites e revistas relacionados ao tema. Como resultado dessa fase obtivemos os principais conceitos e termos relacionados a multi-tenancy que servirão de entrada para a próxima fase. • Fase 2 - Conhecidos os conceitos e termos, é possível planejar e executar um mapeamento sistemático que servirá para entender o contexto no qual o tema pesquisado está inserido. Nessa fase são executadas atividades como definição de questões de pesquisa, escolha de engines de busca, leitura e categorização dos trabalhos relevantes, etc. O objetivo principal dessa fase é entender o estado da arte de multi-tenancy e SaaS, bem como conhecer o que já existe no mercado e quais os possíveis problemas em aberto. • Fase 3 - baseado no resultado do mapeamento sistemático realizado na fase anterior, é definida uma abordagem de implementação, que é adotada durante o desenvolvimento de um projeto na indústria. A Figura 1.5 descreve de forma resumida a metodologia utilizada nessa dissertação.

Figura 1.5 Resumo da Metodologia(Elaboração própria)

7

1.4. CONTRIBUIÇÕES CIENTÍFICAS

1.4

Contribuições científicas

Com este trabalho, espera-se fornecer as seguintes contribuições científicas: • Fornecer um mapeamento da área de multi-tenancy • Consolidar de forma sistemática o conhecimento sobre multi-tenancy, bem como o conhecimento sobre ferramentas e técnicas que auxiliem no desenvolvimento dessas aplicações • Fornecer um catálogo de frameworks e propostas para a implementação da arquitetura multi-tenancy

1.5

Estrutura da dissertação

O restante deste trabalho está organizado em 5 capítulos, conforme a divisão que se segue. O Capítulo 2 introduz os conceitos básicos necessários ao entendimento do trabalho. Em seguida, o Capítulo 3 apresenta a metodologia que foi utilizada para conduzir esta dissertação. O Capítulo 4 apresenta os resultados encontrados após a execução do estudo de mapeamento. No Capítulo 5 é apresentado um estudo de caso para validar o conceito de multi-tenancy. Por fim, o Capítulo 6 apresenta as conclusões da dissertação, ressaltando as contribuições, as limitações e os trabalhos futuros a serem realizados.

8

2
Fundamentação Teórica
Em 1969, Leonard Keinrock, um dos cientistas chefe da ARPANET, precursora da internet, disse: "A partir de agora, redes de computadores estão ainda na sua infância, mas a medida que crescem e tornam-se sofisticadas, nós iremos provavelmente ver a disseminação do ’computador utilitário’ que, como telefones e energia elétrica, irão servir casas e escritórios por todo país"(Kleinrock, 2003). Essa visão de computação utilitária baseada no modelo de fornecimento de serviços antecipa a transformação massiva de toda a indústria de computação nos últimos anos, em que os serviços de computação estarão prontamente disponíveis sob demanda, como os outros serviços utilitários disponíveis atualmente. Similarmente, os usuários(consumidores) precisam pagar os provedores somente quando eles acessam os serviços de computação. Além disso, consumidores não precisam mais realizar altos investimentos ou enfrentar a dificuldade de construir e manter complexas infra-estruturas de TI. Os profissionais de desenvolvimento de software estão enfrentando inúmeros novos desafios para criar software para milhões de consumidores usarem como serviço ao invés de executarem em seus computadores pessoais. E ao longo dos anos, o surgimento de avanços tecnológicos como processadores multicore e ambientes de computação em rede como Cluster Computing(Yeo et al., 2006), Grid Computing(Jacob, 2005), computação P2P(Vu et al., 2010) e o mais recente Cloud Computing(Mell and Grance, 2009), tornam esse objetivo cada vez mais factível. Os serviços de computação citados anteriormente precisam ser altamente confiáveis, escaláveis e dinâmicos para suportar acesso ubíquo e fornecer a possibilidade de composição de outros serviços(Dustdar and Schreiner, 2005). Além disso, consumidores devem ter a capacidade de determinar o nível de serviço requerido através de parâmetros de QoS(Quality of Service) e SLA(Service Level Agreement)(Berberova and Bontchev, 2009).

9

2.1. CLOUD COMPUTING

Cloud Computing foi o último desses paradigmas a emergir e promete entregar serviços confiáveis através da nova geração de datacenters que são construídos utilizando tecnologias de virtualização de processamento e armazenamento. Consumidores estarão habilitados a acessar aplicações e dados da "cloud"em qualquer lugar do mundo e sob demanda, como é o caso do Gmail1 , Google Docs2 , Office Web Apps3 , Dropbox4 , dentre outros. Em outras palavras, a cloud parace ser um ponto de acesso único para todas as necessidades de computação dos consumidores.

2.1

Cloud Computing

Atualmente não existe uma definição oficial do que seja Cloud Computing. O objetivo nessa seção é reunir várias definições de Cloud Computing disponíveis e chegar a uma definição que seja um denominador comum. A Tabela 2.1 mostra as definições de Cloud Computing propostas por muitos especialistas na área (Vaquero et al., 2008). Segundo Markus Klems(Geelan, 2009), escalabilidade imediata e uso otimizado dos recursos são os principais elementos de uma cloud. Isso é provido pelo aumento no monitoramento e automação do gerenciamento de recursos, em um ambiente dinâmico. Outros autores discordam que esse é um requisito para uma infraestrutura ser considerada cloud(Haaff, 2009). Além disso, Cloud Computing tem sido definido por alguns autores como hardware e software virtualizados, somados a aplicação de tecnologias de monitoramento e provisionamento(Geelan, 2009). Ainda existem alguns outros especialistas que não enfatizam capacidades da cloud, mas acreditam que cloud computing é uma "buzz word"abrangendo uma grande variedade de aspectos como deployment, balanceamento de carga, provisionamento e terceirização de processamento e armazenamento de dados. Levando em consideração as características apresentadas na Tabela 2.1, Luiz M. Vaquero e outros autores (Vaquero et al., 2008) tentaram chegar a uma definição de Cloud Computing. Obviamente o conceito de cloud ainda está em mudança e essas definições mostram como o conceito de cloud é concebido por alguns especialistas. Cloud é um grande pool de recursos virtualizados(hardware, plataformas de desenvolvimento e serviços) facilmente utilizáveis e acessíveis. Esses recursos podem ser dinâmicamente reconfigurados para se ajustar a carga variável(escala), permitindo também a otimiza1 http://www.gmail.com 2 http://docs.google.com 3 http://office.microsoft.com/web-apps 4 http://www.dropbox.com

10

2.1. CLOUD COMPUTING
Autor M. Klems P. Gaw R. Buyya Definição ... é possível escalar sua infraestrutura sob demanda em minutos ou em segundos, ao invés de dias ou semanas, evitando desse modo sub-utilização e sobrecarga dos seus recursos in-house. Uso da internet para permitir pessoas acessarem serviços tecnologicamente disponíveis. Esses serviços precisam ser massivamente escaláveis. Uma Cloud é um tipo de sistema paralelo e distribuído que consiste de uma coleção de computadores virtualizados e interconectados que são dinâmicamente provisionados e apresentados como um ou mais recursos computacionais unificados, baseados em SLA estabelecida através de negociação entre o provedor de serviço e o consumidor. Cloud Computing é uma das várias buzz words existentes que tentam abranger uma variedade de aspectos como deployment, balanceamento de carga, provisionamento, modelo de negócios e arquitetura. Esse é o próximo passo em software. A explicação mais simples de Cloud Computing é descrevê-la como ’Software centrado na internet’. Uma ampla gama de serviços baseados na web que objetivam permitir ao usuário obter uma variedade de funcionalidades que são pagas por uso e que anteriormente requeria uma grande quantidade de investimentos em hardware/software e contratação de bons profissionais. Cloud Computing é a realização de idéias antigas de computação utilitária sem a complexidade técnica ou preocupação com deployments complicados. ... o próximo termo para campanhas publicitárias ... criado fora do modelo de software que a virtualização habilitou. ... é o que é possível quando você alcança a infra-estrutura(de aplicação e física) para o tamanho da web de uma forma sob-demanda. Existem somente três tipos de serviço que são baseados em cloud: SaaS, PaaS e Plataformas de Cloud Computing. O autor não garante que escalar massivamente seja um requisito para caber em qualquer categoria. Simplificando, Cloud Computing é uma mudança de paradigma de infraestrutura que habilita a ascenção de software como serviço ... É uma gama de serviços baseados em web que tem como objetivo permitir a usuários obter uma ampla variedade de funcionalidades baseada no modelo de pagamento por uso e que anteriormente requeria uma grande quantidade de investimentos e contratação de profissionais especialistas. Cloud foca em fazer a capacidade de processamento e armazenamento da camada de hardware consumível sob demanda. Esse é um primeiro passo importante, mas para as companhias aproveitarem o poder da cloud, infra-estruturas completas de aplicações precisam ser facilmente configuradas, distribuídas, dinâmicamente escaladas e gerenciadas nesses ambientes de hardware virtualizado. Na realidade é o acesso a recursos e serviços necessários para executar funcionalidades com necessidade de mudança dinâmica. É a virtualização de recursos auto-mantidos e auto-gerenciáveis. Clouds são um vasto pool de recursos com alocação sob demanda... virtualizados ... e cobrados por utilização. Cloud Computing é ... uma versão de grid computing amigável para o usuário. terceirizado, sob-demanda, pago por uso, em qualquer lugar da internet, etc.

R. Cohen

J. Kaplan

D. Gourlay D. Edwards B. de Haff

B. Kepes

K. Sheynkman

K. Hartig J. Pritzker T. Doerkzen T. Von Eicken

11

2.1. CLOUD COMPUTING
Autor M. Sheedan A. Ricadela I. Wladawsky Berger B. Martin R. Bragg Definição a pirâmide de cloud computing ajuda a diferenciar as várias ofertas de cloud... no topo: SaaS, no meio: PaaS, na base: IaaS. Projetos de Cloud Computing são mais poderosos e tolerantes a falhas que sistemas de grid desenvolvidos nos últimos anos. A principal coisa que queremos virtualizar e ocultar do usuário é a complexidade ... todos aqueles softwares que serão virtualizados ou ocultos de nós e o tratamento de sistemas e/ou profissionais que estão em qualquer outro lugar, fora da Cloud. Cloud computing inclui qualquer serviço baseado em assinatura ou pago por uso que, em tempo real e rodando na internet, extende as capacidades de ti existentes. O conceito principal de cloud é a aplicação web... a cloud mais desenvolvida e confiável. Muitos acham barato migrar agora para uma cloud na web ao invés de investir em seus proprios servidores ... isso é um desktop por pessoa sem um computador. Cloud é toda sobre: SaaS ... computação utilitária, PaaS ... integração na internet ... plataformas comerciais. Cloud Computing, onde residem não somente nossos dados mas também alguns de nossos softwares. Nós acessamos qualquer coisa não somente através de nossos PCs, mas também de outros dispositivos, como smartphones, PDAs, ... O megacomputador é habilitado pela virtualização e software como serviço ... Essa é a utilização do poder de computação pela massiva utilização de data centers

G. Gruman and E. Knorr P. McFedries

Tabela 2.1 Definições de Cloud Computing(Vaquero et al., 2008)

ção na utilização de recursos. Esse pool de recursos é normalmente explorado pelo modelo pay-by-use(pague por uso), no qual garantias são oferecidas pelo provedor de infraestrutura por meio de SLA(Service Level Agreement). Olhando para o mínimo denominador comum nas definições, os autores não chegaram a uma definição de uma funcionalidade única proposta em todas as definições. O conjunto de funcionalidades que mais se aproxima da definição mínima poderia ser escalabilidade, modelo de pagamento por uso e virtualização. Nesse trabalho usaremos a definição proposta pelo National Institute of Standards and Technology(NIST), que define Cloud Computing como um modelo que permite, de forma conveniente, o acesso a um pool de recursos computacionais compartilhados(rede, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente provisionados e liberados com o mínimo de esforço de gerenciamento ou interação do provedor de serviço. Ainda segundo o National Institute of Standards and Technology (NIST), Cloud Computing é composta por cinco características essenciais(Mell and Grance, 2009): • Alocação de recursos sob demanda: O usuário pode adquirir unilateralmente

12

2.1. CLOUD COMPUTING

recursos computacionais, como tempo de processamento no servidor ou armazenamento, através da rede na medida em que necessite e sem precisar de interação humana com os provedores de cada serviço. • Amplo acesso a rede: recursos estão disponíveis através da rede e podem ser acessados por meio de mecanismos que funcionem em plataformas heterogêneas (por exemplo, telefones celulares, laptops e PDA). • Pooling de recursos: os recursos do provedor de computação são agrupados para atender vários consumidores através de um modelo multi-tenancy, com diferentes recursos físicos e virtuais atribuídos dinamicamente e novamente de acordo com a demanda do consumidor. Há um senso de independência local em que o cliente geralmente não tem nenhum controle ou conhecimento sobre a localização exata dos recursos disponibilizados, mas pode ser capaz de especificar o local em um nível maior de abstração (por exemplo, país, estado ou data center). Exemplos de recursos incluem o armazenamento, processamento, memória, largura de banda de rede e máquinas virtuais. • Elasticidade rápida: recursos podem ser adquiridos de forma rápida e elástica, em alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da demanda, e podem também ser liberados, na retração dessa demanda. Para os usuários, os recursos disponíveis para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento. • Serviço medido: sistemas em nuvem automaticamente controlam e otimizam a utilização dos recursos, alavancando a capacidade de medição em algum nível de abstração adequado para o tipo de serviço (por exemplo, armazenamento, processamento, largura de banda, e contas de usuários ativos). Uso de recursos pode ser monitorado, controlado e relatado a existência de transparência para o fornecedor e o consumidor do serviço utilizado. Ainda segundo o NIST(Mell and Grance, 2009), Cloud Computing é dividido em três modelos de serviço(Figura 2.1): • Software como Serviço (SaaS): A capacidade fornecida ao consumidor é a de usar as aplicações do fornecedor em uma infraestrutura da nuvem. As aplicações são acessíveis de vários dispositivos cliente através de uma interface thin client, como por exemplo um browser web. O consumidor não administra ou controla a

13

2.1. CLOUD COMPUTING

infraestrutura básica, incluindo rede, servidores, sistemas operacionais, armazenamento, ou mesmo capacidades individuais da aplicação. Mesmo assim ainda é possível definir algumas configurações específicas para o usuário na aplicação. • Plataforma como Serviço (PaaS): A capacidade fornecida ao consumidor é a de realizar deploy de uma aplicação em uma infraestrutura pré-definida ou adquirir aplicações criadas usando linguagens de programação e as ferramentas suportadas pelo provedor de PaaS. O consumidor não administra ou controla a infraestrutura básica como rede, servidores, sistemas operacionais, ou armazenamento, mas tem controle sobre os aplicativos utilizados e eventualmente hospedagem de aplicativos e configurações de ambiente. • Infraestrutura como Serviço (IaaS) : A capacidade prevista para o consumidor é a de processamento, armazenamento, redes e outros recursos computacionais fundamentais para que o consumidor seja capaz de implantar e executar programas arbitrários, que podem incluir sistemas operacionais e aplicativos. O consumidor não administra ou controla a infraestrutura de nuvem subjacente, mas tem controle sobre os sistemas operacionais, armazenamento, aplicativos implantados, e, eventualmente, o controle limitado de componentes de rede (por exemplo, firewall).

Figura 2.1 Modelos de serviço de Cloud Computing

Nesse trabalho teremos como foco principal os tópicos relacionados a SaaS, embora sejam mencionados alguns conceitos associados à PaaS e IaaS. O motivo disso é que multi-tenancy é um conceito existente dentro do contexto de Software como serviço.

14

2.2. SAAS - SOFTWARE COMO SERVIÇO

2.2

SaaS - Software como Serviço

Nos últimos anos muitas empresas tem saído do modelo de entrega de software empacotado para o modelo de fornecimento de software na web(Huang, 2011b). Essas aplicações entregues através da web vão desde emails a calendários, sistemas colaborativos, publicações online, processadores de texto simples, aplicações para negócios e aplicações para uso pessoal. Salesforce.com(Lehnen, 2011), por exemplo, criou um aplicativo para CRM(Customer Relationship Management) e o configurou não como um software empacotado, mas como software rodando sobre servidores acessível através do browser. Quando fez isso, criou a propria plataforma in-house para entregar o software como serviço para seus consumidores. Logo em seguida Salesforce.com criou o AppExchange, uma plataforma de integração aberta para outras empresas de software construirem produtos utilizando algumas funcionalidades do CRM do salesforce. Pouco tempo depois Salesforce extendeu o conceito de plataforma aberta como force.com, um ambiente de desenvolvimento e deployment usando a infraestrutura de SaaS do Salesforce. Posteriormente, algumas outras empresas ingressaram nesse mercado, a Amazon com o Elastic Compute Cloud (EC2)(Amazon, 2011) e Google com o Google AppEngine5 , abrindo suas infraestruturas de cloud para hospedarem aplicações de terceiros, além de produzirem serviços online. Amazon vem se tornando bastante atraente porque possui uma rica infraestrutura para suportar operações de varejo online e tem oferecido vários serviços para usuários de cloud como: data storage, processamento, fila de mensagens, billing e etc. O artigo "Amazon S3’s Amazing Growth"(Huang, 2011a) menciona o crescimento vertiginoso no uso do serviço S3 da Amazon(Amazon, 2011) nos últimos anos, é possível ver o gráfico de crescimento desse serviço na figura 2.2. Cloud Computing e SaaS também parecem ser eficientes tanto para usuários quanto para fornecedores de software. Vários consumidores podem usar a mesma instalação do software e consequentemente isso melhora as taxas de utilização de hardware e rede. Por exemplo, Amazon6 e Google7 tem enormes datacenters que eles não utilizam completamente o tempo todo. Eles podem executar seus próprios produtos e enquanto hospedam aplicações de outras empresas. Hosts como Amazon, Google e Salesforce geralmente garantem a qualidade de serviço para todos os seus consumidores de cloud
5 https://appengine.google.com 6 http://aws.amazon.com 7 http://www.google.com

15

2.2. SAAS - SOFTWARE COMO SERVIÇO

Figura 2.2 Amazon S3’s Growth(Huang, 2011a)

através de SLAs (Service Level Agreeements) detalhadas. Segundo Harris et al.(Harris and Ahmed, 2011) existem três tipos diferentes de aplicações SaaS: • Multi-instance: essas aplicações executam em ambientes onde o servidor web é compartilhado. Nessa abordagem uma cópia da aplicação é inicialmente configurada para cada cliente, e então cada cópia é implantada como um contexto no mesmo servidor web. • Single-instance: as aplicações provêem serviços para um único cliente e executam em um servidor exclusivo. Nesse caso cada servidor web possui uma única instância da aplicação. Essa pode considerada a abordagem com maior desperdício de recursos, dado que um servidor pode executar com apenas 10% de sua capacidade. • Multi-tenancy: provê uma única aplicação compartilhada por vários clientes. Nessa abordagem várias aplicações "virtuais"são criadas na mesma instância. Implementar o conceito de SaaS nem sempre é tão simples como parece. Chong (Chong and Carraro, 2006) propõe 4 níveis de maturidade para aplicações que utilizam o modelo de SaaS: • Nível 1 - Ad-Hoc/Personalizado: O primeiro nível de maturidade é semelhante ao modelo de entrega de software do provedor de serviços de aplicativos (ASP Application Service Provider) tradicional, que data da década de 1990. Nesse nível, cada cliente tem a sua própria versão personalizada do aplicativo hospedado e

16

2.2. SAAS - SOFTWARE COMO SERVIÇO

Figura 2.3 Níveis de Maturidade SaaS(Chong and Carraro, 2006)

executa a sua própria instância do aplicativo nos servidores do provedor. Pensando em arquitetura, software nesse nível de maturidade é muito semelhante aos softwares corporativos vendidos tradicionalmente, em que diferentes usuários de uma organização conectam a uma instância única em execução no servidor, mas essa instância é totalmente independente de quaisquer outras instâncias ou processos que o host esteja executando para os seus outros clientes. • Nível 2 - Configurável: No segundo nível de maturidade, o fornecedor hospeda uma instância separada do aplicativo para cada inquilino. Enquanto no primeiro nível cada instância é personalizada individualmente para o inquilino, neste nível todas as instâncias utilizam a mesma implementação de código e o fornecedor atende as necessidades dos clientes fornecendo opções de configuração detalhadas que permitem ao cliente alterar a aparência e o comportamento do aplicativo para os seus usuários. Apesar de serem idênticas a nível do código, cada instância permanece totalmente isolada de todas as demais. • Nível 3 - Configurável e eficiente para vários tenants: No terceiro nível de maturidade, o fornecedor executa uma única instância que serve a todos os clientes. Metadados configuráveis são usados para fornecer uma experiência de usuário e um conjunto de recursos exclusivos para cada instância. Políticas de autorização e de segurança garantem que os dados de cada cliente sejam mantidos separados dos dados de outros clientes e que, da perspectiva do usuário final, não exista qualquer

17

2.3. MULTI-TENANCY

indicação de que a instância do aplicativo esteja sendo compartilhada entre vários tenants. • Nível 4 - Escalonável, configurável e eficiente para vários tenants: No quarto e último nível de maturidade, o fornecedor hospeda vários clientes em um ambiente com balanceamento de carga. Os dados de cada cliente são mantidos separados e com metadados configuráveis fornecendo uma experiência do usuário e um conjunto de recursos exclusivos para cada cliente. Um sistema de SaaS é escalonável para um número de clientes arbitrariamente grande, uma vez que a quantidade de servidores e instâncias no lado do fornecedor pode ser aumentada ou diminuída conforme necessário para corresponder à demanda sem a necessidade de remodelar a arquitetura aplicativo, além disso as alterações ou correções podem ser transmitidas para milhares de tenants tão facilmente quanto para um único tenant. Normalmente se esperaria que o quarto nível fosse a meta definitiva para qualquer aplicativo de SaaS, mas não é sempre assim. É necessário verificar as necessidades operacionais, arquiteturais e de negócio relacionadas à aplicação. Uma abordagem singletenant faz sentido financeiramente? O seu aplicativo pode ser feito para executar em uma única instância lógica? Você pode garantir os seus contratos de nível de serviço (SLAs) sem isolamento das aplicações? Essas são questões que devem ser respondidas quando se pretende adotar o modelo SaaS. O objeto de estudo principal desse trabalho serão aplicações SaaS do tipo multitenancy.

2.3

Multi-tenancy

Multi-tenancy é uma abordagem organizacional para aplicações SaaS. Bezemer e Zaidman (Bezemer and Zaidman, 2010) definem multi-tenancy como aplicações que permitem a otimização no uso dos recursos de hardware, através do compartilhamento de instâncias da aplicação e da instância do banco de dados, enquanto permite configurar a aplicação para atender às necessidades do cliente como se estivesse executando em um ambiente dedicado. Tenant é uma entidade organizacional que aluga uma aplicação multi-tenancy. Normalmente, um tenant agrupa um número de usuários que são os stakeholders da organização. A definição anterior foca no que nós consideramos aspectos em aplicações multitenancy:

18

2.4. CONSIDERAÇÕES FINAIS

• Possibilidade de compartilhamento de recursos de hardware, permitindo a redução de custos (Wang et al., 2008a). • Alto grau de configurabilidade, permitindo que cada consumidor customize sua própria interface e seu workflow na aplicação (Nitu, 2009; Jansen et al., 2010). • Uma abordagem arquitetural na qual os tenants fazem uso de uma única aplicação e banco de dados (Kwok et al., 2008a). É possível que algumas pessoas confundam multi-tenancy com o conceito de multiusuário. Multi-tenancy não é multi-usuário. Em uma aplicação multi-usuário nós assumimos que os usuários estão usando a mesma aplicação com opções de acesso limitadas e que essa instância da aplicação é utilizada por apenas um único cliente. Nesse caso podemos ter vários usuários com o perfil "gerente", com o perfil "vendedor", ou com qualquer perfil de usuário necessário para o funcionamento da aplicação. Em uma aplicação multi-tenancy nós assumimos cada instância tenants tem um algo grau de configuração, dependendo da definição dessas configurações, dois tenants pode possuir aparência e workflows diferentes. Um argumento adicional para essa distinção é que o SLA para cada tenant pode ser diferente (Lin et al., 2009a). Outra abordagem que contrasta com multi-tenancy é a abordagem multi-instance. Com o aumento da popularidade das tecnologias de virtualização e de Cloud Computing, multi-instance é a forma fácil de criar aplicações parecidas com multi-tenancy. É necessário apenas criar uma imagem de maquina virtual com a aplicação pré-configurada e, logo em seguida criar instâncias apartir dessa imagem. A abordagem multi-instance é uma melhor abordagem quando o número de clientes for pequeno (Guo et al., 2007). Uma abordagem mais profunda sobre o tema multi-tenancy será apresentado no Capítulo 3, onde será realizado um mapeamento da área.

2.4

Considerações Finais

Este capítulo apresentou os conceitos básicos usados na dissertação. Inicialmente, noções sobre Cloud Computing, SaaS, PaaS e IaaS. O conceito de multi-tenancy foi introduzido, explicitando visões e características que serão importantes para o entendimento dos capítulos posteriores. Por fim, foram apresentadas alguns requisitos de aplicações que adotam o modelo de SaaS e multi-tenancy. Embora o que foi apresentado até aqui seja de grande relevância, é preciso bem mais do que isso para adotar uma tecnologia na indústria. É necessário entender as vantagens e

19

2.4. CONSIDERAÇÕES FINAIS

desvantages, o estado da arte na academia, bem como o nível de maturidade existente na aplicação dessa tecnologia. Para responder essas questões o capítulo seguinte apresenta um mapeamento sistemático sobre o campo de multi-tenancy com o objetivo de sintetizar os conhecimentos existentes na área.

20

3
Mapeamento Sistemático
Esse trabalho originou-se de uma necessidade real de se implementar um aplicativo para uma empresa startup (Ries, 2011) que seguisse o modelo de SaaS e que pudesse ser hospedado em algum ambiente de Cloud como Amazon AWS ou Google AppEngine. A publicidade excessiva da mídia em torno de SaaS e multi-tenancy propiciam o surgimento de especulações e informações imprecisas sobre esse campo (Milojicic, 2008). Além disso a ausência de trabalhos que sintetizem o conhecimento gerado de forma a eliminar informações imprecisas ou baseadas exclusivamente em opinião pessoal torna ainda mais difícil definir o status atual da área, como foi possível observar no gráfico da Figura 1.4. Para realizar uma boa pesquisa e gerar conhecimento útil e consistente era necessário utilizar alguma metodologia na realização da pesquisa. Metodologia científica é necessária, entre outras razões, para tornar os resultados da pesquisa mais confiáveis e possíveis de serem reproduzidos, de forma independente, por outros pesquisadores. Partindo do princípio de que deveríamos utilizar alguma metodologia para realizar nossas pesquisa escolheu-se a técnica de Mapeamento Sistemático (Petersen et al., 2008) . Um Mapeamento Sistemático provê a estruturação de uma área de pesquisa, no tocante a relatórios de pesquisa e resultados que vem sendo publicados. Muitas vezes esses resultados são resumidos de forma visual através de tabelas e gráficos. A aplicação dessa técnica provê uma melhor visão panorâmica da área pesquisada (Kitchenham and Charters, 2007). A escolha de sua utilização nesse trabalho ocorreu principalmente por utilizar um processo e protocolo de execução bem definidos, o que permite que essa atividade possa ser repetida por outros pesquisadores em momentos futuros. Mapeamento Sistemático é uma metodologia que é frequentemente utilizada em pesquisas médicas, mas que vem gradualmente ganhando força na comunidade de engenharia de software. De acordo com Budgen (Budgen et al., 2008), dentre os principais motivos para se executar uma mapeamento sistemático podemos citar:

21

• ajuda na realização de uma avaliação imparcial do maior número de estudos possível, identificando lacunas existentes atualmente na área de pesquisa e contribuição para a comunidade científica com uma síntese confiável dos dados; • provê um procedimento sistemático para identificar a natureza e a extensão de dados do estudo que são úteis para responder às questões de pesquisa; • auxilia no mapeamento da pesquisa que foi realizada; • ajuda a planejar uma nova pesquisa,evitando duplicação desnecessária de esforço e erros. • ajuda a identificar lacunas e grupos de estudos primários, para identificar tópicos e áreas para realizar revisões sistemáticas mais completas. Para conduzir o mapeamento sistemático realizado nesse trabalho serão seguidos os passos descritos na Figura 3.1. Cada etapa do processo é brevemente descrita a seguir: 1. Pesquisa exploratória: nessa etapa foram realizados pesquisas em máquinas de busca e bibliotecas digitais disponíveis na web, com o objetivo de entender melhor a área a ser pesquisada. 2. Definição de questões de pesquisa: passado a fase de entendimento do problema, são definidas questões de pesquisa, que irão guiar o mapeamento sistemático. 3. Condução da pesquisa: nessa fase são selecionadas as bibliotecas digitais onde as questões de pesquisa serão executadas e outros locais onde serão pesquisados trabalhos sobre o tema. 4. Triagem de papers: é comum que as pesquisas retornem alguns trabalho com pouca relevância para responder às questões de pesquisa, nesse caso é realizado uma triagem dos trabalhos encontrados durantes as pesquisas, de forma a eliminar os trabalhos irrelevantes. 5. Busca de termos chave usando abstracts: nessa etapa é desenvolvido o esquema de classificação dos trabalhos encontrados. Primeiro é realizado a leitura dos abstracts e palavras chave em busca de conceitos que reflitam a contribuição do trabalho. Ao final dessa leitura um conjunto de palavras chave de diferentes trabalhos são combinadas para desenvolver um entendimento de alto nível sobre a natureza e a contribuição do trabalho. Isso auxilia na definição de um conjunto de categorias que ajudam no entendimento da população de estudos encontrados.

22

3.1. DIRETIVAS DE PESQUISA

6. Extração de dados e processo de mapeamento: após a definição do esquema de classificação, os trabalhos são agrupados e as informações necessárias para responder às questões de pesquisa são extraídas.

Figura 3.1 Processo de Mapeamento Sistemático - Adaptado de (Petersen et al., 2008)

Os detalhes de como o mapeamento sistemático foi conduzido serão descritos no decorrer desse capítulo que está estruturado da seguinte forma: a seção 3.1 descreve as questões que esse mapeamento pretende responder e a seção 3.2 descreve como foram realizadas as buscas e a seleção dos trabalhos relevantes associados às questões definidas na seção 3.1. Após a exclusão dos trabalhos irrelevantes e da leitura de todos os trabalhos relevantes, os mesmos foram agrupados de acordo com as categorias definidas na seção 3.3. Os resultados desse mapeamento sistemático são apresentados nas seções 3.4, 3.5 e 3.6. A seção 3.7 apresenta possíveis ameaças à validade desse trabalho e por fim a seção 3.8 apresenta as considerações finais do capítulo.

3.1
3.1.1

Diretivas de pesquisa
Pesquisa exploratória

Para realizar o mapeamento, a primeira atividade foi realizar uma pesquisa exploratória onde foram realizadas buscas no Google e Bing sobre com as seguintes palavras chave: • multi-tenant • multi-tenancy

23

3.1. DIRETIVAS DE PESQUISA

• SaaS • Software as a service Apartir dessas buscas foram encontrados alguns artigos e matérias na web sobre o assunto. Boa parte desse material tratava-se de artigos baseados em opiniões pessoais ou pequenos tutoriais. Essa atividade serviu para que fosse criada uma massa crítica de conhecimento que ajudou a compreender melhor o problema e a formalizar um conjunto de questionamentos relacionados à multi-tenancy: • Quais as vantagens e desvantagens da adoção da arquitetura multi-tenancy? Devido à inexperiencia com a adoção dessa abordagem era necessário saber quais o benefícios e perdas que se teria adotando a arquitetura multi-tenancy. • Quando a adoção de multi-tenancy é viável? É necessário identificar os cenários onde a adoção da arquitetura multi-tenancy é viável. • Existe alguma forma de extender as funcionalidades de um tenant específico? Dado que cada cliente pode ter uma necessidade específica é preciso saber como implementar as funcionalidades específicas de um cliente(tenant), já que teremos apenas uma única instância da aplicação que será utilizada por todos os clientes. • Como gerenciar a variabilidade entre os tenants? Se o aplicação suportar regras de negócio específicas para cada tenant, é relevante saber como gerenciar isso. • Como verificar se um tenant está consumindo mais recursos do que o esperado? Como otimizar o uso de recursos é uma das principais propostas de multitenancy, é importante saber a quantidade de recursos consumidos por cada tenant. Isso pode ajudar a identificar tenants que tenham uma maior demanda por recursos computacionais e alocar uma infraestrutura adequada para os mesmos, evitando que os outros tenants sejam comprometidos. • Como tratar solicitações de forma assíncrona? A fim de otimizar o uso de recursos, permitir que requisições sejam realizadas de forma assíncrona pode ajudar na melhor utilização de recursos. Existem muitas funcionalidades que podem ser solicitadas e executadas posteriormente quando a demanda de recursos no servidor for menor. • Como isolar os tenants, de forma que um tenant não tenha acesso a dados de outro indevidamente? Prover a segurança dos dados na arquitetura multi-tenancy

24

3.1. DIRETIVAS DE PESQUISA

é um fator crítico, tendo em vista que todos os tentants compartilham a mesma aplicação e possivelmente o mesmo banco de dados. • Caso um tenant esteja consumindo muitos recursos, como migrar esse tenant para outra máquina ou VM (Virtual Machine)? Caso um tenant exija mais recursos do que o esperado, ele pode sobrecarregar o servidor e prejudicar o funcionamento de outros tenants que compartilham a mesma aplicação. • Quais as propostas existentes para se implementar a arquitetura multi-tenancy? Saber quais as propostas, frameworks e bibliotecas existentes que auxiliem na implementação da arquitetura multi-tenancy é de grande importância para prover produtividade no desenvolvimento e evitar trabalho desnecessário.

3.1.2

Definição de Questões de Pesquisa

Para conduzir as pesquisas realizadas nesse trabalho,era necessário definir o escopo do estudo, para isso 4 questões foram derivadas apartir das questões já citadas na Seção 3.1.1: 1. Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? 2. Quais as propostas existentes para implementação da arquitetura multi-tenancy? 3. Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicação multi-tenancy? 4. Quando a adoção da arquitetura multi-tenancy é viável? A estratégia usada para definir os termos de busca, segue uma abordagem baseada em (Kitchenham et al., 2007), uma vez que esse trabalho sistematizou e definiu passos para derivar termos de pesquisa a partir de perguntas, pontos de vista de experts e artigos relevantes. Os passos para definição dos termos são descritos a seguir: • Apartir das questões de pesquisa definidas anteriormente, os principais termos são definidos; • Identificação de sinônimos a partir de artigos conhecidos e trabalhos relevantes na área de pesquisa;

25

3.2. SELEÇÃO DOS DADOS

• Tradução dos termos para o inglês por ser a língua utilizada nas bases de dados eletrônicas de pesquisa e nas principais conferências e eventos dos tópicos de investigação; • Uso do operador OR para indicar que dois termos são alternativos; • Uso do operador AND para indicar que dois termos devem estar juntos no resultado. Após a execução dos passos definidos acima foram encontrados termos para cada pergunta do nosso mapeamento sistemático como é possível observar na Tabela A.5.
ID Q1 Q2 QUESTÃO Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? Quais as propostas existentes para implementação da arquitetura multi-tenancy? Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicação multi-tenancy? Quando a adoção da arquitetura multi-tenancy é viável? TERMOS multi-tenancy, advantages, disadvantages, approach, barrier, adoption, viability approach, methods, techniques, proposal, framework "multi-tenancy" "product lines", variability, variation, "multi-tenancy" adoption, viability, approach, "multi-tenancy"

Q3

Q4

Tabela 3.1 Questionamentos e termos

A combinação desses termos deu origem a uma consulta genérica descrita a seguir:
(multi-tenancy OR multi-tenant) AND ("Cloud computing"OR iaas OR paas OR saas OR advantages OR disadvantages OR approach OR barrier OR adoption OR viability OR approach OR methods OR techniques OR proposal OR framework OR tenant OR "product lines"OR variability OR variation OR adoption OR viability OR challenges OR problems OR benefits OR loss)

3.2
3.2.1

Seleção dos dados
Condução da pesquisa

Segundo Kitchenham (Kitchenham and Charters, 2007), as pesquisas iniciais dos estudos podem ser realizadas em bibliotecas digitais, mas isso não é suficiente para uma revisão sistemática, outras fontes também podem ser pesquisadas. Pesquisadores da área também podem ser consultados para a indicação de fontes de material mais adequado.

26

3.2. SELEÇÃO DOS DADOS

Os critérios para a seleção das fontes foram: (1) disponibilidade de consultar os artigos na web; (2) presença de mecanismos de busca usando palavras-chave; e, (3) importância e relevância das fontes. Um processo de ampla pesquisa foi realizado à procura de artigos publicados combinando pesquisa automática e manual para aumentar a cobertura. A busca automática foi realizada em cinco fontes de pesquisa: • IEEEXplore Digital Library (httt://ieeexplore.ieee.org/) • ACM Digital Library (http://portal.acm.org) • Elsevier ScienceDirect (http:// www.sciencedirect.com) • EI Compendex (http://www.engineeringvillage2.org) • Elsevier Scopus (http://www.scopus.com) A Tabela 3.2 mostra a string de busca executada em cada biblioteca digital. As consultas foram executadas em setembro de 2011, portanto nem todos os trabalhos publicados em 2011 foram considerados nesse trabalho. A pesquisa manual foi realizada, buscando trabalhos nas 5 conferências onde mais se encontrou trabalhos na busca automática: • ICEBE - International Conference on e-Business Engineering • CLOUD - International Conference on Cloud Computing • SIGMOD - Special Interest Group on Management Of Data • ICACT - International Conference on Advanced Communications Technology • ICDE - International Conference on Data Engineering Além das buscas realizadas nessas conferências, foram realizados também buscas de whitepapers de empresas privadas abordando o assunto, como é o caso de Salesforce.com, Amazon e Google que frequentemente publicam documentos sobre o assunto em questão. O Gráfico na Figura 3.2 mostra o percentual de estudos retornados de acordo com cada estratégia de busca, onde 98% (625/637) dos estudos foram retornados por meio de busca automática e 2% (12/637) por meio de busca manual. A partir da string e fontes definidas, as buscas automáticas retornaram um total de 625 estudos, no qual, 23% (144/625) no ScienceDirect, 15% (93/625) dos estudos foram identificados no IEEExplore, 24% (152/625) no El compendex, 24% (148/625) no

27

3.2. SELEÇÃO DOS DADOS

Fonte IEEE

ACM

Scopus

ScienceDirect

Engineering Village

Query (("Document Title":"multi-tenant") OR ("Document Title":"multi-tenancy") OR (Abstract:"multitenant") OR (Abstract:"multi-tenancy")) AND ("Document Title":advantages OR "Document Title":disadvantages OR "Document Title":approach OR "Document Title":barrier OR "Document Title":adoption OR "Document Title":viability OR "Document Title":approach OR "Document Title":methods OR "Document Title":techniques OR "Document Title":proposal OR "Document Title":framewORk OR "Document Title":tenant OR "Document Title":"product lines"OR "Document Title":variability OR "Document Title":variation OR "Document Title":adoption OR "Document Title":viability OR "Document Title":challenges OR "Document Title":problems OR "Document Title":benefits OR "Document Title":loss OR "Document Title":Iaas OR "Document Title":Paas OR "Document Title":Saas OR "Document Title":"Cloud computing"OR Abstract:advantages OR Abstract:disadvantages OR Abstract:approach OR Abstract:barrier OR Abstract:adoption OR Abstract:viability OR Abstract:approach OR Abstract:methods OR Abstract:techniques OR Abstract:proposal OR Abstract:framewORk OR Abstract:tenant OR Abstract:"product lines"OR Abstract:variability OR Abstract:variation OR Abstract:adoption OR Abstract:viability OR Abstract:challenges OR Abstract:problems OR Abstract:benefits OR Abstract:loss OR Abstract:Iaas OR Abstract:Paas OR Abstract:Saas OR Abstract:"Cloud computing") ((((Title:"multi-tenant") or (Title:"multi-tenancy") or (Abstract:"multi-tenant") or (Abstract:"multi-tenancy")) and (Title:advantages or Title:disadvantages or Title:approach or Title:barrier or Title:adoption or Title:viability or Title:approach or Title:methods or Title:techniques or Title:proposal or Title:framework or Title:tenant or Title:"product lines"or Title:variability or Title:variation or Title:adoption or Title:viability or Title:challenges or Title:problems or Title:benefits or Title:loss or Title:Iaas or Title:Paas or Title:Saas or Title:"Cloud computing"or Abstract:advantages or Abstract:disadvantages or Abstract:approach or Abstract:barrier or Abstract:adoption or Abstract:viability or Abstract:approach or Abstract:methods or Abstract:techniques or Abstract:proposal or Abstract:framework or Abstract:tenant or Abstract:"product lines"or Abstract:variability or Abstract:variation or Abstract:adoption or Abstract:viability or Abstract:challenges or Abstract:problems or Abstract:benefits or Abstract:loss or Abstract:Iaas or Abstract:Paas or Abstract:Saas or Abstract:"Cloud computing"))) and (PublishedAs:journal OR PublishedAs:proceeding OR PublishedAs:magazine) (TITLE-ABS-KEY(multi-tenancy OR multi-tenant) AND TITLE-ABS-KEY("Cloud computing"OR iaas OR paas OR saas OR advantages OR disadvantages OR approach OR barrier OR adoption OR viability OR approach OR methods OR techniques OR proposal OR framework OR tenant OR "product lines"OR variability OR variation OR adoption OR viability OR challenges OR problems OR benefits OR loss)) AND SUBJAREA(comp) (TITLE-ABS-KEY(multi-tenancy OR multi-tenant) AND TITLE-ABS-KEY("Cloud computing"OR iaas OR paas OR saas OR advantages OR disadvantages OR approach OR barrier OR adoption OR viability OR approach OR methods OR techniques OR proposal OR framework OR tenant OR "product lines"OR variability OR variation OR adoption OR viability OR challenges OR problems OR benefits OR loss))[All Sources(Computer Science)] (multi-tenancy wn TI OR multi-tenant wn TI OR multi-tenancy wn AB OR multi-tenant wn AB ) AND ("Cloud computing"wn TI OR iaas wn TI OR paas wn TI OR saas wn TI OR advantages wn TI OR disadvantages wn TI OR approach wn TI OR barrier wn TI OR adoption wn TI OR viability wn TI OR approach wn TI OR methods wn TI OR techniques wn TI OR proposal wn TI OR framework wn TI OR tenant wn TI OR "product lines"wn TI OR variability wn TI OR variation wn TI OR adoption wn TI OR viability wn TI OR challenges wn TI OR problems wn TI OR benefits wn TI OR loss OR "Cloud computing"wn AB OR iaas wn AB OR paas wn AB OR saas wn AB OR advantages wn AB OR disadvantages wn AB OR approach wn AB OR barrier wn AB OR adoption wn AB OR viability wn AB OR approach wn AB OR methods wn AB OR techniques wn AB OR proposal wn AB OR framework wn AB OR tenant wn AB OR "product lines"wn AB OR variability wn AB OR variation wn AB OR adoption wn AB OR viability wn AB OR challenges wn AB OR problems wn AB OR benefits wn AB OR loss)

Resultados 93

88

148

144

152

Tabela 3.2 Strings Search

28

3.2. SELEÇÃO DOS DADOS

Figura 3.2 Percentual de estudos retornados de acordo com a estratégia de busca

Figura 3.3 Percentual de estudos retornados pelas buscas automáticas

Scopus e 14% (88/625) na ACM. O gráfico da Figura 3.3 mostra o percentual de estudos retornados por cada engenho de busca. Identificados os potenciais estudos, eles precisam ser analisados para que sua relevância seja confirmada e trabalhos com pouca relevância sejam descartados.

3.2.2

Triagem dos Trabalhos

Segundo Travassos (Travassos and Biolchini, 2007) critérios de inclusão e exclusão devem ser baseados nas questões de pesquisas. Os mesmos servem para excluir estudos que não são relevantes para responder às questões da pesquisa. Durante uma leitura prévia dos abstracts dos artigos foi possível identificar alguns artigos que foram retornados na busca que não estavam relacionados ao contexto dessa pesquisa. Isso ocorreu pelo fato das palavras tenancy e tenant também serem utilizadas na área de engenharia civil. Outro ponto importante é identificar e remover resultados duplicados, já que muitos artigos

29

3.3. CLASSIFICAÇÃO

foram retornados em mais de uma fonte de pesquisa. Foram encontrados também alguns trabalhos aos quais o acesso era restrito. Diante desse cenário, com o objetivo de eliminar os trabalhos irrelevantes, foram definidos os seguintes critérios de exclusão: 1. Papers duplicados 2. Trabalhos não relacionados à arquitetura multi-tanancy 3. Poster, Panel e Workshop paper 4. Papers que não estejam escritos em inglês 5. Papers que não acessíveis na web. Após a aplicação dos critérios de exclusão foram eliminados os trabalhos irrelevantes como mostra a Tabela 3.3. Ao final da aplicação dos critérios de exclusão restaram 71 artigos que foram considerados relevantes para esses trabalho. Esses 71 papers podem ser vistos na Tabela A.1, no Apendice A. Cada paper é referenciado nesse mapeamento através do código descrito nessa tabela. A próxima seção apresenta o processo de análise e classificação desses trabalhos. CRITÉRIO Trabalhos duplicados Trabalhos não relacionados à arquitetura multi-tanancy Poster, Panel e Workshop paper Papers que não estejam escritos em inglês Papers que não acessíveis na web. TRABALHOS EXCLUÍDOS 297 233 14 3 7

Tabela 3.3 Resultado da aplicação dos critérios de exclusão

3.3

Classificação

Nessa seção será descrito o esquema de classificação e os resultados do agrupamento dos trabalhos de acordos com o esquema de classificação definido. O resultado desse agrupamento é apresentado através de tabelas e gráficos no decorrer dessa seção.

3.3.1

Esquema de Classificação

A idéia de categorização dos estudos foi baseado no processo definido por (Petersen et al., 2008). O resumo, título e palavras-chave de cada estudo são revisados em busca

30

3.3. CLASSIFICAÇÃO

de termos e conceitos que reflitam a contribuição do trabalho. Durante essa atividade é identificado também o contexto de cada pesquisa. Nesse processo palavras-chave de diferentes artigos são combinadas para desenvolver um entendimento de alto nível sobre a natureza e a contribuição da pesquisa. Isso auxiliou na definição de um conjunto de categorias que ajudaram representativamente no entendimento de nossa população de artigos. Em nosso estudo três categorizações foram criadas. A primeira delas verifica a área de interesse de multi-tenancy no qual o estudo é focado, por exemplo: banco de dados, alocação de recursos, customização, performance, segurança, escalabilidade, migração de sistemas, SOA e monitoramento. Essas categorias foram baseadas em nos trabalhos (Godse and Mulik, 2009) e (Höfer and Karagiannis, 2011), cada uma delas é descrita na Tabela 3.4. A segunda faceta (Tabela 3.6) agrupa os trabalhos de acordo com suas principais contribuições: framework, método/técnica, modelo, ferramenta e proposta de arquitetura. Essas duas primeiras facetas foram criadas apartir da identificação dos termos mais importantes existentes no título, resumo, introdução e conclusão dos estudos encontrados. No entanto, nesse trabalho também foi utilizado uma faceta que reflete a abordagem de pesquisa usada em cada artigo, independente do foco ou área associado ao artigo. Para isso foi considerado a classificação utilizada por (Wieringa et al., 2005). Essa classificação é descrita na Tabela 3.5.

3.3.2

Classificação dos trabalhos relevantes

Essa atividade consiste em agrupar os trabalhos relevantes de acordo com as questões de pesquisa e facetas definidas anteriormente. Durante essa atividade foi possível encontrar alguns trabalhos que poderiam auxiliar na resposta de mais de uma questão de pesquisa. É possível perceber também que tem-se poucos trabalhos relacionados à resposta da questão 4, isso pode ser um indicativo que essa área poderia ser melhor explorada. Tão importante quanto saber qual questão o trabalho responde é saber a qual contexto ele está relacionado. Baseado nesse princípio foram criadas as categorias descritas na Tabela 3.4. Na Tabela 3.8 os trabalhos são agrupados por contexto. O objetivo com isso é identificar em qual subárea de multi-tenancy o trabalho está focado. Por exemplo, quais trabalhos estudam a relação entre multi-tenancy e banco de dados, ou multi-tenancy e segurança, etc. Identificado o foco de cada trabalho, é necessário saber as contribuições de cada trabalho. Isso pode ajudar a saber em qual nível de maturidade as pesquisas relacionadas a multi-tenancy encontram-se. Dado que um dos objetivos desse trabalho é gerar insumos

31

3.3. CLASSIFICAÇÃO
CATEGORIA Alocação de recursos Banco de dados DESCRIÇÃO Essa categoria agrupa trabalhos que estudam ou propõem soluções para alocação eficiente de recursos(processamento, armazenamento, largura de banda) em uma arquitetura multi-tenancy. Métodos, técnicas e ferramentas que auxiliem na implementação de uma aplicação multi-tenancy para de banco de dados. Nessa categoria também inclui trabalhos que realizam comparativos e experimentos relacionados a técnicas de implementação de requisitos multi-tenancy para de banco de dados. Em muitos casos um tenant pode precisar de customizações específicas para poder atender às necessidades de um cliente. Nesse caso é necessário a aplicação de técnicas para implementar e gerenciar a variabilidade entre os tenants de uma aplicação multitenancy. Essa categoria agrupa trabalhos que estudam ou propõem ferramentas, técnicas ou métodos para resolver o problema de variabilidade de tenants. O principal objetivo de uma aplicação SaaS é atender a muitos clientes a um baixo custo. Nesse caso, permitir que a aplicação consiga atender a um número cada vez maior de clientes é de fundamental importância. Essa categoria agrupa trabalhos que abordem o problema de escalabilidade. Em muitos casos uma empresa pode possuir uma aplicação convencional e deseja transformá-la em uma aplicação multi-tenancy. Essa categoria agrupa trabalhos que estudem ou proponham uma solução para esse problema. Uma questão de grande importância para o sucesso de uma aplicação multi-tenancy é o atendimento à SLA definida para cada cliente. Os trabalhos associados a esse grupo apresentam estudos e propostas para monitoramento dos tenants da aplicação quanto à consumo de recursos ou qualidade de serviço. Esses trabalhos abordam metodologias e técnicas que otimizem a performance de uma aplicação. Tendo em vista que vários tenants podem compartilhar a mesma aplicação e o mesmo banco de dados, é vital para uma aplicação multi-tenancy isolar cada tenant de forma a não permitir acesso a dados não autorizados. Esses trabalhos abordam como SOA pode ser utilizada na implementação de uma aplicação multi-tenancy. Esses trabalhos abordam como virtualização pode ser utilizada para auxiliar o desenvolvimento de aplicações multi-tenancy.

Customização

Escalabilidade

Migração

Monitoramento

Performance Segurança

SOA Virtualização

Tabela 3.4 Faceta Contexto

para possíveis implementações futuras, é importante saber se já existem frameworks, ferramentas, métodos, modelos, arquiteturas, etc, que possam ser utilizadas durante uma possível implementação. A Tabela 3.9 apresenta os trabalhos agrupados por contribuição. Em alguns casos é possível que um trabalho apresente mais de uma contribuição e nesse caso irá aparecer em mais de uma categoria. Outra forma de mapear os trabalhos é atrávés do tipo de pesquisa realizado no trabalho, essa categorização foi descrita na Tabela 3.5 e o resultado de sua aplicação é apresentado na Tabela 3.10. Para um melhor entendimento da área pesquisada e do seu grau de maturidade, foi realizado o cruzamento de algumas categorizações. O objetivo dessa atividade é identificar por exemplo, quantos trabalhos tratam de métodos ou frameworks para resolver problemas

32

3.3. CLASSIFICAÇÃO
CATEGORIA Validation Research Evaluation Research DESCRIÇÃO As técnicas investigadas são novas e não foram implementadas ainda na prática. As técnicas usadas são ,por exemplo, experimentos realizados em laboratório. Técnicas são implementadas na prática e uma avaliação da técnicas é conduzida. É mostrado como a técnica é implementada na prática (solução de implementação) e quais são as consequências da implementação em termos de benefícios e perdas (avaliação da implementação). Isso também inclui identificar problemas na indústria. A solução para o problema é proposto, a solução pode ser nova ou uma extensão significativa de uma técnica existente. Os potenciais benefícios e a aplicabilidade da solução é mostrada por pequenos exemplos ou uma boa linha de argumentação Esses artigos esboçam uma nova forma de visualizar coisas existentes pela estruturação do campo de pesquisa em termos de taxonomia ou framework conceitual. Esses artigos expressam uma opinião pessoal de alguém sobre alguma técnica ou se ela é boa ou ruim, ou como as coisas deveriam ser feitas. Eles não dependem de trabalhos relacionados ou metodologias de pesquisa. Artigos de experiência explicam o que e como algo vem sendo feito na prática. Deve ser uma experiência pessoal do autor.

Solution Proposal Philosophical Paper Opinion Paper

Experience Paper

Tabela 3.5 Faceta Tipos de pesquisa (Fonte: (Wieringa et al., 2005))

de performance de uma aplicação multi-tenancy, ou quais trabalhos apresentam soluções para monitoramento de aplicações multi-tenancy, dentre outros. As Figuras 3.4, 3.5, 3.6 e 3.7 apresentam o resultado desse mapeamento. Observando a Figura 3.4 é possível perceber que a maioria dos trabalhos encontrados foram publicados nos anos de 2010 e 2011, e dentre esses o os principais temas de pesquisa foram customização, performance, segurança, alocação de recursos e banco de dados. Pode-se observar também que em todos os anos temos publicações realcionadas a bancos de dados, customização e performance, isso é um indicativo de que tais áreas possuem aparentemente maior relevância para o desenvolvimento de aplicações multitenancy. Essa figura pode ser muito útil para que pesquisadores possam identificar áreas pouco exploradas no campo de desenvolvimento de aplicações multi-tenancy, de forma a servir como ponto de partida para seus trabalhos de pesquisa. A Figura 3.5 foi criada com o objetivo de auxiliar em decisões a serem tomadas durante o processo de desenvolvimento de software. Durante esse processo é muito comum dúvidas sobre qual técnica será utilizada para implementar o mecanismo de customização da aplicação, qual mecanismo de armazenamento de dados será utilizado, como poder-se-á garantir uma performance aceitável para a aplicação. Observando o gráfico foi possível verificar que a maioria dos trabalhos apresentava algum método/técnica ou alguma proposta de arquitetura para multi-tenancy e a área mais carente de trabalhos é escalabilidade. A maioria dos métodos e técnicas apresentados tratam de assuntos como banco

33

3.3. CLASSIFICAÇÃO
CATEGORIA DESCRIÇÃO Framework Essa categoria agrupa trabalho que apresentam frameworks que auxiliam no desenvolvimento de aplicações multi-tenancy. Consideramos framework como um construto fundamental que define pressupostos, conceitos, valores e práticas, e que inclui orientações para a execução propriamente dita (Tomhave, 2005). Método ou Trabalhos que apresentam métodos e técnicas que tem o objetivo de resolver algum problema específico durante a implementação de aplicações multi-tenancy técnica Modelo Agrupa trabalhos que definem construções conceituais que auxiliam no desenvolvimento de aplicações multi-tenancy. Consideramos modelo como um resumo, uma construção conceitual que representa processos, variáveis e relacionamentos, sem prover orientações específicas ou práticas para implementação (Tomhave, 2005). Ferramenta Essa categoria agrupa ferramentas implementadas para atender à algum requisito de multi-tenancy ou para auxiliar durante o desenvolvimento de uma aplicação. Proposta de Agrupamento de propostas de arquitetura para implementação de aplicações multiArquitetura tenancy ou propostas de arquitetura de plataformas de suporte à multi-tenancy.

Tabela 3.6 Faceta Contribuição (Fonte: (Wieringa et al., 2005))
Questão Q1 Q2 Artigos Relacionados EP09, EP11, EP12, EP13, EP15, EP32, EP44, EP45, EP54, EP55, EP57, EP66 EP03, EP04, EP05, EP06, EP07, EP08, EP09, EP1, EP11, EP13, EP15, EP16, EP17, EP18, EP19, EP20, EP21, EP22, EP23, EP24, EP26, EP27, EP28, EP29, EP30, EP31, EP32, EP33, EP35, EP38, EP39, EP40, EP41, EP42, EP43, EP44, EP46, EP47, EP48, EP49, EP50, EP51, EP52, EP53, EP56, EP57, EP58, EP59, EP60, EP61, EP62, EP63, EP64, EP65, EP66, EP67, EP68, EP69, EP70, EP71 E0P8, EP02, EP05, EP06, EP07, EP10, EP14, EP16, EP25, EP29, EP30, EP34, EP36, EP37, EP47, EP57 EP05, EP08, EP11, EP26, EP45

Q3 Q4

Tabela 3.7 Artigos associados por Questão de pesquisa

de dados, customização, performance e segurança. Já as arquiteturas e geral focam mais em banco de dados e customização. Ainda assim, foram encontrados trabalhos que apresentam arquiteturas que tratam de assuntos como alocação de recursos, escalabilidade, performance, segurança e arquiteturas que se beneficiam de integração de serviços com forte influência de SOA. Para identificar as lacunas existentes na área de pesquisa foi criada a Figura 3.6, com o objetivo de identificar quais tipos de pesquisa foram desenvolvidos em cada contexto relacionado a multi-tenancy. Observou-se que a maioria dos trabalhos apresenta propostas de solução e que tem-se poucos trabalhos objetivando realizar experimentos e validações dessas propostas na indústria. É possível observar a grande evolução das pesquisas na área de customização. Em geral, os autores desses trabalhos são pesquisadores da área de SPL(Software Product Lines) que vislumbraram em multi-tenancy uma oportunidade de aplicar seus conhecimentos de customização. A Figura 3.7 apresenta um mapeamento dos tipos de pesquisa por questão de pesquisa,

34

3.3. CLASSIFICAÇÃO
Contexto Alocação de Recursos Banco de Dados Customização Escalabilidade Migração Monitoramento Performance Segurança SOA Virtualização Artigos Relacionados EP13, EP26, EP32, EP39, EP51, EP55, EP66, EP70 EP03, EP05, EP08, EP09, EP20, EP24, EP28, EP45, EP49, EP57, EP60, EP61, EP63, EP64, EP67, EP69 EP01, EP02, EP05, EP07, EP10, EP14, EP16, EP24, EP25, EP30, EP34, EP36, EP37, EP39, EP42, EP44, EP47, EP55, EP63, EP70 EP31, EP39, EP62, EP70 EP21, EP41, EP71 EP17, EP43 EP01, EP06, EP09, EP15, EP19, EP23, EP38, EP40, EP51, EP52, EP56, EP62 EP01, EP05, EP18, EP22, EP23, EP24, EP35, EP44, EP45, EP54, EP58, EP68 EP11, EP29, EP33, EP46, EP48, EP50 EP04,EP53,EP65

Tabela 3.8 Artigos agrupados por contexto
Contribuição Proposta de Arquitetura Ferramenta Framework Método/Técnica Artigos Relacionados EP09, EP17, EP31, EP33, EP39, EP40, EP44, EP45, EP46, EP48, EP56, EP58, EP63, EP70 EP15, EP42, EP61, EP69 EP01, EP05, EP10, EP26, EP27, EP32, EP38, EP47, EP50, EP53 EP02, EP03, EP04, EP06, EP07, EP08, EP11, EP13, EP16, EP18, EP19, EP20, EP21, EP22, EP23, EP25, EP28, EP29, EP35, EP36, EP41, EP43, EP52, EP64, EP65, EP66, EP69, EP71 EP30, EP49, EP51, EP60, EP62, EP68

Modelo

Tabela 3.9 Artigos agrupados por contribuição

esse cruzamento de informações ajudou a organizar os dados de forma a identificar para cada questão de pesquisa quais os tipos de trabalhos que mais foram realizados. Percebeuse que a questão de pesquisa 2 (Quais as propostas existentes para implementação da arquitetura multi-tenancy?) possui a maior quantidade de trabalhos associados, mas que a maioria são propostas de solução que ainda não foram validadas na indústria. Isso indica a necessidade de integração dos pesquisadores dessas áreas com o mercado de forma a validar as propostas apresentadas e evoluir o campo de pesquisa. Embora os gráficos apresentados até aqui tenham sido de grande relevância para esse trabalho, durante a leitura dos trabalhos encontrados foi encontrado algumas informações importantes que podem ajudar os leitores a entender melhor cada contexto relacionado a multi-tenancy. A seção a seguir apresenta as principais descobertas realizadas durante essa leitura.

35

3.3. CLASSIFICAÇÃO

Figura 3.4 Quantidade de artigos agrupados por Contexto e Ano

Figura 3.5 Quantidade de artigos agrupados por Contexto e Contribuição

36

3.3. CLASSIFICAÇÃO

Figura 3.6 Quantidade de artigos agrupados por Contexto e Tipo de Pesquisa

Figura 3.7 Quantidade de artigos agrupados por Questão e Tipo de Pesquisa

37

3.4. PRINCIPAIS DESCOBERTAS
Tipo de pesquisa Validation Research Evaluation Research Solution Proposal Artigos Relacionados EP28, EP31, EP42, EP50, EP57, EP61, EP62, EP66, EP67, EP69 EP05, EP11, EP37 EP01, EP02, EP04, EP07, EP08, EP13, EP14, EP15, EP16, EP17, EP18, EP19, EP20, EP21, EP22, EP23, EP25, EP26, EP27, EP29, EP30, EP32, EP33, EP35, EP36, EP38, EP39, EP40, EP41, EP43, EP46, EP47, EP48, EP49, EP51, EP52, EP53, EP56, EP58, EP60, EP64, EP65, EP68, EP70, EP71 EP10, EP59 EP03,EP12 EP06, EP09, EP24, EP34, EP44, EP45, EP54, EP55, EP63

Philosophical Paper Opinion Paper Experience Paper

Tabela 3.10 Artigos agrupados por Tipo de Pesquisa

3.4
3.4.1

Principais Descobertas
Alocação de Recursos

Para que se possa desfrutar dos benefícios que uma aplicação multi-tenancy traz, um conjunto de desafios devem ser solucionados (Kwok and Mohindra, 2008): 1. calcular os recursos computacionais necessários para o funcionamento de cada novo tenant, e ao mesmo tempo atender às restrições de todos os tenants em instância da aplicação compartilhada. 2. Identificar fatores limitantes ou gargalos nos recursos computacionais requeridos para as várias instâncias, cada uma com vários tenants contendo diferentes restrições que devem ser atendidas. 3. Durante a distribuição dos tenants é necessário indicar a melhor localização para que nenhuma restrição de SLA seja violada. 4. A distribuição dos tenants e instâncias em um ambiente de computação distribuído deve ser automatizada. 5. A economia alcançada entre as diferentes formas de distribuições de tenants e instâncias deve ser comparada e otimizada, de forma que seja encontrada a melhor distribuição possível. O cálculo do número máximo de usuários e tenants em uma instância compartilhada em um servidor, sem que haja violação de restrições definidas no contrato de SLA de

38

3.4. PRINCIPAIS DESCOBERTAS

cada tenant é um desafio não trivial. Em (Kwok and Mohindra, 2008) os autores propõem uma abordagem para o cálculo de recursos requeridos para o bom funcionamento de vários tenants em uma instância de aplicação compartilhada. Nesse trabalho também é descrito um método para otimizar a distribuição de tenants e instâncias de uma aplicação em um conjunto de servidores sem violar qualquer requisito de SLA dos tenants. Por fim os autores apresentam uma ferramenta que tem o objetivo de auxiliar o deployment de aplicações multi-tenancy usando o número mínimo de servidores, fornecendo portanto o máximo de economia em um ambiente de computação distribuído. Em (Fehling et al., 2010), os autores também realizam um estudo sobre as oportunidades de otimização do uso de recursos, mas nesse caso o cenário considerado é um ambiente de computação heterogêneo onde os recursos utilizados são oriundos de clouds públicas e privadas. Nesse trabalhos os autores utilizam um algoritmo Smarter Simulated Annealing para auxiliar na busca de uma distribuição otimizada dos recursos computacionais. Outra questão associada à alocação de recursos é a priorização das requisições recebidas por uma instância de uma aplicação multi-tenancy. Em um cenário multi-tenancy é comum que cada tenant necessite priorizar as requisições de seus consumidores de tal maneira que um consumidor com prioridade alta poderá ser atendido mais rapidamente que outro, e que a instância da aplicação também priorize os tenants, de forma que as requisições de um tenant tenha maior prioridade de atendimento que outros. Diante desse cenário, os autores de (Tsai et al., 2010b) propõem um modelo para priorizar requisições de vários tenants enquanto preserva as prioridades locais das requisições de um tenant específico. Os autores propõem um algoritmo chamado Crystalline Mapping que mapeia prioridades internas de um tenant específico para prioridades globais.

3.4.2

Banco de Dados

Uma das preocupações quando pretende-se implementar uma aplicação multi-tenancy é planejar como os dados da aplicação serão armazenados. Atualmente, boa parte das aplicações existentes no mercado utilizam bancos de dados relacionais. Existem várias estratégias para implementar um esquema de banco de dados relacional de forma que ele permita o armazenamento de dados de vários tenants. (Aulbach et al., 2008) apresenta várias dessas técnicas, que são mostradas na Figura 3.8 e brevemente descritas a seguir: • Basic Layout - a técnica mais básica para implementar multi-tenancy é adicionar uma coluna TENANTID em cada tabela para armazenar um valor que identifica

39

3.4. PRINCIPAIS DESCOBERTAS

a qual tenant um registro pertence. Essa abordagem provê uma boa consolidação mas não provê uma boa extensibilidade, já que não possui nenhum mecanismo para customização de armazenamento de dados para um tenant específico. • Private Table - é a forma mais básica para suportar extensibilidade, dado que cada tenant possui sua próprias tabelas privadas. Nessa abordagem, é necessário uma camada de transformação de queries para ajustar o nome das tabelas nas queries e substituir pelo nome da tabela privada. • Extension Table - essa técnica é a combinação das duas técnicas anteriores, as tabelas de extensão bem como as tabelas base devem possuir uma coluna para armazenar os dados de identificação do tenant. Outra coluna também precisa ser adicionada para armazenar a tabela lógica para que os dados possam ser reconstruídos. Essa abordagem é utilizada para mapear esquemas orientados a objeto com herança no modelos relacional atualmente. • Universal Table - estruturas genéricas permitem a criação de um número arbitrário de tabelas com formas arbitrárias. Universal Table é uma estrutura genérica com uma coluna Tenant, uma coluna Table e um grande número de colunas de dados genéricas. A coluna de dados tem um tipo flexível, como VARCHAR, no qual outro tipo pode ser convertido. • Pivot Table - nessa técnica as entidades de domínio são representadas por tabelas lógicas, cujas informações são montadas dinâmicamente. Uma Pivot Table possui as seguintes colunas: Tenant(identifica o tenant), Table(identifica a tabela à qual o dado está associado), Row(identificar a linha à qual o dado está associado) Col(identifica o campo que a linha representa) e uma coluna para armazenar o dado em si, que pode ser armazenada em um tipo flexível como VARCHAR. Essa abordagem proporciona uma alta flexibilidade mas possui muitas colunas de metadados que podem impactar negativamente na performance da aplicação, durante a manipulação dos dados. • Chunk Table - essa técnica é uma extensão da técnica anterior e trabalha com o conceito de Chunk Table. Uma Chunk Table é semelhante a uma Pivot Table exceto pelo fato de possuir um conjunto de colunas de dados de vários tipos, e a coluna Col é substituida pela coluna Chunk. Em comparação com a técnica Pivot Table, essa técnica armazena uma quantidade menor de metadados, o que diminui o tempo de reconstrução da tabela lógica.

40

3.4. PRINCIPAIS DESCOBERTAS

• Chunk Folding - as tabelas lógicas são verticalmente particionadas em chunks, os quais permitem junção quando necessário. Essas são as técnicas básicas para a implementação de modelos de dados para aplicações multi-tenancy, outras abordagens foram criadas apartir delas como é o caso de (Foping et al., 2009; Xue et al., 2011; Weiliang et al., 2010). Em (Aulbach et al., 2009) é realizado um estudo experimental para comparar cinco técnicas de implementação de aplicações multi-tenancy a nível de banco de dados. Os autores concluíram que ainda não existe um Sistema de Gerenciamento de Banco de Dados(SGBD) ideal para esse tipo de aplicação e que um SGBD para SaaS deveria ser baseado na técnica Private Table. Schiller (Schiller et al., 2011) apresenta em seu trabalho as primeiras funcionalidades para que um SGBD relacional possa suportar múltiplos tenants nativamente. Em sua proposta tenants são introduzidos como objetos de primeira classe e é proposto o conceito de "contexto"para isolar um tenant de outro. Além disso, o conceito de herança permite compartilhar o esquema da aplicação entre os tenants, ao mesmo tempo em que permite que o esquema seja extendido com estruturas de dados adicionais. Ao final do trabalho o autor realiza uma avaliação da implementação de sua proposta através de experimentos.

3.4.3

Customização

Um ponto importante em uma aplicação multi-tenancy é a customização. Em aplicações web customizáveis o código torna-se mais complexo, problemas de performance impactam todos os tenants da aplicação e planejar segurança e robustez tornam-se pontos importantes. Segundo (Jansen et al., 2010), existem três áreas de pesquisa que são diretamente relacionadas a Técnicas de Realização de Customização(Customization Realization Techniques - CRT) em aplicações multi-tenancy: variabilidade em linhas de produtos de software, personalização do usuário final em aplicações web e arquiteturas multi-tenancy. Pesquisadores que pretendem atacar esse problema devem direcionar seus estudos nessas três áreas. Outro ponto importante é que os tenants de uma aplicação multi-tenancy não somente tem diferentes requisitos com respeito a propriedades funcionais, mas também podem exigir diferentes propriedades de qualidade de serviço como privacidade e performance. Alguns tenants exigem que a aplicação possua alta disponibilidade e estão dispostos a pagar um alto preço pelo uso desse serviço. Outros tenants não estão interessados em alta disponibilidade mas preocupam-se mais com um baixo preço. Em casos como esse é necessário que exista na aplicação algum mecanismo para ajustar a aplicação às reais

41

3.4. PRINCIPAIS DESCOBERTAS

Figura 3.8 Técnicas de mapeamento de esquema(Fonte: (Aulbach et al., 2008))

42

3.4. PRINCIPAIS DESCOBERTAS

necessidades do usuário, no tocante aos casos citados anteriormente.

3.4.4

Escalabilidade

Para alcançar economia de escala, esse é um dos problemas mais críticos para serem resolvidos em um cenário real. Dado um número fixo de servidores, é necessário otimizar a distribuição dos tenants de forma a maximizar o número total de tenants possíveis sem violar seus requisitos de SLA e ainda estar preparado para o crescimento do volume de dados e de requisições. Em (Yuanyuan et al., 2009), os autores apresentam uma arquitetura focada na escalabilidade de dados. Eles propõem uma entidade com base em grupos de particionamento horizontal, através da análise das relações entre as entidades de uma aplicação multitenancy. Nessa abordagem, entidades de negócio altamente coesas formam um grupo de entidades e o particionamento ocorre com base nesse grupo. Dessa forma cada operação acessa um único grupo de instâncias, podendo obter os dados necessários através do acesso a um único banco de dados e evitando a necessidade de transações distribuídas. (Koziolek, 2010) e (Koziolek, 2011) apresentam um estilo arquitetural focado em escalabilidade de dados e ilustra como os conceitos apresentados nesses trabalhos podem ajudar a fazer as Plataformas como Serviço(PaaS) atuais como Force.com,Windows Azure, e Google App Engine escaláveis e customizáveis. Já em (Zhang et al., 2010b), os autores focam no problema de localização de tenants, propõem um algoritmo heurístico chamado Tenant Dispatch Heuristic(TDH) e realizam um conjunto de simulações e comparações onde é avaliado como o uso desse algoritmo impacta na escalabilidade e economia de recursos.

3.4.5

Migração

Migrar aplicações web legadas que trabalham com um único tenant(Isolated Tenancy Hosted Applications - ITHA) para multi-tenancy(multi-tenancy Enabled Application MTEA) é não é uma tarefa trivial, devido a quantidade de ferramentas e técnicas de migração apropriadas. De acordo com (Zhang et al., 2010a) os métodos existentes para migração são muito abstratos ou muito específicos quando tentamos aplicá-los como guias para migrar uma aplicação que trabalha com um tenant isolado para uma aplicação multi-tenancy. Nesse mesmo trabalho os autores propõem um método sistemático que provê diretrizes para migrar aplicações ITHA para MTEA, levando em conta custo, risco e efetividade do método de migração.

43

3.4. PRINCIPAIS DESCOBERTAS

Dado a característica de demanda sazonal existente em vários tipos de aplicação, uma funcionalidade essencial para um ambiente multi-tenancy é a funcionalidade que permite a migração de tenants entre hosts, uma técnica chamada live migration(Clark et al., 2005; Liu et al., 2009). Em (Elmore et al., 2011) os autores apresentam Zephyr, uma técnica para live migration que tem o objetivo de minimizar a interrupção de serviço do tenant migrado. Através da introdução de uma sincronização dupla que permite a ambos os nós, o nó origem dos dados e o nó destino, executarem simultaneamente transações para o tenant. A migração inicia-se com a transferência dos metadados do tenant para o nó destino, que pode realizar novas transações enquanto o nó origem completa as transações que foram iniciadas quando a migração se iniciou. De acordo com os autores, live migration é uma importante característica para habilitar elasticidade em bancos de dados multi-tenancy para plataformas de cloud.

3.4.6

Monitoramento

Para obter uma visão geral do funcionamento de seus serviços, provedores de serviço precisam de informações sobre todas as camada de seus sistema, incluindo a aplicação, máquinas virtuais e uso de rede. Por razões de simplicidade, todas essas informações devem idealmente ser entregues através de uma única interface de monitoramento. Em (Hasselmeyer and d’Heureuse, 2010) os autores apresentam alguns requisitos básicos de uma infraestrutura de monitoramento para ambientes multi-tenancy: • Multi-tenancy: a infraestrutura de monitoramento precisa naturalmente ser capaz de lidar com informações de monitoramento provinientes de diferentes clientes (tenants). • Escalabilidade: uma solução de monitoramento precisa ser escalável em vários aspectos. Ela precisa escalar para um grande número de agentes de monitoramento, de notificação de eventos, de tenants, de recursos(virtuais e físicos, servidores, elementos de rede e aplicações), e de tipos de informação de monitoramento. • Dinamismo: sistemas de monitoramento multi-tenancy precisam suportar o dinamismo que é inerente a um ambiente multi-tenancy. Esse dinamismo decorre da rápida e frequente adição e remoção de tenants no datacenter. Além disso, a alocação de recursos para os tenants também está em constante mudança e o conjunto de recursos que está sendo monitorado também pode mudar.

44

3.4. PRINCIPAIS DESCOBERTAS

• Simplicidade: o sistema de monitoramento deveria ser simples em dois aspectos: primeiro, a interface para monitoramento do sistema precisa ser fácil de entender e usar. Segundo, o sistema precisar ser fácil de instalar e manter, tanto para quem gerencia o datacenter quanto para os consumidores. Uma API simples é desejável, uma vez que facilita o trabalho de desenvolvedores que criam soluções de controle e monitoramento. • Abrangência: esse requisito aborda a necessidade de uma infraestrutura única de monitoramento que deve ser utilizável para todos os tipos de informação de monitoramento, não importa o que está relacionado ao recurso ou qual o significado que ele transmite. Essa abrangência aplica-se a multiplos aspectos: tipos de dados, fontes de notificação e tenants. Já em (Cheng et al., 2009) os autores propõem um mecanismo de controle que monitora a qualidade de serviço por tenant, detecta situações anormais e dinamicamente ajusta o uso de recursos baseado nos parametros de SLA definidos para o tenant. Nesse trabalho os autores apresenta sua proposta e realizam um estudo experimental para avaliar os resultados.

3.4.7

Performance

Esse assunto está diretamente ligado à monitoramento de aplicações multi-tenancy, isso porque aplicações são monitoradas para que se possa verificar se a mesma está executando em um nível de performance compatível com a SLA definida para o cliente. Desde 2008 temos um bom número de trabalhos que estudam esse problema, dentre eles estão propostas de arquitetura, frameworks, métodos, técnicas, ferramentas e experimentos, que utilizam as mais variadas abordagens. O primeiro trabalho encontrado relacionado à performance foi (Wang et al., 2008a), onde os autores apresentam os principais padrões de implementação de aplicações multi-tenancy que tratam dos aspectos de isolamento e segurança, e avaliam a performance desse padrões através de uma série de experimentos e simulações. Para permitir que um provedor de serviço ofereça diferentes níveis de performance baseado no nível de SLA definido para um tenant específico, (Lin et al., 2009b) propõe uma solução que utiliza um regulador de performance baseado no controle de feedback. O regulador possui uma estrutura hierárquica, na qual um controlador de alto nível gerencia a taxa de admissão de requisições para prevenir sobrecarga e um controlador de baixo nível que gerencia os recursos alocados pelas requisições admitidas para alcançar um

45

3.4. PRINCIPAIS DESCOBERTAS

nível específico de diferenciação de serviço entre os tenants que compartilham os mesmos recursos. Um protótipo dessa abordagem é implementado utilizando Tomcat e MySQL e ao final são realzados alguns experimentos para validar a proposta. Outro ponto importante é o isolamento de performance para prevenir protenciais anomalias de comportamento de um tenant, que possam afetar a performance de outros tenants que compartilham os mesmos recursos. Em (Li et al., 2008) os autores propõem o SPIN(Service Performance Isolation Infrastructure) que visa permitir um abrangente compartilhamento de recursos em ambientes multi-tenancy. Uma vez que alguns tenants agressivos podem interferir na performance de outros tenants, SPIN fornece um relatório de anomalias, identifica os tenants agressivos, e fornece um mecanismo de moderação para eliminar o impacto negativo em outros tenants. Durante sua pesquisa os autores implementaram um protótipo do SPIN e realizaram alguns experimentos para demonstrar sua eficiência. Um desafio interessante na área de gerenciamento de performance é entender e predizer performance de sistemas. Durante a realização desse mapeamento foram encontradas duas abordagens relacionadas a esse assunto. (Schaffner et al., 2011) apresenta um estudo sobre a automação de tarefas operacionais em clusters multi-tenancy de bancos de dados em memória orientados a coluna. Foi desenvolvido um modelo para predizer se a alocação de um tenant em um servidor no cluster levaria a uma violação no tempo de resposta esperado. Já em (Ahmad and Bowman, 2011) é realizado um estudo experimental para entender e predizer a performance de sistemas, nesse trabalho os autores sugerem uma abordagem de máquina de aprendizado que usa dados monitorados para entender a performance do sistema. (Guo et al., 2007) apresenta um framework que possui um componente específico para isolamento de performance. Segundo os autores os objetivos principais do isolamento de performance incluem dois aspectos. Primeiro, evitar que o comportamento(potencialmente ruim) de um tenant afete o comportamento de outro tenant de maneira imprevista. Segundo, evitar a injustiça entre tenants em termos de performance de uso. Para alcançar esse objetivo os autores sugerem um padrão de isolamento de performance híbrido, baseado em várias técnicas apresentadas em seu trabalho.

3.4.8

Segurança

Confiança é um dos maiores desafios que influenciam a ampla aceitação de SaaS. Na ausência de confiança em SaaS, segurança e privacidade de dados figuram entre os principais e mais importantes assuntos relacionados a arquitetura multi-tenancy. Foram

46

3.4. PRINCIPAIS DESCOBERTAS

encontrados durante nossa pesquisa alguns trabalhos publicados nos últimos 2 anos que estão relacionados a esse assunto. Um assunto bastante relevante é a avaliação de credibilidade de tenants, que indica quais tenants tem um comportamento que possa prejudicar o funcionamento dos demais. Zhiqiang(Nie, 2010) apresenta um algoritmo de avaliação de credibilidade de tenants baseado na experiência. Essa abordagem visa realizar a detecção e gerenciamento de tenants maliciosos a um baixo custo. De acordo com o histórico de acesso dos tenants, ele pode calcular a credibilidade de tenants, atribuir privilégios de acesso e determinar estratégias de detecção e monitoramento. De acordo com (Li et al., 2010) separação de responsabilidade de segurança entre provedores SaaS e consumidores precisa ser suportada em um ambiente de cloud. Arquitetura multi-tenancy baseada em modelo de controle de acesso (MTACM - multi-tenancy based access control model) foi projetada para inserir o princípio de separação de responsabilidade de segurança em cloud; essa arquitetura define dois níveis de granularidade no mecanismo de controle de acesso. O primeiro nível está relacionado ao provedor de serviço, que compartilha sua infraestrutura entre vários clientes. O segundo nível é o nível da aplicação onde uma mesma aplicação hospeda informações de vários tenants. Em (Zhang et al., 2009; Calero et al., 2010; Tsai and Shao, 2011) são apresentadas três abordagens diferentes para implementação de mecanismos de segurança e controle de acesso para aplicações multi-tenancy. Em (Zhang et al., 2009) é proposta uma abordagem de controle de acesso baseado em restrições de privacidade customizáveis. Essa abordagem combina criptografia de dados e separação de informação e define três tipos de restrições de privacidade baseado na funcionalidade de customização em aplicações SaaS. (Calero et al., 2010) descreve um sistema de autorização para um serviço de middleware em uma PaaS, que suporta controle de acesso baseado em hierarquia de funções, hierarquia de objetos baseada em caminho e federações. Os autores apresentam também uma arquitetura de sistema de autorização para implementação do modelo. De acordo com Wei-Tek(Tsai and Shao, 2011) as abordagens atuais para controle de accesso em cloud não escalam bem para requisitos multi-tenancy porque eles são baseados principalmente em identificadores(IDs) de usuário individual em diferentes níveis de granularidade. No entanto, o número de usuários pode ser enorme e causar um overread significante no gerenciamento de segurança. RBAC (Role-Based Access Control) torna-se atrativo nesse caso pelo fato do número de papéis de usuário em uma aplicação ser significativamento menor, e usuários podem ser classificados de acordo com seus papéis. Wei-Tek propõe um RBAC usando uma ontologia de papéis para arquitetura

47

3.5. MAPEAMENTO DAS EVIDÊNCIAS

multi-tenancy em clouds.

3.4.9

SOA

De acordo com o cenário apresentado até aqui, é possível perceber que seria muito difícil e caro criar uma aplicação multi-tenancy que fosse tão configurável a ponto de permitir que todos os requisitos do usuário pudessem ser atendidos através de configurações. Mesmo nesse cenário é possível permitir que os próprios usuários implementem parte de suas soluções e as integrem à plataforma multi-tenancy utilizada. Para solucionar esse problema, alguns autores propuseram abordagens para implementar arquitetura multi-tenancy com SOA. Afkham Azeez(Azeez et al., 2010) apresenta uma arquitetura para implementar multitenancy no nível de SOA, que habilita usuários a executar seus serviços e outros artefatos SOA em um framework multi-tenancy SOA, bem como prover um ambiente para construir aplicações multi-tenancy. Em seu trabalho os autores discutem arquitetura, decisões de projeto, e problemas encontrados, juntamente com potenciais soluções. Diferentes aspectos de arquitetura de sistemas no que se refere a multi-tenancy para SOA também são considerados como: deployment de serviços, envio de mensagens, segurança, execução de serviços e finalmente acesso a dados. Junjie Jing(Jing and Zhang, 2010) apresenta uma arquitetura aberta para construir soluções SaaS. Um benefício dessa abordagem é a diminuição do acoplamento, o que traz maior flexibilidade para aplicações SaaS. Por um lado novos serviços podem facilmente se juntar aos existentes, por outro lado pode-se também reprogramar um serviço para gerar um novo serviço de acordo com as necessidades do negócio. Dessa forma aplicações multi-tenancy baseadas em SOA podem ser consideradas alteráveis e extensíveis para suportar resposta rápida e agilidade operacional.

3.5

Mapeamento das evidências

Nessa seção, são apresentados os resultados para cada questão de pesquisa. Na Seção 3.5.1 são apresentadas a evidências relacionada à vantagens e desvantagens da adoção da arquitetura multi-tenancy. Na Seção 3.5.2 são apresentadas as evidências relacionadas à propostas existentes que podem auxiliar a adoção e implementação de multi-tenancy, bem como frameworks, APIs e ferramentas relacionadas a esse tema. Na Seção 3.5.3 são descritos evidências que apresentam formas de gerenciar variabilidade entre tenants de uma aplicação multi-tenancy, nessa seção são apresentadas abordagens e propostas de

48

3.5. MAPEAMENTO DAS EVIDÊNCIAS

solução para esse problema. Por último a seção 3.5.4 apresenta evidências que podem auxiliar durante a tomada de decisão de adotar ou não a arquitetura multi-tenancy.

3.5.1

Q1 - Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy?

Essa questão busca identificar em meio aos trabalhos encontrados, evidências que apontem vantagens e desvantagens da adoção da arquitetura multi-tenancy. Durante esse trabalho foram identificados 12 trabalhos que citam alguma vantagem ou desvantagem da adoção de multi-tenancy. Apartir da leitura dos mesmos identificamos as seguintes vantagens: • O provedor de serviço pode usar a mesma versão da aplicação(com o único código base) para prover serviços para várias organizações(Tsai et al., 2010b) • Consumidores obtém acesso à capacidade de processamento elástico que pode ser aumentada ou diminuida de acordo com a demanda se a necessidade de realizar manutenção em servidores(Tsai et al., 2010b) • Dois benefícios de uma abordagem baseada em uma plataforma multi-tenancy são colaboração e integração. Pelo fato de todas as aplicações executarem em um único espaço, torna-se mais fácil permitir a um usuário de qualquer aplicação acesso à uma coleção de dados. Essa capacidade simplifica o esforço necessário para integrar aplicações relacionadas e os dados que elas gerenciam(Weissman and Bobrowski, 2009) • Atualização do software de uma só vez para todos os tenants(Mietzner et al., 2009a) • Economia nos custos com infra-estrutura de hardware(Shwartz et al., 2009)(Kwok and Mohindra, 2008)(Aulbach et al., 2009) • Economia nos custos de gerenciamento de infra-estrutura(Shwartz et al., 2009)(Kwok and Mohindra, 2008)(Aulbach et al., 2009) • Os tenants podem obter acesso imediato às últimas melhorias e inovações sem gastar seu próprio orcamento de TI(Kwok and Mohindra, 2008) • Aumento da margem de lucro para o provedor de serviço através da redução dos custos de entrega e diminuição dos custos de assinatura do serviço para os clientes(Li et al., 2008)

49

3.5. MAPEAMENTO DAS EVIDÊNCIAS

• Possibilidade de reusar regras de negócio com o mínimo de adaptação(Bezemer et al., 2010) • Organização dos usuários em vários níveis de acordo com suas necessidades e melhor gerenciamento de recursos(Jasti et al., 2010) • O usuário pode customizar sob-demanda os serviços providos pelo fornecedor do software(Zheng et al., 2010) • Redução dos custos de venda e manutenção do software por porte do provedor do software(Zheng et al., 2010) As desvantagens da adoção de multi-tenancy foram pouco mencionadas nos trabalhos encontrados. Em geral os trabalhos mencionavam mais vantagens do que desvantagens. A seguir são listados alguns pontos considerados vantagens e desvantagens por alguns autores: • É difícil calcular os recursos requeridos por cada novo tenant e ao mesmo tempo garantir que as restrições de todos os outros tenants da mesma instância sejam atendidas(Kwok and Mohindra, 2008) • Fatores limitantes e gargalos nos recursos computacionais exigidos pelas várias instâncias devem ser identificados(Kwok and Mohindra, 2008), e isso não é trivial nesse tipo de ambiente • Dificuldade de comparar e otimizar a redução de custos das diferentes formas de distribuição dos tenants entre os servidores, pelo fato de existirem várias variáveis envolvidas(Kwok and Mohindra, 2008) • Preocupação das empresas com o custo inicial de reestruturas suas aplicações legadas para multi-tenancy(Bezemer and Zaidman, 2010) • Preocupação dos mantenedores de software com a possibilidade de multi-tenancy introduzir problemas adicionais de manutenção decorrentes do fato desses novos sistemas serem altamente customizáveis(Bezemer and Zaidman, 2010)

3.5.2

Q2 - Quais as propostas existentes para implementação da arquitetura multi-tenancy?

Essa questão visa identificar trabalhos que possam auxiliar na possível implementação de uma aplicação multi-tenancy. Frameworks, ferramentas, modelos, propostas de

50

3.5. MAPEAMENTO DAS EVIDÊNCIAS

arquitetura, métodos ou técnicas que possam auxiliar no desenvolvimento de aplicações multi-tenancy são identificados e catalogados. Um ponto importante nessa parte do trabalho é identificar o grau de maturidade das aplicações multi-tenancy com relação à implementação. Frameworks Os autores de (Guo et al., 2007) focam seu trabalho principalmente no padrão multitenancy nativo. Eles exploram os principais requisitos e dasafios de multi-tenancy nativo e apresentam um framework baseado em SOA para suportar o projeto, desenvolvimento e gerenciamento de aplicações multi-tenancy de forma transparente. Através de da entrega de vários serviços que provêem funcionalidades multi-tenancy à aplicação desenvolvida, os desenvolvedores podem focar na camada de lógica de negócios sem se preocupar com a implementação dos requisitos inerentes a multi-tenancy. Os 5 principais componentes de serviço desse framework que habilitam multi-tenancy em uma aplicação são: • isolamento de segurança: baseado nos mecanismos de segurança tradicionais (autenticação, autorização, auditoria, etc), é preciso também considerar os riscos de segurança pontenciais introduzidos por outros tenants que compartilham a mesma instância da aplicação e recursos. • isolamento de performance: administradores do sistema estão interessados em evitar que o comportamento de um tenant afete a performance de outros tenants. Além disso, os tenants esperam receber os níveis de serviço definidos no contrato. • isolamento de disponibilidade: quando muitos tenants compartilham a mesma instância da aplicação, é crítico para o provedor de serviço detectar qualquer falha e evitar a propagação dessa falha o mais breve possível. • isolamento de administração: a interface administrativa deveria ser isolada para cada tenant individual para que eles possam visualizar e mudar os dados no nível operacional e de negócio que são relevantes para suas organizações. • customização on-the-fly: é necessário customizar a aplicação para ajustar as necessidades e situações particulares do tenant. Para negócio pequenos e médios que utilizam esse framework a customização será realizada de forma intuitiva e pelo próprio cliente, sem a necessidade de uma equipe de desenvolvimento.

51

3.5. MAPEAMENTO DAS EVIDÊNCIAS

(Kwok et al., 2008b) e (Rimal and El-Refaey, 2010) apresentam propostas de frameworks e apresentam o resultado de sua aplicação em um contexto específico. (Kwok et al., 2008b) apresenta o desenvolvimento de uma aplicação para gerenciamento de contratos eletrônicos e a implementação dos requisitos multi-tenancy através de um framework proposto pelos autores. Em sua abordagem os autores tratam de pontos importantes como customização, segurança e armazenamento de dados. (Rimal and El-Refaey, 2010) descreve um framework para orquestração de ambiente de cloud multi-tenancy que apresenta duas abordagens para o gerenciamento de workflows científicos: workflows baseados em semântica onde os autores apresentam uma abordagem utilizando ontologias e workflows baseados em políticas, que podem ser definidas como recursos requeridos ou controle de segurança. Um ponto importante no contexto de multi-tenancy é a alocação de recursos e localização dos tenants no datacenter. (Fehling et al., 2010) e (Tang et al., 2010) tratam desse assunto. (Fehling et al., 2010) analisa os desafios inerentes ao cenário de multi-tenancy e identifica várias oportunidades de otimização decorrentes da necessidade de distribuir eficientemente tenants que possuem funcionalidades iguais, mas qualidade de serviço diferentes. Esse trabalho também define um framework para desenvolvimento de estratégias de distribuição de tenants que permite a modelagem de recursos, suas dependências de implantação e usuários com demandas específicas de forma a permitir o melhor uso dos recursos. (Tang et al., 2010) discute como o acesso a dados entre os tenants afeta a carga de trabalho do datacenter e como otimizar a utilização de recursos no processo de alocação dos tenants. Nesse mesmo trabalho os autores propõem um framework para capturar dados dos tenants que auxiliem na identificação de fatores determinantes na localização dos tenants, um algoritmo para alocação de tenants e um método para estimação de recursos. (Pervez et al., 2010a) apresenta o framework D-Val que realiza a validação de requisições e auxilia os provedores de SaaS a fornecer software com qualidade de serviço em conformidade com a SLA definida para o cliente. D-Val funciona como um filtro que identifica requisições inválidas e impede que elas sejam processadas pelo servidor. Em (Tsai et al., 2010a) e (Wang et al., 2010) os autores propõem frameworks que focam em customização. (Tsai et al., 2010a) apresenta um framework para customização, que suporta e gerencia variabilidade de SaaS e requisitos específicos dos tenants. Os autores utilizam ontologias para derivar a customização e informações de implantação dos tenants. Além disso esse framework possui uma engine de recomendações inteligente que auxilia a criação de novos tenants usando informações de tenants já implantados. (Wang

52

3.5. MAPEAMENTO DAS EVIDÊNCIAS

et al., 2010) apresenta um framework para gerenciamento de processos de negócio em aplicações multi-tenancy que utiliza o paradigma orientado a aspectos para implementar as customizações. (Chen et al., 2011) define RaaS(Routing as a Service), um framework para prover uma plataforma de controle de rota para múltiplos tenants para executar controle de rota independentemente com pouco envolvimento do administrador do sistema. Ferramentas (Li et al., 2008),(Hui et al., 2009) e (Xiong et al., 2011) apresentam ferramentas para auxiliar o desenvolvimento de aplicações multi-tenancy. (Li et al., 2008) apresenta o SPIN(Service Performance Isolation Infrastructure), que permite compartilhamento de recursos em sistemas de hospedagem. Dado que podem existir tenants que interferem de forma agressiva no comportamento de outros tenants, SPIN fornece relatórios para identificar os tenants agressivos e fornece um mecanismo de moderação auto-adaptativo para eliminar seus impactos negativos nos outros tenants. Em (Hui et al., 2009) os autores propõem um SGBD chamado M-Store, que provê serviços de armazenamento e indexação para aplicações multi-tenancy. Para melhorar a escalabilidade dos sistemas, M-Store trabalha com 2 técnicas chamadas BIT(Bitmap Interpreted Tuple) e MSI(Multi-Separated Index). BIT é uma otimização onde o SGBD não armazena valores nulos de atributos não usados em tabelas compartilhadas, já o MSI provê flexibilidade, uma vez que os indices no SGBD são criados para cada tenant ao invés da criação de um indice para todos os tenants. (Xiong et al., 2011) propõe o SmartSLA que apresenta uma forma de gerenciar recursos em sistemas de bancos de dados compartilhados em ambiente de cloud. O SmartSLA consiste de dois componentes principais: o módulos de modelagem de sistema e o módulo de decisão de alocação de recursos. O módulo de modelagem de sistema usa técnicas de máquinas de aprendizado para descobrir a margem de lucro potencial para cada cliente sob diferentes formas de alocação de recursos. Baseado no modelo de aprendizado, o módulo de alocação de recursos ajusta dinamicamente a alocação de recursos para alcançar a otimização dos lucros. Métodos ou Técnicas No total foram encontrados 27 métodos ou técnicas que abordam os mais variados contextos relacionados a aplicações multi-tenancy. Esses trabalhos são brevemente descritos na tabela 3.11.

53

3.5. MAPEAMENTO DAS EVIDÊNCIAS
Contexto Alocação de Recursos Alocação de Recursos Banco de dados Banco de dados Banco de dados Descrição do método ou técnica (Kwok and Mohindra, 2008) descreve métodos para localização ótima de tenants e instancias baseado em um modelo de localização de tenants proposto pelos autores, sem violar qualquer requisitos de SLA dos tenants existentes nos servidores do datacenter. (Tsai et al., 2010b) propõe um método para priorizar requisições de serviços para aplicações multi-tenancy preservando as prioridades locais das requisições de cada tenant. Os autores propõem o um algoritmos chamado Crystalline Mapping(CM) que mapeia prioridades locais de cada tenant individualmente e para prioridades globais. (Jacobs and Aulbach, 2007) esse trabalho descreve três abordagens para implementar bancos de dados multi-tenancy e às compara através de experimentos. As tres abordagens comparadas são: shared machine, shared process e shared table. (Aulbach et al., 2008) descreve uma técnica para mapeamento de esquemas de banco de dados para multi-tenancy chamada Chunk Folding. Nessa técnica tabelas lógicas são verticalmente particionadas em chunks que são distribuídas em diferentes tabelas físicas e é realizado a junção desses dados quando necessário. (Grund et al., 2008) os autores analisam operações típica em bancos de dados multi-tenancy e mostram como essas operações se relacionam. No decorrer o trabalho os autores definem diferentes padrões de acesso baseado na abordagem de tabelas compatilhadas(shared table approach) e propõem uma nova projeto de compartilhamento de tabelas multitenancy. (Weiliang et al., 2010) os autores propõem uma abordagem chamada multiple sparse tables que seria uma adaptação da técnica sparse tables tradicional para o contexto de multi-tenancy. (Schiller et al., 2011) essa abordagem implementa isolamento entre tenants, extensão de esquemas tenants e funcionalidade de gerenciamento de dados centrada nos tenants em um SGBD relacional. Os autores também apresenta o conceito de herança de esquema, que permite o compartilhamento do esquema base de uma aplicação através dos tenants ao mesmo tempo que permite a extensão do esquema por tenant. (Xiong et al., 2011) esse trabalho já citado na seção 3.5.2, além de apresentar a ferramenta SmartSLA apresenta os métodos e técnicas implementados pela ferramenta. (Mietzner et al., 2008) descreve um formato para compor pacotes de aplicações SaaS configuráveis para aplicações desenvolvidas utilizando arquitetura orientada a serviço. Os autores descrevem como arquitetura de componentes de serviço (SCA - Service Component Architecture) pode ser extendida com descritores de variabilidade e padrões multitenancy para empacotar e implantar aplicações multi-tenancy configuráveis. (Jegadeesan and Balasubramaniam, 2009) os autores apresentam uma abordagem para implementar variabilidade de tenants utilizando programação orientada a aspectos. (Cai et al., 2010) nesse trabalho é descrito uma abordagem transparente para fazer uma aplicação web existente suportar multi-tenancy e executar em uma cloud pública. Os autores também implementam um sistema multi-tenancy real que separa os interesses dos desenvolvedores da aplicação, operados de SaaS, administrador do tenant e usuário do tenant. (Zhang et al., 2010a) um método sistemático é proposto para migrar aplicações single-tenant para multi-tenancy focando em aspectos como modelo de dados, controle de acesso e gerenciamento de tenants, levando em consideração as necessidades de negócio e assuntos técnicos. (Elmore et al., 2011) é proposto o Zephyr, uma técnica para migrar tenants com o mínimo de interrupção de serviço. (Hasselmeyer and d’Heureuse, 2010) os autores apresentam uma abordagem para monitoramento de vários recursos coo rede, servidores e aplicações em um ambiente multi-tenancy, levando em consideração que normalmente essas aplicações executam em algum ambiente virtualizado. (Wang et al., 2008b) nesse trabalho os autores identificam os potenciais gargalos de performance, apresentam as abordagens de otimização correspondentes e melhores práticas para implementação em ambientes multi-tenancy. (Lin et al., 2009b) nesse trabalho é apresentado uma abordagem de regulação de performance baseada em feedback. O regulador de performance possui uma estrutura hieráquica, com a qual um controlador de alto nível gerencia as taxas de admissão de requisições para evitar sobrecarga e um controlador de baixo nível gerencia a alocação de recursos para as requisições aceitas. (Ahmad and Bowman, 2011) os autores realizam um estudo experimental é realizado para entender os fatores que influenciam na performance de sistemas multi-tenancy e sugerem uma abordagem utilizando máquinas de aprendizado para predizer a performance das aplicações. (Brassil, 2010) os autores apresentam uma abordagem utilizando hardware para isolar tenants. (Zhang et al., 2009) esse trabalho demonstra o modelo de armazenamento de dados compartilhado, definie três tipo de restrições de privacidade, e então propõe uma abordagem baseada em restrições de privacidade customizáveis. (Li et al., 2010) os autores apresentam uma abordagem para serparação de segurança em cloud onde são definidos 2 níveis de granularidade para controle de acesso. O primeiro nível refere-se à segurança entre tenants e o segundo nível trata do mecanismo de controle de acesso da própria aplicação. (Nie, 2010) apresenta um algoritimo de avaliação de credibilidade entre os tenants baseado em experiência. De acordo com o histórico de acesso, o algoritimo calcula a credibilidade de um tenant, permitindo a detecção e monitoramento de tenants maliciosos com um baixo custo. (Mietzner et al., 2009a) os autores introduzem e avaliam um conjunto de padrões que podem ser usados para projetar, desenvolver e implantar aplicações SaaS orientadas a serviço. Além disso os autores descrevem como os requisitos multi-tenancy podem ser alcançados. (Ding et al., 2010) os autores apresentam um mecanismo de compensação flexível que suporta customização e implanta dinâmicamente processos de compensação. (Tsai et al., 2007) os autores exploram o uso de virtualização para habilitar funcionalidades multi-tenancy em sistemas com o mínimo de alterações possível. (Siddhisena et al., 2011) apresenta uma abordagem que utiliza uma abordagem de virtualização para construção de uma plataforma virtualizada para aplicações multi-tenancy, com foco no aumento de segurança e escalabilidade.

Banco de dados Banco de dados

Banco de dados Customização

Customização Migração

Migração

Migração Monitoramento

Performance Performance

Performance

Performance/ Segurança Segurança Segurança

Segurança

SOA

SOA Virtualização Virtualização

Tabela 3.11 Métodos e técnicas para implementar multi-tenancy

54

3.5. MAPEAMENTO DAS EVIDÊNCIAS

Modelos É de fundamental importância modelos que auxiliem desenvolvedores e engenheiros de software durante a construção de aplicações. No caso de multi-tenancy isso é ainda mais crucial pelo fato da mesma ser uma abordagem nova. Os modelos encontrados durante essa pesquisa surgiram nos último 2 anos, específicamente nos anos de 2010 e 2011. Essa seção apresenta alguns trabalhos relacionados a modelos que visam auxiliar o desenvolvimento de aplicações multi-tenancy. (Kong et al., 2010) propõe um modelo de customização multi-nível para aplicações SaaS que suporta compartilhamento de customizações através de diferentes tenants. Nesse trabalho os autores apresentam o projeto de uma arquitetura de armazenamento de dados que implementa esse modelo e apresenta uma comparação experimental dessa nova estratégia de customização. Em (Schaffner et al., 2011), como já mencionado na seção 3.4.7 os autores estudam a automação operacional de tarefas em bancos de dados orientados a coluna e definem um modelo para predição de violações no tempo de resposta esperado. Para a alocação de recursos no datacenter, os autores apresentam um algoritmo que move os tenants entre os servidores do datacenter para garantir o tempo de resposta esperado. Outro modelo focado em performance e alocação de recursos é apresentado em (Zhang et al., 2010b). Focando-se no problema OTPP(On-line Tenant Placement Problem), nesse trabalho os autores propõem um modelo para estimar consumo de recursos em aplicações multi-tenancy. Foram encontrados também modelos que propõem alguma melhoria no armazenamento de dados em aplicações multi-tenancy. (Xue et al., 2011) apresenta um modelo de indexação para armazenamentos de dados que utilizam a abordagem Multiple Sparse Tables. Um trabalho que também aborda esse assunto é (Ahmad and Bowman, 2011) e já foi citado na seção 3.5.2. Já em (Aulbach et al., 2011) os autores apresentam três funcionalidades que um SGBD multi-tenancy deveria prover: extensibilidade, compartilhamento de dados e evolução. Os autores apresentam o FLEXSCHEME, um modelo integrado para bancos de dados multi-tenancy que atende, segundo os autores, às três funcionalidades citadas anteriormente. (Tsai and Shao, 2011) propõe um modelo de controle de acesso que utiliza ontologias. Esse modelo já foi mencionado na seção 3.4.8.

55

3.5. MAPEAMENTO DAS EVIDÊNCIAS

Propostas de Arquitetura Um ponto importante durante o desenvolvimento de software em qualquer segmento é conhecer implementações semelhantes já realizadas por outros desenvolvedores. Partindo desse princípio essa seção apresenta propostas de arquitetura de software que auxiliem no desenvolvimento aplicações multi-tenancy. Foram encontradas propostas de arquitetura para aplicações multi-tenancy (Koziolek, 2010; Bezemer et al., 2010; Bezemer and Zaidman, 2010; Pervez et al., 2010b; Tsai et al., 2010d; Yuanyuan et al., 2009; Jing and Zhang, 2010; Cheng et al., 2009; Koziolek, 2011) e para plataformas de suporte a multi-tenancy (Weissman and Bobrowski, 2009; Oh et al., 2011; Azeez et al., 2010). Dentre essas propostas algumas já foram aplicadas à indústria, como é o caso do Force.com (Weissman and Bobrowski, 2009) e EXACT (Bezemer et al., 2010). Force.com é uma plataforma de desenvolvimento de software que utiliza arquitetura dirigida à metadados para construção de aplicações multi-tenancy. Nessa arquitetura tudo que é exposto para os desenvolvedores e usuários da aplicação é internamente representado como metadado. Formulários, relatórios, workflows, priviégios de acesso, customizações específicas do tenant e lógica de negócio, tudo é armazenado como metadados. Outro exemplo de arquitetura dirigida à metadados pode ser encontrada em (Oh et al., 2011). Em (Bezemer et al., 2010) Bezemer apresenta uma arquitetura utilizada no desenvolvimento de aplicações na empresa EXACT, uma empresa de desenvolvimento de software especializada em ERP, CRM e aplicações financeiras. Em sua arquitetura os autores apresentam 3 componentes básico para a implementação de aplicações multi-tenancy: componente de autenticação, customização e banco de dados. Além disso os autores apresentam um estudo de caso e uma lista de lições aprendidas. Outros autores apresentam Arquiteturas Orientadas a Serviço que implementam requisitos de multi-tenancy como é o caso de (Jing and Zhang, 2010),(Azeez et al., 2010) e (Pervez et al., 2010b). Em (Jing and Zhang, 2010) os autores apresenta OSaaS, uma arquitetura que utiliza tecnologias SOA para desenvolvimento de aplicações SaaS. (Azeez et al., 2010) apresenta uma arquitetura para implementar multi-tenancy a nível de SOA, que permite a usuários executar seus serviços e outros artefatos SOA em um framework multi-tenancy SOA. Já (Pervez et al., 2010b) apresenta uma arquitetura para SaaS que foca nos aspectos de segurança e balanceamento de carga em ambiente de cloud computing. Além das propostas de arquitetura citadas anteriormente, foi encontrado também uma proposta de estilo arquitetural, o SPOSAD, que é descrito em (Koziolek, 2010) e (Koziolek, 2011). SPOSAD descreve componentes, conectores, e elementos de dados

56

3.5. MAPEAMENTO DAS EVIDÊNCIAS

de uma arquitetura multi-tenancy, bem como restrições impostas nesses elementos. Os autores também apresentam os benefícios do uso dessa arquitetura e informações que podem auxiliar em decisões de projeto. Em (Tsai et al., 2010d) os autores apresentam uma arquitetura de duas camadas que foca em escalabilidade, que trabalha a nível de serviço e aplicação para economizar o uso de recursos, e a idéia chave é aumentar os recursos somente onde houver gargalos. Várias técnicas de duplicação de recursos computacionais são propostas, incluindo duplicação preguiçosa e duplicação pro-ativa para alcançar a melhor performance do sistema. Além da arquitetura esse trabalho apresenta um algoritmo para alocação de recursos para cluster em ambientes de cloud. Já em (Yuanyuan et al., 2009) os autores apresentam uma arquitetura multi-tenancy para sistemas de suporte a negócios (BSS - Business Support System) e discute brevemente uma abordagem para alcançar configurabilidade, seguranca e escalabilidade na arquitetura. Focando em escalabilidade de dados, os autores propõem um particionamento horizontal baseado em grupos de entidades pela análise das relacões entre as entidade do sistema. (Takahashi et al., 2010) esse trabalho propõe uma arquitetura de sistema autônomo para infraestrutura de SaaS escalável para atender ao crescimento e acesso multi-tenancy de aplicações SaaS. Os autores propõe o conceito e arquitetura do Cache L4, que tem o objetivo de aumentar a eficiência SaaS com otimizações no uso do hardware. (Calero et al., 2010) os autores apresentam a arquitetura de um sistema de autorização multi-tenancy apropriado para um serviço de middleware para PaaS. Cada empresa pode prover vários serviços de cloud que podem colaborar com outros serviços tanto da mesma organização quanto de organizações diferentes. Esse sistema de autorização suporta acordos de colaboração entre empresas(também conhecidos como federações).

3.5.3

Q3 - Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicação multi-tenancy

Um sistema de banco de dados para SaaS deveria oferecer esquemas flexíveis, que podem ser extendidos para diferentes versões da aplicação e dinamicamente modificados enquanto o sistema está sendo usado. Como já mencionado nas seções 3.4.2 e 3.5.2, os trabalhos (Aulbach et al., 2008) e (Aulbach et al., 2009), apresentam técnicas para mapear variabilidade de tenants em um banco de dados. Os autores descrevem essas técnicas e realizam experimentos com o objetivo de identificar a técnica que apresenta os melhores resultados em bancos de dados como Microsft SQL Server, IBM DB2 e HBase. Os autores concluiram que o banco de dados ideal para SaaS ainda não foi desenvolvido

57

3.5. MAPEAMENTO DAS EVIDÊNCIAS

e apresentam algumas sugestões sobre como ele deveria ser projetado. Em SaaS, sistemas de workflow são uma boa opção para o baixo acoplamento, customização, arquitetura de computação baseada em web e serviços web. Além disso, podemos dinamicamente customizar serviços e processos de negócio. Para alcançar isso, o suporte a transação de processos de negócio tem se tornado cada vez mais importante. Em meio aos protocolos de serviços web atuais, existem alguns protocolos relevantes para suporte a processamento de transações. Em (Wang et al., 2008b) os autores propõem um mecanismo de compensação flexível que suporta deploymente customizável e processo de compensação. (Arya et al., 2010) apresenta informações sobre a natureza da configurabilidade em SaaS, como pode ser provido e quais tecnologias são necessárias para suportá-la. De acordo com os autores, as principais tecnologias habilitadoras de cloud computing são: web 2.0, RIA (Rich Internet Application), SOA, Cloud Computing e virtualização. Além disso os autores definem GUI, workflow, dados e controle de acesso como os principais aspectos configuráveis em SaaS, e descrevem vários métodos utilizados para manipulação de metadados, segurança e serviços compartilhados, bem como módulos de customização e extensão de tenants. (Jansen et al., 2010) apresenta uma visão geral de como técnicas de realização de customização de linha de produtos de software podem ser aplicadas para realizar customização durante o desenvolvimento de aplicações multi-tenancy. Os autores apresentam um catálogo de técnicas de realização de customização para aplicações web e mostram como são implementadas na prática usando dois estudos de caso. O catálogo auxilia desenvolvedores web e arquitetos de software a selecionar a técnica correta durante a implementação de aplicações multi-tenancy. Sem esse tipo de informação, desenvolvedores de aplicações multi-tenancy precisam reinventar a roda e não se beneficiam de padrões arquiteturais existentes. Em muitos casos, se a aplicação de software apenas com requisitos comuns não consegue atender de forma aceitável à maioria dos clientes, uma forte capacidade de configuração e customização irá tornar-se uma fator chave no sucesso da aplicação. Em (Sun et al., 2008), o conceito de configuração e customização no contexto de SaaS são esclarecidos, e é introduzido um modelo de competência e um framework para ajudar fornecedores de SaaS a planejar a oferta de customização e configuração em suas aplicações. Em (Kwok et al., 2008b) autores apresentam o desenvolvimento de uma aplicação multi-tenancy para gerenciamento de contrato eletrônico. No decorrer desse trabalho os

58

3.5. MAPEAMENTO DAS EVIDÊNCIAS

autores descrevem vários métodos usados para gerenciamento de metadados, compartilhamento de serviços e segurança. Ainda de acordo com os autores os atributos para o sucesso de uma aplicação multi-tenancy são configurabilidade, eficiência e escalabilidade. Durante esse trabalhos os autores enfatizam multi-tenancy e customização. (Li et al., 2009) explora os desafios existente na área de customização em ambiente multi-tenancy e propõe um modelo de customização de relacionamentos. Em seu trabalho os autores apresentam o modelo de customização de objetos como o mais importante e apresenta níveis de customização de objetos: dados, serviço, processo e interface gráfica. Os autores discutem o relacionamento entre objetos em cada um desses níveis. Caso não seja implementadoo corretamente, a realização de customização de tenants separadamente por diferentes aplicações de negócio, leva à muita duplicação de código e metadados. Em (Kong et al., 2010), os autores propõem um modelo de customização multi-nível para aplicações SaaS que suporta compartilhamento de customização através de diferentes aplicações multi-tenancy virtualizadas. Além disso os autores apresentam uma arquitetura de armazenamento de dados multi-tenancy dirigida a metadados que implementa modelo de customização multi-nível. Ao final do trabalho é realizada uma comparação do modelo proposto com o modelo antigo através de experimentos. (Tsai et al., 2010a) apresenta um framework para customização multi-camada, para suportar e gerenciar a variabilidade de aplicaçãoes SaaS e requisitos específicos dos tenants. Ontologia é usada para derivar a customização e informações de implantação para os tenants. O framework também possui uma engine de recomendação para suportar a implantação de novos tenants usando informações de tenants existentes. Um estudo de caso é usado para demonstrar o modelo proposto. (Zhang et al., 2007), nesse trabalho é proposto uma política de customização baseada em WSDL (Web Service Definition Language). A política proposta é aplicada para permitir a customização de SaaS e facilitar a integração entre SaaS. Para permitir a implementação dessa abordagem os autores apresentam um framework chamado WSPolicy. Já (Mietzner et al., 2008), como já citado na seção 3.5.2 apresenta uma abordagem baseada em SCA para implementar variabilidade entre tenants. Em (Jegadeesan and Balasubramaniam, 2009), os autores propõem o uso de orientação à aspectos para modularizar fatores de variabilidade como interesses transversais ou aspectos. Além disso é proposto uma forma de compor esses interesses com um módulo básico da aplicação que os autores chamam de kernel, possibilitando a criação de variantes do serviço. Essa abordagem visa oferecer o máximo de flexibilidade para os tenants enquanto garante fácil configurabilidade e reuso.

59

3.5. MAPEAMENTO DAS EVIDÊNCIAS

(Mietzner et al., 2009b) apresenta como técnicas de modelagem de variabilidade, já conhecidas no contexto de linha de produtos de software, podem ser usadas para modelar variabilidade em SaaS. É aplicado o conceito de variabilidade interna e externa da engenharia de linha de produtos de software para o problema de customização e implantação em aplicações SaaS. (Lizhen et al., 2010) propõe a modelagem de variabilidade usando metagrafos para gerenciar a variabilidade para configuração e customização de aplicações SaaS. Essa abordagem pode sistematicamente, segundo os autores, descrever pontos de variabilidade e seus relacionamentos, e garantir a qualidade de entradas de configuração feitas pelos consumidores. Os benefícios dessa abordagem são demonstrados no trabalho através de um exemplo simples.

3.5.4

Q4 - Quando a adoção da arquitetura multi-tenancy é viável?

Não encontramos trabalhos que tratam diretamente da viabilidade de multi-tenancy. Ainda assim, foi possível coletar evidências em alguns trabalhos encontrados que apontam cenários em que a adoção de multi-tenancy é viável. O principal ponto que deve-se considerar é a capacidade da equipe de desenvolvimento de implementar requisitos funcionais e não funcionais relacionados a multi-tenancy como compartilhamento de recursos de hardware, configurabilidade, compartilhamento de aplicação, autenticação, armazenamento de dados, customização, etc. Implementar esses requisitos podem gerar um custo bem maior do que simplesmente manter 2 ou 3 versões de uma aplicação, em alguns casos. De acordo com (Kwok et al., 2008b), com um único código base da aplicação para suportar vários tenants, o tempo total de implantação em um novo cliente é menor. Além disso, a atualização da aplicação é mais simples e centralizada pelo fato de existir apenas um única versão do código fonte e uma única instância da aplicação(ou um número muito reduzido). Há de se levar em consideração que tanto novas implementações quanto bugs serão propagados para todos os clientes de uma só vez, isso exige uma boa bateria de testes para garantir a qualidade da aplicação. Desconsiderar a criticidade de uma boa bateria de testes nesse ambiente pode inviabilizar a adoção de multi-tenancy. De acordo com (Aulbach et al., 2008), multi-tenancy torna-se menos atrativo em cenários onde a complexidade da aplicação é crescente. De acordo com os autores, single-tenant é a abordagem mais adequada para aplicações mais complexas. Em muitos casos existem dados sigilosos que os usuários não desejam que saiam dos limites físicos da empresa. Na maioria dos casos isso pode inviabilizar a adoção de uma

60

3.6. DISCUSSÃO

aplicativo no modelo SaaS que funcione em ambiente multi-tenancy. Uma abordagem para que os provedores de serviço não percam clientes nesse perfil é desenvolver uma aplicação multi-tenancy que forneça algum tipo de integração com aplicações externas. Dessa forma o cliente poderia contratar o serviço e usar apenas as funcionalidades que não manipulam dados sigilosos, deixando que os dados sigilosos sejam tratados por uma aplicação em seu próprio data center. Em (Mietzner et al., 2009a), os autores apresentam uma abordagem de como combinar diferentes padrões multi-tenancy em uma aplicação orientada a serviços. Em (Bezemer and Zaidman, 2010) os autores apresentam duas barreiras que pode influenciar na adoção de multi-tenancy: • empresas podem ter receio financiar o custo inicial de reengenharia de suas aplicações existentes para multi-tenancy • Desenvolvedores de software que mantém a aplicação podem ficar incomodados com os problemas de manutenção adicionais que a introdução de multi-tenancy pode causar devido ao fato desses novos aplicativos serem altamente configuráveis.

3.6

Discussão

Plataformas de SaaS como Salesforce.com permitem que muitas customizações da aplicação sejam realizadas sem a necessidade de programação através da especificação de regras de negócio que são simples o suficiente para não-programadores implementarem. Grandes empresas de TI como HP e IBM tem investido bastante nessa área, isso é comprovado com o fato de vários artigos encontrados durante esse estudo serem escritos por membros dessas empresas. Além disso, algumas empresas também vendem aplicativos que podem ser configurados para executar como SaaS em nuvens privadas; SAP por exemplo, pode ser usado como um SaaS oferecido dentro das empresas. A primeira dificuldade encontrada durante as pesquisas foi identificar quais os requisitos de uma aplicação multi-tenancy que são essenciais para sua implementação. Durante a tentativa de identificá-los, foi possível perceber que duas características chave de multi-tenancy são o auto grau de automação nas atividades de manutenção da aplicação e uma interface amigável para que o usuário possa realizar suas customizações, reduzindo ao máximo a necessidade de intervenções por parte de desenvolvedores e administradores de sistema.

61

3.6. DISCUSSÃO

Durante o a condução do mapeamento sistemático foi possível notar a existência de muitos trabalhos associados à multi-tenancy e armazenamento de dados. Propostas de métodos, técnicas e até um SGBD multi-tenancy foi proposto. Embora esse seja o campo de multi-tenancy onde mais se encontrou publicações, ainda é um campo onde existem muitos pontos de melhoria, principalmente pelo fato do armazenamento de dados influenciar diretamente no tempo de resposta de todas as operações que manipulam dados. Vários experimentos foram realizados com as abordagens existentes para armazenamento de dados em aplicações multi-tenancy mas não foi encontrada na literatura um consenso sobre qual abordagem é a melhor. Migração de dados, modelagem dos dados, tempo de resposta, armazenamento distribuído, integração com ferramentas de BI, todos esses fatores podem influenciar na escolha de uma abordagem para armazenamento de dados. Atualmente, novas formas de armazenamento de dados estão surgindo como: HBase1 , Cassandra2 , Hipertable3 , MongoDB4 , CouchDB5 , etc. Esses sistemas armazenam dados de uma forma diferente do usado nos modelos relacionais e compõem um movimento chamado NoSQL. Uma lacuna pouco explorada foi a utilização dessas novas tecnologias no desenvolvimento de aplicações multi-tenancy, dado que bancos de dados NoSQL surgiram como uma solução para a questão da escalabilidade no armazenamento e processamento de grandes volumes de dados(Diana et al., 2010). A necessidade de uma nova tecnologia de BD surgiu como consequência da ineficiência dos bancos de dados relacionais em lidar com a tarefa de manipulação de grandes volumes de dados. Vale ressaltar que o modelo relacional foi proposto na década de 70, quando as aplicações de banco de dados caracterizavam-se por lidar com dados estruturados, ou seja, dados que possuem uma estrutura fixa e bem definida, e esse não é o caso de aplicações multi-tenancy que podem ser customizadas(Lóscio et al., 2011). O crescente surgimento de APIs(DuVander, 2011) web mostra que a utilização desse tipo de abordagem faz muito sentido no contexto de aplicações web e SaaS. Um exemplo de sucesso é o Tweetdeck, uma aplicação cliente do twitter que foi desenvolvida utilizando a API disponibilizada pelo twitter aos desenvolvedores e teve grande aceitação pelos usuários do twitter.com. O valor real da aquisição não foi declarado, mas especula-se algo em torno de 40 milhões de dólares(BBC News, 2011).
1 http://hbase.apache.org 2 http://cassandra.apache.org 3 http://hypertable.com 4 http://www.mongodb.org 5 http://couchdb.apache.org

62

3.6. DISCUSSÃO

Outro exemplo de sucesso é o marketplace desenvolvido pela Salesforce, o AppExchange, que possui mais de 1 milhão de aplicações cadastradas, desde extensões da aplicação de CRM do Salesforce até aplicações para outros propósitos. Exemplos como esse mostram quão vantajoso é trazer desenvolvedores independentes para o mercado de SaaS. A realidade é que para entender o campo de customização de aplicações multi-tenancy é necessário entender o contexto no qual essas aplicações estão surgindo. Dado que não é possível atender com uma única aplicação a necessidade de todos os clientes, como já foi mencionado anteriormente, enfrenta-se em aplicações multi-tenancy o desafio de permitir de alguma forma que o cliente adicione novas regras e customize a aplicação ou faça extensões que auxiliem na solução de seus problemas específicos. Durante esse trabalho foram encontrados vários estudos relacionados ao tema, muitos deles utilizando trabalhando com metadados, orientação a aspectos, SOA, etc. Customização de aplicações já é um tema bastante explorado pelos pesquisadores da área de linha de produtos de software. Basicamente podemos considerar que a customização de aplicações multi-tenancy é equivalente a variabilidade de linha de produtos de software em tempo de execução. Uma iniciativa de customização de aplicações multitenancy tomando-se como base os conhecimentos de linha de produtos de software é apresentado em (Jansen et al., 2010). Dado que SaaS tem como objetivo prover software para uma grande massa de consumidores, o atendimento aos requisitos de alocação de recursos, monitoramento, escalabilidade e performance são requisitos não funcionais que podem até ser ignorados em uma aplicação comum, mas que são de vital importância em aplicações multi-tenancy, principalmente se a aplicação estiver hospedada em um ambiente de cloud onde a tarifação é paga por consumo. Nesses ambientes uma aplicação mal projetada pode levar a custos operacionais tão altos que podem inviabilizar o funcionamento da aplicação, dado o valor que deverá ser pago para manter a infraestrutura de servidores funcionando. Por outro lado, em uma contexto onde a alocação de recursos é feita de forma inteligente, o monitoramento indica quais recursos estão ociosos e quais os gargalos da aplicação, a elasticidade(capacidade de aumentar e diminuir os recursos de hardware) é realizada de forma automática e inteligente, os custos operacionais podem ser diminuidos drasticamente se a aplicação consumir somente o que é estritamente necessário para atender aos requisitos de SLA definidos aos cliente. A realização desse mapeamento foi de crucial importância para verificar a viabilidade de implementação de uma solução multi-tenancy. Numa decisão como essa é necessário

63

3.7. AMEAÇAS A VALIDADE

verificar não só a aderência da tecnologia com relação a necessidades imediatas, mas também para necessidades que podem surgir futuramente. O mapeamento sistemático ajudou a identificar que customização, armazenamento de dados, segurança e alocação de recursos são pontos críticos no desenvolvimento de uma aplicação multi-tenancy e precisam ser implementados de forma eficiente para o bom funcionamento da aplicação. O cruzamento de dados realizado na Figura 3.5, ajudou a identificar a ausência de uma ferramenta que desse suporta à migração de sistemas single-tenant para multi-tenancy. Com isso identificou-se uma lacuna na área que pode inviabilizar em alguns casos a adoção de uma abordagem multi-tenancy, dado o fato de várias empresas já possuírem sistemas legados com dados pré-cadastrados. Esses dados, na maioria dos casos são artefatos de negócio de importância muito elevada para serem descartados. No Capítulo 4 poder-se-á verificar que foi necessário a implementação de uma ferramenta para auxiliar na migração de um sistema single-tenant para multi-tenancy. Soluções para requisitos futuros da aplicação que será descrita no Capítulo 4 também poderam ser identificadas, como é o caso da possível adoção de SOA para realizar a integração de sistemas, métodos para otimização de performance em aplicações multitenancy, soluções para monitoramento de aplicações multi-tenancy, virtualização de aplicações, etc. O Capítulo 4 apresenta detalhadamente como cada problema foi resolvido e como as informações obtidas apartir do mapeamento sistemático foram utilizadas para chegar à uma solução.

3.7

Ameaças a validade

Existem alguns fatores identificados no processo de mapeamento sistemático que foram considerados ameaças a validade do trabalho. Esses fatores são descritos a seguir: • Questões de pesquisa: o conjunto de questões definido pode não cobrir de forma satisfatória a área de desenvolvimento de aplicações multi-tenancy. Para mitigar essa ameaça, foram realizadas reuniões de discussão com outros pesquisadores da área para calibrar as questões. Dessa forma, mesmo que não se tenha selecionado as melhores questões de pesquisa, tentou-se chegar o mais próximo possível disso. • Abrangência da pesquisa: não é possível garantir que todos os estudos relevantes foram selecionados. É possível que algum estudo relevante não tenha sido selecionado no processo de pesquisa. Mitigou-se essa ameaça realizando o processo de revisão dos trabalhos mais de uma vez em momentos diferentes.

64

3.8. CONSIDERAÇÕES FINAIS

• Qualidade da avaliação: durante o agrupamento dos trabalhos nas facetas definidas pode haver ocorrido alguma classificação errada, dado que a classificação ocorre baseada exclusivamente na leitura dos artigos realizada pelo autor desse trabalho. Para minimizar esse risco, após a classificação dos trabalhos, foi realizada uma segunda leitura em cada trabalho para verificar se o trabalho estava devidamente associado às facetas corretas. • Falta de familiaridade com a área pesquisada: os termos usados nas strings de pesquisa podem ter muitos sinônimos e existe a possibilidade da ausência de algum desses sinônimos influenciar na pesquisa, de forma que algum trabalho relevante não tenha sido encontrado com as strings de busca definidas. Para mitigar esse problema foi foi realizado uma pesquisa inicial que teve o objetivo de auxiliar na familiarização com os termos da área.

3.8

Considerações Finais

Este capítulo apresentou um mapeamento sistemático realizado na área de multi-tenancy. Inicialmente foi apresentado a metodologia utilizada para conduzir o mapeamento e a seguir sua aplicação e os resultados encontrados no mapeamento. Nenhum mapeamento sistemático na área foi encontrado, embora tenha-se encontrado vários estudos sobre o tema. Durante a condução do mapeamento foram definidas algumas facetas que tiveram o objetivo de agrupar os trabalhos por campos de pesquisa existentes dentro de multi-tenancy, para que pesquisadores interessados em multi-tenancy possam focar seus esforços em um desses campos ou mais. Foram identificados os campos mais pesquisados e as principais descobertas em cada um deles. Por fim, baseado em evidências encontradas nos estudos foram respondidas as quatro perguntas definidas no início do mapeamento sistemático. O capítulo a seguir apresenta como os conhecimentos adquiridos através do mapeamento sistemático foram utilizados durante o desenvolvimento de uma aplicação multi-tenancy em uma empresa real.

65

4
Aplicação na Indústria
Como um dos objetivos desse trabalho é verificar a aplicabilidade dos conceitos relacionados à multi-tenancy no mercado de software, esse capítulo apresenta um case de desenvolvimento de uma aplicação SaaS multi-tenancy em uma empresa startup que atua no segmento de reuso de software. No decorrer desse capítulo serão apresentadas as experiências adquiridas da junção dos conhecimentos obtidos através do mapeamento sistemático descrito no capítulo anterior e dos resultados da aplicação desses conhecimentos na prática. Nesse capítulo a seção 4.1 apresenta o cenário no qual a aplicação multi-tenancy foi desenvolvida e seus requisitos, a seção 4.2 descreve a metodologia utilizada para combinar mapeamento sistemático e desenvolvimento da aplicação. A arquitetura adotada na aplicação e a metodologia para sua definição são descritos na seção 4.3 ,já a seção 4.4 descreve como foi realizado o processo de migração de dados da aplicação legada para a nova aplicação no modelo multi-tenancy e por fim a seção 4.5 apresenta as considerações finais do capítulo.

4.1

Problema

O objetivo do projeto era desenvolver uma ferramenta de suporte a atividades de engenharia de software para auxílio no processo de desenvolvimento de SPL(Software Product Lines). A versão inicial da ferramenta deverá permitir ao usuário cadastrar informações relacionadas ao levantamento de requisitos e definição de escopo de uma linha de produtos de software. Posteriormente seria adicionado à ferramenta funcionalidades relacionadas ao armazenamento e busca de assets reutilizáveis desenvolvidos pelos usuários da ferramenta. No contexto de SPL, onde uma grande variedade de produtos são derivados de uma

66

4.1. PROBLEMA

plataforma comum, e podem mudar e evoluir, é importante gerenciar a variabilidade da Linha de Produtos e a rastreabilidade entre os artefatos. (Cavalcanti et al., 2011) apresenta um metamodelo que tem como objetivo coordenar as atividades relacionadas ao desenvolvimento de uma SPL, pelo gerenciamento de diferentes fases da SPL e suas responsabilidades, e da manutenção da rastreabilidade e variabilidade entre os diferentes artefatos. Esse metamodelo é representado utilizando a notação UML na Figura 4.1. O metamodelo é dividido em cinco sub-modelos, que descrevem funcionalmente a aplicação que será desenvolvida: • Gerenciamento de Projeto: módulo da aplicação responsável por armazenar informações sobre o projeto da SPL, suas fases do desenvolvimento, tarefas, membros responsáveis por essas tarefas e o papel de cada um no projeto. Além disso, podem ser documentadas as decisões de projeto, descrição de alternativas à essas decisões, justificativa para decisões, notas explicativas, membros da equipe envolvidos na decisão e momento em que a decisão foi tomada. • Gerenciamento de Risco: é importante para os projetos de software por causa do grau de incerteza que envolve a maioria dos projetos. Os riscos resultam de requisitos fracamente definidos, dificuldades de estimar esforço e recursos necessários para o desenvolvimento de software. Além disso, dependência de habilidades individuais e mudança nos requisitos devido à mudanças na necessidade dos clientes, também pode influenciar nos riscos associados ao projeto. • Escopo: agrupa as funcionalidades para auxiliar na identificação e documentação das features de uma SPL. Em alguns casos pode ser necessário construir uma árvore contendo todos os tipos de features existentes em um produto como features mandatórias, alternativas ou opcionais. Além disso é necessário gerenciar relacionamentos entre features, por exemplo, features obrigatórias(identificadas apartir de relações de dependência entre features) e excludentes(features que não podem co-existir em um mesmo produto). • Requisitos: gerencia os requisitos e casos de uso associados a cada feature e a cada módulo da aplicação documentada. Durante a elicidação, o módulo suporta variações de requisitos entre os produtos derivados apartir da SPL documentada e apresentar o que o sistema deverá fazer e como as variações serão suportadas. • Teste: gerencia como os casos de teste do sistema interagem com os outros artefatos. Os casos de teste são derivados dos casos de uso documentados. Essa estratégia

67

4.2. METODOLOGIA

permite que cada mudança em casos de uso ou pontos de variação da SPL possam ser propagadas para os casos de teste. Além dos requisitos do metamodelo, ainda existiam alguns fatores que poderiam influenciar nas decisões de projeto: • A aplicação seria incialmente provida como SaaS para um grupo de 20 clientes, que validariam os requisitos da aplicação durante o uso da versão beta; • Os clientes deveriam ter a possibilidade de contratar e usar a aplicação sem nenhuma intervenção manual da empresa provedora do serviço; • Cada cliente deveria poder gerenciar seus próprios usuários; • A aplicação iria executar em um ambiente virtualizado com 613MB de memória e 30GB de armazenamento; • Os requisitos da aplicação deveriam ser elicidados e implementados de forma incremental; • A aplicação deveria aproveitar o máximo de recursos possível. Diante das características citadas acima, multi-tenancy apresentou-se como uma alternativa viável para esse projeto. A necessidade de prover uma aplicação web que o cliente contratasse sem a intervenção do provedor de serviço fortaleceram a escolha da abordagem SaaS. Já recursos limitados de hardware e a necessidade de prover a aplicação para 20 clientes que poderiam ter vários usuários à utilizando simultaneamente, exigiam o máximo de otimização no uso do hardware. Dentre os 3 tipos de SaaS apresentados na seção 2.2, multi-tenancy apresentou-se como a melhor escolha por permitir a melhor abordagem para otimização de recursos e facilidade de prover software como serviço com modelo de pagamento por uso. Essa é uma aplicação real que foi desenvolvida e entrou em produção antes da apresentação desse trabalho. As seções a seguir descrevem como essa aplicação foi desenvolvida

4.2

Metodologia

Para conduzir a etapa de desenvolvimento de um aplicativo na indústria seguiremos o processo definido na Figura 4.2. De acordo com a figura, a primeira etapa consiste em definir uma arquitetura do aplicativo a ser desenvolvido. Para realizar essa atividade foram

68

4.2. METODOLOGIA

Figura 4.1 Metamodelo para SPL(Fonte: (Cavalcanti et al., 2011))

69

4.3. DEFINIÇÃO DE ARQUITETURA

Figura 4.2 Metodologia utilizada para desenvolvimento de aplicação na indústria(Fonte: Elaboração própria)

utilizadas informações obtidas através do resultado do mapeamento sistemático e da lista de requisitos da aplicação. Apartir dessas informações foi possível identificar as propostas de arquitetura que mais se adequam aos requisitos da aplicação. A segunda etapa foi escolher as tecnologias que seriam utilizadas para a implementação dos requisitos funcionais e não funcionais da aplicação, além da migração dos dados já cadastrados que anteriormente eram manipulados por uma aplicação legada. Durante a etapa de implementação foi adotado SCRUM como metodologia de desenvolvimento, o que facilitou a realização de releases incrementais e rápidos. Vantagens da adoção de SCRUM com metodologia para gerenciamento ágil de produtos SaaS pode ser visto em (Agarwal, 2011). Por fim, na terceira etapa é realizado a coleta de feedback dos usuários, de forma que seja possível melhorar a aplicação no tocante a requisitos funcionais e não-funcionais. Uma sequência de vários ciclos compostos da etapa de "implementação"e "validação da aplicação", é realizada com o objetivo de proporcionar uma evolução incremental do produto.

4.3

Definição de Arquitetura

Modelos arquiteturais possuem um importante papel como ponte entre os requisitos do sistema e a sua implementação, além de serem considerados o primeiro conjunto de decisões de projeto relacionadas ao atendimento dos requisitos no sistema (Babar et al., 2004). Arquitetura de software está sendo cada vez mais utilizada em projetos de desenvolvimento de software para representar as soluções computacionais. Isso ocorre devido às facilidades que ela oferece como, por exemplo, a possibilidade em abstrair informações,

70

4.3. DEFINIÇÃO DE ARQUITETURA

o que diminui a complexidade e facilita o entendimento da solução. Nos últimos anos, arquitetura de software tem sido cada vez mais importante devido ao aumento da complexidade das aplicações que vem sendo desenvolvidas. Nos últimos tempos, aplicações tem se tornado mais complexas, difíceis de enteder, e demasiadamente caras de se desenvolver apartir do zero. Isso fortalece a necessidade de reusar e adaptar arquiteturas de software existentes, otimizando os custos do projeto (Ciaccia et al., 1997). Para que seja possível reusar uma arquitetura de software existente, é necessário efetuar uma avaliação dessa arquitetura para verificar se ela é adequada ao cenário onde pretende-se aplicá-la. O processo de avaliação de arquitetura de software tipicamente inclui a aplicação de um método de avaliação. Existem diversos métodos disponíveis com diferentes técnicas e objetivos como: SAAM, ATAM, ALPSM, SBAR, SALUTA, SAAMCS, ESAAMI, ASAAM, SACAM e DoSAM(Graham and Roy, 2008). Contudo, a análise dos métodos identificados e resultados obtidos por surveys (Babar et al., 2004; Dobrica and Niemela, 2002) identificaram quatro problemas principais: grande subjetividade dos métodos, elevado custo de aplicação, dificuldades para avaliar simultaneamente o atendimento a vários requisitos de qualidade e contexto limitado para a aplicação de alguns dos métodos. O elevado custo de aplicação de métodos de avaliação está relacionado ao destes terem sido desenvolvidos para projetos de grande porte, que geralmente possuem alta disponibilidade de recursos. Com isso, somente um pequeno número de empresas conseguem aplicar de forma correta as avaliações (Lattanze, 2005). Diante de tantos métodos de avaliação era necessário identificar o método mais adequado ao contexto do projeto. Babar (Babar and Gorton, 2009) realiza um survey que tem o objetivo de identificar como as técnicas de revisão de arquitetura estão sendo utilizadas no mercado. Segundo seu trabalho, as quatro técnicas mais comuns aplicadas para revisão de uma arquitetura de software são baseadas em experiência, prototipagem, técnicas baseadas em cenários e técnicas baseadas em checklists. Após a análise das técnicas de revisão de arquitetura identificou-se que a quantidade de pessoas necessárias para realizar uma revisão de arquitetura, a quantidade de documentação que precisaria ser gerada e o esforço necessário para realizar as atividades inviabilizariam a adoção dessas técnicas por uma equipe pequena, como era o caso da startup onde essa aplicação foi desenvolvida. Para realizar a definição da arquitetura que seria adotada foi criada uma adaptação do processo apresentado em (Meier et al., 2008). Os passos para definição e avaliação de arquitetura utilizados nesse trabalho são descritos a seguir:

71

4.3. DEFINIÇÃO DE ARQUITETURA

1. Identificação dos objetivos da Arquitetura: nessa etapa os objetivos da arquitetura pretendida são claramente definidos. Objetivos claros ajudam a focar na resolução do problema e identificar quando uma arquitetura adequada foi encontrada. 2. Visão geral da aplicação: nessa etapa o objetivo é entender o tipo de aplicação, restrições de implantação, identificar estilos arquiteturais importantes e determinar tecnologias relevantes para a implementação de uma possível solução. 3. Pontos Críticos: são identificados pontos críticos da arquitetura da aplicação para entender as áreas onde os erros normalmente acontecem. Os prontos são agrupados em termos de atributos de qualidade e interesses transversais. 4. Possíveis Soluções: apartir das informações obtidas até esse ponto é possível verificar a existência de arquiteturas pré-existentes que possivelmente possam ser adotadas para a solução pretendida. A escolha de arquiteturas candidatas leva em consideração a adequação aos requisitos funcionais e não-funcionais da aplicação, pontos críticos e restrições de deployment. 5. Proposta de solução de arquitetura: caso existam arquiteturas pré-existentes ou estilos arquiteturais que sejam adequados ao contexto, nessa fase é realizado a escolha de uma proposta. Caso não seja encontradas propostas de arquiteturas, uma arquitetura deve ser definida baseado nos requisitos funcionais, não-funcionais e pontos críticos. 6. Prototipagem: nessa etapa é desenvolvido um pequeno protótipo que servirá como prova de conceito e tem como objetivo identificar possíveis problemas de implementação durante a adoção da proposta selecionada. 7. Avaliação dos resultados: Após a implementação do protótipo, os pontos positivos e negativos da abordagem são apresentados de forma a verificar se a solução de arquitetura implementada no protótipo é adequada para o produto a ser desenvolvido.

4.3.1

Identificação dos objetivos da Arquitetura

Diante de um cenário onde era necessário atender a interesses dos usuários finais, clientes, desenvolvedores e do próprio provedor de serviço, foi necessário identificar quais eram esses interesses que poderiam influenciar no projeto:

72

4.3. DEFINIÇÃO DE ARQUITETURA

• Usuários finais da aplicação: interessados em requisitos funcionais corretos e usabilidade • Clientes do provedor de serviço: preço acessível, atendimento aos requisitos funcionais do negócio, retorno de investimento • Desenvolvedor: separação entre requisitos multi-tenancy e requisitos funcionais da aplicação, facilidade de execução de testes. • Provedor de serviços: uso eficiente de recursos computacionais, prazo e custo. Apartir dos interesses dos stakeholders e dos requisitos funcionais e não funcionais, definimos o objetivo que nossa arquitetura deveria alcançar: • Consumo de recursos computacionais otimizados; • Independência entre requisitos funcionais e requisitos relacionados a implementação de multi-tenancy(autenticação e autorização, configurabilidade, acesso a dados, etc...); • A aplicação será executada em ambiente web, tendo como principal cliente o browser; • A arquitetura deve facilitar o desenvolvimento de testes automatizados; • A arquitetura deve permitir que os módulos relacionados aos requisitos multitenancy sejam reutilizados em projetos futuros; • A arquitetura deve facilitar a integração da aplicação SaaS com outras aplicações utilizadas pelo cliente;

4.3.2

Visão geral da aplicação

Apartir dos requisitos funcionais identificou-se 3 perfis de atores necessários para o funcionamento da primeira versão da aplicação: • Usuário Final: é o usuário da aplicação responsável por cadastrar as informações sobre as linhas de produto de software documentadas através de nossa aplicação. Esse usuário poderá acessar funcionalidades relacionada a gerencia de projetos, gerencia de risco, gerencia de escopo, gerencia de requisitos e gerencia de testes.

73

4.3. DEFINIÇÃO DE ARQUITETURA

Figura 4.3 Diagrama de Caso de Uso da Aplicação Alexandria(Fonte: Elaboração própria)

• Consumidor de SaaS: é o usuário do lado do cliente que possui maior privilégio no uso da aplicação. Além do acesso a todas a funcionalidades disponibilizadas para o perfil Usuário Final, esse perfil é associado ao usuário que contrata nosso software através de uma interface web. Esse usuário é responsável pelo gerenciamento dos outros usuários(cadastro, exclusão de usuários, alteração de dados do usuário) • Provedor de serviço: poderá ter acesso à funcionalidades de gerenciamento e monitoramento dos tenants da aplicação. A Figura 4.3 apresenta um diagrama de caso de uso que tem o objetivo de apresentar uma visão geral dos requisitos funcionais da aplicação. Esse diagrama foi construído apartir das informações já descritas na seção 4.1. Para implementar nossa aplicação, identificou-se alguns estilos arquiteturais em (Team, 2009), que poderiam servir como base para a definição de arquitetura da aplicação: • Cliente/Servidor: como o sistema deveria funcionar na web esse estilo arquitetural apresentou-se como uma solução a ser escolhida. Nele é apresentado o conceito de cliente e servidor, onde o servidor recebe requisições de vários clientes.

74

4.3. DEFINIÇÃO DE ARQUITETURA

• Baseado em componentes: esse estilo arquitetural decompõe o projeto de software em componentes funcionais ou lógicos que expõem interfaces de comunicação bem definidas que contenham métodos, eventos e propriedades. • Baseado em camadas: esse estilo arquitetural é focado no agrupamento funcional da aplicação em camadas distintas, empilhadas verticalmente. A funcionalidade em cada camada está relacionada a um papel ou responsabilidade comum. A comunicação entre camadas é explícita e fracamente acoplada. • Orientado a Objetos: estilo arquitetural baseado no paradigma orientado a objetos, no qual ocorre a divisão de responsabilidades do sistema em objetos reusáveis e coesos, que contém dados e comportamentos relevantes. Uma proposta final de arquitetura pode sofrer influência de vários estilos arquiteturais. A decisão de qual estilo arquitetural pode influenciar a solução proposta depende de quais benefícios cada estilo pode oferecer. A Tabela 4.1 apresenta os pontos que foram considerados quando definimos que os quatro estilos arquiteturais supracitados poderiam beneficiar nossa solução final. Escolhidos os estilos arquiteturais que seriam tomados como base, o proximo passo seria escolher as tecnologias que seriam utilizadas para a implementação da solução. Um ponto levado em consideração aqui foi o fato dos desenvolvedores já possuirem experiências prévias com desenvolvimento de aplicações na plataforma Java. Com o objetivo de evitar que seja gasto muito tempo com curvas de aprendizado de novas tecnologias, decidiu-se buscar para a implementação tecnologias ou propostas baseadas nessa plataforma. Dado que um dos objetivos do projeto seria criar uma solução que proporcionasse o máximo de reuso possível, encontrou-se 2 abordagens relevantes. A primeira abordagem seria o desenvolvimento de uma aplicação web, cuja modularização seria implementada utilizando OSGi (Kaegi and Deugo, 2008; Stoev and Dimov, 2008). A segunda abordagem seria a utilização de Grails1 , um framework de desenvolvimento de aplicações web que utiliza uma abordagem baseada em plugins, na qual várias funcionalidades da aplicação podem ser implementadas como plugins reutilizáveis. Antes da escolha de qualquer abordagem deve-se levar em consideração alguns pontos críticos que são apresentados na seção seguinte.
1 http://grails.org

75

4.3. DEFINIÇÃO DE ARQUITETURA

Estilo Arquitetural

Benefícios • A aplicacão deverá suportar vários clientes.

Cliente/Servidor

• A aplicacão deverá ser acessada através do browser. Centralização de armazenamento de dados, backup e funcionalidades de gerenciamento. • A aplicação poderá suportar diferentes tipos de clientes de diferentes tipo de dispositivos. • Possibilidade de obter componentes de fornecedores externos.

Baseado em componentes

• Possibilidade de criar uma arquitetura plugável que permita, com o mínimo de esforço possível, substituir ou atualizar componentes individuais. • Diminuição da complexidade da aplicação através do agrupamento funcional em diferentes áreas de interesse.

Baseado em camadas

• Melhorar a manutenibilidade e extensibilidade da aplicação através da minimização de dependencias. • Possibilidade de implementação de regras de negócio complexas e configuráveis, que poderiam ser agrupadas em uma camada específica. • Capacidade de modelar a aplicação baseada em objetos e ações do mundo real.

Orientado a Objetos

• Necessidade de encapsular lógica e dados juntos em componentes reusáveis.

Tabela 4.1 Estilos arquiteturais escolhidos e suas influências em nossa arquitetura

76

4.3. DEFINIÇÃO DE ARQUITETURA

4.3.3

Pontos Críticos e Soluções

Para definir as tecnologias e a proposta de arquitetura mais adequadas para nosso caso, foi necessário definir alguns atributos de qualidade desejáveis para nossa aplicação, como pode ser visto na Tabela 4.2. Além dos pontos críticos considerados, antes de propor qualquer solução, fez-se necessário verificar a existência de propostas de arquitetura para aplicações multi-tenancy existentes na literatura. Foram analisadas as arquiteturas encontradas durante o mapeamento sistemático realizado no Capítulo 3. Na seção 3.5.2 foram identificados 2 tipos de arquiteturas: definições de arquitetura para aplicações multi-tenancy (Yuanyuan et al., 2009; Jing and Zhang, 2010; Koziolek, 2010; Bezemer et al., 2010; Bezemer and Zaidman, 2010; Azeez et al., 2010; Pervez et al., 2010b; Tsai et al., 2010d; Calero et al., 2010; Oh et al., 2011; Koziolek, 2011) e para plataformas que suportam aplicações multi-tenancy (Weissman and Bobrowski, 2009; Cheng et al., 2009; Takahashi et al., 2010). Para a escolha da arquitetura de nossa aplicação foram analisadas apenas as propostas de arquitetura para aplicações. A principal preocupação na escolha seria identificar uma arquitetura que já tivesse sido validada na indústria, que tivesse maior aderência aos requisitos de nossa aplicação e aos atributos de qualidade definidos. Além disso era necessário verificar a possibilidade de atendimento a requisitos futuros de segurança, performance, alocação de recursos, armazenamento de dados, modularização e todos os outros pontos importantes em uma aplicação multi-tenancy que foram vistos no mapeamento sistemático. Nem todos esses requisitos foram atendidos de imediato, mas era de fundamental importância que a abordagem escolhida desse suporte a tais requisitos. Partindo desse princípio a arquitetura escolhida como referência para nossa implementação foi a apresentada por Bezemer (Bezemer et al., 2010). Embora essa arquitetura tenha sido a escolhida, não foi descartado a possibilidade de utilização de conceitos e abordagens apresentadas nos outros trabalhos. Outro ponto crítico é que já existia uma aplicação legada implementada na linguagem de programação python, que já possuía dados pré-existentes. Essa aplicação legada já implementava alguns requisitos do meta-modelo implementado(Cavalcanti et al., 2011), mas não adotava o modelo de Software como Serviço(SaaS). Antes da implantação da primeira versão da aplicação seria necessário realizar a migração dos dados já cadastrados pela aplicação legada. A separação de interesses entre requisitos relacionados ao negócio principal da aplicação e requisitos inerentes a multi-tenancy também é um fator crítico que deve ser levado em consideração. A aplicação deveria ser implementada de forma o código

77

4.3. DEFINIÇÃO DE ARQUITETURA

de regra de negócio sofresse o mínimo de interferência possível do código associado a implementações de multi-tenancy. A arquitetura escolhida como referência foi a que melhor se adequou a esse cenário.

4.3.4

Proposta de solução de arquitetura

Multi-tenancy afeta quase todas as camadas de uma aplicação típica e possui um grande potencial para ser implementado como interesse transversal. Para reduzir a complexidade do código, a implementação de requisitos multi-tenancy deve ser separada da lógica de negócio o máximo possível. Caso contrário, a manutenção pode se tornar um pesadelo, porque: • Implementar código de requisitos da arquitetura multi-tenancy juntamente com a lógica de negócio dos tenants, exige que todos os desenvolvedores sejam reeducados para entenderem os conceitos de multi-tenancy; • Misturar multi-tenancy com código de lógica de negócio dos tenants leva ao aumento da complexidade da implementação, pois é mais difícil manter o controle de onde o código multi-tenancy é introduzido. Estes problemas podem ser superados integrando cuidadosamente multi-tenancy na arquitetura. No restante desta seção, descrevemos os componentes da arquitetura abordada por Bezemer (Bezemer et al., 2010) para implementação de multi-tenancy como um interesse transversal. A Figura 4.4 apresenta a descrição dessa aplicação e as subseções seguintes descrevem cada componente da aplicação. Autenticação Pelo motivo de uma aplicação multi-tenancy ter apenas uma instância da aplicação e do banco de dados, todos os tenants usam o mesmo ambiente físico. A fim de oferecer a customização do ambiente e ter certeza de que os tenants podem acessar somente os seus próprios dados, tenants devem ser autenticados. Enquanto autenticação de usuário é, possivelmente, já presente na aplicação de destino, um mecanismo separado de autenticação de tenants específicos pode ser necessário, por duas razões: (1) geralmente é muito mais fácil introduzir um mecanismo de autenticação adicional, do que mudar um já existente, e (2) autenticação de tenants permite que um único usuário faça parte de mais do que uma organização lógica, o que estende a idéia de autenticação de usuários com "grupos".

78

4.3. DEFINIÇÃO DE ARQUITETURA

Atributo Disponibilidade

Considerações • Como planejar backups e restaurações • Como projetar a aplicação para atualizações em tempo de execução • • • • • • • • Como isolar a aplicação de dependencias externas Como criar um caminho Como criar um plano para atualização de tecnologias Como evoluir a aplicação sem prejudicar o cliente Como tratar regras de negócio dinamicamente Como tratar dinamicamente interface com o usuário Como tratar mudanças em dados e lógica de processamento Como tratar mudanças em requisitos de negócio

Integridade Conceitual

Flexibilidade

Interoperabilidade

• Como prover interoperabilidade entre aplicacões enquanto elas evoluem • Como isolar sistemas através de interfaces de serviço • Como reduzir dependências entre camadas e componentes • Como implementar uma arquitetura plugável • Como monitorar operações e saúde do sistema • Como modificar o comportamento do sistema baseado em sua carga • Como determinar uma estratégia de caching • Como gerenciar recursos eficientemente • Como reduzir duplicaçãode código entre componentes e camadas • Como compartilhar funcionalidades através de sistemas • Como compartilhar funcionalidades através de componentes e camadas • Como ajustar a aplicação para aumento e diminuição de carga • Como lidar com os picos no trafego e carga • Como lidar com autenticação e autorização • Como proteger-se de entradas mal intencionadas • Como proteger dados sensíveis • Como projetar a aplicação para testabilidade • Como projetar testes de unidade • Como evitar armadilhas comuns de experiência com usuário

Manutenibilidade

Gerenciabilidade

Performance

Reusabilidade

Escalabilidade

Segurança

Testabilidade

Usabilidade

Tabela 4.2 Atributos de qualidade desejáveis na arquitetura

79

4.3. DEFINIÇÃO DE ARQUITETURA

Figura 4.4 Arquitetura de Referência adotada(Fonte: (Bezemer et al., 2010))

Configuração Em uma aplicação multi-tenancy a customização deve ser possível através de configuração. A fim de permitir que o usuário tenha uma experiência como se ele estivesse trabalhando em um ambiente dedicado, é necessário permitir pelo menos os seguintes tipos de configuração: Estilo de Layout(Layout Style): O componente de configuração de estilo de layout permite o uso de temas e estilos específicos. Configuração Geral (General Configuration) O componente de configuração geral permite a especificação de configurações específicas, como configurações de chave de criptografia e detalhes do perfil pessoal. Entrada e saída de arquivo (File I/O) O componente de configuração de I/O de arquivo permite a especificação de caminhos de arquivos, que podem ser usados para, por exemplo, geração de relatório. Fluxo de trabalho (Workflow) O componente de configuração de fluxo de trabalho permite a configuração de fluxos específicos. Por exemplo, configuração de fluxos é necessária em uma aplicação de planejamento de recursos empresariais -

80

4.3. DEFINIÇÃO DE ARQUITETURA

ERP, em que o fluxo de requisições pode variar significativamente para diferentes companhias. Banco de dados (Database) Em uma aplicação multi-tenancy há uma grande exigência para o isolamento dos dados. Porque todos os tenants usam a mesma instância de um banco de dados é necessário ter certeza de que eles podem acessar somente seus próprios dados. Atualmente sistemas de gerenciamento de dados (Data Base Management Systems - DBMS) de prateleira não são capazes de lidar com multi-tenancy, isso deve ser feito em uma camada entre a camada lógica de negócios e o pool de banco de dados de aplicações. As principais tarefas dessa camada são as seguintes: Criação de novos tenants no banco de dados: Se a aplicação armazena ou recupera dados que podem ser de tenants específicos, é tarefa da camada de banco de dados criar os registros do banco de dados correspondente quando um novo tenant se inscreveu para a aplicação. Adaptação de consulta: A fim de prover um isolamento de dados adequado, a camada de banco de dados deve ter certeza que consultas são ajustadas de forma que cada tenant possa acessar somente seus próprios registros. Balanceamento de carga: Para melhorar o desempenho de uma aplicação multi-tenancy é necessário um balanceamento de carga eficiente para o pool de banco de dados. Note que qualquer acordo feito no SLA de um tenant e quaisquer restrições impostas pela legislação do país onde o tenant está localizado deve ser satisfeita. Por outro lado, nossa expectativa é a de que é possível criar algoritmos de balanceamento de carga mais eficientes usando as informações coletadas sobre as características de funcionamento dos tenants.

4.3.5

Tecnologias

Após a escolha de uma arquitetura de referência para ser adotada por nossa aplicação, tem-se a necessidade de escolher as tecnologias que serão adotadas para a implementação. Devido ao perfil da equipe de desenvolvimento optou-se por escolher tecnologias que executassem na plataforma Java para aproveitar a experiência da equipe. Durante a

81

4.3. DEFINIÇÃO DE ARQUITETURA

escolha dessas tecnologias avaliou-se a possibilidade do uso de JSF2 , Struts 23 , Spring Framework4 e Grails5 . Apartir de reuniões com os envolvidos observou-se que Grails apresentava um conjunto de recursos que poderiam dar produtividade para a equipe de desenvolvimento que não foram encontrados nas outras tecnologias como geração de CRUD (Create, Read, Update e Delete), arquitetura baseada em plugins que permite a criação e reuso de componentes, e total integração com frameworks e APIs Java. O Grails é um framework web open-source que utiliza a linguagem Groovy6 , e outros frameworks consagrados como Hibernate7 , Spring Framework e Sitemesh8 . Uma descrição visual da arquitetura do Grails é apresentada na Figura 4.5. O Grails foi projetado para desenvolver aplicações CRUD de forma simples e ágil, utilizando o modelo de "escrever código por convenção"introduzido pelo Ruby on Rails. O Grails propõe-se a trazer a produtividade do Ruby on Rails para a plataforma Java, porém ele possui uma grande vantagem, já que é baseado na linguagem Groovy. Groovy (padronizado pela JSR-241) é uma linguagem dinâmica e ágil para a plataforma Java, que possui muitas características de linguagens de script como Ruby, Python e Smalltalk, e além disso aplicações Groovy podem utilizar classes Java facilmente. Linguagens de script estão ganhando cada vez mais popularidade, devido a quantidade reduzida de código fonte necessário para implementar determinadas funcionalidades, se comparado com uma implementação em Java. A aplicação que está sendo desenvolvida, em particular se beneficiará da capacidade de definir métodos e propriedades em tempo de execução, disponibilizado pela linguagem Groovy. Essa característica da linguagem Groovy é chamada de metaprogramação. Em uma linguagem estática como Java, o acesso a uma propriedade ou invocação de um método é resolvido em tempo de compilação. Em comparação, Groovy não resolve o acessos à propriedades ou invocação de métodos até que a aplicação seja executada (Richardson, 2009). Uma aplicação que utiliza essa linguagem pode dinamicamente definir métodos ou propriedades em tempo de execução, isso vai de encontro à necessidade de customização das aplicações, dado que, com a utilização desse recurso, pode-se adicionar atributos e customizar comportamentos de um tenant específico futuramente. Outro ponto que influenciou bastante na escolha de Grails foi sua arquitetura baseada
2 http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 3 http://struts.apache.org/2.3.1.2/index.html 4 http://www.springsource.org/spring-framework 5 http://grails.org 6 http://groovy.codehaus.org 7 http://www.hibernate.org 8 http://www.sitemesh.org

82

4.3. DEFINIÇÃO DE ARQUITETURA

Figura 4.5 Arquitetura do Grails Framework(Fonte: (Judd et al., 2008))

em plugins. Grails não se propõe a ter todas as respostas e soluções para o desenvolvimento de aplicações web. Ao invés disso, ele provê uma arquitetura baseada em plugins e um repositório mantido pela comunidade de desenvolvedores onde é possível encontrar plugins que implementam as mais diversas funcionalidades como segurança, AJAX, teste, busca, geração de relatórios, web services, etc. Essa abordagem proporciona o reuso e permite que funcionalidades de difícil implementação possam ser adicionadas na aplicação de forma bastante simples. Além das tecnologias relacionadas à programação, foi necessário escolher a tecnologia utilizada para armazenamento de dados. Como já existiam dados legados cadastrados em um banco de dados relacional, decidiu-se adotar o SGBD PostgreSQL. A escolha desse SGBD deu-se pelo fato do mesmo ser open-source bastante consolidado no mercado e possuir integração com várias ferramentas de relatórios, o que poderia facilitar futuras extrações de dados para os clientes.

4.3.6

Prototipagem

Apartir da escolha da arquitetura de referência, das tecnologias a serem adotadas e da divisão dos módulos da aplicação chegou-se a proposta de arquitetura apresentada na Figura 4.6. Em nossa proposta a nossa aplicação possui 5 módulos associados à lógica de negócio da aplicação, esses módulos foram descritos anteriormente na seção 4.1. Foi adotado o Framework Grails para auxílio ao desenvolvimento da aplicação web e juntamente com ele foram adotados alguns de seus plugins. Para validar nossa arquitetura foi desenvolvido um protótipo contendo uma parte pequena dos requisitos funcionais da aplicação. Nesse protótipo serão implementados os cadastros de Projeto, Módulo e Features. A implementação do protótipo tem o objetivo de verificar a viabilidade de implementação e o atendimento dos objetivos da arquitetura.

83

4.3. DEFINIÇÃO DE ARQUITETURA

Figura 4.6 Arquitetura da Aplicação(Fonte: Elaboração própria)

Como mencionado anteriormente na seção 4.3.4, existe uma grande necessidade de separar código de lógica de negócio de código relacionado aos requisitos multitenancy. Com o objetivo de implementar os requisitos multi-tenancy de forma reutilizável, a solução foi implementar esses requisitos como um plugin do Grails, dessa forma aplicações futuras poderiam se beneficiar do código implementado. Uma vantagem do uso dessa abordagem é que dentro de um plugin grails é possível adicionar não só classes implementadas em Groovy ou Java, mas também páginas da camada de visão e outros tipos de arquivo. Antes de implementar os requisitos multi-tenancy como plugin foi realizado uma pesquisa no repositório de plugins do Grails para verificar se já existia algo semelhante ao que pretendia-se implementar. Durante a pesquisa foi encontrado o plugin Multi-tenancy Core9 que implementa as funcionalidades de 2 dos componentes mencionados em nossa arquitetura de referência(Bezemer et al., 2010), o componente de autenticação e o componentes de acesso ao banco de dados. Esse plugin implementa a funcionalidade de associar um usuário da aplicação a um tenant específico e além disso realiza de forma dinâmica o filtro dos dados durante uma consulta ao banco de dados, de forma que um usuário da aplicação tenha acesso apenas aos dados vinculados ao seu tenant. A autenticação e controle de acesso pode ser realizado através da integração desse plugin com o Spring Security10 , um framework de controle de acesso bastante utilizado em aplicação Java. O terceiro componente mencionado em nossa arquitetura de referência é o componente de configuração. O objetivo desse componente de gerenciar as configurações relacionadas a cada tenant e prover funcionalidades de customização da aplicação para cada tenant. Essa customização pode ir desde alterações em interface com o usuário até alteração nas
9 http://multi-tenancy.github.com/grails-multi-tenancy-core 10 http://static.springsource.org/spring-security/site/index.html

84

4.4. MIGRAÇÃO DO SISTEMA

classes de negócio, tudo isso realizado de forma dinâmica. Durante nossa pesquisa foi encontrado o plugin Dynamic Domain Class11 que proporciona a criação de classes de domínio de forma dinâmica, esse plugin ajudou a validar a idéia de usar Groovy e Grails para customizar as classes de domínio em tempo de execução. Durante a implementação detectou-se que o padrão de geração de telas do Grails não satisfazia aos anseios dos usuários quanto à forma de interação com o aplicativo. Apartir dessa necessidade foi desenvolvido um plugin para implementar o padrão de tela Mestre/Detalhe(Neil, 2010), não implementado nativamente pelo gerador de telas padrão do Grails. Durante a implementação desse plugin identificou-se que poderia ser viável implementar módulos completos da aplicação como plugins Grails, desde classes de negócio à camada de visão. Após a implementação do protótipo foi realizado a avaliação do protótipo para verificar quais atributos de qualidade desejáveis foram atendidos. A Tabela 4.3 apresenta para cada atributo de qualidade uma breve descrição de como ele foi atendido. Após a avaliação do protótipo foi possível observar que nossa solução atendia a 8 dos 12 atributos de qualidade desejados. Quatro atributos de qualidade(disponibilidade, gerenciabilidade, performance, escalabilidade) não puderam ser avaliados durante a implementação do protótipo inicial. A avaliação foi considerada satisfatória, considerando que os quatro atributos de qualidade da arquitetura que não foram atendidos inicialmente não geraram nenhum impedimento para a geração da primeira versão do aplicativo. Ao fim da implementação do protótipo deu-se início ao desenvolvimento da aplicação real. Ao final da implementação da primeira versão da aplicação, foi necessário criar algum mecanismo para migrar os dados já cadastrados pela aplicação legada. Essa atividade será descrita na seção a seguir.

4.4

Migração do Sistema

A reengenharia de dados é um processo utilizado para padronizar dados de uma base para um formato comum, corrigindo problemas de qualidade de dados, removendo duplicação de informação, construindo novos relacionamentos entre tabelas ou enriquecendo a base de dados com informações suplementares. Sommerville(Sommerville, 2003) demonstra em sua obra 3 abordagens da engenharia de dados: limpeza de dados, extensão de dados e migração de dados. Durante a migração de dados é realizado um conjunto de tarefas que têm como objetivo garantir uma melhor qualidade dos dados migrados. Em (Neto
11 http://code.google.com/p/grails-dynamic-domain-class-plugin/

85

4.4. MIGRAÇÃO DO SISTEMA

ATRIBUTO Disponibilidade Integridade Conceitual Flexibilidade

Interoperabilidade Manutenibilidade

Gerenciabilidade Performance Reusabilidade

Escalabilidade Segurança

Testabilidade

Usabilidade

AVALIAÇÃO Como foi adotado um SGBD PostgreSQL, é possivel agendar tarefas automáticas no servidor para executar backups periódicos. Tanto as entidades de negócio quanto as classes utilitárias da aplicação foram modularizadas em plugins de forma que os interesses da aplicação foram bem definidos e separados. A flexibilidade pode ser alcançada através do uso das característica de linguagem dinâmica existente na linguagem Groovy. Dessa forma é possivel criar Entidade de domínio e alterar entidades já existentes em tempo de execução, caso seja necessário. O uso de plugins Grails permite que os dados da aplicação possam ser expostos através de REST ou Web Services para os usuários. A arquitetura de plugins do Grails facilita a manutenção dos código já que cada plugin pode ser mantido separadamente, reduzindo as dependências entre os componentes da aplicação. Não foi possivel identificar soluções para esse atributo durante a implementação do protótipo. Não foi possivel identificar soluções para esse atributo durante a implementação do protótipo. As partes da aplicação implementadas como plugins podem ser reutilizadas em aplicações futuras facilmente, sem a necessidade de qualquer adaptação no plugin. Não foi possivel identificar soluções para esse atributo durante a implementação do protótipo. A autenticação e controle de acesso puderam ser garantidos pelo uso do Framework Spring Security, que pôde ser facilmente integrado com o plugin de multi-tenancy no atendimento do requisito de isolamento de acesso entre dados dos tenants. O Grails Framework provê uma infraestrutura para auxiliar na implementação de testes unitários que utiliza JUnit, um framework de teste para aplicações java. Durante a criação de uma classe o Grails Framework já cria uma classe de testes correspondente para otimizar o tempo de desenvolvimento. Grails trabalha com templates para geração de telas. Embora já possua um template padrão, o desenvolvedor pode implementar um template próprio que atenda à necessidades específicas de interação com o usuário. O template padrão do Grails Framework já implementa alguns padrões de usabilidade bem estabelecidos no mercado.

Tabela 4.3 Resultado da aplicação dos critérios de exclusão(Fonte: Elaboração própria)

86

4.4. MIGRAÇÃO DO SISTEMA

and Passos, 2009) 3 projetos de migração de dados foram analisados e juntamente com a migração de dados, identificou-se que foi necessário realizar a limpeza dos dados para corrigir inconsistências existentes nos bancos de dados origem. Daniel Aebi e Reto Largo (Aebi and Largo, 1994) apresentam vários problemas que podem ser encontrados durante o processo de migração e reengenharia de dados. Alguns desse problemas foram detectados nos projetos de migração analisados: • Mapeamento de esquema - atributos e tabelas do esquema antigo precisam ser mapeados para o novo esquema de acordo com os requisitos da nova modelagem. • Tabelas e relacionamentos - tabelas novas podem ser introduzidas ou relacionadas com as tabelas já existentes. Para estabelecer um relacionamento apropriado valores correspondentes devem ser fornecidos de alguma forma. • Heterogeneidade de chaves-primárias - tabelas são identificadas por diferentes construções de chaves. Por exemplo, uma tabela pode ser identificada por um conjunto de atributos na base de dados legada, enquanto que na base nova é introduzido um atributo chave para a tabela. • Atributos - atributos na nova base podem utilizar tipos diferentes. Adição ou remoção de atributos podem causar diferenças entre a mesma tabela nos bancos legado e novo. • Identificação de objetos - algumas entidade podem aparecer duplicadas no mesmo contexto. Essas duplicatas devem ser identificadas e removidas para evitar redundância. • Conflito de limites - o valor de um atributo pode não ser compatível com o limite definido. Por exemplo, um valor negativo em um campo que deveria conter somente valores positivos. • Diferenças de unidade, escala e granularidade - alguns cálculos podem ter mudado com o tempo, mas o formato dos dados podem não ter sido ajustados após isso. As unidades de medida do sistema novo podem diferir do sistema antigo. • Codificação - valores de dados freqüentemente podem possuir definição de codificação diferente. O novo sistema pode ter um esquema de codificação diferente. • Inconsistência de valores default - para certos campos o valor default definido pode ser diferente. O valor default pode ser 0 em uma base de dados e em outra -1.

87

4.4. MIGRAÇÃO DO SISTEMA

Durante a avaliação e planejamento do processo de migração de dados, foram identificadas as seguintes atividades: • Migração de dados entre bancos de dados relacionais com diferenças na modelagem • Migração entre SGBDs relacionais de fabricantes diferentes. O SGBD origem dos dados era MySQL e o SGBD destino PostgreSQL. • Correção de inconsistências existentes na base de dados origem. • Conversão de alguns dados para permitir a compatibilidade com a nova aplicação. Com o objetivo de agilizar o processo de implementação e execução do processo de migração foi necessário a adoção de uma ferramenta para automatizar o processo. Para realizar essa tarefa foi escolhida a ferramenta JExodus (Neto and Passos, 2009). Essa ferramenta foi desenvolvida anteriormente pelo autor desse trabalho e dá suporte a resolução de parte dos problemas encontrados durante o processo de migração e reengenharia de dados, como: mapeamento de esquemas, novas tabelas e relacionamentos, atributos de tipos diferentes, inconsistência de valor default, dentre outros. O JExodus foi desenvolvido para realizar a migração de bases de dados tendo como fonte de dados um SGBD, documentos de texto ou objetos Java, de forma que o desenvolvedor efetue a migração de dados sem se preocupar com detalhes de baixo nível como conexão com bancos de dados, comandos SQL ou implementar código para ler dados de diversas fontes diferentes. Essa ferramenta não tem como objetivo principal a migração de dados entre bancos com mesma modelagem de dados e SGBDs diferentes, mas sim a migração entre bases de dados com modelagens diferentes e SGBDs diferentes, isso foi de grande ajuda para nosso projeto já que existiam diferenças consideráveis na modelagem de dados entre o banco de dados origem e destino. Para realizar a tarefa de migração o JExodus utiliza o framework Hibernate e a API JDBC (Java Database Connectivity). Baseado em metadados informados via XML, o JExodus monta comandos SQL (select,insert e update) baseados no dialeto do banco utilizado, que é informado através de um mapeamento, esses dialetos são os mesmos utilizados pelo Hibernate. O JExodus disponibiliza formas do desenvolvedor implementar código java que manipule os dados que estão sendo migrados. Para cada campo migrado é possível implementar uma classe que execute correção ou algum tratamento do valor da coluna que está sendo migrada, essa funcionalidade foi bastante utilizada durante nosso projeto de migração. Essa abordagem favorece o reuso das classes de tratamento e correção

88

4.5. CONSIDERAÇÕES FINAIS

de valores, já que elas podem ser reutilizadas no mapeamento de várias colunas. Essa funcionalidade da ferramenta permitiu a implementação de código java para realizar a correção de inconsistências existentes nos dados migrados. Com a utilização dessa ferramenta, a migração foi realizada sem grandes dificuldades. O produtividade provida pela mesma permitiu que mais tempo do projeto pudesse ser dedicado à atividade de verificação da corretude dos dados após o processo de migração.

4.5

Considerações Finais

Esse capítulo apresentou as experiências obtidas durante o processo de desenvolvimento de uma aplicação multi-tenancy em uma empresa real. Durante o capítulo foi apresentado a metodologia utilizada durante o desenvolvimento, bem como a descrição de cada passo realizado e cada decisão tomada durante todo o processo. No processo de desenvolvimento foram utilizadas várias informações obtidas apartir do mapeamento sistemático realizado no capítulo anterior, essas informações serviram como um guia para os desenvolvedores durante o processo de desenvolvimento. No decorrer desse capítulo, foi descrito a escolha de uma arquitetura utilizada como referência durante a implementação, bem como a escolha de tecnologias e seu uso no projeto. Um protótipo inicial foi implementado com o objetivo de validar a solução proposta e identificar os atributos de qualidade alcançados com a proposta de implementação apresentada. Ao final foi descrito como os dados foram migrados após a conclusão da primeira versão da aplicação.

89

5
Conclusão e Trabalhos Futuros
Nos últimos anos muitas empresas têm saído do modelo de entrega de software empacotado para o modelo de fornecimento de software na web. Essas aplicações entregues através da web vão desde emails a calendários, sistemas colaborativos, publicações online, processadores de texto simples, aplicações para negócios e aplicações para uso pessoal. Com o aumento da popularidade de marketing baseado em web, e-commerce e muitos outros serviços baseados em web, mesmo os pequenos negócios tem sido obrigados oferecer seus produtos e serviços na internet para serem competitivos no mercado. A característica de compatilhamento de recursos e diminuição de custos trazidos por multi-tenancy, tem feito dessa abordagem uma excelente alternativa para prover software de qualidade e com um baixo custo para pequenas e médias empresas. Com o objetivo de validar a aplicabilidade de multi-tenancy e o nível de maturidade dessa abordagem, foi realizado um mapeamento sistemático da área para identificar, através de evidências encontradas em publicações e resultados de pesquisa, os principais requisitos e interesses associados a esse estilo de arquitetura. Foi realizado um levantamento de um vasto material bibliográfico que ajudou a identificar como diversos problemas associados a multi-tenancy, soluções para alguns desses problemas e como seus requisitos seriam implementados. Identificou-se também os tipos de pesquisas realizados na área e as principais contribuições dos trabalhos encontrados. Adicionalmente foi apresentado nesse trabalho o resultado da aplicação dos conceitos encontrados no mapeamento sistemático, através da experiência de desenvolvimento de um aplicativo multi-tenancy em uma indústria de software. Durante essa atividade foi possível confrontar os resultados encontrados na bibliografia com reais necessidades do mercado, permitindo verificar em ambiente de produção se os resultados encontrados na academia realmente seriam aplicáveis no mercado de software. Apresentamos uma proposta de implementação com foco em reuso, que realiza a separação de interesses

90

5.1. CONTRIBUIÇÕES

através do uso de uma arquitetura de plugins. Isso permitiu que código de lógica de negócio fosse saparado do código de implementação dos requisitos específicos de multitenancy. Concluímos que a implementação de multi-tenancy não só é viável do ponto de vista de negócios como do ponto de vista técnico, embora ainda existam problemas e pontos de melhoria que devem ser tratados.

5.1

Contribuições

• Apresentação uma visão geral da arquitetura multi-tenancy, explicando os principais conceitos úteis para entendimento deste trabalho; • Identificação de fatores que influenciam na adoção e desenvolvimento de SaaS multi-tenancy; • Classificação dos estudos primários e dos artefatos encontrados de forma a auxiliar no desenvolvimento de uma aplicação multi-tenancy • Combinação dos resultados encontrados no mapeamento sistemático com uma aplicação prática na indústria. • Organização dos trabalhos encontrados em categorias que podem auxiliar na definição de uma agenda de pesquisa na área de multi-tenancy • Apresentação e implementação de uma arquitetura multi-tenancy que proporciona um alto grau de reuso dos artefatos implementados. • Validação dos conceitos encontrados através de experiência prática na indústria

5.2

Trabalhos Futuros

Considera-se que o presente trabalho atingiu o objetivo proposto. Porém, a abordagem utilizada merece algumas extensões e melhorias na forma de trabalhos futuros, os quais são especificados a seguir: • Implementação da arquitetura proposta utilizando outras linguagens – seria muito útil verificar como a arquitetura seria implementada utilizando outras tecnologias e linguagens de programação, e realizar um comparativo das abordagens.

91

5.2. TRABALHOS FUTUROS

• Avaliar benefícios do uso núvens públicas para implantar multi-tenancy – avaliação de quais recursos são oferecidos por provedores de cloud existentes no mercado (Amazon AWS, Google App Engine, Microsoft Azure, etc) que podem ser utilizados em uma aplicação multi-tenancy para garantir disponibilidade, escalabilidade, gerenciabilidade e performance. • Avaliar a utilização de SGBDs não relacionais para armazenamento de dados – como o objetivo de aplicações multi-tenancy é prover serviços para o máximo de usuários possível apartir de uma única instância da aplicação, SGBDs não relacionais (NoSQL) apresentaram-se como uma boa alternativa para esse propósito. O objetivo aqui é validar essa idéia apartir de experimentos e implementações práticas. • Migração de dados do modelo relacional para o modelo não-relacional – caso seja identificado que bancos de dados não relacionais são a melhor escolha para armazenamento de dados em aplicações multi-tenancy, pretende-se estender a ferramenta de migração de dados utilizada nesse trabalho para suportar a migração para SGBDs não-relacionais. • Estudo empírico de abordagens de customização de aplicações multi-tenancy – estudo aprofundado e comparativo de abordagens de implementação de customização e gerenciamento de variabilidade em aplicações multi-tenancy. Além disso pretende-se validar, através de implementação e de experimentos, algumas das abordagens mais relevantes. • Definição de um processo para migração de aplicações single-tenant para multi-tenancy – pretende-se implementar mais cases de desenvolmento de aplicações multi-tenancy e migrações de aplicações single-tenant para multi-tenancy a fim de identificar passos e pontos que devem ser levados em consideração durante o processo de migração. • Avaliar empiricamente o grau de reusabilidade dos plugins – avaliar através de experimentos, o nível de reusabilidade dos plugins desenvolvidos durante esse trabalho.

92

Referências Bibliográficas

Aebi, D. and Largo, R. (1994). Methods and tools for data value re-engineering. In In Applications of Databases (ADB-94), volume 819 of LNCS, pages 400–411. Springer. Agarwal, P. (2011). Continuous scrum: agile management of saas products. In Proceedings of the 4th India Software Engineering Conference, ISEC ’11, pages 51–60, New York, NY, USA. ACM. Ahmad, M. and Bowman, I. T. (2011). Predicting system performance for multi-tenant database workloads. In Proceedings of the Fourth International Workshop on Testing Database Systems, DBTest ’11, pages 6:1–6:6, New York, NY, USA. ACM. Amazon (2011). What is AWS? Amazon Company. Disponível em: <http://aws.amazon.com/pt/what-is-aws>. Acesso em: 10 dez. 2011. Anderson, C. (2006). A Cauda Longa: Porque o Futuro dos Negócios é vender menos de mais. Hyperion. Arya, P. K., Venkatesakumar, V., and Palaniswami, S. (2010). Configurability in saas for an electronic contract management application. In Proceedings of the 12th international conference on Networking, VLSI and signal processing, ICNVS’10, pages 210–216, Stevens Point, Wisconsin, USA. World Scientific and Engineering Academy and Society (WSEAS). Aulbach, S., Grust, T., Jacobs, D., Kemper, A., and Rittinger, J. (2008). Multi-tenant databases for software as a service: schema-mapping techniques. In Proceedings of the 2008 ACM SIGMOD international conference on Management of data, SIGMOD ’08, pages 1195–1206, New York, NY, USA. ACM. Aulbach, S., Jacobs, D., Kemper, A., and Seibold, M. (2009). A comparison of flexible schemas for software as a service. In Proceedings of the 35th SIGMOD international conference on Management of data, SIGMOD ’09, pages 881–888, New York, NY, USA. ACM. Aulbach, S., Seibold, M., Jacobs, D., and Kemper, A. (2011). Extensibility and data sharing in evolving multi-tenant databases. In Data Engineering (ICDE), 2011 IEEE 27th International Conference on, pages 99 –110.

93

REFERÊNCIAS BIBLIOGRÁFICAS

Azeez, A., Perera, S., Gamage, D., Linton, R., Siriwardana, P., Leelaratne, D., Weerawarana, S., and Fremantle, P. (2010). Multi-tenant soa middleware for cloud computing. In Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, pages 458 –465. Babar, M. and Gorton, I. (2009). Software architecture review: The state of practice. Computer, 42(7), 26 –32. Babar, M. A., Zhu, L., and Jeffery, R. (2004). A framework for classifying and comparing software architecture evaluation methods. In Proceedings of the 2004 Australian Software Engineering Conference, ASWEC ’04, pages 309–, Washington, DC, USA. IEEE Computer Society. BBC News (2011). Twitter acquires Tweetdeck app for undisclosed fee. BBC News. Disponível em: <http://www.bbc.co.uk/news/technology-13518382>. Acesso em: 10 dez. 2011. Berberova, D. and Bontchev, B. (2009). Design of service level agreements for software services. In Proceedings of the International Conference on Computer Systems and Technologies and Workshop for PhD Students in Computing, CompSysTech ’09, pages 26:1–26:6, New York, NY, USA. ACM. Bezemer, C.-P. and Zaidman, A. (2010). Multi-tenant saas applications: maintenance dream or nightmare? In Proceedings of the Joint ERCIM Workshop on Software Evolution (EVOL) and International Workshop on Principles of Software Evolution (IWPSE), IWPSE-EVOL ’10, pages 88–92, New York, NY, USA. ACM. Bezemer, C.-P., Zaidman, A., Platzbeecker, B., Hurkmans, T., and ’t Hart, A. (2010). Enabling multi-tenancy: An industrial experience report. In Software Maintenance (ICSM), 2010 IEEE International Conference on, pages 1 –8. Brassil, J. (2010). Physical layer network isolation in multi-tenant clouds. In Distributed Computing Systems Workshops (ICDCSW), 2010 IEEE 30th International Conference on, pages 77 –81. Budgen, D., Turner, M., Brereton, P., and Kitchenham, B. (2008). Using mapping studies in software engineering. Proceedings of PPIG.

94

REFERÊNCIAS BIBLIOGRÁFICAS

Cai, H., Wang, N., and Zhou, M. J. (2010). A transparent approach of enabling saas multi-tenancy in the cloud. In Services (SERVICES-1), 2010 6th World Congress on, pages 40 –47. Calero, J., Edwards, N., Kirschnick, J., Wilcock, L., and Wray, M. (2010). Toward a multi-tenancy authorization system for cloud services. Security Privacy, IEEE, 8(6), 48 –55. Cavalcanti, Y. C., Do Carmo Machado, I., Da Mota, P. A., Neto, S., Lobato, L. L., De Almeida, E. S., and De Lemos Meira, S. R. (2011). Towards metamodel support for variability and traceability in software product lines. Proceedings of the 5th Workshop on Variability Modeling of SoftwareIntensive Systems VaMoS 11, (840), 49–57. Chen, C.-C., Yuan, L., Greenberg, A., Chuah, C.-N., and Mohapatra, P. (2011). Routingas-a-service (raas): A framework for tenant-directed route control in data center. In INFOCOM, 2011 Proceedings IEEE, pages 1386 –1394. Cheng, X., Shi, Y., and Li, Q. (2009). A multi-tenant oriented performance monitoring, detecting and scheduling architecture based on sla. In Pervasive Computing (JCPC), 2009 Joint Conferences on, pages 599 –604. Chong, F. and Carraro, G. (2006). Architecture strategies for catching the long tail. Disponível em: <http://msdn2.microsoft.com/en-us/library/aa479069.aspx>. Acesso em: 10 dez. 2011. Choudhary, V. (2007). Software as a service: Implications for investment in software development. In System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on, page 209a. Ciaccia, P., Ciancarini, P., and Penzo, W. (1997). Reusing software architectures: a formal basis. In Software Engineering for Parallel and Distributed Systems, 1997. Proceedings., Second International Workshop on, pages 256 –262. Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt, I., and Warfield, A. (2005). Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation - Volume 2, NSDI’05, pages 273–286, Berkeley, CA, USA. USENIX Association. Cusumano, M. (2008). The changing software business: Moving from products to services. Computer, 41(1), 20 –27.

95

REFERÊNCIAS BIBLIOGRÁFICAS

Diana, D., Mauricio, Gerosa, and Aurélio, M. (2010). Nosql na web 2.0: Um estudo comparativo de bancos não-relacionais para armazenamento de dados na web 2.0. Communications. Ding, X., Luo, R., and Hui, M. (2010). A multi-tenant oriented customizable compensation mechanism for workflows. In Broadband Network and Multimedia Technology (IC-BNMT), 2010 3rd IEEE International Conference on, pages 951 –955. Dobrica, L. and Niemela, E. (2002). A survey on software architecture analysis methods. Software Engineering, IEEE Transactions on, 28(7), 638 – 653. Dustdar, S. and Schreiner, W. (2005). A survey on web services composition. Int. J. Web Grid Serv., 1, 1–30. DuVander, A. (2011). Api growth doubles in 2010, social and mobile are trends. Elmore, A. J., Das, S., Agrawal, D., and El Abbadi, A. (2011). Zephyr: live migration in shared nothing databases for elastic cloud platforms. In Proceedings of the 2011 international conference on Management of data, SIGMOD ’11, pages 301–312, New York, NY, USA. ACM. Fehling, C., Leymann, F., and Mietzner, R. (2010). A framework for optimized distribution of tenants in cloud applications. In Proceedings of the 2010 IEEE 3rd International Conference on Cloud Computing, CLOUD ’10, pages 252–259, Washington, DC, USA. IEEE Computer Society. Foping, F., Dokas, I., Feehan, J., and Imran, S. (2009). A new hybrid schema-sharing technique for multitenant applications. In Digital Information Management, 2009. ICDIM 2009. Fourth International Conference on, pages 1 –6. Gartner (2011). Gartner says worldwide software as a service revenue is forecast to grow 21 percent in 2011. Disponível em: <http://www.gartner.com/it/page.jsp?id=1739214>. Acesso em: 10 dez. 2011. Geelan, J. (2009). Twenty-one experts define cloud computing. Cloud Computing Journal, 2009, 1–5. Godse, M. and Mulik, S. (2009). An approach for selecting software-as-a-service (saas) product. In Cloud Computing, 2009. CLOUD ’09. IEEE International Conference on, pages 155 –158.

96

REFERÊNCIAS BIBLIOGRÁFICAS

Graham, T. C. N. and Roy, B. (2008). Methods for evaluating software architecture: A survey. Technical Report 2008-545, School of Computing — Queen’s University, Kingston, Ontario, Canada. Grund, M., Schapranow, M., Krueger, J., Schaffner, J., and Bog, A. (2008). Shared table access pattern analysis for multi-tenant applications. In Advanced Management of Information for Globalized Enterprises, 2008. AMIGE 2008. IEEE Symposium on, pages 1 –5. Guo, C. J., Sun, W., Huang, Y., Wang, Z. H., and Gao, B. (2007). A framework for native multi-tenancy application development and management. In E-Commerce Technology and the 4th IEEE International Conference on Enterprise Computing, E-Commerce, and E-Services, 2007. CEC/EEE 2007. The 9th IEEE International Conference on, pages 551 –558. Haaff, B. d. (2009). Cloud computing – the jargon is back! Cloud Computing Journal. Harris, I. S. and Ahmed, Z. (2011). An open multi-tenant architecture to leverage smes. European Journal of Scientific Research, 65(4), 601–610. Hasselmeyer, P. and d’Heureuse, N. (2010). Towards holistic multi-tenant monitoring for virtual data centers. In Network Operations and Management Symposium Workshops (NOMS Wksps), 2010 IEEE/IFIP, pages 350 –356. Höfer, C. and Karagiannis, G. (2011). Cloud computing services: taxonomy and comparison. Journal of Internet Services and Applications, 2, 81–94. 10.1007/s13174-0110027-x. Huang, J. (2011a). Amazon s3’s amazing growth. Cloud Computing Journal. Disponível em: <http://cloudcomputing.sys-con.com/node/1699373>. Acesso em: 10 dez. 2011. Huang, J. (2011b). Gartner says worldwide software as a service revenue is forecast to grow 21 percent in 2011. Disponível em: <http://www.gartner.com/it/page.jsp?id=1739214>. Acesso em: 10 dez. 2011. Hui, M., Jiang, D., Li, G., and Zhou, Y. (2009). Supporting database applications as a service. In Data Engineering, 2009. ICDE ’09. IEEE 25th International Conference on, pages 832 –843. Jacob, B. (2005). Introduction to Grid Computing. IBM redbooks. IBM, International Technical Support Organization.

97

REFERÊNCIAS BIBLIOGRÁFICAS

Jacobs, D. and Aulbach, S. (2007). Ruminations on multi-tenant databases. BTW Proceedings, 103(Btw), 514–521. Jansen, S., Houben, G.-J., and Brinkkemper, S. (2010). Customization realization in multi-tenant web applications: case studies from the library sector. In Proceedings of the 10th international conference on Web engineering, ICWE’10, pages 445–459, Berlin, Heidelberg. Springer-Verlag. Jasti, A., Shah, P., Nagaraj, R., and Pendse, R. (2010). Security in multi-tenancy cloud. In Security Technology (ICCST), 2010 IEEE International Carnahan Conference on, pages 35 –41. Jegadeesan, H. and Balasubramaniam, S. (2009). A method to support variability of enterprise services on the cloud. In Cloud Computing, 2009. CLOUD ’09. IEEE International Conference on, pages 117 –124. Jing, J. and Zhang, J. (2010). Research on open saas software architecture based on soa. In Computational Intelligence and Design (ISCID), 2010 International Symposium on, volume 2, pages 144 –147. Judd, C. M., Nusairat, J. F., Shingler, J., Moodie, M., Ottinger, J., Pepper, J., Pohlmann, F., Renow-clarke, B., Shakeshaft, D., Wade, M., and et al. (2008). Beginning groovy and grails from novice to professional. Specialist, page 440. Kaegi, S. R. and Deugo, D. (2008). Modular java web applications. In Proceedings of the 2008 ACM symposium on Applied computing, SAC ’08, pages 688–693, New York, NY, USA. ACM. Kitchenham, B. and Charters, S. (2007). Guidelines for performing Systematic Literature Reviews in Software Engineering. Technical Report EBSE 2007-001, Keele University and Durham University Joint Report. Kitchenham, B., Mendes, E., and Travassos, G. (2007). Cross versus within-company cost estimation studies: A systematic review. Software Engineering, IEEE Transactions on, 33(5), 316 –329. Kleinrock, L. (2003). An internet vision: the invisible global infrastructure. Ad Hoc Networks, 1(1), 3–11.

98

REFERÊNCIAS BIBLIOGRÁFICAS

Kong, L., Li, Q., and Zheng, X. (2010). A novel model supporting customization sharing in saas applications. In Multimedia Information Networking and Security (MINES), 2010 International Conference on, pages 225 –229. Koziolek, H. (2010). Towards an architectural style for multi-tenant software applications. Proc Software Engineering 2010 SE10 Fachtagung des GIFachbereichs Softwaretechnik, To appear, 81–92. Koziolek, H. (2011). The sposad architectural style for multi-tenant software applications. In Software Architecture (WICSA), 2011 9th Working IEEE/IFIP Conference on, pages 320 –327. Kwok, T. and Mohindra, A. (2008). Resource calculations with constraints, and placement of tenants and instances for multi-tenant saas applications. In Proceedings of the 6th International Conference on Service-Oriented Computing, ICSOC ’08, pages 633–648, Berlin, Heidelberg. Springer-Verlag. Kwok, T., Nguyen, T., and Lam, L. (2008a). A software as a service with multi-tenancy support for an electronic contract management application. In Services Computing, 2008. SCC ’08. IEEE International Conference on, volume 2, pages 179 –186. Kwok, T., Nguyen, T., and Lam, L. (2008b). A software as a service with multi-tenancy support for an electronic contract management application. In Services Computing, 2008. SCC ’08. IEEE International Conference on, volume 2, pages 179 –186. Lattanze, A. (2005). The architecture centric development method. Technical report (Carnegie Mellon University. School of Computer Science. Institute for Software Research International). Carnegie Mellon University, School of Computer Science, [Institute for Software Research International]. Lehnen, S. (2011). Understanding the basic building blocks of sales force crm. Disponível em: <http://www.salesforce.com/customer-resources/learning-center/details/bestpractices/understanding-the-basic-building.jsp>. Acesso em: 28 dez. 2011. Li, H., Shi, Y., and Li, Q. (2009). A multi-granularity customization relationship model for saas. In Proceedings of the 2009 International Conference on Web Information Systems and Mining, WISM ’09, pages 611–615, Washington, DC, USA. IEEE Computer Society.

99

REFERÊNCIAS BIBLIOGRÁFICAS

Li, X. H., Liu, T. C., Li, Y., and Chen, Y. (2008). Spin: Service performance isolation infrastructure in multi-tenancy environment. In Proceedings of the 6th International Conference on Service-Oriented Computing, ICSOC ’08, pages 649–663, Berlin, Heidelberg. Springer-Verlag. Li, X.-Y., Shi, Y., Guo, Y., and Ma, W. (2010). Multi-tenancy based access control in cloud. In Computational Intelligence and Software Engineering (CiSE), 2010 International Conference on, pages 1 –4. Lin, H., Sun, K., Zhao, S., and Han, Y. (2009a). Feedback-control-based performance regulation for multi-tenant applications. In Parallel and Distributed Systems (ICPADS), 2009 15th International Conference on, pages 134 –141. Lin, H., Sun, K., Zhao, S., and Han, Y. (2009b). Feedback-control-based performance regulation for multi-tenant applications. In Parallel and Distributed Systems (ICPADS), 2009 15th International Conference on, pages 134 –141. Liu, H., Jin, H., Liao, X., Hu, L., and Yu, C. (2009). Live migration of virtual machine based on full system trace and replay. In Proceedings of the 18th ACM international symposium on High performance distributed computing, HPDC ’09, pages 101–110, New York, NY, USA. ACM. Lizhen, C., Haiyang, W., Lin, J., and Pu, H. (2010). Customization modeling based on metagraph for multi-tenant applications. In Pervasive Computing and Applications (ICPCA), 2010 5th International Conference on, pages 255 –260. Lóscio, B. F., Oliveira, H. R. d., and Pontes, J. C. d. S. (2011). Nosql no desenvolvimento de aplicações web colaborativas. VIII Simpósio Brasileiro de Sistemas Colaborativos. Meier, J., Homer, A., Taylor, J., Bansode, P., Wall, L., Boucher, R., and Bogawat, A. (2008). How to - design using agile architecture. Disponível em: <http://apparch.codeplex.com/wikipage?title=How%20To%20%20Design%20Using%20Agile%20Architecture>. Acesso em: 10 dez. 2011. Mell, P. and Grance, T. (2009). The nist definition of cloud computing. National Institute of Standards and Technology, 53(6), 50. Mietzner, R., Leymann, F., and Papazoglou, M. (2008). Defining composite configurable saas application packages using sca, variability descriptors and multi-tenancy patterns.

100

REFERÊNCIAS BIBLIOGRÁFICAS

In Internet and Web Applications and Services, 2008. ICIW ’08. Third International Conference on, pages 156 –161. Mietzner, R., Unger, T., Titze, R., and Leymann, F. (2009a). Combining different multi-tenancy patterns in service-oriented applications. In Proceedings of the 2009 IEEE International Enterprise Distributed Object Computing Conference (edoc 2009), EDOC ’09, pages 131–140, Washington, DC, USA. IEEE Computer Society. Mietzner, R., Metzger, A., Leymann, F., and Pohl, K. (2009b). Variability modeling to support customization and deployment of multi-tenant-aware software as a service applications. In Proceedings of the 2009 ICSE Workshop on Principles of Engineering Service Oriented Systems, PESOS ’09, pages 18–25, Washington, DC, USA. IEEE Computer Society. Milojicic, D. (2008). Cloud computing: Interview with russ daniels and franco travostino. Internet Computing, IEEE, 12(5), 7 –9. Neil, T. (2010). 12 standard screen patterns. Disponível em: <http://designingwebinterfaces.com/designing-web-interfaces-12-screen-patterns>. Acesso em: 10 dez. 2011. Neto, J. and Passos, E. (2009). Jexodus: uma ferramenta para migração de dados independente de sgbd. In ERCEMAPI Graduação (). Nie, Z. (2010). Credibility evaluation of saas tenants. In Advanced Computer Theory and Engineering (ICACTE), 2010 3rd International Conference on, volume 4, pages V4–488 –V4–491. Nitu (2009). Configurability in saas (software as a service) applications. In Proceedings of the 2nd India software engineering conference, ISEC ’09, pages 19–26, New York, NY, USA. ACM. Oh, B.-T., Won, H.-S., and Hur, S.-J. (2011). Multi-tenant supporting online application service system based on metadata model. In Advanced Communication Technology (ICACT), 2011 13th International Conference on, pages 1173 –1176. Pervez, Z., Khattak, A., Lee, S., and Lee, Y.-K. (2010a). Dual validation framework for multi-tenant saas architecture. In Future Information Technology (FutureTech), 2010 5th International Conference on, pages 1 –5.

101

REFERÊNCIAS BIBLIOGRÁFICAS

Pervez, Z., Lee, S., and Lee, Y.-K. (2010b). Multi-tenant, secure, load disseminated saas architecture. In Advanced Communication Technology (ICACT), 2010 The 12th International Conference on, volume 1, pages 214 –219. Petersen, K., Feldt, R., Mujtaba, S., and Mattsson, M. (2008). Systematic Mapping Studies in Software engineering. In EASE ’08: Proceedings of the 12th International Conference on Evaluation and Assessment in Software Engineering. Richardson, C. (2009). Orm in dynamic languages. Commun. ACM, 52(4), 48–55. Ries, E. (2011). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing Group. Rimal, B. P. and El-Refaey, M. A. (2010). A framework of scientific workflow management systems for multi-tenant cloud orchestration environment. In Proceedings of the 2010 19th IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises, WETICE ’10, pages 88–93, Washington, DC, USA. IEEE Computer Society. Schaffner, J., Eckart, B., Jacobs, D., Schwarz, C., Plattner, H., and Zeier, A. (2011). Predicting in-memory database performance for automating cluster management tasks. In Data Engineering (ICDE), 2011 IEEE 27th International Conference on, pages 1264 –1275. Schiller, O., Schiller, B., Brodt, A., and Mitschang, B. (2011). Native support of multitenancy in rdbms for software as a service. In Proceedings of the 14th International Conference on Extending Database Technology, EDBT/ICDT ’11, pages 117–128, New York, NY, USA. ACM. Shwartz, L., Diao, Y., and Grabarnik, G. (2009). Multi-tenant solution for it service management: A quantitative study of benefits. In Integrated Network Management, 2009. IM ’09. IFIP/IEEE International Symposium on, pages 721 –731. Siddhisena, B., Warusawithana, L., and Mendis, M. (2011). Next generation multi-tenant virtualization cloud computing platform. In Advanced Communication Technology (ICACT), 2011 13th International Conference on, pages 405 –410. Smith, D. M. (2011). Hype cycle for cloud computing , 2011. Cycle, 38(July), 1 – 42. Sommerville, I. (2003). Engenharia de Software. Pearson, 6 edition.

102

REFERÊNCIAS BIBLIOGRÁFICAS

Sousa, F. R. C., Moreira, L. O., De Macêdo, J. A. F., and Machado, J. C. (2010). Gerenciamento de dados em nuvem. SWIB 2010, page 40. Stoev, A. and Dimov, A. (2008). Architectural framework for dynamic web-applications. In Proceedings of the 9th International Conference on Computer Systems and Technologies and Workshop for PhD Students in Computing, CompSysTech ’08, pages 15:II.10–15:1, New York, NY, USA. ACM. Sun, W., Zhang, X., Guo, C. J., Sun, P., and Su, H. (2008). Software as a service: Configuration and customization perspectives. In Congress on Services Part II, 2008. SERVICES-2. IEEE, pages 18 –25. Takahashi, H., Mori, K., and Ahmad, H. (2010). Efficient i/o intensive multi tenant saas system using l4 level cache. In Service Oriented System Engineering (SOSE), 2010 Fifth IEEE International Symposium on, pages 222 –228. Tang, K., Jiang, Z. B., Sun, W., Zhang, X., and Dong, W. S. (2010). Research on tenant placement based on business relations. In e-Business Engineering (ICEBE), 2010 IEEE 7th International Conference on, pages 479 –483. Team, M. P. P. (2009). Microsoft Application Architecture Guide (Patterns & Practices). Microsoft Press. Tomhave, B. L. (2005). Alphabet soup: Making sense of models, frameworks, and methodologies. Travassos, G. H. and Biolchini, J. (2007). Revisões sistemáticas aplicadas a engenharia de software. Empirical Software Engineering, page 27. Tsai, C.-H., Ruan, Y., Sahu, S., Shaikh, A., and Shin, K. (2007). Virtualization-based techniques for enabling multi-tenant management tools. In A. Clemm, L. Granville, and R. Stadler, editors, Managing Virtualization of Networks and Services, volume 4785 of Lecture Notes in Computer Science, pages 171–182. Springer Berlin / Heidelberg. Tsai, W.-T. and Shao, Q. (2011). Role-based access-control using reference ontology in clouds. In Autonomous Decentralized Systems (ISADS), 2011 10th International Symposium on, pages 121 –128. Tsai, W.-T., Shao, Q., and Li, W. (2010a). Oic: Ontology-based intelligent customization framework for saas. In Service-Oriented Computing and Applications (SOCA), 2010 IEEE International Conference on, pages 1 –8.

103

REFERÊNCIAS BIBLIOGRÁFICAS

Tsai, W.-T., Shao, Q., and Elston, J. (2010b). Prioritizing service requests on cloud with multi-tenancy. In e-Business Engineering (ICEBE), 2010 IEEE 7th International Conference on, pages 117 –124. Tsai, W.-T., Shao, Q., Huang, Y., and Bai, X. (2010c). Towards a scalable and robust multitenancy saas. In Proceedings of the Second Asia-Pacific Symposium on Internetware, Internetware ’10, pages 8:1–8:15, New York, NY, USA. ACM. Tsai, W.-T., Sun, X., Shao, Q., and Qi, G. (2010d). Two-tier multi-tenancy scaling and load balancing. In e-Business Engineering (ICEBE), 2010 IEEE 7th International Conference on, pages 484 –489. Vaquero, L. M., Rodero-Merino, L., Caceres, J., and Lindner, M. (2008). A break in the clouds: towards a cloud definition. SIGCOMM Comput. Commun. Rev., 39, 50–55. Vu, Q. H., Lupu, M., and Ooi, B. C. (2010). Peer-to-peer computing. Media. Wang, M., Bandara, K. Y., and Pahl, C. (2010). Process as a service distributed multitenant policy-based process runtime governance. In Proceedings of the 2010 IEEE International Conference on Services Computing, SCC ’10, pages 578–585, Washington, DC, USA. IEEE Computer Society. Wang, Z. H., Guo, C. J., Gao, B., Sun, W., Zhang, Z., and An, W. H. (2008a). A study and performance evaluation of the multi-tenant data tier design patterns for service oriented computing. In Proceedings of the 2008 IEEE International Conference on e-Business Engineering, pages 94–101, Washington, DC, USA. IEEE Computer Society. Wang, Z. H., Guo, C. J., Gao, B., Sun, W., Zhang, Z., and An, W. H. (2008b). A study and performance evaluation of the multi-tenant data tier design patterns for service oriented computing. In e-Business Engineering, 2008. ICEBE ’08. IEEE International Conference on, pages 94 –101. Weiliang, C., Shidong, Z., and Lanju, K. (2010). A multiple sparse tables approach for multi-tenant data storage in saas. In Industrial and Information Systems (IIS), 2010 2nd International Conference on, volume 1, pages 413 –416. Weissman, C. D. and Bobrowski, S. (2009). The design of the force.com multitenant internet application development platform. In Proceedings of the 35th SIGMOD international conference on Management of data, SIGMOD ’09, pages 889–896, New York, NY, USA. ACM.

104

REFERÊNCIAS BIBLIOGRÁFICAS

Wieringa, R., Maiden, N., Mead, N., and Rolland, C. (2005). Requirements engineering paper classification and evaluation criteria: a proposal and a discussion. Requir. Eng., 11, 102–107. Xiong, P., Chi, Y., Zhu, S., Moon, H. J., Pu, C., and Hacigumus, H. (2011). Intelligent management of virtualized resources for database systems in cloud environment. In Data Engineering (ICDE), 2011 IEEE 27th International Conference on, pages 87 –98. Xue, W., Qingzhong, L., and Lanju, K. (2011). Multiple sparse tables based on pivot table for multi-tenant data storage in saas. In Information and Automation (ICIA), 2011 IEEE International Conference on, pages 634 –637. Yeo, C. S., Buyya, R., Pourreza, H., Eskicioglu, R., Graham, P., Sommers, F., and Computing, G. (2006). Cluster computing: High-performance, high-availability, and high-throughput processing on a network of computers. Communication, pages 1–24. Yuanyuan, D., Hong, N., Bingfei, W., and Lei, L. (2009). Scaling the data in multi-tenant business support system. In Knowledge Engineering and Software Engineering, 2009. KESE ’09. Pacific-Asia Conference on, pages 43 –46. Zhang, K., Zhang, X., Sun, W., Liang, H., Huang, Y., Zeng, L., and Liu, X. (2007). A policy-driven approach for software-as-services customization. In E-Commerce Technology and the 4th IEEE International Conference on Enterprise Computing, E-Commerce, and E-Services, 2007. CEC/EEE 2007. The 9th IEEE International Conference on, pages 123 –130. Zhang, K., Shi, Y., Li, Q., and Bian, J. (2009). Data privacy preserving mechanism based on tenant customization for saas. In Multimedia Information Networking and Security, 2009. MINES ’09. International Conference on, volume 1, pages 599 –603. Zhang, X., Shen, B., Tang, X., and Chen, W. (2010a). From isolated tenancy hosted application to multi-tenancy: Toward a systematic migration method for web application. In Software Engineering and Service Sciences (ICSESS), 2010 IEEE International Conference on, pages 209 –212. Zhang, Y., Wang, Z., Gao, B., Guo, C., Sun, W., and Li, X. (2010b). An effective heuristic for on-line tenant placement problem in saas. In Web Services (ICWS), 2010 IEEE International Conference on, pages 425 –432.

105

REFERÊNCIAS BIBLIOGRÁFICAS

Zheng, J., Li, X., Zhao, X., Zhang, X., and Hu, S. (2010). The research and application of a saas-based teaching resources management platform. In Computer Science and Education (ICCSE), 2010 5th International Conference on, pages 765 –770.

106

Appendices

107

A
Estudos Primários
ID EP01 EP02 TÍTULO A Framework for Native Multi-Tenancy Application Development and Management A Policy-Driven Approach for Software-as-Services Customization ANO 2007 2007 EP03 EP04 Ruminations on Multi-Tenant Databases Virtualization-based techniques for enabling multi-tenant management tools A Software as a Service with Multi-tenancy Support for an Electronic Contract Management Application A Study and Performance Evaluation of the Multi-Tenant Data Tier Design Patterns for Service Oriented Computing Defining Composite Configurable SaaS Application Packages Using SCA, Variability Descriptors and Multi-tenancy Patterns Multi-tenant databases for software as a service: Schema-mapping techniques The design of the force.com multitenant internet application development platform 2007 2007 AUTORES Chang Jie Guo, Wei Sun, Ying Huang, Zhi Hu Wang, Bo Gao, Kuo Zhang, Xin Zhang, Wei Sun, Haiqi Liang, Ying Huang, Liangzhao Zeng, Xuanzhe Liu, Dean Jacobs, Stefan Aulbach Chang-Hao Tsai,Yaoping Ruan,Sambit Sahu,Anees Shaikh,Kang G. Shin Kwok, T., Thao Nguyen, Linh Lam, Zhi Hu Wang, Chang Jie Guo, Bo Gao, Wei Sun, Zhen Zhang, Wen Hao An, Ralph Mietzner,Frank Leymann,Mike P. Papazoglou

EP05

2008

EP06

2008

EP07

2008

EP08

2008

EP09

2009

Stefan Aulbach,Torsten Grust,Dean Jacobs,Alfons Kemper,Jan Rittinger Craig D. Weissman, Steve Bobrowski

Tabela A.1 Estudos Primários

108

ID EP10 EP11 EP12

EP13

EP14 EP15

EP16 EP17

EP18 EP19 EP20

TÍTULO Software as a service: Configuration and customization perspectives Combining Different Multi-tenancy Patterns in Service-Oriented Applications Multi-tenant solution for IT service management: A quantitative study of benefits Resource calculations with constraints, and placement of tenants and instances for multi-tenant SaaS applications A multi-granularity customization relationship model for SaaS SPIN: Service performance isolation infrastructure in multi-tenancy environment A Method to Support Variability of Enterprise Services on the Cloud A multi-tenant oriented performance monitoring, detecting and scheduling architecture based on SLA Data privacy preserving mechanism based on tenant customization for SaaS Feedback-control-based performance regulation for multi-tenant applications Shared table access pattern analysis for multi-tenant applications A Transparent Approach of Enabling SaaS Multi-tenancy in the Cloud Multi-Tenancy Based Access Control in Cloud Physical Layer Network Isolation in Multi-tenant Clouds The multi-tenant data architecture design for the collaboration service system of textile apparel supply chain Variability modeling to support customization and deployment of multi-tenant-aware Software as a Service applications

ANO 2008 2009 2009

AUTORES Wei Sun, Xin Zhang, Chang Jie Guo, Pei Sun, Hui Su, Ralph Mietzner, Tobias Unger, Robert Titze, Larisa Shwartz,Yixin Diao,Genady Ya. Grabarnik Thomas Kwok, Ajay Mohindra Hongbo Li,Yuliang Shi, Qingzhong Li Xin Hui Li,Tian Cheng Liu,Ying Li,Ying Chen, Harshavardhan Jegadeesan, Sundar Balasubramaniam Xu Cheng , Yuliang Shi , Qingzhong Li , Kun Zhang,Yuliang Shi,Qingzhong Li,Ji Bian , Hailue Lin,Kai Sun,Shuan Zhao,Yanbo Han Grund, M., Schapranow, M., Krueger, J., Schaffner, J., Bog, A., Hong Cai, Ning Wang, Ming Jun Zhou Xiao-Yong Li, Yong Shi, Yu Guo, Wei Ma, Jack Brassil Xiao Feng Wang, Ping Jun Dong Ralph Mietzner, Andreas Metzger, Frank Leymann, Klaus Pohl

2008

2009 2008

2009 2009

2009 2009 2009

EP21 EP22 EP23 EP24

2010 2010 2010 2009

EP25

2009

Tabela A.2 Estudos Primários(Continuação)

109

ID EP26 EP27

EP28 EP29 EP30

EP31 EP32

TÍTULO A framework for optimized distribution of tenants in cloud applications A Framework of Scientific Workflow Management Systems for Multi-tenant Cloud Orchestration Environment A multiple sparse tables approach for multi-tenant data storage in SaaS A multi-tenant oriented customizable compensation mechanism for workflows A Novel Model Supporting Customization Sharing in SaaS Applications Scaling the Data in Multi-tenant Business Support System Research on Tenant Placement Based on Business Relations Research on open SaaS software architecture based on SOA Configurability in SaaS for an electronic contract management application Credibility evaluation of SaaS tenants Customization modeling based on metagraph for multi-tenant applications Customization realization in multi-tenant web applications: Case studies from the library sector Dual Validation Framework for Multi-Tenant SaaS Architecture Towards an Architectural Style for Multi-tenant Software Applications Efficient I/O Intensive Multi Tenant SaaS System Using L4 Level Cache From isolated tenancy hosted application to multi-tenancy: Toward a systematic migration method for web application Highly available component sharing in large-scale multi-tenant cloud systems Towards holistic multi-tenant monitoring for virtual data centers

ANO 2010 2010

AUTORES Christoph Fehling, Frank Leymann, Ralph Mietzner Bhaskar Prasad Rimal, Mohamed A. El-Refaey Chen Weiliang, Zhang Shidong, Kong Lanju Xiao Ding, Ruobing Luo, Ming Hui Lanju Kong, Qingzhong Li, Xuxu Zheng Dong Yuanyuan, Ni Hong, Wang Bingfei, Liu Lei, Kai Tang, Zhong Bo Jiang, Wei Sun, Xin Zhang, Wei Shan Dong Junjie Jing , Jian Zhang Pradeep Kumar Arya, V. Venkatesakumar, S. Palaniswami Zhiqiang Nie Cui Lizhen, Wang Haiyang, Jinjiao Lin, Haitao Pu, Slinger Jansen, Geert-Jan Houben, Sjaak Brinkkemper Pervez, Z., Khattak, A.M., Sungyoung Lee, Young-Koo Lee Heiko Koziolek Hironao Takahashi, Kinji Mori, Hafiz Farooq Ahmad Xuesong Zhang, Beijun Shen, Xucheng Tang, Wei Chen, Juan Du, Xiaohui Gu, Douglas S. Reeves, Hasselmeyer, P., d’Heureuse, N.

2010 2010 2010

2009 2010

EP33 EP34

2010 2010

EP35 EP36 EP37

2010 2010 2010

EP38

2010

EP39 EP40 EP41

2010 2010 2010

EP42 EP43

2010 2010

Tabela A.3 Estudos Primários(Continuação)

110

ID EP44

TÍTULO Enabling multi-tenancy: An industrial experience report Multi-tenant SaaS applications: Maintenance dream or nightmare? Multi-tenant SOA Middleware for Cloud Computing

ANO 2010

EP45 EP46

2010 2010

EP47 EP48 EP49 EP50

EP51

EP52 EP53

EP54 EP55

OIC: Ontology-based intelligent customization framework for SaaS Multi-tenant, secure, load disseminated SaaS architecture Multiple sparse tables based on pivot table for multi-tenant data storage in SaaS Process as a Service Distributed Multi-tenant Policy-Based Process Runtime Governance Predicting in-memory database performance for automating cluster management tasks Predicting system performance for multi-tenant database workloads Routing-as-a-Service (RaaS): A framework for tenant-directed route control in data center Security in multi-tenancy cloud The research and application of a SaaS-based teaching resources management platform Two-Tier Multi-tenancy Scaling and Load Balancing A comparison of flexible schemas for Software as a Service Toward a multi-tenancy authorization system for cloud services Engineering multi-tenant Software-as-a-Service systems

2010 2010 2011 2010

AUTORES Cor-Paul Bezemer, Andy Zaidman, Bart Platzbeecker, Toine Hurkmans, Aad ’t Hart Cor-Paul Bezemer, Andy Zaidman Azeez, A., Perera, S., Gamage, D., Linton, R., Siriwardana, P., Leelaratne, D., Weerawarana, S., Fremantle, P., Wei-Tek Tsai, Qihong Shao, Wu Li, Zeeshan Pervez, Sungyoung Lee, Young-Koo Lee Wang Xue, Li Qingzhong, Kong Lanju MingXue Wang, Kosala Yapa Bandara, Claus Pahl Schaffner, J., Eckart, B., Jacobs, D., Schwarz, C., Plattner, H., Zeier, A. Mumtaz Ahmad, Ivan T. Bowman Chao-Chih Chen , Lihua Yuan , Greenberg, A. , Chen-Nee Chuah , Mohapatra, P. Jasti, A. , Shah, P. , Nagaraj, R. , Pendse, R. Jiecai Zheng, Xueqing Li, Xinxiao Zhao, Xiaomin Zhang, Sheng Hu Wei-Tek Tsai, Xin Sun, Qihong Shao, Guanqiu Qi Stefan Aulbach,Dean Jacobs,Alfons Kemper, Michael Seibold, Calero, J.M.A., Edwards, N., Kirschnick, J., Wilcock, L., Wray, M. Bikram Sengupta, Abhik Roychoudhury

2011

2011 2011

2010 2010

EP56 EP57

2010 2009

EP58

2010

EP59

2011

Tabela A.4 Estudos Primários(Continuação)

111

ID EP60 EP61 EP62

TÍTULO Extensibility and Data Sharing in evolving multi-tenant databases Supporting Database Applications as a Service An effective heuristic for on-line tenant placement problem in SaaS Multi-tenant supporting online application service system based on metadata model Native support of multi-tenancy in RDBMS for Software as a Service Next generation multi-tenant virtualization cloud computing platform Prioritizing Service Requests on Cloud with Multi-tenancy Research on data layer structure of multi-tenant e-commerce system Role-Based Access-Control Using Reference Ontology in Clouds Intelligent management of virtualized resources for database systems in cloud environment The SPOSAD Architectural Style for Multi-tenant Software Applications Zephyr: Live migration in shared nothing databases for elastic cloud platforms

ANO 2011 2009 2010

EP63 EP64

2011 2011

EP65

2011

EP66 EP67 EP68 EP69

2010 2010 2011 2011

AUTORES Aulbach, S., Seibold, M., Jacobs, D., Kemper, A. Mei Hui, Dawei Jiang, Guoliang Li, Yuan Zhou Yi Zhang, Zhihu Wang, Bo Gao, Changjie Guo, Wei Sun, Xiaoping Li Byeong-Thaek Oh, Hee-Sun Won, Sung-Jin Hur Oliver Schiller, Benjamin Schiller, Andreas Brodt, Bernhard Mitschang Siddhisena, B., Warusawithana, L., Mendis, M. Wei-Tek Tsai, Qihong Shao, Jay Elston Jia Du, Hao-yu Wen, Zhao-jun Yang Wei-Tek Tsai, Qihong Shao Pengcheng Xiong, Yun Chi, Shenghuo Zhu, Hyun Jin Moon, Calton Pu, Hacigumus, H. Koziolek, H. Aaron J. Elmore, Sudipto Das, Divyakant Agrawal, Amr El Abbadi

EP70 EP71

2011 2011

Tabela A.5 Estudos Primários(Continuação)

112