Java EE 6 com MongoDB na prática - Revista Java Magazine 97

NoSQL é um termo, relativamente recente, que tem aparecido com frequência na agenda de desenvolvedores e arquitetos de soluções. Embora ainda não tenha uma definição precisa, o termo é usado para classificar um conjunto de ferramentas de armazenamento de dados que possuem um modelo de dados diferente do tradicional modelo relacional, e/ou que se diferenciam dele em algum aspecto arquitetural, tal como no modelo de consistência, de distribuição ou de linguagem para manipulação de dados. Tal termo também é utilizado para falar sobre uma “corrente” de arquitetura, que prega uma análise mais profunda das necessidades de persistência das aplicações e o uso das ferramentas citadas complementando os tradicionais SGBDs relacionais. Este aspecto complementar é enfatizado pelo significado da sigla ser “Not Only SQL” (Não Somente SQL) – ao contrário do sugerido por um contato inicial (Não SQL).

Em edições anteriores da revista, o tema NoSQL foi abordado em uma série de artigos de Alexandre Porcelli, um dos maiores especialistas do assunto no Brasil, no qual apresentou-se os principais conceitos e paradigmas relacionados ao tema, as ferramentas mais utilizados e como escolher entre as diversas opções disponíveis.

Este artigo explora em maior profundidade um dos bancos NoSQL mais comentados e utilizados atualmente: o MongoDB (de humongous, gíria americana que significa extraordinariamente grande). Para tal, construímos uma aplicação exemplo baseada nos mais recentes padrões do Java EE 6, tais como JSF 2.0, CDI 1.0 e EJB 3.1, e implementamos a persistência através do MongoDB.

A aplicação consiste em um player de músicas acessado através da web, com recursos de redes sociais para compartilhamento de opiniões. Através desse rico estudo de caso, exemplificamos como a modelagem orientada a documentos, utilizada pelo Mongo, difere da tradicional modelagem entidade-relacional. Mostramos também como interagir com o MongoDB através do driver Java, além de ilustrar técnicas de construção de aplicações e boas práticas das APIs Java EE quando utilizadas em conjunto. Por fim, exploramos recursos avançados disponíveis na plataforma, tais como a injeção de dependências e a implementação do padrão Observer disponíveis no CDI, o uso de mensagens assíncronas através do JMS e chamadas Ajax na camada de apresentação.

Como veremos, o MongoDB oferece uma boa alternativa para a persistência de dados, provendo facilidades para um desenvolvimento altamente produtivo e um produto final de ótimo desempenho. Esperamos com isso incentivar o leitor ao seu uso e ao estudo de outras ferramentas NoSQL, ampliando o seu leque de opções e ajudando-o a fazer as escolhas mais adequadas de ferramentas de armazenamento de dados.

Aplicação exemplo

A aplicação a ser construída é um player de músicas online, acessado pela Web, com recursos de redes sociais para compartilhamento de opiniões e notas, e um mecanismo automatizado para inserção de novas músicas no repositório.

Algumas das funcionalidades que estão disponíveis para o usuário são:

·         Criação de Playlists: o usuário pode criar listas de execuções com suas músicas preferidas. No momento da criação, ele busca as músicas cadastradas no sistema através do nome e as adiciona à lista;

·         Escutar Playlists: o usuário tem a disposição um player de música, em que ele seleciona uma playlist anteriormente criada para tocar. Neste momento, ele pode também comentar sobre as músicas e avaliá-las, além de visualizar os comentários e notas de outros;

·         Inserir Músicas: o processo de inserção de novas músicas no repositório da aplicação é feito através de um processo de indexação de diretórios. O usuário aponta um diretório e a aplicação encarrega-se de ler todas as músicas no formato MP3, cadastrando-as automaticamente.

Como todo serviço de sucesso, essa aplicação possui também alguns requisitos extras que precisam ser atendidos:

·         Tempo muito pequeno para seu lançamento inicial;

·         Preparação para explosão, a qualquer momento, no número de usuários;

·         Adição de funcionalidades constantes e não disruptivas.

Analisando-se estas características, além da necessidade de bom desempenho para pequenas (e muitas) leituras e escritas e a expectativa da geração de grande volume de dados, o MongoDB torna-se um bom candidato para implementação da persistência da aplicação.

Preparando o ambiente

Para a execução da aplicação, iremos precisar de um servidor de aplicações Java EE 6 e um servidor de banco de dados MongoDB. O servidor Java EE 6 utilizado foi o GlassFish 3.1, mas não deve haver problemas com outros servidores.

Configurando o GlassFish

O processo de instalação do GlassFish pode ser consultado em seu próprio site (ver seção Links [2]). Adicionalmente, é necessária a criação de uma fila JMS no servidor. Como veremos a frente, ela é necessária para a comunicação assíncrona e fracamente acoplada entre dois módulos da aplicação.

Podemos criar esse recurso diretamente pela interface de administração do GlassFish ou podemos utilizar a ferramenta de linha de comando asadmin. Para utilizar essa ferramenta, o primeiro passo é criar um arquivo de configuração com os recursos que serão adicionados. Assim, crie um arquivo chamado glassfish-resources.xml em uma pasta de sua preferência com o conteúdo da Listagem 1.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE resources

  PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN"

  "http://glassfish.org/dtds/glassfish-resources_1_5.dtd">

"