Desenvolvendo aplicações multi-tenancy para computação em núvem

Transcrição

1 Capítulo 6 Desenvolvendo aplicações multi-tenancy para computação em núvem Josino Rodrigues Neto, Vinícius Cardozo Garcia e Wilton dos Santos Oliveira Abstract This course focuses on presenting the main concepts of multi-tenancy and use a practical approach to demonstrate the implementation of an application based on a multi-tenancy architecture. Thus, this chapter presents the definitions and key characteristics of cloud computing, SaaS service model and a multi-tenancy approach for SaaS. Resumo Este minicurso tem como foco principal apresentar os principais conceitos de multitenancy e utilizar uma abordagem prática para demonstrar a implementação de uma aplicação baseada em uma arquitetura multi-tenancy. Assim, este capítulo apresenta as definições e as características essenciais da computação em nuvem, o modelos de serviço SaaS e uma abordagem multi-tenancy para SaaS. 6.1 Introdução Com o ritmo de desenvolvimento da sociedade humana moderna, serviços básicos e essenciais são quase todos entregues de uma forma completamente transparente. Serviços de utilidade pública como água, eletricidade e telefone tornaram-se fundamentais para nossa vida diária e são explorados através de um modelo de pagamento baseado no uso. As infraestruturas existentes permitem entregar os serviços em qualquer lugar e a qualquer hora, de forma que possamos simplesmente acender a luz, abrir a torneira ou fazer uma ligação para qualquer lugar. O uso desses serviços é cobrado de acordo com as diferentes políticas para o usuário final. A mesma idéia de 124

2 utilidade tem sido aplicada na área da informática e uma mudança consistente neste sentido tem sido feita com a disseminação da computação em nuvem. Segundo o NIST, Cloud Computing(Computação em núvem) é composta por cinco características essenciais: self-service sob demanda; amplo acesso a rede; pooling de recursos; elasticidade rápida. Ainda segundo o NIST, Cloud Computing é dividido em três modelos de serviço: Software como serviço (SaaS); Plataforma como serviço (PaaS); Infraestrutura como Serviço (IaaS). Nesse contexto, este minicurso tem como foco principal apresentar os principais conceitos de multi-tenancy e utilizar uma abordagem prática para demonstrar a implementação de uma aplicação baseada em uma arquitetura multi-tenancy. Assim, este capítulo apresenta as definições e as características essenciais da computação em nuvem, o modelos de serviço SaaS e uma abordagem multi-tenancy para SaaS. Este capítulo está organizado no seguinte formato: A seção 1.2apresenta os conceitos fundamentais de cloud computing, Software como serviço e Multi-tenancy. A seção 1.3 apresenta os componentes de uma arquitetura multi-tenancy. A seção 1.4 apresenta o passo a passo para a implementação de um protótipo de aplicação multi-tenancy com Grails. Finalmente, a seção 1.5 apresenta as conclusões finais. 6.2 Conceitos Fundamentais Cloud Computing Na computação em nuvem os recursos de TI são fornecidos como um serviço, permitindo aos usuários o acessa-los sem a necessidade de conhecimento sobre a tecnologia utilizada. Assim, os usuários e as empresas passaram a acessar os serviços sob demanda e independente de localização, o que aumentou a quantidade de serviços disponíveis. Computação em nuvem pretende ser global e prover serviços para todos, desde o usuário final que hospeda seus documentos pessoais na Internet até empresas que terceirizarão toda a parte de TI para outras empresas. Mas o que é Cloud Computing? Segundo Taurion o termo computação em nuvem surgiu em 2006 em uma palestra de Eric Schmidt, da Google, sobre como sua empresa gerenciava seus data centers. Hoje, computação em nuvem, se apresenta como o cerne de um movimento de profundas transformações do mundo da tecnologia (TAURION, 2009). Segundo o NIST(National Institute of Standards and Technology), Cloud Computing é composta por cinco características essenciais: 125

3 Self-service sob demanda: O usuário pode adquirir unilateralmente recurso computacional, como tempo de processamento no servidor ou armazenamento na rede na medida em que necessite e sem precisar de interação humana com os provedores de cada serviço. Amplo acesso a rede: recursos estão disponíveis através da rede e acessados por meio de mecanismos que promovam o padrão utilizado por plataformas heterogêneas (por exemplo, telefones celulares, laptops e PDAs). Pooling de recursos: o provedor de recursos de computação são agrupados para atender vários consumidores através de um modelo multi-tenant, com diferentes recursos físicos e virtuais atribuídos dinamicamente e novamente de acordo com a demanda do consumidor. Há um senso de independência local em que o cliente geralmente não tem nenhum controle ou conhecimento sobre a localização exata dos recursos disponibilizados, mas pode ser capaz de especificar o local em um nível maior de abstração (por exemplo, país, estado ou data center). Exemplos de recursos incluem o armazenamento, processamento, memória, largura de banda de rede e máquinas virtuais. Elasticidade rápida: recursos podem ser adquiridos de forma rápida e elástica, em alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da demanda, e liberados, na retração dessa demanda. Para os usuários, os recursos disponíveis para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento. Serviço medido: sistemas em nuvem automaticamente controlam e otimizam a utilização dos recursos, alavancando a capacidade de medição em algum nível de abstração adequado para o tipo de serviço (por exemplo, armazenamento, processamento, largura de banda, e contas de usuários ativos). Uso de recursos pode ser monitorado, controlado e relatado a existência de transparência para o fornecedor e o consumidor do serviço utilizado. Ainda segundo o NIST, Cloud Computing é dividido em três modelos de serviço: Software como Serviço (Software as a Service - SaaS): A capacidade fornecida ao consumidor é usar as aplicações do fornecedor que funcionam em uma infraestrutura da nuvem. As aplicações são acessíveis dos vários dispositivos do cliente através de uma relação do thin client tal como um browser web. O consumidor não administra ou controla a infraestrutura básica, incluindo nuvens de rede, servidores, sistemas operacionais, armazenamento, ou mesmo capacidades de aplicação individual, com a possível exceção de limitada aplicação específica e definições de configuração de usuários da aplicação. Plataforma como Serviço (Plataform as a Service - PaaS): A capacidade fornecida ao consumidor é desdobrar na nuvem a infraestrutura consumidor criada ou as aplicações adquiridas criadas usando linguagens de programação e as ferramentas suportadas pelo fornecedor. O consumidor não administrar ou 126

4 controlar a infraestrutura básica, incluindo nuvens de rede, servidores, sistemas operacionais, ou armazenamento, mas tem controle sobre os aplicativos utilizados e eventualmente hospedagem de aplicativos e configurações de ambiente. Infraestrutura como Serviço (Infraestructure as a Service - IaaS) : A capacidade prevista para o consumidor é a prestação de transformação, armazenamento, redes e outros recursos computacionais fundamental que o consumidor seja capaz de implantar e executar programas arbitrários, que podem incluir sistemas operacionais e aplicativos. O consumidor não administra ou controla a infraestrutura de nuvem subjacente, mas tem controle sobre os sistemas operacionais, armazenamento, aplicativos implantados, e, eventualmente, o controle limitado de componentes de rede selecionar (por exemplo, firewalls host). Esse trabalho não pretende abordar exaustivamente todos os modelos de serviço de Cloud Computing, esse trabalho tem como foco principal SaaS, especificamente a aplicação da arquitetura multi-tenancy Software como Serviço(SaaS) Por décadas, as companhias utilizavam seu software em sua própria infraestrutura e eram responsáveis por todas as atividades de manutenção, integridade, escalabilidade, disponibilidade e uma série de encargos relacionados ao gerenciamento de TI na empresa. Além de custos relacionados à compra de licenças e atualizações, as empresas tinham que adequar sua infraestrutura e contratar pessoas especializadas para as atividades de gerenciamento. Foi nesse contexto que surgiu o conceito de SaaS. Neste modelo, a funcionalidade da aplicação é oferecida através de um modelo de assinatura pela Internet. O cliente não se torna dono do software, ao invés disso, ele aluga a solução total que é oferecida remotamente. Podemos dividir as aplicações de software como serviço em duas categorias (CHONG e CARRARO, 2006): Serviços para linha de negócios (line-of-business): oferecidos a empresas e organizações de todos os tamanhos. Os serviços de linha de negócios geralmente são soluções de negócios grandes e personalizáveis direcionadas para facilitar processos de negócios como finanças, gerenciamento da cadeia de suprimentos e relações com o cliente. Normalmente esses serviços são vendidos aos clientes como assinatura. Um exemplo desse tipo de serviço são as soluções personalizáveis do Salesforce (SALESFORCE, 2000). Serviços orientados ao consumidor: oferecidos ao público em geral. Os serviços orientados a cliente às vezes são vendidos como assinatura, mas geralmente são fornecidos sem custo e financiados por anúncios. Um outro 127

5 exemplo desse tipo de serviço são os serviços oferecidos pelo Google(Gmail, Google docs, Google Agenda, etc). Apesar do conceito de SaaS não ser uma coisa nova, esse conceito ganhou força somente por volta de 2005 e 2006 com o surgimento e viabilidade de uso de novas tecnologias como web 2.0, rich internet application(ria), SOA, cloud computing, virtualização, etc. Implementar o conceito de SaaS nem sempre é tão simples como parece. Chong (CHONG e CARRARO, 2006) propõe 4 níveis de maturidade para aplicações que utilizam o modelo de SaaS: Figura Níveis de Maturidade SaaS (CHONG e CARRARO, 2006) Nível 1 Ad-Hoc/Personalizado: O primeiro nível de maturidade é semelhante ao modelo de entrega de software do provedor de serviços de aplicativos (ASP) tradicional, que data da década de Nesse nível, cada cliente tem a sua própria versão personalizada do aplicativo hospedado e executa a sua própria instância do aplicativo nos servidores do host. Pensando em arquitetura, software nesse nível de maturidade é muito semelhante ao software de linha de negócios vendido tradicionalmente, em que diferentes clientes em uma organização conectam a uma instância única em execução no servidor, mas essa instância é totalmente independente de quaisquer outras instâncias ou processos que o host esteja executando para os seus outros clientes. Nível 2 Configurável: No segundo nível de maturidade, o fornecedor hospeda uma instância separada do aplicativo para cada inquilino enquanto que no 128

6 primeiro nível cada instância é personalizada individualmente para o inquilino, neste nível todas as instâncias utilizam a mesma implementação de código e o fornecedor atende as necessidades dos clientes fornecendo opções de configuração detalhadas que permitem ao cliente alterar a aparência e o comportamento do aplicativo para os seus usuários. Apesar de serem idênticas umas às outras no nível do código, cada instância permanece totalmente isolada de todas as demais. Nível 3 Configurável e eficiente para vários tenants: No terceiro nível de maturidade, o fornecedor executa uma única instância que serve a todos os clientes, com metadados configuráveis fornecendo uma experiência de usuário e conjunto de recursos exclusivos para cada um. Políticas de autorização e de segurança garantem que os dados de cada cliente sejam mantidos separados dos de outros clientes e que, da perspectiva do usuário final, não exista qualquer indicação de que a instância do aplicativo esteja sendo compartilhada entre vários tenants. Nível 4 Escalonável, configurável e eficiente para vários tenants: No quarto e último nível de maturidade, o fornecedor hospeda vários clientes em um ambiente com carga balanceada de instâncias idênticas, com os dados de cada cliente mantidos separados e com metadados configuráveis fornecendo uma experiência do usuário e um conjunto de recursos exclusivos para cada cliente. Um sistema de SaaS é escalonável para um número de clientes arbitrariamente grande, uma vez que a quantidade de servidores e instâncias no lado do fornecedor pode ser aumentada ou diminuída conforme necessário para corresponder à demanda sem a necessidade de remodelar a arquitetura aplicativo, além do que as alterações ou correções podem ser transmitidas para milhares de tenants tão facilmente quanto para um único tenant. Normalmente se esperaria que o quarto nível fosse a meta definitiva para qualquer aplicativo de SaaS, mas não é sempre assim. É necessário verificar as necessidades operacionais, arquiteturais e de negócio relacionadas à aplicação. Uma abordagem single-tenant faz sentido financeiramente? O seu aplicativo pode ser feito para executar em uma única instância lógica? Você pode garantir os seus contratos de nível de serviço (SLAs) sem isolamento das aplicações? Essas são questões que devem ser respondidas quando se pretende adotar o modelo SaaS Multi-tenancy Multi-tenancy é uma abordagem organizacional para aplicações SaaS. Bezemer (BEZEMER e ZAIDMAN, 2010) define multi-tenancy como aplicações que permitem o compartilhamento dos mesmos recursos de hardware, através do compartilhamento da aplicação e da instância do banco de dados, enquanto permite configurar a aplicação para atender às necessidades do cliente como se estivesse executando em um ambiente dedicado. Tenant é uma entidade organizacional que aluga uma aplicação multi-tenancy. Normalmente, um tenant agrupa um número de usuários que são os stakeholders da organização. 129

7 A definição acima foca no que nós consideramos aspectos em aplicações multi-tenancy: Possibilidade de compartilhamento de recursos de hardware, permitindo a redução de custos (HU WANG, JIE GUO, et al., 2008) (WARFIELD, 2007). Alto grau de configurabilidade, permitindo que cada consumidor customize sua própria interface e seu workflow na aplicação (NITU, 2009)(JANSEN, HOUBEN e BRINKKEMPER, 2010). Uma abordagem arquitetural na qual os tenants fazem uso de uma única aplicação e banco de dados (KWOK, NGUYEN e LAM, 2008). Como multi-tenancy é um conceito relativamente novo, é muito comum as pessoas confundirem multi-tenancy com outros conceitos já existentes. Multi-tenancy não é multi-usuário. Em uma aplicação multi-usuário nós assumimos que os usuários estão usando a mesma aplicação com opções de acesso limitadas. Em uma aplicação multi-tenancy nós assumimos que os tenants tem um algo grau de configuração, dependendo da definição dessas configurações, dois tenants pode possuir aparência e workflows diferentes. Um argumento adicional para essa distinção é que o SLA(Service Level Agreement) para cada tenant pode ser diferente (LIN, SUN, et al., 2009). Outra abordagem que contrasta com multi-tenancy é a abordagem multiinstance. Com o aumento da popularidade de das tecnologias de virtualização e de cloud Computing, multi-instance é a forma fácil de criar aplicações parecidas com multitenancy. É necessário apenas criar uma imagem de maquina virtual com a aplicação préconfigurada e, logo em seguida criar instâncias apartir dessa imagem. A abordagem multi-instance é uma melhor abordagem quando o número de tenants for pequeno (JIE GUO, SUN, et al., 2007) Arquitetura Multi-tenancy Nesse minicurso iremos tomar como base a arquitetura apresentada na Figura 6.2. Aqui vemos que multi-tenancy afeta quase todas as camadas de uma aplicação típica, e como tal, possui um grande potencial para se tornar um interesse transversal. Para manter o impacto sobre o código (complexidade), as implementações de componentes multitenancy devem ser separadas da lógica dos tenants o tanto quanto possível. Caso contrário, a manutenção pode se tornar um pesadelo, porque: Implementar código de requisitos da arquitetura multi-tenancy juntamente com a lógica de negócio dos tenants em todas as camadas de aplicação, o que exige que todos os desenvolvedores sejam reeducados sobre multi-tenancy; Misturar multi-tenancy com código de tenants leva ao aumento da complexidade do código, pois é mais difícil manter o controle de onde o código multi-tenancy é introduzido. Estes dos problemas podem ser superados integrando cuidadosamente multi-tenancy na arquitetura. No restante desta seção, descrevemos os componentes da arquitetura 130

8 abordada por Bezemer (BEZEMER e ZAIDMAN, 2010) para implementação de multitenancy como um interesse transversal. A. Autenticação Pelo motivo de uma aplicação multi-tenant ter apenas uma aplicação e instancia de banco de dados, todos os tenants usam o mesmo ambiente físico. A fim de ser capaz de oferecer customização do ambiente e ter certeza de que os tenants podem acessar somente os seus próprios dados, tenants devem ser autenticados. Enquanto autenticação de usuário é, possivelmente, já presente na aplicação de destino, um mecanismo separado de autenticação de tenants específicos pode ser necessário, por duas razões: (1) geralmente é muito mais fácil introduzir um mecanismo de autenticação adicional, do que mudar um já existente, e (2) autenticação de tenants permite que um único usuário faça parte de mais do que uma organização lógica, o que estende a idéia de autenticação de usuários com grupos. B. Configuração Em uma aplicação multi-tenancy a customização deve ser possível através de configuração. A fim de permitir que o usuário tenha uma experiência como se ele estivesse trabalhando em um ambiente dedicado, é necessário permitir pelo menos os tipos de configuração seguintes: Estilo de Layout(Layout Style) O componente de configuração de estilo de layout permite o uso de temas e estilos específicos. Configuração Geral (General Configuration) O componente de configuração geral permite a especificação de configurações específicas, como configurações de chave de criptografia e detalhes do perfil pessoal. Entrada e saída de arquivo (File I/O) O componente de configuração de I/O de arquivo permite a especificação de caminhos de arquivos, que podem ser usados para, por exemplo, geração de relatório. Fluxo de trabalho (Workflow) O componente de configuração de fluxo de trabalho permite a configuração de fluxos específicos. Por exemplo, configuração de fluxos é necessária em uma aplicação de planejamento de recursos empresariais ERP, em que o fluxo de requisições pode variar significativamente para diferentes companhias. C. Banco de dados (Database) Em uma aplicação multi-tenancy há uma grande exigência para o isolamento dos dados. Porque todos os tenants usam a mesma instância de um banco de dados é necessário ter certeza de que eles podem acessar somente seus próprios dados. Atualmente sistemas de gerenciamento de dados (Data Base Management Systems DBMS) de prateleira não são capazes de lidar com multi-tenancy, isso deve ser feito em uma camada entre a 131

9 camada lógica de negócios e o pool de banco de dados de aplicações. As principais tarefas dessa camada são as seguintes: Criação de novos tenants no banco de dados Se a aplicação armazena ou recupera dados que podem ser de tenants específicos, é tarefa da camada de banco de dados criar os registros do banco de dados correspondente quando um novo tenant se inscreveu para a aplicação. Adaptação de consulta A fim de prover um isolamento de dados adequado, a camada de banco de dados deve ter certeza que consultas são ajustadas de forma que cada tenant possa acessar somente seus próprios registros. Balanço de carga Para melhorar o desempenho de uma aplicação multi-tenancy é necessário um balanceamento de carga eficiente para o pool de banco de dados. Note que qualquer acordo feito no SLA de um tenant e quaisquer restrições impostas pela legislação do país onde o tenant está localizado deve ser satisfeita. Além disso, a aplicação pode ter requisitos de onde os dados de um tenant estão sendo armazenados, por exemplo, para a geração de relatórios. Estes requisitos dificultam o uso de algoritmos de balanceamento de carga existentes. Por outro lado, nossa expectativa é a de que é possível criar algoritmos de balanceamento de carga mais eficientes usando as informações que possuímos sobre os tenants. Figura 6.2- Arquitetura Multi-tenancy (BEZEMER e ZAIDMAN, 2010) 132

10 6.1.4 Implementando um protótipo de aplicação multi-tenancy com Grails Introdução ao Framework Grails Para implementar um protótipo que demonstre a aplicabilidade da arquitetura multitenancy será utilizado o framework Grails. O Grails é um framework web open-source que utiliza a linguagem Groovy, e outros frameworks consagrados como Hibernate, Spring e Sitemesh, como mostrado na Figura 6.3. O Grails foi projetado para desenvolver aplicações CRUD (Create, Read, Update e Delete) de forma simples e ágil, utilizando o modelo de escrever código por convenção introduzido pelo Ruby on Rails. O Grails está se propondo a trazer a produtividade do Ruby on Rails para a plataforma Java, porém ele possui uma grande vantagem, sendo que a linguagem Groovy roda sobre uma JVM, e pode utilizar classes Java e as diversas APIs que existem normalmente. Groovy (padronizado pela JSR-241) é uma linguagem dinâmica e ágil para a plataforma Java, que possui muitas características de linguagens de script como Ruby, Python e Smalltalk, e ainda pode utilizar classes Java facilmente. Linguagens de script estão ganhando cada vez mais popularidade, devido a quantidade reduzida de código fonte necessário para implementar determinadas funcionalidades, se comparado com uma implementação em Java. Figura Arquitetura Grails Instalando Grails Instalar o Grails framework pode ser considerada uma tarefa simples. O passo a passo para a instalação do Grails framework é apresentado na Figura

11 Uma vez instalado, é possível abrir um prompt de comando e testar sua instalação utilizando, por exemplo, o comando grails help. Figura Instalação Grails Para criar uma aplicação em grails o desenvolvedor dever executar o comando: grails create-app multitenantapp Esse comando cria um projeto de aplicação grails contendo um conjunto de arquivos e diretórios necessários para executar uma aplicação grails. Os diretórios criados e suas descrições podem ser vistos com mais detalhes na Tabela 6.1. Tabela Estrutura de pastas de uma aplicação Grails Pasta Descrição + grails-app + conf Contém as configurações da aplicação, como a configuração de banco (DataSource.groovy) e onde podem ser feitas as configurações de inicialização(bootstrap.groovy) entre outros. + controllers Contém as classes de controller(controladores) da aplicação. + domain Contém as classes de Domínio, ou modelos. + i18n Contém arquivos inerentes a internacionalização. 134

12 + services Nessa pasta ficam as classes utilizadas na camada de serviços do Grails, caso sejam criadas. + taglib Contém as TagLibs criadas pelo usuário + views Contém os arquivos.gsp (Groovy Server Pages) utilizados para cada classe de domínio. + layouts Nessa pasta ficam os templates da aplicação. Templates em Grails são views incluídas em outras views. + grails-tests Parta que contém os testes unitários + lib Contém as libs externas, como por exemplo os drivers de conexão aos bancos de dados + src + groovy Contém classes groovy que não se encaixam nem em Domain, Controller ou Service. + java Contém classes java que poderão ser usadas na aplicação + web-app + css Contém os arquivos.css + images Imagens + js JavaScript + WEB-INF Arquivos relacionados ao deploy + index.jsp O Index da app Para executar a aplicação criada deverão ser executados os seguintes comandos: >> cd multitenantapp >> grails run-app O comando cd multitenantapp irá abrir o diretório da aplicação e o comando grails run-app executará a aplicação. Para adicionar um cadastro de uma entidade (CRUD) à aplicação, deve ser criado uma classe de domínio e em seguida uma classe de controller que irá gerenciar as requisições para o cadastro desta entidade. >> grails create-domain-class Product >> grails create-controller multitenantapp Product O primeiro comando cria uma classe de domínio no seguinte endereço..\multitenantapp\grails-app\domain\multitenantapp\product.groovy. >> grails create-domain-class Product Esse arquivo >> grails create-controller multitenantapp Product deverá ser alterado para o código da Figura 6.5 a seguir: 135

13 Figura código Product.groovy O segundo comando cria a classe de controller, que deverá ser alterada para o código a da seguir: Figura Código da Classe Controller Uma vez criadas as classes de domínio e controller,o comando grails run-app deverá ser executado novamente. Após isso será possível acessar o link para visualizar a primeira tela da aplicação, mostrado na Figura 6.7, com o CRUD da entidade criada (Product). Figura Tela Inicial de uma aplicação Grails Assim, observamos que com poucos comandos temos uma pequena aplicação grails funcionando Componentes de uma aplicação multi-tenancy Para implementar uma aplicação multi-tenancy é necessário implementar autenticação, controle de configurabilidade e controle de acesso a dados que atendam às necessidades de uma aplicação multi-tenancy que foram descritos nos tópicos anteriores. A fim de diminuir a complexidade da aplicação de exemplo não será implementado o controle de configurabilidade em nosso aplicativo de demonstração. 136

14 Grails disponibiliza uma arquitetura de plugins que promove o reuso e o aumento de produtividade. Dentre os plug-ins disponíveis existem plugins que facilitam muito a implementação de aplicações multi-tenancy em Grails. São eles Multi-tenant Plugin (Core) e Multi-tenant Spring Security Integration. Esses 2 plugins extendem as funcionalidades de controle de acesso a dados e autenticação de forma a atender os requisitos de aplicações multi-tenant. Para dar continuidade ao nosso exemplo prático será instalado agora um plugin que adiciona a funcionalidade de autenticação em nossa aplicação. Para isso é necessário a execução dos comandos a seguir. >> grails install-plugin spring-security-core >> s2-quickstart login SecUser Role Requestmap Para que esse plugin funcione é necessário que o código no arquivo BootStrap.groovy existente na pasta conf do seu projeto esteja semelhante ao código apresentado na Figura 6.8. Em Seguida já é possível re-executar a aplicação com o comando run-app e verificar que para utilizar a aplicação agora é necessário utilizar um login e senha. As configurações adicionadas no arquivo BootStrap.groovy criaram no banco de dados 2 usuários(user1 e user2), ambos com senha 123. Figura BootStrap.groovy (Single Tenant) O próximo passo é instalar os plug-ins necessários para tornar nosso exemplo uma aplicação multi-tenant. Para isso é necessário a execução do comando a seguir em nosso projeto. >> grails install-plugin multi-tenant-spring-security Após a instalação do plugin são necessárias algumas configurações adicionais: 137

15 1. Adicionar o campo Integer usertenantid na classe SecUser.groovy. Isso fará com que cada usuário esteja associado a um tenant específico. Ao cadastrar um usuário, ele deverá possuir um valor para o campo usertenantid, isso irá indicar quais registros do banco de dados ele terá acesso. 2. Anotar a classe Product.groovy Em uma aplicação multitenancy poderemos ter entidades que terão ou não características multi-tenancy. Ou seja, mesmo em uma aplicação multi-tenancy poderemos ter entidades que terão seus registros compartilhados entre todos os tenants. Para indicar quais entidades terão seus registros filtrados por tenant utilizamos a 3. Adicionar no bloco de constraints da classe Product.groovy a seguinte linha de código tenantid(display:false). Isso fará com que o campo tenantid, que é criado dinamicamente não seja alterado pelos usuários. Dado que o gerenciamento de seu valor é feito pelo plugin. 4. Altera a classe BootStrap.groovy para que o valor do atributo usertenantid seja informado na criação dos 2 usuários padrões do sistema. O código da classe BootStrap.groovy deverá ficar semelhante ao código apresentado na Figura 6.9. Essa alteração fará com que cada usuário padrão do sistema esteja em um tenant diferente. 5. Adicionar o código da Figura 6.10 ao final do arquivo Config.groovy, localizado na pasta conf do projeto. Figura BootStrap.groovy (Multi-tenant) Figura Alteração Config.groovy 138

16 Seguido estes passos, as funcionalidades básicas de uma aplicação multi-tenancy estão presentes no nosso exemplo. Para validar o funcionamento é necessário efetuar o login com o usuário user1(senha=123) e cadastrar alguns produtos. Em seguida efetuar login com o usuário user2 e, também, efetuar alguns cadastros no sistema. Será possível ver que os dados cadastrados efetuados pelo usuário user1 não serão visualizados pelo usuário user2, e vice versa. Isto ocorre porque quando esses usuários foram criados colocados em tenants diferentes Conclusão Tomando como base a fundamentação teórica e o exemplo prático apresentado, concluímos que é possível implementar uma aplicação multi-tenancy de forma produtiva e com alto grau de reuso de código. Apesar do exemplo prático ser implementado em Groovy e Grails, essa arquitetura pode ser replicada em várias outras linguagens existentes no mercado. Embora os esforços de pesquisa na área de SaaS e multi-tenancy estejam crescendo bastante ainda existem vários pontos a serem explorados e evoluídos, como avaliação de desempenho, monitoramento de tenants, escalabilidade, migração de aplicações legadas para a arquitetura multi-tenancy, entre outros Referências ABDUL-JAWAD,. Groovy and Grails Recipes. Berkely: Apress, BEZEMER, C.-P.; ZAIDMAN, A. Multi-tenant SaaS applications: maintenance dream or nightmare? ERCIM Workshop on Software Evolution (EVOL) and International Workshop on Principles of Software Evolution (IWPSE), New York, CHONG, ; CARRARO,. Architecture Strategies for Catching the Long Tail, Disponivel em: < Acesso em: 2011 out. 01. HU WANG, Z. et al. A Study and Performance Evaluation of the Multi-Tenant Data Tier Design Patterns for Service Oriented Computing. ICEBE '08 Proceedings of the 2008 IEEE International Conference on e-business Engineering, Washington, DC, JANSEN, S.; HOUBEN, G.-J.; BRINKKEMPER, S. Customization realization in multi-tenant web applications: case studies from the library sector. Proceeding ICWE'10 Proceedings of the 10th international conference on Web engineering, Berlin, Heidelberg, JIE GUO, et al. A Framework for Native Multi-Tenancy Application Development and Management. 9th IEEE International Conference on E-Commerce Technology and the 4th IEEE International Conference on Enterprise Computing, E-Commerce, and E-Services, Tokyo, KLEIN, D. Grails: A Quick-Start Guide. [S.l.]: Pragmatic Bookshelf, KWOK, T.; NGUYEN, T.; LAM, L. A Software as a Service with Multi-tenancy Support for an Electronic Contract Management Application. International Conference on Services Computing. Washington: IEEE Computer Society p

17 LIN, H. et al. Feedback-Control-Based Performance Regulation for Multi-Tenant Applications. 15th International Conference on Parallel and Distributed Systems (ICPADS). Shenzhen: IEEE p MELL, P.; GRANCE,. Draft nist working definition of cloud computing - v15. National Insitute of Standards and Technology, Disponivel em: < Acesso em: 1 out NITU. Configurability in SaaS (software as a service) applications. Proceedings of the 2nd annual India Software Engineering Conference (ISEC), Pune, India, ROCHER, G. K. The Definitive Guide to Grails. Berkely: Apress, SALESFORCE, Disponivel em: < Acesso em: 2011 out. 1. SMITH, G.; LEDBROOK, P. Grails in Action. Greenwich: Manning Publications, TAURION, C. Cloud Computing: Computação em Nuvem: Transformando o mundo da tecnologia da informação. Rio de Janeiro: Brasport, WARFIELD, B. Multitenancy Can Have a 16:1 Cost Advantage Over Single-Tenant. SmoothSpan Blog, Disponivel em: < Acesso em: 17 out