Desenvolvimento de Aplicações Multi-Tenancy: Um Estudo de Mapeamento Sistemático

Desenvolvimento de aplicaes multi-tenancy: um estudo de mapeamento sistemtico
Por
Josino Rodrigues Neto

Dissertao de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE, Junho/2012
Universidade Federal de Pernambuco Centro de Informtica Ps-graduao em Cincia da Computao
Josino Rodrigues Neto
Desenvolvimento de aplicaes multi-tenancy: um estudo de mapeamento sistemtico
Trabalho apresentado ao Programa de Ps-graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para obteno do grau de Mestre em Cincia da Computao.
Orientador: Silvio Romero de Lemos Meira Co-Orientador: Vinicius Cardoso Garcia
RECIFE, Junho/2012
Eu dedico essa dissertao primeiramente minha famlia, aos meus amigos e aos meus professores que me deram todo o suporte necessrio para chegar at aqui. Em especial agradeo a Deus por ter colocado todas essas pessoas no meu caminho.
Agradecimentos
Agradeo a Deus, por ter me dado uma famlia linda. minha esposa , Ksia(in memorian) por ter me incentivado a continuar mesmo quando eu pensava que nada iria dar certo. minha lha Sara, que aprendeu a usar o skype sozinha pra conseguir conversar comigo enquanto trabalhava na minha dissertao. minha me, Dona Susana que me apoiou no momento mais difcil 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 tambm foi muito til nas revises da minha dissertao, deu contribuies de preciso cirrgia 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). Agradeo tambm 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 implementao prtica da minha dissertao. Gostaria de agradecer aos meus amigos da FJB(Fora Jovem Brasil), aos que so piauienses(Jezlia Resende, ngela Nbia, Eullio Pereira e Amanda Patricia) e aos que so pernambucanos(aqui no vou citar nomes porque so muitos). Todo essas pessoas foram um suporte pra mim nas horas vagas. Era com eles que eu realizava as atividades lantrpicas que me zeram crescer como ser humano. Dentre esses gostaria de agradecer especialmente Dra Jezlia Resende por ter revisado alguns trechos da minha dissertao e ajudado corrigir alguns detalhes do portugus. Por m, mas no mais importante queria agradecer aos meus mestres e orientadores Silvio Meira, Vincius Garcia e Paulo Anselmo por terem me ajudado a organizar minhas idias em uma dissertao e transforma-las em cincia de verdade. Muito Obrigado a todos.
iv
Eu vou marcar a minha gerao Vou conquistar a minha posio Se eu acreditar no sonho Vou realizar Chegou a minha vez No vou ter medo de tentar Eu sei, quem sabe faz a hora hora de lutar. SONOROS (Fora Jovem Brasil)
Resumo
De forma crescente, Software como servio (SaaS) est se tornando uma forma dominante de entrega de software aos usurios. Da perspectiva dos provedores de servio, os benefcios de SaaS mostram-se atravs da economia de escala, pela oferta de software a um grande nmero de consumidores atravs de uma instncia compartilhada de software. Uma forma de implementar SaaS atravs da adoo de multi-tenancy, uma abordagem para a implementao de SaaS que divide a instncia de uma aplicao em vrias aplicaes virtuais chamadas tenants. Para prover software desse tipo necessrio levar em considerao vrios aspectos como segurana, alocao de recursos, customizao, escalabilidade, armazenamento de dados, reuso, etc. Esse trabalho visa, apartir de um mapeamento sistemtico, identicar o estado da arte de multi-tenancy, propostas de implementao e principais lacunas existentes nessa rea atravs da anlise dos principais trabalhos publicados sobre o assunto. Ao nal desse trabalho apresentado aplicao desses conceitos na indstria.
vi
Abstract
Increasingly, Software as a Service (SaaS) is becoming a dominant form of software delivery to users. From perspective of service providers, the benets 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
Sumrio
Lista de Figuras Lista de Tabelas Lista de Siglas 1 Introduo 1.1 Motivao . . . . . . . . . . 1.2 Objetivos . . . . . . . . . . 1.2.1 Objetivos Gerais . . 1.2.2 Objetivos Especcos 1.3 Metodologia . . . . . . . . . 1.4 Contribuies cientcas . . 1.5 Estrutura da dissertao . . .
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
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Fundamentao Terica 2.1 Cloud Computing . . . . . . . 2.2 SaaS - Software como Servio 2.3 Multi-tenancy . . . . . . . . . 2.4 Consideraes Finais . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Mapeamento Sistemtico 3.1 Diretivas de pesquisa . . . . . . . . . . . . . 3.1.1 Pesquisa exploratria . . . . . . . . . 3.1.2 Denio de Questes de Pesquisa . . 3.2 Seleo dos dados . . . . . . . . . . . . . . . 3.2.1 Conduo da pesquisa . . . . . . . . 3.2.2 Triagem dos Trabalhos . . . . . . . . 3.3 Classicao . . . . . . . . . . . . . . . . . 3.3.1 Esquema de Classicao . . . . . . 3.3.2 Classicao dos trabalhos relevantes 3.4 Principais Descobertas . . . . . . . . . . . . 3.4.1 Alocao de Recursos . . . . . . . . 3.4.2 Banco de Dados . . . . . . . . . . . 3.4.3 Customizao . . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
viii
3.5
3.6 3.7 3.8 4
3.4.4 Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 Migrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.7 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.8 Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.9 SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapeamento das evidncias . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Q1 - Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Q2 - Quais as propostas existentes para implementao da arquitetura multi-tenancy? . . . . . . . . . . . . . . . . . . . . . . . Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mtodos ou Tcnicas . . . . . . . . . . . . . . . . . . . . . . . Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Propostas de Arquitetura . . . . . . . . . . . . . . . . . . . . . 3.5.3 Q3 - Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicao multi-tenancy . . . . . . . . . . . . . 3.5.4 Q4 - Quando a adoo da arquitetura multi-tenancy vivel? . . Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ameaas a validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consideraes 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
Aplicao na Indstria 4.1 Problema . . . . . . . . . . . . . . . . . . . . . 4.2 Metodologia . . . . . . . . . . . . . . . . . . . . 4.3 Denio de Arquitetura . . . . . . . . . . . . . 4.3.1 Identicao dos objetivos da Arquitetura 4.3.2 Viso geral da aplicao . . . . . . . . . 4.3.3 Pontos Crticos e Solues . . . . . . . . 4.3.4 Proposta de soluo de arquitetura . . . . Autenticao . . . . . . . . . . . . . . . Congurao . . . . . . . . . . . . . . . Banco de dados (Database) . . . . . . . . 4.3.5 Tecnologias . . . . . . . . . . . . . . . . 4.3.6 Prototipagem . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
ix
4.4 4.5 5
Migrao do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . .
85 89 90 91 91 92 107 108
Concluso e Trabalhos Futuros 5.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Referncias Bibliogrcas Appendices A Estudos Primrios
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 vem 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 negcio. Pagamento de assinatura mensal o modelo de pagamento mais popular (Adaptada de: (Cusumano, 2008)) . Hype Cycle para Cloud Computing((Smith, 2011)) . . . . . . . . . . . Resumo da Metodologia(Elaborao prpria) . . . . . . . . . . . . . . Modelos de servio de Cloud Computing . . . . . . . . . . . . . . . . . Amazon S3s Growth(Huang, 2011a) . . . . . . . . . . . . . . . . . . . Nveis de Maturidade SaaS(Chong and Carraro, 2006) . . . . . . . . . Processo de Mapeamento Sistemtico - Adaptado de (Petersen et al., 2008) Percentual de estudos retornados de acordo com a estratgia de busca . Percentual de estudos retornados pelas buscas automticas . . . . . . . Quantidade de artigos agrupados por Contexto e Ano . . . . . . . . . . Quantidade de artigos agrupados por Contexto e Contribuio . . . . . Quantidade de artigos agrupados por Contexto e Tipo de Pesquisa . . . Quantidade de artigos agrupados por Questo e Tipo de Pesquisa . . . . Tcnicas de mapeamento de esquema(Fonte: (Aulbach et al., 2008)) . . Metamodelo para SPL(Fonte: (Cavalcanti et al., 2011)) . . . . . . . . . Metodologia utilizada para desenvolvimento de aplicao na indstria(Fonte: Elaborao prpria) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de Caso de Uso da Aplicao Alexandria(Fonte: Elaborao prpria) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura de Referncia adotada(Fonte: (Bezemer et al., 2010)) . . . Arquitetura do Grails Framework(Fonte: (Judd et al., 2008)) . . . . . . Arquitetura da Aplicao(Fonte: Elaborao prpria) . . . . . . . . . .
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
Denies de Cloud Computing(Vaquero et al., 2008) . . . . . . . . . . Questionamentos e termos . . . . . . . . . . . . . . . . Strings Search . . . . . . . . . . . . . . . . . . . . . . . Resultado da aplicao dos critrios de excluso . . . . . Faceta Contexto . . . . . . . . . . . . . . . . . . . . . . Faceta Tipos de pesquisa (Fonte: (Wieringa et al., 2005)) Faceta Contribuio (Fonte: (Wieringa et al., 2005)) . . . Artigos associados por Questo de pesquisa . . . . . . . Artigos agrupados por contexto . . . . . . . . . . . . . . Artigos agrupados por contribuio . . . . . . . . . . . . Artigos agrupados por Tipo de Pesquisa . . . . . . . . . Mtodos e tcnicas para implementar multi-tenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12 26 28 30 32 33 34 34 35 35 38 54
Estilos arquiteturais escolhidos e suas inuncias em nossa arquitetura . 76 Atributos de qualidade desejveis na arquitetura . . . . . . . . . . . . . 79 Resultado da aplicao dos critrios de excluso(Fonte: Elaborao prpria) 86 Estudos Primrios . . . . . . . . Estudos Primrios(Continuao) Estudos Primrios(Continuao) Estudos Primrios(Continuao) Estudos Primrios(Continuao) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Informao UML Unied Modeling Language WSDL Web Service Denition Language XML Extensible Markup Language
xiv
1
Introduo
Os consumidores mudaram com a evoluo dos meios de comunicao, transporte e distribuio de produtos e servios. medida que os custos de distribuio baixam, diversos produtos que no tinham condies 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 fenmeno 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 vivel com o advento da internet, j que a inexistncia de limitao do espao fsico, para exibio 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 anlise 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 ttulos) representava em torno de um quarto da receita. Analisando o cenrio temos a impresso de que so produtos que no vale a pena vender (Anderson, 2006). Isso verdade para uma loja fsica tradicional puramente por uma questo de espao fsico, o que no acontece em uma loja virtual. Foi no varejo da internet que descobriu-se o poder da Cauda Longa e da prateleira de tamanho innito. Segundo Chong et al. (Chong and Carraro, 2006), fornecedores de solues complexas de software de linha de negcios 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 negcios tende a ser personalizado para atender as necessidades de clientes individuais, potencialmente incluindo instalao no local e visitas de servio por parte das equipes de manuteno do fornecedor, muitas vezes exigindo
1.1. MOTIVAO
hardware de servidor dedicado e uma equipe de suporte para gerenci-lo. O custo de fornecer esse tipo de ateno dedicada inuencia no preo mnimo desse produto. Esse software, portanto, tende a ser vendido para empresas maiores que podem pagar por esse nvel de ateno.
Figura 1.1 Cauda Longa(Adaptada de: (Chong and Carraro, 2006))
Para cada grande empresa que compra uma soluo de linha de negcios existem dezenas de empresas menores e de tamanho mdio que poderiam beneciar-se dessa soluo, mas no possuem os recursos para adquiri-la. Assim, no modelo SaaS (Choudhary, 2007) de fornecimento de software, precisa-se desenvolver solues e infraestruturas de baixo custo, com alto aproveitamento de recursos durante o uso do aplicativo por um grande nmero de usurios, para assim atingir um pblico ainda no suportado, devido os custos proibitivos de entrada(Sousa et al., 2010).
1.1
Motivao
Na Cauda Longa, um nmero muito grande de usurios que poder adotar a soluo de software que permite a cada cliente pagar um valor muito baixo pelo uso do software, e ainda assim, o provedor de servio poder ter um lucro considervel ao nal do ms. No mercado de software pode-se citar duas abordagens para venda de software, uma seria vender uma soluo para um pequeno grupo de clientes que esto dispostos a pagar um alto valor por esse produto ou servio. Outra vender(ou prover um servio) a um valor muito baixo, desde que se possa atender a um nmero grande de clientes. Esse cenrio demonstrado na Figura 1.1. Quanto mais um provedor de servios consegue
1.1. MOTIVAO
baixar o custo de um produto para os clientes, um nmero maior de clientes poder ser alcanado. Um ponto importante no modelo de SaaS o apoio para vrios clientes, fazendo possvel que compartilhem a mesma aplicao e infraestrutura, reduzindo os custos operacionais. Isso signica que cada cliente pode interagir com o aplicativo como se ele fosse o nico usurio da aplicao. Em especial, um cliente no pode acessar ou visualizar os dados de outro, embora compartilhem a mesma estrutura fsica (Sousa et al., 2010) e paga por esse servio de acordo com o uso. Nos ltimos anos, temos sofrido uma grande mudana no mercado de software onde empresas tm mudado seu foco do desenvolvimento de produtos para o desenvolvimento de servios(Cusumano, 2008). Um estudo realizado com 500 empresas de desenvolvimento de software, onde analisou-se o percentual de vendas de produtos e servios dessas empresas, mostrou o crescimento do percentual de vendas de servios em relao produtos. O resultado desse estudo apresentado na Figura 1.2.
Figura 1.2 Empresas de software globais vem 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 informaes obtidas apartir 108 empresas de desenvolvimento de software corporativo, identicou que a cobrana de taxa mensal a forma de cobrana mais utilizada nessas empresas, superando em mais de 2 vezes a forma de cobrana atravs de pagamento de Taxa Inicial de Licena de Software, que considerada a forma de cobrana tradicional(Figura 1.3)(Cusumano, 2008). Segundo estudos do Instituto Gartner(Gartner, 2011), em julho de 2011, a previso de receita mundial de SaaS era de U$ 12,1 bilhes em 2011, um aumento de 20,7% em relao receita de 2010 quando a receita atingiu U$ 10 bilhes. A previso, de acordo com a pesquisa que SaaS apresente um crescimento saudvel at 2015, quando a receita
1.1. MOTIVAO
Figura 1.3 Empresas de software corporativo baseado em web tem adotado uma varidade de modelos de negcio. Pagamento de assinatura mensal o modelo de pagamento mais popular (Adaptada de: (Cusumano, 2008))
mundial atingiria U$ 21,3 bilhes. No mercado de SaaS, aplicaes de CRM(Customer Relationship Management) arrematam a maior fatia, com faturamento de U$ 3,2 bilhes em 2010 e podendo chegar ao nal de 2011 com U$ 3,8 bilhes. 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 cenrio nebuloso para os desenvolvedores(Milojicic, 2008). O nmero crescente de tecnologias, somado expeculaes sobre seu uso, pode dicultar a tomada de deciso por parte de desenvolvedores e gerentes de projeto. O Gartner lana anualmente o "Gartners Hype Cycle", que caracteriza como o exagero sobre uma tecnologia desenvolve-se "de um entusiasmo atravs de um perodo de desiluso a um eventual entendimento da relevncia da tecnologia e seu papel em um mercado ou domnio"(Smith, 2011). Segundo Smith et al.(Smith, 2011), multi-tenancy(Tsai et al., 2010c), uma das formas de se implementar aplicaes SaaS est no segundo estgio do "hype cycle"denido pelo Gartner, como mostra a Figura 1.4. O "hype cycle" dividido em cinco fases que so descritas a seguir: Technology Trigger - a primeira fase do hype cycle, quando a nova tecnologia gera grande interesse da mdia e da sociedade. Peak of Inated Expectations - Nesta fase apresentado um entusiasmo exagerado, cercado de expectativas no realistas. Ocorrem aplicaes de sucesso da
1.1. MOTIVAO
Figura 1.4 Hype Cycle para Cloud Computing((Smith, 2011))
tecnologia e decepes. a fase atual de Cloud Computing, segundo o relatrio do Instituto Gartner(Smith, 2011). Trough of Disillusionment - O interesse na tecnologia comea a diminuir devido a experimentos e implementaes falharem na entrega. Ela ocorre devido a nova tecnologia no conseguir atender toda a expectativa criada. Slope of Enlightenment - Nessa fase, mais casos de como as empresas podem se beneciar da tecnologia comeam a se cristalizar e a tecnologia comea a ser mais amplamente compreendida. Produtos comeam a surgir de fornecedores de tecnologia, mas empresas conservadoras continuam cautelosas. Plateau of Productivity - Uma adoo da tecnologia com maior maturidade comea a acontecer. Os crittios de viabilidade da tecnologia so melhor denidos. A aplicabilidade da tecnologia no mercado em geral e sua relevncia podem ser claramente vistos. De acordo com o grco da Figura 1.4, um entusiasmo exagerado, cercado de expectativas no realistas permeia a rea de multi-tenancy. Diante disso , identicou-se a necessidade de elaborar uma sintetizao do conhecimento gerado sobre multi-tenancy, bem como o levantamento de evidncias que possam auxiliar desenvolvedores a tomar
1.2. OBJETIVOS
decises durante o desenvolvimento de uma aplicao SaaS multi-tenancy. A realizao de uma sintetizao que siga o rigor da metodologia cientca, aumenta a credibilidade deste trabalho e elimina interferncias causadas por entusiasmos proporcionados pela mdia. Tornando esse trabalho um artefato importante durante a tomada de decises em um projeto real.
1.2
Objetivos
Esta seo lista o objetivo geral e os objetivos especcos desta dissertao.
1.2.1
Objetivos Gerais
Mapear a rea de multi-tenancy identicando pontos que possam auxiliar desenvolvedores e engenheiros de software durante o criao de aplicaes web que adotem multi-tenancy como estilo arquitetural para a implementao de SaaS.
1.2.2
Objetivos Especcos
O objetivo geral pode ser decomposto nos seguintes objetivos especcos: Apresentar uma viso geral da arquitetura multi-tenancy, explicando os principais conceitos teis para entendimento deste trabalho; Denir o status de maturidade atual de multi-tenancy; Identicar as evidncias sobre os fatores que inuenciam na adoo e desenvolvimento de SaaS multi-tenancy; Analisar e classicar de maneira sistemtica os estudos primrios e os artefatos encontrados que podem auxiliar no desenvolvimento de uma aplicao multitenancy Por m, combinar os resultados evidenciados no estudo secundrio com uma aplicao prtica dos conceitos de multi-tenancy na indstria.
1.3
Metodologia
Para alcanar os objetivos esperados, as atividades foram divididas em 3 fases:
1.3. METODOLOGIA
Fase 1 - Apartir dos objetivos da pesquisa, foi realizado uma reviso bibliogrca inicial para a familiarizao com os termos e principais conceitos relacionados ao tema multi-tenancy. Essa fase foi baseada na leitura de artigos, publicaes em sites e revistas relacionados ao tema. Como resultado dessa fase obtivemos os principais conceitos e termos relacionados a multi-tenancy que serviro de entrada para a prxima fase. Fase 2 - Conhecidos os conceitos e termos, possvel planejar e executar um mapeamento sistemtico que servir para entender o contexto no qual o tema pesquisado est inserido. Nessa fase so executadas atividades como denio de questes de pesquisa, escolha de engines de busca, leitura e categorizao 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 possveis problemas em aberto. Fase 3 - baseado no resultado do mapeamento sistemtico realizado na fase anterior, denida uma abordagem de implementao, que adotada durante o desenvolvimento de um projeto na indstria. A Figura 1.5 descreve de forma resumida a metodologia utilizada nessa dissertao.
Figura 1.5 Resumo da Metodologia(Elaborao prpria)
1.4. CONTRIBUIES CIENTFICAS
1.4
Contribuies cientcas
Com este trabalho, espera-se fornecer as seguintes contribuies cientcas: Fornecer um mapeamento da rea de multi-tenancy Consolidar de forma sistemtica o conhecimento sobre multi-tenancy, bem como o conhecimento sobre ferramentas e tcnicas que auxiliem no desenvolvimento dessas aplicaes Fornecer um catlogo de frameworks e propostas para a implementao da arquitetura multi-tenancy
1.5
Estrutura da dissertao
O restante deste trabalho est organizado em 5 captulos, conforme a diviso que se segue. O Captulo 2 introduz os conceitos bsicos necessrios ao entendimento do trabalho. Em seguida, o Captulo 3 apresenta a metodologia que foi utilizada para conduzir esta dissertao. O Captulo 4 apresenta os resultados encontrados aps a execuo do estudo de mapeamento. No Captulo 5 apresentado um estudo de caso para validar o conceito de multi-tenancy. Por m, o Captulo 6 apresenta as concluses da dissertao, ressaltando as contribuies, as limitaes e os trabalhos futuros a serem realizados.
2
Fundamentao Terica
Em 1969, Leonard Keinrock, um dos cientistas chefe da ARPANET, precursora da internet, disse: "A partir de agora, redes de computadores esto ainda na sua infncia, mas a medida que crescem e tornam-se sosticadas, ns iremos provavelmente ver a disseminao do computador utilitrio que, como telefones e energia eltrica, iro servir casas e escritrios por todo pas"(Kleinrock, 2003). Essa viso de computao utilitria baseada no modelo de fornecimento de servios antecipa a transformao massiva de toda a indstria de computao nos ltimos anos, em que os servios de computao estaro prontamente disponveis sob demanda, como os outros servios utilitrios disponveis atualmente. Similarmente, os usurios(consumidores) precisam pagar os provedores somente quando eles acessam os servios de computao. Alm disso, consumidores no precisam mais realizar altos investimentos ou enfrentar a diculdade de construir e manter complexas infra-estruturas de TI. Os prossionais de desenvolvimento de software esto enfrentando inmeros novos desaos para criar software para milhes de consumidores usarem como servio ao invs de executarem em seus computadores pessoais. E ao longo dos anos, o surgimento de avanos tecnolgicos como processadores multicore e ambientes de computao em rede como Cluster Computing(Yeo et al., 2006), Grid Computing(Jacob, 2005), computao P2P(Vu et al., 2010) e o mais recente Cloud Computing(Mell and Grance, 2009), tornam esse objetivo cada vez mais factvel. Os servios de computao citados anteriormente precisam ser altamente conveis, escalveis e dinmicos para suportar acesso ubquo e fornecer a possibilidade de composio de outros servios(Dustdar and Schreiner, 2005). Alm disso, consumidores devem ter a capacidade de determinar o nvel de servio requerido atravs de parmetros de QoS(Quality of Service) e SLA(Service Level Agreement)(Berberova and Bontchev, 2009).
2.1. CLOUD COMPUTING
Cloud Computing foi o ltimo desses paradigmas a emergir e promete entregar servios conveis atravs da nova gerao de datacenters que so construdos utilizando tecnologias de virtualizao de processamento e armazenamento. Consumidores estaro habilitados a acessar aplicaes e dados da "cloud"em qualquer lugar do mundo e sob demanda, como o caso do Gmail1 , Google Docs2 , Ofce Web Apps3 , Dropbox4 , dentre outros. Em outras palavras, a cloud parace ser um ponto de acesso nico para todas as necessidades de computao dos consumidores.
2.1
Cloud Computing
Atualmente no existe uma denio ocial do que seja Cloud Computing. O objetivo nessa seo reunir vrias denies de Cloud Computing disponveis e chegar a uma denio que seja um denominador comum. A Tabela 2.1 mostra as denies 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 so os principais elementos de uma cloud. Isso provido pelo aumento no monitoramento e automao do gerenciamento de recursos, em um ambiente dinmico. Outros autores discordam que esse um requisito para uma infraestrutura ser considerada cloud(Haaff, 2009). Alm disso, Cloud Computing tem sido denido por alguns autores como hardware e software virtualizados, somados a aplicao de tecnologias de monitoramento e provisionamento(Geelan, 2009). Ainda existem alguns outros especialistas que no 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 terceirizao de processamento e armazenamento de dados. Levando em considerao as caractersticas apresentadas na Tabela 2.1, Luiz M. Vaquero e outros autores (Vaquero et al., 2008) tentaram chegar a uma denio de Cloud Computing. Obviamente o conceito de cloud ainda est em mudana e essas denies mostram como o conceito de cloud concebido por alguns especialistas. Cloud um grande pool de recursos virtualizados(hardware, plataformas de desenvolvimento e servios) facilmente utilizveis e acessveis. Esses recursos podem ser dinmicamente recongurados para se ajustar a carga varivel(escala), permitindo tambm a otimiza1 http://www.gmail.com 2 http://docs.google.com 3 http://ofce.microsoft.com/web-apps 4 http://www.dropbox.com
10

Autor M. Klems P. Gaw R. Buyya Denio ... possvel escalar sua infraestrutura sob demanda em minutos ou em segundos, ao invs de dias ou semanas, evitando desse modo sub-utilizao e sobrecarga dos seus recursos in-house. Uso da internet para permitir pessoas acessarem servios tecnologicamente disponveis. Esses servios precisam ser massivamente escalveis. Uma Cloud um tipo de sistema paralelo e distribudo que consiste de uma coleo de computadores virtualizados e interconectados que so dinmicamente provisionados e apresentados como um ou mais recursos computacionais unicados, baseados em SLA estabelecida atravs de negociao entre o provedor de servio e o consumidor. Cloud Computing uma das vrias buzz words existentes que tentam abranger uma variedade de aspectos como deployment, balanceamento de carga, provisionamento, modelo de negcios e arquitetura. Esse o prximo passo em software. A explicao mais simples de Cloud Computing descrev-la como Software centrado na internet. Uma ampla gama de servios baseados na web que objetivam permitir ao usurio obter uma variedade de funcionalidades que so pagas por uso e que anteriormente requeria uma grande quantidade de investimentos em hardware/software e contratao de bons prossionais. Cloud Computing a realizao de idias antigas de computao utilitria sem a complexidade tcnica ou preocupao com deployments complicados. ... o prximo termo para campanhas publicitrias ... criado fora do modelo de software que a virtualizao habilitou. ... o que possvel quando voc alcana a infra-estrutura(de aplicao e fsica) para o tamanho da web de uma forma sob-demanda. Existem somente trs tipos de servio que so baseados em cloud: SaaS, PaaS e Plataformas de Cloud Computing. O autor no garante que escalar massivamente seja um requisito para caber em qualquer categoria. Simplicando, Cloud Computing uma mudana de paradigma de infraestrutura que habilita a asceno de software como servio ... uma gama de servios baseados em web que tem como objetivo permitir a usurios obter uma ampla variedade de funcionalidades baseada no modelo de pagamento por uso e que anteriormente requeria uma grande quantidade de investimentos e contratao de prossionais especialistas. Cloud foca em fazer a capacidade de processamento e armazenamento da camada de hardware consumvel sob demanda. Esse um primeiro passo importante, mas para as companhias aproveitarem o poder da cloud, infra-estruturas completas de aplicaes precisam ser facilmente conguradas, distribudas, dinmicamente escaladas e gerenciadas nesses ambientes de hardware virtualizado. Na realidade o acesso a recursos e servios necessrios para executar funcionalidades com necessidade de mudana dinmica. a virtualizao de recursos auto-mantidos e auto-gerenciveis. Clouds so um vasto pool de recursos com alocao sob demanda... virtualizados ... e cobrados por utilizao. Cloud Computing ... uma verso de grid computing amigvel para o usurio. 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

Autor M. Sheedan A. Ricadela I. Wladawsky Berger B. Martin R. Bragg Denio a pirmide de cloud computing ajuda a diferenciar as vrias ofertas de cloud... no topo: SaaS, no meio: PaaS, na base: IaaS. Projetos de Cloud Computing so mais poderosos e tolerantes a falhas que sistemas de grid desenvolvidos nos ltimos anos. A principal coisa que queremos virtualizar e ocultar do usurio a complexidade ... todos aqueles softwares que sero virtualizados ou ocultos de ns e o tratamento de sistemas e/ou prossionais que esto em qualquer outro lugar, fora da Cloud. Cloud computing inclui qualquer servio 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 aplicao web... a cloud mais desenvolvida e convel. Muitos acham barato migrar agora para uma cloud na web ao invs de investir em seus proprios servidores ... isso um desktop por pessoa sem um computador. Cloud toda sobre: SaaS ... computao utilitria, PaaS ... integrao na internet ... plataformas comerciais. Cloud Computing, onde residem no somente nossos dados mas tambm alguns de nossos softwares. Ns acessamos qualquer coisa no somente atravs de nossos PCs, mas tambm de outros dispositivos, como smartphones, PDAs, ... O megacomputador habilitado pela virtualizao e software como servio ... Essa a utilizao do poder de computao pela massiva utilizao de data centers
G. Gruman and E. Knorr P. McFedries
Tabela 2.1 Denies de Cloud Computing(Vaquero et al., 2008)
o na utilizao de recursos. Esse pool de recursos normalmente explorado pelo modelo pay-by-use(pague por uso), no qual garantias so oferecidas pelo provedor de infraestrutura por meio de SLA(Service Level Agreement). Olhando para o mnimo denominador comum nas denies, os autores no chegaram a uma denio de uma funcionalidade nica proposta em todas as denies. O conjunto de funcionalidades que mais se aproxima da denio mnima poderia ser escalabilidade, modelo de pagamento por uso e virtualizao. Nesse trabalho usaremos a denio proposta pelo National Institute of Standards and Technology(NIST), que dene Cloud Computing como um modelo que permite, de forma conveniente, o acesso a um pool de recursos computacionais compartilhados(rede, servidores, armazenamento, aplicaes e servios) que podem ser rapidamente provisionados e liberados com o mnimo de esforo de gerenciamento ou interao do provedor de servio. Ainda segundo o National Institute of Standards and Technology (NIST), Cloud Computing composta por cinco caractersticas essenciais(Mell and Grance, 2009): Alocao de recursos sob demanda: O usurio pode adquirir unilateralmente
12
recursos computacionais, como tempo de processamento no servidor ou armazenamento, atravs da rede na medida em que necessite e sem precisar de interao humana com os provedores de cada servio. Amplo acesso a rede: recursos esto disponveis atravs da rede e podem ser acessados por meio de mecanismos que funcionem em plataformas heterogneas (por exemplo, telefones celulares, laptops e PDA). Pooling de recursos: os recursos do provedor de computao so agrupados para atender vrios consumidores atravs de um modelo multi-tenancy, com diferentes recursos fsicos e virtuais atribudos dinamicamente e novamente de acordo com a demanda do consumidor. H um senso de independncia local em que o cliente geralmente no tem nenhum controle ou conhecimento sobre a localizao exata dos recursos disponibilizados, mas pode ser capaz de especicar o local em um nvel maior de abstrao (por exemplo, pas, estado ou data center). Exemplos de recursos incluem o armazenamento, processamento, memria, largura de banda de rede e mquinas virtuais. Elasticidade rpida: recursos podem ser adquiridos de forma rpida e elstica, em alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da demanda, e podem tambm ser liberados, na retrao dessa demanda. Para os usurios, os recursos disponveis para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento. Servio medido: sistemas em nuvem automaticamente controlam e otimizam a utilizao dos recursos, alavancando a capacidade de medio em algum nvel de abstrao adequado para o tipo de servio (por exemplo, armazenamento, processamento, largura de banda, e contas de usurios ativos). Uso de recursos pode ser monitorado, controlado e relatado a existncia de transparncia para o fornecedor e o consumidor do servio utilizado. Ainda segundo o NIST(Mell and Grance, 2009), Cloud Computing dividido em trs modelos de servio(Figura 2.1): Software como Servio (SaaS): A capacidade fornecida ao consumidor a de usar as aplicaes do fornecedor em uma infraestrutura da nuvem. As aplicaes so acessveis de vrios dispositivos cliente atravs de uma interface thin client, como por exemplo um browser web. O consumidor no administra ou controla a
13
infraestrutura bsica, incluindo rede, servidores, sistemas operacionais, armazenamento, ou mesmo capacidades individuais da aplicao. Mesmo assim ainda possvel denir algumas conguraes especcas para o usurio na aplicao. Plataforma como Servio (PaaS): A capacidade fornecida ao consumidor a de realizar deploy de uma aplicao em uma infraestrutura pr-denida ou adquirir aplicaes criadas usando linguagens de programao e as ferramentas suportadas pelo provedor de PaaS. O consumidor no administra ou controla a infraestrutura bsica como rede, servidores, sistemas operacionais, ou armazenamento, mas tem controle sobre os aplicativos utilizados e eventualmente hospedagem de aplicativos e conguraes de ambiente. Infraestrutura como Servio (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 arbitrrios, que podem incluir sistemas operacionais e aplicativos. O consumidor no 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, rewall).
Figura 2.1 Modelos de servio de Cloud Computing
Nesse trabalho teremos como foco principal os tpicos 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 servio.
14
2.2. SAAS - SOFTWARE COMO SERVIO
2.2
SaaS - Software como Servio
Nos ltimos anos muitas empresas tem sado do modelo de entrega de software empacotado para o modelo de fornecimento de software na web(Huang, 2011b). Essas aplicaes entregues atravs da web vo desde emails a calendrios, sistemas colaborativos, publicaes online, processadores de texto simples, aplicaes para negcios e aplicaes para uso pessoal. Salesforce.com(Lehnen, 2011), por exemplo, criou um aplicativo para CRM(Customer Relationship Management) e o congurou no como um software empacotado, mas como software rodando sobre servidores acessvel atravs do browser. Quando fez isso, criou a propria plataforma in-house para entregar o software como servio para seus consumidores. Logo em seguida Salesforce.com criou o AppExchange, uma plataforma de integrao 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 aplicaes de terceiros, alm de produzirem servios online. Amazon vem se tornando bastante atraente porque possui uma rica infraestrutura para suportar operaes de varejo online e tem oferecido vrios servios para usurios de cloud como: data storage, processamento, la de mensagens, billing e etc. O artigo "Amazon S3s Amazing Growth"(Huang, 2011a) menciona o crescimento vertiginoso no uso do servio S3 da Amazon(Amazon, 2011) nos ltimos anos, possvel ver o grco de crescimento desse servio na gura 2.2. Cloud Computing e SaaS tambm parecem ser ecientes tanto para usurios quanto para fornecedores de software. Vrios consumidores podem usar a mesma instalao do software e consequentemente isso melhora as taxas de utilizao de hardware e rede. Por exemplo, Amazon6 e Google7 tem enormes datacenters que eles no utilizam completamente o tempo todo. Eles podem executar seus prprios produtos e enquanto hospedam aplicaes de outras empresas. Hosts como Amazon, Google e Salesforce geralmente garantem a qualidade de servio para todos os seus consumidores de cloud
5 https://appengine.google.com 6 http://aws.amazon.com 7 http://www.google.com
15
Figura 2.2 Amazon S3s Growth(Huang, 2011a)
atravs de SLAs (Service Level Agreeements) detalhadas. Segundo Harris et al.(Harris and Ahmed, 2011) existem trs tipos diferentes de aplicaes SaaS: Multi-instance: essas aplicaes executam em ambientes onde o servidor web compartilhado. Nessa abordagem uma cpia da aplicao inicialmente congurada para cada cliente, e ento cada cpia implantada como um contexto no mesmo servidor web. Single-instance: as aplicaes provem servios para um nico cliente e executam em um servidor exclusivo. Nesse caso cada servidor web possui uma nica instncia da aplicao. Essa pode considerada a abordagem com maior desperdcio de recursos, dado que um servidor pode executar com apenas 10% de sua capacidade. Multi-tenancy: prov uma nica aplicao compartilhada por vrios clientes. Nessa abordagem vrias aplicaes "virtuais"so criadas na mesma instncia. Implementar o conceito de SaaS nem sempre to simples como parece. Chong (Chong and Carraro, 2006) prope 4 nveis de maturidade para aplicaes que utilizam o modelo de SaaS: Nvel 1 - Ad-Hoc/Personalizado: O primeiro nvel de maturidade semelhante ao modelo de entrega de software do provedor de servios de aplicativos (ASP Application Service Provider) tradicional, que data da dcada de 1990. Nesse nvel, cada cliente tem a sua prpria verso personalizada do aplicativo hospedado e
16
Figura 2.3 Nveis de Maturidade SaaS(Chong and Carraro, 2006)
executa a sua prpria instncia do aplicativo nos servidores do provedor. Pensando em arquitetura, software nesse nvel de maturidade muito semelhante aos softwares corporativos vendidos tradicionalmente, em que diferentes usurios de uma organizao conectam a uma instncia nica em execuo no servidor, mas essa instncia totalmente independente de quaisquer outras instncias ou processos que o host esteja executando para os seus outros clientes. Nvel 2 - Congurvel: No segundo nvel de maturidade, o fornecedor hospeda uma instncia separada do aplicativo para cada inquilino. Enquanto no primeiro nvel cada instncia personalizada individualmente para o inquilino, neste nvel todas as instncias utilizam a mesma implementao de cdigo e o fornecedor atende as necessidades dos clientes fornecendo opes de congurao detalhadas que permitem ao cliente alterar a aparncia e o comportamento do aplicativo para os seus usurios. Apesar de serem idnticas a nvel do cdigo, cada instncia permanece totalmente isolada de todas as demais. Nvel 3 - Congurvel e eciente para vrios tenants: No terceiro nvel de maturidade, o fornecedor executa uma nica instncia que serve a todos os clientes. Metadados congurveis so usados para fornecer uma experincia de usurio e um conjunto de recursos exclusivos para cada instncia. Polticas de autorizao e de segurana garantem que os dados de cada cliente sejam mantidos separados dos dados de outros clientes e que, da perspectiva do usurio nal, no exista qualquer
17
2.3. MULTI-TENANCY
indicao de que a instncia do aplicativo esteja sendo compartilhada entre vrios tenants. Nvel 4 - Escalonvel, congurvel e eciente para vrios tenants: No quarto e ltimo nvel de maturidade, o fornecedor hospeda vrios clientes em um ambiente com balanceamento de carga. Os dados de cada cliente so mantidos separados e com metadados congurveis fornecendo uma experincia do usurio e um conjunto de recursos exclusivos para cada cliente. Um sistema de SaaS escalonvel para um nmero de clientes arbitrariamente grande, uma vez que a quantidade de servidores e instncias no lado do fornecedor pode ser aumentada ou diminuda conforme necessrio para corresponder demanda sem a necessidade de remodelar a arquitetura aplicativo, alm disso as alteraes ou correes podem ser transmitidas para milhares de tenants to facilmente quanto para um nico tenant. Normalmente se esperaria que o quarto nvel fosse a meta denitiva para qualquer aplicativo de SaaS, mas no sempre assim. necessrio vericar as necessidades operacionais, arquiteturais e de negcio relacionadas aplicao. Uma abordagem singletenant faz sentido nanceiramente? O seu aplicativo pode ser feito para executar em uma nica instncia lgica? Voc pode garantir os seus contratos de nvel de servio (SLAs) sem isolamento das aplicaes? Essas so questes que devem ser respondidas quando se pretende adotar o modelo SaaS. O objeto de estudo principal desse trabalho sero aplicaes SaaS do tipo multitenancy.
2.3
Multi-tenancy
Multi-tenancy uma abordagem organizacional para aplicaes SaaS. Bezemer e Zaidman (Bezemer and Zaidman, 2010) denem multi-tenancy como aplicaes que permitem a otimizao no uso dos recursos de hardware, atravs do compartilhamento de instncias da aplicao e da instncia do banco de dados, enquanto permite congurar a aplicao para atender s necessidades do cliente como se estivesse executando em um ambiente dedicado. Tenant uma entidade organizacional que aluga uma aplicao multi-tenancy. Normalmente, um tenant agrupa um nmero de usurios que so os stakeholders da organizao. A denio anterior foca no que ns consideramos aspectos em aplicaes multitenancy:
18
2.4. CONSIDERAES FINAIS
Possibilidade de compartilhamento de recursos de hardware, permitindo a reduo de custos (Wang et al., 2008a). Alto grau de congurabilidade, permitindo que cada consumidor customize sua prpria interface e seu workow na aplicao (Nitu, 2009; Jansen et al., 2010). Uma abordagem arquitetural na qual os tenants fazem uso de uma nica aplicao e banco de dados (Kwok et al., 2008a). possvel que algumas pessoas confundam multi-tenancy com o conceito de multiusurio. Multi-tenancy no multi-usurio. Em uma aplicao multi-usurio ns assumimos que os usurios esto usando a mesma aplicao com opes de acesso limitadas e que essa instncia da aplicao utilizada por apenas um nico cliente. Nesse caso podemos ter vrios usurios com o perl "gerente", com o perl "vendedor", ou com qualquer perl de usurio necessrio para o funcionamento da aplicao. Em uma aplicao multi-tenancy ns assumimos cada instncia tenants tem um algo grau de congurao, dependendo da denio dessas conguraes, dois tenants pode possuir aparncia e workows diferentes. Um argumento adicional para essa distino 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 virtualizao e de Cloud Computing, multi-instance a forma fcil de criar aplicaes parecidas com multi-tenancy. necessrio apenas criar uma imagem de maquina virtual com a aplicao pr-congurada e, logo em seguida criar instncias apartir dessa imagem. A abordagem multi-instance uma melhor abordagem quando o nmero de clientes for pequeno (Guo et al., 2007). Uma abordagem mais profunda sobre o tema multi-tenancy ser apresentado no Captulo 3, onde ser realizado um mapeamento da rea.
2.4
Consideraes Finais
Este captulo apresentou os conceitos bsicos usados na dissertao. Inicialmente, noes sobre Cloud Computing, SaaS, PaaS e IaaS. O conceito de multi-tenancy foi introduzido, explicitando vises e caractersticas que sero importantes para o entendimento dos captulos posteriores. Por m, foram apresentadas alguns requisitos de aplicaes que adotam o modelo de SaaS e multi-tenancy. Embora o que foi apresentado at aqui seja de grande relevncia, preciso bem mais do que isso para adotar uma tecnologia na indstria. necessrio entender as vantagens e
19
desvantages, o estado da arte na academia, bem como o nvel de maturidade existente na aplicao dessa tecnologia. Para responder essas questes o captulo seguinte apresenta um mapeamento sistemtico sobre o campo de multi-tenancy com o objetivo de sintetizar os conhecimentos existentes na rea.
20
3
Mapeamento Sistemtico
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 mdia em torno de SaaS e multi-tenancy propiciam o surgimento de especulaes e informaes imprecisas sobre esse campo (Milojicic, 2008). Alm disso a ausncia de trabalhos que sintetizem o conhecimento gerado de forma a eliminar informaes imprecisas ou baseadas exclusivamente em opinio pessoal torna ainda mais difcil denir o status atual da rea, como foi possvel observar no grco da Figura 1.4. Para realizar uma boa pesquisa e gerar conhecimento til e consistente era necessrio utilizar alguma metodologia na realizao da pesquisa. Metodologia cientca necessria, entre outras razes, para tornar os resultados da pesquisa mais conveis e possveis de serem reproduzidos, de forma independente, por outros pesquisadores. Partindo do princpio de que deveramos utilizar alguma metodologia para realizar nossas pesquisa escolheu-se a tcnica de Mapeamento Sistemtico (Petersen et al., 2008) . Um Mapeamento Sistemtico prov a estruturao de uma rea de pesquisa, no tocante a relatrios de pesquisa e resultados que vem sendo publicados. Muitas vezes esses resultados so resumidos de forma visual atravs de tabelas e grcos. A aplicao dessa tcnica prov uma melhor viso panormica da rea pesquisada (Kitchenham and Charters, 2007). A escolha de sua utilizao nesse trabalho ocorreu principalmente por utilizar um processo e protocolo de execuo bem denidos, o que permite que essa atividade possa ser repetida por outros pesquisadores em momentos futuros. Mapeamento Sistemtico uma metodologia que frequentemente utilizada em pesquisas mdicas, mas que vem gradualmente ganhando fora na comunidade de engenharia de software. De acordo com Budgen (Budgen et al., 2008), dentre os principais motivos para se executar uma mapeamento sistemtico podemos citar:
21
ajuda na realizao de uma avaliao imparcial do maior nmero de estudos possvel, identicando lacunas existentes atualmente na rea de pesquisa e contribuio para a comunidade cientca com uma sntese convel dos dados; prov um procedimento sistemtico para identicar a natureza e a extenso de dados do estudo que so teis para responder s questes de pesquisa; auxilia no mapeamento da pesquisa que foi realizada; ajuda a planejar uma nova pesquisa,evitando duplicao desnecessria de esforo e erros. ajuda a identicar lacunas e grupos de estudos primrios, para identicar tpicos e reas para realizar revises sistemticas mais completas. Para conduzir o mapeamento sistemtico realizado nesse trabalho sero seguidos os passos descritos na Figura 3.1. Cada etapa do processo brevemente descrita a seguir: 1. Pesquisa exploratria: nessa etapa foram realizados pesquisas em mquinas de busca e bibliotecas digitais disponveis na web, com o objetivo de entender melhor a rea a ser pesquisada. 2. Denio de questes de pesquisa: passado a fase de entendimento do problema, so denidas questes de pesquisa, que iro guiar o mapeamento sistemtico. 3. Conduo da pesquisa: nessa fase so selecionadas as bibliotecas digitais onde as questes de pesquisa sero executadas e outros locais onde sero pesquisados trabalhos sobre o tema. 4. Triagem de papers: comum que as pesquisas retornem alguns trabalho com pouca relevncia para responder s questes 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 classicao dos trabalhos encontrados. Primeiro realizado a leitura dos abstracts e palavras chave em busca de conceitos que reitam a contribuio do trabalho. Ao nal dessa leitura um conjunto de palavras chave de diferentes trabalhos so combinadas para desenvolver um entendimento de alto nvel sobre a natureza e a contribuio do trabalho. Isso auxilia na denio de um conjunto de categorias que ajudam no entendimento da populao de estudos encontrados.
22
3.1. DIRETIVAS DE PESQUISA
6. Extrao de dados e processo de mapeamento: aps a denio do esquema de classicao, os trabalhos so agrupados e as informaes necessrias para responder s questes de pesquisa so extradas.
Figura 3.1 Processo de Mapeamento Sistemtico - Adaptado de (Petersen et al., 2008)
Os detalhes de como o mapeamento sistemtico foi conduzido sero descritos no decorrer desse captulo que est estruturado da seguinte forma: a seo 3.1 descreve as questes que esse mapeamento pretende responder e a seo 3.2 descreve como foram realizadas as buscas e a seleo dos trabalhos relevantes associados s questes denidas na seo 3.1. Aps a excluso dos trabalhos irrelevantes e da leitura de todos os trabalhos relevantes, os mesmos foram agrupados de acordo com as categorias denidas na seo 3.3. Os resultados desse mapeamento sistemtico so apresentados nas sees 3.4, 3.5 e 3.6. A seo 3.7 apresenta possveis ameaas validade desse trabalho e por m a seo 3.8 apresenta as consideraes nais do captulo.
3.1
3.1.1
Diretivas de pesquisa
Pesquisa exploratria
Para realizar o mapeamento, a primeira atividade foi realizar uma pesquisa exploratria onde foram realizadas buscas no Google e Bing sobre com as seguintes palavras chave: multi-tenant multi-tenancy
23
SaaS Software as a service Apartir dessas buscas foram encontrados alguns artigos e matrias na web sobre o assunto. Boa parte desse material tratava-se de artigos baseados em opinies pessoais ou pequenos tutoriais. Essa atividade serviu para que fosse criada uma massa crtica 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 adoo da arquitetura multi-tenancy? Devido inexperiencia com a adoo dessa abordagem era necessrio saber quais o benefcios e perdas que se teria adotando a arquitetura multi-tenancy. Quando a adoo de multi-tenancy vivel? necessrio identicar os cenrios onde a adoo da arquitetura multi-tenancy vivel. Existe alguma forma de extender as funcionalidades de um tenant especco? Dado que cada cliente pode ter uma necessidade especca preciso saber como implementar as funcionalidades especcas de um cliente(tenant), j que teremos apenas uma nica instncia da aplicao que ser utilizada por todos os clientes. Como gerenciar a variabilidade entre os tenants? Se o aplicao suportar regras de negcio especcas para cada tenant, relevante saber como gerenciar isso. Como vericar 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 identicar 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 solicitaes de forma assncrona? A m de otimizar o uso de recursos, permitir que requisies sejam realizadas de forma assncrona pode ajudar na melhor utilizao 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 no tenha acesso a dados de outro indevidamente? Prover a segurana dos dados na arquitetura multi-tenancy
24
um fator crtico, tendo em vista que todos os tentants compartilham a mesma aplicao e possivelmente o mesmo banco de dados. Caso um tenant esteja consumindo muitos recursos, como migrar esse tenant para outra mquina 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 aplicao. Quais as propostas existentes para se implementar a arquitetura multi-tenancy? Saber quais as propostas, frameworks e bibliotecas existentes que auxiliem na implementao da arquitetura multi-tenancy de grande importncia para prover produtividade no desenvolvimento e evitar trabalho desnecessrio.
3.1.2
Denio de Questes de Pesquisa
Para conduzir as pesquisas realizadas nesse trabalho,era necessrio denir o escopo do estudo, para isso 4 questes foram derivadas apartir das questes j citadas na Seo 3.1.1: 1. Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? 2. Quais as propostas existentes para implementao da arquitetura multi-tenancy? 3. Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicao multi-tenancy? 4. Quando a adoo da arquitetura multi-tenancy vivel? A estratgia usada para denir os termos de busca, segue uma abordagem baseada em (Kitchenham et al., 2007), uma vez que esse trabalho sistematizou e deniu passos para derivar termos de pesquisa a partir de perguntas, pontos de vista de experts e artigos relevantes. Os passos para denio dos termos so descritos a seguir: Apartir das questes de pesquisa denidas anteriormente, os principais termos so denidos; Identicao de sinnimos a partir de artigos conhecidos e trabalhos relevantes na rea de pesquisa;
25
3.2. SELEO DOS DADOS
Traduo dos termos para o ingls por ser a lngua utilizada nas bases de dados eletrnicas de pesquisa e nas principais conferncias e eventos dos tpicos de investigao; Uso do operador OR para indicar que dois termos so alternativos; Uso do operador AND para indicar que dois termos devem estar juntos no resultado. Aps a execuo dos passos denidos acima foram encontrados termos para cada pergunta do nosso mapeamento sistemtico como possvel observar na Tabela A.5.
ID Q1 Q2 QUESTO Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy? Quais as propostas existentes para implementao da arquitetura multi-tenancy? Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicao multi-tenancy? Quando a adoo da arquitetura multi-tenancy vivel? 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 combinao desses termos deu origem a uma consulta genrica 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 benets OR loss)
3.2
3.2.1
Seleo dos dados

Conduo da pesquisa
Segundo Kitchenham (Kitchenham and Charters, 2007), as pesquisas iniciais dos estudos podem ser realizadas em bibliotecas digitais, mas isso no suciente para uma reviso sistemtica, outras fontes tambm podem ser pesquisadas. Pesquisadores da rea tambm podem ser consultados para a indicao de fontes de material mais adequado.
26
Os critrios para a seleo das fontes foram: (1) disponibilidade de consultar os artigos na web; (2) presena de mecanismos de busca usando palavras-chave; e, (3) importncia e relevncia das fontes. Um processo de ampla pesquisa foi realizado procura de artigos publicados combinando pesquisa automtica e manual para aumentar a cobertura. A busca automtica 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 conferncias onde mais se encontrou trabalhos na busca automtica: 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 Alm das buscas realizadas nessas conferncias, foram realizados tambm 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 questo. O Grco na Figura 3.2 mostra o percentual de estudos retornados de acordo com cada estratgia de busca, onde 98% (625/637) dos estudos foram retornados por meio de busca automtica e 2% (12/637) por meio de busca manual. A partir da string e fontes denidas, as buscas automticas retornaram um total de 625 estudos, no qual, 23% (144/625) no ScienceDirect, 15% (93/625) dos estudos foram identicados no IEEExplore, 24% (152/625) no El compendex, 24% (148/625) no
27
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":benets 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:benets 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:benets 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:benets 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 benets 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 benets 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 benets 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 benets wn AB OR loss)
Resultados 93
88
148
144
152
Tabela 3.2 Strings Search
28
Figura 3.2 Percentual de estudos retornados de acordo com a estratgia de busca
Figura 3.3 Percentual de estudos retornados pelas buscas automticas
Scopus e 14% (88/625) na ACM. O grco da Figura 3.3 mostra o percentual de estudos retornados por cada engenho de busca. Identicados os potenciais estudos, eles precisam ser analisados para que sua relevncia seja conrmada e trabalhos com pouca relevncia sejam descartados.
3.2.2
Triagem dos Trabalhos
Segundo Travassos (Travassos and Biolchini, 2007) critrios de incluso e excluso devem ser baseados nas questes de pesquisas. Os mesmos servem para excluir estudos que no so relevantes para responder s questes da pesquisa. Durante uma leitura prvia dos abstracts dos artigos foi possvel identicar alguns artigos que foram retornados na busca que no estavam relacionados ao contexto dessa pesquisa. Isso ocorreu pelo fato das palavras tenancy e tenant tambm serem utilizadas na rea de engenharia civil. Outro ponto importante identicar e remover resultados duplicados, j que muitos artigos
29
3.3. CLASSIFICAO
foram retornados em mais de uma fonte de pesquisa. Foram encontrados tambm alguns trabalhos aos quais o acesso era restrito. Diante desse cenrio, com o objetivo de eliminar os trabalhos irrelevantes, foram denidos os seguintes critrios de excluso: 1. Papers duplicados 2. Trabalhos no relacionados arquitetura multi-tanancy 3. Poster, Panel e Workshop paper 4. Papers que no estejam escritos em ingls 5. Papers que no acessveis na web. Aps a aplicao dos critrios de excluso foram eliminados os trabalhos irrelevantes como mostra a Tabela 3.3. Ao nal da aplicao dos critrios de excluso 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 atravs do cdigo descrito nessa tabela. A prxima seo apresenta o processo de anlise e classicao desses trabalhos. CRITRIO Trabalhos duplicados Trabalhos no relacionados arquitetura multi-tanancy Poster, Panel e Workshop paper Papers que no estejam escritos em ingls Papers que no acessveis na web. TRABALHOS EXCLUDOS 297 233 14 3 7
Tabela 3.3 Resultado da aplicao dos critrios de excluso
3.3
Classicao
Nessa seo ser descrito o esquema de classicao e os resultados do agrupamento dos trabalhos de acordos com o esquema de classicao denido. O resultado desse agrupamento apresentado atravs de tabelas e grcos no decorrer dessa seo.
3.3.1
Esquema de Classicao
A idia de categorizao dos estudos foi baseado no processo denido por (Petersen et al., 2008). O resumo, ttulo e palavras-chave de cada estudo so revisados em busca
30
3.3. CLASSIFICAO
de termos e conceitos que reitam a contribuio do trabalho. Durante essa atividade identicado tambm o contexto de cada pesquisa. Nesse processo palavras-chave de diferentes artigos so combinadas para desenvolver um entendimento de alto nvel sobre a natureza e a contribuio da pesquisa. Isso auxiliou na denio de um conjunto de categorias que ajudaram representativamente no entendimento de nossa populao de artigos. Em nosso estudo trs categorizaes foram criadas. A primeira delas verica a rea de interesse de multi-tenancy no qual o estudo focado, por exemplo: banco de dados, alocao de recursos, customizao, performance, segurana, escalabilidade, migrao de sistemas, SOA e monitoramento. Essas categorias foram baseadas em nos trabalhos (Godse and Mulik, 2009) e (Hfer 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 contribuies: framework, mtodo/tcnica, modelo, ferramenta e proposta de arquitetura. Essas duas primeiras facetas foram criadas apartir da identicao dos termos mais importantes existentes no ttulo, resumo, introduo e concluso dos estudos encontrados. No entanto, nesse trabalho tambm foi utilizado uma faceta que reete a abordagem de pesquisa usada em cada artigo, independente do foco ou rea associado ao artigo. Para isso foi considerado a classicao utilizada por (Wieringa et al., 2005). Essa classicao descrita na Tabela 3.5.
3.3.2
Classicao dos trabalhos relevantes
Essa atividade consiste em agrupar os trabalhos relevantes de acordo com as questes de pesquisa e facetas denidas anteriormente. Durante essa atividade foi possvel encontrar alguns trabalhos que poderiam auxiliar na resposta de mais de uma questo de pesquisa. possvel perceber tambm que tem-se poucos trabalhos relacionados resposta da questo 4, isso pode ser um indicativo que essa rea poderia ser melhor explorada. To importante quanto saber qual questo o trabalho responde saber a qual contexto ele est relacionado. Baseado nesse princpio foram criadas as categorias descritas na Tabela 3.4. Na Tabela 3.8 os trabalhos so agrupados por contexto. O objetivo com isso identicar em qual subrea de multi-tenancy o trabalho est focado. Por exemplo, quais trabalhos estudam a relao entre multi-tenancy e banco de dados, ou multi-tenancy e segurana, etc. Identicado o foco de cada trabalho, necessrio saber as contribuies de cada trabalho. Isso pode ajudar a saber em qual nvel de maturidade as pesquisas relacionadas a multi-tenancy encontram-se. Dado que um dos objetivos desse trabalho gerar insumos
31
3.3. CLASSIFICAO
CATEGORIA Alocao de recursos Banco de dados DESCRIO Essa categoria agrupa trabalhos que estudam ou propem solues para alocao eciente de recursos(processamento, armazenamento, largura de banda) em uma arquitetura multi-tenancy. Mtodos, tcnicas e ferramentas que auxiliem na implementao de uma aplicao multi-tenancy para de banco de dados. Nessa categoria tambm inclui trabalhos que realizam comparativos e experimentos relacionados a tcnicas de implementao de requisitos multi-tenancy para de banco de dados. Em muitos casos um tenant pode precisar de customizaes especcas para poder atender s necessidades de um cliente. Nesse caso necessrio a aplicao de tcnicas para implementar e gerenciar a variabilidade entre os tenants de uma aplicao multitenancy. Essa categoria agrupa trabalhos que estudam ou propem ferramentas, tcnicas ou mtodos para resolver o problema de variabilidade de tenants. O principal objetivo de uma aplicao SaaS atender a muitos clientes a um baixo custo. Nesse caso, permitir que a aplicao consiga atender a um nmero cada vez maior de clientes de fundamental importncia. Essa categoria agrupa trabalhos que abordem o problema de escalabilidade. Em muitos casos uma empresa pode possuir uma aplicao convencional e deseja transform-la em uma aplicao multi-tenancy. Essa categoria agrupa trabalhos que estudem ou proponham uma soluo para esse problema. Uma questo de grande importncia para o sucesso de uma aplicao multi-tenancy o atendimento SLA denida para cada cliente. Os trabalhos associados a esse grupo apresentam estudos e propostas para monitoramento dos tenants da aplicao quanto consumo de recursos ou qualidade de servio. Esses trabalhos abordam metodologias e tcnicas que otimizem a performance de uma aplicao. Tendo em vista que vrios tenants podem compartilhar a mesma aplicao e o mesmo banco de dados, vital para uma aplicao multi-tenancy isolar cada tenant de forma a no permitir acesso a dados no autorizados. Esses trabalhos abordam como SOA pode ser utilizada na implementao de uma aplicao multi-tenancy. Esses trabalhos abordam como virtualizao pode ser utilizada para auxiliar o desenvolvimento de aplicaes multi-tenancy.
Customizao
Escalabilidade
Migrao
Monitoramento
Performance Segurana
SOA Virtualizao
Tabela 3.4 Faceta Contexto
para possveis implementaes futuras, importante saber se j existem frameworks, ferramentas, mtodos, modelos, arquiteturas, etc, que possam ser utilizadas durante uma possvel implementao. A Tabela 3.9 apresenta os trabalhos agrupados por contribuio. Em alguns casos possvel que um trabalho apresente mais de uma contribuio e nesse caso ir aparecer em mais de uma categoria. Outra forma de mapear os trabalhos atrvs do tipo de pesquisa realizado no trabalho, essa categorizao foi descrita na Tabela 3.5 e o resultado de sua aplicao apresentado na Tabela 3.10. Para um melhor entendimento da rea pesquisada e do seu grau de maturidade, foi realizado o cruzamento de algumas categorizaes. O objetivo dessa atividade identicar por exemplo, quantos trabalhos tratam de mtodos ou frameworks para resolver problemas
32
3.3. CLASSIFICAO
CATEGORIA Validation Research Evaluation Research DESCRIO As tcnicas investigadas so novas e no foram implementadas ainda na prtica. As tcnicas usadas so ,por exemplo, experimentos realizados em laboratrio. Tcnicas so implementadas na prtica e uma avaliao da tcnicas conduzida. mostrado como a tcnica implementada na prtica (soluo de implementao) e quais so as consequncias da implementao em termos de benefcios e perdas (avaliao da implementao). Isso tambm inclui identicar problemas na indstria. A soluo para o problema proposto, a soluo pode ser nova ou uma extenso signicativa de uma tcnica existente. Os potenciais benefcios e a aplicabilidade da soluo mostrada por pequenos exemplos ou uma boa linha de argumentao Esses artigos esboam uma nova forma de visualizar coisas existentes pela estruturao do campo de pesquisa em termos de taxonomia ou framework conceitual. Esses artigos expressam uma opinio pessoal de algum sobre alguma tcnica ou se ela boa ou ruim, ou como as coisas deveriam ser feitas. Eles no dependem de trabalhos relacionados ou metodologias de pesquisa. Artigos de experincia explicam o que e como algo vem sendo feito na prtica. Deve ser uma experincia 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 aplicao multi-tenancy, ou quais trabalhos apresentam solues para monitoramento de aplicaes 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 possvel 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 customizao, performance, segurana, alocao de recursos e banco de dados. Pode-se observar tambm que em todos os anos temos publicaes realcionadas a bancos de dados, customizao e performance, isso um indicativo de que tais reas possuem aparentemente maior relevncia para o desenvolvimento de aplicaes multitenancy. Essa gura pode ser muito til para que pesquisadores possam identicar reas pouco exploradas no campo de desenvolvimento de aplicaes 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 decises a serem tomadas durante o processo de desenvolvimento de software. Durante esse processo muito comum dvidas sobre qual tcnica ser utilizada para implementar o mecanismo de customizao da aplicao, qual mecanismo de armazenamento de dados ser utilizado, como poder-se- garantir uma performance aceitvel para a aplicao. Observando o grco foi possvel vericar que a maioria dos trabalhos apresentava algum mtodo/tcnica ou alguma proposta de arquitetura para multi-tenancy e a rea mais carente de trabalhos escalabilidade. A maioria dos mtodos e tcnicas apresentados tratam de assuntos como banco
33
3.3. CLASSIFICAO
CATEGORIA DESCRIO Framework Essa categoria agrupa trabalho que apresentam frameworks que auxiliam no desenvolvimento de aplicaes multi-tenancy. Consideramos framework como um construto fundamental que dene pressupostos, conceitos, valores e prticas, e que inclui orientaes para a execuo propriamente dita (Tomhave, 2005). Mtodo ou Trabalhos que apresentam mtodos e tcnicas que tem o objetivo de resolver algum problema especco durante a implementao de aplicaes multi-tenancy tcnica Modelo Agrupa trabalhos que denem construes conceituais que auxiliam no desenvolvimento de aplicaes multi-tenancy. Consideramos modelo como um resumo, uma construo conceitual que representa processos, variveis e relacionamentos, sem prover orientaes especcas ou prticas para implementao (Tomhave, 2005). Ferramenta Essa categoria agrupa ferramentas implementadas para atender algum requisito de multi-tenancy ou para auxiliar durante o desenvolvimento de uma aplicao. Proposta de Agrupamento de propostas de arquitetura para implementao de aplicaes multiArquitetura tenancy ou propostas de arquitetura de plataformas de suporte multi-tenancy.
Tabela 3.6 Faceta Contribuio (Fonte: (Wieringa et al., 2005))

Questo 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 Questo de pesquisa
de dados, customizao, performance e segurana. J as arquiteturas e geral focam mais em banco de dados e customizao. Ainda assim, foram encontrados trabalhos que apresentam arquiteturas que tratam de assuntos como alocao de recursos, escalabilidade, performance, segurana e arquiteturas que se beneciam de integrao de servios com forte inuncia de SOA. Para identicar as lacunas existentes na rea de pesquisa foi criada a Figura 3.6, com o objetivo de identicar quais tipos de pesquisa foram desenvolvidos em cada contexto relacionado a multi-tenancy. Observou-se que a maioria dos trabalhos apresenta propostas de soluo e que tem-se poucos trabalhos objetivando realizar experimentos e validaes dessas propostas na indstria. possvel observar a grande evoluo das pesquisas na rea de customizao. Em geral, os autores desses trabalhos so pesquisadores da rea de SPL(Software Product Lines) que vislumbraram em multi-tenancy uma oportunidade de aplicar seus conhecimentos de customizao. A Figura 3.7 apresenta um mapeamento dos tipos de pesquisa por questo de pesquisa,
34
3.3. CLASSIFICAO
Contexto Alocao de Recursos Banco de Dados Customizao Escalabilidade Migrao Monitoramento Performance Segurana SOA Virtualizao 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

Contribuio Proposta de Arquitetura Ferramenta Framework Mtodo/Tcnica 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 contribuio
esse cruzamento de informaes ajudou a organizar os dados de forma a identicar para cada questo de pesquisa quais os tipos de trabalhos que mais foram realizados. Percebeuse que a questo de pesquisa 2 (Quais as propostas existentes para implementao da arquitetura multi-tenancy?) possui a maior quantidade de trabalhos associados, mas que a maioria so propostas de soluo que ainda no foram validadas na indstria. Isso indica a necessidade de integrao dos pesquisadores dessas reas com o mercado de forma a validar as propostas apresentadas e evoluir o campo de pesquisa. Embora os grcos apresentados at aqui tenham sido de grande relevncia para esse trabalho, durante a leitura dos trabalhos encontrados foi encontrado algumas informaes importantes que podem ajudar os leitores a entender melhor cada contexto relacionado a multi-tenancy. A seo a seguir apresenta as principais descobertas realizadas durante essa leitura.
35
3.3. CLASSIFICAO
Figura 3.4 Quantidade de artigos agrupados por Contexto e Ano
Figura 3.5 Quantidade de artigos agrupados por Contexto e Contribuio
36
3.3. CLASSIFICAO
Figura 3.6 Quantidade de artigos agrupados por Contexto e Tipo de Pesquisa
Figura 3.7 Quantidade de artigos agrupados por Questo 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
Alocao de Recursos
Para que se possa desfrutar dos benefcios que uma aplicao multi-tenancy traz, um conjunto de desaos devem ser solucionados (Kwok and Mohindra, 2008): 1. calcular os recursos computacionais necessrios para o funcionamento de cada novo tenant, e ao mesmo tempo atender s restries de todos os tenants em instncia da aplicao compartilhada. 2. Identicar fatores limitantes ou gargalos nos recursos computacionais requeridos para as vrias instncias, cada uma com vrios tenants contendo diferentes restries que devem ser atendidas. 3. Durante a distribuio dos tenants necessrio indicar a melhor localizao para que nenhuma restrio de SLA seja violada. 4. A distribuio dos tenants e instncias em um ambiente de computao distribudo deve ser automatizada. 5. A economia alcanada entre as diferentes formas de distribuies de tenants e instncias deve ser comparada e otimizada, de forma que seja encontrada a melhor distribuio possvel. O clculo do nmero mximo de usurios e tenants em uma instncia compartilhada em um servidor, sem que haja violao de restries denidas no contrato de SLA de
38
cada tenant um desao no trivial. Em (Kwok and Mohindra, 2008) os autores propem uma abordagem para o clculo de recursos requeridos para o bom funcionamento de vrios tenants em uma instncia de aplicao compartilhada. Nesse trabalho tambm descrito um mtodo para otimizar a distribuio de tenants e instncias de uma aplicao em um conjunto de servidores sem violar qualquer requisito de SLA dos tenants. Por m os autores apresentam uma ferramenta que tem o objetivo de auxiliar o deployment de aplicaes multi-tenancy usando o nmero mnimo de servidores, fornecendo portanto o mximo de economia em um ambiente de computao distribudo. Em (Fehling et al., 2010), os autores tambm realizam um estudo sobre as oportunidades de otimizao do uso de recursos, mas nesse caso o cenrio considerado um ambiente de computao heterogneo onde os recursos utilizados so oriundos de clouds pblicas e privadas. Nesse trabalhos os autores utilizam um algoritmo Smarter Simulated Annealing para auxiliar na busca de uma distribuio otimizada dos recursos computacionais. Outra questo associada alocao de recursos a priorizao das requisies recebidas por uma instncia de uma aplicao multi-tenancy. Em um cenrio multi-tenancy comum que cada tenant necessite priorizar as requisies de seus consumidores de tal maneira que um consumidor com prioridade alta poder ser atendido mais rapidamente que outro, e que a instncia da aplicao tambm priorize os tenants, de forma que as requisies de um tenant tenha maior prioridade de atendimento que outros. Diante desse cenrio, os autores de (Tsai et al., 2010b) propem um modelo para priorizar requisies de vrios tenants enquanto preserva as prioridades locais das requisies de um tenant especco. Os autores propem um algoritmo chamado Crystalline Mapping que mapeia prioridades internas de um tenant especco para prioridades globais.
3.4.2
Banco de Dados
Uma das preocupaes quando pretende-se implementar uma aplicao multi-tenancy planejar como os dados da aplicao sero armazenados. Atualmente, boa parte das aplicaes existentes no mercado utilizam bancos de dados relacionais. Existem vrias estratgias para implementar um esquema de banco de dados relacional de forma que ele permita o armazenamento de dados de vrios tenants. (Aulbach et al., 2008) apresenta vrias dessas tcnicas, que so mostradas na Figura 3.8 e brevemente descritas a seguir: Basic Layout - a tcnica mais bsica para implementar multi-tenancy adicionar uma coluna TENANTID em cada tabela para armazenar um valor que identica
39
a qual tenant um registro pertence. Essa abordagem prov uma boa consolidao mas no prov uma boa extensibilidade, j que no possui nenhum mecanismo para customizao de armazenamento de dados para um tenant especco. Private Table - a forma mais bsica para suportar extensibilidade, dado que cada tenant possui sua prprias tabelas privadas. Nessa abordagem, necessrio uma camada de transformao de queries para ajustar o nome das tabelas nas queries e substituir pelo nome da tabela privada. Extension Table - essa tcnica a combinao das duas tcnicas anteriores, as tabelas de extenso bem como as tabelas base devem possuir uma coluna para armazenar os dados de identicao do tenant. Outra coluna tambm precisa ser adicionada para armazenar a tabela lgica para que os dados possam ser reconstrudos. Essa abordagem utilizada para mapear esquemas orientados a objeto com herana no modelos relacional atualmente. Universal Table - estruturas genricas permitem a criao de um nmero arbitrrio de tabelas com formas arbitrrias. Universal Table uma estrutura genrica com uma coluna Tenant, uma coluna Table e um grande nmero de colunas de dados genricas. A coluna de dados tem um tipo exvel, como VARCHAR, no qual outro tipo pode ser convertido. Pivot Table - nessa tcnica as entidades de domnio so representadas por tabelas lgicas, cujas informaes so montadas dinmicamente. Uma Pivot Table possui as seguintes colunas: Tenant(identica o tenant), Table(identica a tabela qual o dado est associado), Row(identicar a linha qual o dado est associado) Col(identica o campo que a linha representa) e uma coluna para armazenar o dado em si, que pode ser armazenada em um tipo exvel como VARCHAR. Essa abordagem proporciona uma alta exibilidade mas possui muitas colunas de metadados que podem impactar negativamente na performance da aplicao, durante a manipulao dos dados. Chunk Table - essa tcnica uma extenso da tcnica 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 vrios tipos, e a coluna Col substituida pela coluna Chunk. Em comparao com a tcnica Pivot Table, essa tcnica armazena uma quantidade menor de metadados, o que diminui o tempo de reconstruo da tabela lgica.
40
Chunk Folding - as tabelas lgicas so verticalmente particionadas em chunks, os quais permitem juno quando necessrio. Essas so as tcnicas bsicas para a implementao de modelos de dados para aplicaes 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 tcnicas de implementao de aplicaes multi-tenancy a nvel de banco de dados. Os autores concluram que ainda no existe um Sistema de Gerenciamento de Banco de Dados(SGBD) ideal para esse tipo de aplicao e que um SGBD para SaaS deveria ser baseado na tcnica Private Table. Schiller (Schiller et al., 2011) apresenta em seu trabalho as primeiras funcionalidades para que um SGBD relacional possa suportar mltiplos tenants nativamente. Em sua proposta tenants so introduzidos como objetos de primeira classe e proposto o conceito de "contexto"para isolar um tenant de outro. Alm disso, o conceito de herana permite compartilhar o esquema da aplicao entre os tenants, ao mesmo tempo em que permite que o esquema seja extendido com estruturas de dados adicionais. Ao nal do trabalho o autor realiza uma avaliao da implementao de sua proposta atravs de experimentos.
3.4.3
Customizao
Um ponto importante em uma aplicao multi-tenancy a customizao. Em aplicaes web customizveis o cdigo torna-se mais complexo, problemas de performance impactam todos os tenants da aplicao e planejar segurana e robustez tornam-se pontos importantes. Segundo (Jansen et al., 2010), existem trs reas de pesquisa que so diretamente relacionadas a Tcnicas de Realizao de Customizao(Customization Realization Techniques - CRT) em aplicaes multi-tenancy: variabilidade em linhas de produtos de software, personalizao do usurio nal em aplicaes web e arquiteturas multi-tenancy. Pesquisadores que pretendem atacar esse problema devem direcionar seus estudos nessas trs reas. Outro ponto importante que os tenants de uma aplicao multi-tenancy no somente tem diferentes requisitos com respeito a propriedades funcionais, mas tambm podem exigir diferentes propriedades de qualidade de servio como privacidade e performance. Alguns tenants exigem que a aplicao possua alta disponibilidade e esto dispostos a pagar um alto preo pelo uso desse servio. Outros tenants no esto interessados em alta disponibilidade mas preocupam-se mais com um baixo preo. Em casos como esse necessrio que exista na aplicao algum mecanismo para ajustar a aplicao s reais
41
Figura 3.8 Tcnicas de mapeamento de esquema(Fonte: (Aulbach et al., 2008))
42
necessidades do usurio, no tocante aos casos citados anteriormente.
3.4.4
Escalabilidade
Para alcanar economia de escala, esse um dos problemas mais crticos para serem resolvidos em um cenrio real. Dado um nmero xo de servidores, necessrio otimizar a distribuio dos tenants de forma a maximizar o nmero total de tenants possveis sem violar seus requisitos de SLA e ainda estar preparado para o crescimento do volume de dados e de requisies. Em (Yuanyuan et al., 2009), os autores apresentam uma arquitetura focada na escalabilidade de dados. Eles propem uma entidade com base em grupos de particionamento horizontal, atravs da anlise das relaes entre as entidades de uma aplicao multitenancy. Nessa abordagem, entidades de negcio altamente coesas formam um grupo de entidades e o particionamento ocorre com base nesse grupo. Dessa forma cada operao acessa um nico grupo de instncias, podendo obter os dados necessrios atravs do acesso a um nico banco de dados e evitando a necessidade de transaes distribudas. (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 Servio(PaaS) atuais como Force.com,Windows Azure, e Google App Engine escalveis e customizveis. J em (Zhang et al., 2010b), os autores focam no problema de localizao de tenants, propem um algoritmo heurstico chamado Tenant Dispatch Heuristic(TDH) e realizam um conjunto de simulaes e comparaes onde avaliado como o uso desse algoritmo impacta na escalabilidade e economia de recursos.
3.4.5
Migrao
Migrar aplicaes web legadas que trabalham com um nico tenant(Isolated Tenancy Hosted Applications - ITHA) para multi-tenancy(multi-tenancy Enabled Application MTEA) no uma tarefa trivial, devido a quantidade de ferramentas e tcnicas de migrao apropriadas. De acordo com (Zhang et al., 2010a) os mtodos existentes para migrao so muito abstratos ou muito especcos quando tentamos aplic-los como guias para migrar uma aplicao que trabalha com um tenant isolado para uma aplicao multi-tenancy. Nesse mesmo trabalho os autores propem um mtodo sistemtico que prov diretrizes para migrar aplicaes ITHA para MTEA, levando em conta custo, risco e efetividade do mtodo de migrao.
43
Dado a caracterstica de demanda sazonal existente em vrios tipos de aplicao, uma funcionalidade essencial para um ambiente multi-tenancy a funcionalidade que permite a migrao de tenants entre hosts, uma tcnica chamada live migration(Clark et al., 2005; Liu et al., 2009). Em (Elmore et al., 2011) os autores apresentam Zephyr, uma tcnica para live migration que tem o objetivo de minimizar a interrupo de servio do tenant migrado. Atravs da introduo de uma sincronizao dupla que permite a ambos os ns, o n origem dos dados e o n destino, executarem simultaneamente transaes para o tenant. A migrao inicia-se com a transferncia dos metadados do tenant para o n destino, que pode realizar novas transaes enquanto o n origem completa as transaes que foram iniciadas quando a migrao se iniciou. De acordo com os autores, live migration uma importante caracterstica para habilitar elasticidade em bancos de dados multi-tenancy para plataformas de cloud.
3.4.6
Monitoramento
Para obter uma viso geral do funcionamento de seus servios, provedores de servio precisam de informaes sobre todas as camada de seus sistema, incluindo a aplicao, mquinas virtuais e uso de rede. Por razes de simplicidade, todas essas informaes devem idealmente ser entregues atravs de uma nica interface de monitoramento. Em (Hasselmeyer and dHeureuse, 2010) os autores apresentam alguns requisitos bsicos de uma infraestrutura de monitoramento para ambientes multi-tenancy: Multi-tenancy: a infraestrutura de monitoramento precisa naturalmente ser capaz de lidar com informaes de monitoramento provinientes de diferentes clientes (tenants). Escalabilidade: uma soluo de monitoramento precisa ser escalvel em vrios aspectos. Ela precisa escalar para um grande nmero de agentes de monitoramento, de noticao de eventos, de tenants, de recursos(virtuais e fsicos, servidores, elementos de rede e aplicaes), e de tipos de informao de monitoramento. Dinamismo: sistemas de monitoramento multi-tenancy precisam suportar o dinamismo que inerente a um ambiente multi-tenancy. Esse dinamismo decorre da rpida e frequente adio e remoo de tenants no datacenter. Alm disso, a alocao de recursos para os tenants tambm est em constante mudana e o conjunto de recursos que est sendo monitorado tambm pode mudar.
44
Simplicidade: o sistema de monitoramento deveria ser simples em dois aspectos: primeiro, a interface para monitoramento do sistema precisa ser fcil de entender e usar. Segundo, o sistema precisar ser fcil de instalar e manter, tanto para quem gerencia o datacenter quanto para os consumidores. Uma API simples desejvel, uma vez que facilita o trabalho de desenvolvedores que criam solues de controle e monitoramento. Abrangncia: esse requisito aborda a necessidade de uma infraestrutura nica de monitoramento que deve ser utilizvel para todos os tipos de informao de monitoramento, no importa o que est relacionado ao recurso ou qual o signicado que ele transmite. Essa abrangncia aplica-se a multiplos aspectos: tipos de dados, fontes de noticao e tenants. J em (Cheng et al., 2009) os autores propem um mecanismo de controle que monitora a qualidade de servio por tenant, detecta situaes anormais e dinamicamente ajusta o uso de recursos baseado nos parametros de SLA denidos 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 aplicaes multi-tenancy, isso porque aplicaes so monitoradas para que se possa vericar se a mesma est executando em um nvel de performance compatvel com a SLA denida para o cliente. Desde 2008 temos um bom nmero de trabalhos que estudam esse problema, dentre eles esto propostas de arquitetura, frameworks, mtodos, tcnicas, 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 padres de implementao de aplicaes multi-tenancy que tratam dos aspectos de isolamento e segurana, e avaliam a performance desse padres atravs de uma srie de experimentos e simulaes. Para permitir que um provedor de servio oferea diferentes nveis de performance baseado no nvel de SLA denido para um tenant especco, (Lin et al., 2009b) prope uma soluo que utiliza um regulador de performance baseado no controle de feedback. O regulador possui uma estrutura hierrquica, na qual um controlador de alto nvel gerencia a taxa de admisso de requisies para prevenir sobrecarga e um controlador de baixo nvel que gerencia os recursos alocados pelas requisies admitidas para alcanar um
45
nvel especco de diferenciao de servio entre os tenants que compartilham os mesmos recursos. Um prottipo dessa abordagem implementado utilizando Tomcat e MySQL e ao nal so 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 propem 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 relatrio de anomalias, identica os tenants agressivos, e fornece um mecanismo de moderao para eliminar o impacto negativo em outros tenants. Durante sua pesquisa os autores implementaram um prottipo do SPIN e realizaram alguns experimentos para demonstrar sua ecincia. Um desao interessante na rea de gerenciamento de performance entender e predizer performance de sistemas. Durante a realizao desse mapeamento foram encontradas duas abordagens relacionadas a esse assunto. (Schaffner et al., 2011) apresenta um estudo sobre a automao de tarefas operacionais em clusters multi-tenancy de bancos de dados em memria orientados a coluna. Foi desenvolvido um modelo para predizer se a alocao de um tenant em um servidor no cluster levaria a uma violao 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 mquina de aprendizado que usa dados monitorados para entender a performance do sistema. (Guo et al., 2007) apresenta um framework que possui um componente especco 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 injustia entre tenants em termos de performance de uso. Para alcanar esse objetivo os autores sugerem um padro de isolamento de performance hbrido, baseado em vrias tcnicas apresentadas em seu trabalho.
3.4.8
Segurana
Conana um dos maiores desaos que inuenciam a ampla aceitao de SaaS. Na ausncia de conana em SaaS, segurana e privacidade de dados guram entre os principais e mais importantes assuntos relacionados a arquitetura multi-tenancy. Foram
46
encontrados durante nossa pesquisa alguns trabalhos publicados nos ltimos 2 anos que esto relacionados a esse assunto. Um assunto bastante relevante a avaliao 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 avaliao de credibilidade de tenants baseado na experincia. Essa abordagem visa realizar a deteco e gerenciamento de tenants maliciosos a um baixo custo. De acordo com o histrico de acesso dos tenants, ele pode calcular a credibilidade de tenants, atribuir privilgios de acesso e determinar estratgias de deteco e monitoramento. De acordo com (Li et al., 2010) separao de responsabilidade de segurana 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 princpio de separao de responsabilidade de segurana em cloud; essa arquitetura dene dois nveis de granularidade no mecanismo de controle de acesso. O primeiro nvel est relacionado ao provedor de servio, que compartilha sua infraestrutura entre vrios clientes. O segundo nvel o nvel da aplicao onde uma mesma aplicao hospeda informaes de vrios tenants. Em (Zhang et al., 2009; Calero et al., 2010; Tsai and Shao, 2011) so apresentadas trs abordagens diferentes para implementao de mecanismos de segurana e controle de acesso para aplicaes multi-tenancy. Em (Zhang et al., 2009) proposta uma abordagem de controle de acesso baseado em restries de privacidade customizveis. Essa abordagem combina criptograa de dados e separao de informao e dene trs tipos de restries de privacidade baseado na funcionalidade de customizao em aplicaes SaaS. (Calero et al., 2010) descreve um sistema de autorizao para um servio de middleware em uma PaaS, que suporta controle de acesso baseado em hierarquia de funes, hierarquia de objetos baseada em caminho e federaes. Os autores apresentam tambm uma arquitetura de sistema de autorizao para implementao do modelo. De acordo com Wei-Tek(Tsai and Shao, 2011) as abordagens atuais para controle de accesso em cloud no escalam bem para requisitos multi-tenancy porque eles so baseados principalmente em identicadores(IDs) de usurio individual em diferentes nveis de granularidade. No entanto, o nmero de usurios pode ser enorme e causar um overread signicante no gerenciamento de segurana. RBAC (Role-Based Access Control) torna-se atrativo nesse caso pelo fato do nmero de papis de usurio em uma aplicao ser signicativamento menor, e usurios podem ser classicados de acordo com seus papis. Wei-Tek prope um RBAC usando uma ontologia de papis para arquitetura
47
3.5. MAPEAMENTO DAS EVIDNCIAS
multi-tenancy em clouds.
3.4.9
SOA
De acordo com o cenrio apresentado at aqui, possvel perceber que seria muito difcil e caro criar uma aplicao multi-tenancy que fosse to congurvel a ponto de permitir que todos os requisitos do usurio pudessem ser atendidos atravs de conguraes. Mesmo nesse cenrio possvel permitir que os prprios usurios implementem parte de suas solues 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 nvel de SOA, que habilita usurios a executar seus servios e outros artefatos SOA em um framework multi-tenancy SOA, bem como prover um ambiente para construir aplicaes multi-tenancy. Em seu trabalho os autores discutem arquitetura, decises de projeto, e problemas encontrados, juntamente com potenciais solues. Diferentes aspectos de arquitetura de sistemas no que se refere a multi-tenancy para SOA tambm so considerados como: deployment de servios, envio de mensagens, segurana, execuo de servios e nalmente acesso a dados. Junjie Jing(Jing and Zhang, 2010) apresenta uma arquitetura aberta para construir solues SaaS. Um benefcio dessa abordagem a diminuio do acoplamento, o que traz maior exibilidade para aplicaes SaaS. Por um lado novos servios podem facilmente se juntar aos existentes, por outro lado pode-se tambm reprogramar um servio para gerar um novo servio de acordo com as necessidades do negcio. Dessa forma aplicaes multi-tenancy baseadas em SOA podem ser consideradas alterveis e extensveis para suportar resposta rpida e agilidade operacional.
3.5
Mapeamento das evidncias
Nessa seo, so apresentados os resultados para cada questo de pesquisa. Na Seo 3.5.1 so apresentadas a evidncias relacionada vantagens e desvantagens da adoo da arquitetura multi-tenancy. Na Seo 3.5.2 so apresentadas as evidncias relacionadas propostas existentes que podem auxiliar a adoo e implementao de multi-tenancy, bem como frameworks, APIs e ferramentas relacionadas a esse tema. Na Seo 3.5.3 so descritos evidncias que apresentam formas de gerenciar variabilidade entre tenants de uma aplicao multi-tenancy, nessa seo so apresentadas abordagens e propostas de
48
soluo para esse problema. Por ltimo a seo 3.5.4 apresenta evidncias que podem auxiliar durante a tomada de deciso de adotar ou no a arquitetura multi-tenancy.
3.5.1
Q1 - Quais as vantagens e desvantagens de se adotar arquitetura multi-tenancy?
Essa questo busca identicar em meio aos trabalhos encontrados, evidncias que apontem vantagens e desvantagens da adoo da arquitetura multi-tenancy. Durante esse trabalho foram identicados 12 trabalhos que citam alguma vantagem ou desvantagem da adoo de multi-tenancy. Apartir da leitura dos mesmos identicamos as seguintes vantagens: O provedor de servio pode usar a mesma verso da aplicao(com o nico cdigo base) para prover servios para vrias organizaes(Tsai et al., 2010b) Consumidores obtm acesso capacidade de processamento elstico que pode ser aumentada ou diminuida de acordo com a demanda se a necessidade de realizar manuteno em servidores(Tsai et al., 2010b) Dois benefcios de uma abordagem baseada em uma plataforma multi-tenancy so colaborao e integrao. Pelo fato de todas as aplicaes executarem em um nico espao, torna-se mais fcil permitir a um usurio de qualquer aplicao acesso uma coleo de dados. Essa capacidade simplica o esforo necessrio para integrar aplicaes relacionadas e os dados que elas gerenciam(Weissman and Bobrowski, 2009) Atualizao 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 inovaes sem gastar seu prprio orcamento de TI(Kwok and Mohindra, 2008) Aumento da margem de lucro para o provedor de servio atravs da reduo dos custos de entrega e diminuio dos custos de assinatura do servio para os clientes(Li et al., 2008)
49
Possibilidade de reusar regras de negcio com o mnimo de adaptao(Bezemer et al., 2010) Organizao dos usurios em vrios nveis de acordo com suas necessidades e melhor gerenciamento de recursos(Jasti et al., 2010) O usurio pode customizar sob-demanda os servios providos pelo fornecedor do software(Zheng et al., 2010) Reduo dos custos de venda e manuteno do software por porte do provedor do software(Zheng et al., 2010) As desvantagens da adoo de multi-tenancy foram pouco mencionadas nos trabalhos encontrados. Em geral os trabalhos mencionavam mais vantagens do que desvantagens. A seguir so listados alguns pontos considerados vantagens e desvantagens por alguns autores: difcil calcular os recursos requeridos por cada novo tenant e ao mesmo tempo garantir que as restries de todos os outros tenants da mesma instncia sejam atendidas(Kwok and Mohindra, 2008) Fatores limitantes e gargalos nos recursos computacionais exigidos pelas vrias instncias devem ser identicados(Kwok and Mohindra, 2008), e isso no trivial nesse tipo de ambiente Diculdade de comparar e otimizar a reduo de custos das diferentes formas de distribuio dos tenants entre os servidores, pelo fato de existirem vrias variveis envolvidas(Kwok and Mohindra, 2008) Preocupao das empresas com o custo inicial de reestruturas suas aplicaes legadas para multi-tenancy(Bezemer and Zaidman, 2010) Preocupao dos mantenedores de software com a possibilidade de multi-tenancy introduzir problemas adicionais de manuteno decorrentes do fato desses novos sistemas serem altamente customizveis(Bezemer and Zaidman, 2010)
3.5.2
Q2 - Quais as propostas existentes para implementao da arquitetura multi-tenancy?
Essa questo visa identicar trabalhos que possam auxiliar na possvel implementao de uma aplicao multi-tenancy. Frameworks, ferramentas, modelos, propostas de
50
arquitetura, mtodos ou tcnicas que possam auxiliar no desenvolvimento de aplicaes multi-tenancy so identicados e catalogados. Um ponto importante nessa parte do trabalho identicar o grau de maturidade das aplicaes multi-tenancy com relao implementao. Frameworks Os autores de (Guo et al., 2007) focam seu trabalho principalmente no padro multitenancy nativo. Eles exploram os principais requisitos e dasaos de multi-tenancy nativo e apresentam um framework baseado em SOA para suportar o projeto, desenvolvimento e gerenciamento de aplicaes multi-tenancy de forma transparente. Atravs de da entrega de vrios servios que provem funcionalidades multi-tenancy aplicao desenvolvida, os desenvolvedores podem focar na camada de lgica de negcios sem se preocupar com a implementao dos requisitos inerentes a multi-tenancy. Os 5 principais componentes de servio desse framework que habilitam multi-tenancy em uma aplicao so: isolamento de segurana: baseado nos mecanismos de segurana tradicionais (autenticao, autorizao, auditoria, etc), preciso tambm considerar os riscos de segurana pontenciais introduzidos por outros tenants que compartilham a mesma instncia da aplicao e recursos. isolamento de performance: administradores do sistema esto interessados em evitar que o comportamento de um tenant afete a performance de outros tenants. Alm disso, os tenants esperam receber os nveis de servio denidos no contrato. isolamento de disponibilidade: quando muitos tenants compartilham a mesma instncia da aplicao, crtico para o provedor de servio detectar qualquer falha e evitar a propagao dessa falha o mais breve possvel. isolamento de administrao: a interface administrativa deveria ser isolada para cada tenant individual para que eles possam visualizar e mudar os dados no nvel operacional e de negcio que so relevantes para suas organizaes. customizao on-the-y: necessrio customizar a aplicao para ajustar as necessidades e situaes particulares do tenant. Para negcio pequenos e mdios que utilizam esse framework a customizao ser realizada de forma intuitiva e pelo prprio cliente, sem a necessidade de uma equipe de desenvolvimento.
51
(Kwok et al., 2008b) e (Rimal and El-Refaey, 2010) apresentam propostas de frameworks e apresentam o resultado de sua aplicao em um contexto especco. (Kwok et al., 2008b) apresenta o desenvolvimento de uma aplicao para gerenciamento de contratos eletrnicos e a implementao dos requisitos multi-tenancy atravs de um framework proposto pelos autores. Em sua abordagem os autores tratam de pontos importantes como customizao, segurana e armazenamento de dados. (Rimal and El-Refaey, 2010) descreve um framework para orquestrao de ambiente de cloud multi-tenancy que apresenta duas abordagens para o gerenciamento de workows cientcos: workows baseados em semntica onde os autores apresentam uma abordagem utilizando ontologias e workows baseados em polticas, que podem ser denidas como recursos requeridos ou controle de segurana. Um ponto importante no contexto de multi-tenancy a alocao de recursos e localizao dos tenants no datacenter. (Fehling et al., 2010) e (Tang et al., 2010) tratam desse assunto. (Fehling et al., 2010) analisa os desaos inerentes ao cenrio de multi-tenancy e identica vrias oportunidades de otimizao decorrentes da necessidade de distribuir ecientemente tenants que possuem funcionalidades iguais, mas qualidade de servio diferentes. Esse trabalho tambm dene um framework para desenvolvimento de estratgias de distribuio de tenants que permite a modelagem de recursos, suas dependncias de implantao e usurios com demandas especcas 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 utilizao de recursos no processo de alocao dos tenants. Nesse mesmo trabalho os autores propem um framework para capturar dados dos tenants que auxiliem na identicao de fatores determinantes na localizao dos tenants, um algoritmo para alocao de tenants e um mtodo para estimao de recursos. (Pervez et al., 2010a) apresenta o framework D-Val que realiza a validao de requisies e auxilia os provedores de SaaS a fornecer software com qualidade de servio em conformidade com a SLA denida para o cliente. D-Val funciona como um ltro que identica requisies invlidas e impede que elas sejam processadas pelo servidor. Em (Tsai et al., 2010a) e (Wang et al., 2010) os autores propem frameworks que focam em customizao. (Tsai et al., 2010a) apresenta um framework para customizao, que suporta e gerencia variabilidade de SaaS e requisitos especcos dos tenants. Os autores utilizam ontologias para derivar a customizao e informaes de implantao dos tenants. Alm disso esse framework possui uma engine de recomendaes inteligente que auxilia a criao de novos tenants usando informaes de tenants j implantados. (Wang
52
et al., 2010) apresenta um framework para gerenciamento de processos de negcio em aplicaes multi-tenancy que utiliza o paradigma orientado a aspectos para implementar as customizaes. (Chen et al., 2011) dene RaaS(Routing as a Service), um framework para prover uma plataforma de controle de rota para mltiplos 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 aplicaes 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 relatrios para identicar os tenants agressivos e fornece um mecanismo de moderao auto-adaptativo para eliminar seus impactos negativos nos outros tenants. Em (Hui et al., 2009) os autores propem um SGBD chamado M-Store, que prov servios de armazenamento e indexao para aplicaes multi-tenancy. Para melhorar a escalabilidade dos sistemas, M-Store trabalha com 2 tcnicas chamadas BIT(Bitmap Interpreted Tuple) e MSI(Multi-Separated Index). BIT uma otimizao onde o SGBD no armazena valores nulos de atributos no usados em tabelas compartilhadas, j o MSI prov exibilidade, uma vez que os indices no SGBD so criados para cada tenant ao invs da criao de um indice para todos os tenants. (Xiong et al., 2011) prope 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 mdulos de modelagem de sistema e o mdulo de deciso de alocao de recursos. O mdulo de modelagem de sistema usa tcnicas de mquinas de aprendizado para descobrir a margem de lucro potencial para cada cliente sob diferentes formas de alocao de recursos. Baseado no modelo de aprendizado, o mdulo de alocao de recursos ajusta dinamicamente a alocao de recursos para alcanar a otimizao dos lucros. Mtodos ou Tcnicas No total foram encontrados 27 mtodos ou tcnicas que abordam os mais variados contextos relacionados a aplicaes multi-tenancy. Esses trabalhos so brevemente descritos na tabela 3.11.
53

Contexto Alocao de Recursos Alocao de Recursos Banco de dados Banco de dados Banco de dados Descrio do mtodo ou tcnica (Kwok and Mohindra, 2008) descreve mtodos para localizao tima de tenants e instancias baseado em um modelo de localizao de tenants proposto pelos autores, sem violar qualquer requisitos de SLA dos tenants existentes nos servidores do datacenter. (Tsai et al., 2010b) prope um mtodo para priorizar requisies de servios para aplicaes multi-tenancy preservando as prioridades locais das requisies de cada tenant. Os autores propem 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 trs abordagens para implementar bancos de dados multi-tenancy e s compara atravs de experimentos. As tres abordagens comparadas so: shared machine, shared process e shared table. (Aulbach et al., 2008) descreve uma tcnica para mapeamento de esquemas de banco de dados para multi-tenancy chamada Chunk Folding. Nessa tcnica tabelas lgicas so verticalmente particionadas em chunks que so distribudas em diferentes tabelas fsicas e realizado a juno desses dados quando necessrio. (Grund et al., 2008) os autores analisam operaes tpica em bancos de dados multi-tenancy e mostram como essas operaes se relacionam. No decorrer o trabalho os autores denem diferentes padres de acesso baseado na abordagem de tabelas compatilhadas(shared table approach) e propem uma nova projeto de compartilhamento de tabelas multitenancy. (Weiliang et al., 2010) os autores propem uma abordagem chamada multiple sparse tables que seria uma adaptao da tcnica sparse tables tradicional para o contexto de multi-tenancy. (Schiller et al., 2011) essa abordagem implementa isolamento entre tenants, extenso de esquemas tenants e funcionalidade de gerenciamento de dados centrada nos tenants em um SGBD relacional. Os autores tambm apresenta o conceito de herana de esquema, que permite o compartilhamento do esquema base de uma aplicao atravs dos tenants ao mesmo tempo que permite a extenso do esquema por tenant. (Xiong et al., 2011) esse trabalho j citado na seo 3.5.2, alm de apresentar a ferramenta SmartSLA apresenta os mtodos e tcnicas implementados pela ferramenta. (Mietzner et al., 2008) descreve um formato para compor pacotes de aplicaes SaaS congurveis para aplicaes desenvolvidas utilizando arquitetura orientada a servio. Os autores descrevem como arquitetura de componentes de servio (SCA - Service Component Architecture) pode ser extendida com descritores de variabilidade e padres multitenancy para empacotar e implantar aplicaes multi-tenancy congurveis. (Jegadeesan and Balasubramaniam, 2009) os autores apresentam uma abordagem para implementar variabilidade de tenants utilizando programao orientada a aspectos. (Cai et al., 2010) nesse trabalho descrito uma abordagem transparente para fazer uma aplicao web existente suportar multi-tenancy e executar em uma cloud pblica. Os autores tambm implementam um sistema multi-tenancy real que separa os interesses dos desenvolvedores da aplicao, operados de SaaS, administrador do tenant e usurio do tenant. (Zhang et al., 2010a) um mtodo sistemtico proposto para migrar aplicaes single-tenant para multi-tenancy focando em aspectos como modelo de dados, controle de acesso e gerenciamento de tenants, levando em considerao as necessidades de negcio e assuntos tcnicos. (Elmore et al., 2011) proposto o Zephyr, uma tcnica para migrar tenants com o mnimo de interrupo de servio. (Hasselmeyer and dHeureuse, 2010) os autores apresentam uma abordagem para monitoramento de vrios recursos coo rede, servidores e aplicaes em um ambiente multi-tenancy, levando em considerao que normalmente essas aplicaes executam em algum ambiente virtualizado. (Wang et al., 2008b) nesse trabalho os autores identicam os potenciais gargalos de performance, apresentam as abordagens de otimizao correspondentes e melhores prticas para implementao em ambientes multi-tenancy. (Lin et al., 2009b) nesse trabalho apresentado uma abordagem de regulao de performance baseada em feedback. O regulador de performance possui uma estrutura hierquica, com a qual um controlador de alto nvel gerencia as taxas de admisso de requisies para evitar sobrecarga e um controlador de baixo nvel gerencia a alocao de recursos para as requisies aceitas. (Ahmad and Bowman, 2011) os autores realizam um estudo experimental realizado para entender os fatores que inuenciam na performance de sistemas multi-tenancy e sugerem uma abordagem utilizando mquinas de aprendizado para predizer a performance das aplicaes. (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, denie trs tipo de restries de privacidade, e ento prope uma abordagem baseada em restries de privacidade customizveis. (Li et al., 2010) os autores apresentam uma abordagem para serparao de segurana em cloud onde so denidos 2 nveis de granularidade para controle de acesso. O primeiro nvel refere-se segurana entre tenants e o segundo nvel trata do mecanismo de controle de acesso da prpria aplicao. (Nie, 2010) apresenta um algoritimo de avaliao de credibilidade entre os tenants baseado em experincia. De acordo com o histrico de acesso, o algoritimo calcula a credibilidade de um tenant, permitindo a deteco e monitoramento de tenants maliciosos com um baixo custo. (Mietzner et al., 2009a) os autores introduzem e avaliam um conjunto de padres que podem ser usados para projetar, desenvolver e implantar aplicaes SaaS orientadas a servio. Alm disso os autores descrevem como os requisitos multi-tenancy podem ser alcanados. (Ding et al., 2010) os autores apresentam um mecanismo de compensao exvel que suporta customizao e implanta dinmicamente processos de compensao. (Tsai et al., 2007) os autores exploram o uso de virtualizao para habilitar funcionalidades multi-tenancy em sistemas com o mnimo de alteraes possvel. (Siddhisena et al., 2011) apresenta uma abordagem que utiliza uma abordagem de virtualizao para construo de uma plataforma virtualizada para aplicaes multi-tenancy, com foco no aumento de segurana e escalabilidade.
Banco de dados Banco de dados
Banco de dados Customizao
Customizao Migrao
Migrao
Migrao Monitoramento
Performance Performance
Performance
Performance/ Segurana Segurana Segurana
Segurana
SOA
SOA Virtualizao Virtualizao
Tabela 3.11 Mtodos e tcnicas para implementar multi-tenancy
54
Modelos de fundamental importncia modelos que auxiliem desenvolvedores e engenheiros de software durante a construo de aplicaes. 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, especcamente nos anos de 2010 e 2011. Essa seo apresenta alguns trabalhos relacionados a modelos que visam auxiliar o desenvolvimento de aplicaes multi-tenancy. (Kong et al., 2010) prope um modelo de customizao multi-nvel para aplicaes SaaS que suporta compartilhamento de customizaes atravs de diferentes tenants. Nesse trabalho os autores apresentam o projeto de uma arquitetura de armazenamento de dados que implementa esse modelo e apresenta uma comparao experimental dessa nova estratgia de customizao. Em (Schaffner et al., 2011), como j mencionado na seo 3.4.7 os autores estudam a automao operacional de tarefas em bancos de dados orientados a coluna e denem um modelo para predio de violaes no tempo de resposta esperado. Para a alocao 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 alocao de recursos apresentado em (Zhang et al., 2010b). Focando-se no problema OTPP(On-line Tenant Placement Problem), nesse trabalho os autores propem um modelo para estimar consumo de recursos em aplicaes multi-tenancy. Foram encontrados tambm modelos que propem alguma melhoria no armazenamento de dados em aplicaes multi-tenancy. (Xue et al., 2011) apresenta um modelo de indexao para armazenamentos de dados que utilizam a abordagem Multiple Sparse Tables. Um trabalho que tambm aborda esse assunto (Ahmad and Bowman, 2011) e j foi citado na seo 3.5.2. J em (Aulbach et al., 2011) os autores apresentam trs funcionalidades que um SGBD multi-tenancy deveria prover: extensibilidade, compartilhamento de dados e evoluo. Os autores apresentam o FLEXSCHEME, um modelo integrado para bancos de dados multi-tenancy que atende, segundo os autores, s trs funcionalidades citadas anteriormente. (Tsai and Shao, 2011) prope um modelo de controle de acesso que utiliza ontologias. Esse modelo j foi mencionado na seo 3.4.8.
55
Propostas de Arquitetura Um ponto importante durante o desenvolvimento de software em qualquer segmento conhecer implementaes semelhantes j realizadas por outros desenvolvedores. Partindo desse princpio essa seo apresenta propostas de arquitetura de software que auxiliem no desenvolvimento aplicaes multi-tenancy. Foram encontradas propostas de arquitetura para aplicaes 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 indstria, 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 construo de aplicaes multi-tenancy. Nessa arquitetura tudo que exposto para os desenvolvedores e usurios da aplicao internamente representado como metadado. Formulrios, relatrios, workows, privigios de acesso, customizaes especcas do tenant e lgica de negcio, 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 aplicaes na empresa EXACT, uma empresa de desenvolvimento de software especializada em ERP, CRM e aplicaes nanceiras. Em sua arquitetura os autores apresentam 3 componentes bsico para a implementao de aplicaes multi-tenancy: componente de autenticao, customizao e banco de dados. Alm disso os autores apresentam um estudo de caso e uma lista de lies aprendidas. Outros autores apresentam Arquiteturas Orientadas a Servio 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 aplicaes SaaS. (Azeez et al., 2010) apresenta uma arquitetura para implementar multi-tenancy a nvel de SOA, que permite a usurios executar seus servios 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 segurana e balanceamento de carga em ambiente de cloud computing. Alm das propostas de arquitetura citadas anteriormente, foi encontrado tambm uma proposta de estilo arquitetural, o SPOSAD, que descrito em (Koziolek, 2010) e (Koziolek, 2011). SPOSAD descreve componentes, conectores, e elementos de dados
56
de uma arquitetura multi-tenancy, bem como restries impostas nesses elementos. Os autores tambm apresentam os benefcios do uso dessa arquitetura e informaes que podem auxiliar em decises de projeto. Em (Tsai et al., 2010d) os autores apresentam uma arquitetura de duas camadas que foca em escalabilidade, que trabalha a nvel de servio e aplicao para economizar o uso de recursos, e a idia chave aumentar os recursos somente onde houver gargalos. Vrias tcnicas de duplicao de recursos computacionais so propostas, incluindo duplicao preguiosa e duplicao pro-ativa para alcanar a melhor performance do sistema. Alm da arquitetura esse trabalho apresenta um algoritmo para alocao 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 negcios (BSS - Business Support System) e discute brevemente uma abordagem para alcanar congurabilidade, seguranca e escalabilidade na arquitetura. Focando em escalabilidade de dados, os autores propem um particionamento horizontal baseado em grupos de entidades pela anlise das relaces entre as entidade do sistema. (Takahashi et al., 2010) esse trabalho prope uma arquitetura de sistema autnomo para infraestrutura de SaaS escalvel para atender ao crescimento e acesso multi-tenancy de aplicaes SaaS. Os autores prope o conceito e arquitetura do Cache L4, que tem o objetivo de aumentar a ecincia SaaS com otimizaes no uso do hardware. (Calero et al., 2010) os autores apresentam a arquitetura de um sistema de autorizao multi-tenancy apropriado para um servio de middleware para PaaS. Cada empresa pode prover vrios servios de cloud que podem colaborar com outros servios tanto da mesma organizao quanto de organizaes diferentes. Esse sistema de autorizao suporta acordos de colaborao entre empresas(tambm conhecidos como federaes).
3.5.3
Q3 - Existe alguma forma de gerenciar a variabilidade entre os tenants de uma aplicao multi-tenancy
Um sistema de banco de dados para SaaS deveria oferecer esquemas exveis, que podem ser extendidos para diferentes verses da aplicao e dinamicamente modicados enquanto o sistema est sendo usado. Como j mencionado nas sees 3.4.2 e 3.5.2, os trabalhos (Aulbach et al., 2008) e (Aulbach et al., 2009), apresentam tcnicas para mapear variabilidade de tenants em um banco de dados. Os autores descrevem essas tcnicas e realizam experimentos com o objetivo de identicar a tcnica 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 no foi desenvolvido
57
e apresentam algumas sugestes sobre como ele deveria ser projetado. Em SaaS, sistemas de workow so uma boa opo para o baixo acoplamento, customizao, arquitetura de computao baseada em web e servios web. Alm disso, podemos dinamicamente customizar servios e processos de negcio. Para alcanar isso, o suporte a transao de processos de negcio tem se tornado cada vez mais importante. Em meio aos protocolos de servios web atuais, existem alguns protocolos relevantes para suporte a processamento de transaes. Em (Wang et al., 2008b) os autores propem um mecanismo de compensao exvel que suporta deploymente customizvel e processo de compensao. (Arya et al., 2010) apresenta informaes sobre a natureza da congurabilidade em SaaS, como pode ser provido e quais tecnologias so necessrias para suport-la. De acordo com os autores, as principais tecnologias habilitadoras de cloud computing so: web 2.0, RIA (Rich Internet Application), SOA, Cloud Computing e virtualizao. Alm disso os autores denem GUI, workow, dados e controle de acesso como os principais aspectos congurveis em SaaS, e descrevem vrios mtodos utilizados para manipulao de metadados, segurana e servios compartilhados, bem como mdulos de customizao e extenso de tenants. (Jansen et al., 2010) apresenta uma viso geral de como tcnicas de realizao de customizao de linha de produtos de software podem ser aplicadas para realizar customizao durante o desenvolvimento de aplicaes multi-tenancy. Os autores apresentam um catlogo de tcnicas de realizao de customizao para aplicaes web e mostram como so implementadas na prtica usando dois estudos de caso. O catlogo auxilia desenvolvedores web e arquitetos de software a selecionar a tcnica correta durante a implementao de aplicaes multi-tenancy. Sem esse tipo de informao, desenvolvedores de aplicaes multi-tenancy precisam reinventar a roda e no se beneciam de padres arquiteturais existentes. Em muitos casos, se a aplicao de software apenas com requisitos comuns no consegue atender de forma aceitvel maioria dos clientes, uma forte capacidade de congurao e customizao ir tornar-se uma fator chave no sucesso da aplicao. Em (Sun et al., 2008), o conceito de congurao e customizao no contexto de SaaS so esclarecidos, e introduzido um modelo de competncia e um framework para ajudar fornecedores de SaaS a planejar a oferta de customizao e congurao em suas aplicaes. Em (Kwok et al., 2008b) autores apresentam o desenvolvimento de uma aplicao multi-tenancy para gerenciamento de contrato eletrnico. No decorrer desse trabalho os
58
autores descrevem vrios mtodos usados para gerenciamento de metadados, compartilhamento de servios e segurana. Ainda de acordo com os autores os atributos para o sucesso de uma aplicao multi-tenancy so congurabilidade, ecincia e escalabilidade. Durante esse trabalhos os autores enfatizam multi-tenancy e customizao. (Li et al., 2009) explora os desaos existente na rea de customizao em ambiente multi-tenancy e prope um modelo de customizao de relacionamentos. Em seu trabalho os autores apresentam o modelo de customizao de objetos como o mais importante e apresenta nveis de customizao de objetos: dados, servio, processo e interface grca. Os autores discutem o relacionamento entre objetos em cada um desses nveis. Caso no seja implementadoo corretamente, a realizao de customizao de tenants separadamente por diferentes aplicaes de negcio, leva muita duplicao de cdigo e metadados. Em (Kong et al., 2010), os autores propem um modelo de customizao multi-nvel para aplicaes SaaS que suporta compartilhamento de customizao atravs de diferentes aplicaes multi-tenancy virtualizadas. Alm disso os autores apresentam uma arquitetura de armazenamento de dados multi-tenancy dirigida a metadados que implementa modelo de customizao multi-nvel. Ao nal do trabalho realizada uma comparao do modelo proposto com o modelo antigo atravs de experimentos. (Tsai et al., 2010a) apresenta um framework para customizao multi-camada, para suportar e gerenciar a variabilidade de aplicaoes SaaS e requisitos especcos dos tenants. Ontologia usada para derivar a customizao e informaes de implantao para os tenants. O framework tambm possui uma engine de recomendao para suportar a implantao de novos tenants usando informaes de tenants existentes. Um estudo de caso usado para demonstrar o modelo proposto. (Zhang et al., 2007), nesse trabalho proposto uma poltica de customizao baseada em WSDL (Web Service Denition Language). A poltica proposta aplicada para permitir a customizao de SaaS e facilitar a integrao entre SaaS. Para permitir a implementao dessa abordagem os autores apresentam um framework chamado WSPolicy. J (Mietzner et al., 2008), como j citado na seo 3.5.2 apresenta uma abordagem baseada em SCA para implementar variabilidade entre tenants. Em (Jegadeesan and Balasubramaniam, 2009), os autores propem o uso de orientao aspectos para modularizar fatores de variabilidade como interesses transversais ou aspectos. Alm disso proposto uma forma de compor esses interesses com um mdulo bsico da aplicao que os autores chamam de kernel, possibilitando a criao de variantes do servio. Essa abordagem visa oferecer o mximo de exibilidade para os tenants enquanto garante fcil congurabilidade e reuso.
59
(Mietzner et al., 2009b) apresenta como tcnicas 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 customizao e implantao em aplicaes SaaS. (Lizhen et al., 2010) prope a modelagem de variabilidade usando metagrafos para gerenciar a variabilidade para congurao e customizao de aplicaes SaaS. Essa abordagem pode sistematicamente, segundo os autores, descrever pontos de variabilidade e seus relacionamentos, e garantir a qualidade de entradas de congurao feitas pelos consumidores. Os benefcios dessa abordagem so demonstrados no trabalho atravs de um exemplo simples.
3.5.4
Q4 - Quando a adoo da arquitetura multi-tenancy vivel?
No encontramos trabalhos que tratam diretamente da viabilidade de multi-tenancy. Ainda assim, foi possvel coletar evidncias em alguns trabalhos encontrados que apontam cenrios em que a adoo de multi-tenancy vivel. O principal ponto que deve-se considerar a capacidade da equipe de desenvolvimento de implementar requisitos funcionais e no funcionais relacionados a multi-tenancy como compartilhamento de recursos de hardware, congurabilidade, compartilhamento de aplicao, autenticao, armazenamento de dados, customizao, etc. Implementar esses requisitos podem gerar um custo bem maior do que simplesmente manter 2 ou 3 verses de uma aplicao, em alguns casos. De acordo com (Kwok et al., 2008b), com um nico cdigo base da aplicao para suportar vrios tenants, o tempo total de implantao em um novo cliente menor. Alm disso, a atualizao da aplicao mais simples e centralizada pelo fato de existir apenas um nica verso do cdigo fonte e uma nica instncia da aplicao(ou um nmero muito reduzido). H de se levar em considerao que tanto novas implementaes quanto bugs sero propagados para todos os clientes de uma s vez, isso exige uma boa bateria de testes para garantir a qualidade da aplicao. Desconsiderar a criticidade de uma boa bateria de testes nesse ambiente pode inviabilizar a adoo de multi-tenancy. De acordo com (Aulbach et al., 2008), multi-tenancy torna-se menos atrativo em cenrios onde a complexidade da aplicao crescente. De acordo com os autores, single-tenant a abordagem mais adequada para aplicaes mais complexas. Em muitos casos existem dados sigilosos que os usurios no desejam que saiam dos limites fsicos da empresa. Na maioria dos casos isso pode inviabilizar a adoo de uma
60
3.6. DISCUSSO
aplicativo no modelo SaaS que funcione em ambiente multi-tenancy. Uma abordagem para que os provedores de servio no percam clientes nesse perl desenvolver uma aplicao multi-tenancy que fornea algum tipo de integrao com aplicaes externas. Dessa forma o cliente poderia contratar o servio e usar apenas as funcionalidades que no manipulam dados sigilosos, deixando que os dados sigilosos sejam tratados por uma aplicao em seu prprio data center. Em (Mietzner et al., 2009a), os autores apresentam uma abordagem de como combinar diferentes padres multi-tenancy em uma aplicao orientada a servios. Em (Bezemer and Zaidman, 2010) os autores apresentam duas barreiras que pode inuenciar na adoo de multi-tenancy: empresas podem ter receio nanciar o custo inicial de reengenharia de suas aplicaes existentes para multi-tenancy Desenvolvedores de software que mantm a aplicao podem car incomodados com os problemas de manuteno adicionais que a introduo de multi-tenancy pode causar devido ao fato desses novos aplicativos serem altamente congurveis.
3.6
Discusso
Plataformas de SaaS como Salesforce.com permitem que muitas customizaes da aplicao sejam realizadas sem a necessidade de programao atravs da especicao de regras de negcio que so simples o suciente para no-programadores implementarem. Grandes empresas de TI como HP e IBM tem investido bastante nessa rea, isso comprovado com o fato de vrios artigos encontrados durante esse estudo serem escritos por membros dessas empresas. Alm disso, algumas empresas tambm vendem aplicativos que podem ser congurados para executar como SaaS em nuvens privadas; SAP por exemplo, pode ser usado como um SaaS oferecido dentro das empresas. A primeira diculdade encontrada durante as pesquisas foi identicar quais os requisitos de uma aplicao multi-tenancy que so essenciais para sua implementao. Durante a tentativa de identic-los, foi possvel perceber que duas caractersticas chave de multi-tenancy so o auto grau de automao nas atividades de manuteno da aplicao e uma interface amigvel para que o usurio possa realizar suas customizaes, reduzindo ao mximo a necessidade de intervenes por parte de desenvolvedores e administradores de sistema.
61
3.6. DISCUSSO
Durante o a conduo do mapeamento sistemtico foi possvel notar a existncia de muitos trabalhos associados multi-tenancy e armazenamento de dados. Propostas de mtodos, tcnicas e at um SGBD multi-tenancy foi proposto. Embora esse seja o campo de multi-tenancy onde mais se encontrou publicaes, ainda um campo onde existem muitos pontos de melhoria, principalmente pelo fato do armazenamento de dados inuenciar diretamente no tempo de resposta de todas as operaes que manipulam dados. Vrios experimentos foram realizados com as abordagens existentes para armazenamento de dados em aplicaes multi-tenancy mas no foi encontrada na literatura um consenso sobre qual abordagem a melhor. Migrao de dados, modelagem dos dados, tempo de resposta, armazenamento distribudo, integrao com ferramentas de BI, todos esses fatores podem inuenciar na escolha de uma abordagem para armazenamento de dados. Atualmente, novas formas de armazenamento de dados esto surgindo como: HBase1 , Cassandra2 , Hipertable3 , MongoDB4 , CouchDB5 , etc. Esses sistemas armazenam dados de uma forma diferente do usado nos modelos relacionais e compem um movimento chamado NoSQL. Uma lacuna pouco explorada foi a utilizao dessas novas tecnologias no desenvolvimento de aplicaes multi-tenancy, dado que bancos de dados NoSQL surgiram como uma soluo para a questo 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 consequncia da inecincia dos bancos de dados relacionais em lidar com a tarefa de manipulao de grandes volumes de dados. Vale ressaltar que o modelo relacional foi proposto na dcada de 70, quando as aplicaes de banco de dados caracterizavam-se por lidar com dados estruturados, ou seja, dados que possuem uma estrutura xa e bem denida, e esse no o caso de aplicaes multi-tenancy que podem ser customizadas(Lscio et al., 2011). O crescente surgimento de APIs(DuVander, 2011) web mostra que a utilizao desse tipo de abordagem faz muito sentido no contexto de aplicaes web e SaaS. Um exemplo de sucesso o Tweetdeck, uma aplicao cliente do twitter que foi desenvolvida utilizando a API disponibilizada pelo twitter aos desenvolvedores e teve grande aceitao pelos usurios do twitter.com. O valor real da aquisio no foi declarado, mas especula-se algo em torno de 40 milhes de dlares(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. DISCUSSO
Outro exemplo de sucesso o marketplace desenvolvido pela Salesforce, o AppExchange, que possui mais de 1 milho de aplicaes cadastradas, desde extenses da aplicao de CRM do Salesforce at aplicaes para outros propsitos. Exemplos como esse mostram quo vantajoso trazer desenvolvedores independentes para o mercado de SaaS. A realidade que para entender o campo de customizao de aplicaes multi-tenancy necessrio entender o contexto no qual essas aplicaes esto surgindo. Dado que no possvel atender com uma nica aplicao a necessidade de todos os clientes, como j foi mencionado anteriormente, enfrenta-se em aplicaes multi-tenancy o desao de permitir de alguma forma que o cliente adicione novas regras e customize a aplicao ou faa extenses que auxiliem na soluo de seus problemas especcos. Durante esse trabalho foram encontrados vrios estudos relacionados ao tema, muitos deles utilizando trabalhando com metadados, orientao a aspectos, SOA, etc. Customizao de aplicaes j um tema bastante explorado pelos pesquisadores da rea de linha de produtos de software. Basicamente podemos considerar que a customizao de aplicaes multi-tenancy equivalente a variabilidade de linha de produtos de software em tempo de execuo. Uma iniciativa de customizao de aplicaes 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 alocao de recursos, monitoramento, escalabilidade e performance so requisitos no funcionais que podem at ser ignorados em uma aplicao comum, mas que so de vital importncia em aplicaes multi-tenancy, principalmente se a aplicao estiver hospedada em um ambiente de cloud onde a tarifao paga por consumo. Nesses ambientes uma aplicao mal projetada pode levar a custos operacionais to altos que podem inviabilizar o funcionamento da aplicao, dado o valor que dever ser pago para manter a infraestrutura de servidores funcionando. Por outro lado, em uma contexto onde a alocao de recursos feita de forma inteligente, o monitoramento indica quais recursos esto ociosos e quais os gargalos da aplicao, a elasticidade(capacidade de aumentar e diminuir os recursos de hardware) realizada de forma automtica e inteligente, os custos operacionais podem ser diminuidos drasticamente se a aplicao consumir somente o que estritamente necessrio para atender aos requisitos de SLA denidos aos cliente. A realizao desse mapeamento foi de crucial importncia para vericar a viabilidade de implementao de uma soluo multi-tenancy. Numa deciso como essa necessrio
63
3.7. AMEAAS A VALIDADE
vericar no s a aderncia da tecnologia com relao a necessidades imediatas, mas tambm para necessidades que podem surgir futuramente. O mapeamento sistemtico ajudou a identicar que customizao, armazenamento de dados, segurana e alocao de recursos so pontos crticos no desenvolvimento de uma aplicao multi-tenancy e precisam ser implementados de forma eciente para o bom funcionamento da aplicao. O cruzamento de dados realizado na Figura 3.5, ajudou a identicar a ausncia de uma ferramenta que desse suporta migrao de sistemas single-tenant para multi-tenancy. Com isso identicou-se uma lacuna na rea que pode inviabilizar em alguns casos a adoo de uma abordagem multi-tenancy, dado o fato de vrias empresas j possurem sistemas legados com dados pr-cadastrados. Esses dados, na maioria dos casos so artefatos de negcio de importncia muito elevada para serem descartados. No Captulo 4 poder-se- vericar que foi necessrio a implementao de uma ferramenta para auxiliar na migrao de um sistema single-tenant para multi-tenancy. Solues para requisitos futuros da aplicao que ser descrita no Captulo 4 tambm poderam ser identicadas, como o caso da possvel adoo de SOA para realizar a integrao de sistemas, mtodos para otimizao de performance em aplicaes multitenancy, solues para monitoramento de aplicaes multi-tenancy, virtualizao de aplicaes, etc. O Captulo 4 apresenta detalhadamente como cada problema foi resolvido e como as informaes obtidas apartir do mapeamento sistemtico foram utilizadas para chegar uma soluo.
3.7
Ameaas a validade
Existem alguns fatores identicados no processo de mapeamento sistemtico que foram considerados ameaas a validade do trabalho. Esses fatores so descritos a seguir: Questes de pesquisa: o conjunto de questes denido pode no cobrir de forma satisfatria a rea de desenvolvimento de aplicaes multi-tenancy. Para mitigar essa ameaa, foram realizadas reunies de discusso com outros pesquisadores da rea para calibrar as questes. Dessa forma, mesmo que no se tenha selecionado as melhores questes de pesquisa, tentou-se chegar o mais prximo possvel disso. Abrangncia da pesquisa: no possvel garantir que todos os estudos relevantes foram selecionados. possvel que algum estudo relevante no tenha sido selecionado no processo de pesquisa. Mitigou-se essa ameaa realizando o processo de reviso dos trabalhos mais de uma vez em momentos diferentes.
64
Qualidade da avaliao: durante o agrupamento dos trabalhos nas facetas denidas pode haver ocorrido alguma classicao errada, dado que a classicao ocorre baseada exclusivamente na leitura dos artigos realizada pelo autor desse trabalho. Para minimizar esse risco, aps a classicao dos trabalhos, foi realizada uma segunda leitura em cada trabalho para vericar 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 sinnimos e existe a possibilidade da ausncia de algum desses sinnimos inuenciar na pesquisa, de forma que algum trabalho relevante no tenha sido encontrado com as strings de busca denidas. Para mitigar esse problema foi foi realizado uma pesquisa inicial que teve o objetivo de auxiliar na familiarizao com os termos da rea.
3.8
Consideraes Finais
Este captulo apresentou um mapeamento sistemtico realizado na rea de multi-tenancy. Inicialmente foi apresentado a metodologia utilizada para conduzir o mapeamento e a seguir sua aplicao e os resultados encontrados no mapeamento. Nenhum mapeamento sistemtico na rea foi encontrado, embora tenha-se encontrado vrios estudos sobre o tema. Durante a conduo do mapeamento foram denidas 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 esforos em um desses campos ou mais. Foram identicados os campos mais pesquisados e as principais descobertas em cada um deles. Por m, baseado em evidncias encontradas nos estudos foram respondidas as quatro perguntas denidas no incio do mapeamento sistemtico. O captulo a seguir apresenta como os conhecimentos adquiridos atravs do mapeamento sistemtico foram utilizados durante o desenvolvimento de uma aplicao multi-tenancy em uma empresa real.
65
4
Aplicao na Indstria
Como um dos objetivos desse trabalho vericar a aplicabilidade dos conceitos relacionados multi-tenancy no mercado de software, esse captulo apresenta um case de desenvolvimento de uma aplicao SaaS multi-tenancy em uma empresa startup que atua no segmento de reuso de software. No decorrer desse captulo sero apresentadas as experincias adquiridas da juno dos conhecimentos obtidos atravs do mapeamento sistemtico descrito no captulo anterior e dos resultados da aplicao desses conhecimentos na prtica. Nesse captulo a seo 4.1 apresenta o cenrio no qual a aplicao multi-tenancy foi desenvolvida e seus requisitos, a seo 4.2 descreve a metodologia utilizada para combinar mapeamento sistemtico e desenvolvimento da aplicao. A arquitetura adotada na aplicao e a metodologia para sua denio so descritos na seo 4.3 ,j a seo 4.4 descreve como foi realizado o processo de migrao de dados da aplicao legada para a nova aplicao no modelo multi-tenancy e por m a seo 4.5 apresenta as consideraes nais do captulo.
4.1
Problema
O objetivo do projeto era desenvolver uma ferramenta de suporte a atividades de engenharia de software para auxlio no processo de desenvolvimento de SPL(Software Product Lines). A verso inicial da ferramenta dever permitir ao usurio cadastrar informaes relacionadas ao levantamento de requisitos e denio de escopo de uma linha de produtos de software. Posteriormente seria adicionado ferramenta funcionalidades relacionadas ao armazenamento e busca de assets reutilizveis desenvolvidos pelos usurios da ferramenta. No contexto de SPL, onde uma grande variedade de produtos so 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 manuteno da rastreabilidade e variabilidade entre os diferentes artefatos. Esse metamodelo representado utilizando a notao UML na Figura 4.1. O metamodelo dividido em cinco sub-modelos, que descrevem funcionalmente a aplicao que ser desenvolvida: Gerenciamento de Projeto: mdulo da aplicao responsvel por armazenar informaes sobre o projeto da SPL, suas fases do desenvolvimento, tarefas, membros responsveis por essas tarefas e o papel de cada um no projeto. Alm disso, podem ser documentadas as decises de projeto, descrio de alternativas essas decises, justicativa para decises, notas explicativas, membros da equipe envolvidos na deciso e momento em que a deciso 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 denidos, diculdades de estimar esforo e recursos necessrios para o desenvolvimento de software. Alm disso, dependncia de habilidades individuais e mudana nos requisitos devido mudanas na necessidade dos clientes, tambm pode inuenciar nos riscos associados ao projeto. Escopo: agrupa as funcionalidades para auxiliar na identicao e documentao das features de uma SPL. Em alguns casos pode ser necessrio construir uma rvore contendo todos os tipos de features existentes em um produto como features mandatrias, alternativas ou opcionais. Alm disso necessrio gerenciar relacionamentos entre features, por exemplo, features obrigatrias(identicadas apartir de relaes de dependncia entre features) e excludentes(features que no podem co-existir em um mesmo produto). Requisitos: gerencia os requisitos e casos de uso associados a cada feature e a cada mdulo da aplicao documentada. Durante a elicidao, o mdulo suporta variaes de requisitos entre os produtos derivados apartir da SPL documentada e apresentar o que o sistema dever fazer e como as variaes sero suportadas. Teste: gerencia como os casos de teste do sistema interagem com os outros artefatos. Os casos de teste so derivados dos casos de uso documentados. Essa estratgia
67
4.2. METODOLOGIA
permite que cada mudana em casos de uso ou pontos de variao da SPL possam ser propagadas para os casos de teste. Alm dos requisitos do metamodelo, ainda existiam alguns fatores que poderiam inuenciar nas decises de projeto: A aplicao seria incialmente provida como SaaS para um grupo de 20 clientes, que validariam os requisitos da aplicao durante o uso da verso beta; Os clientes deveriam ter a possibilidade de contratar e usar a aplicao sem nenhuma interveno manual da empresa provedora do servio; Cada cliente deveria poder gerenciar seus prprios usurios; A aplicao iria executar em um ambiente virtualizado com 613MB de memria e 30GB de armazenamento; Os requisitos da aplicao deveriam ser elicidados e implementados de forma incremental; A aplicao deveria aproveitar o mximo de recursos possvel. Diante das caractersticas citadas acima, multi-tenancy apresentou-se como uma alternativa vivel para esse projeto. A necessidade de prover uma aplicao web que o cliente contratasse sem a interveno do provedor de servio fortaleceram a escolha da abordagem SaaS. J recursos limitados de hardware e a necessidade de prover a aplicao para 20 clientes que poderiam ter vrios usurios utilizando simultaneamente, exigiam o mximo de otimizao no uso do hardware. Dentre os 3 tipos de SaaS apresentados na seo 2.2, multi-tenancy apresentou-se como a melhor escolha por permitir a melhor abordagem para otimizao de recursos e facilidade de prover software como servio com modelo de pagamento por uso. Essa uma aplicao real que foi desenvolvida e entrou em produo antes da apresentao desse trabalho. As sees a seguir descrevem como essa aplicao foi desenvolvida
4.2
Metodologia
Para conduzir a etapa de desenvolvimento de um aplicativo na indstria seguiremos o processo denido na Figura 4.2. De acordo com a gura, a primeira etapa consiste em denir 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. DEFINIO DE ARQUITETURA
Figura 4.2 Metodologia utilizada para desenvolvimento de aplicao na indstria(Fonte: Elaborao prpria)
utilizadas informaes obtidas atravs do resultado do mapeamento sistemtico e da lista de requisitos da aplicao. Apartir dessas informaes foi possvel identicar as propostas de arquitetura que mais se adequam aos requisitos da aplicao. A segunda etapa foi escolher as tecnologias que seriam utilizadas para a implementao dos requisitos funcionais e no funcionais da aplicao, alm da migrao dos dados j cadastrados que anteriormente eram manipulados por uma aplicao legada. Durante a etapa de implementao foi adotado SCRUM como metodologia de desenvolvimento, o que facilitou a realizao de releases incrementais e rpidos. Vantagens da adoo de SCRUM com metodologia para gerenciamento gil de produtos SaaS pode ser visto em (Agarwal, 2011). Por m, na terceira etapa realizado a coleta de feedback dos usurios, de forma que seja possvel melhorar a aplicao no tocante a requisitos funcionais e no-funcionais. Uma sequncia de vrios ciclos compostos da etapa de "implementao"e "validao da aplicao", realizada com o objetivo de proporcionar uma evoluo incremental do produto.
4.3
Denio de Arquitetura
Modelos arquiteturais possuem um importante papel como ponte entre os requisitos do sistema e a sua implementao, alm de serem considerados o primeiro conjunto de decises 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 solues computacionais. Isso ocorre devido s facilidades que ela oferece como, por exemplo, a possibilidade em abstrair informaes,
70
o que diminui a complexidade e facilita o entendimento da soluo. Nos ltimos anos, arquitetura de software tem sido cada vez mais importante devido ao aumento da complexidade das aplicaes que vem sendo desenvolvidas. Nos ltimos tempos, aplicaes tem se tornado mais complexas, difceis 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 possvel reusar uma arquitetura de software existente, necessrio efetuar uma avaliao dessa arquitetura para vericar se ela adequada ao cenrio onde pretende-se aplic-la. O processo de avaliao de arquitetura de software tipicamente inclui a aplicao de um mtodo de avaliao. Existem diversos mtodos disponveis com diferentes tcnicas e objetivos como: SAAM, ATAM, ALPSM, SBAR, SALUTA, SAAMCS, ESAAMI, ASAAM, SACAM e DoSAM(Graham and Roy, 2008). Contudo, a anlise dos mtodos identicados e resultados obtidos por surveys (Babar et al., 2004; Dobrica and Niemela, 2002) identicaram quatro problemas principais: grande subjetividade dos mtodos, elevado custo de aplicao, diculdades para avaliar simultaneamente o atendimento a vrios requisitos de qualidade e contexto limitado para a aplicao de alguns dos mtodos. O elevado custo de aplicao de mtodos de avaliao est relacionado ao destes terem sido desenvolvidos para projetos de grande porte, que geralmente possuem alta disponibilidade de recursos. Com isso, somente um pequeno nmero de empresas conseguem aplicar de forma correta as avaliaes (Lattanze, 2005). Diante de tantos mtodos de avaliao era necessrio identicar o mtodo mais adequado ao contexto do projeto. Babar (Babar and Gorton, 2009) realiza um survey que tem o objetivo de identicar como as tcnicas de reviso de arquitetura esto sendo utilizadas no mercado. Segundo seu trabalho, as quatro tcnicas mais comuns aplicadas para reviso de uma arquitetura de software so baseadas em experincia, prototipagem, tcnicas baseadas em cenrios e tcnicas baseadas em checklists. Aps a anlise das tcnicas de reviso de arquitetura identicou-se que a quantidade de pessoas necessrias para realizar uma reviso de arquitetura, a quantidade de documentao que precisaria ser gerada e o esforo necessrio para realizar as atividades inviabilizariam a adoo dessas tcnicas por uma equipe pequena, como era o caso da startup onde essa aplicao foi desenvolvida. Para realizar a denio da arquitetura que seria adotada foi criada uma adaptao do processo apresentado em (Meier et al., 2008). Os passos para denio e avaliao de arquitetura utilizados nesse trabalho so descritos a seguir:
71
1. Identicao dos objetivos da Arquitetura: nessa etapa os objetivos da arquitetura pretendida so claramente denidos. Objetivos claros ajudam a focar na resoluo do problema e identicar quando uma arquitetura adequada foi encontrada. 2. Viso geral da aplicao: nessa etapa o objetivo entender o tipo de aplicao, restries de implantao, identicar estilos arquiteturais importantes e determinar tecnologias relevantes para a implementao de uma possvel soluo. 3. Pontos Crticos: so identicados pontos crticos da arquitetura da aplicao para entender as reas onde os erros normalmente acontecem. Os prontos so agrupados em termos de atributos de qualidade e interesses transversais. 4. Possveis Solues: apartir das informaes obtidas at esse ponto possvel vericar a existncia de arquiteturas pr-existentes que possivelmente possam ser adotadas para a soluo pretendida. A escolha de arquiteturas candidatas leva em considerao a adequao aos requisitos funcionais e no-funcionais da aplicao, pontos crticos e restries de deployment. 5. Proposta de soluo de arquitetura: caso existam arquiteturas pr-existentes ou estilos arquiteturais que sejam adequados ao contexto, nessa fase realizado a escolha de uma proposta. Caso no seja encontradas propostas de arquiteturas, uma arquitetura deve ser denida baseado nos requisitos funcionais, no-funcionais e pontos crticos. 6. Prototipagem: nessa etapa desenvolvido um pequeno prottipo que servir como prova de conceito e tem como objetivo identicar possveis problemas de implementao durante a adoo da proposta selecionada. 7. Avaliao dos resultados: Aps a implementao do prottipo, os pontos positivos e negativos da abordagem so apresentados de forma a vericar se a soluo de arquitetura implementada no prottipo adequada para o produto a ser desenvolvido.
4.3.1
Identicao dos objetivos da Arquitetura
Diante de um cenrio onde era necessrio atender a interesses dos usurios nais, clientes, desenvolvedores e do prprio provedor de servio, foi necessrio identicar quais eram esses interesses que poderiam inuenciar no projeto:
72
Usurios nais da aplicao: interessados em requisitos funcionais corretos e usabilidade Clientes do provedor de servio: preo acessvel, atendimento aos requisitos funcionais do negcio, retorno de investimento Desenvolvedor: separao entre requisitos multi-tenancy e requisitos funcionais da aplicao, facilidade de execuo de testes. Provedor de servios: uso eciente de recursos computacionais, prazo e custo. Apartir dos interesses dos stakeholders e dos requisitos funcionais e no funcionais, denimos o objetivo que nossa arquitetura deveria alcanar: Consumo de recursos computacionais otimizados; Independncia entre requisitos funcionais e requisitos relacionados a implementao de multi-tenancy(autenticao e autorizao, congurabilidade, acesso a dados, etc...); A aplicao 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 mdulos relacionados aos requisitos multitenancy sejam reutilizados em projetos futuros; A arquitetura deve facilitar a integrao da aplicao SaaS com outras aplicaes utilizadas pelo cliente;
4.3.2
Viso geral da aplicao
Apartir dos requisitos funcionais identicou-se 3 pers de atores necessrios para o funcionamento da primeira verso da aplicao: Usurio Final: o usurio da aplicao responsvel por cadastrar as informaes sobre as linhas de produto de software documentadas atravs de nossa aplicao. Esse usurio poder acessar funcionalidades relacionada a gerencia de projetos, gerencia de risco, gerencia de escopo, gerencia de requisitos e gerencia de testes.
73
Figura 4.3 Diagrama de Caso de Uso da Aplicao Alexandria(Fonte: Elaborao prpria)
Consumidor de SaaS: o usurio do lado do cliente que possui maior privilgio no uso da aplicao. Alm do acesso a todas a funcionalidades disponibilizadas para o perl Usurio Final, esse perl associado ao usurio que contrata nosso software atravs de uma interface web. Esse usurio responsvel pelo gerenciamento dos outros usurios(cadastro, excluso de usurios, alterao de dados do usurio) Provedor de servio: poder ter acesso funcionalidades de gerenciamento e monitoramento dos tenants da aplicao. A Figura 4.3 apresenta um diagrama de caso de uso que tem o objetivo de apresentar uma viso geral dos requisitos funcionais da aplicao. Esse diagrama foi construdo apartir das informaes j descritas na seo 4.1. Para implementar nossa aplicao, identicou-se alguns estilos arquiteturais em (Team, 2009), que poderiam servir como base para a denio de arquitetura da aplicao: Cliente/Servidor: como o sistema deveria funcionar na web esse estilo arquitetural apresentou-se como uma soluo a ser escolhida. Nele apresentado o conceito de cliente e servidor, onde o servidor recebe requisies de vrios clientes.
74
Baseado em componentes: esse estilo arquitetural decompe o projeto de software em componentes funcionais ou lgicos que expem interfaces de comunicao bem denidas que contenham mtodos, eventos e propriedades. Baseado em camadas: esse estilo arquitetural focado no agrupamento funcional da aplicao em camadas distintas, empilhadas verticalmente. A funcionalidade em cada camada est relacionada a um papel ou responsabilidade comum. A comunicao entre camadas explcita e fracamente acoplada. Orientado a Objetos: estilo arquitetural baseado no paradigma orientado a objetos, no qual ocorre a diviso de responsabilidades do sistema em objetos reusveis e coesos, que contm dados e comportamentos relevantes. Uma proposta nal de arquitetura pode sofrer inuncia de vrios estilos arquiteturais. A deciso de qual estilo arquitetural pode inuenciar a soluo proposta depende de quais benefcios cada estilo pode oferecer. A Tabela 4.1 apresenta os pontos que foram considerados quando denimos que os quatro estilos arquiteturais supracitados poderiam beneciar nossa soluo nal. Escolhidos os estilos arquiteturais que seriam tomados como base, o proximo passo seria escolher as tecnologias que seriam utilizadas para a implementao da soluo. Um ponto levado em considerao aqui foi o fato dos desenvolvedores j possuirem experincias prvias com desenvolvimento de aplicaes 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 implementao tecnologias ou propostas baseadas nessa plataforma. Dado que um dos objetivos do projeto seria criar uma soluo que proporcionasse o mximo de reuso possvel, encontrou-se 2 abordagens relevantes. A primeira abordagem seria o desenvolvimento de uma aplicao web, cuja modularizao seria implementada utilizando OSGi (Kaegi and Deugo, 2008; Stoev and Dimov, 2008). A segunda abordagem seria a utilizao de Grails1 , um framework de desenvolvimento de aplicaes web que utiliza uma abordagem baseada em plugins, na qual vrias funcionalidades da aplicao podem ser implementadas como plugins reutilizveis. Antes da escolha de qualquer abordagem deve-se levar em considerao alguns pontos crticos que so apresentados na seo seguinte.
1 http://grails.org
75
Estilo Arquitetural
Benefcios A aplicaco dever suportar vrios clientes.
Cliente/Servidor
A aplicaco dever ser acessada atravs do browser. Centralizao de armazenamento de dados, backup e funcionalidades de gerenciamento. A aplicao 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 plugvel que permita, com o mnimo de esforo possvel, substituir ou atualizar componentes individuais. Diminuio da complexidade da aplicao atravs do agrupamento funcional em diferentes reas de interesse.
Baseado em camadas
Melhorar a manutenibilidade e extensibilidade da aplicao atravs da minimizao de dependencias. Possibilidade de implementao de regras de negcio complexas e congurveis, que poderiam ser agrupadas em uma camada especca. Capacidade de modelar a aplicao baseada em objetos e aes do mundo real.
Orientado a Objetos
Necessidade de encapsular lgica e dados juntos em componentes reusveis.
Tabela 4.1 Estilos arquiteturais escolhidos e suas inuncias em nossa arquitetura
76
4.3.3
Pontos Crticos e Solues
Para denir as tecnologias e a proposta de arquitetura mais adequadas para nosso caso, foi necessrio denir alguns atributos de qualidade desejveis para nossa aplicao, como pode ser visto na Tabela 4.2. Alm dos pontos crticos considerados, antes de propor qualquer soluo, fez-se necessrio vericar a existncia de propostas de arquitetura para aplicaes multi-tenancy existentes na literatura. Foram analisadas as arquiteturas encontradas durante o mapeamento sistemtico realizado no Captulo 3. Na seo 3.5.2 foram identicados 2 tipos de arquiteturas: denies de arquitetura para aplicaes 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 aplicaes multi-tenancy (Weissman and Bobrowski, 2009; Cheng et al., 2009; Takahashi et al., 2010). Para a escolha da arquitetura de nossa aplicao foram analisadas apenas as propostas de arquitetura para aplicaes. A principal preocupao na escolha seria identicar uma arquitetura que j tivesse sido validada na indstria, que tivesse maior aderncia aos requisitos de nossa aplicao e aos atributos de qualidade denidos. Alm disso era necessrio vericar a possibilidade de atendimento a requisitos futuros de segurana, performance, alocao de recursos, armazenamento de dados, modularizao e todos os outros pontos importantes em uma aplicao multi-tenancy que foram vistos no mapeamento sistemtico. Nem todos esses requisitos foram atendidos de imediato, mas era de fundamental importncia que a abordagem escolhida desse suporte a tais requisitos. Partindo desse princpio a arquitetura escolhida como referncia para nossa implementao foi a apresentada por Bezemer (Bezemer et al., 2010). Embora essa arquitetura tenha sido a escolhida, no foi descartado a possibilidade de utilizao de conceitos e abordagens apresentadas nos outros trabalhos. Outro ponto crtico que j existia uma aplicao legada implementada na linguagem de programao python, que j possua dados pr-existentes. Essa aplicao legada j implementava alguns requisitos do meta-modelo implementado(Cavalcanti et al., 2011), mas no adotava o modelo de Software como Servio(SaaS). Antes da implantao da primeira verso da aplicao seria necessrio realizar a migrao dos dados j cadastrados pela aplicao legada. A separao de interesses entre requisitos relacionados ao negcio principal da aplicao e requisitos inerentes a multi-tenancy tambm um fator crtico que deve ser levado em considerao. A aplicao deveria ser implementada de forma o cdigo
77
de regra de negcio sofresse o mnimo de interferncia possvel do cdigo associado a implementaes de multi-tenancy. A arquitetura escolhida como referncia foi a que melhor se adequou a esse cenrio.
4.3.4
Proposta de soluo de arquitetura
Multi-tenancy afeta quase todas as camadas de uma aplicao tpica e possui um grande potencial para ser implementado como interesse transversal. Para reduzir a complexidade do cdigo, a implementao de requisitos multi-tenancy deve ser separada da lgica de negcio o mximo possvel. Caso contrrio, a manuteno pode se tornar um pesadelo, porque: Implementar cdigo de requisitos da arquitetura multi-tenancy juntamente com a lgica de negcio dos tenants, exige que todos os desenvolvedores sejam reeducados para entenderem os conceitos de multi-tenancy; Misturar multi-tenancy com cdigo de lgica de negcio dos tenants leva ao aumento da complexidade da implementao, pois mais difcil manter o controle de onde o cdigo multi-tenancy introduzido. Estes problemas podem ser superados integrando cuidadosamente multi-tenancy na arquitetura. No restante desta seo, descrevemos os componentes da arquitetura abordada por Bezemer (Bezemer et al., 2010) para implementao de multi-tenancy como um interesse transversal. A Figura 4.4 apresenta a descrio dessa aplicao e as subsees seguintes descrevem cada componente da aplicao. Autenticao Pelo motivo de uma aplicao multi-tenancy ter apenas uma instncia da aplicao e do banco de dados, todos os tenants usam o mesmo ambiente fsico. A m de oferecer a customizao do ambiente e ter certeza de que os tenants podem acessar somente os seus prprios dados, tenants devem ser autenticados. Enquanto autenticao de usurio , possivelmente, j presente na aplicao de destino, um mecanismo separado de autenticao de tenants especcos pode ser necessrio, por duas razes: (1) geralmente muito mais fcil introduzir um mecanismo de autenticao adicional, do que mudar um j existente, e (2) autenticao de tenants permite que um nico usurio faa parte de mais do que uma organizao lgica, o que estende a idia de autenticao de usurios com "grupos".
78
Atributo Disponibilidade
Consideraes Como planejar backups e restauraes Como projetar a aplicao para atualizaes em tempo de execuo Como isolar a aplicao de dependencias externas Como criar um caminho Como criar um plano para atualizao de tecnologias Como evoluir a aplicao sem prejudicar o cliente Como tratar regras de negcio dinamicamente Como tratar dinamicamente interface com o usurio Como tratar mudanas em dados e lgica de processamento Como tratar mudanas em requisitos de negcio
Integridade Conceitual
Flexibilidade
Interoperabilidade
Como prover interoperabilidade entre aplicaces enquanto elas evoluem Como isolar sistemas atravs de interfaces de servio Como reduzir dependncias entre camadas e componentes Como implementar uma arquitetura plugvel Como monitorar operaes e sade do sistema Como modicar o comportamento do sistema baseado em sua carga Como determinar uma estratgia de caching Como gerenciar recursos ecientemente Como reduzir duplicaode cdigo entre componentes e camadas Como compartilhar funcionalidades atravs de sistemas Como compartilhar funcionalidades atravs de componentes e camadas Como ajustar a aplicao para aumento e diminuio de carga Como lidar com os picos no trafego e carga Como lidar com autenticao e autorizao Como proteger-se de entradas mal intencionadas Como proteger dados sensveis Como projetar a aplicao para testabilidade Como projetar testes de unidade Como evitar armadilhas comuns de experincia com usurio
Manutenibilidade
Gerenciabilidade
Performance
Reusabilidade
Escalabilidade
Segurana
Testabilidade
Usabilidade
Tabela 4.2 Atributos de qualidade desejveis na arquitetura
79
Figura 4.4 Arquitetura de Referncia adotada(Fonte: (Bezemer et al., 2010))
Congurao Em uma aplicao multi-tenancy a customizao deve ser possvel atravs de congurao. A m de permitir que o usurio tenha uma experincia como se ele estivesse trabalhando em um ambiente dedicado, necessrio permitir pelo menos os seguintes tipos de congurao: Estilo de Layout(Layout Style): O componente de congurao de estilo de layout permite o uso de temas e estilos especcos. Congurao Geral (General Conguration) O componente de congurao geral permite a especicao de conguraes especcas, como conguraes de chave de criptograa e detalhes do perl pessoal. Entrada e sada de arquivo (File I/O) O componente de congurao de I/O de arquivo permite a especicao de caminhos de arquivos, que podem ser usados para, por exemplo, gerao de relatrio. Fluxo de trabalho (Workow) O componente de congurao de uxo de trabalho permite a congurao de uxos especcos. Por exemplo, congurao de uxos necessria em uma aplicao de planejamento de recursos empresariais -
80
ERP, em que o uxo de requisies pode variar signicativamente para diferentes companhias. Banco de dados (Database) Em uma aplicao multi-tenancy h uma grande exigncia para o isolamento dos dados. Porque todos os tenants usam a mesma instncia de um banco de dados necessrio ter certeza de que eles podem acessar somente seus prprios dados. Atualmente sistemas de gerenciamento de dados (Data Base Management Systems - DBMS) de prateleira no so capazes de lidar com multi-tenancy, isso deve ser feito em uma camada entre a camada lgica de negcios e o pool de banco de dados de aplicaes. As principais tarefas dessa camada so as seguintes: Criao de novos tenants no banco de dados: Se a aplicao armazena ou recupera dados que podem ser de tenants especcos, tarefa da camada de banco de dados criar os registros do banco de dados correspondente quando um novo tenant se inscreveu para a aplicao. Adaptao de consulta: A m de prover um isolamento de dados adequado, a camada de banco de dados deve ter certeza que consultas so ajustadas de forma que cada tenant possa acessar somente seus prprios registros. Balanceamento de carga: Para melhorar o desempenho de uma aplicao multi-tenancy necessrio um balanceamento de carga eciente para o pool de banco de dados. Note que qualquer acordo feito no SLA de um tenant e quaisquer restries impostas pela legislao do pas onde o tenant est localizado deve ser satisfeita. Por outro lado, nossa expectativa a de que possvel criar algoritmos de balanceamento de carga mais ecientes usando as informaes coletadas sobre as caractersticas de funcionamento dos tenants.
4.3.5
Tecnologias
Aps a escolha de uma arquitetura de referncia para ser adotada por nossa aplicao, tem-se a necessidade de escolher as tecnologias que sero adotadas para a implementao. Devido ao perl da equipe de desenvolvimento optou-se por escolher tecnologias que executassem na plataforma Java para aproveitar a experincia da equipe. Durante a
81
escolha dessas tecnologias avaliou-se a possibilidade do uso de JSF2 , Struts 23 , Spring Framework4 e Grails5 . Apartir de reunies com os envolvidos observou-se que Grails apresentava um conjunto de recursos que poderiam dar produtividade para a equipe de desenvolvimento que no foram encontrados nas outras tecnologias como gerao de CRUD (Create, Read, Update e Delete), arquitetura baseada em plugins que permite a criao e reuso de componentes, e total integrao 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 descrio visual da arquitetura do Grails apresentada na Figura 4.5. O Grails foi projetado para desenvolver aplicaes CRUD de forma simples e gil, utilizando o modelo de "escrever cdigo por conveno"introduzido pelo Ruby on Rails. O Grails prope-se a trazer a produtividade do Ruby on Rails para a plataforma Java, porm ele possui uma grande vantagem, j que baseado na linguagem Groovy. Groovy (padronizado pela JSR-241) uma linguagem dinmica e gil para a plataforma Java, que possui muitas caractersticas de linguagens de script como Ruby, Python e Smalltalk, e alm disso aplicaes Groovy podem utilizar classes Java facilmente. Linguagens de script esto ganhando cada vez mais popularidade, devido a quantidade reduzida de cdigo fonte necessrio para implementar determinadas funcionalidades, se comparado com uma implementao em Java. A aplicao que est sendo desenvolvida, em particular se beneciar da capacidade de denir mtodos e propriedades em tempo de execuo, disponibilizado pela linguagem Groovy. Essa caracterstica da linguagem Groovy chamada de metaprogramao. Em uma linguagem esttica como Java, o acesso a uma propriedade ou invocao de um mtodo resolvido em tempo de compilao. Em comparao, Groovy no resolve o acessos propriedades ou invocao de mtodos at que a aplicao seja executada (Richardson, 2009). Uma aplicao que utiliza essa linguagem pode dinamicamente denir mtodos ou propriedades em tempo de execuo, isso vai de encontro necessidade de customizao das aplicaes, dado que, com a utilizao desse recurso, pode-se adicionar atributos e customizar comportamentos de um tenant especco futuramente. Outro ponto que inuenciou 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
Figura 4.5 Arquitetura do Grails Framework(Fonte: (Judd et al., 2008))
em plugins. Grails no se prope a ter todas as respostas e solues para o desenvolvimento de aplicaes web. Ao invs disso, ele prov uma arquitetura baseada em plugins e um repositrio mantido pela comunidade de desenvolvedores onde possvel encontrar plugins que implementam as mais diversas funcionalidades como segurana, AJAX, teste, busca, gerao de relatrios, web services, etc. Essa abordagem proporciona o reuso e permite que funcionalidades de difcil implementao possam ser adicionadas na aplicao de forma bastante simples. Alm das tecnologias relacionadas programao, foi necessrio 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 integrao com vrias ferramentas de relatrios, o que poderia facilitar futuras extraes de dados para os clientes.
4.3.6
Prototipagem
Apartir da escolha da arquitetura de referncia, das tecnologias a serem adotadas e da diviso dos mdulos da aplicao chegou-se a proposta de arquitetura apresentada na Figura 4.6. Em nossa proposta a nossa aplicao possui 5 mdulos associados lgica de negcio da aplicao, esses mdulos foram descritos anteriormente na seo 4.1. Foi adotado o Framework Grails para auxlio ao desenvolvimento da aplicao web e juntamente com ele foram adotados alguns de seus plugins. Para validar nossa arquitetura foi desenvolvido um prottipo contendo uma parte pequena dos requisitos funcionais da aplicao. Nesse prottipo sero implementados os cadastros de Projeto, Mdulo e Features. A implementao do prottipo tem o objetivo de vericar a viabilidade de implementao e o atendimento dos objetivos da arquitetura.
83
Figura 4.6 Arquitetura da Aplicao(Fonte: Elaborao prpria)
Como mencionado anteriormente na seo 4.3.4, existe uma grande necessidade de separar cdigo de lgica de negcio de cdigo relacionado aos requisitos multitenancy. Com o objetivo de implementar os requisitos multi-tenancy de forma reutilizvel, a soluo foi implementar esses requisitos como um plugin do Grails, dessa forma aplicaes futuras poderiam se beneciar do cdigo implementado. Uma vantagem do uso dessa abordagem que dentro de um plugin grails possvel adicionar no s classes implementadas em Groovy ou Java, mas tambm pginas da camada de viso e outros tipos de arquivo. Antes de implementar os requisitos multi-tenancy como plugin foi realizado uma pesquisa no repositrio de plugins do Grails para vericar 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 referncia(Bezemer et al., 2010), o componente de autenticao e o componentes de acesso ao banco de dados. Esse plugin implementa a funcionalidade de associar um usurio da aplicao a um tenant especco e alm disso realiza de forma dinmica o ltro dos dados durante uma consulta ao banco de dados, de forma que um usurio da aplicao tenha acesso apenas aos dados vinculados ao seu tenant. A autenticao e controle de acesso pode ser realizado atravs da integrao desse plugin com o Spring Security10 , um framework de controle de acesso bastante utilizado em aplicao Java. O terceiro componente mencionado em nossa arquitetura de referncia o componente de congurao. O objetivo desse componente de gerenciar as conguraes relacionadas a cada tenant e prover funcionalidades de customizao da aplicao para cada tenant. Essa customizao pode ir desde alteraes em interface com o usurio at alterao nas
9 http://multi-tenancy.github.com/grails-multi-tenancy-core 10 http://static.springsource.org/spring-security/site/index.html
84
4.4. MIGRAO DO SISTEMA
classes de negcio, tudo isso realizado de forma dinmica. Durante nossa pesquisa foi encontrado o plugin Dynamic Domain Class11 que proporciona a criao de classes de domnio de forma dinmica, esse plugin ajudou a validar a idia de usar Groovy e Grails para customizar as classes de domnio em tempo de execuo. Durante a implementao detectou-se que o padro de gerao de telas do Grails no satisfazia aos anseios dos usurios quanto forma de interao com o aplicativo. Apartir dessa necessidade foi desenvolvido um plugin para implementar o padro de tela Mestre/Detalhe(Neil, 2010), no implementado nativamente pelo gerador de telas padro do Grails. Durante a implementao desse plugin identicou-se que poderia ser vivel implementar mdulos completos da aplicao como plugins Grails, desde classes de negcio camada de viso. Aps a implementao do prottipo foi realizado a avaliao do prottipo para vericar quais atributos de qualidade desejveis foram atendidos. A Tabela 4.3 apresenta para cada atributo de qualidade uma breve descrio de como ele foi atendido. Aps a avaliao do prottipo foi possvel observar que nossa soluo atendia a 8 dos 12 atributos de qualidade desejados. Quatro atributos de qualidade(disponibilidade, gerenciabilidade, performance, escalabilidade) no puderam ser avaliados durante a implementao do prottipo inicial. A avaliao foi considerada satisfatria, considerando que os quatro atributos de qualidade da arquitetura que no foram atendidos inicialmente no geraram nenhum impedimento para a gerao da primeira verso do aplicativo. Ao m da implementao do prottipo deu-se incio ao desenvolvimento da aplicao real. Ao nal da implementao da primeira verso da aplicao, foi necessrio criar algum mecanismo para migrar os dados j cadastrados pela aplicao legada. Essa atividade ser descrita na seo a seguir.
4.4
Migrao 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 duplicao de informao, construindo novos relacionamentos entre tabelas ou enriquecendo a base de dados com informaes suplementares. Sommerville(Sommerville, 2003) demonstra em sua obra 3 abordagens da engenharia de dados: limpeza de dados, extenso de dados e migrao de dados. Durante a migrao de dados realizado um conjunto de tarefas que tm como objetivo garantir uma melhor qualidade dos dados migrados. Em (Neto
11 http://code.google.com/p/grails-dynamic-domain-class-plugin/
85
ATRIBUTO Disponibilidade Integridade Conceitual Flexibilidade
Interoperabilidade Manutenibilidade
Gerenciabilidade Performance Reusabilidade
Escalabilidade Segurana
Testabilidade
Usabilidade
AVALIAO Como foi adotado um SGBD PostgreSQL, possivel agendar tarefas automticas no servidor para executar backups peridicos. Tanto as entidades de negcio quanto as classes utilitrias da aplicao foram modularizadas em plugins de forma que os interesses da aplicao foram bem denidos e separados. A exibilidade pode ser alcanada atravs do uso das caracterstica de linguagem dinmica existente na linguagem Groovy. Dessa forma possivel criar Entidade de domnio e alterar entidades j existentes em tempo de execuo, caso seja necessrio. O uso de plugins Grails permite que os dados da aplicao possam ser expostos atravs de REST ou Web Services para os usurios. A arquitetura de plugins do Grails facilita a manuteno dos cdigo j que cada plugin pode ser mantido separadamente, reduzindo as dependncias entre os componentes da aplicao. No foi possivel identicar solues para esse atributo durante a implementao do prottipo. No foi possivel identicar solues para esse atributo durante a implementao do prottipo. As partes da aplicao implementadas como plugins podem ser reutilizadas em aplicaes futuras facilmente, sem a necessidade de qualquer adaptao no plugin. No foi possivel identicar solues para esse atributo durante a implementao do prottipo. A autenticao e controle de acesso puderam ser garantidos pelo uso do Framework Spring Security, que pde 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 implementao de testes unitrios que utiliza JUnit, um framework de teste para aplicaes java. Durante a criao de uma classe o Grails Framework j cria uma classe de testes correspondente para otimizar o tempo de desenvolvimento. Grails trabalha com templates para gerao de telas. Embora j possua um template padro, o desenvolvedor pode implementar um template prprio que atenda necessidades especcas de interao com o usurio. O template padro do Grails Framework j implementa alguns padres de usabilidade bem estabelecidos no mercado.
Tabela 4.3 Resultado da aplicao dos critrios de excluso(Fonte: Elaborao prpria)
86
and Passos, 2009) 3 projetos de migrao de dados foram analisados e juntamente com a migrao de dados, identicou-se que foi necessrio realizar a limpeza dos dados para corrigir inconsistncias existentes nos bancos de dados origem. Daniel Aebi e Reto Largo (Aebi and Largo, 1994) apresentam vrios problemas que podem ser encontrados durante o processo de migrao e reengenharia de dados. Alguns desse problemas foram detectados nos projetos de migrao 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-primrias - tabelas so identicadas por diferentes construes de chaves. Por exemplo, uma tabela pode ser identicada 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. Adio ou remoo de atributos podem causar diferenas entre a mesma tabela nos bancos legado e novo. Identicao de objetos - algumas entidade podem aparecer duplicadas no mesmo contexto. Essas duplicatas devem ser identicadas e removidas para evitar redundncia. Conito de limites - o valor de um atributo pode no ser compatvel com o limite denido. Por exemplo, um valor negativo em um campo que deveria conter somente valores positivos. Diferenas de unidade, escala e granularidade - alguns clculos podem ter mudado com o tempo, mas o formato dos dados podem no ter sido ajustados aps isso. As unidades de medida do sistema novo podem diferir do sistema antigo. Codicao - valores de dados freqentemente podem possuir denio de codicao diferente. O novo sistema pode ter um esquema de codicao diferente. Inconsistncia de valores default - para certos campos o valor default denido pode ser diferente. O valor default pode ser 0 em uma base de dados e em outra -1.
87
Durante a avaliao e planejamento do processo de migrao de dados, foram identicadas as seguintes atividades: Migrao de dados entre bancos de dados relacionais com diferenas na modelagem Migrao entre SGBDs relacionais de fabricantes diferentes. O SGBD origem dos dados era MySQL e o SGBD destino PostgreSQL. Correo de inconsistncias existentes na base de dados origem. Converso de alguns dados para permitir a compatibilidade com a nova aplicao. Com o objetivo de agilizar o processo de implementao e execuo do processo de migrao foi necessrio a adoo 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 resoluo de parte dos problemas encontrados durante o processo de migrao e reengenharia de dados, como: mapeamento de esquemas, novas tabelas e relacionamentos, atributos de tipos diferentes, inconsistncia de valor default, dentre outros. O JExodus foi desenvolvido para realizar a migrao de bases de dados tendo como fonte de dados um SGBD, documentos de texto ou objetos Java, de forma que o desenvolvedor efetue a migrao de dados sem se preocupar com detalhes de baixo nvel como conexo com bancos de dados, comandos SQL ou implementar cdigo para ler dados de diversas fontes diferentes. Essa ferramenta no tem como objetivo principal a migrao de dados entre bancos com mesma modelagem de dados e SGBDs diferentes, mas sim a migrao entre bases de dados com modelagens diferentes e SGBDs diferentes, isso foi de grande ajuda para nosso projeto j que existiam diferenas considerveis na modelagem de dados entre o banco de dados origem e destino. Para realizar a tarefa de migrao 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 atravs de um mapeamento, esses dialetos so os mesmos utilizados pelo Hibernate. O JExodus disponibiliza formas do desenvolvedor implementar cdigo java que manipule os dados que esto sendo migrados. Para cada campo migrado possvel implementar uma classe que execute correo ou algum tratamento do valor da coluna que est sendo migrada, essa funcionalidade foi bastante utilizada durante nosso projeto de migrao. Essa abordagem favorece o reuso das classes de tratamento e correo
88
de valores, j que elas podem ser reutilizadas no mapeamento de vrias colunas. Essa funcionalidade da ferramenta permitiu a implementao de cdigo java para realizar a correo de inconsistncias existentes nos dados migrados. Com a utilizao dessa ferramenta, a migrao foi realizada sem grandes diculdades. O produtividade provida pela mesma permitiu que mais tempo do projeto pudesse ser dedicado atividade de vericao da corretude dos dados aps o processo de migrao.
4.5
Consideraes Finais
Esse captulo apresentou as experincias obtidas durante o processo de desenvolvimento de uma aplicao multi-tenancy em uma empresa real. Durante o captulo foi apresentado a metodologia utilizada durante o desenvolvimento, bem como a descrio de cada passo realizado e cada deciso tomada durante todo o processo. No processo de desenvolvimento foram utilizadas vrias informaes obtidas apartir do mapeamento sistemtico realizado no captulo anterior, essas informaes serviram como um guia para os desenvolvedores durante o processo de desenvolvimento. No decorrer desse captulo, foi descrito a escolha de uma arquitetura utilizada como referncia durante a implementao, bem como a escolha de tecnologias e seu uso no projeto. Um prottipo inicial foi implementado com o objetivo de validar a soluo proposta e identicar os atributos de qualidade alcanados com a proposta de implementao apresentada. Ao nal foi descrito como os dados foram migrados aps a concluso da primeira verso da aplicao.
89
5
Concluso e Trabalhos Futuros
Nos ltimos anos muitas empresas tm sado do modelo de entrega de software empacotado para o modelo de fornecimento de software na web. Essas aplicaes entregues atravs da web vo desde emails a calendrios, sistemas colaborativos, publicaes online, processadores de texto simples, aplicaes para negcios e aplicaes para uso pessoal. Com o aumento da popularidade de marketing baseado em web, e-commerce e muitos outros servios baseados em web, mesmo os pequenos negcios tem sido obrigados oferecer seus produtos e servios na internet para serem competitivos no mercado. A caracterstica de compatilhamento de recursos e diminuio 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 mdias empresas. Com o objetivo de validar a aplicabilidade de multi-tenancy e o nvel de maturidade dessa abordagem, foi realizado um mapeamento sistemtico da rea para identicar, atravs de evidncias encontradas em publicaes e resultados de pesquisa, os principais requisitos e interesses associados a esse estilo de arquitetura. Foi realizado um levantamento de um vasto material bibliogrco que ajudou a identicar como diversos problemas associados a multi-tenancy, solues para alguns desses problemas e como seus requisitos seriam implementados. Identicou-se tambm os tipos de pesquisas realizados na rea e as principais contribuies dos trabalhos encontrados. Adicionalmente foi apresentado nesse trabalho o resultado da aplicao dos conceitos encontrados no mapeamento sistemtico, atravs da experincia de desenvolvimento de um aplicativo multi-tenancy em uma indstria de software. Durante essa atividade foi possvel confrontar os resultados encontrados na bibliograa com reais necessidades do mercado, permitindo vericar em ambiente de produo se os resultados encontrados na academia realmente seriam aplicveis no mercado de software. Apresentamos uma proposta de implementao com foco em reuso, que realiza a separao de interesses
90
5.1. CONTRIBUIES
atravs do uso de uma arquitetura de plugins. Isso permitiu que cdigo de lgica de negcio fosse saparado do cdigo de implementao dos requisitos especcos de multitenancy. Conclumos que a implementao de multi-tenancy no s vivel do ponto de vista de negcios como do ponto de vista tcnico, embora ainda existam problemas e pontos de melhoria que devem ser tratados.
5.1
Contribuies
Apresentao uma viso geral da arquitetura multi-tenancy, explicando os principais conceitos teis para entendimento deste trabalho; Identicao de fatores que inuenciam na adoo e desenvolvimento de SaaS multi-tenancy; Classicao dos estudos primrios e dos artefatos encontrados de forma a auxiliar no desenvolvimento de uma aplicao multi-tenancy Combinao dos resultados encontrados no mapeamento sistemtico com uma aplicao prtica na indstria. Organizao dos trabalhos encontrados em categorias que podem auxiliar na denio de uma agenda de pesquisa na rea de multi-tenancy Apresentao e implementao de uma arquitetura multi-tenancy que proporciona um alto grau de reuso dos artefatos implementados. Validao dos conceitos encontrados atravs de experincia prtica na indstria
5.2
Trabalhos Futuros
Considera-se que o presente trabalho atingiu o objetivo proposto. Porm, a abordagem utilizada merece algumas extenses e melhorias na forma de trabalhos futuros, os quais so especicados a seguir: Implementao da arquitetura proposta utilizando outras linguagens seria muito til vericar como a arquitetura seria implementada utilizando outras tecnologias e linguagens de programao, e realizar um comparativo das abordagens.
91
5.2. TRABALHOS FUTUROS
Avaliar benefcios do uso nvens pblicas para implantar multi-tenancy avaliao de quais recursos so oferecidos por provedores de cloud existentes no mercado (Amazon AWS, Google App Engine, Microsoft Azure, etc) que podem ser utilizados em uma aplicao multi-tenancy para garantir disponibilidade, escalabilidade, gerenciabilidade e performance. Avaliar a utilizao de SGBDs no relacionais para armazenamento de dados como o objetivo de aplicaes multi-tenancy prover servios para o mximo de usurios possvel apartir de uma nica instncia da aplicao, SGBDs no relacionais (NoSQL) apresentaram-se como uma boa alternativa para esse propsito. O objetivo aqui validar essa idia apartir de experimentos e implementaes prticas. Migrao de dados do modelo relacional para o modelo no-relacional caso seja identicado que bancos de dados no relacionais so a melhor escolha para armazenamento de dados em aplicaes multi-tenancy, pretende-se estender a ferramenta de migrao de dados utilizada nesse trabalho para suportar a migrao para SGBDs no-relacionais. Estudo emprico de abordagens de customizao de aplicaes multi-tenancy estudo aprofundado e comparativo de abordagens de implementao de customizao e gerenciamento de variabilidade em aplicaes multi-tenancy. Alm disso pretende-se validar, atravs de implementao e de experimentos, algumas das abordagens mais relevantes. Denio de um processo para migrao de aplicaes single-tenant para multi-tenancy pretende-se implementar mais cases de desenvolmento de aplicaes multi-tenancy e migraes de aplicaes single-tenant para multi-tenancy a m de identicar passos e pontos que devem ser levados em considerao durante o processo de migrao. Avaliar empiricamente o grau de reusabilidade dos plugins avaliar atravs de experimentos, o nvel de reusabilidade dos plugins desenvolvidos durante esse trabalho.
92
Referncias Bibliogrcas
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 400411. Springer. Agarwal, P. (2011). Continuous scrum: agile management of saas products. In Proceedings of the 4th India Software Engineering Conference, ISEC 11, pages 5160, 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:16:6, New York, NY, USA. ACM. Amazon (2011). What is AWS? Amazon Company. Disponvel em: <http://aws.amazon.com/pt/what-is-aws>. Acesso em: 10 dez. 2011. Anderson, C. (2006). A Cauda Longa: Porque o Futuro dos Negcios vender menos de mais. Hyperion. Arya, P. K., Venkatesakumar, V., and Palaniswami, S. (2010). Congurability in saas for an electronic contract management application. In Proceedings of the 12th international conference on Networking, VLSI and signal processing, ICNVS10, pages 210216, Stevens Point, Wisconsin, USA. World Scientic 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 11951206, New York, NY, USA. ACM. Aulbach, S., Jacobs, D., Kemper, A., and Seibold, M. (2009). A comparison of exible schemas for software as a service. In Proceedings of the 35th SIGMOD international conference on Management of data, SIGMOD 09, pages 881888, 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
REFERNCIAS BIBLIOGRFICAS
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. Disponvel 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:126: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 8892, 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
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), 4957. 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. Disponvel 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 Wareld, A. (2005). Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation - Volume 2, NSDI05, pages 273286, Berkeley, CA, USA. USENIX Association. Cusumano, M. (2008). The changing software business: Moving from products to services. Computer, 41(1), 20 27.
95
Diana, D., Mauricio, Gerosa, and Aurlio, M. (2010). Nosql na web 2.0: Um estudo comparativo de bancos no-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 workows. 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, 130. 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 301312, 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 252259, 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. Disponvel em: <http://www.gartner.com/it/page.jsp?id=1739214>. Acesso em: 10 dez. 2011. Geelan, J. (2009). Twenty-one experts dene cloud computing. Cloud Computing Journal, 2009, 15. 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
Graham, T. C. N. and Roy, B. (2008). Methods for evaluating software architecture: A survey. Technical Report 2008-545, School of Computing Queens 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 Scientic Research, 65(4), 601610. Hasselmeyer, P. and dHeureuse, 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. Hfer, C. and Karagiannis, G. (2011). Cloud computing services: taxonomy and comparison. Journal of Internet Services and Applications, 2, 8194. 10.1007/s13174-0110027-x. Huang, J. (2011a). Amazon s3s amazing growth. Cloud Computing Journal. Disponvel 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. Disponvel 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
Jacobs, D. and Aulbach, S. (2007). Ruminations on multi-tenant databases. BTW Proceedings, 103(Btw), 514521. 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, ICWE10, pages 445459, 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 688693, 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), 311.
98
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, 8192. 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 633648, 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. Disponvel 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 611615, Washington, DC, USA. IEEE Computer Society.
99
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 649663, 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 101110, 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. Lscio, B. F., Oliveira, H. R. d., and Pontes, J. C. d. S. (2011). Nosql no desenvolvimento de aplicaes web colaborativas. VIII Simpsio 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. Disponvel 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 denition of cloud computing. National Institute of Standards and Technology, 53(6), 50. Mietzner, R., Leymann, F., and Papazoglou, M. (2008). Dening composite congurable saas application packages using sca, variability descriptors and multi-tenancy patterns.
100
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 131140, 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 1825, 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. Disponvel 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 migrao de dados independente de sgbd. In ERCEMAPI Graduao (). Nie, Z. (2010). Credibility evaluation of saas tenants. In Advanced Computer Theory and Engineering (ICACTE), 2010 3rd International Conference on, volume 4, pages V4488 V4491. Nitu (2009). Congurability in saas (software as a service) applications. In Proceedings of the 2nd India software engineering conference, ISEC 09, pages 1926, 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
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), 4855. Ries, E. (2011). The Lean Startup: How Todays Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing Group. Rimal, B. P. and El-Refaey, M. A. (2010). A framework of scientic workow 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 8893, 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 117128, New York, NY, USA. ACM. Shwartz, L., Diao, Y., and Grabarnik, G. (2009). Multi-tenant solution for it service management: A quantitative study of benets. 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
Sousa, F. R. C., Moreira, L. O., De Macdo, 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.1015:1, New York, NY, USA. ACM. Sun, W., Zhang, X., Guo, C. J., Sun, P., and Su, H. (2008). Software as a service: Conguration and customization perspectives. In Congress on Services Part II, 2008. SERVICES-2. IEEE, pages 18 25. Takahashi, H., Mori, K., and Ahmad, H. (2010). Efcient 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). Revises sistemticas 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 171182. 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
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-Pacic Symposium on Internetware, Internetware 10, pages 8:18: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 denition. SIGCOMM Comput. Commun. Rev., 39, 5055. 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 578585, 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 94101, 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 889896, New York, NY, USA. ACM.
104
Wieringa, R., Maiden, N., Mead, N., and Rolland, C. (2005). Requirements engineering paper classication and evaluation criteria: a proposal and a discussion. Requir. Eng., 11, 102107. 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 124. 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. Pacic-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
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 Primrios
ID EP01 EP02 TTULO 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 Dening Composite Congurable 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 Primrios
108
ID EP10 EP11 EP12
EP13
EP14 EP15
EP16 EP17
EP18 EP19 EP20
TTULO Software as a service: Conguration and customization perspectives Combining Different Multi-tenancy Patterns in Service-Oriented Applications Multi-tenant solution for IT service management: A quantitative study of benets 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 Primrios(Continuao)
109
ID EP26 EP27
EP28 EP29 EP30
EP31 EP32
TTULO A framework for optimized distribution of tenants in cloud applications A Framework of Scientic Workow 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 workows 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 Congurability 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 Efcient 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, Haz Farooq Ahmad Xuesong Zhang, Beijun Shen, Xucheng Tang, Wei Chen, Juan Du, Xiaohui Gu, Douglas S. Reeves, Hasselmeyer, P., dHeureuse, 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
110
ID EP44
TTULO 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 exible 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
111
ID EP60 EP61 EP62
TTULO 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
112

Desenvolvimento de Aplicações Multi-Tenancy: Um Estudo de Mapeamento Sistemático

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Desenvolvimento de Aplicações Multi-Tenancy: Um Estudo de Mapeamento Sistemático

Uploaded by

Copyright:

Available Formats

Desenvolvimento de aplicaes multi-tenancy: um estudo de mapeamento sistemtico

Josino Rodrigues Neto

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br

Universidade Federal de Pernambuco Centro de Informtica Ps-graduao em Cincia da Computao

Josino Rodrigues Neto

Desenvolvimento de aplicaes multi-tenancy: um estudo de mapeamento sistemtico

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

3.6 3.7 3.8 4

Migrao do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . .

Concluso e Trabalhos Futuros 5.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Referncias Bibliogrcas Appendices A Estudos Primrios

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

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

Esta seo lista o objetivo geral e os objetivos especcos desta dissertao.

Para alcanar os objetivos esperados, as atividades foram divididas em 3 fases:

Figura 1.5 Resumo da Metodologia(Elaborao prpria)

1.4. CONTRIBUIES CIENTFICAS

2.1. CLOUD COMPUTING

2.1. CLOUD COMPUTING

D. Gourlay D. Edwards B. de Haff

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

2.1. CLOUD COMPUTING

G. Gruman and E. Knorr P. McFedries

Tabela 2.1 Denies de Cloud Computing(Vaquero et al., 2008)

2.1. CLOUD COMPUTING

2.1. CLOUD COMPUTING

Figura 2.1 Modelos de servio de Cloud Computing

2.2. SAAS - SOFTWARE COMO SERVIO

SaaS - Software como Servio

2.2. SAAS - SOFTWARE COMO SERVIO

Figura 2.2 Amazon S3s Growth(Huang, 2011a)

2.2. SAAS - SOFTWARE COMO SERVIO

Figura 2.3 Nveis de Maturidade SaaS(Chong and Carraro, 2006)

2.4. CONSIDERAES FINAIS

2.4. CONSIDERAES FINAIS

3.1. DIRETIVAS DE PESQUISA

Figura 3.1 Processo de Mapeamento Sistemtico - Adaptado de (Petersen et al., 2008)

3.1. DIRETIVAS DE PESQUISA

3.1. DIRETIVAS DE PESQUISA

Denio de Questes de Pesquisa

3.2. SELEO DOS DADOS

Tabela 3.1 Questionamentos e termos

Seleo dos dados

3.2. SELEO DOS DADOS

3.2. SELEO DOS DADOS

Tabela 3.2 Strings Search

3.2. SELEO DOS DADOS

Figura 3.2 Percentual de estudos retornados de acordo com a estratgia de busca

Figura 3.3 Percentual de estudos retornados pelas buscas automticas

Triagem dos Trabalhos

Tabela 3.3 Resultado da aplicao dos critrios de excluso

Classicao dos trabalhos relevantes

Tabela 3.4 Faceta Contexto

Solution Proposal Philosophical Paper Opinion Paper

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

Tabela 3.6 Faceta Contribuio (Fonte: (Wieringa et al., 2005))

Tabela 3.7 Artigos associados por Questo de pesquisa

Tabela 3.8 Artigos agrupados por contexto

Tabela 3.9 Artigos agrupados por contribuio

Figura 3.4 Quantidade de artigos agrupados por Contexto e Ano

Figura 3.5 Quantidade de artigos agrupados por Contexto e Contribuio

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

Figura 3.7 Quantidade de artigos agrupados por Questo e Tipo de Pesquisa