UNIVERSIDADE ESTADUAL DO CEARÁ CENTRO DE CIÊNCIA E TECNOLOGIA CURSO DE ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE COM ÊNFASE EM PADRÕES DE SOFTWARE

Transcrição

1 UNIVERSIDADE ESTADUAL DO CEARÁ CENTRO DE CIÊNCIA E TECNOLOGIA CURSO DE ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE COM ÊNFASE EM PADRÕES DE SOFTWARE CAIO HOLANDA COSTA ESTUDO DE CASO: ADAPTAÇÃO NÃO INTRUSIVA DE UM SISTEMA E MIGRAÇÃO PARCIAL DE SEU BANCO DE DADOS RELACIONAL PARA UM BANCO DE DADOS NOSQL NA NUVEM FORTALEZA 2014

2 CAIO HOLANDA COSTA ESTUDO DE CASO: ADAPTAÇÃO NÃO INTRUSIVA DE UM SISTEMA PARA MIGRAÇÃO PARCIAL DE SEU BANCO DE DADOS RELACIONAL PARA UM BANCO DE DADOS NOSQL NA NUVEM Monografia submetida à Coordenação do curso de Pós- Graduação em Engenharia de Software com Ênfase em Padrões de Software da Universidade Estadual do Ceará, como requisite parcial para obtenção do título de Especialista em Engenharia de Software. Orientação: Professor Paulo Henrique M. Maia, PhD. FORTALEZA

3 CAIO HOLANDA COSTA ESTUDO DE CASO: ADAPTAÇÃO NÃO INTRUSIVA DE UM SISTEMA PARA MIGRAÇÃO PARCIAL DE SEU BANCO DE DADOS RELACIONAL PARA UM BANCO DE DADOS NOSQL NA NUVEM Monografia submetida à Coordenação do curso de Pós- Graduação em Engenharia de Software com Ênfase em Padrões de Software da Universidade Estadual do Ceará, como requisite parcial para obtenção do título de Especialista em Engenharia de Software. Orientação: Professor Paulo Henrique M. Maia, PhD. Aprovada em: / / BANCA EXAMINADORA Professor Paulo Henrique Mendes Maia, PhD Universidade Estadual do Ceará Professor Dr. Lincoln Souza Rocha Universidade Federal do Ceará Professor Nabor das Chagas Mendonça, PhD Universidade de Fortaleza 3

4 Dedicatória Dedico este trabalho ao meu pai, Júlio César, por ser exemplo de honestidade e dinamismo, à minha mãe, Silvana, por ser exemplo de ternura e fé, ao meu avô, Severino, que me ensinou humildade através da atitude, e a minha amada noiva, Anne, e compreensiva irmã, Priscila, que entenderam minha ausência durante o período de elaboração deste trabalho. 4

5 AGRADECIMENTOS Agradeço, em primeiro lugar, aos meus pais que sempre me apoiam, me orientam e sempre estão ao meu lado, até mesmo nas piores circunstâncias. Juntamente com Deus, eles são os alicerces sobre os quais construí o meu caráter. Agradeço a minha irmã que sempre traz alegria a minha vida e me incentiva a continuar crescendo apesar de qualquer obstáculo. Agradeço a minha noiva, Anne, por finalmente me trazer o amor que sempre sonhei, puro e tranquilo. Agradeço especialmente ao professor Paulo Henrique Mendes Maia por ter disponibilizado seu tempo para me orientar e contribuir valiosamente com o crescimento do meu conhecimento acadêmico. Agradeço também a todos os professores que lecionaram as disciplinas da especialização em Engenharia de Software da UECE. Agradeço aos funcionários da UECE que contribuem para a formação de especialistas na especialização em Engenharia de Software. Por fim, agradeço aos colegas de turma que por diversas vezes contribuíram para meu crescimento durante as discussões em sala e nos corredores. 5

6 RESUMO Este trabalho apresenta um estudo de caso onde, para melhorar seu desempenho, um sistema de monitoramento veicular teve sua maior e mais importante tabela migrada de um banco de dados relacional para o banco de dados DynamoDB. Para viabilizar essa migração as duas aplicações que compõem o sistema, uma aplicação web e uma aplicação standalone, foram adaptadas de forma não intrusiva utilizando programação orientada a aspectos e funcionalidades dinâmicas da linguagem Groovy, para acessar simultaneamente a base de dados relacional e a nova base de dados DynamoDB. 6

7 ABSTRACT This paper presents a case study where, to improve performance, a system for monitoring vehicle had its biggest and most important table migrated from a relational database to the DynamoDB database. To make this migration possible the two applications which compose the system, a web application and a standalone application, were adapted non- intrusively using aspect- oriented and dynamic features of Groovy programming language, to simultaneously access the relational database and the new base DynamoDB database. 7

8 LISTA DE FIGURAS FIGURA TABELA EM UM BANCO DE DADOS RELACIONAL, E COLEÇÃO SIMILAR, EM UM BANCO DE DADOS NOSQL FIGURA CAMPO ADICIONAL NÃO PREVISTO EM UM AGREGADO DE UMA COLEÇÃO NOSQL FIGURA TABELAS RELACIONADAS POR MEIO DE CHAVE ESTRANGEIRA FIGURA AGREGADO DE UMA COLEÇÃO ARMAZENA TODOS OS DADOS QUE COMPÕEM UMA UNIDADE FIGURA MÉTODO SAVE NA INTERFACE POSICAODAO DA APLICAÇÃO RBRDRIVER FIGURA CHAMADA AO MÉTODO SAVE DA INTERFACE POSICAODAO É UM JOINT POINT FIGURA POINTCUT LOGSAVE INTERCEPTA CHAMADA AO MÉTODO SAVE DA INTERFACE POSICAODAO FIGURA ADVICE QUE LOGA PERSISTÊNCIA DE UMA POSIÇÃO ACESSA CONTEXTO DO JOINT POINT FIGURA 5.1 CLASSE JAVA DETERMINA MÉDIA ARITMÉTICA DOS VALORES DE ENTRADA FIGURA SCRIPT GROOVY DETERMINA MÉDIA ARITMÉTICA DOS VALORES DE ENTRADA FIGURA APLICAÇÕES GROOVY EXECUTAM NA JVM E UTILIZAM CÓDIGO JAVA FIGURA CLASSES GROOVY E CLASSES JAVA EM UMA MESMA HIERARQUIA FIGURA CHAMADAS DE MÉTODO GROOVY SÃO FILTRADAS POR UMA CAMADA INTERMEDIÁRIA FIGURA 5.6 EM GROOVY, CHAMADAS A MÉTODOS DEFINIDOS NA MESMA CLASSE TAMBÉM SÃO FILTRADOS FIGURA INTERFACE GROOVYOBJECT, IMPLEMENTADA POR TODAS AS CLASSES GROOVY FIGURA 5.8 IMPLEMENTAÇÃO DE GROOVYOBJECTSUPPORT É REPLICADA EM IMPLEMENTAÇÕES DE GROOVYOBJECT FIGURA CHAMADA PARA METODO3 DE CLASSEGROOVY3 É DIRECIONADO PARA A META CLASSE DA MESMA FIGURA 5.10 SUBSTITUIÇÃO DE META CLASSE POR MEIO DA ADIÇÃO DA NOVA META CLASSE EM PACOTE ESPECÍFICO FIGURA 6.1 COMUNICAÇÃO DO AVL COM O SERVIDOR NA INTERNET FIGURA ARQUITETURA DO SISTEMA ENTRE O GATEWAY E O RBRDRIVER FIGURA INTERFACE DE MONITORAMENTO DO RASTROBR FIGURA 6.4 RELATÓRIO DE POSIÇÕES FIGURA INTERFACES DA CAMADA DAO DIRETAMENTE RELACIONADAS COM O REGISTRO DE POSIÇÕES FIGURA CLASSES DAO PARA BANCOS DE DADOS RELACIONAIS FIGURA CÓDIGO DA CLASSE QUE SALVA UMA POSIÇÃO NA BASE DE DADOS FIGURA CLASSE QUE PRODUZ RELATÓRIOS E DAOS QUE INTERAGEM COM A TABELA POSIÇÃO FIGURA SPRING INJETA CLASSE GORMDAOFACTORY NA CLASSE RELATORIOSERVICE FIGURA SCRIPT DE CONFIGURAÇÃO SPRING PARA INJEÇÃO DE DEPENDÊNCIAS FIGURA COLEÇÃO POSIÇÃO ARMAZENA CAMPOS DE OUTRAS TABELAS AO INVÉS DE ARMAZENAR APENAS IDS FIGURA ASSISTENTE PARA PROVISIONAMENTO DO THROUGHPUT PARA UMA COLEÇÃO DYNAMODB FIGURA ENTIDADE POSIÇÃO COM ALTERAÇÃO PARA SER PERSISTIDA NO BANCO DE DADOS DYNAMODB FIGURA MÉTODO DA CLASSE GORMPOSICAODAO QUE CONSULTA A TABELA POSIÇÃO FIGURA ADVICE INTERCEPTA CHAMADA AO MÉTODO GETPOSICAODAO E RETORNA UM DYNAMODBPOSICAODAO FIGURA 7.6 CODIGO FONTE DO ASPECTO DAOFACTORYASPECT FIGURA DEFINIÇÃO DO ASPECTO DAOFACTORYASPECT NO SCRIPT DE CONFIGURAÇÃO SPRING BEANS FIGURA CLASSE SQLPOSICAODAO IMPLEMENTA A INTERFACE GROOVYOBJECT FIGURA META CLASSE DA CLASSE SQLPOSICAODAO FIGURA META CLASSE E ESTRUTURA DE PACOTES PARA A CLASSE SQLPOSICAODAO FIGURA NOVA META CLASSE SQLPOSICAODAO

9 LISTA DE ABREVIATURAS E SIGLAS ACID AOP API AVL AWS DAO DBA GPRS GPS GSM IaaS JVM MOP NoSQL PaaS SaaS SGBD SOA SQL XML Atomicity, Consistency, Isolation, Durability Aspect- Oriented Programming Application Programming Interface Automatic Vehicle Location Amazon Web Services Data Access Object DataBase Administrator General Packet Radio Service Global Positioning System Global System for Mobile communications Infrastructure as a Service Java Virtual Machine Meta- Object Protocol Not Only SQL Platform as a Service Software as a Service Sistema Gerenciador de Banco de Dados Service Oriented Architecture Structured Query Language extensible Markup Language 9

10 Sumário 1 Introdução Problema Escalonamento horizontal com PostgreSQL Adaptação das aplicações Objetivos Organização do texto Trabalhos relacionados Bancos de dados NoSQL Agregados Bancos de dados NoSQL orientados a agregados Restrições e vantagens de bancos de dados NoSQL orientados a agregados Programação orientada a aspecto AspectJ Joint Point Pointcut Advice Aspecto Spring AOP A linguagem de programação Groovy Sintaxe Groovy e a plataforma Java Programação dinâmica com Groovy Meta classes Descrição do sistema Comunicação entre módulos rastreadores e servidor RBRDriver RastroBR RBRDriver Acesso ao banco de dados RastroBR Acesso ao banco de dados Implementação da solução Adaptação dos dados da tabela Posição Escolha do banco de dados NoSQL Adaptação das aplicações O plugin DynamoDB GORM Abordagem baseada em aspectos RastroBR - Interceptação de métodos DAO com Spring AOP RBRDriver interceptação de métodos DAO por meio de meta classes Conclusão e trabalhos futuros Conclusão Eficácia dos aspectos na adaptação de aplicações Migração de base de dados relacionais legadas para bancos NoSQL Um banco NoSQL adequado para cada aplicação Aspectos com Groovy Trabalhos futuros Testar outros bancos de dados NoSQL Expandir a implementação dos aspectos com Groovy Anexo A

11 A1. Classe DynamoDbPosicaoDao.groovy A2. Classe DynamoDbClient.groovy Anexo B B1. Classe SqlPosicaoDaoMetaClass.groovy B2. Classe DynamoDbPosicaoDao.groovy B3. Classe DynamoDbClient.groovy B4. Classe DynamoDbDaoFactory.groovy Bibliografia

12 1 Introdução Este trabalho apresenta um estudo de caso onde um sistema de monitoramento veicular, pertencente à empresa cearense Azul Tecnologia, foi adaptado por meio de uma abordagem não intrusiva para que a persistência da entidade mais importante do domínio fosse migrada de uma tabela em um banco de dados relacional para uma coleção no banco de dados DynamoDB (SIVASUBRAMANIAN, 2012), sem interferir na persistência de todos os demais modelos no banco de dados relacional. 1.1 Problema O sistema de monitoramento veicular supracitado é composto de duas aplicações, uma aplicação web, chamada RastroBR, e uma aplicação standalone, chamada RBRDriver, e o banco de dados relacional PostgreSQL como base de dados. Ambas as aplicações possuem a entidade Posição entre os modelos de seus domínios. Uma posição corresponde aos dados georreferenciados enviados pelos veículos monitorados. O RRBDriver recebe essas posições através da Internet, as persiste no banco de dados, mais especificamente na tabela Posição, e a aplicação web RastroBR consulta a mesma tabela para fornecer seus relatórios. A tabela Posição é a maior e mais importante tabela do sistema. Tanto o RBRDriver quanto o RastroBR fazem uso intenso da mesma. O fato de que todos os veículos monitorados transmitem automaticamente uma posição por minuto faz com que a tabela Posição tenha uma taxa de crescimento elevada. O próprio progresso do negócio torna o crescimento dessa tabela mais acentuado, pois cada novo contrato corporativo fechado pela empresa aumenta a quantidade de dados a serem armazenados nessa tabela fazendo com que a curva de crescimento da mesma assemelhe- se à curva de uma função exponencial. Todos os relatórios do RastroBR têm como fonte de dados a tabela Posição. É comum que clientes do sistema requisitem relatórios de grandes períodos concomitantemente, especialmente no final de cada mês onde são registrados picos de leitura nessa tabela que, como consequência, causam quedas no tempo de resposta dos relatórios disponibilizados pelo RastroBR. O tempo de resposta desses relatórios tende a se tornar cada vez maior e a preocupação era de que, com o passar do tempo, a espera viesse a se tornar inaceitável. 12

13 Também havia preocupação com o desempenho do RBRDriver. Com o crescimento da tabela Posição a inserção de um registro na mesma se tornava uma operação cada vez mais lenta. Em alguns momentos acontecia o acúmulo de posições a serem salvas na base de dados. Para amenizar o problema do atraso na inserção de posições, o escalonamento vertical do servidor de banco de dados foi realizado algumas vezes, porém essa é uma estratégia cara possuindo limites práticos e financeiros. Durante o período em que este trabalho foi escrito, a cada seis segundos, em média, o RBRDriver persistia trezentas posições na tabela Posição, resultando em três mil inserções por minuto. Durante os dezoito meses de funcionamento do sistema, a tabela Posição acumulou 78 gigabytes de dados e 31 gigabytes de índices, totalizando 109 gigabytes. Desse total, cerca de 60 gigabytes foram referentes aos últimos seis meses. Apesar dos números aparentemente modestos, além das quedas de desempenho relatadas, a empresa responsável pelo sistema já enfrentava dificuldades para gerenciar atividades como backup, restauração, e manutenção de índices e tuplas mortas (NAVATHE e ELMASRI, 2005). Tornava- se cada vez mais difícil melhorar o desempenho do banco de dados, e a empresa não possuía um DBA (DataBase Administrator) dedicado para essa função. Devido a esses problemas duas alternativas foram cogitadas para melhorar o desempenho no acesso à tabela Posição e simplificar o gerenciamento da mesma. A primeira alternativa era realizar um escalonamento horizontal (NAVATHE e ELMASRI, 2005) com o banco de dados PostgreSQL. A segunda alternativa era migrar apenas a tabela Posição para um banco de dados NoSQL (SADALAGE e FOWLER, 2013) Escalonamento horizontal com PostgreSQL O escalonamento vertical do servidor que executava o SGBD PostgreSQL era uma solução cara e que eventualmente chegaria a um limite, financeiro ou prático. Então o escalonamento horizontal foi considerado. Haviam três opções de configuração disponíveis: um cluster, onde várias máquinas compartilham um sistema de arquivos; uma configuração master- slave; uma configuração distribuída onde os dados da tabela Posição seriam particionados por vários servidores. De acordo com Sadalage et al (2013), bancos de dados relacionais não foram projetados para serem escalonados horizontalmente. Nenhuma das soluções citadas 13

14 acima eram adequadas para a empresa Azul Tecnologia, pois todas eram extremamente complexas para implementar e manter. Manter a sincronia dos servidores e o balanceamento de carga entre eles era uma tarefa que exigiria muito esforço e conhecimento, e não havia um DBA na empresa com conhecimento necessário para executar tal tarefa. A alternativa baseada em um banco de dados NoSQL se tornou a mais viável devido às características oferecidas por alguns produtos desse tipo. Entre essas características a mais importante, no contexto deste projeto, era o fato de que a maioria dos bancos de dados NoSQL foram projetados para lidar com grandes volumes de dados através do escalonamento horizontal, tornando o particionamento dos dados em vários servidores uma tarefa mais simples e com maior nível de automatização Adaptação das aplicações Uma vez que a solução baseada em bases de dados NoSQL foi escolhida, era necessário adaptar as duas aplicações, o RBRDriver e o RastroBR, para que ambas passassem a trabalhar com esse tipo de banco de dados. Porém, essa solução deveria ser utilizada apenas para a entidade Posição, todas as outras entidades deveriam continuar na base de dados relacional devido às restrições de integridade que não são oferecidas em bases de dados NoSQL, além dos mesmos não darem suporte a relacionamentos entre coleções. A intenção dos gerentes da empresa era implementar uma solução simples, que não demandasse muito esforço, e testá- la antes de adotar a mesma de forma definitiva. Nesse contexto não era desejável fazer grandes modificações no código do RastroBR ou do RBRDriver, pois naquele momento não havia profissionais disponíveis para esse esforço. Além disso, os profissionais que desenvolveram as aplicações desse sistema já haviam deixado a empresa. Assim, caso novos profissionais fossem contratados, eles deveriam se inteirar da arquitetura das aplicações para fazer alterações nas mesmas, tornando o esforço ainda maior. Um dos motivos que contribuiu para a rejeição da alternativa baseada na distribuição da tabela Posição por vários servidores PostgreSQL foi o fato de que a mesma sugeria modificações complexas e que iriam contra as boas práticas de desenvolvimento de software. Da mesma forma, modificar em ambas as aplicações apenas as porções de código responsáveis por interagir com a tabela Posição para que deixassem de fazê- lo e, ao invés disso, passassem a interagir com uma coleção em um 14

15 banco de dados NoSQL, também dava sinais de que seria uma implementação complexa e bastante intrusiva Objetivos O objetivo principal do projeto abordado neste estudo de caso é adaptar de forma não intrusiva as aplicações RBRDriver e RastroBR para que passem a utilizar um banco de dados NoSQL para, respectivamente, armazenar e consultar os registros da entidade Posição. O objetivo principal é desdobrado nos seguintes objetivos específicos: escolher um banco de dados NoSQL, em um ambiente de nuvem, que ofereça fácil manutenção e que seja de rápido aprendizado; adequar os dados da tabela Posição para o modelo do banco de dados NoSQL escolhido; adaptar a aplicação RBRDriver da forma menos intrusiva possível, mas de forma que seja fácil retornar para o modo de funcionamento anterior onde os dados são salvos no banco de dados relacional; por fim, adaptar a aplicação RastroBR da forma menos intrusiva possível, mas de forma que seja fácil retornar para o modo de funcionamento anterior onde os dados são consultados no banco de dados relacional; 1.2 Organização do texto O capítulo 2 apresenta trabalhos relacionados a este a fim de situar o mesmo no contexto das pesquisas acadêmicas. Cada trabalho é brevemente descrito e os pontos em que o mesmo se relaciona e se diferencia deste trabalho são citados. Os capítulos 3, 4 e 5 apresentam conceitos que serão necessários para compreender a solução. O capítulo 3 conceitua bancos de dados NoSQL e apresenta algumas funcionalidades e restrições dos mesmos. O capítulo 4 apresenta a programação orientada a aspectos e suas estruturas. O capítulo 5 descreve de forma breve a linguagem de programação Groovy e algumas de suas capacidades dinâmicas. O capítulo 6 descreve a arquitetura do sistema, e é focado na interação das duas aplicações que compõem o sistema, RastroBR e RBRDriver, com a tabela Posição. O capítulo 7 descreve a solução implementada e justifica as escolhas de ferramentas e tecnologias. Por fim, o capítulo 8 apresenta as conclusões obtidas a partir desse estudo de caso e sugere trabalhos futuros. 15

16 2 Trabalhos relacionados Semelhantemente ao relato realizado neste trabalho, em (SCHRAM e ANDERSON, 2012) são relatas as lições aprendidas durante a transição de uma base de dados de grandes proporções de um banco de dados relacional para um modelo híbrido que combina um banco de dados relacional e um banco de dados NoSQL, a fim de contornar algumas limitações relacionadas a utilização de bancos de dados relacionais. O sistema adaptado em (SCHRAM e ANDERSON, 2012) é composto de vários serviços que coletam e analisam informações postadas no Twitter relacionadas a grandes eventos de emergência, como catástrofes naturais. A camada de persistência desse sistema tornou- se um ponto crítico pois o framework Hibernate apresentava muitos problemas de desempenho ao lidar com grandes massas de dados. Diferentemente dos problemas relacionados ao Hibernate relatados em (SCHRAM e ANDERSON, 2012), os problemas que motivaram a adaptação das aplicações RBRDiver e RastroBR são relacionados apenas ao tempo de resposta do banco de dados relacional e à dificuldade de manutenção do mesmo. Assim como na adaptação das aplicações estudada neste texto, em (SCHRAM e ANDERSON, 2012) foi necessário adequar os dados que foram migrados do banco de dados relacional, MySQL, para o banco de dados NoSQL, Cassandra, para se ajustarem ao modelo de dados e restrições do último. Assim como desejado na migração das aplicações RastroBR e RBRDriver, em (SCHRAM e ANDERSON, 2012) o sistema foi adaptado de forma pouco intrusiva pois a composição dos serviços era realizada por meio da injeção de dependência do framework Spring que injeta implementações concretas em referências de tipos de interfaces. Logo, foram criadas novas implementações para trabalhar com o banco de dados NoSQL porém seguindo o contrato das interfaces existentes. Diferentemente deste trabalho, em (SCHRAM e ANDERSON, 2012) não foi mencionado se o banco de dados NoSQL Cassandra deveria ser utilizado em uma infra estrutura de nuvem. Em (JAMSHIDI, AHMAD e PAHL, 2013) uma revisão sistemática é conduzida a fim de identificar, classificar e comparar pesquisas focadas em planejar, executar e validar migrações de aplicações legadas para a nuvem. Por meio de um processo rigoroso, 23 pesquisas foram identificadas e classificadas utilizando duas ferramentas: um modelo de referência que classifica as pesquisas quanto aos processos e atividades envolvidas na 16

17 migração, e um framework que caracteriza as técnicas utilizadas para executar a migração. De acordo com Jamshidi et al (2013) considerando o nível de adaptação necessário e as camadas da aplicação migrada, os tipos de migração podem ser divididos em: substituição, esse é o tipo menos invasivo onde dados e/ou camada de negócios são migrados para a nuvem; migração parcial, onde componentes ou funcionalidades da aplicação são migrados para a nuvem; migração da pilha completa da aplicação, é o tipo mais simples pois a aplicação é monoliticamente encapsulada em uma ou mais máquinas virtuais na nuvem; e cloudify, é o tipo mais completo onde toda a aplicação é convertida em um sistema completamente compatível com a nuvem e passa a ser uma composição de vários serviços da nuvem. De acordo com essa classificação, a migração que o estudo de caso deste trabalho aborda é caracterizada como uma migração por substituição e nenhuma das pesquisas que fizeram parte da revisão literária sistemática de (JAMSHIDI, AHMAD e PAHL, 2013) são caracterizadas como tal por se tratar mais de um melhoramento de uma aplicação legada por meio de serviços de nuvem do que uma migração pura. Porém alguns trabalhos relacionados em (JAMSHIDI, AHMAD e PAHL, 2013) possuem fases que também estão presentes na migração abordada neste texto possibilitando relacionar alguns trabalhos semelhantes quanto a migração para nuvem. Em (VU e ASAL, 2012), um dos trabalhos listados em (JAMSHIDI, AHMAD e PAHL, 2013), é realizada uma análise prática e metodológica sobre as funcionalidades, restrições e limitações das principais plataformas de nuvem do mercado a fim de responder à algumas questões de viabilidade. Dentre as questões levantadas a que mais se aproxima do tema deste trabalho é a seguinte: Quais são os pontos importantes que precisam ser considerados para migrar uma aplicação assim como sua base de dados? Um guia geral é apresentado com base nas lições aprendidas e como prova de conceito três exemplos de migração de aplicações são apresentados. Em um desses exemplos a aplicação possui uma base de dados e atenção especial é dada à migração dos dados dessa aplicação para um serviço de banco de dados na nuvem. 17

18 Similarmente ao estudo de caso deste trabalho, a base de dados em (VU e ASAL, 2012) era armazenada em um banco relacional, MySQL, e é migrada para uma base de dados NoSQL na nuvem Google App Engine. Consequentemente, a aplicação teve que passar por uma série de modificações. A diferença da prova de conceito apresentada em (VU e ASAL, 2012) para o estudo de caso deste trabalho é que em (VU e ASAL, 2012) todas as modificações foram realizadas de forma intrusiva por não se tratar de uma aplicação comercial em produção. O trabalho descrito em (CHAUHAN e BABAR, 2011), também listado em (JAMSHIDI, AHMAD e PAHL, 2013), relata a migração da ferramenta SOA Hackystat para um ambiente de nuvem. A ferramenta Hackystat é uma aplicação Open Source orientada a serviço para monitoramento de desenvolvimento de software. Nesse trabalho o foco é identificar e entender os desafios presentes na migração de sistemas orientados a serviço, SOA, para a nuvem, enquanto que o estudo de caso deste texto aborda a migração por substituição de uma aplicação standalone e uma aplicação cliente- servidor. Em (CHAUHAN e BABAR, 2011) os diversos serviços que compõem o sistema Hackystat são implantados separadamente em instâncias da nuvem Amazon EC2 e o serviço de elasticidade é utilizado nessas instâncias, consequentemente o sistema SOA evoluiu para um sistema SaaS baseado em IaaS. De acordo com Jamshidi et al (2013) esse é o tipo mais simples de migração, onde a pilha completa da aplicação é migrada para servidores virtuais na nuvem. Entre as conclusões mostradas em (CHAUHAN e BABAR, 2011) está a constatação de que sistemas que dividem a lógica do negócio entre aplicação e bases de dados, gatilhos e outras funcionalidades, são mais difíceis de migrar pois a nuvem deve oferecer um banco de dados que possibilite que as mesmas estruturas possam ser executadas. Essa é uma das causas que fez com que a migração da base de dados dos sistemas RBRDriver e RastroBR fosse parcial, pois a mesma contem gatilhos que fazem parte da lógica do negócio. Diferentemente da migração parcial dos dados do sistema de monitoramento veicular deste trabalho, que utilizou um serviço PaaS para armazenamento de uma de suas tabelas, em (CHAUHAN e BABAR, 2011) o servidor SGBD foi instalado em uma instância Amazon EC2 e os dados foram armazenados no serviço de armazenamento elástico da Amazon S3. O artigo de Vasconcelos et al (2013) aborda o esforço de desenvolvimento considerável para que uma aplicação legada seja adaptada para o ambiente de nuvem, 18

19 que pode conter muitas restrições, e o fato de que as alterações necessárias no código fonte podem inserir erros. Frente a esse problema, o artigo sugere uma abordagem não intrusiva baseada em eventos para adaptar o código de uma aplicação legada para as restrições do ambiente de nuvem. Esse artigo cita alguns exemplos em que essa abordagem poderia ser utilizada. Um desses exemplos é o caso de uma aplicação que, para alcançar maior escalabilidade, poderia ter seu banco de dados substituído por um serviço de armazenamento do tipo NoSQL baseado na nuvem. Esse caso é muito semelhante ao projeto que a empresa Azul Tecnologia desejava executar. A diferença era o fato de que, ao invés de migrar toda base de dados, a empresa desejava migrar apenas uma tabela. A abordagem descrita em (VASCONCELOS, BARBOSA, et al., 2013) sugeriu um caminho para a implementação desse projeto e este trabalho descreve a solução implementada. De acordo com Vasconcelos et al (2013), um modelo de arquitetura Publish/Subscribe pode ser utilizado para interceptar eventos de interesse e modificar o fluxo de execução da aplicação de maneira desacoplada. Baseadas nessa arquitetura, técnicas de interceptação de código podem ser utilizadas para capturar a execução de trechos específicos de código e alterar o fluxo da aplicação, executando outro código, e se necessário, retornar os valores que se espera que sejam retornados pelos trechos de código interceptados. O artigo sugere a utilização de programação orientada a aspectos para interceptar eventos em nível de software a fim de adaptá- lo para a nuvem. Para interceptar eventos nos testes executados pelos autores do artigo foi utilizado o AspectJ (KISELEV, 2002), uma extensão que adiciona a linguagem Java a programação orientada a aspecto. O projeto relatado neste estudo de caso aplica parte das ideias sugeridas em (VASCONCELOS, BARBOSA, et al., 2013). 19

20 3 Bancos de dados NoSQL A partir do início dos anos 2000 houve um grande crescimento na quantidade de dados trafegados na Internet. Sites passaram a manter registros detalhados das atividades de seus usuários para que pudessem obter informações importantes quanto ao perfil dos mesmos. As redes sociais surgiram, interconectando uma imensa quantidade de usuários e indexando informações sobre eles. Os sites de busca se tornavam mais importantes e indexavam uma quantidade cada vez maior de páginas. Além do aumento da massa de dados a natureza dos mesmos se diversificou. Surgiram dados desestruturados que dificultavam o armazenamento eficiente em bases de dados tradicionais. As empresas que operavam negócios na Internet precisavam persistir essa grande quantidade de dados de maneira eficiente para manter tempos de resposta satisfatórios para seus clientes. Para lidar com o grande aumento da quantidade de dados haviam duas alternativas: o escalonamento vertical e o escalonamento horizontal dos sistemas de bancos de dados. O escalonamento vertical consiste em realizar upgrades nos servidores de bancos de bancos de dados: troca e/ou aumento da quantidade de processadores, aumento da quantidade de memória, aumento da capacidade dos dispositivos de armazenamento, etc. O escalonamento horizontal consiste em adicionar mais máquinas a uma arquitetura distribuída formada por diversos nós independentes, conectados em uma rede, funcionando em paralelo, porém compondo um mesmo sistema de banco de dados. A primeira alternativa, o escalonamento vertical, possui limites práticos. Ao contrário do escalonamento horizontal, onde sempre é possível adicionar mais nós ao sistema, não é possível realizar o upgrade em uma máquina sempre que necessário. Além disso, com o crescimento da quantidade de dados, fatalmente o escalonamento horizontal se torna mais barato que o escalonamento vertical, pois é possível utilizar várias máquinas de menor capacidade resultando em uma solução mais barata do que um servidor com grande capacidade de processamento e armazenamento. Um sistema escalonado horizontalmente ainda possui a vantagem de ser mais resistente a falhas. Enquanto sistemas centralizados param completamente devido a uma falha, sistemas distribuídos descentralizados podem continuar operando com menor capacidade, ou com ausência temporária de uma porção dos dados, durante falhas em alguns de seus nós. 20

21 Devido às propriedades dos clusters, estes foram vistos como alternativa imediata para o aumento da demanda de armazenamento de dados. Porém, sistemas de bancos de dados relacionais não foram originalmente projetados para operar em clusters (SADALAGE e FOWLER, 2013). Sistemas de bancos de dados relacionais que possuem a capacidade de operar em cluster utilizam um único sistema de arquivos compartilhado entre todos os nós. Dessa maneira, o acesso compartilhado ao dispositivo de armazenado atua como gargalo para o sistema, além de ser um ponto crítico de falha. Existem configurações alternativas ao cluster para escalonar horizontalmente um banco de dados relacional, porém elas também apresentam grande complexidade e sérias limitações. Na arquitetura master- slave um servidor é o master, utilizado apenas para escrita, e outro servidor é o slave, utilizado apenas para leitura. Cada instância deve ser otimizada de acordo com sua função. Para melhorar o desempenho da arquitetura master- slave podem haver várias máquinas master e várias máquinas slave todas sincronizadas e com um servidor de balanceamento de carga dividindo as requisições para os servidores de acordo com o seu tipo, leitura ou escrita. Outra alternativa é particionar os dados entre vários servidores balanceando a carga entre os mesmos. Porém a aplicação deve saber qual servidor consultar para obter determinado conjunto de dados. Além disso não é possível manter restrições de integridade e transações entre dois ou mais servidores. As limitações das ferramentas de bancos de dados relacionais tradicionais levaram algumas empresas a criar suas próprias ferramentas, não baseadas no modelo relacional, capazes de lidar com grandes volumes de dados. Dentre essas soluções, o Bigtable (CHANG, DEAN, et al., 2006) do Google, e o DynamoDB (SIVASUBRAMANIAN, 2012) da Amazon, foram pioneiros. NoSQL, cujo significado do acrônimo é Not Only SQL, é um termo geral criado para classificar esse recente conjunto de soluções de bancos de dados não relacionais. A maioria das soluções que surgiram foram projetadas com o objetivo de serem executados em cluster para trabalhar com um grande volume de dados. Outras foram projetadas para trabalhar com estruturas de dados que eram difíceis de serem armazenadas em bancos de dados relacionais, por exemplo, grafos originados dos relacionamentos entre pessoas em sites de redes sociais. 21

22 3.1 Agregados Os bancos de dados NoSQL não utilizam a definição de esquema como os bancos de dados relacionais, onde as tabelas possuem uma quantidades fixa de campos e cada campo possui um tipo de dado. A estrutura de todas as tuplas armazenadas em uma mesma tabela de um banco de dados relacional é sempre a mesma, e uma unidade de dados que tenha uma estrutura diferente não pode ser armazenada nessa tabela. Os bancos de dados NoSQL são diferentes. Sua unidade de dados é chamada de agregado. Agregados que possuem algo em comum, por definição da aplicação, são armazenados em uma coleção. Para facilitar a compreensão é possível fazer uma analogia entre tuplas e agregados, e entre tabelas e coleções Os agregados de uma mesma coleção podem apresentar estruturas diferentes. Dois agregados em uma mesma coleção podem ter quantidades de campos diferentes ou até tipos de dados diferentes. A Figura 3.1 exibe uma tabela chamada Pessoa Física, contendo dados de pessoas físicas, e uma coleção semelhante em um banco de dados NoSQL. Na coleção não existem colunas que dividem os campos de um agregado. Isso fica mais evidente quando observamos que na tabela existem campos que ficam vazios, com o valor NULL, quando o registro não tem informação para esses campos. Já na coleção não é necessário nem mesmo considerar os campos que não possuem informações, eles simplesmente não são armazenados. Figura Tabela em um banco de dados relacional, e coleção similar, em um banco de dados NoSQL. 22

23 Sem problema algum, é possível inserir na coleção Pessoa Física, um agregado que tenha um campo adicional que não tinha sido previsto anteriormente, e que nenhum outro agregado possua. Por exemplo, um campo para telefone. Veja a Figura 3.2. Figura Campo adicional não previsto em um agregado de uma coleção NoSQL. 3.2 Bancos de dados NoSQL orientados a agregados A sigla NoSQL é um termo guarda- chuva que agrega todos os tipos de soluções que não são classificadas como bancos de dados relacionais. Como mencionado anteriormente, existem vários tipos de bancos de dados, porém aqueles que interessam para este trabalho são os bancos de dados NoSQL orientados a agregados. Os bancos de dados NoSQL orientados a agregados podem ser classificados em três categorias: o modelo baseado em chave- valor; o modelo baseado em documentos; e o modelo baseado em famílias de colunas, column- family. O agregado é opaco para bancos de dados baseados no modelo chave- valor. Para esses bancos de dados, a estrutura, tipo, ou significado, dos dados do agregado são irrelevantes. Esses bancos de dados permitem que sejam realizadas consultas baseadas na chave do agregado e o agregado completo é retornado. Não é possível realizar uma consulta por outro campo que não seja a chave. Também não é possível retornar apenas uma porção do agregado pois a ferramenta não tem conhecimento algum sobre a estrutura do agregado. Utilizando como exemplo a coleção da Figura 3.2, e definindo que o ID é a chave de um agregado, se uma aplicação está interessa em saber o nome da pessoa física com ID de valor igual a 537 é possível consultar a coleção pela chave com valor igual a 537, porém todo o agregado será retornado. Não é possível retornar apenas o ID e o nome da pessoa física ou consultá- la por outro campo, por exemplo, seu nome. Para os banco de dados baseados em documentos o agregado é transparente. Nesses tipos de bancos de dados é possível realizar uma consulta baseada na chave ou outro campo do agregado e obter apenas parte do agregado. No exemplo do parágrafo anterior não seria possível obter apenas o ID e o nome da pessoa física, ou realizar uma 23

24 consulta pelo campo nome, mas para bancos de dados baseado em documento é possível. No entanto, mesmo o agregado sendo transparente para bancos de dados orientados a documento, como não existe esquema para a coleção, o banco de dados não tem meios para otimizar o armazenamento ou a consulta de partes de um agregado. Os bancos de dados baseados em famílias de colunas, colunm- family, dividem um único agregado em famílias, ou grupos, de colunas, impondo uma estrutura mínima ao agregado. Para esse tipo de banco NoSQL, uma família de colunas em um agregado pode ser tratada como uma unidade de dados dentro do agregado. Apesar da desvantagem de impor alguma estrutura ao agregado isso permite que o banco de dados otimize o acesso a porções do agregado. 3.3 Restrições e vantagens de bancos de dados NoSQL orientados a agregados Nos bancos de dados relacionais, registros, ou tuplas, em diferentes relações ou tabelas, podem ser relacionados e esta relação pode ser garantida por meio dos conceitos de chave estrangeira e integridade referencial. Bancos de dados relacionais permitem a manipulação de qualquer combinação de registros de tabelas diferentes em uma única transação. Essas transações seguem os princípios ACID (Atomicity, Consistency, Isolation, Durability). Para os banco de dados NoSQL orientados a agregados não existem esses conceitos, ou pelo menos não da mesma maneira como são conhecidos nos bancos de dados relacionais. Não existem restrições de integridade que garantam o relacionamento entre agregados em coleções diferentes, isso fica por conta da aplicação. Em um banco de dados NoSQL, transações ACID são garantidas apenas para operações em um único agregado. A principal razão para os bancos de dados NoSQL utilizarem o conceito de agregado é que esse conceito é bastante apropriado para a arquitetura em cluster, que é o motivo da ascensão dos bancos NoSQL. Um agregado informa ao banco de dados quais informações devem ser tratadas como uma única unidade indivisível de dados, e por isso essas informações devem ser mantidas em um mesmo nó, máquina servidora. Porém, dois agregados diferentes, mesmo sendo de uma mesma coleção, não precisam ser mantidos em um mesmo nó. A ausência de relacionamentos entre agregados, como bancos de dados relacionais possuem para chaves estrangeiras, facilita ainda mais a divisão dos dados entre vários nós. 24

25 Veja o exemplo da Figura 3.3. Um banco de dados relacional armazena informações a respeito de funcionários e seus dependentes. Existe uma tabela para os funcionários e outra para seus dependentes. É comum que cada registro na tabela de dependentes possua uma chave estrangeira para a tabela de funcionários. Em um banco de dados relacional é difícil particionar essas informações em vários nós. O desempenho de uma consulta seria muito ruim se o registro do funcionário procurado estivesse em um nó enquanto os registro de seus dependentes estão em outro nó. Figura Tabelas relacionadas por meio de chave estrangeira. No caso de um banco de dados NoSQL orientado a agregados, o agregado que representa as informações do funcionário também possui as informações dos dependentes, Figura 3.4. Essas informações são tratadas como uma unidade completa facilitando o particionamento de uma mesma coleção em vários nós. Essa é a chave para o desempenho dos bancos de dados NoSQL. Figura Agregado de uma coleção armazena todos os dados que compõem uma unidade. Os banco de dados NoSQL são relativamente recentes e, devido às diferenças entre o modelo orientado a agregado e o modelo relacional, nem sempre é possível adotar um banco de dados NoSQL prontamente. Muitas vezes é necessário pensar e projetar de forma diferente o domínio e modelo de dados de uma aplicação para tirar proveito das vantagens de um banco NoSQL. Existem casos em que o modelo orientado a agregados não se encaixa bem na regra de negócio e pode ser melhor representado com o modelo relacional tradicional. 25

26 4 Programação orientada a aspecto A programação orientada a aspecto (Aspect- Oriented Programming - AOP), surgiu devido a existência de questões que não são tratadas de maneira adequada pelas metodologias de programação tradicionais. Por exemplo, o logging de uma aplicação. Essa atividade permeia muitas das unidades naturais de modularização de uma aplicação. Para linguagens de programação orientadas a objeto, a unidade natural de modularização é a classe. Nesse caso, em um sistema desenvolvido em uma linguagem de programação orientada a objeto, como Java, o código responsável por realizar logging está presente de maneira indisciplinada em muitas classes do sistema. Atividades como essa são difíceis de encapsular em uma única classe e são espalhadas de forma indesejada por todo o código da aplicação. A programação orientada a aspecto é uma maneira de modularizar atividades como essa, encapsulando- as em módulos chamados aspectos. Esse capítulo explica brevemente a programação orientada a aspecto utilizando como exemplo a extensão AspectJ. Além de facilitar a entendimento dos conceitos de AOP o framework que foi utilizado neste projeto compartilha dos mesmos conceitos do AspectJ. 4.1 AspectJ AspectJ (KISELEV, 2002) é uma implementação de programação orientada a aspecto para Java. O AspectJ adiciona à plataforma Java um novo conceito chamado joint point e algumas estruturas: aspect, pointcut, advice e declarações inter- type. A última não será bordado porque não é necessário para a compreensão do estudo de caso descrito neste trabalho Joint Point Um joint point é apenas um nome dado a um conceito já existente na linguagem Java. Um joint point é um ponto bem definido na execução de um programa. Um dos joint points definidos pelo AspectJ, e de interesse para este trabalho, é a chamada de método. Um joint point de chamada de método inclui todas as etapas envolvidas na chamada, desde seu início, passando pela resolução dos argumentos, até o retorno de um valor. Em tempo de execução cada chamada de método é um joint point diferente, mesmo que as chamadas sejam originadas de uma mesma linha de código. A Figura 4.1 mostra o método save, da interface PosicaoDao do RBRDriver, utilizado para persistir uma Posição na base de dados. 26

27 Figura Método save na interface PosicaoDao da aplicação RBRDriver. Por exemplo, o momento em que uma classe cliente chama o método save em uma instância de uma classe que implementa a interface PosicaoDao, é um joint point. Veja este exemplo na Figura 4.2. A linha selecionada é um joint point, simplesmente um ponto bem definido na execução da aplicação. Figura Chamada ao método save da interface PosicaoDao é um joint point Pointcut Os pointcuts são utilizados quando há interesse em interceptar determinados joint points durante a execução de uma aplicação. Para interceptar os momentos em que o método save, exibido na Figura 4.1, da interface PosicaoDao, é chamado em alguma instância de uma classe que implemente a interface PosicaoDao, ou seja, interceptar os joint points que correspondem a chamada desse método, o pointcut, de nome logsave, mostrado na Figura 4.3 é utilizado. O pointcut mostrado na Figura 4.3 vai interceptar cada joint point que seja uma chamada para o método save da interface PosicaoDao. Observe a linha seis da Figura 4.3. A assinatura completa do método é utilizada para especificar o joint point. Todas as vezes em que esse joint point especificado na linha seis da Figura 4.3 ocorrer durante a execução da aplicação, este será capturado pelo pointcut logsave. 27

28 Figura Pointcut logsave intercepta chamada ao método save da interface PosicaoDao Advice Um pointcut têm a função de apenas interceptar joint points. Para implementar ações que devam ser executadas quando um joint point for interceptado é necessário implementar um advice. É em um advice que o desenvolvedor vai escrever o código que ele deseja que seja executado quando o joint point especificado pelo pointcut for interceptado. Existem três tipos de advice: before, que executa antes da execução do joint point, logo após a avaliação dos argumentos do método se o joint point for uma chamada de método; after, executa logo após a execução do joint point; around, executa no lugar do código invocado pelo joint point. Se o joint point for uma chamada de método, ao invés do corpo do método chamado ser executado, o código do advice será executado. A Figura 4.4 exibe, entre as linhas doze e vinte, um advice do tipo after cujo código é executado imediatamente após a execução do joint point interceptado pelo pointcut logsave. Esse advice, do tipo after, foi implementado para logar quando um registro Posição é salvo na base de dados. Se o advice da Figura 4.4 fosse do tipo before o código seria executado antes do joint point interceptado pelo pointcut logsave. Se o advice da Figura 4.4 fosse do tipo around, ao invés do código do joint point, o método save, ser executado, o código implementado pelo advice seria executado. Porém um advice do tipo around também podem invocar o código do joint point que ele está suprimindo, basta realizar uma chamada ao método proceed no corpo do advice. 28

29 Figura Advice que loga persistência de uma Posição acessa contexto do joint point. Um advice pode ter acesso ao contexto do joint point interceptado pelo pointcut. Para isso o pointcut deve expor contexto do joint point. É o que mostra a Figura 4.4. Os pointcuts podem expor o objeto no qual é realizada a chamada de método, no caso do joint point ser uma chamada de método. Esse objeto é denominado target. No exemplo da Figura 4.4 o objeto no qual o método save é chamado é exposto. Além disso, os argumentos passados para o método também são expostos. A primitiva target do pointcut expõe o objeto no qual o método foi chamado, e a primitiva args expõe os argumentos passados para o método. A assinatura do pointcut precisa declarar os elementos expostos. Na Figura 4.4 é possível verificar como o advice recebe como argumentos os elementos expostos. A partir desse ponto o advice pode executar qualquer código, inclusive utilizando os parâmetros recebidos Aspecto Por fim, o aspecto é a unidade de modularização da programação orientada a aspecto, assim como a classe é para a programação orientada a objeto. No AspectJ, os aspectos são declarados com a palavra chave aspect como pode ser visto na Figura 4.4. O aspecto encapsula os pointcuts e os advices. Muito semelhante, a classes Java também é permitido que aspectos tenham atributos e métodos. Como as classes, os aspectos podem ser instanciados, mas é o AspectJ quem controla como essa instanciação acontece. O desenvolvedor não pode utilizar o operador 29

30 new da linguagem Java para instanciar um aspecto. Por padrão os aspectos são Singletons. Para compilar os arquivos de aspectos, que possuem extensão.aj, é necessário utilizar o compilador ajc. O compilador ajc realiza uma operação chamada weaving. Weaving é a ligação em nível de bytecode, realizada durante a compilação, entre os aspectos e os objetos da aplicação para que possa acontecer o monitoramento dos joint points. Para executar aplicações Java contendo aspectos AspectJ é necessário adicionar a biblioteca de runtime aspectjrt.jar no classpath da aplicação. 4.2 Spring AOP O Spring AOP é parte integrante do framework Spring (HO e HARROP, 2012) e implementa as capacidades da programação orientada a aspecto. Foi criado inicialmente para complementar o Spring IoC, o container para injeção de dependência e inversão de controle do framework Spring. Porém ele é uma implementação de AOP bastante eficiente e pode ser utilizado pelos desenvolvedores para seus próprios objetivos. O Spring AOP merece uma breve descrição porque foi utilizado na implementação estudada neste trabalho e será mencionado adiante no texto. Os conceitos de joint point, pointcut e advice, explicados utilizando como exemplo o AspectJ, também estão presentes no Spring AOP. Porém, diferentemente do AspectJ, no Spring AOP os aspectos são implementados utilizando classes Java comuns. Existem três maneiras para uma classe assumir a função de um aspecto: utilizando annotations utilizando arquivos XML que declaram a classe como um aspecto além de declarar os pointcuts; ou mesclando as duas maneiras. É possível indicar ao framework Spring quais classes implementam aspectos utilizando XML em um arquivo de configuração, e na classe especificar os joint points e advices por meio de annotations. Existem outros tipos de joint points e estruturas AOP que não foram abordadas neste capítulo pois seu objetivo é apenas apresentar conceitos essenciais para a compreensão deste trabalho. 30

31 5 A linguagem de programação Groovy Groovy (KOENIG, GLOVER, et al., 2007) é uma linguagem de programação moderna e dinâmica derivada da linguagem Java e construída sobre a plataforma Java. Ela oferece muitos recursos avançados inspirados em linguagens como Python, Ruby, e Smalltalk. A linguagem Groovy é opcionalmente tipada e oferece uma sintaxe mais intuitiva, concisa, e expressiva, do que a linguagem Java, além de permitir a criação de scripts. 5.1 Sintaxe Apesar da adição de estruturas que permitem um código mais conciso e expressivo, a sintaxe Groovy é bastante alinhada com a sintaxe Java. Isso permite que o desenvolvedor Java migre para Groovy quase que imediatamente. À medida que seu conhecimento da linguagem Groovy é aprofundado, ele pode criar códigos mais claros e concisos utilizando as estruturas oferecidas pelo Groovy. A ffigura 5.1 mostra o método main de uma classe Java que calcula a média aritmética dos valores o fornecidos como argumentos. Figura 5.1 Classe Java determina média aritmética dos valores de entrada. Já o código da Figura 5.2 exibe um script Groovy que tem a mesma função da classe da Figura 5.1. O código da segunda figura é mais expressivo, porém semelhante à sintaxe Java. Figura Script Groovy determina média aritmética dos valores de entrada. Se o código da Figura 5.1 for salvo em uma classe Groovy (um arquivo com extensão.groovy), ele também irá funcionar. Até mesmo mesclar código no estilo Java e código no estilo Groovy na mesma classe é permitido. Isso facilita bastante a adoção da linguagem Groovy. 31